Kurzfassung
Ab dem 31. Juli 2026 begann ein als „TheHatman“ bekannter Bedrohungsakteur, Mitarbeiterdatenbanken zu verkaufen, die angeblich aus den Microsoft-Azure- und Entra-ID-Tenants mehrerer Fortune-500-Unternehmen — darunter McDonald's, Vodafone, Tata Consultancy Services und HCL Technologies — exfiltriert wurden. Das beanspruchte Gesamtvolumen beläuft sich auf 3,64 Millionen Datensätze. Hudson Rock, das Stichproben überprüfte, stufte die Daten als „höchstwahrscheinlich authentisch“ ein und identifizierte durch Infostealer gestohlene Azure-Zugangsdaten, die mit mehreren der genannten Unternehmen in Verbindung stehen und in Untergrundmärkten kursieren. Der Angriff scheint keine Schwachstelle in Azure selbst auszunutzen — es wurden gültige gestohlene Zugangsdaten verwendet, um sich als legitime Benutzer anzumelden und Verzeichnisdaten zu exportieren.
Der Vorfall wurde erstmals am 17. August 2026 von The Register berichtet und am folgenden Tag von BleepingComputer und Help Net Security aufgegriffen. TCS hat öffentlich erklärt, keine glaubwürdigen Belege für einen Einbruch in die eigenen Systeme gefunden zu haben; die anderen genannten Unternehmen hatten zum Zeitpunkt der Erstveröffentlichung keine formellen Stellungnahmen abgegeben.
Was geschah: vom Infostealer zum Azure-Verzeichnis
Die Angriffskette besteht aus zwei Gliedern. Zunächst kompromittierte Infostealer-Malware — eine Kategorie von Software zum Sammeln von Zugangsdaten, die still gespeicherte Passwörter, Browser-Cookies und Sitzungs-Token von infizierten Endpunkten extrahiert — Geräte von Mitarbeitern der Zielunternehmen. Sobald ein Infostealer auf einem Endpunkt aktiv ist, sammelt er alle Cloud-Zugangsdaten, die er finden kann: Microsoft-365-Token, Azure-Management-Portal-Anmeldedaten, Entra-ID-Administratorkonten. Diese gestohlenen Zugangsdaten werden anschließend in Untergrundmärkten verkauft oder gehandelt.
Im zweiten Schritt nutzte der Angreifer die gesammelten Zugangsdaten, um sich direkt bei den Microsoft-Azure- und Entra-ID-Tenants der Opfer als legitime Benutzer zu authentifizieren. Von innen heraus ist der Export des Mitarbeiterverzeichnisses — das Azure authentifizierten Benutzern mit ausreichenden Berechtigungen über seine Graph-API und das Admin-Portal zugänglich macht — ein reibungsarmer Vorgang, der nur dann Spuren hinterlässt, wenn die richtigen Auditprotokolle überwacht werden. Hudson Rock stellt fest, dass es „durch Infostealer-Aktivitäten kompromittierte Azure-Zugangsdaten“ bei mehreren genannten Unternehmen identifizierte, was den behaupteten Vektor bestätigt, ohne dass festgestellt werden konnte, welche spezifischen Zugangsdaten für welchen einzelnen Export verwendet wurden.
Der Grund, warum diese Angriffskette so wirksam ist, liegt darin, dass sie Perimeter-Abwehrmaßnahmen vollständig umgeht. Es gibt keinen Exploit, keine schädliche Nutzlast, die in die Azure-Infrastruktur eingeschleust wird, keinen Netzwerkeinbruch im traditionellen Sinne. Der Angreifer meldet sich mit einem echten Passwort und einem gültigen (oder kürzlich ungültig gemachten) Sitzungs-Token an, navigiert zum Verzeichnis und exportiert es. Aus Azures Perspektive sieht die Sitzung wie eine gewöhnliche Administratoraktion aus.
Wer betroffen war und welche Daten gestohlen wurden
Der beanspruchte Umfang ist erheblich. McDonald's steht mit angeblich 1,7 Millionen Datensätzen an erster Stelle, gefolgt von Tata Consultancy Services mit rund 800.000, Vodafone mit etwa 425.000 und HCL Technologies mit rund 250.000. Der Rest der insgesamt 3,64 Millionen Datensätze verteilt sich auf Gap Inc., InterContinental Hotels Group, Kyndryl, Hexaware Technologies und Wyndham Hotels.
Besonders heikel an den Daten ist nicht nur das Volumen, sondern die Reichhaltigkeit des Verzeichnisschemas. Von Hudson Rock überprüfte Stichproben enthielten berichten zufolge Unternehmens-E-Mail-Adressen, Telefonnummern, physische Büroadressen, Mitarbeiter-IDs, Stellenbezeichnungen, abteilungsbezogene Organigramme mit Vorgesetzten-Beziehungen, Active-Directory-Gruppenmitgliedschaften und Details zu Dienstkonten. Kritisch: Einige Datensätze identifizierten berichten zufolge Konten mit globalen Administratorrechten in Entra ID. Diese letzte Kategorie stellt eine Zielliste dar: Ein Angreifer, der weiß, welche Konten im Tenant die höchsten Berechtigungen besitzen, verfügt über eine fertige Karte für die nächste Phase eines umfassenderen Einbruchs.
TCS reichte am 10. August beim Bombay Stock Exchange eine Erklärung ein, nachdem Bedrohungsgeheimdienstwarnungen eingegangen waren, und erklärte, „keine glaubwürdigen Belege für einen Einbruch“ in die eigenen Systeme oder Kundenumgebungen gefunden zu haben. Keines der anderen genannten Unternehmen hatte zum Zeitpunkt der Erstberichterstattung öffentliche Stellungnahmen abgegeben.
Warum das über die reinen Zahlen hinaus bedeutsam ist
Durchgesickerte Mitarbeiterverzeichnisse werden häufig als weniger schwerwiegende Vorfälle eingestuft als Verstöße gegen Finanz- oder Gesundheitsdaten — eine Einschätzung, die ihren nachgelagerten Wert für Angreifer unterschätzt. Ein vollständiges Organigramm mit E-Mail-Adressen und Berichtsstrukturen bildet die Grundlage für gezielte Spear-Phishing- und Business-Email-Compromise-Kampagnen (BEC). Zu wissen, dass „Alice in der Buchhaltung an Bob, den CFO, berichtet“, ermöglicht es einem Angreifer, eine äußerst überzeugende Imitation von Bob zu erstellen, der Alice dringend um eine Überweisung bittet.
Die Einbeziehung von Dienstkonten und deren Entra-ID-Gruppenmitgliedschaften erhöht den Schweregrad weiter. Dienstkonten verfügen oft über erhöhte Berechtigungen und werden selten so genau überwacht wie menschliche Konten. Wenn eines dieser Dienstkonten Passwörter verwendet hat, die an anderer Stelle in Infostealer-Dumps auftauchen, werden sie zu sofortigen Einstiegspunkten in Produktionsinfrastruktur, CI/CD-Pipelines oder Data Warehouses.
Für Organisationen, die der EU-Datenschutz-Grundverordnung unterliegen, löst jede bestätigte Exfiltration personenbezogener Mitarbeiterdaten eine 72-stündige Meldepflicht bei der zuständigen Aufsichtsbehörde aus, unabhängig davon, ob der Verstoß durch einen Plattformfehler oder gestohlene Zugangsdaten verursacht wurde. Artikel 33 DSGVO unterscheidet nicht zwischen Einbruchsmethoden. Die Vodafone- und IHG-Expositionen würden, sofern bestätigt, Meldepflichten in mehreren EU-Mitgliedstaaten auslösen.
Was das für US- und EU-Entwicklungsteams bedeutet
Das systemische Problem, das dieser Vorfall aufdeckt, ist die Lücke zwischen Cloud-Tenant-Sicherheit und Endpunktsicherheit. Teams, die intensiv in Entra-ID-Conditional-Access, Bedrohungserkennung und Zero-Trust-Architektur investiert haben, können dennoch kompromittiert werden, wenn ein Infostealer lange genug unentdeckt auf dem Laptop eines Entwicklers läuft, um ein gültiges Sitzungs-Token zu stehlen. Sitzungs-Token in modernen Identitätssystemen können stunden- bis tagelang gültig bleiben, und viele Infostealers zielen speziell auf sie ab anstatt auf Passwörter, da Token MFA vollständig umgehen.
Software-Teams, die auf Azure aufbauen, sind diesem Muster besonders ausgesetzt, weil Entwicklungsumgebungen dazu neigen, umfangreiche Berechtigungen anzusammeln. Ein Entwickler, dem der Entra-ID-Directory-Reader-Zugriff gewährt wurde oder der Mitglied einer Gruppe mit erhöhten Azure-Ressourcenberechtigungen ist, wird zu einem hochwertigem Ziel für jede Infostealer-Kampagne. Das Prinzip der minimalen Rechtevergabe — auf der Infrastrukturebene gut verstanden — wird auf der Entwicklerrollenebene häufig verletzt, weil es im täglichen Arbeitsablauf Reibung erzeugt.
Die praktische Schlussfolgerung für Entwicklungsleiter lautet: Endpunkt-Hygiene als erstklassige Cloud-Sicherheitskontrolle behandeln, nicht als separate IT-Angelegenheit. Infostealer-Infektionen verbreiten sich über Phishing-E-Mails, schädliche Browser-Erweiterungen, trojanisierte Entwicklertools und gecrackte Software. Ein Team, das Zero-Trust-Netzwerkzugang einsetzt, aber Entwicklern erlaubt, nicht überprüfte Browser-Erweiterungen zu installieren, hat eine Lücke, die Angreifer finden werden.
Was jetzt zu tun ist: eine praktische Checkliste
- Entra-ID-Anmeldeprotokolle auf umfangreiche Verzeichnisexportoperationen prüfen. Navigieren Sie im Microsoft-Entra-Admin-Center zu Identität → Überwachung & Integrität → Auditprotokolle und filtern Sie nach Vorgängen wie „Verzeichnis exportieren“, „Benutzer abrufen“ in großem Umfang oder Graph-API-Aufrufen, die große Ergebnismengen zurückgegeben haben. Schauen Sie mindestens 90 Tage zurück. Anomale Anmeldungen aus neuen geografischen Regionen, unbekannten Geräten oder außerhalb der Geschäftszeiten in diesem Zeitraum erfordern sofortige Untersuchung.
- Phishing-resistente MFA für alle privilegierten Konten erzwingen, insbesondere globale Administratoren und Dienstkonten. Nur-Passwort-Authentifizierung und SMS-basierte MFA sind beide unzureichend. Verlangen Sie FIDO2-Hardware-Schlüssel oder Microsoft Authenticator mit Nummernabgleich (der Push-Bombing verhindert) für jedes Konto mit Berechtigungen auf Verzeichnisebene. Wenden Sie Richtlinien für bedingten Zugriff an, die Legacy-Authentifizierungsprotokolle blockieren, die MFA überhaupt nicht unterstützen.
- Zugangsdaten für Dienstkonten rotieren, die über kompromittierte Sitzungen zugänglich gewesen sein könnten. Wenn ein menschliches Konto in Ihrem Tenant im verdächtigen Zeitraum Zugriff auf Dienstkonto-Zugangsdaten, API-Schlüssel oder Geheimnisse hatte, rotieren Sie diese Zugangsdaten jetzt. Priorisieren Sie in Umgebungsvariablen gespeicherte Geheimnisse, CI/CD-Pipeline-Konfigurationen und Azure Key Vault-Einträge, die für die betreffenden Konten zugänglich sind.
- Umfang der Entwicklerberechtigungen in Entra ID überprüfen. Prüfen Sie, welche Entwicklerkonten Directory-Reader-, User-Administrator- oder Global-Administrator-Rollen innehaben und ob Gruppenmitgliedschaften impliziten Zugriff auf sensible Azure-Ressourcen gewähren. Wenden Sie das Prinzip der minimalen Rechtevergabe an: Entwickler, die auf Azure aufbauen, benötigen für ihre tägliche Arbeit selten Lese-Berechtigungen auf Verzeichnisebene. Entfernen Sie, was nicht notwendig ist.
- Endpunkt-Infostealer-Exposition bewerten. Überprüfen Sie EDR-Telemetrie auf Browser-Zugangsdaten-Harvesting-Verhalten, unerwartete Prozessinjektionen in Browser-Prozesse und Netzwerkverbindungen zu bekannter Infostealer-C2-Infrastruktur. Wenn Sie keine EDR-Lösung haben, die Entwicklerworkstations abdeckt, ist diese Lücke jetzt ein dokumentiertes Cloud-Sicherheitsrisiko, nicht nur ein Endpunktverwaltungsversäumnis.
- Bei DSGVO-Geltungsbereich: Meldepflichten prüfen. Gemäß Art. 33 DSGVO löst eine Verletzung personenbezogener Daten mit Mitarbeiterdatensätzen eine 72-stündige Meldepflicht bei Ihrer federführenden Aufsichtsbehörde aus, wenn ein Risiko für die Rechte und Freiheiten natürlicher Personen besteht. Konsultieren Sie umgehend Ihren Datenschutzbeauftragten, wenn Ihre Organisation zu den genannten Unternehmen gehört oder wenn eine interne Untersuchung eine vergleichbare Zugangsdaten-Exposition aufdeckt.
Häufig gestellte Fragen
Wie funktionierte die Azure-Zugangsdatendiebstahl-Kampagne?
Der Angreifer nutzte Zugangsdaten, die durch Infostealer-Malware von infizierten Mitarbeiterendpunkten der Zielunternehmen gestohlen wurden. Diese Zugangsdaten ermöglichten den Zugriff auf die Microsoft-Azure- und Entra-ID-Tenants der Unternehmen, aus denen der Angreifer Mitarbeiterverzeichnisdaten exportierte. Hudson Rock identifizierte durch Infostealer-Infektionen kompromittierte Azure-Zugangsdaten bei mehreren genannten Unternehmen, was den behaupteten Vektor bestätigt.
Welche Unternehmen waren betroffen?
Der Bedrohungsakteur behauptete, Daten von McDonald's (~1,7 Mio. Datensätze), TCS (~800.000), Vodafone (~425.000), HCL Technologies (~250.000), Gap Inc., IHG, Kyndryl, Hexaware Technologies und Wyndham Hotels zu besitzen — insgesamt 3,64 Millionen Datensätze. TCS hat öffentlich bestritten, glaubwürdige Belege für einen Einbruch in seine eigenen Systeme gefunden zu haben. Andere Unternehmen hatten zum Zeitpunkt der Erstberichterstattung keine formellen Stellungnahmen abgegeben.
Welche Daten wurden offengelegt?
Von Hudson Rock überprüfte Stichproben enthielten berichten zufolge Unternehmens-E-Mails, Telefonnummern, physische Adressen, Mitarbeiter-IDs, Stellenbezeichnungen, Abteilungen, Organigramm-Berichtsstrukturen, Active-Directory-Gruppenmitgliedschaften und Dienstkontodetails. Bemerkenswert: Einige Datensätze identifizierten Konten mit globalen Administratorrechten in Entra ID, was eine hochwertige Zielliste für Folgeangriffe darstellt.
Was ist ein Infostealer und wie ermöglicht er diese Art von Angriff?
Ein Infostealer ist Malware, die still gespeicherte Zugangsdaten, Sitzungs-Token und im Browser gespeicherte Passwörter von infizierten Geräten extrahiert. Wenn das Gerät eines Mitarbeiters infiziert wird, sammelt der Infostealer Azure- und Microsoft-365-Token und sendet sie an den Angreifer. Da die Anmeldung gültige Zugangsdaten verwendet, umgeht sie oft Perimeter-Abwehrmaßnahmen. Ein kürzlich erfasstes gültiges Sitzungs-Token kann MFA vollständig umgehen.
Bedeutet das, dass Azure selbst eine Sicherheitslücke hat?
Nein. Forscher kamen zu dem Schluss, dass der Angriff durch Infostealer gestohlene Zugangsdaten verwendete und keine systemische Schwachstelle in Azure oder Entra ID. Eine weitverbreitete Plattformlücke würde auch kleine Unternehmen unterschiedslos betreffen. Microsoft hat keine Sicherheitsempfehlung herausgegeben, die diesen Vorfall auf einen Plattformfehler zurückführt. Die Grundursache ist Zugangsdatendiebstahl auf Endpunktebene.
Was sollten Entwicklerteams tun, um ihre Azure-Tenants zu schützen?
Erzwingen Sie Phishing-resistente MFA (FIDO2 oder Authenticator mit Nummernabgleich) für alle Konten. Prüfen Sie Entra-ID-Anmeldeprotokolle auf anomale Massenverzeichnisexporte der letzten 90 Tage. Blockieren Sie Legacy-Authentifizierungsprotokolle via bedingtem Zugriff. Rotieren Sie Dienstkonto-Zugangsdaten und API-Schlüssel überall dort, wo Zweifel bestehen. Überprüfen Sie Entwicklerrollenberechtigungen zur Durchsetzung minimaler Rechtevergabe. Und behandeln Sie Endpunkt-Infostealer-Hygiene als erstklassige Cloud-Sicherheitskontrolle, nicht als separate IT-Angelegenheit.
Quellen
The Register — Crook hawks millions of records allegedly plundered from corporate Azure tenants (17. August 2026)
BleepingComputer — Hacker claims 3.6 million Azure account records stolen from major companies
Help Net Security — Hacker claims millions of records stolen from corporate Azure tenants (18. August 2026)
SC Media — McDonald’s employee records allegedly stolen from Azure