'Ivanti-lek trof Belgische Staatsveiligheid, criminelen stalen persoonsgegevens'

De Belgische Staatsveiligheid is getroffen door een cyberaanval, schrijft de Franstalige omroep RTBF. Daarbij zouden gegevens als namen en telefoonnummers van personeelsleden zijn gestolen.

Cybercriminelen gebruikten volgens RTBF een lek in de externe vpn-software Ivanti Mobile, die de telefoons van de Staatsveiligheid beveiligt. Dit lek trof ook andere organisaties, waaronder de Europese Commissie, de Nederlandse Rechtspraak, de Autoriteit Persoonsgegevens en de Dienst Justitiële Inrichtingen. De organisatie verhielp het lek begin dit jaar.

De criminelen zouden onder meer voor- en achternamen, telefoonnummers en e-mailadressen van personeelsleden van de Belgische burgerlijke geheime dienst hebben gestolen. Ook kregen ze mogelijk toegang tot gps-gegevens. De gevoeligste informatie bleef volgens de omroep buiten schot, aangezien de verzending daarvan niet via het reguliere telefoonnetwerk gaat. Staatsveiligheid reageerde niet op vragen van RTBF. Bronnen zeggen tegen de omroep wel dat de dienst 'maatregelen' heeft genomen naar aanleiding van de aanval, maar gaan niet verder daarop in.

Reacties (25)

[Gijs007]

Voor de mensen die niet bekend zijn met een Belgisch instituut genaamd "Staatsveiligheid", het is de Belgische tegenhanger van de AIVD. Zie ook: Wikipedia: Dienst voor de Veiligheid van de Staat

[wildhagen]

een lek in de externe vpn-software Ivanti Mobile,

Ivanti heeft meer Mobile producten, het gaat hier specifiek om Ivanti Endpoint Manager for Mobile, andere producten uit de Mobile-reeks zijn (zover bekend dan) niet betrokken.

Het gaat blijkbaar om exploit(s) voor deze twee lekken: https://hub.ivanti.com/s/...-2026-1340?language=en_US

Dit waren twee lekken, beiden als Critical gerate, met beiden een CVE-rating van 9.8 (uit een maximale 10).

Daarvoor is op 4 februari door Ivanti al een fix uitgebracht. Nu weet ik niet wanneer deze hack gebeurd is (ik kan het niet uit het RTBF-artikel halen iig) maar je zou toch verwachten dat een dienst die met zulke gevoelige info werkt een patch met zo'n hoge CVE-score a.s.a.p. installeert.

[Fietsventje]

Volgens de nieuwsdienst van de VRT gaat het om eind 2025, begin 2026:

De Staatsveiligheid is tussen mei 2025 en het voorjaar van 2026 het slachtoffer geworden van een cyberaanval, waarbij er mogelijk personeelsgegevens gestolen zijn.

Bron: Staatsveiligheid slachtoffer van cyberaanval: mogelijk gegevens van agenten gestolen

[applesap]

Nu weet ik niet wanneer deze hack gebeurd is (ik kan het niet uit het RTBF-artikel halen iig) maar je zou toch verwachten dat een dienst die met zulke gevoelige info werkt een patch met zo'n hoge CVE-score a.s.a.p. installeert.

Allereerste zin van het RTBF artikel:

Entre mai 2025 et le printemps 2026, le service belge de renseignement civil a été victime d’une cyberattaque compromettant les données personnelles de ses agents, deux ans après un incident similaire

VRT artikel voor diegene die liever Nederlands lezen: https://www.vrt.be/vrtnws/nl/2026/06/20/staatsveiligheid-cyberaanval/

[Reactie gewijzigd door applesap op 20 juni 2026 13:08]

[RichardMe]

[...] maar je zou toch verwachten dat een dienst die met zulke gevoelige info werkt een patch met zo'n hoge CVE-score a.s.a.p. installeert.

Niet dus. VPN access direct uitschakelen doen ze niet “want dat is lastig”. En zo’n patch moet eerst geïnstalleerd worden in een test omgeving, getest worden. Daarna hetzelfde riedeltje op een quality assurance omgeving etc etc. En al die stappen moeten besproken en ingepland worden tijdens de standup. En zo gaat het dus iedere keer mis.

[Reactie gewijzigd door RichardMe op 20 juni 2026 13:27]

[BvdW1978]

Interessant is dat altijd inderdaad. "De boel staat in de fik!".. okee.. maar kwaliteitsproces. Okee. Maar de "kwaliteit" van de fix gaat vrij moeilijk slechter worden dan de huidige staat van het systeem. Zullen we even tempo maken anders?

[RichardMe]

“Je kunt het toch nooit helemaal voor zijn”. “Moeten we dat dan iedere keer gaan doen als ergens een patch voor verschijnt?”. 😉🫤

[macaidwin]

"Niet doen? Zou je me dat dan even per mail willen bevestigen met een aantal mensen in de cc?"

[BvdW1978]

Heerlijke gesprekken zijn dat altijd inderdaad. Je moet dit altijd kunnen doen. Als je niet in staat bent een patch heel snel door een keten van kritieke infrastructuur te drukken zonder dat de stukken eraf vliegen, is je proces ontoereikend. Misschien is dat pijnlijk om te horen, maar daar trekt de operationele realiteit zich helaas weinig van aan.

[Keypunchie]

Binnen de meeste processen is er voor "emergency patches" gewoon een versneld traject.

Daar mag een organisatie zich niet achter verschuilen.

[Blokker_1999]

Als een probleem ernstig genoeg is en waarbij mitigatie of patching niet onmiddelijk mogelijk is, dan is het uitschakelen van de dienst echt wel een optie voor zulke organisaties. Wanneer veiligheid voor op komt, dan neem je het ongemak dat men enkel nog vanop kantoor kan werken in geval van nood er gewoon bij.

Ik vind het spijtig dat mensen de slechte manier van werken altijd en overal maar weer blijven projecteren als het ergens mis gaat. De kans bestaat dat men al binnen zat voordat Ivanti er van wist. Dit is het soort van primaire doelwitten voor dit soort aanvallen uiteindelijk.

En het is perfect mogelijk om bij alles de best practices toe te passen, ook bij noodpatching (dat is waar emergency changes voor zijn) en toch nog slachtoffer te worden.

[theduke1989]

[...]


Daarvoor is op 4 februari door Ivanti al een fix uitgebracht. Nu weet ik niet wanneer deze hack gebeurd is (ik kan het niet uit het RTBF-artikel halen iig) maar je zou toch verwachten dat een dienst die met zulke gevoelige info werkt een patch met zo'n hoge CVE-score a.s.a.p. installeert.

Je zult versteld staan hoeveel bedrijven wachten met dit soort dingen.

Wij persoonlijk proberen altijd dezelfde week de fix uit te voeren.

Rapid7 toont de score en de oplossing. En wij passen het toe.

[baseoa]

Is iemand hier bekend met dit soort producten en kan uitleggen waarom ze niet hun VPN baseren op iets dat niet constant pre-auth RCE-lekken heeft?

Het gebeurt aan de lopende band:

een lek in de externe vpn-software Ivanti Mobile, [...]. Dit lek trof ook andere organisaties, waaronder de Europese Commissie, de Nederlandse Rechtspraak, de Autoriteit Persoonsgegevens en de Dienst Justitiële Inrichtingen.

Elk jaar is het ook weer raak met bijvoorbeeld een actief uitgebuit lek in Fortinet en ik meen ook iets van Cisco vaker voorbij te zien komen (kom niet op de naam).

Gebruikers kunnen niet allemaal zelf een Wireguard-client aanslingeren, dus dat er een gebruiksvriendelijke en op-afstand-beheerde client moet zijn: sure. Maar waarom doe je niet de authenticatie via Wireguard of OpenVPN en steek je de extra functionaliteit binnen de vertrouwde tunnel? Niet dat je daar nooit binnenkomt (phishing bijv.) maar dan kun je al niet zomaar de aanval op iedereen tegelijk uitvoeren omdat je eerst op iedereens netwerk moet binnendringen

[Reactie gewijzigd door baseoa op 20 juni 2026 14:06]

[The Zep Man]

Is iemand hier bekend met dit soort producten en kan me uitleggen waarom ze niet hun VPN baseren op iets dat niet constant pre-auth RCE-lekken heeft?

Ieder van dit soort bedrijven wil hun eigen protocol implementeren, wat niet compatibel is met andere protocollen om zo vender lock-in te forceren. Het is niet alleen Ivanti die hierdoor geraakt wordt. F5, Cisco, Citrix, ... Ze implementeren allemaal een TLS-smaakje veilige verbinding en trappen ieder steeds opnieuw in dezelfde valkuilen. Het blijkt dat veilig software ontwikkelen erg lastig is.

[baseoa]

Incompatibel zijn ze sowieso. Binnen de tunnel kan er een hoop extra functionaliteit zijn (om bijvoorbeeld updates uit te rollen) waardoor je niet simpelweg de ene client met de andere server kan gebruiken. Je kan dan hooguit authenticeren maar vervolgens loopt het alsnog vast

Daarnaast is het van de grond af aan opbouwen veel te kostbaar vergeleken met een byte voor de header gooien die de opensource of concurrerende servers niet snappen (als je xGET in plaats van GET stuurt naar een webserver, krijg je al een foutmelding terug). Ik ken de softwarebranche en kan me niet voorstellen dat ze zoveel moeite steken voor hetzelfde effect als hier en daar een byte veranderen

[Reactie gewijzigd door baseoa op 20 juni 2026 14:01]

[The Zep Man]

Incompatibel zijn ze sowieso. Binnen de tunnel kan er een hoop extra functionaliteit zijn (om bijvoorbeeld updates uit te rollen) waardoor je niet simpelweg de ene client met de andere server kan gebruiken. Je kan dan hooguit authenticeren maar vervolgens loopt het alsnog vast

En door iedereen zelf een full stack op te laten bouwen, maakt iedereen dezelfde full stack fouten.

Daarnaast is het van de grond af aan opbouwen veel te kostbaar

Eens. Gebruik voor OSI level 3/4-geneuzel dan ook gewoon een bestaand protocol en implementatie van de stapel.

[Reactie gewijzigd door The Zep Man op 20 juni 2026 14:02]

[baseoa]

En door iedereen zelf een full stack op te laten bouwen, maakt iedereen dezelfde full stack fouten.

Maar waarom zouden ze? Die extra functies (de stack van eigen producten) kan toch prima achter een oud en vertrouwd authenticatieprotocol zitten?

Het is namelijk tekens weer een pre-auth bug. Met 'privileges required for exploitation', en 'adjacent network' als attack vector, geeft CVSS je niet een moord-en-brand score (in dit geval 9.8 van de 10)

[mocean]

Omdat ze pre-auth willen kunnen updaten/configs pushen.

[The Zep Man]

Omdat ze pre-auth willen kunnen updaten/configs pushen.

"Pre-auth" is OSI-niveau 5-7. Dat heeft niets met met 3-4 te maken. Je kan een eigen oplossing daarvoor ontwikkelen die gedragen wordt door bestaande protocollen.

[CH4OS]

En 2FA is ook een deel van het antwoord.

[baseoa]

Deze bug is zo te zien pre-auth. Dan kun je 7FA hebben, blijkbaar wordt dat component omzeild

[Blokker_1999]

Noem eens een product dat gegarandeerd veilig is zou ik zeggen. Want dat bestaat niet. Ook andere leveranciers, of het nu Cisco, Palo Alto, ... zijn hebben hun CVEs en ernstige kwetsbaarheden.

En de tijd dat bedrijven enkel en alleen een losstaande VPN ergens implementeren is ook al lang voorbij. Alles integreert vandaag met elkaar. Dan kan je niet zomaar snel even iets als Wireguard er tussen gaan steken, een project waar je vanuit de ontwikkelaar 0 ondersteuning kunt kopen en maar moet hopen dat als er iets is, ze het snel oplossen.

[baseoa]

Noem eens een product dat gegarandeerd veilig is zou ik zeggen.

Strawman-argument: het genoemde verdraaien tot iets dat makkelijk te weerleggen is. Ik had het niet over garanties. Je wilt iets waar al veel mensen naar gekeken hebben. Ik stap liever in een getestte auto dan in een nieuw-bedacht prototype zegmaar. Geen van beide zijn een garantie op geen ongeluk kunnen krijgen, dat snapt iedereen...

Ook andere leveranciers, of het nu Cisco, Palo Alto, ... zijn hebben hun CVEs

Doet een van hen dan de authenticatie via een algemeen vertrouwd protocol dan? Dat was namelijk precies mijn punt: onbegrip voor al deze vendors die steeds weer hele ernstige bugs hebben die je in de bekende opensource-pakketten niet met deze regelmaat ziet gebeuren terwijl ze méér gebruikt worden (en ook voor belangrijke systemen) dan zo'n enterprise inlogsysteem waar je flink voor moet betalen

[Alfa1970]

Jammer dat de overheid erin getuind is. Het SSL product van Ivanti, voorheen Pulse Secure, en daarvoor onderdeel van Juniper.

Het is al die tijd vreselijk buggy software geweest, in het begin bij Juniper kreeg je het gratis bij een pakje boter dus kon je er nog niet al te veel van vinden. Maar daarna gingen ze op zichzelf omdat Juniper geen kans zag om het goed te krijgen. En helaas is het nooit echt iets geworden.