Die ersten beiden Artikel unserer Password Cracking Serie haben sich mit den Basics von Password Cracking und einigen coolen Tricks befasst. Die gezeigten Ansätze sind zwar wichtig für das Verständnis, bewegten sich aber bisher eher in einem theoretischen Rahmen.
Nun konfrontieren wir die Learnings daraus mit der Realität und demonstrieren so deren praktische Anwendbarkeit: In diesem Artikel stellen wir euch zwei Fälle vor, in denen wir bei echten Pentests erfolgreich Password Cracking betrieben haben.
Die beiden hier besprochenen Fallbeispielen haben einige Gemeinsamkeiten: In beiden Fällen arbeiteten die getesteten Unternehmen mit klassischem Active Directory. Unsere Pentester haben jeweils den DC übernommen und anschließend mittels DC-Sync die NTDS.dit heruntergeladen.
Bei Unternehmen A handelt es sich um ein größeres Unternehmen, das keinerlei Password Policy eingeführt hatte. Unternehmen B ist ein mittelständisches Unternehmen mit unterschiedlichen Password Policies für Administratoren und Nutzer. Die jeweiligen Password Policies waren sinnvoll konfiguriert.
Es ist vermutlich wenig überraschend, dass wir bei Unternehmen A durch Password Cracking nach kurzer Zeit ca. 80% der Passwörter wiederherstellen konnten. Doch auch bei Unternehmen B konnten wir ca. 60% der Passwörter (von Nutzern und Administratoren) wiederherstellen. Wie war das möglich?
Unternehmen A hatte keine Password Policy und die Mindestlänge von 8 Zeichen hat uns das Password Cracking sehr leicht gemacht. Zudem waren Passwörter teils gar nicht gesetzt oder wurden mehrfach verwendet. Diese Voraussetzungen erklären die hohe Erfolgsquote bei der Wiederherstellung der Passwörter.
Die Password Policy von Unternehmen B sieht auf den ersten Blick sehr sicher aus: Sie erzwang die Aktualisierung der Passwörter nach 30 Tagen, speicherte eine Historie von 24 vorherigen Passwörtern und erforderte drei von 4 Komplexitäts-Merkmalen. Das Admin-Netzwerk erlaubte jedoch noch LM-Hashes zur Passwort-Speicherung. Die Mindestlänge für Passwörter lag bei 14 Zeichen. Damit hatte Unternehmen B die alten Vorgaben der „NIST Special Publication 800 – 63. Appendix A“ voll erfüllt.
Klingt doch wirklich sicher, oder?
In der Realität führen gutgemeinte Password Policies leider häufig zu unsicheren Passwörtern.
In den folgenden Abschnitten nehmen wir die einzelnen Anforderungen unter die Lupe und zeigen, wo die Schwächen der Policy von Unternehmen B liegen. (Spoiler Alert: Die größte Schwachstelle ist meistens der Mensch.)
Komplexitätsanforderungen sollen in der Theorie das Cracken der Passwörter durch die Erhöhung möglicher Zeichenkombinationen erschweren. In der Praxis erfüllen Nutzer die Anforderungen jedoch oft durch typische Schemata und erleichtern so im Gegenteil das Cracken:
Großgeschriebene Anfangsbuchstaben, darauffolgende Kleinbuchstaben und anschließend Zahlen oder Sonderzeichen. Sehen deine „sicheren“ Passwörter zufällig auch so aus?
Mit dem Wissen um solche Muster lassen sich Masken, Regeln und Wörterbücher erstellen, die genau auf solche Pattern abzielen.
Beispiel:
example.local\user:Straßenbahn01#
example.local\user:Neuseeland1997!
example.local\user:Westfranken!!!!
example.local\user:Gabelstapler2000
Die Password History im AD soll Password Reuse nach Password Changes verhindern, kann jedoch durch die Speicherung der abgelaufen Passwörter weitreichende Informationen über das Nutzerverhalten preisgeben. Die erzwungenen regelmäßigen Änderungen steigern somit nicht die Sicherheit, sondern sorgen für schwächere Passwörter, die einmal erstellt und anschließend jedes Mal minimal geändert werden. Dies schwächt die Sicherheit dahingehend, dass ein einzelnes gecracktes Passwort aus der Password History alle anderen Passwörter offenbaren kann. Mit Regeln und Masken lässt sich die Password History eines Nutzers gut cracken.
Die Password History wird beim “normalen” NTDS-dump nicht mit heruntergeladen. Auch Frameworks wie Crackmapexec können dies aktuell nicht. Secretsdump bietet aber mit -history eine passende Option.
Beispiel:
secretsdump.py example.local/Administrator:password123@10.0.0.1 -history
example.local\user:Hash:München1976
example.local\user_history0:Hash:München1975
example.local\user_history1:Hash:München1974
example.local\user_history2:Hash:München1973
example.local\user_history3:Hash:München1972
Ist man also auf der sichereren Seite, wenn man Nutzer nicht zum regelmäßigen Erneuern der Passwörter zwingt? Nicht wirklich, denn häufig werden einmal erstellte Passwörter mehrfach verwendet. Dank der fehlenden Salts bei NTLM ist Password Reuse schon an den Hashes erkennbar.
Aufgrund von Password Reuse können bis zu 30% der Systeme das gleiche Passwort haben.
Diese hohe Zahl kommt zum Teil durch die vom Administrator vergebenen Standard Passwörter für Machine Accounts in Active Directorys. Zudem werden typische Passwörter von verschiedensten Personen mehrfach verwendet.
Das Passwort Sommer+Jahreszahl ist hier ein unrühmliches Beispiel.
Beispiel:
example.local\user:Sommer2022!
example.local\user01:Firma1234#
example.local\user02:Firma1234#
example.local\user03:Sommer2022!
Teilweise kommt es auch heute noch vor, dass bei älteren Systemen oder aus Gründen der Abwärtskompatibilität LM-Hashes nicht deaktiviert wurden. Der LM-Hash ist der Vorgänger des NT-Hashes und weißt zahlreiche kryptographische Schwächen auf, wodurch er heute problemlos crackbar ist.
LM_Hashes sollten heutzutage per Default deaktiviert sein.
Beispiel:
LM deaktivert bzw. leerer LM Hash
example.local\user01:aad3b435b51404eeaad3b435b51404ee :9b1b37b966345526850732e17aed49f8:Sommer2022!
LM nicht deaktiviert
example.local\user02:628eddc897eb8d8cfb12c634df37c04f :9b1b37b966345526850732e17aed49f8:Sommer2022!
Zuerst habe ich einige Methoden gegen die Passwörter angewendet, die dir aus den ersten Artikeln bekannt sind: Wörterbuch-, Hybrid- und Masken/Bruteforce-Attacken. Mein erstes Vorgehen bei beiden NTDS-Dumps bestand aus:
1. LM-Hashes vorhanden?
Wenn ja:
hashcat -a3 -m3000 a?a?a?a?a?a?a?
2. Bruteforce bis 8 Zeichen:
hashcat -a3 -m1000 -O -w4 ntds.txt "?a?a?a?a?a?a?a?a"
3. Wörterbuchangriffe mit Regeln und Loopback:
hashcat -a0 -m1000 -O -w4 ntds.txt wörterbuch.txt -r rule.rule --loopback
4. OSINT & Cewl
Erstellung von gezielten Wörterbüchern mittels Cewl
Suche nach weiteren Informationen über das Ziel
5. Gezieltere Wörterbuchangriffe mit Regeln und Loopback
hashcat -a0 -m1000 -O -w4 ntds.txt eigenes_Wörterbuch.txt -r --loopback rule.rule
Auf diese Weise habe ich im ersten Schritt ca. 60% (Unternehmen A) bzw. 40% (Unternehmen B) der Hashes gecrackt. Anschließend habe ich eine Password Analyse durchgeführt, um statistische Besonderheiten zu ermitteln und auszunutzen.
Die gecrackten Passwörter wiesen einige Auffälligkeiten auf:
Beispiel:
Wortwiederholungen:
Sommer_Sommer18wdefrgthzj
UrlaubUrlaubUrlaub
Sätze:
Back_me.up12
Derbaum4mal
Keyboardwalk:
qwertzuiop
wdefrgthzj
q2w3e4r5t67z8u9i0o
Ähnliche Suffixe bzw. Präfixe:
Playstation.4
Bananenbieger1984!
Sommer2022!
2008anna
Dies sind alles typische Passwortkombinationen, die sich mit den passenden Regeln und Wörterbücher einfach cracken lassen.
Das Wissen hierfür ist öffentlich verfügbar, ein Angreifer könnte also ohne Probleme ca. 50% der Passwörter cracken.
Um mehr als 50% zu cracken, ist jedoch Wissen über die Optimierung von Hashcat und den verwendeten Angriffen notwendig. Damit befasst sich der nächste Schritt.
Bei der weiteren Analyse der gecrackten Passwörter kommen Tools wie Pack und Pipal ins Spiel, um Gemeinsamkeiten zu finden. Basierend auf dieser Analyse werden anschließend Statistiken, Regeln und Masken erstellt, um Passwörter mit ähnlichen Schemata zu cracken. Falls wie im vorliegenden Fall Informationen über die Password Policy verfügbar sind, kannst du mittels Pack Masken generieren. Dieser Abschnitt stellt Pack mit seinen enthaltenen Programmen sowie Pipal als Alternative vor und gibt Tipps zu deren Verwendung.
Peter Kacherginsky hat Pack (Password Analysis and Cracking Kit) vor mehreren Jahren entwickelt. Heutzutage gibt es einen Rewrite in Python3 von Hydraze. Mit Pack kann man Passwörter analysieren, auswerten und eigene Masken, Regeln und Statistiken entwerfen. Pack besteht aus mehreren Programmen: Statsgen, Maskgen, Policygen, Rulegen. Mit diesen Unterprogrammen werden alle Funktionen von Pack abgebildet.
Installation:
git clone https://github.com/Hydraze/pack
Für RuleGen benötigt
sudo apt install python3-enchant
python3 statsgen.py
Die Grundlage von Pack ist StatsGen, das zur Analyse von Passwörtern dient. Statsgen erstellt Statistiken über Passwörter, Längenverteilung, Zeichensätze, Passwortkomplexität und mögliche Masken. Diese Informationen benötigt Pack für seine weitere Nutzung.
Andere Möglichkeiten bei Statsgen sind der Parameter –hiderare, um die Statistik durch seltene Passwörter nicht zu verfälschen. Außerdem lassen sich Filter nutzen, um bestimmte Passwörtern näher zu untersuchen. Hierzu verwendet man die Optionen –charset,—simplemask,–maxlength,–minlength. Erstellte Masken können mit -O gespeichert und von Hashcat genutzt werden.
Syntax:
Syntaxbeispiele:
Analyse von Passwörtern:
python3 statsgen.py cracked_hashes.txt
Analyse und Ausschluss von seltenen Passwörtern:
python3 statsgen.py cracked_hashes.txt --hiderare
Analyse und Speicherung als Maske:
python3 statsgen.py cracked_hashes.txt -o
Analyse und Filterung + alles vorherige:
python3 statsgen.py cracked_hashes.txt --simplemask=stringdigit --hidereare -o
MaskGen optimiert die mittels StatsGen erzeugten Masken, indem es Masken sortiert und analysiert. Dadurch lassen sich bessere Hashcracking Ergebnisse erzielen.
Masken kannst du nach Komplexität, Häufigkeit oder OptIndex (Mischung aus Komplexität und Häufigkeit) sortieren. Meistens ist –optindex eine gute Methode zur Sortierung, bei Password Policys kann auch –Complexity einen Blick wert sein. Der Parameter zur Sortierung –occurrence ist meiner Meinung nach zu vernachlässigen, da damit nur wenige sinnvolle Masken erzeugt werden.
Häufig können bei Pentests nicht alle Attacken durchgeführt werden. Insbesondere bei Masken oder Bruteforce-Attacken stellt dies immer ein zeitliches Problem dar. Die maximal erlaubte Zeitdauer aller Masken lässt sich mit –targettime angeben. Mit —targettime kann die gesamte Zeitdauer des Engagements angegeben werden, also die maximal mögliche Zeit. Einzelne Masken lassen sich mit –showmasks anzeigen und auf ihre Länge, Häufigkeit und Zeitdauer bewerten. Dies kann sinnvoll sein, um zeitliche Ausreißer zu finden oder Masken, die aus anderen Gründen nicht ins Schema passen.
Mit dem Parameter –showmasks lassen sich die einzelnen Masken mit ihrer jeweiligen Länge, Häufigkeit und Zeitdauer ausgeben. Der Parameter -pps wichtig, um die Berechnung realistisch zu halten: Er bezieht die Rechenleistung in Passwörter pro Sekunde ein. Bei höherer Rechenleistung sind umfangreichere Masken schneller durchsuchbar bzw. umgekehrt. Mit -o lassen sich die Masken im .hcmasks Format speichern, mit dem Hashcat problemlos arbeiten kann. Die Maskgen Header lassen sich mit -q ausblenden.
Inviduelle Filter:
Masken kannst du auch mit individuellen Filtern nach Länge, Zeit, Komplexität oder Häufigkeit sortieren. Die Parameter –minlength oder –maxlength sind sinnvoll, wenn z. B. bis 8 Buchstaben alles gecracked ist oder man ab einer gewissen Länge von Masken absehen möchte. Mit den Parametern –mintime oder –maxtime kann die Zeitdauer einer einzelnen Maske angeben werden.
Persönlich würde ich mit –targettime die Dauer der zur Verfügung stehenden Zeit angeben und mittels –mintime die Zeit für die jeweilig einzelne Maske, um Ausreißer zu vermeiden. Mittels –min/maxcomplexity und –min/maxoccurrence lässt sich Finetuning der Masken betreiben, doch für den Anfang reichen die oben genannten Parameter meist aus.
Eigene mit Maskgen generierte Masken lassen sich an Passwortlisten auf ihre Funktionalität gegen echte Passwörter testen. Hier würde ich jedoch zur Vorsicht raten, denn die meisten Passwortleaks kommen von Websites und/oder aus dem englischsprachigen Bereich. Daher sind viele dieser Dumps nicht mit den typischen Passwörtern aus dem „deutschen“ AD-Umfeld vergleichbar. Möglich ist es dennoch mit der Option –checkmasksfile, bei der zwei Masken miteinander verglichen werden.
Syntax:
Syntaxbeispiele:
Analyse von Masken, Anzeige aller Masken und eigener Geschwindigkeit:
python maskgen.py --showmasks --pps 10000000
Analyse von Masken und Sortierung nach optindex:
python maskgen.py --optindex
Analyse von Masken und Filterung nach Länge:
python maskgen.py --minlength=9 --maxlength=14
Analyse von Masken und Sortierung nach einzelner Maskenlaufzeit
python maskgen.py --targettime 21600
Analyse von Masken und Filterung nach gesamter Maskenlaufzeit:
python maskgen.py --maxtime=3600
Überprüfung
PolicyGen ist das Tool der Wahl, wenn es um Passwort Policies von Unternehmen geht. In AD-Umgebungen wird häufig durch Password Policies (Link zu Artikel 1) eine Mindestkomplexität erzwungen. Hierbei wird die Verwendung von Groß-, Kleinbuchstaben, Zahlen sowie Sonderzeichen erzwungen. PoliyGen erzeugt Masken, die dieses Schema erfüllen.
Mit PolicyGen lassen sich eine Vielzahl von Aufgaben ausführen: Einhaltung von Password Policies überprüfen, Passwort-Cracking bei Pentests unterstützten und Password Policies überprüfen.
Die Hashes pro Sekunde lassen sich wie bei MaskGen mittels –pps angeben. Das gilt ebenfalls für weitere Parameter wie -o zum Speichern, –showmasks und -q. Mit den Parametern –min/maxlength lässt sich die Länge der Passwörter angeben. Hier ist zu beachten, dass zu große Masken sich nicht mehr in akzeptabler Zeit cracken lassen. Die einzelnen Policy-Parameter lassen sich mittels –min/maxspecial, –min/maxdigit , –min/maxupper, –min/maxlower definieren. Falls man im Rahmen eines Audits nach Passwörtern sucht, die gegen die Policy verstoßen, lässt sich dies mit –noncompliant durchführen.
Bei Windows Password Policies gilt jedoch eine Besonderheit: Nativ werden nur 3 von 4 Komplexitätsanforderungen benötigt, was in PolicyGen so nicht vorgesehen ist. Der Workaround besteht aus dem manuellen Ausführern aller 4 Kombinationen, dem anschließenden Zusammenfügen in einer Datei und einer anschließenden Deduplizierung. Auch wäre hier –noncompliant eine sinnvolle Option, um Passwörter zu finden, die gegen die Policy verstoßen.
./policygen.py --minlength=9 --maxlength=10 --mindigit=1 --minspecial=1 --minlower=1 -o testing/mask01.hcmask
./policygen.py --minlength=9 --maxlength=10 --mindigit=1 --minspecial=1 --minupper=1 -o testing/mask02.hcmask
./policygen.py --minlength=9 --maxlength=10 --mindigit=1 --minlower=1 --minupper=1 -o testing/mask03.hcmask
./policygen.py --minlength=9 --maxlength=10 --minspecial=1 --minlower=1 --minupper=1 -o testing/mask04.hcmask
cat *.hcmask >> allmasks
sort allmasks | uniq -u > 9-10_chars_3_off_4.hcmask
Syntax
Syntaxbeispiele:
Passwort Policy zwischen 9 und 14 Zeichen
./policygen.py --minlength=9 --maxlength=14
Passwort Policy mit verschiedenen Zeichen als Mindestanforderung:
./policygen.py --minspecial=1 --minlower=1 --minupper=1 --mindigit=1
Passwort Policy mit verschiedenen Zeichen als Maximalanforderung:
./policygen.py --maxdigit=5 --maxlower=3 --maxupper=4 --maxspecial=2
Passwort Policy mit verschiedenen Zeichen und Filterung nach noncompliant
./policygen.py --minspecial=1 --minlower=1 --minupper=1 --mindigit=1 --noncompliant
RuleGen bietet Werkzeuge und Möglichkeiten, um Regeln zu analysieren, generieren und optimieren. Hierzu werden gecrackte Passwörter mittels der Pythonlibrary Enchant und Sprachengines wie Aspell, Myspell und Hunspell analysiert. Rulegen kann sowohl einzelne Passwörter als auch ganze Wörterlisten analysieren und passende Regeln erstellen. Außerdem kannst du erstellte Regeln analysieren und weiter optimieren werden.
Damit Rulegen richtig funktioniert, müssen einige Wörterbücher für die verschiedenen Rechtschreibkorrekturen genutzt werden. Es ist empfohlen, eine möglichst große Vielfalt an Wörterbüchern zu installieren: verschiedene Sprachen, Dialekte, fachspezifische Wörterbücher oder auch alte/neue Rechtschreibung.
Eine kleine Auswahl an Wörterbüchern:
sudo apt install aspell-de-1901
sudo apt install aspell-de
sudo apt install aspell-nl
sudo apt install aspell-fr
sudo apt install hunspell-de-de
sudo apt install hunspell-de-med
sudo apt install hunspell-de-at
sudo apt install hunspell-de-ch
Einzelne Passwörter:
Anschließend können einzelne Passwörter mit der Option –password <Input> analysiert werden. Hierbei ist es sinnvoll, den Verbose-Modus zu nutzen, um die Regelerstellung mitverfolgen zu können.
Exotische Wörter lassen sich mittels –word als Stammwort erzwingen, da sie häufig nicht von der Sprachengine erkannt werden. Ein Nutzungsbeispiel wäre hier der Kundenname im Pentest. Für mehrere solcher eigener Wörter lassen sich mittels –wordlist eigene Wörterbücher angeben, die ebenfalls berücksichtigt werden sollen. Eigene Wörterlisten sind insbesondere dann sinnvoll, wenn man schon gecrackte Passwörter hat oder besondere Sprache/Wörter mit verwenden möchte.
Um mehr Regel bzw. Wortvorschläge zu erzeugen, eignen sich die Parameter –morerules und –morewords. Durch diese Optionen wird die Generierung von suboptimalen Regeln und Wörtern ermöglicht. Eine weitere Option für die Anpassung von RuleGen wäre die Option —maxworddist=10, bei der die erlaubte Levenshtein Distanz angepasst wird. Bei diesen Optionen ist zu beachten, dass dadurch mehr Stammwörter bzw. Regeln generiert werden können, aber die Qualität nicht unbedingt dadurch steigt.
Vergleich verschiedener RuleGen Optionen in Bezug auf die Menge an gecrackten Hashes:
Es wird ersichtlich, dass Aspell die effizientere Sprachkorrektur ist und die Standardeinstellungen in den meisten Fällen mehr als ausreichen sind.
Anmerkung: Die Auswertung erfüllt keinen wissenschaftlichen Anspruch und wurde nur mit einer begrenzten Zahl an unterschiedlichen NTDS-Dumps durchgeführt.
Standardeinstellungen mit Aspell
./rulegen.py hash.txt --providers=aspell -b test03
Recovered........: 3309/9061 (36.52%) Digests (total), 3309/9061 (36.52%) Digests (new)
Standart Einstelllungen mit hunspell
./rulegen.py hash.txt --providers=hunspell -b test02
Recovered........: 2963/9061 (32.70%) Digests (total), 2963/9061 (32.70%) Digests (new)
Einstellungen mit verschiedenen Parametern zusammen
./rulegen.py hash.txt --maxworddist=15 --morewords --morerules --providers=aspell,myspell,hunspell -b test01
Recovered........: 2656/9061 (29.31%) Digests (total), 2656/9061 (29.31%) Digests (new)
Passwortlisten:
Passwortlisten lassen sich einfach als Datei angeben und werden von RuleGen direkt interpretiert. Die Passwörter in den Listen müssen ohne den jeweiligen Hashwert oder sonstige Zusätze angegeben werden. Passwörter, die keine ausreichenden Pattern bieten, werden übersprungen. Gleiches gilt für Zahlen und Nicht-ASCII-Zeichen, was eine gewisse Einschränkung bei verschiedenen Sprachen darstellt.
Mit der Option -b <Name> lassen sich die Ergebnisse in einer Datei speichern. Es wird jeweils eine unsortierte Regel- und Stammwörter-Datei erstellt.
Syntax:
Syntaxbeispiele:
Rulegen Analyse einzelner Passwörter im Verbose Modus:
./rulegen.py Hashlist --password WinterS8793! -verbose
Rulegen Analyse von Passwortlisten mit Speicherung der Regeln
./rulegen.py Hashlist -b
Rulegen Analyse von Passwortlisten mit verschiedenen Sprachprovidern:
./rulegen.py Hashlist --providers=aspell,hunspell,myspell
Rulegen Analyse von Passwortlisten mit erzwungenen Stammwörtern:
./rulegen.py Hashlist —word=
Rulegen Analyse von Passwortlisten mit eigenen Wörterbüchern:
./rulegen.py Hashlist -w /path/to/the/dict
Rulegen Analyse von Passwortlisten mit Fine-Tuning der Regel/Wort Generierung:
./rulegen.py Hashlist --maxworddist=10 --maxwords=7 --maxrulelen=15 --maxrules = 5
Eine Alternative zu Pack ist Pipal, das von Robin Wood aka Digininja programmiert wird. Es analysiert genau wie Pack Passwörter und bietet dabei einige Besonderheiten, auf die ich im Folgenden eingehe.
Das Programm ist modular aufgebaut, sodass sich alle Funktionen aktiveren bzw. deaktivieren lassen. Die Module heißen Checker und bieten jeweils einzelne spezifische Funktionen. Der modulare Aufbau bietet den großen Vorteil, dass nicht benötigte Funktionen temporär deaktivieren werden können. Dies bringt insbesondere bei großen Passwortlisten zeitliche Vorteile.
Standardmäßig nutzt Pipal nur den Basic Checker, der die häufigsten Pass- und Stammwörter, Passwortlänge und Verteilung und die Buchstaben/Ziffernnutzung analysiert. Andere Checker fügen Methoden zur Analyse von Sprachen wie Deutsch, Englisch, Französisch und Niederländisch ein. Weiterhin gibt es Checker, die (ähnlich wie StatsGen) Masken für Hashcat generieren oder Passwörter mit der Default Windows Passwort Policy abgleichen.
Meiner Meinung nach liegt der entscheidende Unterschied zu Pack und StatsGen darin, dass Pipal wesentlich stärker auf das reine Analysieren und Auswerten von Passwörtern ausgelegt ist. StatsGen hingegen ist eher für das Erstellen von Masken in Kombination mit MaskGen gedacht und spielt dort seine Stärken aus.
Installation:
https://github.com/digininja/pipal.git
././pipal.rb
Für manche Module sollte auch noch das Gem "levenshtein-ffi" installiert sein:
gem install levenshtein-ffi
# Checkers:
Aktivieren des Basic Checkers:
ln -s ../checkers_available/basic.rb .
Aktiveren aller anderen Checker:
ln -s ../checkers_available/*rb .
Beachte, dass das Aktivieren weiterer Checkern die Dauer der Passwort-Analyse deutlich verlängern kann: Je mehr Checker genutzt werden, desto länger dauert der Vorgang. Da es sich um Symlinks handelt, lassen sich nicht benötigt Checker ohne Probleme einfach aus der Datei checkers_enabled löschen
Nutzung:
Die Nutzung von verschiedenen Checkern kann unterschiedliche Optionen freischalten, daher gehe ich nun von folgendem Setup aus:
ls checkers_enabled/
01basic.rb DE_emotion_checker.rb DE_religion_checker.rb DE_season_checker.rb DE_vehicle_checker.rb README
DE_colour_checker.rb DE_family_checker.rb DE_road_checker.rb DE_sport_checker.rb hashcat_mask_generator.rb windows_complexity_checker.rb
Pipal benötigt für die Analyse von Passwörtern eine Datei mit den jeweiligen Passwörtern und die gewünschten Checker. Anschließend findet die Analyse automatisch statt und wird mit -o in ein Outputfile geschrieben. Hashcatmasken für alle analysierten Wörter lassen sich mit der Option –hashcat.all ausgeben.
Syntax
Syntaxbeispiele:
Pipal Analyse einer Passwortliste:
./pipal.rb
Pipal Analyse einer Passwortliste und Speicherung:
./pipal.rb -o
Pipal Analyse einer Passwortliste und Anzeigen der Top Passwörter:
./pipal.rb --top
Pipal Analyse einer Passwortliste und Ausgabe aller Hashcat-Masken:
./pipal.rb --hashcat.all
Durch die im Text beschrieben Tools, Techniken und Methoden war es uns in beiden Fallbeispielen möglich, die Menge an gecrackten Hashes mit geringem Aufwand deutlich zu erhöhen.
Bei allen Analysetools solltest du jedoch immer zu beachten, dass sich mit Programmen zwar eine Menge bewirken lässt, der Mensch jedoch mehr Muster erkennen kann als Programme. Mein Rat ist daher, Analysen selbst durchzuführen und nötigenfalls eigene Regeln oder Masken für den jeweiligen Fall zu schreiben. Programmieren oder Skripten hilft hier enorm, um diese Arbeit zu vereinfachen.
Dennoch sind Pack & Pipal zwei extrem wertvolle Tools beim fortgeschrittenen Password Cracking. Durch die zuvor beschrieben Möglichkeiten von Pack konnten wir in beiden Fällen eine erhebliche Menge an weiteren Hashes cracken.
Als Pentester (oder Angreifer generell) würde ich die statistischen Methoden nutzen, um Muster zu finden und diese auszunutzen. Das Thema bietet noch sehr viel Raum für weitere Forschungen und eigene Entwicklungen.
Das weitere Vorgehen werde ich in den folgenden Artikeln detailliert beschreiben, da es insbesondere für das Cracking des letzten Drittels der Passwörter eine Vielzahl an Methoden gibt. Password Cracking ist richtig durchgeführt ein sehr umfangreiches Thema und so kann auch dieser Artikel nur einen Ausschnitt auf die verschiedenen Möglichkeiten der Password Analyse geben.
In unserem ersten Beitrag zum Thema Password Cracking ging es um Password Policies, die mit den richtigen Einstellungen ein wichtiges Element zum Schutz vor Angreifern darstellen. In den oben genannten Fallbeispielen hat die Passwort Policy von Unternehmen B dazu geführt, dass wir statt 80% „nur“ 60% der Passwörter mit relativ einfachen Mitteln cracken konnten.
Der immer noch recht hohe Prozentsatz gecrackter Passwörter zeigt jedoch auch die Schwächen des Instruments Password Policy: Die Nutzer sind „auch nur Menschen“ und suchen sich oft den bequemsten Weg, um Richtlinien zu erfüllen. So kann beispielsweise eine gut gemeinte Password History in der Realität dazu führen, dass nur minimal geänderte Passwörter so noch leichter gecrackt werden können.
Als Sysadmin (oder Verteidiger generell) würde ich anraten, Passwörter aufgrund der menschlichen Schwächen mit viel User Awareness und MFA zu kombinieren. Von Menschen generierte Passwörter sind immer sehr angreifbar gegenüber von statistischer oder gar probalistischen Angriffen.
Ein Cyberangriff auf Jaguar Land Rover hat gezeigt: Es sind nicht immer ausländische Hackergruppen, sondern oft organisierte Jugendliche aus eigenem Land, die die digitale Leistungsfähigkeit moderner Industrieunternehmen untergraben. Dies sollte Firmen dazu veranlassen, Sicherheitskultur, Governance und Gefahrenanalyse ernst zu nehmen.
Cloudflare hat eine DDoS-Attacke von 11,5 Terabit pro Sekunde abgewehrt, einen traurigen Rekord und Weckruf für Unternehmen, ihre IT-Sicherheitsstrategie neu zu bewerten. Die Bedrohung bewegt sich über Hackereingriffe und betrifft geopolitische Interessen, kriminelle Netzwerke und technische Superwaffen.
Cyberkriminelle nutzen legitime Sicherheitstools wie „Velociraptor“ zur Durchführung von Angriffen auf Unternehmen. Dies unterstreicht die wachsende Unsichtbarkeit von Angreifern und das zunehmende Risiko von Kontrollverlust in IT-Systemen. Unternehmen müssen den Einsatz solcher Tools sorgfältig prüfen und kontextsensitive Sicherheitsmaßnahmen ergreifen.
