Password spaying

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen

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: 

Benutzer: alice@example.com
    Passwort 1
    Passwort 2
    Passwort 3
    ...

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: 

Passwort: CommonPassword123!
    alice@example.com
    bob@example.com
    carol@example.com
    david@example.com
    eric@example.com

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

Passwort A  ->  viele Konten
   warten
Passwort B  ->  viele Konten
   warten
Passwort C  ->  viele Konten

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.

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: 

Firmenname + Jahr
Firmenname + Jahreszeit
Willkommen + Jahr
Abteilung + Jahr

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: 

Passwort A
     |
500 Konten
     |
  2 erfolgreiche Anmeldungen

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: 

<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>

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

  1. Auf einem Laborhost mehrere Fehlanmeldungen gegen unterschiedliche Benutzernamen erzeugen (jeweils nur ein Versuch pro Benutzer).
  2. Zum Vergleich mehrere Fehlanmeldungen gegen denselben Benutzer erzeugen.
  3. Beide Muster in /var/log/auth.log mit den oben genannten Auswertungen gegenüberstellen.
  4. Prüfen, welches der beiden Muster Fail2ban beziehungsweise CrowdSec auslöst – und welches nicht.
  5. Die Wazuh-Regel 100310 einspielen und mit wazuh-logtest verifizieren.
  6. 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

Abgerufen von „https://xinux.net/index.php?title=Password_spaying&oldid=72715“