Ett adminkonto var allt som krävdes.
Den 11 mars 2026 raderade Handala enheter i 79 länder, och allt som krävdes för det var ett komprometterat Intune-adminkonto. Ingen skadlig kod, ingen exploit, bara legitima hanteringsverktyg vända mot sina ägare. Vad som hände, varför det fungerade och vilka två arkitektoniska luckor som måste stängas.

Onsdag den 11 mars 2026. Medarbetare på Strykers kontor i 79 länder slog på sina datorer och fann dem tomma. Inloggningsskärmar ersatta med en logotyp. Företagsdatorer, tjänstemobiler, privata enheter som var registrerade i företagets BYOD-program – alla raderade samtidigt, över natten. Ingen ransomware, inga signaturer för skadlig kod, ingenting som ett endpoint-detection-verktyg hade kunnat upptäcka.
Angriparen, en pro-iransk hacktivistgrupp vid namn Handala, hade gjort Strykers egen IT-hanteringsinfrastruktur till ett vapen.
Vad som faktiskt hände
Kärnan i attacken var ingen avancerad exploit och ingen zero-day-sårbarhet, utan något långt enklare och långt vanligare: ett administratörskonto komprometterades, och det kontot hade åtkomst till Microsoft Intune.
Enligt rapporter från BleepingComputer raderades omkring 80 000 enheter mellan 05:00 och 08:00 UTC. Handala hävdade att siffran översteg 200 000, däribland servrar och mobila enheter i företagets globala verksamhet i 79 länder. En attack som utfördes uteslutande via en legitim hanteringskonsol.
Varför denna attack lyckades
Det finns ett strukturellt problem i grunden av den här incidenten, som inte är specifikt för Stryker. Det gäller de flesta företag.
De flesta organisationer behandlar administrativa uppgifter och det dagliga arbetet som aktiviteter som utan problem kan samexistera på samma enhet under samma användaridentitet. En IT-administratör svarar på e-post, surfar på nätet, klickar ibland på en länk och hanterar från samma session, på samma enhet, molninfrastruktur, godkänner åtkomständringar eller vidrör, som i det här fallet, en enhetshanteringskonsol med behörighet att radera hela enhetsflottan.
Det är angreppsytan. När det dagliga arbetskontextet och det privilegierade administrationskontextet delar en gemensam endpoint och en gemensam identitet, är varje kompromettering av den endpointen automatiskt en kompromettering av allt som den identiteten kan nå. Phishing, credential-stöld via infostealer-skadlig kod, Adversary-in-the-Middle (AiTM) stöld av sessionstoken – allt detta blir en direkt väg till de mäktigaste kontrollerna i miljön. Ingen privilegie-eskalering krävs. Angriparen använder helt enkelt det som redan finns.
I Strykers fall omfattade den åtkomsten en Intune-tenant som hanterade enheter på sex kontinenter.
CISA har sett nog
Attackens omfattning och fräckhet utlöste en ovanlig reaktion: CISA, den amerikanska Cybersecurity and Infrastructure Security Agency, publicerade riktlinjer som direkt adresserar risken med komprometterade enhetshanteringsplattformar. Myndigheten bekräftade att den kände till angreppsvektorn och uppmanade organisationer att vidta konkreta åtgärder – att säkerställa att högriskfunktioner i Intune, som radering av enheter, kräver godkännande från en andra administratör innan de körs.
Det är en sällsynt och betydelsefull signal. När en federal säkerhetsmyndighet ger ut riktade riktlinjer direkt efter en konkret incident är budskapet tydligt: det här är inget randfall. Det är ett mönster, och andra organisationer är med stor sannolikhet utsatta för samma risk.
Separation är ingen lyx. Det är själva kontrollen.
Stryker-attacken visar med all önskvärd tydlighet vilken omfattning en platt privilegiemodell kan ha. Angriparen behövde inte eskalera privilegier genom en kedja av sårbarheter. Han fick åtkomst till inloggningsuppgifter eller en sessionstoken på en nivå och konstaterade att den nivån redan räckte för att orsaka katastrofal, global, oåterkallelig skada.
Det arkitektoniska svaret på detta problem har ett namn: Microsoft Enterprise Access Model (EAM). Dess kärnprincip är skiktad administration: privilegierade operationer utförs med dedikerade konton och dedikerade enheter, strikt åtskilda från det dagliga arbetskontextet. Denna least-privilege-ansats innebär att ett komprometterat produktivitetskonto inte kan nå hanteringsnivån och att ett komprometterat hanteringskonto inte kan utföra control-plane-operationer. Detta gäller lika mycket för rena molnmiljöer som för hybrida setup, inklusive on-premises-anslutning till Active Directory via Entra ID, där ett enda överprivilegierat konto fortfarande kan koppla ihop molnet och domänen.
Idén är enkel. Administrativt arbete sker på administrativa enheter. Identiteten som används för att hantera Microsoft 365-tenanten, Intune-miljön eller Azure-infrastrukturen är aldrig samma identitet som används för att läsa e-post eller delta i Teams-samtal. Enheten som används för dessa administrativa sessioner är härdad, begränsad och isolerad från vanligt webbsurfande och det produktivitetskontext som skapar angreppsytan. Lateral rörelse blir strukturellt svårare, eftersom det inte finns någon lateral väg.
Två försvarsnivåer
För att adressera denna hotmodell på rätt sätt måste man arbeta på två nivåer samtidigt: säkra vem som kan vidröra hanteringsnivån och dess inloggningsuppgifter, och härda hur den hanteringsnivån själv konfigureras och drivs. Det är inte samma problem, och båda är viktiga.
Managed Red Tenant: skydda det administrativa kontextet
Den första nivån är fullständig isolering av den privilegierade åtkomsten. Det är vad vår Managed Red Tenant är utformad för.
Managed Red Tenant erbjuder en fullständigt isolerad, molnbaserad administrativ miljö – en dedikerad Microsoft Entra-tenant („den röda tenanten"), som uteslutande används för privilegierade operationer. Administrativa identiteter bor här. Administrativa enheter hanteras här. Ingenting från den vanliga arbetsmiljön flödar över.
För de mest kritiska rollerna – de med control-plane-åtkomst, som globala administratörer – implementerar vi „Clean Keyboard"-ansatsen: en fysisk Privileged Admin Workstation (PAW) med dedikerad hårdvara, härdade policyer och inga som helst beröringspunkter med det dagliga arbetskontextet. För administrativa roller under control plane erbjuder vi skalbara Virtual Access Workstations (VAW), byggda på en härdad Azure Virtual Desktop-infrastruktur inuti den röda tenanten. Själva åtkomstvägen skyddas av Microsoft Entra Private Access, med Zero Trust Network Access och Conditional Access-policyer innan en session kan upprättas.
Microsoft Entra Internet Access blockerar offentlig internetåtkomst från administrativa sessioner och begränsar anslutningarna strikt till privilegierade gränssnitt och auktoriserade tenant-miljöer. Återkallelse av sessioner i nära realtid är möjlig genom Universal Conditional Access Evaluation, vilket innebär att en återkallad credential inte kvarstår som en giltig session.
Managed Red Tenant övervakas dygnet runt av vårt Cloud Security Operations Center (CSOC), med särskilt utvecklade detektioner som är riktade mot administrativa behörigheter och åtkomstmönster. En angripare som på något sätt komprometterar en credential i den här miljön hade inte tre oupptäckta timmar på sig att köra wipe-kommandon över en global enhetsflotta.
Det är särskilt relevant för roller som Intune-administratörer. De vet hur man säkrar klienter, men att säkra en privilegierad admin-workstation kräver andra färdigheter: Enterprise Access Architecture, Identity Hardening, Zero Trust Controls. Dessa ligger typiskt hos säkerhetsteamet. En Managed Red Tenant tar bort den bördan helt: Intune-admins får en professionellt hanterad, konsekvent härdad workstation, utan att själva behöva bli experter på säkerhets-workstations. Det gäller varje högprivilegierad roll i organisationen.
Managed Intune: säkra själva hanteringsnivån
Den andra nivån är att säkerställa att Intune – verktyget som användes som vapen i Stryker-attacken – konfigureras, drivs och kontinuerligt underhålls enligt högsta säkerhetsstandard. Det är vad vår Managed Intune-tjänst ansvarar för.
En av de centrala insikterna från incidenter som denna är att organisationer ofta ärver Intune-miljöer som har vuxit organiskt: policyer staplade på policyer, manuella ändringar via portalen som är svåra att granska, och säkerhets-baselines som inte har hållit jämna steg med Microsofts egna, ständigt utvecklade rekommendationer. Det är precis den sortens miljö där konfigurationsdrift skapar utnyttjbara luckor.
Microsoft publicerade nyligen Best Practices för att säkra Microsoft Intune – en signal om att även Microsoft betraktar Intune-härdning som ett ämne som kräver uttrycklig uppmärksamhet i hela branschen. Vår Managed Intune-tjänst bygger på dessa principer, och vi har implementerat Microsofts rekommendationer som en del av vår baseline.
Vår Managed Intune-tjänst bygger på glueckkanja Intune Foundation: en beprövad, kontinuerligt underhållen uppsättning best practices för enhetshantering, fullständigt tillhandahållen som kod med Terraform och vår egen TerraProvider. Varje ändring är automatiserad, versionshanterad och granskningsbar. Det finns inga odokumenterade click-through-konfigurationer som en angripare skulle kunna utnyttja genom att förstå glappet mellan det avsedda och det faktiskt satta.
Ur ett säkerhetsperspektiv innebär det att Zero Trust, App Protection Policies och Endpoint Security-konfigurationer tillämpas konsekvent by design – över Windows, macOS, iOS och Android – inte som engångsutrullningar, utan som kontinuerligt upprätthållna, löpande uppdaterade baselines som följer Microsofts egna säkerhetsriktlinjer.
Avgörande är att Managed Intune speglar den driftmässiga mognad som modern endpoint-hantering kräver: kontinuerlig compliance-övervakning, strukturerad ändringsstyrning och regelbundna service-reviews – inte som valfria extrafunktioner, utan som baseline-operationer. Men att säkra Intune-konfigurationen är bara halva jobbet. Om administratören som når konsolen gör det från en oskyddad enhet, förblir hanteringsnivån ändå exponerad – och det är precis här som Managed Red Tenant fullbordar modellen.
Eftersom alla konfigurationer tillhandahålls som kod på basis av Intune Foundation, tillämpar vi en strikt fyra-ögon-princip med peer review, ytterligare automatiserad validering och kontrollerade deployment-pipelines. Det eliminerar ohanterade portaländringar inom Intune Foundation och säkerställer en konsekvent, granskningsbar och säker baseline över alla enheter.
Den administrativa åtkomsten styrs av en least-privilege-modell med GDAP och Azure Lighthouse, med tydligt definierade ansvarsområden och snävt avgränsad åtkomst till kundtenanten. Det minskar avsevärt den angreppsyta som är förknippad med privilegierade operationer.
Åtgärder på enhetsnivå, inklusive destruktiva operationer, förblir kundens ansvar, eftersom deras utförande är nära knutet till organisationsspecifika processer och interna governance-ramverk. Microsoft och CISA rekommenderar att sådana åtgärder säkras med ytterligare skyddsåtgärder, exempelvis genom Multi-Admin-godkännandekontroller i Intune.
Den obekväma frågan
Stryker-attacken är ingen anklagelse mot Microsoft Intune. Intune betedde sig exakt som det var utformat att göra. Det körde de kommandon det tog emot från en autentiserad administratör. Felet låg inte i verktyget. Det låg i avsaknaden av kontroller över vem som kunde nå det verktyget, från vilket kontext och med vilken grad av auktorisering.
Det är ett governance- och arkitekturproblem. Och det är samma problem som finns i de flesta organisationer som driver Microsoft 365 idag.
Om dina administratörer når Intune, Entra ID eller Azure från samma enheter och identiteter som de använder för det dagliga arbetet – och om din Intune-miljö har vuxit fram genom år av manuella portaländringar i stället för genom en strukturerad, automatiserad driftmodell – bär du samma strukturella risk som Stryker bar den 11 mars. Frågan är om en angripare kommer att hitta den svagheten innan du stänger den.
Managed Red Tenant adresserar privilegie- och identitetsnivån. Managed Intune adresserar konfigurations- och driftnivån. Tillsammans stänger de de två luckor som gjorde Stryker-attacken möjlig.
Om du vill förstå hur någon av tjänsterna gäller din nuvarande miljö eller var dina konkreta svagheter finns, pratar vi gärna om det.
Vi kommer inom kort också att publicera en deep-dive-artikel som undersöker hur Stryker-incidenten över huvud taget kunde bli möjlig.
Mer information
Ta kontakt
Vill du veta hur Managed Red Tenant och Managed Intune stänger de luckor som Stryker-attacken utnyttjade? Fyll i formuläret så förklarar vi hur det gäller din miljö.














