AD badPwdCount Analyse: Zähler vor einem Angriffsurteil prüfen

Was die AD badPwdCount Analyse feststellen kann

Die AD badPwdCount Analyse beginnt mit einer Frage zur Beweislage: Welcher Domänencontroller hat den Zähler dieses Kontos geliefert, zu welchem Zeitpunkt, und war die Erfassung tatsächlich erfolgreich? Eine Verzeichnisaufnahme kann Konten identifizieren, die untersucht werden sollten. Für sich allein kann sie weder einen Wörterbuchangriff belegen noch die Quelle der Fehlversuche identifizieren oder zeigen, dass ein Passwort schwach ist.

Das praktische Ergebnis ist eine Prüfakte, die den Verzeichniszustand mit der Authentifizierungsaktivität verknüpft. Bewahren Sie den ursprünglichen Befund auf, erfassen Sie vergleichbare Ansichten der relevanten Domänencontroller, prüfen Sie den berechneten Sperrstatus und untersuchen Sie die Protokolle des betreffenden Authentifizierungswegs. Dokumentieren Sie anschließend, ob die Belege für einen Benutzerfehler, eine Anwendung mit wiederholten Versuchen mit einem veralteten Geheimnis, verdächtige Aktivität oder einen ungeklärten Fall sprechen.

Dieser Leitfaden verwendet defensive Verzeichnisabfragen und ein dokumentiertes Beispiel für eine gezielte Entsperrung. Die Befehle sind beispielhafte Anpassungen für einen autorisierten Administrator mit dem PowerShell-Modul ActiveDirectory und den entsprechenden Berechtigungen. Sie wurden nicht gegen eine Domäne ausgeführt. Es wurden weder Password Spraying noch absichtliche Kontosperrtests durchgeführt.

Was der LDAP-Zähler tatsächlich misst

Microsofts Referenz zu Sicherheitsattributen von Benutzern beschreibt badPwdCount als nicht repliziertes Attribut, das auf jedem Domänencontroller separat verwaltet wird. Es zählt Anmeldeversuche mit falschem Passwort aus Sicht dieses Controllers; laut Referenz kann null auch einen unbekannten Wert bedeuten. Für eine domänenweite Ansicht empfiehlt sie, jeden DC abzufragen, statt eine einzelne Abfrage als Gesamtsumme der Domäne zu behandeln.

Die Schemareferenz zu Bad-Pwd-Count ergänzt, dass das Attribut auf einem bestimmten DC zurückgesetzt wird, wenn sich der Benutzer erfolgreich an diesem DC anmeldet. Ein Zähler ist somit kein dauerhaftes Verlaufsprotokoll. Ein niedrigerer Wert in einer späteren Aufnahme belegt nicht, dass alle früheren Fehlversuche untersucht wurden.

Bewahren Sie für die Analyse die einzelnen DC-Beobachtungen auf, bevor Sie eine Zusammenfassung erstellen. Eine Zahl ohne Server und Erfassungszeit verliert den Kontext, der für den Vergleich mit einer anderen Beobachtung nötig ist. Auch eine Zusammenfassung der Zähler identifiziert keine einzelnen Versuche innerhalb eines gewählten Zeitintervalls; erstellen Sie diese Zeitleiste anhand von Ereignisdatensätzen.

Die Kontosperre ist eine separate Frage. Microsoft dokumentiert UF_LOCKOUT mit dem Wert 0x0010 in msDS-User-Account-Control-Computed. Fordern Sie dieses berechnete Attribut ausdrücklich an, wenn Sie den aktuellen AD-DS-Zustand prüfen. Gehen Sie nicht davon aus, dass ein Collector-Boolean namens LockedOut zwingend daraus stammt.

Erkennung: Vergleichbare Ansichten von jedem DC erfassen

Konto und Erfassungsumfang identifizieren

Beginnen Sie mit der Kontokennung des Befunds und dem ursprünglichen Collector-Endpunkt. Dokumentieren Sie Domäne, Konto-DN oder GUID, Collector-Version, Erfassungszeit, angeforderte Attribute und sämtliche Erfassungsfehler. Gleichen Sie die DC-Liste mit dem Domäneninventar ab; das folgende Beispiel mit zwei Servern ist keine Anweisung, weitere DCs auszulassen.

Die Dokumentation zu Get-ADUser unterstützt die Auswahl eines Benutzers per DN, die Anforderung zusätzlicher Eigenschaften und die Angabe eines Verzeichnisservers. Diese angepassten Abfragen verwenden einen expliziten DC-Hostnamen, statt sich auf die automatische Serverauswahl zu verlassen:

Get-ADUser -Identity 'CN=Alex Smith,OU=Users,DC=contoso,DC=com' -Server 'dc01.contoso.com' -Properties badPwdCount,userAccountControl,msDS-User-Account-Control-Computed,lockoutTime -ErrorAction Stop

Get-ADUser -Identity 'CN=Alex Smith,OU=Users,DC=contoso,DC=com' -Server 'dc02.contoso.com' -Properties badPwdCount,userAccountControl,msDS-User-Account-Control-Computed,lockoutTime -ErrorAction Stop

Ersetzen Sie den beispielhaften DN und die Hostnamen durch verifizierte Werte. Die Anforderung von lockoutTime bewahrt ein weiteres Rohattribut für die Prüfung; verwenden Sie einen von null verschiedenen Wert nicht allein als Urteil über eine aktuelle Sperre. Interpretieren Sie das berechnete Sperrbit nur, wenn sein Wert erfolgreich zurückgegeben wurde. Ein fehlender Wert ist unbekannt, nicht falsch.

Für eine umfassendere, autorisierte Bestandsaufnahme akzeptiert Get-ADUser auch einen LDAP-Filter. Dieses Beispiel ruft aktivierte Benutzerobjekte und die relevanten Attribute von einem ausdrücklich ausgewählten Server ab. Es beschränkt die Auswahl bewusst nicht auf Konten, die bereits über dem Produktschwellenwert liegen:

Get-ADUser -LDAPFilter '(&(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))' -Server 'dc01.contoso.com' -Properties badPwdCount,userAccountControl,msDS-User-Account-Control-Computed,lockoutTime -ErrorAction Stop

Wiederholen Sie die Abfrage gegen die anderen verifizierten DCs innerhalb des genehmigten Umfangs. Erstellen Sie keinen LDAP-Filter durch Verkettung eines nicht maskierten Kontonamens. Für einen einzelnen Fall vermeiden die identitätsbasierten Abfragen diese Interpolation vollständig.

Erfassungsqualität zusammen mit den Werten aufbewahren

Verwenden Sie eine Aufzeichnung mit einer Zeile pro Konto und DC. Die folgenden Felder sind eine betriebliche Empfehlung und keine Ausgabe, die der Detektor automatisch liefert:

Ist ein DC nicht verfügbar, melden Sie die Lücke und bewahren Sie die erfolgreichen Abfragen auf. Ersetzen Sie die fehlende Zeile nicht durch null und reduzieren Sie den angegebenen Umfang nicht stillschweigend. Unterscheiden sich die Beobachtungen, bewahren Sie beide auf und untersuchen Sie Zeitpunkt und Herkunft, bevor Sie eine Zusammenfassung wählen. Ziel ist ein prüfbarer Vergleich, nicht ein identisches Erscheinungsbild aller Zellen.

Erkennung: Ereignisse dem Authentifizierungsweg zuordnen

Die LDAP-Aufnahme wählt ein Untersuchungsziel aus; die Ereigniszeitleiste liefert den Aktivitätskontext. Prüfen Sie Audit-Abdeckung, Weiterleitung, Aufbewahrung und die durchsuchten Systeme, bevor Sie ein leeres Ergebnis interpretieren. Wählen Sie das Prüfintervall anhand der Fallzeitleiste und der verfügbaren Belege. Der Zähler selbst liefert dieses Intervall nicht.

Microsoft ordnet diese Ereignisse jeweils Audit Logon/Account Lockout, Audit Kerberos Authentication Service und Audit Credential Validation zu. Eine Suche ausschließlich auf DCs deckt nicht alle Orte für 4625 ab. Ereignis 4771 fehlt bei Konten, für die keine Kerberos-Präauthentifizierung erforderlich ist. Ereignis 4776 erfasst erfolgreiche und fehlgeschlagene Prüfungen und identifiziert die Quell-Workstation statt des Zielservers oder einer IP-Adresse.

Lesen Sie die für das jeweilige Ereignis geltenden Codes. Bewahren Sie bei 4625 beide Statusfelder auf, statt sie zu einer allgemeinen Fehlerbezeichnung zusammenzufassen. In 4771 bedeutet 0x18 ungültige Präauthentifizierungsinformationen; ein falsches Passwort ist als Ursache dokumentiert. In 4776 bezeichnet 0xC000006A ein falsches oder falsch eingegebenes Passwort, 0xC0000064 einen unbekannten Benutzernamen und 0xC0000234 ein gesperrtes Konto. Ein durch eine Sperre verursachter Fehler ist ein anderer Beleg als die vorausgegangene Aktivität mit falschem Passwort.

Erstellen Sie eine Zeitleiste, gruppiert nach Konto, Quelle, Authentifizierungsweg und ausgebendem System. Bewahren Sie Verweise auf die Originaldatensätze auf, damit ein anderer Analyst die Schlussfolgerung prüfen kann. Addieren Sie nicht jede Zeile verschiedener Ereignistypen zu einer behaupteten Anzahl unabhängiger Rateversuche: Stellen Sie zuerst fest, welche Datensätze denselben Authentifizierungsvorgang beschreiben.

Erweitern Sie die Untersuchung über das ausgewählte Konto hinaus, wenn Quellen oder Zeitpunkte dies rechtfertigen. Der Kontext zur kontenübergreifenden Korrelation langsamer, verteilter Versuche in unserem Password-Spraying-Leitfaden erläutert diese breitere Untersuchung. Hier bleibt die erste Aufgabe, die Verzeichnisbeobachtung zu qualifizieren, die den Fall eröffnet hat.

Behebung: Die Ursache klären, bevor der Befund geschlossen wird (Remediation)

Belege sichern und konkurrierende Erklärungen prüfen

Bewahren Sie die ursprünglichen LDAP-Werte und relevanten Ereignisdatensätze auf, bevor Sie Anmeldeinformationen oder Kontozustand ändern. Identifizieren Sie den Kontoverantwortlichen und die Anwendungen, die das Konto verwenden. Fragen Sie nach kürzlichen Passwortänderungen, Änderungen der Dienstkonfiguration, geplanten Aufgaben, Fernzugriff und den vom Benutzer gemeldeten Erfahrungen. Nutzen Sie diese Antworten, um die zu prüfenden Systeme auszuwählen, nicht als Ersatz für deren Protokolle.

Die folgende Entscheidungsmatrix ist eine vorgeschlagene Analysemethode. Keine dieser Erklärungen wird allein aus badPwdCount berechnet:

Bei einem Workload mit veralteten Anmeldeinformationen koordinieren Sie die Änderung der Anmeldeinformationen mit allen bekannten Verbrauchern. Nur eine geplante Aufgabe zu aktualisieren und einen weiteren wiederholt zugreifenden Client ungeklärt zu lassen, ist keine vollständige Behebung. Prüfen Sie die eigene Konfiguration des Workloads und die nachfolgenden Authentifizierungsdatensätze, bevor Sie ihm die Fehlversuche abschließend zuordnen.

Behandeln Sie ungewöhnliche Namen als anderes Signal. Unsere Prüfung von Kontonamen unterscheidet einen statischen Namensindikator von Anmeldeaktivität. Ein generischer Kontoname belegt weder, welches Passwort versucht wurde, noch wer es übermittelt hat oder ob dieser Fall bösartig ist.

Bei Bedarf nur das geprüfte Konto entsperren

Wenn der berechnete Zustand eine Sperre bestätigt und der zuständige Administrator nach Prüfung der Ursache die Wiederherstellung des Zugriffs genehmigt hat, verwenden Sie eine gezielte Operation. Dieses Beispiel passt die für Unlock-ADAccount dokumentierten Identitäts- und Serverparameter an:

Unlock-ADAccount -Identity 'CN=Alex Smith,OU=Users,DC=contoso,DC=com' -Server 'dc01.contoso.com' -Confirm

Dies ist ein Beispiel für eine Zustandsänderung und kein für diesen Artikel ausgeführter Befehl. Bestätigen Sie Identität und Server vor der Verwendung. Leiten Sie nicht das gesamte Inventar per Pipeline in eine Massenentsperrung. Eine Entsperrung korrigiert weder ein veraltetes Anwendungsgeheimnis noch klärt sie verdächtige Aktivität; wählen Sie anhand der Belege die geeignete Reaktion.

Wenn die Untersuchung eine Kompromittierung oder eine fortbestehende Bedrohung feststellt, folgen Sie dem Incident-Response-Verfahren der Organisation für Eindämmung, Änderungen von Anmeldeinformationen und betroffene Systeme. Ein Verzeichniszähler reicht nicht aus, um diese Maßnahmen automatisch auszuwählen. Lockern Sie ebenso wenig Sperrkontrollen allein zur Verringerung von Befunden, ohne die Folgen für Sicherheit und Verfügbarkeit zu prüfen.

Korrektur überprüfen und Schlussfolgerung dokumentieren

Wiederholen Sie nach der genehmigten Änderung dieselben Verzeichnisabfragen mit derselben Kontoidentität und expliziten DCs. Bewahren Sie erneut Zeitstempel und Erfassungsqualität auf. Prüfen Sie die relevanten Protokolle über einen angegebenen Beobachtungszeitraum und lassen Sie den Verantwortlichen bestätigen, dass die betroffene Anwendung oder der Benutzerablauf erwartungsgemäß funktioniert.

Schließen Sie den Fall mit einer belegten Aussage: Eine identifizierte Anwendung mit Wiederholungsversuchen wurde korrigiert; ein Benutzerzugriffsproblem wurde behoben; Aktivität wurde als verdächtig eskaliert; oder die Abdeckung bleibt unvollständig. Dokumentieren Sie die unterstützenden Ereignisverweise, ausgeschlossenen Erklärungen, fehlenden Belege, Maßnahmen, Verantwortlichen und den Termin zur Nachverfolgung. Ein unterschrittener Produktschwellenwert ist nützlicher Kontext, doch der Abschluss sollte die Ursache und die Belege für die Entscheidung erklären.

Wie EtcSec dies erkennt

Die Prüfung des etc-collector heißt PASSWORD_DICT_ATTACK_RISK, Kategorie Password, Schweregrad Medium. Die geprüfte Detect()-Implementierung befindet sich in public/internal/audit/detectors/ad/password/dict-attack-risk.go:24. Sie schließt Benutzer mit Disabled=true aus und wählt jeden verbleibenden Benutzer aus, wenn BadPasswordCount > 3 oder LockedOut=true.

Count ist die Anzahl ausgewählter Benutzer, nicht die Summe fehlgeschlagener Versuche, die Anzahl der Quellsysteme oder die Anzahl der Angriffe. Jeder Benutzer zählt einmal, auch wenn beide Bedingungen zutreffen. Die Implementierung gibt den Befund auch bei null zurück; betroffene Entitäten werden aufgenommen, wenn Details angefordert werden und mindestens ein Benutzer ausgewählt ist.

Der Provider bestimmt, was die Prüfung tatsächlich sehen kann:

• parser.go:164 liest badPwdCount über getIntAttr; diese Hilfsfunktion in Zeile 290 gibt bei fehlendem Wert null zurück und ignoriert Fehler von strconv.Atoi.
• client.go:460 ruft Benutzer aus dem ausgewählten LDAP-Kontext ab. Dieser Pfad aggregiert keine Beobachtungen aller DCs.
• parser.go:189 leitet LockedOut aus dem Bit 0x0010 in userAccountControl ab. Die Standardliste der Benutzerattribute fordert msDS-User-Account-Control-Computed nicht an. Obwohl lockoutTime erfasst wird, dient es nicht zur Berechnung dieses Booleans.

Dieser Sperrzweig darf daher für modernes AD DS nicht als zuverlässige berechnete Bewertung einer aktuellen Sperre dargestellt werden. Fordern Sie das berechnete Attribut bei der Analyse des Befunds unabhängig an. Bewahren Sie eine Abweichung zwischen dem Collector-Boolean und dieser Abfrage auf, statt die Bezeichnung des Collectors als maßgeblich zu behandeln.

Die Prüfung enthält weder Zeitfenster noch Authentifizierungsquelle, Ereigniskorrelation, Bewertung der effektiven Sperrrichtlinie oder Messung der Passwortqualität. Der Schwellenwert ist ein Produktprädikat, kein AD-DS-Richtlinienwert. Drei oder weniger erfasste Fehlversuche belegen keine Sicherheit, und eine positive Anzahl belegt keinen Angriff.

Es gibt einen konkreten Grund, Zähler zu untersuchen, ohne ihre Ursache vorauszusetzen. Das öffentliche SafeSpray-Repository und dessen main.go-Quellcode verwenden einen LDAP-Filter mit badPwdCount=0, um Benutzer vor SMB-Authentifizierungsversuchen auszuwählen. Dies belegt, wie ein öffentliches Tool Zähler verwendet, nicht, dass es in Ihrer Umgebung ausgeführt wurde oder dass seine Aussage zur Sperrvermeidung zuverlässig ist. Der Code wurde gelesen; das Tool wurde nicht ausgeführt.