Een oplossing die het probleem niet oplost, maar juist problemen veroorzaakt. Het klinkt ironisch, maar bleek helaas de realiteit. In deze blog leg ik uit hoe de RESURGE-malware misbruik maakte van een kwetsbaarheid in Ivanti Connect Secure en een threat actor ongezien remote toegang kan geven tot je netwerk.
Ivanti Connect Secure
Ivanti Connect Secure (ICS) is een oplossing waarmee een organisatie remote toegang tot haar vertrouwde omgevingen kan beheren. De oplossing wordt geplaatst tussen het openbare internet en het eigen vertrouwde netwerk en fungeert daar als security checkpoint of gateway. Op het moment dat iemand verbinding probeert te maken, controleert de ICS-oplossing of voldaan wordt aan vooraf ingestelde beveiligingseisen.
Omdat deze oplossing aan de rand van het netwerk staat, wordt dit type systeem een ‘edge-device’ genoemd. Van iedere binnenkomende verbinding wordt geacht dat aangetoond kan worden dat diegene is wie diegene zegt wie het is en wordt gecontroleerd of hetgeen wat diegene wil gaan doen, ook is toegestaan. Van al deze verbindingen, de doorlopen controles en de resultaten van deze controles wordt bewijs vastgelegd. Deze logging is essentieel, zowel voor security reviews als voor forensisch onderzoek.
Kritieke kwetsbaarheid
Begin 2025 maakte Ivanti bekend dat er sprake was van actief misbruik van een tot dan toe onbekende kwetsbaarheid in ICS. Het betrof een zero-day-kwetsbaarheid, geregistreerd als CVE-2025-0282 en beoordeeld met een CVSS-score van 9. Deze kritieke ‘stack based buffer overflow’ maakt het mogelijk om zonder authenticatie willekeurige code uit te voeren op de ICS-oplossing.
In de praktijk betekent dit dat een specifiek vormgegeven verzoek ervoor kan zorgen dat de ICS-oplossing alle ingestelde beveiligingsinstructies ‘vergeet’ en vervangt door nieuwe instructies. Hiermee wordt het security checkpoint zelf misbruikt als ingang. Gelijktijdig met de bekendmaking bracht Ivanti een update uit om deze kwetsbaarheid te verhelpen.
Welk risico loop je?
Geautomatiseerd misbruik
Zero-day-kwetsbaarheden zijn in eerste instantie slechts bekend bij een beperkt aantal geavanceerde threat actors. Het risico neemt echter toe zodra een kwetsbaarheid openbaar wordt gemaakt en een update beschikbaar komt. Door reverse-engineering van de update wordt zichtbaar hoe de kwetsbaarheid misbruikt kan worden.
Dit verlaagt de drempel voor minder geavanceerde aanvallers. Het risico wordt pas echt groot wanneer geautomatiseerde malware beschikbaar komt die deze kwetsbaarheid misbruikt. In dat geval hoeft een aanvaller geen diepgaande kennis meer te hebben; een toegankelijk doelwit is voldoende. Dit maakt grootschalige besmetting mogelijk.
Besmetting met RESURGE-malware
Zoals we eerder beschreven in de ‘Wake-up Wednesday’ van 04 maart 2026, publiceerde het Amerikaanse ‘Cybersecurity and Infrastructure Security Agency’ (CISA) een update op diens analyse report over de RESURGE-malware. De RESURGE-malware maakt misbruik van deze kwetsbaarheid in de ICS-oplossing. Door de buffer overflow wordt de beveiligingsfunctie van het systeem uitgeschakeld en fungeert het device als toegangspunt voor de threat actor. De malware is in eerste instantie passief en zoekt niet actief contact met de aanvaller. Activatie vindt plaats via een automatisch proces waarbij een TLS-handshake wordt gebruikt om een versleutelde mTLS-sessie op te zetten. Deze werkwijze maakt detectie lastig, omdat het proces lijkt op legitieme beveiligde communicatie.
Mogelijkheden van de RESURGE-malware
RESURGE bestaat uit een primair implantaat (‘libdsupgrade.so’) en aanvullende tooling voor logmanipulatie en firmware-toegang. De malware wordt geïnstalleerd in zowel de firmware als de bootimage, waardoor persistentie ontstaat. Een herstart of software-update verwijdert de malware niet. Omdat de ICS-oplossing verantwoordelijk is voor identiteitsvalidatie, stelt RESURGE de threat actor in staat om inloggegevens te verzamelen. Deze gegevens kunnen vervolgens misbruikt worden op het interne netwerk. De aard van de malware maakt het daarnaast mogelijk om logs te bewerken en bewijsmateriaal te verwijderen, waardoor misbruik langdurig onopgemerkt kan blijven.
Wat is je handelingsperspectief
Kun je een besmetting voorkomen?
Na publicatie van de kwetsbaarheid kan het installeren van de beveiligingsupdate besmetting voorkomen op systemen die nog niet gecompromitteerd zijn. De kwetsbaarheid werd echter al actief misbruikt vóórdat de update beschikbaar was. Dit betekent dat een ICS-oplossing al besmet kan zijn, ook als deze inmiddels geüpdatet is. De update ontneemt een threat actor niet automatisch de bestaande toegang. Aanvullend onderzoek is noodzakelijk.
Hoe onderzoek je of je besmet bent?
Het vaststellen van een besmetting vereist specialistisch forensisch onderzoek. Hierbij wordt gekeken naar specifieke kenmerken van de RESURGE-malware, waaronder:
- De activatie – De RESURGE-malware is initieel passief en dient te worden geactiveerd door middel van een TLS-handshake, waarna een versleutelde mTLS-sessie wordt opgezet. Dit kan gecontroleerd worden in het netwerkverkeer
- De installatie- De RESURGE-malware wordt geïnstalleerd op de ICS-oplossing. Dit betekent dat er gecontroleerd kan worden of de hiervoor benodigde bestanden, zoals ‘libdsupgrade.so’ en ‘liblogblock.so’ te vinden zijn op de ICS-oplossing.
- Het wissen van bewijs – De RESURGE-malware maakt het mogelijk om bewijsmateriaal te wissen, door de logregels van malafide activiteiten achteraf te verwijderen. Dit heeft als gevolg dat er niet-verklaarbare ‘gaten’ in de beschikbare logs zijn, waar op gecontroleerd kan worden.
Op basis van deze controles kan worden vastgesteld of besmetting aannemelijk is en of er mogelijk misbruik heeft plaatsgevonden.
Hoe herstel je van een besmetting
Het advies is om de ICS-oplossing volledig te herstellen naar fabrieksinstellingen. Omdat RESURGE persistentie heeft verkregen in firmware en bootimage, kunnen bestaande installatiebestanden niet worden vertrouwd. Ivanti heeft specifieke herstelstappen gepubliceerd. Voorafgaand aan herstel is het raadzaam om bewijsmateriaal veilig te stellen en onderzoek te doen naar de impact. Pas wanneer duidelijk is wat er is gebeurd, kunnen aanvullende herstelmaatregelen zorgvuldig worden bepaald.
Onderzoeken van de impact
Wat is er gebeurd? Waar had de threat actor toegang toe? Is er data gestolen? Is er sprake van een meldplichtig datalek of incident? Deze vragen vereisen gedegen onderzoek.
De kwaliteit en beschikbaarheid van logs zijn hierbij doorslaggevend. Bij een gecompromitteerd systeem kunnen logs ontbreken of onbetrouwbaar zijn. Daarom is het noodzakelijk om ook logs van aangrenzende systemen te betrekken. Alleen zo kan de impact worden vastgesteld en kunnen vervolgacties, meldingen en herstelmaatregelen onderbouwd worden.
Conclusie
Zero-day-aanvallen zoals deze zijn niet te voorkomen. Dit maakt voorbereiding cruciaal. Niet alleen technische detectie is belangrijk, maar ook het vermogen om snel en goed onderzoek uit te voeren. Organisaties moeten zich afvragen of zij hierop zijn ingericht. Wie moet worden gebeld bij een incident? Wie neemt de telefoon op? En welke vervolgstappen zijn nodig?
Daarover nadenken vóór een incident, voorkomt improvisatie tijdens het incident. Dat bepaalt uiteindelijk hoe weerbaar een organisatie werkelijk is.
Dit is een ingezonden bijdrage van Tesorion. Via deze link vind je meer informatie over de mogelijkheden van het bedrijf.