Windows Event-ID 4625: fehlgeschlagene Anmeldungen lesen

Was 4625 ist

Ereignis-ID 4625 — „Fehler beim Anmelden eines Kontos" — wird bei jedem abgelehnten Authentifizierungsversuch ins Windows-Sicherheitsprotokoll geschrieben, aus welchem Grund auch immer: falsches Passwort, nicht existierendes Konto, deaktiviertes Konto, Anmeldung außerhalb erlaubter Zeiten. Das erfolgreiche Gegenstück ist 4624.

Es ist das nützlichste Ereignis auf einem Windows-Server im Internet, weil hier ein Brute-Force-Angriff sichtbar wird, bevor er Erfolg hat. Alles, was eine Abwehr auf Firewall-Ebene tut, beginnt mit dem Lesen dieses Stroms.

Sehen Sie auf einem nachweislich erreichbaren Server gar keine 4625-Ereignisse, ist die Überwachung aus und nicht der Server ruhig. Prüfen und aktivieren:

auditpol /get /subcategory:"Logon"
auditpol /set /subcategory:"Logon" /success:enable /failure:enable

Die Felder, auf die es ankommt

Ein 4625-Eintrag ist wortreich und größtenteils Rauschen. Fünf Felder tragen die Information:

• Kontoname (unter „Konto, für das die Anmeldung fehlgeschlagen ist") — der versuchte Benutzername. Bei einem echten Angriff ist das eine Parade von Namen, die es auf Ihrer Maschine nie gab.
• Quellnetzwerkadresse — die IP, von der der Versuch kam. Auf dieses Feld handeln Sie. Bei lokalen Konsolenanmeldungen ist es leer.
• Anmeldetyp — wie angemeldet wurde. 10 ist RemoteInteractive (RDP), 3 ist Netzwerk (SMB oder RDP hinter manchen Gateways), 2 ist die physische Konsole, 5 ein Dienst, 4 eine geplante Aufgabe.
• Fehlerursache und Status / Unterstatus — der hexadezimale Code, der erklärt, was falsch war. Hier liegt die nützliche Unterscheidung.
• Arbeitsstationsname — der vom Client gemeldete Hostname. Angriffswerkzeuge senden oft Müll, eine Zufallszeichenkette, oder lassen das Feld leer, was selbst ein Signal ist.

Statuscodes entschlüsselt

Zu lesen ist das Feld Unterstatus; der übergeordnete Status enthält meist das generische 0xC000006D. Lernen Sie diese fünf und Sie klassifizieren fast jedes 4625 auf einen Blick:

• 0xC0000064 — der Kontoname existiert nicht. Fast immer ein Angriff: Ihre eigenen Nutzer kennen ihre Benutzernamen.
• 0xC000006A — das Konto existiert, das Passwort war falsch. Entweder ein echter Nutzer mit Tippfehler oder ein Bot, der einen gültigen Namen erraten hat.
• 0xC0000234 — das Konto ist gesperrt. Kommen davon Serien, wird Ihre Sperrrichtlinie gegen Sie verwendet.
• 0xC0000072 — das Konto ist deaktiviert. Häufig ein vergessenes Konto, das ein Angreifer gefunden hat und weiter probiert.
• 0xC000006F / 0xC0000070 — Anmeldung außerhalb erlaubter Zeiten oder von einer nicht zugelassenen Arbeitsstation. Selten, und eher zu untersuchen als zu ignorieren.

Angriff von Tippfehler unterscheiden

Drei Signale trennen sie, und vor einer automatischen Reaktion wollen Sie alle drei.

Rate und Ausdauer. Ein Mensch macht zwei bis drei Versuche innerhalb einer Minute und ruft dann entweder Sie an oder kommt rein. Ein Bot hält stundenlang eine konstante Rate, die ganze Nacht, ohne Pause und ohne jemanden anzurufen.

Kontovielfalt. Ein Mensch probiert ein Konto: sein eigenes. Ein Bot arbeitet eine Liste ab — administrator, admin, user, test, sql, backup, scan — und die meisten dieser Konten existieren auf Ihrer Maschine nicht, was genau die 0xC0000064-Signatur von oben ergibt.

Quelle. Ihre Leute melden sich von einer Handvoll bekannter Adressen an. Angriffe kommen aus Hosting-Bereichen, alle paar hundert Versuche von einer anderen Adresse, oft aus mehreren Ländern in derselben Stunde.

Das gruppiert die Fehlschläge des letzten Tages nach Quelladresse und Konto, sodass alle drei auf einmal sichtbar sind:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddDays(-1)} |
  ForEach-Object {
    $d = ([xml]$_.ToXml()).Event.EventData.Data
    [pscustomobject]@{
      IP      = ($d | Where-Object Name -eq 'IpAddress')['#text']
      Account = ($d | Where-Object Name -eq 'TargetUserName')['#text']
      Status  = ($d | Where-Object Name -eq 'SubStatus')['#text']
    }
  } |
  Group-Object IP |
  Sort-Object Count -Descending |
  Select-Object -First 15 Count, Name,
    @{n='Accounts'; e={ ($_.Group.Account | Select-Object -Unique) -join ', ' }}

Vom Lesen der Ereignisse zum Blockieren

4625 von Hand zu lesen ist Diagnose, keine Abwehr — wenn Sie die Abfrage ausführen, läuft der Angriff schon eine Woche. Etwas ändert erst, wer das laufend tut und einen Schwellwert in eine Firewall-Regel übersetzt.

Die naive Variante abonniert das Sicherheitsprotokoll, zählt Fehlschläge pro Quelle und ruft New-NetFirewallRule auf, sobald eine Quelle die Grenze überschreitet. Das funktioniert — und läuft dann in dieselben Probleme wie jedes solche Skript: Der Regelsatz wächst in die Tausende und die Firewall kriecht, das Protokoll rotiert unter Last und Ereignisse gehen verloren, das Skript stirbt nach einem Neustart still, und ein Fehltreffer sperrt den Administrator vom einzigen Zugang aus.

RDP Protector führt diese Schleife als Dienst aus, mit einer zusammengefassten Firewall-Regel statt tausender, einer Whitelist, die jede Sperre schlägt, und einer lokal getroffenen Entscheidung — sie hält also, wenn das Netz nicht hält. Er liest denselben Ereignisstrom, der oben gezeigt wird; nichts bleibt Ihnen verborgen.