Am 11. März 2026 löschte die iranisch-verlinkte Hacktivistengruppe Handala über Microsofts Intune-Wipe-Funktion nahezu 80.000 Geräte des Medizintechnik-Konzerns Stryker. Stryker meldete keine Hinweise auf Ransomware/Malware in der eigenen Umgebung. Der Angriff erfolgte durch den Missbrauch von cloud-basierten Diensten zur Administration der Endgeräte. Für die destruktive Phase war keine zusätzliche Malware auf den Endpoints nötig. Der Angriff missbrauchte legitime Intune‑Wipe‑Funktionen. Der initiale Angriffsweg, mit dem sich die Täter Zugang zur Cloud verschafften (Credential Theft), bleibt jedoch unklar.
Der Fall illustriert ein strukturelles Risiko, das viele Organisationen unterschätzen: Wenn eine einzelne Steuerungsebene Code ausrollen, Konfigurationen ändern oder Geräte auf Unternehmensebene löschen kann, ist sie kein „einfaches Endpoint-Management“ mehr, sondern verhält sich wie kritische Infrastruktur. Ein Angreifender mit Intune-Administrator-Zugang braucht keine Malware – er kann Konfigurationsänderungen verteilen, die VPN oder WLAN lahmlegen, Skripte laufen lassen, die Sicherheitsfunktionen deaktivieren, den Compliance-Status manipulieren – sodass Conditional-Access-Nutzer aussperrt werden – und gleichzeitig Endpoints aus der Ferne löschen, um die Recovery zu verlangsamen.
CISA reagierte am 18. März mit einem Alert und forderte US-Organisationen auf, ihre Intune-Umgebungen gegen ähnliche Angriffe zu härten. Die Kernempfehlungen: Einen Least-Privilege-Ansatz über Intunes RBAC realisieren, bei dem nur die tatsächlich benötigten Berechtigungen vergeben werden. Dazu kommen Multi-Faktor-Authentisierung (MFA) und privilegierte Zugriffshygiene über Conditional Access, Risk Signals und Microsoft Entra ID sowie Multi-Admin-Approval für sensible Aktionen wie Device Wipes, Anwendungsänderungen und RBAC-Modifikationen.
Das reicht allerdings nicht. Diese Empfehlungen härten zwar den administrativen Zugang, adressieren aber nicht die tieferliegende Architektur-Realität: Intune fungiert inzwischen als Teil der Identity Control Plane und muss wie Identity-Infrastruktur geplant, betrieben und überwacht werden. Konkret bedeutet das eine Tier-0-Behandlung: Für administrative Zugänge müssen phishing-resistente MFA-Verfahren wie FIDO2 oder Hardware-Token verbindlich sein; zugleich sollte der Zugriff auf die Intune-Administrationsoberfläche auf gemanagte und konforme Geräte beschränkt werden. Privilegierte Rollen dürfen nicht dauerhaft zugewiesen sein, sondern sollten über Privileged Identity Management (PIM) nur zeitlich begrenzt und nachvollziehbar aktiviert werden. Ebenso wichtig ist ein aktives Monitoring mit Alarmierung auf sicherheitskritische Ereignisse – insbesondere auf Anmeldungen privilegierter Konten sowie auf die Anlage, Änderung oder Rechteausweitung administrativer Identitäten. Schließlich müssen Audit- und Sign-in-Logs über die standardmäßigen Aufbewahrungsfristen hinaus gesichert werden, damit auch verzögert erkannte Kompromittierungen forensisch belastbar rekonstruierbar bleiben.
Das Fazit ist unbequem: Wenn eine Plattform Policies durchsetzen, Zugriff entziehen und den Betrieb auf Unternehmensebene mit Admin-Aktionen stören kann, verdient sie dieselbe architektonische Disziplin wie Identity-Systeme. Der Stryker-Breach ist der Proof of Concept dafür, dass MDM-Plattformen Tier-0-Assets sind – ob Organisationen sie so behandeln oder nicht.
https://therecord.media/stryker-cyberattack-iran-hackers
https://petri.com/why-microsoft-intune-belongs-in-the-tier-0-identity-control-plane
