Ein Admin-Konto war alles, was es brauchte.

Mittwoch, 11. März 2026. Mitarbeiter in Stryker-Büros in 79 Ländern schalteten ihre Computer ein und fanden sie leer. Login-Bildschirme ersetzt durch ein Logo. Firmen-Laptops, Diensthandys, private Geräte, die im BYOD-Programm des Unternehmens registriert waren – alle gleichzeitig gelöscht, über Nacht. Keine Ransomware, keine Malware-Signaturen, nichts, das ein Endpoint-Detection-Tool hätte erkennen können.

Der Angreifer, eine pro-iranische Hacktivistengruppe namens Handala, hatte Strykers eigene IT-Management-Infrastruktur zur Waffe gemacht.

Was wirklich passiert ist

Der Kern des Angriffs war kein ausgefeilter Exploit und keine Zero-Day-Schwachstelle, sondern etwas weitaus Einfacheres und weitaus Häufigeres: Ein Administrator-Konto wurde kompromittiert, und dieses Konto hatte Zugang zu Microsoft Intune.

Laut Berichten von BleepingComputer wurden etwa 80.000 Geräte zwischen 5:00 und 8:00 Uhr UTC gelöscht. Handala behauptete, die Zahl habe 200.000 überschritten, darunter Server und mobile Geräte im globalen Betrieb des Unternehmens in 79 Ländern. Ein Angriff, ausgeführt ausschließlich über eine legitime Management-Konsole.

Warum dieser Angriff erfolgreich war

Es gibt ein strukturelles Problem an der Wurzel dieses Vorfalls, das nicht spezifisch für Stryker ist. Es betrifft die meisten Unternehmen.

Die meisten Organisationen behandeln administrative Aufgaben und die tägliche Arbeit als Aktivitäten, die auf demselben Gerät unter derselben Benutzeridentität problemlos koexistieren können. Ein IT-Administrator beantwortet E-Mails, surft im Internet, klickt gelegentlich auf einen Link und verwaltet von derselben Sitzung, auf demselben Gerät aus Cloud-Infrastruktur, genehmigt Zugriffsänderungen oder berührt, wie in diesem Fall, eine Geräteverwaltungskonsole mit der Berechtigung, die gesamte Geräteflotte zu löschen.

Das ist die Angriffsfläche. Wenn der alltägliche Arbeitskontext und der privilegierte Administrationskontext einen gemeinsamen Endpunkt und eine gemeinsame Identität teilen, ist jede Kompromittierung dieses Endpunkts automatisch eine Kompromittierung von allem, was diese Identität erreichen kann. Phishing, Credential-Diebstahl über Infostealer-Malware, Adversary-in-the-Middle (AiTM) Session-Token-Diebstahl – all das wird zu einem direkten Pfad zu den mächtigsten Kontrollen in der Umgebung. Keine Privilege-Eskalation erforderlich. Der Angreifer nutzt einfach das, was bereits vorhanden ist.

Im Fall von Stryker umfasste dieser Zugang einen Intune-Tenant, der Geräte auf sechs Kontinenten verwaltete.

CISA hat genug gesehen

Das Ausmaß und die Dreistigkeit des Angriffs lösten eine ungewöhnliche Reaktion aus: CISA, die US-amerikanische Cybersecurity and Infrastructure Security Agency, veröffentlichte Leitlinien, die direkt das Risiko kompromittierter Geräteverwaltungsplattformen adressieren. Die Behörde bestätigte, dass sie den Angriffsvektor kannte, und forderte Organisationen auf, konkrete Maßnahmen zu ergreifen – sicherzustellen, dass hochriskante Intune-Funktionen wie das Löschen von Geräten die Genehmigung eines zweiten Administrators erfordern, bevor sie ausgeführt werden.

Das ist ein seltenes und bedeutsames Signal. Wenn eine Bundesbehörde für Sicherheit unmittelbar nach einem konkreten Vorfall gezielte Leitlinien herausgibt, ist die Botschaft klar: Das ist kein Randfall. Das ist ein Muster, und andere Organisationen sind mit hoher Wahrscheinlichkeit demselben Risiko ausgesetzt.

Trennung ist kein Luxus. Sie ist die Kontrolle.

Der Stryker-Angriff zeigt in aller Deutlichkeit, welches Ausmaß ein flaches Privilege-Modell haben kann. Der Angreifer musste keine Privilegien durch eine Kette von Schwachstellen eskalieren. Er erlangte Zugang zu Anmeldedaten oder einem Session-Token auf einer Ebene und stellte fest, dass diese Ebene bereits ausreichte, um katastrophalen, globalen, irreversiblen Schaden zu verursachen.

Die architektonische Antwort auf dieses Problem hat einen Namen: das Microsoft Enterprise Access Model (EAM). Sein Kernprinzip ist die gestaffelte Administration: Privilegierte Operationen werden mit dedizierten Konten und dedizierten Geräten durchgeführt, strikt vom alltäglichen Arbeitskontext getrennt. Dieser Least-Privilege-Ansatz bedeutet, dass ein kompromittiertes Produktivitätskonto die Management-Ebene nicht erreichen kann und ein kompromittiertes Management-Konto keine Control-Plane-Operationen durchführen kann. Das gilt gleichermaßen für reine Cloud-Umgebungen und hybride Setups einschließlich On-Premises-Anbindung an Active Directory über Entra ID, wo ein einziges überprivilegiertes Konto nach wie vor die Cloud und die Domäne verbinden kann.

Die Idee ist einfach. Administrative Arbeit findet auf administrativen Geräten statt. Die Identität, die zur Verwaltung des Microsoft 365-Tenants, der Intune-Umgebung oder der Azure-Infrastruktur verwendet wird, ist niemals dieselbe Identität, die zum Lesen von E-Mails oder zur Teilnahme an Teams-Anrufen genutzt wird. Das Gerät, das für diese administrativen Sitzungen verwendet wird, ist gehärtet, eingeschränkt und vom regulären Internet-Browsing und dem Produktivitätskontext isoliert, der die Angriffsfläche erzeugt. Laterale Bewegung wird strukturell schwieriger, weil es keinen lateralen Pfad gibt.

Zwei Verteidigungsebenen

Um dieses Bedrohungsmodell richtig zu adressieren, muss man gleichzeitig auf zwei Ebenen arbeiten: sichern, wer die Management-Ebene und deren Anmeldedaten berühren kann, und härten, wie diese Management-Ebene selbst konfiguriert und betrieben wird. Das sind nicht dasselbe Problem, und beide sind wichtig.

Managed Red Tenant: den administrativen Kontext schützen

Die erste Ebene ist die vollständige Isolierung des privilegierten Zugangs. Dafür ist unser Managed Red Tenant konzipiert.

Der Managed Red Tenant bietet eine vollständig isolierte, cloudbasierte administrative Umgebung – einen dedizierten Microsoft Entra-Tenant („der Red Tenant"), der ausschließlich für privilegierte Operationen genutzt wird. Administrative Identitäten leben hier. Administrative Geräte werden hier verwaltet. Nichts aus der regulären Arbeitsumgebung fließt hinüber.

Für die kritischsten Rollen – jene mit Control-Plane-Zugang, wie Global Administratoren – implementieren wir den „Clean Keyboard"-Ansatz: eine physische Privileged Admin Workstation (PAW) mit dedizierter Hardware, gehärteten Richtlinien und keinerlei Berührungspunkten mit dem alltäglichen Arbeitskontext. Für administrative Rollen unterhalb der Control Plane bieten wir skalierbare Virtual Access Workstations (VAW) an, die auf einer gehärteten Azure Virtual Desktop-Infrastruktur innerhalb des Red Tenants aufgebaut sind. Der Zugriffspfad selbst ist durch Microsoft Entra Private Access geschützt, mit Zero Trust Network Access und Conditional Access-Richtlinien, bevor eine Sitzung hergestellt werden kann.

Microsoft Entra Internet Access blockiert den öffentlichen Internetzugang aus administrativen Sitzungen und beschränkt die Verbindungen strikt auf privilegierte Schnittstellen und autorisierte Tenant-Umgebungen. Nahezu Echtzeit-Sitzungswiderruf ist durch Universal Conditional Access Evaluation möglich, was bedeutet, dass ein widerrufenes Credential nicht als gültige Sitzung weiterbesteht.

Der Managed Red Tenant wird rund um die Uhr von unserem Cloud Security Operations Center (CSOC) überwacht, mit speziell entwickelten Erkennungen, die gezielt auf administrative Berechtigungen und Zugriffsmuster ausgerichtet sind. Ein Angreifer, der irgendwie ein Credential in dieser Umgebung kompromittiert, hätte nicht drei unentdeckte Stunden, um Wipe-Befehle über eine globale Geräteflotte auszuführen.

Das ist besonders relevant für Rollen wie Intune-Administratoren. Sie wissen, wie man Clients sichert, aber die Absicherung einer privilegierten Admin-Workstation erfordert andere Fähigkeiten: Enterprise Access Architecture, Identity Hardening, Zero Trust Controls. Diese liegen typischerweise beim Sicherheitsteam. Ein Managed Red Tenant nimmt diese Last vollständig ab: Intune-Admins erhalten eine professionell verwaltete, konsistent gehärtete Workstation, ohne selbst zu Experten für Sicherheits-Workstations werden zu müssen. Das gilt für jede hochprivilegierte Rolle in der Organisation.

Managed Intune: die Management-Ebene selbst absichern

Die zweite Ebene ist sicherzustellen, dass Intune – das Tool, das beim Stryker-Angriff als Waffe eingesetzt wurde – nach höchstem Sicherheitsstandard konfiguriert, betrieben und kontinuierlich gepflegt wird. Dafür ist unser Managed Intune-Service zuständig.

Eine der zentralen Erkenntnisse aus Vorfällen wie diesem ist, dass Organisationen häufig Intune-Umgebungen erben, die organisch gewachsen sind: Richtlinien auf Richtlinien gestapelt, manuelle Änderungen über das Portal, die schwer zu prüfen sind, und Sicherheits-Baselines, die mit Microsofts eigenen, sich weiterentwickelnden Empfehlungen nicht Schritt gehalten haben. Genau diese Art von Umgebung ist es, in der Konfigurationsdrift ausnutzbare Lücken schafft.

Microsoft hat kürzlich Best Practices für die Absicherung von Microsoft Intune veröffentlicht – ein Signal, dass auch Microsoft Intune-Härtung als Thema betrachtet, das branchenweit explizite Aufmerksamkeit erfordert. Unser Managed Intune-Service basiert auf diesen Prinzipien, und wir haben Microsofts Empfehlungen als Teil unserer Baseline implementiert.

Unser Managed Intune-Service basiert auf der glueckkanja Intune Foundation: ein bewährter, kontinuierlich gepflegter Satz von Best Practices für das Gerätemanagement, vollständig als Code mit Terraform und unserem eigenen TerraProvider bereitgestellt. Jede Änderung ist automatisiert, versionskontrolliert und prüfbar. Es gibt keine undokumentierten Click-through-Konfigurationen, die ein Angreifer ausnutzen könnte, indem er die Lücke zwischen dem Beabsichtigten und dem tatsächlich Gesetzten versteht.

Aus Sicherheitsperspektive bedeutet das, dass Zero Trust, App Protection Policies und Endpoint Security-Konfigurationen by Design konsistent angewendet werden – über Windows, macOS, iOS und Android – nicht als einmalige Bereitstellungen, sondern als kontinuierlich durchgesetzte, fortlaufend aktualisierte Baselines, die Microsofts eigene Sicherheitsleitlinien nachverfolgen.

Entscheidend ist, dass Managed Intune die betriebliche Reife widerspiegelt, die modernes Endpoint-Management erfordert: kontinuierliches Compliance-Monitoring, strukturierte Änderungsgovernance und regelmäßige Service-Reviews – nicht als optionale Extras, sondern als Baseline-Operationen. Aber die Intune-Konfiguration zu sichern ist nur die halbe Miete. Wenn der Administrator, der auf die Konsole zugreift, dies von einem ungeschützten Gerät aus tut, bleibt die Management-Ebene trotzdem exponiert – genau hier vervollständigt der Managed Red Tenant das Modell.

Da alle Konfigurationen als Code auf Basis der Intune Foundation bereitgestellt werden, setzen wir ein striktes Vier-Augen-Prinzip mit Peer Review, zusätzlicher automatisierter Validierung und kontrollierten Deployment-Pipelines durch. Das eliminiert nicht verwaltete Portal-Änderungen innerhalb der Intune Foundation und stellt eine konsistente, prüfbare und sichere Baseline über alle Geräte hinweg sicher.

Der administrative Zugang wird durch ein Least-Privilege-Modell mit GDAP und Azure Lighthouse gesteuert, mit klar definierten Verantwortlichkeiten und eng begrenztem Zugang zum Kunden-Tenant. Das reduziert die mit privilegierten Operationen verbundene Angriffsfläche erheblich.

Aktionen auf Geräteebene, einschließlich destruktiver Operationen, verbleiben in der Verantwortung des Kunden, da ihre Ausführung eng mit organisationsspezifischen Prozessen und internen Governance-Frameworks verbunden ist. Microsoft und CISA empfehlen, solche Aktionen durch zusätzliche Schutzmaßnahmen zu sichern, beispielsweise durch Multi-Admin-Genehmigungskontrollen in Intune.

Die unbequeme Frage

Der Stryker-Angriff ist keine Anklage gegen Microsoft Intune. Intune hat sich genau so verhalten, wie es konzipiert wurde. Es führte die Befehle aus, die es von einem authentifizierten Administrator erhielt. Das Versagen lag nicht im Tool. Es lag im Fehlen von Kontrollen darüber, wer dieses Tool erreichen konnte, aus welchem Kontext heraus und mit welchem Autorisierungsgrad.

Das ist ein Governance- und Architekturproblem. Und es ist dasselbe Problem, das in den meisten Organisationen besteht, die heute Microsoft 365 betreiben.

Wenn Ihre Administratoren auf Intune, Entra ID oder Azure von denselben Geräten und Identitäten zugreifen, die sie für die alltägliche Arbeit verwenden – und wenn Ihre Intune-Umgebung über Jahre manueller Portal-Änderungen gewachsen ist anstatt durch ein strukturiertes, automatisiertes Betriebsmodell – tragen Sie dasselbe strukturelle Risiko, das Stryker am 11. März trug. Die Frage ist, ob ein Angreifer diese Schwachstelle finden wird, bevor Sie sie schließen.

Managed Red Tenant adressiert die Privilege- und Identitätsebene. Managed Intune adressiert die Konfigurations- und Betriebsebene. Zusammen schließen sie die zwei Lücken, die den Stryker-Angriff möglich gemacht haben.

Wenn Sie verstehen möchten, wie einer der Services auf Ihre aktuelle Umgebung zutrifft oder wo Ihre konkreten Schwachstellen liegen, sprechen wir gerne darüber.

Wir werden in Kürze auch einen Deep-Dive-Artikel veröffentlichen, der untersucht, wie der Stryker-Vorfall überhaupt möglich sein konnte.

Weitere Informationen

• CISA: Securing Cloud Business Applications
• Microsoft: Best Practices für die Absicherung von Microsoft Intune
• TechCrunch: CISA fordert Unternehmen auf, Microsoft Intune-Systeme zu sichern, nachdem Hacker Stryker-Geräte massenhaft gelöscht haben
• Managed Red Tenant im Azure Marketplace