De vpn was bijgewerkt. De sleutelkast niet.

Op 3 oktober draaide er bij een organisatie een Ivanti-vpn-server die volledig bijgewerkt was. Laatste versie, groen vinkje in het patchdashboard, niemand die er wakker van lag. Twee weken later weten we dat een aanvaller op diezelfde server volledige controle (root) had en vanaf daar in Active Directory rustig ging zoeken naar BitLocker-herstelsleutels en LAPS-wachtwoorden: de sleutels om versleutelde laptops te openen en de lokale beheerderswachtwoorden van werkplekken.

Het pijnlijke zit niet in de zeroday. Zerodays overkomen je. Het pijnlijke zit in de vraag waarom een vpn-apparaat überhaupt in de buurt van de sleutelkast mocht komen. Dat is geen patchvraag. Dat is een vraag over Active Directory beveiliging.

Wat er gebeurde met Ivanti Connect Secure

• Onderzoeksbureau Volexity ontdekte de aanval begin oktober bij een klant. Het apparaat draaide versie 22.8R2.4, op dat moment de nieuwste.
• De aanvaller koppelde drie kwetsbaarheden: een authenticatie-omzeiling, code-uitvoering en een rechtenverhoging. Resultaat: volledige controle over de vpn-server, zonder ooit in te loggen.
• Ivanti bracht op 13 oktober updates uit voor CVE-2026-104935 (omzeiling plus code-uitvoering). Een deel was volgens Ivanti al in juli gepatcht; de fix voor de rechtenverhoging volgt volgens Volexity later.
• Daarna gebruikte de aanvaller het opgeslagen domein-serviceaccount van de appliance om via LDAP te zoeken naar LAPS-wachtwoorden, BitLocker-herstelsleutels en wachtwoordattributen. Een hernoemde netwerksniffer ving ondertussen LDAP- en HTTP-inloggegevens en NTLM-hashes op.
• Logregels werden gewist. De eigen Integrity Checker van Ivanti vond niets; Volexity had geheugenanalyse nodig.

Ivanti spreekt van een “beperkt aantal” getroffen klanten en heeft geen betrouwbare sporen waarmee je een inbraak kunt herkennen (indicators of compromise, IoC’s). Het NCSC schat kans en schade als hoog in. Wie erachter zit is onbekend; Volexity vermoedt met lage zekerheid een crimineel motief. Of de zoektocht naar sleutels iets opleverde, staat niet in de openbare analyse.

Wat mag het serviceaccount van je vpn eigenlijk lezen?

Daar zit de echte les. Of die zoektocht iets opleverde, hangt van één ding af: welke rechten dat ene serviceaccount had. Een vpn moet gebruikers kunnen controleren. Het hoeft geen BitLocker-herstelsleutel van de laptop van de CFO te kunnen lezen.

Toch zijn serviceaccounts vaak de rommelzolder van het domein. Ooit aangemaakt door een leverancier, rechten verruimd “omdat het anders niet werkte”, wachtwoord ouder dan de huidige IT-manager. Niemand is eigenaar, dus niemand kijkt.

ISO 27002 is hier niet vaag over: toegangsrechten op basis van need-to-know (5.15 en 5.18), speciale toegangsrechten beperkt en beheerd (8.2). LAPS-wachtwoorden en herstelsleutels zijn precies zulke speciale rechten. Ze horen leesbaar te zijn voor een kleine, benoemde groep, en bulkopvragingen horen een alarm te geven. Wie het beheer van beheerdersrechten alleen op mensen richt, vergeet de accounts die nooit met vakantie gaan.

Vpn-beveiliging: het apparaat waar je het minst in kunt kijken

Een vpn-appliance is een vreemde gast. Hij staat aan de rand van het netwerk, krijgt van iedereen het meeste vertrouwen, en je kunt er zelf nauwelijks in kijken. In dit geval vond zelfs de controletool van de leverancier niets. De aanval werd zichtbaar doordat iemand het netwerkverkeer rond het apparaat bewaakte.

Behandel zo’n apparaat daarom als buurman, niet als huisgenoot. Zet het in een eigen segment (ISO 27002 8.22), laat het alleen praten met wat het nodig heeft, en monitor wat er vanaf komt (8.16). Een vpn die ineens vragen stelt over herstelsleutels is net zo verdacht als een postbode die vraagt waar je de reservesleutel bewaart. Voor organisaties onder de Cbw valt dit gewoon onder de zorgplicht: kwetsbaarheidsbeheer en toegangsbeveiliging staan met zoveel woorden in NIS2 artikel 21.

Patchen is een vinkje, herstel is een proces

Het NCSC zegt het droog: “alleen updaten maakt een eerdere inbraak niet ongedaan.” Dat is de zin die in veel organisaties wegvalt tussen het change-ticket en de vrijdagmiddagborrel. De update is geplaatst, het ticket is dicht, het risico staat in het register op ‘behandeld’.

Maar als je leverancier zegt dat er geen betrouwbare sporen zijn om een inbraak te herkennen, dan weet je dus niet of je getroffen bent. Dan hoort de incidentprocedure (ISO 27001 A.5.24 tot en met 5.26) te bepalen wat je wél doet: wachtwoord van het serviceaccount vervangen, LAPS-wachtwoorden laten vernieuwen, nagaan of herstelsleutels zijn opgevraagd. En vastleggen waarom je besluit dat het geen meldplichtig incident is, mocht je dat besluiten.

Drie vragen voor maandagochtend

1. Welke rechten heeft het serviceaccount van onze vpn (en van de firewall, de scanner en die ene printer) in Active Directory, en wie heeft dat voor het laatst getoetst?
2. Wie kan BitLocker-herstelsleutels en LAPS-wachtwoorden lezen, en zien we het als iemand ze in bulk opvraagt?
3. Als een leverancier van een apparaat aan de rand van ons netwerk morgen meldt dat er geen betrouwbare sporen zijn: wat is ons plan, behalve patchen en hopen?

De voordeur zat volgens de laatste specificaties op slot. Alleen hing de sleutelbos van het hele pand aan een haakje direct erachter.

Bronnen

• Security.NL: Ivanti vpn-servers volledig gehackt bij aanval, aanvallers zoeken BitLocker keys (14-10-2026)
• Security.NL: Ivanti waarschuwt voor misbruik van lek in Connect Secure vpn-servers (13-10-2026)
• Volexity: A series of unauthenticated events, chained exploitation of Ivanti Connect Secure zero-days
• NCSC: Zero-day kwetsbaarheid in Ivanti Connect Secure, update direct