Bastava un account admin.

Mercoledì 11 marzo 2026. I dipendenti negli uffici Stryker di 79 paesi hanno acceso i loro computer e li hanno trovati vuoti. Schermate di login sostituite da un logo. Laptop aziendali, telefoni di servizio, dispositivi personali registrati nel programma BYOD dell'azienda, tutti cancellati simultaneamente, nel corso di una notte. Nessun ransomware, nessuna firma malware, nulla che uno strumento di endpoint detection avrebbe potuto rilevare.

L'attaccante, un gruppo hacktivista pro-iraniano chiamato Handala, aveva trasformato in arma la stessa infrastruttura di IT management di Stryker.

Cos'è successo davvero

Il cuore dell'attacco non è stato un exploit sofisticato o una vulnerabilità zero-day, ma qualcosa di molto più semplice e molto più comune: un account amministratore è stato compromesso, e quell'account aveva accesso a Microsoft Intune.

Secondo i report di BleepingComputer, circa 80.000 dispositivi sono stati cancellati tra le 5:00 e le 8:00 UTC. Handala ha rivendicato che il numero superava i 200.000, inclusi server e dispositivi mobili nelle operazioni globali dell'azienda in 79 paesi. Un attacco eseguito esclusivamente attraverso una console di management legittima.

Perché questo attacco ha avuto successo

Alla radice di questo incidente c'è un problema strutturale che non è specifico di Stryker. Riguarda la maggior parte delle aziende.

La maggior parte delle organizzazioni tratta le attività amministrative e il lavoro quotidiano come attività che possono coesistere senza problemi sullo stesso dispositivo, sotto la stessa identità utente. Un amministratore IT risponde alle email, naviga in internet, occasionalmente clicca su un link e dalla stessa sessione, sullo stesso dispositivo, gestisce infrastruttura cloud, approva modifiche di accesso o, come in questo caso, tocca una console di gestione dispositivi con l'autorizzazione di cancellare l'intera flotta.

Questa è la superficie di attacco. Quando il contesto di lavoro quotidiano e il contesto amministrativo privilegiato condividono un endpoint comune e un'identità comune, ogni compromissione di quell'endpoint diventa automaticamente una compromissione di tutto ciò che quell'identità può raggiungere. Phishing, furto di credenziali tramite malware infostealer, furto di token di sessione via Adversary-in-the-Middle (AiTM), tutto questo diventa un percorso diretto verso i controlli più potenti dell'ambiente. Nessuna privilege escalation necessaria. L'attaccante utilizza semplicemente ciò che è già presente.

Nel caso di Stryker, quell'accesso comprendeva un tenant Intune che gestiva dispositivi in sei continenti.

CISA ne ha visto abbastanza

La portata e l'audacia dell'attacco hanno provocato una reazione inusuale: CISA, la Cybersecurity and Infrastructure Security Agency statunitense, ha pubblicato linee guida che affrontano direttamente il rischio di piattaforme di gestione dispositivi compromesse. L'agenzia ha confermato di conoscere il vettore di attacco e ha invitato le organizzazioni ad adottare misure concrete, come assicurarsi che funzioni Intune ad alto rischio, come la cancellazione dei dispositivi, richiedano l'approvazione di un secondo amministratore prima di essere eseguite.

È un segnale raro e significativo. Quando un'agenzia federale per la sicurezza emette linee guida mirate immediatamente dopo un incidente concreto, il messaggio è chiaro: non è un caso isolato. È un pattern, e altre organizzazioni sono con alta probabilità esposte allo stesso rischio.

La separazione non è un lusso. È il controllo.

L'attacco Stryker mostra con chiarezza quale portata possa avere un modello di privilege piatto. L'attaccante non ha dovuto scalare privilegi attraverso una catena di vulnerabilità. Ha ottenuto accesso a credenziali o a un token di sessione a un solo livello e ha scoperto che quel livello era già sufficiente per causare danni catastrofici, globali e irreversibili.

La risposta architetturale a questo problema ha un nome: il Microsoft Enterprise Access Model (EAM). Il suo principio fondamentale è l'amministrazione a livelli: le operazioni privilegiate vengono eseguite con account dedicati e dispositivi dedicati, rigorosamente separati dal contesto di lavoro quotidiano. Questo approccio least-privilege significa che un account di produttività compromesso non può raggiungere il livello di management, e un account di management compromesso non può eseguire operazioni sul control plane. Vale allo stesso modo per ambienti puramente cloud e per setup ibridi, compresa la connessione on-premises ad Active Directory tramite Entra ID, dove un singolo account sovra-privilegiato può ancora collegare cloud e dominio.

L'idea è semplice. Il lavoro amministrativo avviene su dispositivi amministrativi. L'identità utilizzata per gestire il tenant Microsoft 365, l'ambiente Intune o l'infrastruttura Azure non è mai la stessa identità usata per leggere le email o partecipare a chiamate Teams. Il dispositivo utilizzato per queste sessioni amministrative è hardened, ristretto e isolato dal normale browsing internet e dal contesto di produttività che genera la superficie di attacco. Il movimento laterale diventa strutturalmente più difficile, perché non esiste un percorso laterale.

Due livelli di difesa

Per affrontare correttamente questo modello di minaccia bisogna lavorare simultaneamente su due livelli: mettere in sicurezza chi può toccare il livello di management e le sue credenziali, e hardening del modo in cui questo livello di management viene configurato e gestito. Non sono lo stesso problema, ed entrambi contano.

Managed Red Tenant: proteggere il contesto amministrativo

Il primo livello è l'isolamento completo dell'accesso privilegiato. È per questo che è stato progettato il nostro Managed Red Tenant.

Il Managed Red Tenant offre un ambiente amministrativo cloud completamente isolato, un tenant Microsoft Entra dedicato («il Red Tenant») utilizzato esclusivamente per operazioni privilegiate. Le identità amministrative vivono qui. I dispositivi amministrativi vengono gestiti qui. Nulla dell'ambiente di lavoro regolare passa dall'altra parte.

Per i ruoli più critici, quelli con accesso al control plane come i Global Administrator, implementiamo l'approccio «Clean Keyboard»: una Privileged Admin Workstation (PAW) fisica con hardware dedicato, policy hardened e nessun punto di contatto con il contesto di lavoro quotidiano. Per i ruoli amministrativi al di sotto del control plane offriamo Virtual Access Workstation (VAW) scalabili, costruite su un'infrastruttura Azure Virtual Desktop hardened all'interno del Red Tenant. Il percorso di accesso stesso è protetto da Microsoft Entra Private Access, con Zero Trust Network Access e policy Conditional Access, prima che sia possibile stabilire una sessione.

Microsoft Entra Internet Access blocca l'accesso pubblico a internet dalle sessioni amministrative e limita rigorosamente le connessioni alle interfacce privilegiate e agli ambienti tenant autorizzati. La revoca delle sessioni in tempo quasi reale è possibile grazie a Universal Conditional Access Evaluation, il che significa che una credenziale revocata non persiste come sessione valida.

Il Managed Red Tenant è monitorato 24 ore su 24 dal nostro Cloud Security Operations Center (CSOC), con detection sviluppate appositamente e mirate a autorizzazioni amministrative e pattern di accesso. Un attaccante che in qualche modo compromettesse una credenziale in questo ambiente non avrebbe tre ore non rilevate per eseguire comandi wipe su una flotta globale di dispositivi.

Questo è particolarmente rilevante per ruoli come gli amministratori Intune. Sanno come mettere in sicurezza i client, ma la messa in sicurezza di una privileged admin workstation richiede competenze diverse: Enterprise Access Architecture, identity hardening, Zero Trust controls. Queste ricadono tipicamente sul team di security. Un Managed Red Tenant toglie completamente questo peso: gli admin Intune ricevono una workstation gestita professionalmente e coerentemente hardened, senza dover diventare esperti di security workstation. Vale per ogni ruolo altamente privilegiato dell'organizzazione.

Managed Intune: mettere in sicurezza il livello di management stesso

Il secondo livello consiste nell'assicurarsi che Intune, lo strumento trasformato in arma nell'attacco Stryker, venga configurato, gestito e mantenuto secondo il più alto standard di sicurezza. È di questo che si occupa il nostro servizio Managed Intune.

Una delle intuizioni chiave da incidenti come questo è che le organizzazioni ereditano spesso ambienti Intune cresciuti organicamente: policy su policy, modifiche manuali via portale difficili da verificare, security baseline che non hanno tenuto il passo con le raccomandazioni in evoluzione di Microsoft. È esattamente il tipo di ambiente in cui la configuration drift crea lacune sfruttabili.

Microsoft ha recentemente pubblicato le Best Practices per la messa in sicurezza di Microsoft Intune, un segnale che anche Microsoft considera l'hardening di Intune un tema che richiede attenzione esplicita a livello di settore. Il nostro servizio Managed Intune si basa su questi principi, e abbiamo implementato le raccomandazioni di Microsoft come parte della nostra baseline.

Il nostro servizio Managed Intune si basa sulla glueckkanja Intune foundation: un insieme collaudato e continuamente aggiornato di best practice per il device management, deployato integralmente come codice con Terraform e con il nostro TerraProvider. Ogni modifica è automatizzata, versionata e verificabile. Non esistono configurazioni click-through non documentate che un attaccante possa sfruttare cogliendo la differenza tra ciò che era previsto e ciò che è stato effettivamente impostato.

Dal punto di vista della security, questo significa che Zero Trust, App Protection Policies e configurazioni Endpoint Security vengono applicate in modo coerente by design, su Windows, macOS, iOS e Android, non come deployment una tantum, ma come baseline applicate in continuo e costantemente aggiornate, che seguono le linee guida di sicurezza di Microsoft.

Fondamentalmente, Managed Intune riflette la maturità operativa che l'endpoint management moderno richiede: monitoraggio continuo della compliance, change governance strutturata e service review regolari, non come extra opzionali, ma come operazioni baseline. Ma mettere in sicurezza la configurazione di Intune è solo metà del lavoro. Se l'amministratore che accede alla console lo fa da un dispositivo non protetto, il livello di management resta comunque esposto, ed è esattamente qui che il Managed Red Tenant completa il modello.

Dato che tutte le configurazioni vengono deployate come codice sulla base della Intune foundation, applichiamo un rigoroso four-eyes principle con peer review, ulteriore validazione automatizzata e pipeline di deployment controllate. Questo elimina le modifiche non gestite via portale all'interno della Intune foundation e garantisce una baseline coerente, verificabile e sicura su tutti i dispositivi.

L'accesso amministrativo è governato da un modello least-privilege con GDAP e Azure Lighthouse, con responsabilità chiaramente definite e accesso strettamente limitato al tenant del cliente. Questo riduce sensibilmente la superficie di attacco associata alle operazioni privilegiate.

Le azioni a livello di dispositivo, incluse le operazioni distruttive, rimangono di responsabilità del cliente, perché la loro esecuzione è strettamente legata a processi organizzativi specifici e a framework di governance interni. Microsoft e CISA raccomandano di proteggere azioni di questo tipo con misure di salvaguardia aggiuntive, ad esempio tramite controlli di approvazione multi-admin in Intune.

La domanda scomoda

L'attacco Stryker non è un atto d'accusa contro Microsoft Intune. Intune si è comportato esattamente come era stato progettato. Ha eseguito i comandi ricevuti da un amministratore autenticato. Il fallimento non era nel tool. Era nell'assenza di controlli su chi poteva raggiungere quel tool, da quale contesto e con quale grado di autorizzazione.

È un problema di governance e di architettura. Ed è lo stesso problema che esiste nella maggior parte delle organizzazioni che oggi utilizzano Microsoft 365.

Se i tuoi amministratori accedono a Intune, Entra ID o Azure dagli stessi dispositivi e con le stesse identità che usano per il lavoro quotidiano, e se il tuo ambiente Intune è cresciuto in anni di modifiche manuali via portale invece che attraverso un modello operativo strutturato e automatizzato, porti con te lo stesso rischio strutturale che Stryker portava l'11 marzo. La domanda è se un attaccante troverà questa vulnerabilità prima che tu la chiuda.

Managed Red Tenant affronta il livello di privilege e di identità. Managed Intune affronta il livello di configurazione e operations. Insieme chiudono le due lacune che hanno reso possibile l'attacco Stryker.

Se vuoi capire come uno dei servizi si applica al tuo ambiente attuale o dove si trovano le tue vulnerabilità concrete, ne parliamo volentieri.

Pubblicheremo a breve anche un articolo di approfondimento che analizza come l'incidente Stryker sia stato reso possibile.

Ulteriori informazioni

• CISA: Securing Cloud Business Applications
• Microsoft: Best Practices per la messa in sicurezza di Microsoft Intune
• TechCrunch: CISA invita le aziende a mettere in sicurezza i sistemi Microsoft Intune dopo che gli hacker hanno cancellato in massa i dispositivi Stryker
• Managed Red Tenant nell'Azure Marketplace