En admin-konto var alt som skulle til.

Onsdag 11. mars 2026. Ansatte i Stryker-kontorer i 79 land slo på datamaskinene sine og fant dem tomme. Innloggingsskjermer erstattet av en logo. Firmalaptoper, tjenestemobiler, private enheter registrert i selskapets BYOD-program, alle slettet samtidig, over natten. Ingen ransomware, ingen malware-signaturer, ingenting som et endpoint-detection-verktøy kunne ha fanget opp.

Angriperen, en pro-iransk hacktivistgruppe ved navn Handala, hadde gjort Strykers egen IT-management-infrastruktur til et våpen.

Hva som faktisk skjedde

Kjernen i angrepet var ingen sofistikert exploit og ingen zero-day-sårbarhet, men noe langt enklere og langt vanligere: En administrator-konto ble kompromittert, og den kontoen hadde tilgang til Microsoft Intune.

Ifølge rapporter fra BleepingComputer ble omtrent 80 000 enheter slettet mellom klokken 5:00 og 8:00 UTC. Handala hevdet at tallet oversteg 200 000, inkludert servere og mobile enheter i selskapets globale drift i 79 land. Ett angrep, utført utelukkende via en legitim management-konsoll.

Hvorfor dette angrepet lyktes

Det finnes et strukturelt problem i roten av denne hendelsen, og det er ikke spesifikt for Stryker. Det gjelder de fleste selskaper.

De fleste organisasjoner behandler administrative oppgaver og daglig arbeid som aktiviteter som uten videre kan sameksistere på samme enhet under samme brukeridentitet. En IT-administrator svarer på e-post, surfer på nettet, klikker av og til på en lenke, og administrerer fra samme økt, på samme enhet, cloud-infrastruktur, godkjenner tilgangsendringer eller, som i dette tilfellet, tar på en enhetsadministrasjonskonsoll med rettighet til å slette hele enhetsflåten.

Det er angrepsflaten. Når den daglige arbeidskonteksten og den privilegerte administrasjonskonteksten deler et felles endepunkt og en felles identitet, blir enhver kompromittering av det endepunktet automatisk en kompromittering av alt den identiteten kan nå. Phishing, credential-tyveri via infostealer-malware, Adversary-in-the-Middle (AiTM) session-token-tyveri, alt dette blir en direkte vei til de mektigste kontrollene i miljøet. Ingen privilege-eskalering nødvendig. Angriperen bruker rett og slett det som allerede ligger der.

I Strykers tilfelle omfattet denne tilgangen en Intune-tenant som administrerte enheter på seks kontinenter.

CISA har sett nok

Omfanget og frekkheten i angrepet utløste en uvanlig reaksjon: CISA, det amerikanske Cybersecurity and Infrastructure Security Agency, publiserte retningslinjer som direkte adresserer risikoen ved kompromitterte enhetsadministrasjonsplattformer. Byrået bekreftet at de kjente til angrepsvektoren og oppfordret organisasjoner til å iverksette konkrete tiltak, blant annet å sørge for at høyrisikofunksjoner i Intune, som sletting av enheter, krever godkjenning fra en andre administrator før de utføres.

Det er et sjeldent og betydningsfullt signal. Når et føderalt sikkerhetsorgan gir målrettede retningslinjer umiddelbart etter en konkret hendelse, er budskapet tydelig. Dette er ikke et kanttilfelle. Det er et mønster, og andre organisasjoner er med stor sannsynlighet utsatt for den samme risikoen.

Separasjon er ingen luksus. Det er kontrollen.

Stryker-angrepet viser med all tydelighet hvilket omfang en flat privilege-modell kan ha. Angriperen trengte ikke å eskalere privilegier gjennom en kjede av sårbarheter. Vedkommende fikk tilgang til credentials eller et session-token på ett nivå, og fant ut at det nivået allerede var nok til å forårsake katastrofal, global og irreversibel skade.

Det arkitektoniske svaret på dette problemet har et navn: Microsoft Enterprise Access Model (EAM). Kjerneprinsippet er nivådelt administrasjon. Privilegerte operasjoner utføres med dedikerte kontoer og dedikerte enheter, strengt atskilt fra den daglige arbeidskonteksten. Denne Least-Privilege-tilnærmingen betyr at en kompromittert produktivitetskonto ikke kan nå management-laget, og at en kompromittert management-konto ikke kan utføre control-plane-operasjoner. Det gjelder like mye for rene cloud-miljøer som for hybride oppsett med on-premises-tilkobling til Active Directory via Entra ID, der én enkelt overprivilegert konto fortsatt kan koble skyen og domenet sammen.

Ideen er enkel. Administrativt arbeid skjer på administrative enheter. Identiteten som brukes til å administrere Microsoft 365-tenanten, Intune-miljøet eller Azure-infrastrukturen, er aldri den samme identiteten som brukes til å lese e-post eller delta i Teams-samtaler. Enheten som brukes til disse administrative øktene, er herdet, begrenset og isolert fra ordinær internettbruk og den produktivitetskonteksten som skaper angrepsflaten. Lateral bevegelse blir strukturelt vanskeligere fordi det ikke finnes en lateral vei.

To forsvarslag

For å adressere denne trusselmodellen riktig må man jobbe på to nivåer samtidig: sikre hvem som kan berøre management-laget og credentials som hører til, og herde hvordan selve management-laget konfigureres og driftes. Dette er ikke samme problem, og begge er viktige.

Managed Red Tenant: beskytt den administrative konteksten

Det første laget er fullstendig isolering av privilegert tilgang. Det er det vår Managed Red Tenant er utformet for.

Managed Red Tenant tilbyr et fullstendig isolert, skybasert administrativt miljø, en dedikert Microsoft Entra-tenant («Red Tenant»), som utelukkende brukes til privilegerte operasjoner. Administrative identiteter lever her. Administrative enheter administreres her. Ingenting fra det ordinære arbeidsmiljøet flyter over.

For de mest kritiske rollene, de med control-plane-tilgang, som Global Administrators, implementerer vi «Clean Keyboard»-tilnærmingen: en fysisk Privileged Admin Workstation (PAW) med dedikert maskinvare, herdede policyer og null berøringspunkter med den daglige arbeidskonteksten. For administrative roller under control plane tilbyr vi skalerbare Virtual Access Workstations (VAW), bygget på en herdet Azure Virtual Desktop-infrastruktur inne i Red Tenant. Selve tilgangsveien er beskyttet av Microsoft Entra Private Access, med Zero Trust Network Access og Conditional Access-policyer før en økt kan etableres.

Microsoft Entra Internet Access blokkerer offentlig internettilgang fra administrative økter og begrenser tilkoblinger strengt til privilegerte grensesnitt og autoriserte tenant-miljøer. Nær sanntids øktopphør er mulig gjennom Universal Conditional Access Evaluation, noe som betyr at en tilbakekalt credential ikke lever videre som en gyldig økt.

Managed Red Tenant overvåkes døgnet rundt av vårt Cloud Security Operations Center (CSOC), med spesialutviklede deteksjoner rettet mot administrative rettigheter og tilgangsmønstre. En angriper som på et vis kompromitterer en credential i dette miljøet, ville ikke hatt tre uoppdagede timer til å kjøre wipe-kommandoer over en global enhetsflåte.

Dette er særlig relevant for roller som Intune-administratorer. De vet hvordan man sikrer klienter, men å sikre en privilegert admin-workstation krever andre ferdigheter: Enterprise Access Architecture, identity hardening, Zero Trust-kontroller. Disse ligger typisk hos sikkerhetsteamet. En Managed Red Tenant tar denne byrden helt bort. Intune-administratorer får en profesjonelt driftet, konsekvent herdet workstation uten selv å måtte bli eksperter på sikkerhets-workstations. Det gjelder for enhver høyprivilegert rolle i organisasjonen.

Managed Intune: sikre selve management-laget

Det andre laget er å sørge for at Intune, verktøyet som ble brukt som våpen i Stryker-angrepet, konfigureres, driftes og pleies kontinuerlig etter høyeste sikkerhetsstandard. Det er det vår Managed Intune-tjeneste tar seg av.

En av de sentrale erkjennelsene fra hendelser som denne, er at organisasjoner ofte arver Intune-miljøer som har vokst organisk: policyer stablet på policyer, manuelle endringer via portalen som er vanskelige å revidere, og sikkerhetsbaseliner som ikke har fulgt med Microsofts egne, stadig oppdaterte anbefalinger. Det er nettopp denne typen miljø der konfigurasjonsdrift skaper utnyttbare hull.

Microsoft publiserte nylig Best Practices for å sikre Microsoft Intune, et signal om at også Microsoft ser på Intune-herding som et tema som krever eksplisitt oppmerksomhet på tvers av bransjen. Vår Managed Intune-tjeneste hviler på disse prinsippene, og vi har implementert Microsofts anbefalinger som del av vår baseline.

Vår Managed Intune-tjeneste bygger på glueckkanja Intune Foundation: et velprøvd, kontinuerlig vedlikeholdt sett med Best Practices for enhetsadministrasjon, fullstendig levert som kode med Terraform og vår egen TerraProvider. Hver endring er automatisert, versjonskontrollert og reviderbar. Det finnes ingen udokumenterte klikkonfigurasjoner som en angriper kan utnytte ved å forstå gapet mellom det som var intendert og det som faktisk er satt.

Fra et sikkerhetsperspektiv betyr det at Zero Trust, App Protection Policies og Endpoint Security-konfigurasjoner anvendes konsekvent by design, på tvers av Windows, macOS, iOS og Android, ikke som engangsutrullinger, men som kontinuerlig håndhevede, fortløpende oppdaterte baseliner som følger Microsofts egne sikkerhetsretningslinjer.

Avgjørende er at Managed Intune reflekterer den operasjonelle modenheten som moderne endpoint-management krever: kontinuerlig compliance-overvåking, strukturert endringsstyring og regelmessige service-reviews, ikke som valgfrie ekstrafunksjoner, men som baseline-drift. Men å sikre Intune-konfigurasjonen er bare halve jobben. Hvis administratoren som logger på konsollen gjør det fra en ubeskyttet enhet, forblir management-laget likevel eksponert, og det er nettopp her Managed Red Tenant kompletterer modellen.

Siden alle konfigurasjoner leveres som kode basert på Intune Foundation, håndhever vi et strengt firearmsprinsipp med peer review, ekstra automatisert validering og kontrollerte deployment-pipelines. Det eliminerer uadministrerte portal-endringer innenfor Intune Foundation og sikrer en konsekvent, reviderbar og sikker baseline på tvers av alle enheter.

Administrativ tilgang styres av en Least-Privilege-modell med GDAP og Azure Lighthouse, med klart definerte ansvar og tett avgrenset tilgang til kunde-tenanten. Det reduserer angrepsflaten knyttet til privilegerte operasjoner betydelig.

Handlinger på enhetsnivå, inkludert destruktive operasjoner, forblir kundens ansvar, siden utførelsen henger tett sammen med organisasjonsspesifikke prosesser og interne governance-rammeverk. Microsoft og CISA anbefaler å sikre slike handlinger med ytterligere beskyttelsestiltak, for eksempel Multi-Admin-godkjenningskontroller i Intune.

Det ubehagelige spørsmålet

Stryker-angrepet er ingen tiltale mot Microsoft Intune. Intune oppførte seg akkurat slik det er utformet. Det utførte kommandoene det mottok fra en autentisert administrator. Svikten lå ikke i verktøyet. Den lå i mangelen på kontroller over hvem som kunne nå det verktøyet, fra hvilken kontekst og med hvilken grad av autorisasjon.

Det er et governance- og arkitekturproblem. Og det er det samme problemet som finnes i de fleste organisasjoner som driver Microsoft 365 i dag.

Hvis administratorene dine får tilgang til Intune, Entra ID eller Azure fra de samme enhetene og identitetene som de bruker til daglig arbeid, og hvis Intune-miljøet ditt har vokst gjennom år med manuelle portal-endringer i stedet for gjennom en strukturert, automatisert driftsmodell, bærer du den samme strukturelle risikoen som Stryker bar den 11. mars. Spørsmålet er om en angriper finner den sårbarheten før du tetter den.

Managed Red Tenant adresserer privilege- og identitetsnivået. Managed Intune adresserer konfigurasjons- og driftsnivået. Sammen tetter de de to hullene som gjorde Stryker-angrepet mulig.

Hvis du vil forstå hvordan en av tjenestene gjelder for ditt nåværende miljø eller hvor dine konkrete svakheter ligger, tar vi gjerne en prat.

Vi publiserer også snart en deep-dive-artikkel som undersøker hvordan Stryker-hendelsen i det hele tatt kunne skje.

Mer informasjon

• CISA: Securing Cloud Business Applications
• Microsoft: Best Practices for å sikre Microsoft Intune
• TechCrunch: CISA oppfordrer selskaper til å sikre Microsoft Intune-systemer etter at hackere massesletet Stryker-enheter
• Managed Red Tenant i Azure Marketplace