Dies war nicht die Stille eines Netzausfalls oder eines Serverabsturzes, die das Sicherheitsteam erschreckte. Stattdessen war es die Stille von fast 200.000 gelöschten Geräten. Alles, von Laptops über Telefone bis hin zu Servern in 79 Ländern, wurde gleichzeitig abgeschaltet, noch bevor die meisten Mitarbeiter ihren morgendlichen Kaffee getrunken hatten. Was Stryker am 11. März widerfuhr, unterscheidet sich von den üblichen Angriffen, nicht nur aufgrund des Ausmaßes (obwohl das Ausmaß beunruhigend ist), sondern weil es einen blinden Fleck offenbart, der in nahezu jedem Unternehmen der Welt offen sichtbar ist. Es ist an der Zeit, dass wir auf diese Bedrohung aufmerksam werden. 

Lassen Sie mich zunächst diesen Vorfall erläutern, und dann besprechen wir einige Abhilfemaßnahmen.

Bevor wir fortfahren, vergessen Sie nicht, unseren vorherigen Blogbeitrag über  Wie iranische Bedrohungsakteure ohne Konnektivität agierenhier zu lesen. 

Sie können den vollständigen Vorfallsbericht zu diesem Vorfallhier herunterladen.

Was wirklich passiert ist. Die Version, die niemand erzählt

Die Stryker Corporation ist ein Hersteller von medizinischen Geräten. Sie produziert chirurgische Roboter, orthopädische Implantate, Krankenhausbetten und das Lifenet-Elektrokardiogramm-Übertragungssystem, das von Notfallhelfern verwendet wird. Sie wurde von einem zerstörerischen Cyberangriff getroffen, der von Handala, einer mit dem iranischen Ministerium für Geheimdienste und Sicherheit (MOIS) verbundenen Gruppe, beansprucht wurde und dem Präsidenten des Iran untersteht (im Gegensatz zur IRGC, die dem Obersten Führer untersteht). Handala hat in den letzten zwei Wochen ein außergewöhnlich hohes Aktivitätsniveau in einer umgebung mit eingeschränkter Konnektivität gezeigt.

Die oberflächliche Geschichte lautet im Wesentlichen so: Handala hat mehr als 200.000 Geräte vollständig gelöscht, behauptet, 50 Terabyte an Daten exfiltriert, Login-Bildschirme mit ihrem Logo verunstaltet und weltweit 56.000 Mitarbeiter in den Leerlauf versetzt zu haben. Zudem sank Strykers Aktienkurs an einem einzigen Handelstag um fast 4 Prozent. Der Angriff wurde als Vergeltung für einen Raketenangriff auf eine Schule in Minab, Iran, inszeniert.

All dies haben Sie gehört und gelesen, dank der weitreichenden Medienaufmerksamkeit, die diesem Ereignis zuteil wurde. Hier ist nun die Geschichte, die Ihnen nicht erzählt wird.

Der wahre Angriffspfad: Ihr Sicherheitstool war die Waffe

Ein Großteil der Berichterstattung nach dem Vorfall hat dies als einfachen „Wiper-Angriff“ beschrieben und abgehakt. Diese Rahmung, obwohl technisch korrekt, vergräbt das wichtigste Detail in diesem gesamten Vorfall: Handala hat wahrscheinlich keine neuartige Malware eingesetzt, um diese 200.000 Geräte zu löschen. Sie haben einfach Microsoft Intune benutzt.

Intune ist die cloudbasierte Mobile Device Management Plattform, die Unternehmen nutzen, um Sicherheitsrichtlinien durchzusetzen, Software-Updates zu pushen und Geräte, die verlohren oder gestohlen wurden, aus der Ferne zu löschen, um Datendiebstahl zu verhindern. Sie ist speziell dafür konzipiert, IT-Administratoren eine zentrale Konsole zu geben, von der aus sie ein beliebiges angemeldetes Gerät auf der Welt mit wenigen Klicks auf die Werkseinstellungen zurücksetzen können. Es kann mit einem administrativen Atomknopf gleichgesetzt werden.

Handala erlangte Administratorzugriff auf Strykers Intune-Umgebung und nutzte die in Intune integrierte Funktion zum Fernlöschen, um allen registrierten Geräten auf einmal einen Massenlöschbefehl zu erteilen. Das ist keine Zero-Day-Exploiterung. Das ist keine Spitzen-Malware. Das ist das Einloggen in eine legitime Unternehmensplattform mit gestohlenen Administratoranmeldeinformationen und das Drücken eines Knopfes, der bereits vorhanden war.

Dies ist das Detail, das jeden CISO derzeit wach halten sollte: Die Angreifer benötigen keine benutzerdefinierten Tools oder müssen keinen Wiper bereitstellen. Sie mussten lediglich die administrative Ebene einer Plattform erreichen, für die das potenzielle Opfer bereits bezahlt und der es implizit vertraut. Sobald sie diesen Zugang hatten, war die traditionelle Endpunkt-Erkennung blind dafür. Ein über Intune ausgegebener Fernlöschbefehl sieht identisch wie ein legitimer IT-Administrationsvorgang aus. Keine Malware-Signatur, kein anormaler Prozess und keine Warnung.

Das Risiko von innen

BYOD wurde auf eine Weise zu einem Risikomultiplikator, die Mitarbeiter nie vollständig begriffen haben. Stryker betrieb wie die meisten Unternehmen eine Bring Your Own Device-Politik, und Mitarbeiter registrierten ihre persönlichen iPhones und Androids in Intune für den Arbeitszugang. Als der Löschbefehl ausgeführt wurde, wurde nicht zwischen Unternehmensdaten und persönlichen Daten unterschieden. Persönliche Fotos, Banking-Apps und Authenticator-Apps zur Zwei-Faktor-Authentifizierung wurden alle vollständig gelöscht. In einer weiteren (glücklichen) Wendung fanden sich Mitarbeiter, die ihre persönlichen Authenticator-Apps verloren hatten, aus ihren eigenen Bankkonten ausgesperrt wieder, weil der zweite Faktor weg war. Dies ist ein katastrophales BYOD-Versagen, das Compliance-Teams zur Kenntnis nehmen müssen. 

Das Versagen von Lifenet war ein Patientensicherheitsereignis, das sich innerhalb einer Unternehmens-IT-Geschichte versteckte. Strykers Lifenet-System wird von Notfalldiensten verwendet, um Elektrokardiogrammdaten vor der Ankunft des Patienten an Krankenhäuser zu übermitteln — entscheidende Sekunden bei einem kardialen Vorfall. Das Maryland Institute for Emergency Medical Services bestätigte, dass Lifenet in den meisten Teilen des Bundesstaates nach dem Angriff nicht funktionsfähig war und wies die EMS-Mitarbeiter an, auf Radioberatung zurückzugreifen. Dies ist der schlimmste Albtraum des Gesundheitswesens (und er passiert immer wieder): ein Cyberangriff auf einen Anbieter, der die Qualität der Notfallversorgung stillschweigend verschlechtert, ohne dass auch nur ein einziges Krankenhaus infiltriert wird. Diese Dimension hat nahezu keine analytische Aufmerksamkeit erhalten.

Die Begründung für das Ziel zeigt eine neue und gefährliche Logik. Handalas Manifest beschrieb Stryker als ein „****-verwurzelt Unternehmen“ und bezog sich auf die Übernahme von OrthoSpace durch das Unternehmen im Jahr 2019. Stryker hat keine Verbindung zu Militär- oder Verteidigungsaufträgen. Es wurde aufgrund einer historischen Unternehmensübernahme ins Visier genommen, die es in dem ideologischen Rahmen der Angreifer mit Israel verband. Die Implikation ist beträchtlich und ich werde sie hier nicht noch einmal ausführen.

In der modernen Bedrohungslandschaft können frühere Unternehmenseinsätze von Gegnern auditiert werden, um eine narrative Rechtfertigung für Störungen aufzubauen.   

Der Angriff begann kurz nach Mitternacht Eastern Time, präzise kalibriert, um die globale Reichweite während des Zeitfensters zu maximieren, in dem Sicherheitsoperationen typischerweise mit minimaler Besetzung laufen und Geräte im Standby, aber verbunden sind. Das Timing war kein Zufall. Es spiegelt operative Planungen wider, die darauf abzielen, die Anzahl der online angemeldeten Geräte zu maximieren, wenn der Löschbefehl ausgegeben wurde, und gleichzeitig die Zeit zu minimieren, die Verteidiger hatten, um zu reagieren, bevor der Schaden weltweit angerichtet wurde. 

Was schiefgelaufen ist?

Der Einstiegspunkt war mit höchster Wahrscheinlichkeit eine kompromittierte Anmeldeinformation (Phishing ist Handalas dokumentierter primärer Zugangsmethode). Jemand mit Administratorrechten für Strykers Microsoft Entra ID (früher Azure Active Directory) Umgebung wurde kompromittiert, und dieser Kompromiss gewährte Handala Zugriff auf die Intune-Administratorkonsole. Von dieser Position aus hatte der Angreifer gottgleiche Macht über jedes registrierte Gerät in der Organisation.

Es war nicht das Fehlen von Sicherheitstools, das versagte. Stryker hatte Intune weltweit eingesetzt. Sie hatten MDM-Richtlinien. Was fehlte, waren angemessene Kontrollen rund um den privilegierten Zugriff auf die MDM-Administratorebene selbst. Konkret: Mehrfaktor-Authentifizierung unter Verwendung von phishing-resistenten Anmeldedaten für Administratorkonten wurde entweder nicht durchgesetzt oder umgangen; es gab keine Alarmierungsregeln für Massenlöschbefehle. Löschaktionen bei mehr als einer Handvoll von Geräten in einem kurzen Zeitfenster lösten nie eine automatische Untersuchung aus; privilegierte Identitätsverwaltungen, die Just-in-Time-Erhöhung erfordert hätten, um zerstörerische Maßnahmen wie Massenlöschungen durchzuführen