Eén adminaccount was alles wat er nodig was.
Op 11 maart 2026 wiste Handala apparaten in 79 landen, en alles wat daarvoor nodig was, was één gecompromitteerd Intune-adminaccount. Geen malware, geen exploit, alleen legitieme managementtools die tegen hun eigenaars werden gericht. Wat er is gebeurd, waarom het werkte en welke twee architectonische gaten gedicht moeten worden.

Woensdag 11 maart 2026. Medewerkers in Stryker-kantoren in 79 landen zetten hun computers aan en vonden ze leeg. Inlogschermen vervangen door een logo. Bedrijfslaptops, zakelijke telefoons, privéapparaten die in het BYOD-programma van het bedrijf waren geregistreerd, allemaal gelijktijdig gewist, in één nacht. Geen ransomware, geen malwaresignaturen, niets wat een endpoint-detectietool had kunnen opmerken.
De aanvaller, een pro-Iraanse hacktivistengroep genaamd Handala, had Strykers eigen IT-managementinfrastructuur tot wapen gemaakt.
Wat er werkelijk is gebeurd
De kern van de aanval was geen geraffineerde exploit en geen zeroday-kwetsbaarheid, maar iets veel eenvoudigers en veel gangbaarders: een administratoraccount werd gecompromitteerd, en dat account had toegang tot Microsoft Intune.
Volgens berichten van BleepingComputer werden ongeveer 80.000 apparaten tussen 5:00 en 8:00 uur UTC gewist. Handala beweerde dat het aantal de 200.000 oversteeg, inclusief servers en mobiele apparaten in de wereldwijde operatie van het bedrijf in 79 landen. Een aanval die uitsluitend via een legitieme managementconsole werd uitgevoerd.
Waarom deze aanval slaagde
Er zit een structureel probleem aan de wortel van dit incident dat niet specifiek is voor Stryker. Het geldt voor de meeste bedrijven.
De meeste organisaties behandelen administratieve taken en het dagelijkse werk als activiteiten die zonder problemen op hetzelfde apparaat onder dezelfde gebruikersidentiteit kunnen samenleven. Een IT-administrator beantwoordt e-mail, surft op internet, klikt af en toe op een link en beheert vanuit dezelfde sessie, op hetzelfde apparaat, cloudinfrastructuur, keurt toegangswijzigingen goed of raakt, zoals in dit geval, een apparaatbeheerconsole aan met de rechten om de volledige apparaatvloot te wissen.
Dat is het aanvalsoppervlak. Wanneer de alledaagse werkcontext en de privileged administratiecontext een gemeenschappelijk endpoint en een gemeenschappelijke identiteit delen, is elke compromittering van dat endpoint automatisch een compromittering van alles wat die identiteit kan bereiken. Phishing, credentialdiefstal via infostealer-malware, Adversary-in-the-Middle (AiTM) sessietokendiefstal, dat alles wordt een direct pad naar de krachtigste controls in de omgeving. Privilege-escalatie is niet nodig. De aanvaller gebruikt simpelweg wat er al is.
In het geval van Stryker omvatte die toegang een Intune-tenant die apparaten op zes continenten beheerde.
CISA heeft genoeg gezien
De omvang en de brutaliteit van de aanval leidden tot een ongebruikelijke reactie: CISA, de Amerikaanse Cybersecurity and Infrastructure Security Agency, publiceerde richtlijnen die direct het risico van gecompromitteerde apparaatbeheerplatformen adresseren. De dienst bevestigde dat ze de aanvalsvector kende en riep organisaties op concrete maatregelen te nemen, namelijk ervoor te zorgen dat risicovolle Intune-functies zoals het wissen van apparaten de goedkeuring van een tweede administrator vereisen voordat ze worden uitgevoerd.
Dat is een zeldzaam en betekenisvol signaal. Wanneer een federale veiligheidsdienst direct na een concreet incident gerichte richtlijnen uitgeeft, is de boodschap duidelijk: dit is geen randgeval. Dit is een patroon, en andere organisaties lopen met grote waarschijnlijkheid hetzelfde risico.
Scheiding is geen luxe. Het is de controle.
De Stryker-aanval laat scherp zien welke omvang een plat privilegemodel kan hebben. De aanvaller hoefde geen privileges te escaleren via een keten van kwetsbaarheden. Hij kreeg toegang tot inloggegevens of een sessietoken op één niveau en stelde vast dat dat niveau al voldoende was om catastrofale, wereldwijde, onomkeerbare schade aan te richten.
Het architectonische antwoord op dit probleem heeft een naam: het Microsoft Enterprise Access Model (EAM). Het kernprincipe is getrapte administratie: privileged operaties worden uitgevoerd met dedicated accounts en dedicated apparaten, strikt gescheiden van de alledaagse werkcontext. Deze least-privilege-aanpak betekent dat een gecompromitteerd productiviteitsaccount de managementlaag niet kan bereiken en dat een gecompromitteerd managementaccount geen control plane-operaties kan uitvoeren. Dat geldt evenzeer voor pure cloudomgevingen en voor hybride setups inclusief on-premises koppeling met Active Directory via Entra ID, waar een enkel overprivileged account nog altijd de cloud en het domein kan verbinden.
Het idee is eenvoudig. Administratief werk gebeurt op administratieve apparaten. De identiteit die wordt gebruikt om de Microsoft 365-tenant, de Intune-omgeving of de Azure-infrastructuur te beheren, is nooit dezelfde identiteit die wordt gebruikt om e-mail te lezen of aan Teams-calls deel te nemen. Het apparaat dat voor die administratieve sessies wordt gebruikt, is gehard, beperkt en geïsoleerd van het reguliere internetgebruik en van de productiviteitscontext die het aanvalsoppervlak creëert. Laterale beweging wordt structureel moeilijker, omdat er geen lateraal pad is.
Twee verdedigingslagen
Om dit dreigingsmodel goed te adresseren, moet je op twee niveaus tegelijk werken: beveiligen wie de managementlaag en de bijbehorende inloggegevens kan aanraken, en harden hoe die managementlaag zelf wordt geconfigureerd en beheerd. Dat zijn niet hetzelfde probleem, en beide zijn belangrijk.
Managed Red Tenant: de administratieve context beschermen
De eerste laag is de volledige isolatie van privileged toegang. Daarvoor is onze Managed Red Tenant ontworpen.
De Managed Red Tenant biedt een volledig geïsoleerde, cloudgebaseerde administratieve omgeving, een dedicated Microsoft Entra-tenant (“de Red Tenant”) die uitsluitend voor privileged operaties wordt gebruikt. Administratieve identiteiten leven hier. Administratieve apparaten worden hier beheerd. Niets uit de reguliere werkomgeving vloeit hierheen over.
Voor de meest kritische rollen, die met control plane-toegang zoals Global Administrators, implementeren we de “Clean Keyboard”-aanpak: een fysieke Privileged Admin Workstation (PAW) met dedicated hardware, geharde policies en geen enkel raakpunt met de alledaagse werkcontext. Voor administratieve rollen onder de control plane bieden we schaalbare Virtual Access Workstations (VAW) aan, gebouwd op een geharde Azure Virtual Desktop-infrastructuur binnen de Red Tenant. Het toegangspad zelf is beschermd door Microsoft Entra Private Access, met Zero Trust Network Access en Conditional Access-policies voordat een sessie tot stand kan komen.
Microsoft Entra Internet Access blokkeert publieke internettoegang vanuit administratieve sessies en beperkt de verbindingen strikt tot privileged interfaces en geautoriseerde tenantomgevingen. Sessies kunnen vrijwel in realtime worden ingetrokken via Universal Conditional Access Evaluation, wat betekent dat een ingetrokken credential niet als geldige sessie blijft bestaan.
De Managed Red Tenant wordt rond de klok gemonitord door ons Cloud Security Operations Center (CSOC), met speciaal ontwikkelde detecties die gericht zijn op administratieve rechten en toegangspatronen. Een aanvaller die op de een of andere manier een credential in deze omgeving compromitteert, zou geen drie onopgemerkte uren hebben om wipe-commando's over een wereldwijde apparaatvloot uit te voeren.
Dat is bijzonder relevant voor rollen zoals Intune-administrators. Zij weten hoe je clients beveiligt, maar het beveiligen van een privileged admin workstation vraagt andere vaardigheden: Enterprise Access Architecture, identity hardening, Zero Trust controls. Die liggen doorgaans bij het securityteam. Een Managed Red Tenant neemt die last volledig weg: Intune-admins krijgen een professioneel beheerde, consistent geharde workstation, zonder zelf expert in security workstations te hoeven worden. Dat geldt voor elke hooggeprivilegieerde rol in de organisatie.
Managed Intune: de managementlaag zelf beveiligen
De tweede laag is ervoor zorgen dat Intune, de tool die bij de Stryker-aanval als wapen werd ingezet, volgens de hoogste securitystandaard wordt geconfigureerd, beheerd en continu onderhouden. Daarvoor is onze Managed Intune-service verantwoordelijk.
Een van de centrale inzichten uit incidenten als dit is dat organisaties vaak Intune-omgevingen erven die organisch zijn gegroeid: policies op policies gestapeld, manuele wijzigingen via het portal die moeilijk te controleren zijn, en security baselines die geen gelijke tred hebben gehouden met Microsofts eigen, zich ontwikkelende aanbevelingen. Precies dat soort omgeving is waar configuratiedrift misbruikbare gaten creëert.
Microsoft heeft recent best practices voor het beveiligen van Microsoft Intune gepubliceerd, een signaal dat ook Microsoft Intune-hardening beschouwt als een onderwerp dat branchebreed expliciete aandacht vraagt. Onze Managed Intune-service is op deze principes gebaseerd, en we hebben Microsofts aanbevelingen als onderdeel van onze baseline geïmplementeerd.
Onze Managed Intune-service is gebaseerd op de glueckkanja Intune Foundation: een bewezen, continu onderhouden set best practices voor apparaatbeheer, volledig als code uitgerold met Terraform en onze eigen TerraProvider. Elke wijziging is geautomatiseerd, versiebeheerd en controleerbaar. Er zijn geen ongedocumenteerde click-through-configuraties die een aanvaller zou kunnen misbruiken door het gat te begrijpen tussen wat bedoeld was en wat daadwerkelijk is ingesteld.
Vanuit securityperspectief betekent dat dat Zero Trust, App Protection Policies en Endpoint Security-configuraties by design consistent worden toegepast, over Windows, macOS, iOS en Android, niet als eenmalige uitrol, maar als continu gehandhaafde, doorlopend bijgewerkte baselines die Microsofts eigen securityrichtlijnen volgen.
Beslissend is dat Managed Intune de operationele volwassenheid weerspiegelt die modern endpoint management vereist: continue compliance-monitoring, gestructureerde change governance en regelmatige service reviews, niet als optionele extra's, maar als baseline-operaties. Maar de Intune-configuratie beveiligen is pas de helft van het werk. Wanneer de administrator die de console benadert dat doet vanaf een onbeschermd apparaat, blijft de managementlaag alsnog blootgesteld, en precies hier maakt de Managed Red Tenant het model compleet.
Omdat alle configuratie als code op basis van de Intune Foundation wordt uitgerold, handhaven we een strikt vierogenprincipe met peer review, aanvullende geautomatiseerde validatie en gecontroleerde deploymentpipelines. Dat elimineert onbeheerde portalwijzigingen binnen de Intune Foundation en zorgt voor een consistente, controleerbare en veilige baseline over alle apparaten heen.
Administratieve toegang wordt gestuurd via een least-privilege-model met GDAP en Azure Lighthouse, met duidelijk gedefinieerde verantwoordelijkheden en strak begrensde toegang tot de klanttenant. Dat verkleint het aanvalsoppervlak dat met privileged operaties samenhangt aanzienlijk.
Acties op apparaatniveau, inclusief destructieve operaties, blijven de verantwoordelijkheid van de klant, omdat de uitvoering ervan nauw samenhangt met organisatiespecifieke processen en interne governanceframeworks. Microsoft en CISA raden aan zulke acties met aanvullende maatregelen te beveiligen, bijvoorbeeld met multi-admin approval controls in Intune.
De ongemakkelijke vraag
De Stryker-aanval is geen aanklacht tegen Microsoft Intune. Intune gedroeg zich precies zoals het is ontworpen. Het voerde de commando's uit die het van een geauthenticeerde administrator kreeg. Het falen zat niet in de tool. Het zat in het ontbreken van controls over wie die tool kon bereiken, vanuit welke context en met welke mate van autorisatie.
Dat is een governance- en architectuurprobleem. En het is hetzelfde probleem dat in de meeste organisaties bestaat die vandaag Microsoft 365 gebruiken.
Als jullie administrators Intune, Entra ID of Azure benaderen vanaf dezelfde apparaten en identiteiten die ze voor het dagelijkse werk gebruiken, en als jullie Intune-omgeving door jaren van manuele portalwijzigingen is gegroeid in plaats van via een gestructureerd, geautomatiseerd operatiemodel, dan draag je hetzelfde structurele risico dat Stryker op 11 maart droeg. De vraag is of een aanvaller die zwakke plek vindt voordat jullie hem dichten.
Managed Red Tenant adresseert de privilege- en identiteitslaag. Managed Intune adresseert de configuratie- en operatielaag. Samen dichten ze de twee gaten die de Stryker-aanval mogelijk hebben gemaakt.
Wil je begrijpen hoe een van deze services op jullie huidige omgeving van toepassing is of waar jullie concrete zwakke plekken liggen, dan praten we daar graag over.
We publiceren binnenkort ook een deep-dive-artikel dat onderzoekt hoe het Stryker-incident in de eerste plaats mogelijk kon zijn.
Meer informatie
Neem contact op
Wil je weten hoe Managed Red Tenant en Managed Intune de gaten dichten die de Stryker-aanval heeft misbruikt? Vul het formulier in, dan leggen we uit hoe het op jullie omgeving van toepassing is.














