Én admin-konto var alt, hvad der skulle til.

Den 11. marts 2026 slettede Handala enheder i 79 lande, og alt, hvad der skulle til, var en kompromitteret Intune-admin-konto. Ingen malware, ingen exploit, kun legitime management-værktøjer vendt mod deres ejere. Hvad der skete, hvorfor det virkede, og hvilke to arkitektoniske huller der skal lukkes.

Én admin-konto var alt, hvad der skulle til.

Onsdag den 11. marts 2026. Medarbejdere på Stryker-kontorer i 79 lande tændte deres computere og fandt dem tomme. Login-skærme erstattet af et logo. Firmabærbare, arbejdstelefoner, private enheder tilmeldt virksomhedens BYOD-program, alle slettet samtidig, natten over. Ingen ransomware, ingen malware-signaturer, intet, som et endpoint-detection-værktøj kunne have opdaget.

Angriberen, en pro-iransk hacktivistgruppe ved navn Handala, havde gjort Strykers egen IT-management-infrastruktur til et våben.

Hvad der faktisk skete

Kernen i angrebet var hverken en raffineret exploit eller en zero-day-sårbarhed, men noget langt enklere og langt mere udbredt: En administratorkonto blev kompromitteret, og den konto havde adgang til Microsoft Intune.

Ifølge BleepingComputers rapportering blev omkring 80.000 enheder slettet mellem klokken 5:00 og 8:00 UTC. Handala hævdede, at tallet oversteg 200.000, heriblandt servere og mobile enheder i virksomhedens globale drift i 79 lande. Et angreb udført udelukkende gennem en legitim management-konsol.

Hvorfor dette angreb lykkedes

Der ligger et strukturelt problem til grund for denne hændelse, og det er ikke specifikt for Stryker. Det gælder de fleste virksomheder.

De fleste organisationer behandler administrative opgaver og det daglige arbejde som aktiviteter, der uden videre kan sameksistere på samme enhed under samme brugeridentitet. En IT-administrator besvarer mails, surfer på nettet, klikker en gang imellem på et link og administrerer fra samme session, på samme enhed, cloud-infrastruktur, godkender adgangsændringer eller rører, som i dette tilfælde, ved en enhedsadministrationskonsol med rettighed til at slette hele enhedsflåden.

Det er angrebsfladen. Når den daglige arbejdskontekst og den privilegerede administrationskontekst deler samme endpoint og samme identitet, er enhver kompromittering af det endpoint automatisk en kompromittering af alt, hvad den identitet kan nå. Phishing, credential-tyveri via infostealer-malware, adversary-in-the-middle (AiTM) session-token-tyveri, alt sammen bliver en direkte vej til de mest magtfulde kontroller i miljøet. Ingen privilege-eskalering nødvendig. Angriberen bruger simpelthen det, der allerede er der.

I Strykers tilfælde omfattede den adgang en Intune-tenant, der administrerede enheder på seks kontinenter.

CISA har set nok

Angrebets omfang og frækhed udløste en usædvanlig reaktion: CISA, det amerikanske Cybersecurity and Infrastructure Security Agency, udsendte vejledning, der direkte adresserer risikoen ved kompromitterede enhedsadministrationsplatforme. Myndigheden bekræftede, at den kendte angrebsvektoren, og opfordrede organisationer til at træffe konkrete foranstaltninger, herunder at sikre, at højrisiko-funktioner i Intune som sletning af enheder kræver en anden administrators godkendelse, før de udføres.

Det er et sjældent og betydningsfuldt signal. Når en føderal sikkerhedsmyndighed udsender målrettet vejledning umiddelbart efter en konkret hændelse, er budskabet klart: Det her er ikke et særtilfælde. Det er et mønster, og andre organisationer er med stor sandsynlighed udsat for den samme risiko.

Adskillelse er ikke luksus. Det er kontrollen.

Stryker-angrebet viser med al tydelighed, hvilket omfang en flad privilegiemodel kan få. Angriberen behøvede ikke at eskalere privilegier gennem en kæde af sårbarheder. Han fik adgang til loginoplysninger eller et session-token på ét niveau og konstaterede, at det niveau allerede var nok til at forvolde katastrofal, global og uoprettelig skade.

Det arkitektoniske svar på det problem har et navn: Microsoft Enterprise Access Model (EAM). Kerneprincippet er lagdelt administration, hvor privilegerede operationer udføres med dedikerede konti og dedikerede enheder, strengt adskilt fra den daglige arbejdskontekst. Denne least-privilege-tilgang betyder, at en kompromitteret produktivitetskonto ikke kan nå management-laget, og at en kompromitteret management-konto ikke kan udføre control-plane-operationer. Det gælder på samme måde for rene cloud-miljøer og for hybride opsætninger med on-premises-forbindelse til Active Directory via Entra ID, hvor en enkelt overprivilegeret konto fortsat kan forbinde cloud og domæne.

Idéen er enkel. Administrativt arbejde foregår på administrative enheder. Den identitet, der bruges til at administrere Microsoft 365-tenanten, Intune-miljøet eller Azure-infrastrukturen, er aldrig den samme identitet, som bruges til at læse mails eller deltage i Teams-opkald. Den enhed, der bruges til de administrative sessioner, er hærdet, begrænset og isoleret fra den almindelige internetbrowsing og den produktivitetskontekst, der skaber angrebsfladen. Lateral bevægelse bliver strukturelt sværere, fordi der ikke findes nogen lateral vej.

To forsvarslag

For at adressere denne trusselsmodel ordentligt skal man arbejde på to niveauer samtidig: sikre, hvem der kan røre ved management-laget og dets loginoplysninger, og hærde, hvordan det management-lag selv konfigureres og drives. Det er ikke det samme problem, og begge dele er vigtige.

Risiko- og produktoversigt for Stryker-angrebsscenariet: Managed Red Tenant adresserer identitets- og adgangsrisici, Managed Intune adresserer risici i endpoint management

Managed Red Tenant: at beskytte den administrative kontekst

Det første lag er fuldstændig isolering af privilegeret adgang. Det er, hvad vores Managed Red Tenant er bygget til.

Managed Red Tenant leverer et fuldt isoleret, cloudbaseret administrativt miljø, en dedikeret Microsoft Entra-tenant (»the Red Tenant«), der udelukkende bruges til privilegerede operationer. Administrative identiteter bor her. Administrative enheder administreres her. Intet fra det almindelige arbejdsmiljø flyder over.

For de mest kritiske roller, dem med control-plane-adgang som Global Administrators, implementerer vi »Clean Keyboard«-tilgangen: en fysisk Privileged Admin Workstation (PAW) med dedikeret hardware, hærdede politikker og ingen som helst berøring med den daglige arbejdskontekst. For administrative roller under control plane tilbyder vi skalerbare Virtual Access Workstations (VAW), bygget på en hærdet Azure Virtual Desktop-infrastruktur inde i Red Tenant. Selve adgangsvejen er beskyttet af Microsoft Entra Private Access med Zero Trust Network Access og Conditional Access-politikker, før en session overhovedet kan etableres.

Microsoft Entra Internet Access blokerer offentlig internetadgang fra administrative sessioner og begrænser forbindelserne strengt til privilegerede grænseflader og autoriserede tenant-miljøer. Tilbagekaldelse af sessioner i nær realtid er mulig gennem Universal Conditional Access Evaluation, hvilket betyder, at en tilbagekaldt credential ikke lever videre som en gyldig session.

Managed Red Tenant overvåges døgnet rundt af vores Cloud Security Operations Center (CSOC) med specialudviklede detektioner, der er målrettet administrative rettigheder og adgangsmønstre. En angriber, der på en eller anden måde kompromitterer en credential i dette miljø, ville ikke få tre uopdagede timer til at eksekvere wipe-kommandoer på tværs af en global enhedsflåde.

Det er særligt relevant for roller som Intune-administratorer. De ved, hvordan man sikrer klienter, men at sikre en privilegeret admin-workstation kræver andre kompetencer: enterprise access-arkitektur, identity hardening, Zero Trust-kontroller. De ligger typisk hos sikkerhedsteamet. En Managed Red Tenant fjerner den byrde fuldstændigt: Intune-admins får en professionelt administreret, konsistent hærdet workstation uden selv at skulle blive eksperter i sikkerhedsworkstations. Det gælder for enhver højt privilegeret rolle i organisationen.

Jan Geisbauer og Thomas Naunheim diskuterer Managed Red Tenant-cybersikkerhedsstrategien
Mere på vores YouTube-kanal

Managed Intune: at sikre selve management-laget

Det andet lag er at sikre, at Intune, det værktøj der blev brugt som våben i Stryker-angrebet, konfigureres, drives og løbende vedligeholdes efter højeste sikkerhedsstandard. Det er, hvad vores Managed Intune-service står for.

En af de centrale erkendelser fra hændelser som denne er, at organisationer ofte arver Intune-miljøer, der er vokset organisk: politikker stablet oven på politikker, manuelle ændringer via portalen, som er svære at revidere, og sikkerheds-baselines, der ikke har holdt trit med Microsofts egne, løbende opdaterede anbefalinger. Det er præcis den type miljø, hvor konfigurationsdrift skaber huller, der kan udnyttes.

Microsoft har for nylig udgivet best practices for at sikre Microsoft Intune, et signal om, at også Microsoft betragter hærdning af Intune som et emne, der kræver eksplicit opmærksomhed i hele branchen. Vores Managed Intune-service bygger på disse principper, og vi har implementeret Microsofts anbefalinger som en del af vores baseline.

Vores Managed Intune-service bygger på glueckkanja Intune Foundation: et gennemprøvet, løbende vedligeholdt sæt best practices for enhedsadministration, leveret fuldt ud som kode med Terraform og vores egen TerraProvider. Hver ændring er automatiseret, versionsstyret og reviderbar. Der findes ingen udokumenterede click-through-konfigurationer, som en angriber kunne udnytte ved at forstå forskellen mellem det tilsigtede og det faktisk satte.

Set fra et sikkerhedsperspektiv betyder det, at Zero Trust, App Protection Policies og Endpoint Security-konfigurationer anvendes konsistent by design, på tværs af Windows, macOS, iOS og Android, ikke som engangsudrulninger, men som løbende håndhævede, kontinuerligt opdaterede baselines, der følger Microsofts egen sikkerhedsvejledning.

Afgørende er, at Managed Intune afspejler den driftsmæssige modenhed, som moderne endpoint management kræver: kontinuerlig compliance-overvågning, struktureret ændringsgovernance og regelmæssige service reviews, ikke som valgfrie tilvalg, men som baseline-drift. Men at sikre Intune-konfigurationen er kun det halve arbejde. Hvis den administrator, der tilgår konsollen, gør det fra en ubeskyttet enhed, forbliver management-laget alligevel eksponeret, og det er præcis her, Managed Red Tenant gør modellen komplet.

Da alle konfigurationer udrulles som kode på grundlag af Intune Foundation, håndhæver vi et strikt firøjesprincip med peer review, yderligere automatiseret validering og kontrollerede deployment-pipelines. Det eliminerer uadministrerede portalændringer inden for Intune Foundation og sikrer en konsistent, reviderbar og sikker baseline på tværs af alle enheder.

Administrativ adgang styres gennem en least-privilege-model med GDAP og Azure Lighthouse, med klart definerede ansvarsområder og tæt afgrænset adgang til kundens tenant. Det reducerer angrebsfladen forbundet med privilegerede operationer betydeligt.

Handlinger på enhedsniveau, herunder destruktive operationer, forbliver kundens ansvar, fordi deres udførelse er tæt knyttet til organisationsspecifikke processer og interne governance-frameworks. Microsoft og CISA anbefaler at sikre den slags handlinger med yderligere beskyttelsesforanstaltninger, for eksempel multi-admin-godkendelseskontroller i Intune.

Det ubehagelige spørgsmål

Stryker-angrebet er ikke en anklage mod Microsoft Intune. Intune opførte sig præcis som designet. Det udførte de kommandoer, det modtog fra en autentificeret administrator. Fejlen lå ikke i værktøjet. Den lå i fraværet af kontroller for, hvem der kunne nå det værktøj, fra hvilken kontekst og med hvilken grad af autorisation.

Det er et governance- og arkitekturproblem. Og det er det samme problem, som findes i de fleste organisationer, der driver Microsoft 365 i dag.

Hvis jeres administratorer tilgår Intune, Entra ID eller Azure fra de samme enheder og identiteter, som de bruger til det daglige arbejde, og hvis jeres Intune-miljø er vokset gennem år med manuelle portalændringer i stedet for en struktureret, automatiseret driftsmodel, bærer I den samme strukturelle risiko, som Stryker bar den 11. marts. Spørgsmålet er, om en angriber finder den svaghed, før I lukker den.

Managed Red Tenant adresserer privilegie- og identitetslaget. Managed Intune adresserer konfigurations- og driftslaget. Tilsammen lukker de de to huller, der gjorde Stryker-angrebet muligt.

Hvis du vil forstå, hvordan en af de to services gælder for jeres nuværende miljø, eller hvor jeres konkrete svagheder ligger, taler vi gerne om det.

Vi udgiver også snart en deep-dive-artikel, der undersøger, hvordan Stryker-hændelsen overhovedet kunne finde sted.

Yderligere information

Kontakt os

Vil du vide, hvordan Managed Red Tenant og Managed Intune lukker de huller, som Stryker-angrebet udnyttede? Udfyld formularen, så forklarer vi, hvordan det gælder for jeres miljø.
Portræt af Jan Geisbauer, Head of Security hos glueckkanja
Værktøjet gjorde præcis det, man bad det om. Problemet var, at ingen burde have været i stand til at bede det om det, hverken fra en kompromitteret hverdagskonto, uden en anden godkendelse eller uden et isoleret administrativt miljø. Det er det hul, vi hjælper organisationer med at lukke.
Jan GeisbauerHead of Security

Lignende indlæg