Hack the Hash

Eines unserer Workshop-Themen ist „Password Security“, hier erklären wir unter anderem, wie wichtig es ist auf die Länge des Passwortes zu achten. Je mehr Zeichen ein Password hat, desto schwieriger kann es „errechnet“ werden. Ein Real-World-Example bekamen wir nun selbst bei einem Pentest zu spüren, den wir für einen Kunden durchgeführt haben.

Konkret: David ist bereits via Trojaner am Kundenrechner und scannt SPNs in der Domain. Er löst mit den „Kerberoast“ Tools ein Service Ticket, und extrahiert den darin enthaltenen Hashwert des Passwortes (wie genau das funktioniert, lernt ihr in unserem Advanced Hacking Workshop). Was machen wir nun mit dem Hash? Zurückrechnen geht ja nicht – aber man kann alle möglichen Passwortkombinationen durchprobieren, mit dem Hash vergleichen, und schauen ob man das Service-Passwort „errät“.

Los gehts!

Hashcat für Arme

Wir speisen den erbeuteten Hashwert ins Profi-Crack-Tool „HASHCAT“ und geben einige Rahmenbedingungen vor (zb Zeichenanzahl, Muster, etc..).

Am Lab-Notebook schaut der Versuch allerdings etwas….. traurig aus. Für ein 6-stelliges Passwort rechnet man noch gute 2 Stunden herum, aber bei 8 Stellen steigt die Zeit auf 40 Jahre an. Womit bewiesen wäre, dass diese 8 Stellen mehr als ausreichend sind, um ein „sicheres“ Passwort zu verwenden.

Doch damit geben wir uns nicht zufrieden! Ganz klar, ab zum nächsten Media Markt, einen Pack High-End GPUs einkaufen und eine Hashcrack-Workstation aufbauen.

Das Problem: Kostenpunkt über 10.000 €. Und was tut man dann mit diesem Monster, ausser wertvolle Zeit mit 3D-Games verbraten? (Wer jetzt „Bitcoin Mining“ sagt, verlässt bitte umgehend den Blog…. 🙂)

 

Hashcat für Profis

Viel einfacher und vor allem kosteneffizienter ist es, sich so eine Power-Workstation einfach zu mieten – und zwar in der AWS Cloud. Dort gibt es quasi auf Knopfdruck eine fertig vorinstallierte Kali Linux VM mit wahlweise 1, 8 oder 16 NvidiaK80 GPUs (P2-Tier) oder 1, 4 oder 8 Nvidia V100 GPUS (P3-Tier). Der Kostenpunkt hierbei dreht sich um Stundenweise gerade mal einen € bis hin zu 24€ für die High-End-Variante.

Die Hashcat-Zeiten sehen dann auf einmal sogar richtig brauchbar aus:

Hier ein paar Vergleichswerte:

P2.x (1x Nvidia k80) – $1/h
8 Stellen – 1 Jahr 67 Tage
7 Stellen – 5 Tage 22 Stunden
6 Stellen – 1 Stunde 50 Minuten

P3.2x (1x Nvidia V100) – $3/h
8 Stellen – 19 Tage
7 Stellen – 6 Stunden
6 Stellen – 5 Minuten

P3.8x (4x Nvidia V100) – $12.3/h
8 Stellen – 5 Tage 10 Stunden
7 Stellen – 1 Stunde 45 Minuten
6 Stellen – 1 Minute

(Die P3.18x Variante mit 8x Nvidia V100 haben wir nicht mehr getestet. Bei 8 Stellen schätze ich die Rechenzeit aber grob auf 2.5 Tage.)

Um den Bogen zum Eingangs erwähnten Password-Security Workshop zu spannen: es ist für ganz normale Consumer mittlerweile möglich, 8-Stellige Passwörter in 2-3 Tagen zu errechnen – für etwas weniger als 200€. Wer in der Verantwortung steht, sollte sich daher überlegen, eine Mindestlänge von mehr als 8 Zeichen in der Passwortrichtlinie zu setzen. Bei Service-Accounts ist die Verwendung von MSA / Group-MSA empfehlenswert oder der Einsatz eines Remote-Password-Changer Tools. Weitere Tipps und Tricks gibts in unseren Workshops!

In diesem Sinne: Hack on!

 

PS: Der hier im Artikel zu errechnende Hash war vom Typ „Kerberos 5 TGS-REP etype 23“. Andere Hashtypen, wie zb NTLM sind unter Umständen noch wesentlich schneller berechenbar. Es soll hier konkret gezeigt werden, wie „einfach“ es bereits geworden ist, tiefgehende Systemvorgänge (Kerberos Ticket Exchange) zu knacken.

 

 

Attack! … or not?

Bei einem kürzlich durchgeführten Pentest für einen Kunden geschah das Unerwartete: Wir konnten trotz allen Anstrengungen keine C2-Verbindung zum Opfer herstellen.

Am Phishing-Mail dürfte es nicht liegen, denn die ersten User klickten bereits unseren Link an („Bitte installieren sie das verlinkte Plugin um ihren PC auf DSGVO-Kompatibilität zu prüfen“ ist zwar gemein, funktioniert aber). Der Kundenseitige Mailfilter war also nicht Schuld. Am Webserver sahen wir Zugriffslogs auf den ersten Stage der Schadsoftware. Kurz darauf, Nachladen der zweiten Stage. Doch dann – nichts! Es fand keine C2-Kommunikation statt.

Hat der Kunde einen besonders guten Virenscanner? Oder eine neuartige Firewall-Lösung, von der wir nichts wussten? War ein Security-Admin vor Ort, der sein Handwerk versteht und uns zum Narren hält? Ist eine moderne EDR-Lösung im Einsatz? Ganz klar, wir mussten der Sache auf den Grund gehen.

 

Debugging

Im Testlab installierten wir ein der Kundensituation ähnliches Systemumfeld, und fanden dabei (eher durch Zufall) folgende Situation vor:

Ein Powershell-Befehl unseres Staging-Scripts konnte nicht ausgeführt werden – genauer gesagt: System.Text.Encoding soll angeblich nicht existieren?  Diese Klasse ist aber Bestandteil der Standard-Assemblies, und existiert auf jedem System. Und bei unseren Tests vor dem eigentlichen Angriff trat der Fehler auch nicht auf (ja, selbstverständlich testen wir unsere eigenen Hacks 😉 )

Der Fehler lag im „Nichts“: wer genau hinsieht, wird zwischen Encoding und ] ein Leerzeichen erkennen. Diese Technik benutzen wir (unter anderem) gerne für Obfuskierungen von Malicious Code, was erschreckenderweise in vielen Fällen ausreicht, um AV und IDS Systeme zu umgehen. In diesem Fall scheint das Leerzeichen aber dazu zu führen, dass der Parser die PS-Syntax nicht mehr akzeptiert. Doch wieso funktioniert auf unseren Testsystemen alles?

 

Patch me up, Scotty

Auf Windows 10 (beliebige Versionen) wird das Leerzeichen ignoriert:

 

Auf einem Windows 7 SP1 jedoch nicht:

 

Die Moral der Geschichte: Liebe Kunden, bitte updated eure Systeme, sonst funktionieren manche obfuskierte Pentest-Scripts nicht 🙂

 

Microsoft hat in den aktuellsten Windows 10 Versionen 1709 und 1803 einige Sicherheitsfeatures in Windows Defender integriert, welche das Risiko einer Malware-Infektion stark reduzieren sollen. Uns Pentester treffen diese Mitigations potentiell recht schmerzhaft, da sie das derzeitige Schadsoftware-Einfallstor #1 direkt absichern (sollen): Email und Office-Applikationen. Windows 10 und ein aktuell gehaltener Windows Defender sind bereits im Default-Zustand recht effektiv – Grund genug, zu testen ob die zusätzlichen Features die Latte noch höher legen können!

Allgemeine Infos über die Attack Surface Reduction findet man in der Microsoft Dokumentation.

Wir starten mit einem generellen Funktionstest: Mit Kali Linux und Unicorn erstellen wir eine Fileless Malware und verstecken diese in einem Word-2003-Macro, welches beim Öffnen des Dokuments automatisch ausgeführt wird. Dabei wird eine Meterpreter Session zum Angreifer erzeugt.

Wir testen ausserdem die Tools Mimikatz und Kekeo, einerseits um Credentials, andererseits um Kerberos Ticket auszulesen:

Nun konfigurieren wir Defender, idealerweise über Group Policies, denn wir sind Enterprisey 😉 Die offizielle Anleitung ist hier zu finden.
An dieser Stelle auch noch der Hinweis auf ein Beispiel-Ruleset im sehr hilfreichen Blog von Gunnar Haslinger.

Nach gpupdate /force am Testclient führen wir das Malware-verseuchte Word-File neu aus. Wie auf den folgenden Screenshots zu sehen, wird der Angriff erfolgreich blockiert.

 

Unsere Angriffe mit Mimikatz und Kekeo zeigen sich jedoch vom neuen Schutzmechanismus recht unbeeindruckt. Wir können weiterhin Kerberos-Tickets exportieren und Passwörter auslesen.

Dafür bekommen wir nun auf unseren Lab-Notebooks alle paar Sekunden eine Warnmeldung von Defender, die nach näherer Betrachtung im Eventlog von VmWare Workstation auszugehen scheint. Ohne dem näher nachzugehen – das wäre im Produktivbetrieb so nicht brauchbar.

Auf der Microsoft ASR Demo Page  findet sich leider kein Testcase zum Feature lsass Protection / 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 – wir haben mal nachgefragt, was Sache ist. Sollte eine brauchbare Antwort eintreffen, werden wir den Blogpost updaten!

 

Das Unsigned-Executable-From-USB-Stick-Feature haben wir auch kurz probiert:

Dies funktioniert wie erwartet. Es stellt sich aber die Frage, ob dies in der Praxis einen relevanten Schutz darstellt. Selbst das oben genannte Tool Mimikatz ist vom Programmierer digital signiert und wird daher nicht blockiert (um genau zu sein: Defender blockiert das File erfolgreich, aber aufgrund der AV-Signatur, nicht aufgrund der ASR-Settings). Eine Whitelisting, Application Control oder USB-Management Lösung ersetzt das Feature daher nicht.

 

Fazit:
Auf den ersten Blick stellen einige (wenige) der verfügbaren Protection Settings tatsächlich eine größere Hürde für Angreifer dar, zumindest wenn man default-Scriptkiddie-Attacken aus Google-Anleitungen betrachtet.  Inwieweit dieser Schutzmechanismus doch noch umgangen werden kann, wird sich noch zeigen – Child-Prozesse aus Office-Anwendungen heraus nicht mehr erzeugen zu können, dürfte aber schon mal sehr effektiv sein – sofern nicht durch irgendeinen Business-Case nicht im Unternehmen implementierbar.

Windows Defender ist unserer Praxiserfahrung nach daher zu einem ziemlich bissigen Antimalware-Tool geworden und dem ein oder anderen namhaften Konkurrenten duchaus überlegen. Wer Defender im Unternehmen einsetzt, sollte die neuen Mitigations daher unbedingt austesten!