81 Millionen Mal angeklopft: Warum deine Microsoft-Identitäten die wichtigste Sicherheitszone sind

Wenn ich mir aktuelle Angriffe auf Microsoft-Umgebungen anschaue, fällt mir vor allem eines auf: Die Angreifer versuchen immer seltener, mit der digitalen Brechstange durch die Eingangstür zu kommen.

Stattdessen suchen sie nach dem Seiteneingang. Nach einem vergessenen Schlüssel. Nach einem alten Dienstausweis. Oder nach einem Sicherheitsmitarbeiter, der zwar eine schicke Uniform trägt, aber leider nur montags bis donnerstags kontrolliert.

Genau das passiert derzeit rund um Azure, Microsoft Entra ID und klassische Active-Directory-Umgebungen. Im Mittelpunkt steht die Frage, wer oder was sich anmelden darf, unter welchen Bedingungen der Zugriff erlaubt wird und ob eine digitale Identität wirklich die ist, für die sie sich ausgibt.

Identitäten werden damit zur wichtigsten Sicherheitszone moderner Microsoft-Umgebungen.

Und mit KI-Agenten vergrößert sich diese Zone gerade enorm.

Active Directory, Entra ID und Azure: Wer macht hier eigentlich was?

Bevor wir uns die Angriffe genauer ansehen, lohnt sich eine kurze Einordnung. Microsoft hat über die Jahre genügend Produktnamen produziert, um damit ein kleines Quartettspiel zu veröffentlichen.

• Active Directory, kurz AD, verwaltet Identitäten und Zugriffsrechte traditionell im eigenen Unternehmensnetzwerk. Dort liegen Benutzerkonten, Gruppen, Computer und Berechtigungen.

• Microsoft Entra ID, früher Azure Active Directory, übernimmt diese Aufgabe für Cloud-Dienste wie Microsoft 365 und Azure. Es entscheidet beispielsweise, wer sich bei Outlook, Teams, SharePoint oder im Azure-Portal anmelden darf.

• Azure wiederum ist Microsofts Cloud-Plattform. Dort betreiben Unternehmen Server, Datenbanken, Anwendungen und weitere Dienste.

In vielen Unternehmen sind diese Welten miteinander verbunden. Benutzerkonten aus dem lokalen Active Directory werden mit Entra ID synchronisiert oder über Active Directory Federation Services, kurz AD FS, an die Cloud angebunden.

Das ist praktisch. Ein Konto, viele Dienste.

Es bedeutet aber auch: Wird die Identität kompromittiert, bekommt der Angreifer nicht nur Zugriff auf einen einzelnen Rechner, sondern auf E-Mails, Dateien, Anwendungen, Cloud-Ressourcen und administrative Funktionen.

Der Generalschlüssel hängt heute nicht mehr im Hausmeisterbüro. Er liegt in der Cloud.

Angriff Nummer eins: 81 Millionen Anmeldeversuche über die Azure CLI

Wie attraktiv Microsoft-Identitäten für Angreifer sind, zeigt eine im Juni 2026 beobachtete Kampagne besonders deutlich.

Innerhalb von nur zwei Wochen registrierte das Sicherheitsunternehmen Huntress mehr als 81 Millionen Anmeldeversuche gegen Microsoft-Konten. Mindestens 78 Konten in 64 Organisationen wurden erfolgreich kompromittiert.

Die Angreifer nutzten dafür die Azure Command-Line Interface, kurz Azure CLI. Das ist ein legitimes Werkzeug, mit dem Administratoren und Entwickler Azure über Kommandozeilenbefehle verwalten.

Die Azure CLI ist also nicht das Problem. Ein Hammer ist schließlich auch nicht automatisch kriminell, nur weil jemand damit Köpfe einschlägt.

Die Angreifer missbrauchten einen veralteten Anmeldeweg, der auf dem sogenannten ROPC-Verfahren basierte. Dabei werden Benutzername und Passwort direkt gegen einen Token-Endpunkt geprüft. Dieser ältere Authentifizierungsweg unterstützt keine interaktive Multi-Faktor-Authentifizierung.

Anschließend wurde Password Spraying betrieben.

Dabei probieren die Angreifer nicht Tausende Passwörter gegen ein einzelnes Konto aus. Das würde schnell zu Sperrungen und Alarmen führen. Stattdessen testen sie wenige häufig verwendete Passwörter gegen sehr viele Benutzerkonten.

Sinngemäß sieht das so aus:

• „Sommer2026!“ bei 5.000 Konten ausprobieren
• kurz warten
• „Willkommen123!“ ausprobieren
• wieder warten
• hoffen, dass irgendwo die Passwortkreativität Urlaub hatte

Das Problem: Einige der betroffenen Unternehmen hatten MFA grundsätzlich eingerichtet. Sie gingen also davon aus, geschützt zu sein.

Die Richtlinien galten jedoch nicht für alle Benutzer, Anwendungen oder Anmeldewege. Teilweise war MFA nur für Administratoren vorgesehen. Teilweise wurden bestimmte Standorte als vertrauenswürdig eingestuft. In anderen Fällen befanden sich die Conditional-Access-Regeln lediglich im Berichtsmodus.

Sie waren vorhanden. Sie sahen auch sehr offiziell aus. Sie griffen nur leider nicht ein.

MFA ist kein Haken auf einer Checkliste

Multi-Faktor-Authentifizierung gehört weiterhin zu den wirkungsvollsten Schutzmaßnahmen gegen gestohlene Passwörter. Nach Untersuchungen von Microsoft kann MFA das Risiko einer Kontoübernahme um mehr als 99 Prozent reduzieren.

Das ist eine hervorragende Nachricht.

Die schlechte Nachricht: MFA schützt nur die Anmeldevorgänge, für die es tatsächlich verlangt und technisch unterstützt wird.

Eine Richtlinie mit dem Namen „MFA für alle“ muss nicht zwangsläufig für alle Benutzer, alle Cloud-Anwendungen, alle Authentifizierungsverfahren und alle Gerätekonstellationen gelten.

Ausnahmen sammeln sich in vielen Microsoft-Tenants über die Jahre an wie Kabel in einer Schublade: Niemand weiß mehr genau, wofür sie gedacht waren, aber wegwerfen möchte sie auch niemand.

Die Fragen sollten lauten:

• Für welche Benutzer wird MFA wirklich erzwungen?
• Werden Gäste und externe Konten berücksichtigt?
• Welche Anwendungen oder Anmeldewege sind ausgeschlossen?
• Gelten Ausnahmen für vermeintlich vertrauenswürdige Standorte?
• Können ältere Authentifizierungsverfahren noch genutzt werden?
• Welche MFA-Verfahren sind erlaubt?
• Sind besonders privilegierte Konten phishing-resistent geschützt?
• Werden neue Regeln nach der Testphase auch tatsächlich aktiviert?

MFA ist kein Produkt, das man einmal einschaltet. Es ist Teil einer Zugriffsstrategie.

Conditional Access: Der Türsteher braucht eine vollständige Gästeliste

Conditional Access ist vereinfacht gesagt der Türsteher von Microsoft Entra ID.

Bei jeder Anmeldung können verschiedene Signale bewertet werden:

• Wer meldet sich an?
• Auf welche Anwendung möchte die Person zugreifen?
• Von welchem Standort erfolgt die Anmeldung?
• Ist das Gerät bekannt und regelkonform?
• Ist das Verhalten ungewöhnlich?
• Handelt es sich um ein administratives Konto?
• Welche Authentifizierungsmethode wurde verwendet?

Auf Basis dieser Informationen kann Entra ID den Zugriff erlauben, eine zusätzliche Authentifizierung verlangen oder die Anmeldung vollständig blockieren.

Das funktioniert allerdings nur, wenn die Richtlinien vollständig, widerspruchsfrei und aktiv sind.

Ein Türsteher, der nur den Haupteingang kontrolliert, hilft wenig, wenn der Lieferanteneingang offensteht.

Unternehmen sollten deshalb nicht nur einzelne Regeln betrachten, sondern die gesamte Abdeckung überprüfen. Dazu gehören Benutzerkonten, Administratoren, Dienstkonten, Anwendungen, externe Identitäten und zunehmend auch KI-Agenten.

Angriff Nummer zwei: Golden SAML und der gefälschte Generalschlüssel

Noch kritischer wird es, wenn Angreifer nicht nur ein Passwort stehlen, sondern einfach selbst vertrauenswürdige Anmeldetoken erzeugen.

Genau darum geht es bei sogenannten Golden-SAML-Angriffen.

SAML ist ein Verfahren, mit dem Identitätsdienste gegenüber Anwendungen bestätigen: „Diese Person wurde erfolgreich angemeldet und darf hinein.“

Die Anwendung vertraut dieser Aussage, weil sie digital signiert ist.

Man kann sich das wie einen Firmenausweis vorstellen. Solange das Sicherheitssiegel echt ist, wird der Ausweis akzeptiert. Wird jedoch die Maschine gestohlen, mit der diese Siegel hergestellt werden, kann der Angreifer plötzlich eigene Ausweise drucken.

Mit beliebigen Namen. Beliebigen Rollen. Und ohne freundliches Passfoto.

In AD-FS-Umgebungen werden kryptografische Schlüssel genutzt, um solche SAML-Token zu signieren. Gelangen Angreifer an das entsprechende Schlüsselmaterial, können sie unter Umständen gefälschte Token erstellen, die von verbundenen Anwendungen trotzdem als vertrauenswürdig akzeptiert werden.

Eine im Juli 2026 veröffentlichte Schwachstelle in Active Directory Federation Services zeigt, wie aktuell dieses Risiko ist. Zu weit gefasste Berechtigungen auf einem sogenannten Distributed-Key-Manager-Container können es bereits autorisierten Angreifern ermöglichen, auf Schlüsselmaterial zuzugreifen und ihre Rechte auszuweiten.

Die US-amerikanische Cybersecurity-Behörde CISA nahm die Schwachstelle in ihren Katalog aktiv ausgenutzter Sicherheitslücken auf.

Das bedeutet nicht, dass jeder AD-FS-Server automatisch aus dem Internet übernommen werden kann. Ein Angreifer benötigt zunächst einen Zugangspunkt in die Umgebung. Hat er diesen allerdings erreicht, kann eine unzureichend abgesicherte Identitätsinfrastruktur aus einem keinen Einbruch einen unternehmensweiten Vorfall machen.

Warum Golden SAML so gefährlich ist

Bei einem normalen Passwortdiebstahl kann ein Unternehmen das Passwort zurücksetzen. Bei einem gestohlenen Sitzungstoken lassen sich Sitzungen widerrufen.

Wird jedoch ein Token-Signaturschlüssel kompromittiert, reicht ein einfacher Passwortwechsel nicht aus. Der Angreifer kann weiterhin Identitäten vortäuschen, solange die betroffenen Vertrauensstellungen und Schlüssel nicht bereinigt wurden.

Das ist ein bisschen so, als würde man nach einem Einbruch lediglich das Namensschild an der Haustür austauschen, obwohl der Täter eine Kopie des Generalschlüssels besitzt.

Unternehmen mit AD FS sollten deshalb kurzfristig:

• die aktuellen Sicherheitsupdates installieren,
• die Berechtigungen des DKM-Containers überprüfen,
• die von Microsoft bereitgestellten Audit-Ereignisse kontrollieren,
• AD-FS- und Entra-Connect-Systeme gezielt überwachen,
• ungewöhnliche Änderungen an Vertrauensstellungen untersuchen,
• und bei einem möglichen Schlüsselzugriff einen vollständigen Incident-Response-Prozess starten.

Langfristig gehört außerdem die Frage auf den Tisch, ob AD FS noch benötigt wird oder durch modernere Cloud-Authentifizierungsverfahren ersetzt werden kann.

Nicht jede alte Architektur ist automatisch schlecht. Aber „Das läuft schon seit zwölf Jahren“ ist auch keine Sicherheitszertifizierung.

Identity Protection: Auffälliges Verhalten erkennen, bevor es teuer wird

Prävention allein reicht nicht. Unternehmen müssen auch erkennen können, wenn sich eine Identität ungewöhnlich verhält.

Microsoft Entra ID Protection bewertet dazu verschiedene Risikosignale. Dazu können beispielsweise gehören:

• Anmeldungen aus ungewöhnlichen Regionen,
• Verbindungen über verdächtige IP-Adressen,
• Hinweise auf geleakte Zugangsdaten,
• atypische Reisebewegungen,
• ungewöhnliche Anmeldeeigenschaften,
• oder Verhaltensmuster, die nicht zum bisherigen Benutzerprofil passen.

Diese Signale können über Conditional Access direkt in Zugriffsentscheidungen einfließen.

Bei einem erhöhten Anmelderisiko kann beispielsweise eine erneute starke Authentifizierung verlangt werden. Bei hohem Benutzerrisiko kann der Zugriff blockiert oder eine sichere Kennwortänderung erzwungen werden.

Wichtig ist auch hier: Warnungen allein schützen das Unternehmen nicht.

Ein Rauchmelder, dessen Batterie neben ihm auf dem Tisch liegt, ist technisch vorhanden. Beim Brand hilft das trotzdem überschaubar.

Risikobasierte Richtlinien müssen deshalb getestet, aktiviert, überwacht und regelmäßig angepasst werden. Microsoft stellt seine bisherigen eigenständigen Risk Policies zudem auf Conditional Access um. Unternehmen sollten die Migration rechtzeitig einplanen und nicht erst dann beginnen, wenn die alte Konfiguration kurz vor der Abschaltung steht.

Und jetzt kommen KI-Agenten ins Spiel

Mit Microsoft Scout und anderen autonomen KI-Agenten entsteht eine weitere Dimension der Identitätssicherheit.

Scout wurde von Microsoft als dauerhaft aktiver Arbeitsagent vorgestellt. Er kann auf Microsoft-365-Kontext zugreifen, Informationen aus Teams und Outlook verarbeiten und selbstständig Aufgaben vorbereiten oder ausführen. Laut Microsoft-Dokumentation kann Scout unter anderem Dateien lesen und schreiben, Browser bedienen und Befehle ausführen – abhängig von den erteilten Berechtigungen und Freigaben.

Das ist leistungsfähig – und sicherheitsrelevant.

Scout ist kein Beleg dafür, dass KI-Agenten grundsätzlich unsicher sind. Die Entwicklung zeigt aber, dass sich Unternehmen künftig nicht mehr nur mit menschlichen Identitäten beschäftigen müssen.

Ein Agent, der E-Mails liest, Termine koordiniert, Dateien bearbeitet oder Anwendungen bedient, braucht ebenfalls eine klar geregelte Identität.

Dabei stellen sich Fragen wie:

• Wem gehört der Agent?
• Auf welche Informationen darf er zugreifen?
• Handelt er im Namen eines Benutzers oder mit einer eigenen Identität?
• Welche Aktionen darf er selbstständig ausführen?
• Wann benötigt er eine Bestätigung?
• Wie werden seine Aktivitäten protokolliert?
• Was passiert, wenn der verantwortliche Mitarbeiter das Unternehmen verlässt?
• Wann werden nicht mehr benötigte Berechtigungen entfernt?
• Kann ein manipulierter Inhalt den Agenten zu unerwünschten Aktionen bewegen?

Microsoft entwickelt mit Entra Agent ID bereits spezielle Identitäts- und Governance-Funktionen für solche nichtmenschlichen Akteure.

Die Grundregel bleibt jedoch dieselbe: Ein Agent sollte nur die Berechtigungen erhalten, die er für seine konkrete Aufgabe benötigt – und nicht vorsorglich den gesamten digitalen Schlüsselbund.

„Könnte später praktisch sein“ war bei Berechtigungen noch nie eine gute Begründung.

Menschliche und nichtmenschliche Identitäten gemeinsam betrachten

In vielen Unternehmen existieren heute bereits mehr technische als menschliche Identitäten.

Dazu gehören:

• Dienstkonten,
• App-Registrierungen,
• Service Principals,
• verwaltete Identitäten,
• Automatisierungen,
• Skripte,
• Integrationen,
• API-Zugänge,
• Bots,
• und künftig immer mehr KI-Agenten.

Diese Konten können jahrelang aktiv bleiben. Verantwortlichkeiten wechseln, Projekte enden und Anwendungen werden abgeschaltet – die Berechtigungen bleiben jedoch bestehen.

So entsteht schleichend ein Identitätszoo, in dem niemand mehr genau weiß, welches Tier gefüttert werden muss und welches längst durch den Hinterausgang verschwunden ist.

Ein modernes Identity-Security-Konzept muss deshalb menschliche und nichtmenschliche Identitäten gemeinsam erfassen, bewerten und überwachen.

Was IT-Entscheider jetzt konkret tun sollten

Du musst nicht jedes OAuth-Verfahren auswendig erklären können, um die richtigen Entscheidungen zu treffen. Entscheidend ist, dass dein Unternehmen die relevanten Fragen strukturiert beantwortet.

1. Alle Identitäten inventarisieren

Erfasst nicht nur Mitarbeiterkonten, sondern auch Administratoren, Gäste, Dienstkonten, Anwendungen, Service Principals, Automatisierungen und KI-Agenten.

Jede Identität braucht einen dokumentierten Zweck und einen verantwortlichen Eigentümer.

2. MFA-Abdeckung statt MFA-Existenz prüfen

Überprüft, welche Benutzer, Anwendungen und Anmeldewege wirklich geschützt sind. Achtet besonders auf Ausnahmen, vertrauenswürdige Standorte, ältere Verfahren und Richtlinien, die lediglich im Berichtsmodus laufen.

3. Phishing-resistente Anmeldung priorisieren

Für Administratoren und besonders schützenswerte Benutzer sollten phishing-resistente Methoden wie Passkeys, Windows Hello for Business oder FIDO2-Sicherheitsschlüssel eingesetzt werden.

Eine Push-Nachricht auf dem Smartphone ist besser als nur ein Passwort. Ein Verfahren, das sich nicht einfach auf einer gefälschten Seite bestätigen lässt, ist noch besser.

4. Veraltete Authentifizierungswege schließen

Legacy Authentication, ROPC und nicht mehr benötigte Gerätecode- oder Übertragungsflüsse sollten identifiziert und nach Möglichkeit blockiert werden.

Wo alte Anwendungen diese Verfahren noch benötigen, braucht es einen klaren Migrationsplan statt einer zeitlich unbegrenzten Ausnahme.

5. Administrative Rechte begrenzen

Administratoren sollten getrennte Konten für normale Arbeit und administrative Aufgaben verwenden. Hochprivilegierte Rollen sollten möglichst nur bei Bedarf und zeitlich begrenzt aktiviert werden.

Dauerhaft globale Administratorrechte zu verteilen, weil jemand „manchmal etwas einstellen muss“, ist ungefähr so angemessen wie ein Generalschlüssel für alle, die gelegentlich den Besprechungsraum buchen.

6. Hybride Identitätsserver besonders schützen

Domänencontroller, AD-FS-Systeme, Zertifikatsdienste und Entra-Connect-Server gehören zu den sensibelsten Komponenten der gesamten Umgebung.

Sie benötigen konsequentes Patchmanagement, eingeschränkte administrative Zugriffe, Überwachung und eine klare Notfallstrategie.

7. Identity Protection und Monitoring aktiv nutzen

Risikobasierte Conditional-Access-Richtlinien, Entra-Anmeldeprotokolle, Microsoft Defender for Identity und Defender XDR helfen dabei, ungewöhnliches Verhalten zu erkennen und Angriffe über lokale, hybride und Cloud-Identitäten hinweg zu untersuchen.

Wichtig ist, dass jemand die Warnungen bewertet und auf sie reagiert. Ein Dashboard ist noch kein Security Operations Center.

8. KI-Agenten wie neue Mitarbeiter behandeln

Jeder Agent sollte eine definierte Aufgabe, einen Verantwortlichen, begrenzte Berechtigungen und einen dokumentierten Lebenszyklus erhalten.

Vor der produktiven Einführung muss klar sein:

• Welche Daten darf der Agent sehen?
• Welche Aktionen darf er ausführen?
• Wo braucht er eine menschliche Freigabe?
• Wie werden seine Entscheidungen protokolliert?
• Wie kann sein Zugriff sofort beendet werden?

Der Agent braucht kein Onboarding-Frühstück. Ein ordentliches Berechtigungskonzept wäre aber nett.

9. Notfallzugänge vorbereiten und testen

Unternehmen benötigen sichere, cloudbasierte Notfallkonten, die unabhängig vom normalen Betrieb funktionieren. Diese Konten dürfen nicht für tägliche Aufgaben genutzt werden und sollten regelmäßig getestet werden.

Ein Break-Glass-Konto, dessen Passwort niemand kennt, ist hauptsächlich dekorativ.

10. Konfigurationen regelmäßig überprüfen

Conditional-Access-Regeln, Rollenzuweisungen, Vertrauensstellungen und Authentifizierungsmethoden verändern sich laufend.

Darum sollten Unternehmen nicht nur einzelne Sicherheitsmaßnahmen einführen, sondern ihre Microsoft-Tenant-Konfiguration kontinuierlich überwachen und Änderungen nachvollziehbar dokumentieren.

Nur so lässt sich erkennen, ob der tatsächliche Zustand noch dem geplanten Sicherheitskonzept entspricht.

Fazit: Der Angriff beginnt heute mit einer Anmeldung

Der klassische Hackerangriff auf die Cloud sieht unspektakulär aus.

Keine dramatische Explosion. Kein Totenkopf auf dem Bildschirm. Kein Kapuzenpullover, der im Großraumbüro negativ auffallen würde.

Stattdessen meldet sich jemand an.

Mit einem erratenen Passwort. Über einen vergessenen Authentifizierungsweg. Mit einem gestohlenen Token. Mit einer gefälschten SAML-Identität. Oder künftig vielleicht über einen kompromittierten Agenten, dessen Berechtigungen nie sauber begrenzt wurden.

Deshalb muss Identitätssicherheit heute mehr leisten als Benutzerverwaltung.

Sie muss sicherstellen, dass jede menschliche und nichtmenschliche Identität eindeutig bekannt ist, nur die notwendigen Rechte besitzt, unter den richtigen Bedingungen zugreifen darf und bei ungewöhnlichem Verhalten sofort auffällt.

Die gute Nachricht: Die passenden Schutzmechanismen sind in Microsoft-Umgebungen grundsätzlich vorhanden.

Die Herausforderung besteht darin, sie zu konfigurieren, konsequent zu betreiben und regelmäßig zu überprüfen.

So wird Cloud-Sicherheit zu einem beherrschbaren Prozess: klar geregelt, einfach überprüfbar und persönlich betreut.