Keine Kontosperren bedeutet nicht keine Angriffsversuche

Der Helpdesk meldet keine Auffälligkeiten. Auf einzelnen Benutzerkonten stehen nur wenige fehlgeschlagene Anmeldungen. Erst die gemeinsame Sicht zeigt, dass dieselbe Quelle innerhalb eines Zeitraums zahlreiche unterschiedliche Konten erreicht hat. Eine Überwachung, die ausschließlich gesperrte Konten zählt, übersieht dieses Muster.

Password Spraying verteilt Versuche mit wenigen häufigen Kennwörtern über viele Identitäten. Für die Abwehr ist deshalb die Beziehung zwischen Konten, Quellen, Anmeldewegen und Zeit entscheidend. Ein sinnvoller Account Lockout bleibt Teil der Baseline; er liefert allein weder vollständige Erkennung noch verlässliche Prävention.

Der Scope umfasst lokale AD-Anmeldungen und Dienste, die Domänenkennwörter prüfen: etwa VPN, RD Gateway, Webanwendungen oder föderierte Zugänge. Bei hybriden Umgebungen muss zusätzlich geklärt werden, ob ein Cloud-Dienst selbst authentifiziert oder die Prüfung an lokale Komponenten weiterreicht. Nicht jeder Cloud-Fehler taucht im Security-Log eines DCs auf.

Zielbild: Anmeldewege abdecken und Befunde zuordnen

Für jeden relevanten Zugang werden Protokoll, Identitätsquelle, verantwortliches Team, Schutzmaßnahmen und verfügbare Protokolle dokumentiert. Die Abnahme verlangt drei nachvollziehbare Ergebnisse:

  • Fehlversuche über mehrere Konten lassen sich zentral zusammenführen, ohne weitergeleitete Duplikate mehrfach zu zählen.
  • Ein Alarm benennt betroffene Identitäten, Zeitraum, Anmeldeweg und die Aussagekraft der ermittelten Quelle.
  • Das Betriebsteam kann verdächtige Aktivität untersuchen und gezielt begrenzen; Zuständigkeit und Eskalationsweg sind vorab festgelegt.

Zusätzlich wird sichtbar, wenn eine Ereignisquelle ausfällt. Ein stilles Dashboard bei unterbrochener Weiterleitung ist kein Sicherheitsnachweis.

Zuerst die richtige Telemetrie einschalten

Die erweiterten Überwachungsrichtlinien liegen unter Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Erweiterte Überwachungsrichtlinienkonfiguration > Überwachungsrichtlinien. Die englischen Namen helfen bei unterschiedlichen Verwaltungssprachen.

Auf den zuständigen DCs werden Audit Kerberos Authentication Service und Audit Credential Validation für Erfolg und Fehler benötigt. Audit User Account Management mit Erfolgsüberwachung ergänzt Kontosperren. Auf relevanten Zielsystemen gehört Audit Logon für Erfolg und Fehler dazu. Die Einstellung Audit: Force audit policy subcategory settings ... to override audit policy category settings verhindert, dass ältere Kategorieeinstellungen die geplanten Unterkategorien übersteuern; auch ihre effektive Anwendung muss geprüft werden.

Richtlinien zunächst in einem definierten Pilotbereich ausrollen. Danach alle relevanten DCs, Zielsysteme und vorgeschalteten Dienste in die Sammlung aufnehmen. Security-Log-Größe, Weiterleitungsverzögerung, Zeitsynchronisation und Aufbewahrung müssen das erwartete Volumen tragen. Zugriff auf Kontonamen, Quelladressen und Anmeldehistorien nur den zuständigen Rollen geben; Kennwörter werden nicht gesammelt.

Die effektive lokale Audit-Konfiguration lässt sich in einer administrativen Sitzung lesend prüfen:

auditpol.exe /get /category:*

Ein GPO-Bericht und die wirksame lokale Einstellung sollten zusammenpassen. Anschließend muss ein kontrolliertes Testereignis tatsächlich im zentralen System ankommen. Eine konfigurierte Richtlinie beweist noch keine funktionierende Sammlung.

Ereignisse nach Protokoll und Fehlerursache auswerten

Vier Ereignisse liefern unterschiedliche Teile des Bilds:

  • 4771 auf dem DC: Kerberos-Preauthentication ist fehlgeschlagen. Fehlercode 0x18 passt zu einem falschen Kennwort. Andere Fehlercodes dürfen nicht pauschal als Kennwortraten gezählt werden. Die Clientadresse hilft bei der Quellenzuordnung.
  • 4776 auf der prüfenden Instanz: NTLM-Anmeldeinformationen wurden validiert. Für Domänenkonten ist diese Instanz ein DC. Status 0xC000006A bezeichnet ein falsches Kennwort; 0x0 eine erfolgreiche Validierung. Das Ereignis enthält einen Quellworkstation-Namen, aber keine direkte Quell-IP oder Angabe des Zielservers.
  • 4625 auf dem Anmeldeziel: Eine Anmeldung ist fehlgeschlagen. Anmeldetyp, Authentifizierungspaket, Status und Substatus liefern Kontext. Nicht jeder Fehler ist ein falsches Kennwort; Quellinformationen sind je nach Anmeldeweg unterschiedlich vollständig.
  • 4740: Ein Konto wurde gesperrt. Das Ereignis unterstützt die Untersuchung, ist aber keine Voraussetzung für einen Spray-Verdacht.

Ein Gateway oder Vermittlungsdienst kann aus Sicht des DCs die Quelle sein. Dessen Protokolle müssen den Bezug zur ursprünglichen Verbindung liefern. Workstation-Namen und IP-Adressen sind Hinweise, keine verlässlich eindeutigen Geräteidentitäten.

Für die Erfolgsprüfung ergänzen beispielsweise 4768 mit Result Code 0x0 die erfolgreiche Kerberos-TGT-Ausstellung und 4624 eine erfolgreiche Anmeldung auf dem Ziel. Die Event-ID 4768 allein ist kein Erfolgsnachweis. Eine erfolgreiche 4776-Validierung beweist noch keinen abgeschlossenen Zugriff auf eine Anwendung. Ebenso lässt sich aus normalen Windows-Ereignissen nicht ablesen, welches Kennwort eingegeben wurde. Die Erkennung liefert einen begründeten Spray-Verdacht, keinen Beweis für die Wiederverwendung desselben geratenen Kennworts.

Kontenübergreifende Korrelation praktisch aufbauen

Die Verarbeitung im SIEM lässt sich in überschaubare Schritte zerlegen:

  1. Ereignisse in gemeinsame Felder überführen: UTC-Zeit, Domäne beziehungsweise Identitätsraum, Konto, Protokoll, Ergebnis, Quellhinweis und Zielanwendung. UPN und DOMAIN\Benutzer sorgfältig zuordnen; verfügbare SIDs nutzen und gleichnamige Konten verschiedener Domänen getrennt halten.
  2. Kennwortfehler von anderen Ursachen trennen. Originalereignisse und weitergeleitete Kopien deduplizieren. Verschiedene Ereignisse desselben Anmeldevorgangs möglichst verknüpfen, damit eine Anmeldung nicht künstlich als mehrere Versuche erscheint.
  3. Pro Quelle und Anmeldeweg sowohl Fehlversuche als auch unterschiedliche betroffene Konten zählen. Kurze und längere Zeitfenster kombinieren. Zusätzlich konten- und dienstbezogene Muster über mehrere Quellen untersuchen, damit die Erkennung nicht an einer einzigen IP-Adresse hängt.
  4. Schwellen anhand repräsentativer Betriebsdaten festlegen. Ein gemeinsamer VPN-Ausgang, eine VDI-Farm und ein einzelner Client brauchen unterschiedliche Erwartungen. Es gibt keinen universell belastbaren Wert für „Konten pro Minute“.
  5. Alarmdaten mit nachfolgenden Erfolgen, privilegierten Konten sowie relevanten Endpoint- und Gateway-Befunden anreichern. Die Unsicherheit einer Quellenzuordnung ausdrücklich mitliefern.

Eine Regel zunächst beobachtend betreiben. Fehlalarme klassifizieren und eng begrenzte Ausnahmen mit Eigentümer und Ablaufdatum pflegen. Einen gesamten Proxy oder alle Dienstkonten auszublenden schafft einen blinden Bereich genau dort, wo viele Identitäten zusammenlaufen.

Angriffsfläche an den tatsächlichen Zugängen reduzieren

Kennwortlänge und Sperrlisten reduzieren die Wahrscheinlichkeit, dass häufige oder organisationsnahe Kennwörter funktionieren. Bei Microsoft Entra Password Protection für lokales AD wirkt die Prüfung bei Kennwortänderungen und Resets. Bestehende Kennwörter werden nicht nachträglich gescannt. Für konsistente Durchsetzung müssen alle DCs, die solche Änderungen verarbeiten, abgedeckt sein. Auditmodus, Pilot und anschließend Enforced-Modus sind getrennte Schritte; Agent- und Richtlinienzustand bleiben überwacht.

MFA gehört an jeden unterstützten Zugang, bevorzugt mit phishingresistenten Verfahren. Eine Conditional-Access-Richtlinie in Entra ID schützt nicht automatisch sämtliche lokalen Kerberos-, NTLM- oder LDAP-Anmeldungen. Unbenutzte Kennwortzugänge schließen, direkte Umgehungswege prüfen und privilegierte Identitäten aus normalen Benutzerzugängen heraushalten. Rate Limits an Gateways müssen gemeinsame Quellen berücksichtigen, damit ein einzelner auffälliger Client nicht die gesamte Belegschaft blockiert.

Entra Smart Lockout und AD-Kontosperren haben unterschiedliche Wirkungsbereiche. Bei Pass-through Authentication werden Cloud- und AD-Schwellen einschließlich ihrer Sperrdauer bewusst aufeinander abgestimmt. Dienstkonten erhalten keine pauschale Überwachungsausnahme; verwaltete Identitäten beziehungsweise gMSAs ersetzen statische Kennwörter dort, wo die Anwendung das unterstützt.

Reagieren, ohne selbst einen Anmeldeausfall auszulösen

Zuerst Rohereignisse, Quellenauflösung und betroffene Konten prüfen. Veraltete Zugangsdaten eines Dienstes können ein ähnliches Fehlerbild erzeugen. Eine verdächtige Verbindung am zuständigen Gateway begrenzen oder einen bestätigten kompromittierten Endpunkt isolieren, sobald Befund und Zuständigkeit das tragen. Ein aggregierter Fehlerzähler rechtfertigt keine automatische Sperrung aller betroffenen Benutzer.

Bereits ein bestätigter unberechtigter Kennworttreffer löst den Incident-Prozess aus, auch wenn MFA den anschließenden Zugriff verhindert. Betroffene Konten absichern, Kennwörter kontrolliert zurücksetzen, relevante Sitzungen und Tokens behandeln und mögliche Folgeaktivität untersuchen. Eine Kennwortkompromittierung und ein erfolgreicher Anwendungszugriff sind unterschiedliche Befunde. Ein Kennwortreset beendet nicht sofort jedes Kerberos-Ticket oder jede Anwendungssitzung. Abmeldung, Sperrung und Wiederfreigabe müssen zu den tatsächlich betroffenen Diensten passen.

Für den Pilotbetrieb gehören ein Abschaltweg für eine fehlerhafte automatische Reaktion und ein erreichbarer Verantwortlicher in den Betriebsplan. Die Ereignissammlung bleibt dabei bestehen.

Vorteile: frühere Signale und gezielte Reaktion

  • Kontenübergreifende Muster werden sichtbar, bevor zahlreiche Kontosperren auftreten müssen.
  • Die Bestandsaufnahme zeigt ungeschützte Anmeldewege und fehlende Protokollquellen.
  • Protokoll- und Quellenkontext hilft, gezielt einzugreifen und unnötige Sperren zu vermeiden.
  • Messwerte wie Erkennungsverzögerung, Quellenabdeckung und bearbeitete Fehlalarme machen den Betrieb überprüfbar.

Nachteile und Grenzen: Aufwand bleibt, Gewissheit fehlt

  • Zentrale Sammlung, Aufbewahrung und Untersuchung verursachen Speicher-, Lizenz- und Betriebsaufwand.
  • Gemeinsame Gateways, alte Dienstkennwörter und unvollständige Clientdaten erschweren die Unterscheidung zwischen Angriff und Betriebsfehler.
  • Langsame oder über viele Quellen verteilte Versuche können Regeln weiterhin entgehen. Gute Kennwortkontrollen und geschützte Zugänge bleiben erforderlich.
  • Ein Alarm beweist weder die verwendeten Kennwörter noch eine erfolgreiche Kompromittierung. Ein ausbleibender Alarm beweist keine Angriffsfreiheit.
  • Zu aggressive automatische Reaktionen können selbst eine Dienstunterbrechung auslösen. Reaktionsregeln brauchen gesonderte Tests und Freigabekriterien.

Abnahme mit synthetischen Ereignissen und einem Testkonto

Die Detektionslogik mit gekennzeichneten synthetischen Ereignissen in einer Testumgebung prüfen: Fehler über viele Konten, alte Zugangsdaten eines einzelnen Dienstes, eine gemeinsame Gateway-Adresse, ein Erfolg nach Fehlern und der Ausfall eines Collectors. Erwartete Alarme und bewusst nicht ausgelöste Alarme schriftlich festhalten.

Für den vollständigen Übertragungsweg reicht eine freigegebene, nicht privilegierte Testidentität mit kontrollierter Fehl- und Erfolgsanmeldung. Anzahl und Zeitpunkt vorab abstimmen und bestehende Sperrregeln respektieren. Produktive Benutzerkonten müssen dafür nicht mit geratenen Kennwörtern getestet werden. Die synthetische Prüfung bewertet die Korrelation; der kleine Funktionstest bewertet den Weg von der Quelle bis zur Anzeige.

Projekt-Checkliste für einen belastbaren Betrieb

  • Lokale, externe und hybride AD-Anmeldewege mit Verantwortlichen erfasst.
  • Protokolle, Prüfinstanzen und tatsächliche MFA-Wirkungsbereiche dokumentiert.
  • Audit-Unterkategorien auf DCs und Zielsystemen wirksam geprüft.
  • Relevante DC-, Zielsystem- und Gateway-Ereignisse zentral verfügbar.
  • Zeitabgleich, Aufbewahrung, Rollenrechte und Quellenüberwachung eingerichtet.
  • Kontonamen, Fehlercodes und Quellhinweise nachvollziehbar normalisiert.
  • Duplikate und mehrfach protokollierte Anmeldevorgänge berücksichtigt.
  • Unterschiedliche Konten, mehrere Zeitfenster und verteilte Quellen ausgewertet.
  • Erfolgreiche Validierung von tatsächlichem Anwendungszugriff unterschieden.
  • Ausnahmen eng begrenzt, befristet und einem Eigentümer zugewiesen.
  • Kennwortschutz, MFA und nicht benötigte Anmeldewege separat geprüft.
  • Reaktionsplan einschließlich Sitzungen, Tickets und Wiederfreigabe abgestimmt.
  • Synthetische Fälle und kontrollierter Funktionstest erfolgreich abgenommen.
  • Fehlalarme, Erkennungsverzögerung und Collector-Ausfälle regelmäßig nachgehalten.