Password Spraying erkennen: viele Konten, eine Quelle

Password Spraying erkennen ist die Erkennung, die am häufigsten den Anfang eines Vorfalls sieht: Bevor ein Angreifer im Netz ist, braucht er ein Konto, und bevor er ein Konto phisht, probiert er, ob „Sommer2026!“ irgendwo funktioniert. Die Technik ist alt, sie funktioniert weiter, und sie hinterlässt ein Muster, das sich mit einer einzigen Zählung finden lässt. Dieser Beitrag beschreibt, wie Spraying abläuft und warum es Kontosperren umgeht, welche Logquellen es zeigen, vom Domain Controller bis zum Cloud-Anmeldeprotokoll, das Muster, eine Korrelationsregel in Sigma, den Test und die Fehlalarme, die bei dieser Technik fast immer von der eigenen Infrastruktur kommen.

Was der Angreifer tut

Brute Force probiert viele Passwörter gegen ein Konto und löst nach wenigen Versuchen die Kontosperre aus. Spraying dreht das um: ein Passwort gegen alle Konten, dann eine Pause, die länger ist als das Beobachtungsfenster der Sperrrichtlinie, dann das nächste Passwort. Bei einer Richtlinie von fünf Fehlversuchen in 30 Minuten kann ein Angreifer alle 30 Minuten ein neues Passwort gegen tausend Konten testen, ohne eine einzige Sperre auszulösen. Die Kontenliste kommt aus LinkedIn und dem Namensschema der Firma, aus OSINT oder aus einer früheren Aufzählung, die Passwörter aus Jahreszeit und Jahr, Firmenname und Ziffer, und den üblichen Verdächtigen. Ziele sind alles, was von außen Anmeldungen annimmt: Microsoft 365 und andere Cloud-Anmeldeseiten, VPN-Gateways, Outlook Web Access, Citrix, RDP-Gateways, und intern der Domain Controller, sobald der Angreifer einen Fuß im Netz hat. In ATT&CK ist die Technik T1110.003 unter Credential Access; die Detection Strategy nennt genau die Zählung, um die es hier geht.

Welche Logquellen die Technik zeigen

Welche dieser Quellen im SIEM sind, entscheidet, welches Spraying gesehen wird: Ohne die Cloud-Anmeldeprotokolle bleibt der häufigste Fall unsichtbar, ohne das VPN-Log der zweithäufigste. Die Domain Controller sehen nur, was intern oder über durchgereichte Authentifizierung bei ihnen ankommt, und die Details zu den Ereignissen stehen in der Referenz zu den Event-IDs.

Das Muster im Log

Ein einzelner Benutzer, der sein Passwort vergessen hat, erzeugt viele Fehlschläge für ein Konto. Spraying erzeugt wenige Fehlschläge für viele Konten, und genau diese Umkehrung ist die Erkennung: Zähle pro Quelladresse die Anzahl der verschiedenen Zielkonten mit Fehlschlag in einem Zeitfenster, und alles über einer Schwelle, die in der eigenen Umgebung nie legitim erreicht wird, ist Spraying. Die Schwelle liegt bei kleinen Organisationen bei zehn Konten in zehn Minuten, bei großen bei zwanzig oder mehr; die Verteilung der letzten 30 Tage zeigt, wo normal aufhört. Vier Verfeinerungen machen die Regel besser. Erstens der Fehlercode: Eine Serie mit 0xC0000064, also nicht existierenden Konten, zeigt, dass der Angreifer rät, und ist für sich verdächtig. Zweitens die Zeit: Spraying-Wellen liegen oft außerhalb der Arbeitszeit und wiederholen sich im Abstand der Sperrrichtlinie; wer die Abstände zwischen den Wellen misst, sieht die Richtlinie des eigenen Unternehmens im Verhalten des Angreifers. Drittens die Quelle: Adressen aus Cloud-Anbietern, Tor-Ausgängen oder Ländern ohne Geschäftsbezug, und bei Cloud-Spraying der Wechsel der Adresse alle paar Minuten, weil der Angreifer Proxys rotiert. Viertens, und das ist die Regel, die zählt: eine erfolgreiche Anmeldung von einer Quelle, die kurz vorher in der Fehlschlag-Serie war. Das ist der kompromittierte Zugang, und dieser Alarm hat Stufe kritisch.

Die Sigma-Regel

Zwei Korrelationen auf derselben Basis: die Serie und der Erfolg nach der Serie. Die Basisregel deckt 4625 und 4771 zusammen ab.

title: Failed Logon (NTLM or Kerberos)
name: failed_logon_any
logsource:
  product: windows
  service: security
detection:
  selection_ntlm:
    EventID: 4625
  selection_krb:
    EventID: 4771
    Status: '0x18'
  condition: 1 of selection_*
---
title: Successful Logon
name: successful_logon
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
    LogonType:
      - 3
      - 10
  condition: selection
---
title: Password Spraying - Many Accounts From One Source
id: 6c4a2e8d-1b9f-4d3a-8e7c-5f2b0a1d9c8e
status: test
tags:
  - attack.credential_access
  - attack.t1110.003
correlation:
  type: value_count
  rules:
    - failed_logon_any
  group-by:
    - IpAddress
  timespan: 10m
  condition:
    field: TargetUserName
    gte: 15
level: high
---
title: Password Spraying - Success After Spray
id: 2f9e7b3c-6d1a-4c5e-b8f0-7a3d2c1e9b6f
status: test
tags:
  - attack.credential_access
  - attack.t1110.003
  - attack.initial_access
correlation:
  type: temporal_ordered
  rules:
    - failed_logon_any
    - successful_logon
  group-by:
    - IpAddress
  timespan: 60m
level: critical

Die erste Korrelation zählt verschiedene Zielkonten pro Quelladresse, die zweite verlangt, dass auf Fehlschläge von einer Adresse innerhalb einer Stunde ein Erfolg von derselben Adresse folgt. Die zweite ist allein zu breit, weil jeder Tippfehler mit anschließender richtiger Eingabe sie auslöst; in der Praxis wird sie mit der ersten verknüpft, sodass der Erfolg nur zählt, wenn die Quelle vorher die Spraying-Schwelle erreicht hat. Ob das Backend diese Verkettung übersetzt, hängt vom SIEM ab; wo nicht, bleibt die zweite Regel eine gespeicherte Suche, die bei jedem Spraying-Alarm als erster Schritt der Bearbeitung ausgeführt wird. Für das Cloud-Anmeldeprotokoll gilt dieselbe Logik mit dem Fehlercode 50126 statt 4625 und dem Feld für die Quelladresse; die Sigma-Sammlung hat dafür eine eigene Logquelle. Aufbau und Übersetzung von Korrelationsregeln sind im Beitrag zu Sigma-Regeln beschrieben.

Der Test

Atomic Red Team hat für T1110.003 Tests, die per PowerShell oder mit Werkzeugen wie Kerbrute ein Passwort gegen eine Kontenliste probieren. Im Homelab braucht der Test zwanzig Benutzerkonten in der Domäne, von der Kali-VM aus ein Durchlauf mit einem falschen Passwort, dann ein zweiter mit dem richtigen Passwort eines der Konten. Erwartet werden zwanzig 4771 oder 4625 mit derselben Quelladresse innerhalb einer Minute, der Alarm der ersten Korrelation, dann ein 4624 von derselben Adresse und der Alarm der zweiten. Wer den Test gegen die Sperrrichtlinie fährt, sieht auch, ob die Richtlinie sitzt: Bei einem Passwort pro Konto darf kein 4740 entstehen. Für die Cloud-Seite gibt es keinen Test ohne Risiko für echte Konten; dort wird die Regel mit historischen Daten aus den letzten 30 Tagen validiert, in denen bei fast jeder Organisation echtes Spraying zu finden ist.

Fehlalarme und Tuning

• Proxys, Gateways und NAT. Ein VPN-Gateway, ein Terminalserver oder ein Proxy bündelt hunderte Benutzer hinter einer Adresse, und am Montagmorgen erreichen sie die Schwelle mit Tippfehlern. Die Adressen werden ausgenommen, und für sie gilt eine eigene Regel mit dem Feld für die Arbeitsstation statt der Adresse.
• Schwachstellenscanner und Inventarwerkzeuge. Scanner mit Anmeldeversuchen sehen wie Spraying aus und sind es technisch auch. Ausnahme nach Adresse und Zeitplan, mit dem Scan-Ticket als Begründung.
• Abgelaufene Passwörter in Diensten. Ein Dienst, dessen Dienstkonto ein neues Passwort bekommen hat, erzeugt Fehlschläge im Sekundentakt, aber für ein Konto. Er fällt nicht unter die Regel für verschiedene Konten, sondern unter eine eigene für Brute Force und Fehlkonfiguration.
• Die Fehlschläge, die nie ankommen. Wenn das VPN oder die Cloud-Anmeldeseite die Fehlschläge abfängt, bleibt der Domain Controller leer, und die Regel dort ist blind. Das ist kein Fehlalarm, sondern ein fehlender Sensor, und die Maßnahme heißt Anbindung der Quelle.
• Die Gegenmaßnahme, die die Regel entlastet. Phishing-resistente MFA auf allem, was von außen erreichbar ist, Sperrung von Legacy-Protokollen ohne MFA, eine Passwortrichtlinie mit Sperrliste für die üblichen Kandidaten und eine intelligente Sperre, die die Quelle statt das Konto blockiert. Danach findet Spraying zwar noch statt, aber der Erfolg nach der Serie kommt nicht mehr, und genau das ist der Zustand, den die Regel dann bestätigt. Was zu tun ist, wenn der Erfolg doch kommt, steht im Playbook zum kompromittierten Konto. Wenn der erfolgreiche Login über einen Proxy läuft, der MFA umgeht, ist es AiTM-Phishing.

Fazit

Password Spraying ist der Angriff, den fast jede Organisation täglich erlebt und die wenigsten sehen, weil sie Fehlschläge pro Konto zählen statt Konten pro Quelle. Die Umkehrung dieser Zählung, ein Zeitfenster und eine zweite Regel für den Erfolg nach der Serie machen aus dem täglichen Rauschen eine Erkennung, die den Angreifer am Anfang der Kill Chain zeigt, bevor er ein Konto hat. Wer die Quellen anbindet, an denen die Fehlschläge tatsächlich ankommen, und die eigenen Gateways als Ausnahme pflegt, hat eine der wenigen Regeln, die schon vor dem Einbruch etwas findet, und für ein Blue Team ist das der seltene Fall, in dem Erkennung auch Verhinderung ist.