Thomas.will: Die Seite wurde neu angelegt: „= Password Spraying = '''Password Spraying''' ist eine Angriffstechnik gegen Authentifizierungsdienste, bei der ein Angreifer ''wenige'' häufig verwendete Pa…“

2026-08-15T12:12:14Z

Die Seite wurde neu angelegt: „= Password Spraying = '''Password Spraying''' ist eine Angriffstechnik gegen Authentifizierungsdienste, bei der ein Angreifer ''wenige'' häufig verwendete Pa…“

Neue Seite

= Password Spraying =

'''Password Spraying''' ist eine Angriffstechnik gegen Authentifizierungsdienste, bei der ein Angreifer ''wenige'' häufig verwendete Passwörter gegen ''viele'' Benutzerkonten ausprobiert. Ziel ist nicht, ein bestimmtes Konto zu knacken, sondern die Frage zu beantworten:

: ''"Verwendet irgendjemand in dieser Organisation dieses Passwort?"''

Ein einziger Treffer genügt in der Regel, um einen Einstiegspunkt in die Umgebung zu erhalten.

== Einordnung ==

Password Spraying ist '''keine Schwachstelle in einer Software''' im Sinne einer SQL-Injection oder eines Pufferüberlaufs. Es gibt keinen Patch dagegen. Ausgenutzt werden stattdessen organisatorische und konzeptionelle Schwächen:

* schwache oder wiederverwendete Passwörter der Benutzer
* fehlende Mehrfaktor-Authentifizierung
* Anmeldedienste, die aus dem Internet erreichbar sind
* Sperrmechanismen, die ausschließlich pro Konto zählen
* fehlende oder ungenutzte Auswertung der Authentifizierungsprotokolle

Password Spraying ist damit ein '''Authentifizierungsangriff''', der schwache Anmeldedaten und unzureichende Schutzmaßnahmen kombiniert.

== Abgrenzung zum Brute-Force-Angriff ==

Beide Verfahren probieren Passwörter aus, unterscheiden sich aber in der Richtung des Angriffs.

=== Klassischer Brute-Force-Angriff ===

Ein Konto, viele Passwörter:

<pre>
Benutzer: alice@example.com
Passwort 1
Passwort 2
Passwort 3
...
</pre>

Wenn ein Konto nach mehreren Fehlversuchen gesperrt wird, läuft dieser Angriff sehr schnell in die Sperre. Er ist zudem in den Protokollen leicht zu erkennen: viele Fehlschläge auf einem einzigen Konto in kurzer Zeit.

=== Password Spraying ===

Ein Passwort, viele Konten:

<pre>
Passwort: CommonPassword123!
alice@example.com
bob@example.com
carol@example.com
david@example.com
eric@example.com
</pre>

Anschließend wartet der Angreifer eine Weile und wiederholt den Vorgang mit dem nächsten Passwort:

<pre>
Passwort A -> viele Konten
warten
Passwort B -> viele Konten
warten
Passwort C -> viele Konten
</pre>

Pro Konto entstehen dadurch nur ein oder zwei Fehlversuche innerhalb des Sperrintervalls. Die kontobezogene Sperre greift nicht, und in der Einzelbetrachtung eines Kontos sieht der Vorgang unauffällig aus.

{| class="wikitable"
! !! Brute Force !! Password Spraying
|-
| Richtung || viele Passwörter → ein Konto || ein Passwort → viele Konten
|-
| Fehlversuche pro Konto || hoch || sehr niedrig
|-
| Kontosperre || wird ausgelöst || wird umgangen
|-
| Erkennung || pro Konto || nur in der Gesamtschau
|-
| Erfolgskriterium || ein bestimmtes Konto || irgendein Konto
|}

Der entscheidende Punkt für die Erkennung: Password Spraying ist '''auf der Ebene eines einzelnen Kontos praktisch unsichtbar'''. Sichtbar wird es erst, wenn man die Fehlversuche über alle Konten hinweg korreliert.

== Warum das Verfahren funktioniert ==

Password Spraying setzt nicht auf Rechenleistung, sondern auf menschliches Verhalten. Benutzer wählen Passwörter, die

* leicht zu merken sind,
* auf bekannten Wörtern beruhen,
* einen Bezug zur Organisation haben,
* früheren eigenen Passwörtern ähneln,
* auf mehreren Diensten wiederverwendet werden,
* vorhersehbaren Mustern folgen.

Typische Muster in Organisationen:

<pre>
Firmenname + Jahr
Firmenname + Jahreszeit
Willkommen + Jahr
Abteilung + Jahr
</pre>

Der Angreifer muss kein komplexes Passwort erraten. Es genügt, dass '''ein einziger''' von mehreren hundert Benutzern ein vorhersehbares Passwort gewählt hat.

=== Rechenbeispiel ===

Ein Unternehmen hat 500 Mitarbeiter. Der Angreifer beschafft sich die Liste der Mailadressen aus öffentlich zugänglichen Quellen und probiert ein einziges gängiges Passwort gegen alle Konten:

<pre>
Passwort A
|
500 Konten
|
2 erfolgreiche Anmeldungen
</pre>

Der Angreifer muss nicht alle 500 Konten übernehmen. Zwei gültige Zugangsdaten reichen aus, um mit dem eigentlichen Einbruch zu beginnen – mit genau den Rechten, die diese Benutzer besitzen.

== Ablauf einer Kampagne ==

=== Phase 1: Sammeln der Kontonamen ===

Benötigt werden gültige Benutzerkennungen, zum Beispiel

* E-Mail-Adressen
* Anmeldenamen der Mitarbeiter
* Kundenkonten
* VPN-Benutzer
* Konten bei Cloud-Identitätsdiensten
* Dienstkonten

Organisationen geben diese Informationen häufig unbeabsichtigt preis über die eigene Webseite, Mitarbeiterverzeichnisse, soziale Netzwerke, Metadaten in veröffentlichten Dokumenten, Konferenzunterlagen, öffentliche Code-Repositories oder das Namensschema der Firmenmailadressen.

Hilfreich für den Angreifer ist außerdem jeder Dienst, der bei unbekanntem Benutzernamen eine andere Fehlermeldung oder eine messbar andere Antwortzeit liefert als bei falschem Passwort ('''User Enumeration''').

=== Phase 2: Auswahl der Passwörter ===

Ausgewählt werden Passwörter mit möglichst hoher Trefferwahrscheinlichkeit:

* verbreitete Standardpasswörter
* Passwörter aus bekannten Datenlecks
* organisationsspezifische Begriffe
* vorhersehbare Muster (siehe oben)

Das Ziel ist ausdrücklich '''nicht''', möglichst viele Passwörter zu testen, sondern die Trefferwahrscheinlichkeit bei möglichst wenigen Versuchen zu maximieren.

=== Phase 3: Anmeldeversuche ===

Angegriffen werden bevorzugt Dienste, die von außen erreichbar sind:

* Microsoft 365 und andere Cloud-Identitätsdienste
* VPN-Gateways
* Remote-Desktop-Dienste
* Weboberflächen und SaaS-Anwendungen
* Mailserver (IMAP, SMTP-Auth, OWA)
* interne Anmeldeportale

=== Phase 4: Tarnung ===

Ein sorgfältig arbeitender Angreifer versucht, unterhalb der Schwellwerte der Überwachung zu bleiben:

* Verteilung der Versuche über einen langen Zeitraum
* niedrige Zahl von Versuchen pro Konto
* Wechsel der Quell-IP-Adressen (Botnetz, Proxy, Cloud-Instanzen)
* Wechsel zwischen verschiedenen Anmeldediensten
* Abbruch, sobald gültige Zugangsdaten gefunden wurden

Genau diese Tarnung entwertet rein IP-basierte Abwehrmechanismen (siehe unten).

=== Phase 5: Kontoübernahme ===

Ein funktionierendes Passwort liefert eine gültige Kombination aus Benutzername und Passwort. Damit erreichbar sind je nach Konto etwa E-Mail, Cloud-Speicher, interne Anwendungen, Kundendaten, Firmendokumente, Quellcode, VPN-Zugänge oder Verwaltungssysteme. Im Anschluss folgen üblicherweise Rechteausweitung und Ausbreitung im Netz.

== Erkennung ==

Das Erkennungsmuster lautet:

: '''viele verschiedene Benutzernamen + jeweils dasselbe Passwort + wenige Versuche pro Konto'''

Da das Passwort selbst nicht protokolliert wird, ist das praktisch auswertbare Merkmal:

: '''eine Quelle erzeugt Fehlanmeldungen über auffällig viele unterschiedliche Konten'''

Weitere Indikatoren:

* Fehlanmeldungen auf Konten, die gar nicht existieren (Angreifer arbeitet mit einer geratenen Namensliste)
* Fehlversuche in gleichmäßigen Zeitabständen
* Anmeldeversuche außerhalb der Arbeitszeiten
* Zugriffe aus untypischen Ländern, Netzen oder von Cloud-Providern
* eine erfolgreiche Anmeldung unmittelbar nach einer Serie von Fehlschlägen auf anderen Konten – das ist der kritische Fall

=== Auswertung unter Linux ===

;Fehlgeschlagene SSH-Anmeldungen des heutigen Tages anzeigen
*sudo journalctl -u ssh --since today | grep "Failed password"

;Fehlversuche je Quell-IP zählen
*sudo grep "Failed password" /var/log/auth.log | grep -oP "from \K[0-9.]+" | sort | uniq -c | sort -rn

;Angesprochene Benutzernamen auflisten
*sudo grep "Failed password" /var/log/auth.log | grep -oP "for (invalid user )?\K\S+" | sort | uniq -c | sort -rn

;Entscheidende Kennzahl – Anzahl unterschiedlicher Benutzer je Quell-IP
*sudo grep "Failed password" /var/log/auth.log | awk '{for(i=1;i<=NF;i++){if($i=="for")u=$(i+1);if($i=="from")ip=$(i+1)}; print ip, u}' | sort -u | awk '{c[$1]++} END{for(i in c) print c[i], i}' | sort -rn

Eine IP mit zwei Fehlversuchen gegen fünfzig verschiedene Konten ist deutlich verdächtiger als eine IP mit hundert Fehlversuchen gegen ein einziges Konto.

;Versuche gegen nicht existierende Benutzer
*sudo grep "invalid user" /var/log/auth.log | grep -oP "invalid user \K\S+" | sort -u

=== Auswertung unter Windows / Active Directory ===

Relevante Ereignisse im Sicherheitsprotokoll der Domänencontroller:

* '''4625''' – fehlgeschlagene Anmeldung; Statuscode 0xC000006A steht für falsches Passwort bei existierendem Konto, 0xC0000064 für unbekannten Benutzernamen
* '''4771''' – Kerberos-Vorauthentifizierung fehlgeschlagen, Fehlercode 0x18 (falsches Passwort)
* '''4740''' – Konto gesperrt
* '''4768''' – Kerberos-Ticket angefordert, zur Korrelation mit erfolgreichen Anmeldungen

Auch hier gilt: nicht die Zahl der Ereignisse pro Konto ist aussagekräftig, sondern die Zahl unterschiedlicher Konten pro Quelladresse innerhalb eines Zeitfensters.

=== Regelbeispiel für Wazuh ===

Wazuh wertet SSH-Fehlanmeldungen bereits über die Standardregeln aus (unter anderem 5710 für unbekannte Benutzer und 5716 für fehlgeschlagene Anmeldungen). Für Password Spraying ist eine eigene, frequenzbasierte Regel sinnvoll, die über ein längeres Zeitfenster zählt:

<pre>
<group name="authentication,spraying,">

<rule id="100310" level="10" frequency="10" timeframe="600">
<if_matched_sid>5716</if_matched_sid>
<same_source_ip />
<different_user />
<description>Moegliches Password Spraying: viele verschiedene Benutzer von einer Quelle</description>
<mitre>
<id>T1110.003</id>
</mitre>
</rule>

<rule id="100311" level="12" frequency="20" timeframe="3600">
<if_matched_sid>5710</if_matched_sid>
<same_source_ip />
<different_user />
<description>Kontoaufzaehlung: viele nicht existierende Benutzer von einer Quelle</description>
</rule>

</group>
</pre>

Die Regeln gehören in ''/var/ossec/etc/rules/local_rules.xml''.

;Konfiguration prüfen und Manager neu starten
*sudo /var/ossec/bin/wazuh-logtest
*sudo systemctl restart wazuh-manager

Das lange Zeitfenster ist hier der wesentliche Punkt: Ein Angreifer, der die Versuche bewusst streckt, fällt durch die üblichen kurzen Intervalle von 60 oder 120 Sekunden nicht auf.

=== Grenzen von Fail2ban und CrowdSec ===

Fail2ban zählt Fehlversuche '''pro Quell-IP''' und sperrt diese. Gegen eine verteilte Spraying-Kampagne, bei der jede IP nur wenige Versuche unternimmt, greift dieser Mechanismus nicht.

CrowdSec verbessert die Lage, weil neben lokalen Szenarien auch die gemeinsam gepflegten Reputationslisten genutzt werden und dadurch Adressen blockiert werden, die andernorts bereits aufgefallen sind. Ein Angreifer mit frischen Adressen bleibt aber auch hier zunächst unauffällig.

'''Fazit:''' IP-basierte Sperren sind eine sinnvolle Grundhygiene, aber kein Schutz vor Password Spraying. Der Schutz muss auf der Ebene der Authentifizierung selbst ansetzen.

== Gegenmaßnahmen ==

=== 1. Mehrfaktor-Authentifizierung ===

Die wirksamste Einzelmaßnahme. Selbst wenn der Angreifer ein gültiges Passwort findet, führt es nicht zur Anmeldung. Phishing-resistente Verfahren (FIDO2/WebAuthn) sind Einmalpasswörtern per SMS deutlich vorzuziehen. MFA gehört insbesondere an alle von außen erreichbaren Dienste: VPN, Webmail, Cloud-Identität, Fernwartungszugänge.

=== 2. Schwache und geleakte Passwörter blockieren ===

Passwörter werden bereits bei der Vergabe gegen eine Sperrliste geprüft: gängige Passwörter, Begriffe mit Organisationsbezug, Passwörter aus bekannten Datenlecks. Das ist wirksamer als erzwungene Komplexitätsregeln, die Benutzer erfahrungsgemäß zu vorhersehbaren Mustern verleiten (''Firma2026!''). Diese Sichtweise entspricht auch der aktuellen Empfehlung des NIST (SP 800-63B), das regelmäßige Passwortwechsel ohne Anlass ausdrücklich nicht mehr empfiehlt.

=== 3. Authentifizierungsverhalten überwachen ===

Alarmierung auf ungewöhnliche Anmeldemuster, insbesondere auf Fehlversuche, die sich über viele Konten verteilen. Ohne zentrale Sammlung und Korrelation der Anmeldeprotokolle (SIEM) ist dieses Muster nicht sichtbar. Besonders wichtig ist die Alarmierung auf eine ''erfolgreiche'' Anmeldung im zeitlichen Umfeld einer Fehlversuchsserie.

=== 4. Risikobasierte Authentifizierung ===

Zusätzliche Prüfung, wenn die Anmeldung von einem unbekannten Gerät, aus einem ungewöhnlichen Netz oder aus einer untypischen Region kommt. Ebenso sinnvoll sind Sperren nach Herkunftsland, sofern der Dienst nur aus bestimmten Regionen genutzt wird.

=== 5. Von außen erreichbare Anmeldedienste absichern ===

Unnötige Exposition vermeiden, Zugangsbeschränkungen und Ratenbegrenzung anwenden, Legacy-Protokolle ohne MFA-Unterstützung abschalten (etwa Basic Authentication bei IMAP/SMTP). Wo möglich, den Dienst hinter VPN oder Reverse Proxy legen statt direkt zu veröffentlichen.

=== 6. Starke, individuelle Passwörter ===

Jedes Konto erhält ein eigenes starkes Passwort; Zugangsdaten werden nicht über mehrere Systeme hinweg wiederverwendet. Passwortmanager im Unternehmen bereitstellen, damit diese Anforderung praktikabel ist.

=== 7. Sperrmechanismen sinnvoll auslegen ===

Reine Kontosperren nach n Fehlversuchen sind gegen Spraying wirkungslos und eröffnen umgekehrt eine Denial-of-Service-Möglichkeit gegen die eigenen Benutzer. Besser sind ansteigende Verzögerungen sowie Schwellwerte, die zusätzlich mandanten- oder quellbezogen ausgewertet werden.

=== 8. Dienstkonten gesondert behandeln ===

Dienstkonten haben oft alte, nie gewechselte Passwörter, keine MFA und hohe Rechte. Sie sind ein bevorzugtes Ziel und sollten mit langen, zufälligen Passwörtern, interaktivem Anmeldeverbot und eigener Überwachung versehen werden.

== Übung im Labor ==

# Auf einem Laborhost mehrere Fehlanmeldungen gegen ''unterschiedliche'' Benutzernamen erzeugen (jeweils nur ein Versuch pro Benutzer).
# Zum Vergleich mehrere Fehlanmeldungen gegen ''denselben'' Benutzer erzeugen.
# Beide Muster in ''/var/log/auth.log'' mit den oben genannten Auswertungen gegenüberstellen.
# Prüfen, welches der beiden Muster Fail2ban beziehungsweise CrowdSec auslöst – und welches nicht.
# Die Wazuh-Regel 100310 einspielen und mit ''wazuh-logtest'' verifizieren.
# Diskussion: Welche Zeitfenster und Schwellwerte sind in der eigenen Umgebung realistisch, ohne Fehlalarme zu erzeugen?

== Zusammenfassung ==

* Password Spraying dreht den Brute-Force-Angriff um: ein Passwort gegen viele Konten.
* Der Angriff umgeht kontobezogene Sperren, weil pro Konto kaum Fehlversuche entstehen.
* Er nutzt keine Softwarelücke, sondern schwache Passwörter und fehlende Schutzmaßnahmen.
* Erkannt wird er nur durch Korrelation über alle Konten hinweg, nicht in der Einzelbetrachtung.
* Wirksamster Schutz: Mehrfaktor-Authentifizierung plus Sperrlisten für bekannte und schwache Passwörter.
* Ein einziges kompromittiertes Konto genügt als Einstiegspunkt.

== Siehe auch ==

* [[Brute-Force-Angriff]]
* [[Credential Stuffing]]
* [[Mehrfaktor-Authentifizierung]]
* [[Wazuh]]
* [[CrowdSec]]
* [[Absicherung von SSH]]

[[Kategorie:IT-Sicherheit]]
[[Kategorie:Angriffstechniken]]

Password spaying - Versionsgeschichte

Thomas.will: Die Seite wurde neu angelegt: „= Password Spraying = '''Password Spraying''' ist eine Angriffstechnik gegen Authentifizierungsdienste, bei der ein Angreifer ''wenige'' häufig verwendete Pa…“