Sign in Subscribe
By Caster in NetSec —

Neurotransmitter: Detecting network attacks on Windows with Suricata

Poisoning attacks against Windows machines have become well known among pentesters. In this article, I will demonstrate how to detect poisoning attacks using Suricata.

Neurotransmitter: Detecting network attacks on Windows with Suricata

Poisoning attacks against Windows machines have become well known among pentesters. In this article, I will demonstrate how to detect poisoning attacks using Suricata.

Caster - Neurotransmitter

Genre: Defensive
Label: exploit.org
Release Date: 12 May 2024

Performed by: Caster
Written by: Magama Bazarov

Intro

This is an article about detecting network attacks on Windows machines using Suricata IDS. It is specifically about detecting the mitm6 attack and LLMNR/NBT-NS/MDNS Poisoning using Responder.

Mitigating the LLMNR/NBT-NS attack is actually simple, you can just turn them off. They are old protocols and networks are turning them off. But things are not quite so sweet with MDNS. This protocol is actively used by printers, Apple devices, Chromecast and others. And it is not possible to disable MDNS in modern networks.

To stop mitm6 attacks, most experts recommend disabling IPv6, but this is not always possible due to specific features of some infrastructure.

And in this article I will demonstrate signatures for Suricata IDS to detect the above mentioned attacks.

Deconstruction I: mitm6

Windows machines tend to prioritize IPv6 over IPv4 protocol. This is what attackers can use to conduct MITM attacks. The most popular case is the use of the mitm6 tool.

mitm6 is a tool to exploit the prioritization of IPv6 over IPv4 in Windows environments by sending special DHCPv6 packets to impose its IPv6 address as the DNS server address for machines on Windows. This can lead to a MITM attack and subsequent Relay attacks. To understand how to monitor the network environment for mitm6 exploitation, it is necessary to examine in detail the network traffic when mitm6 is being exploited.

DHCPv6 Packet Types

The DHCPv6 protocol has the following message types:

  • DHCPv6 Solicit: This message is sent by the client to initiate communication with DHCPv6 servers. The client broadcasts or multicasts this message to identify available DHCP servers on the network. DHCPv6 servers, upon receiving Solicit, may respond with a DHCP Advertise message offering their configuration.
  • DHCPv6 Advertise: This message is the DHCPv6 server's response to a DHCPv6 Solicit message received from the client. The server uses this message to tell the client that it is available to send configuration (def. GW, DNS Server, etc)
  • DHCPv6 Request: After receiving DHCPv6 Advertise, the client selects a DHCPv6 server and sends a DHCP v6-Request message to that server to formally request the proposed settings. This message can also be used to confirm or update previously received configuration settings when reconnecting the device to the network.
  • DHCPv6 Reply: The DHCPv6 Reply message is used by the server to confirm the provisioning or updating of an IP address and other configuration parameters to a device. It can also be sent by the server in response to a DHCP Release message from a client when the client releases a leased IP address.

Not a full SLAAC attack

A typical situation in which an attacker imposes itself as the IPv6 address of a DNS server against a Windows machine:

Attacker - fe80::20c:29ff:fe4d:cc91

Victim - fe80::cf5d:312a:57d3:301a

However, when using mitm6 - it is not a full SLAAC attack that occurs, i.e. the attacker does not position itself as a full router, it only imposes itself as a DNS server at the IPv6 level. This is achieved by sending a DHCPv6 Advertise.

The attacker imposes itself as a DNS server on the IPv6 layer
The IPv6 address of the attacker as the DNS server on the target Windows machine

The attacker imposed itself as a DNS server on the IPv6 layer by sending a special DHCPv6 Advertise message:

DHCPv6 Advertise (with option 23)
Attack scheme using mitm6

Detection

Obviously, DHCPv6 Advertise and DHCPv6 Reply messages within a network segment with Windows machines would be an anomaly, since no DHCPv6 server is expected to be there. I will write a signature on these two types of DHCPv6 packets so that Suricata can detect them in traffic and notify the network administrator.

To be honest, there is nothing extraordinary about writing signatures for mitm6, all you need to do is study the packet structure carefully and write a signature (following Suricata syntax)

I think you can start with DHCPv6 Advertise. According to RFC 8415, the opcode is 2, you can write a signature for that. Also, when writing a signature, it is worth considering that DHCPv6 uses UDP ports 546 and 547. The mitm6 attacker was sending this DHCPv6 Advertise from the source UDP port 547 to the destination UDP port 546

RFC 8415 (DHCPv6 Advertise)
Byte 02 (DHCPv6 Advertise)

Suricata Signature

Suricata IDS is usually deployed inside the infrastructure and takes mirrored legitimate traffic as input. But in my case, to test the signature performance, I simply installed Suricata on my Kali Linux and will use pcap as input, which is a dump of the traffic where the attacker conducted the mitm6 attack.

In my configuration the rules for Suricata are in /var/lib/suricata/rules, referencing the suricata.rules file

suricata.yaml file

Writing a signature:

alert udp any any -> any 546 (msg:"Suspicious DHCPv6 Advertise Packet Detected, Possible attack using mitm6"; content:"|02|"; depth:1; offset:0; reference:url,https://blog.exploit.org/caster-neurotransmitter/; sid:100000; rev:1;)

There:

alert - indicates the type of rule. In this case, alert indicates that a warning will be generated when the rule is triggered;

udp - indicates the transport layer protocol to which the rule will respond. udp indicates that the rule applies to UDP traffic;

any any -> any 546 - the first any indicates any source IP address, the second any indicates any source port, the arrow -> indicates the direction of traffic from source to destination, the third any indicates any destination IP address, 546 indicates the destination port, which is the standard port for DHCPv6 clients;

msg: "Suspicious DHCPv6 Advertise Packet Detected, Possible attack using mitm6" is the message that will be displayed when the rule is triggered;

content:"|02|" is an indication of the specific packet content that must be detected for the rule to be triggered. |02| means that the rule is looking for a packet that has the byte 02 in the specified position. An entry in the form |02| is used to denote a hexadecimal value in the content.

depth:1 - specifies how deep in the packet to search for the specified content means that only the first byte of the packet should be checked;

offset:0 - defines the initial position in the packet from which the content check starts. 0 means that the check starts from the beginning of the packet;

reference:url, - link to an external resource where you can learn more about the detected security problem;

sid:1000000 - the unique rule identifier (SID, or Signature ID). This is a number that uniquely identifies a rule in a rule set;

rev:1 - indicates the version of the rule. This is a number that is incremented when the rule is updated or modified.

Verify that the signature works:

caster@kali:/var/lib/suricata/rules$ sudo suricata -c /etc/suricata/suricata.yaml -r /mnt/hgfs/neurotransmitter/mitm6.pcap
i: suricata: This is Suricata version 7.0.3 RELEASE running in USER mode
i: threads: Threads created -> RX: 1 W: 4 FM: 1 FR: 1   Engine started.
i: suricata: Signal Received.  Stopping engine.
i: pcap: read 1 file, 195 packets, 15654 bytes
caster@kali:/var/lib/suricata/rules$ cat fast.log | grep -i "DHCPv6 Advertise"
05/11/2024-15:11:18.486526  [**] [1:100000:1] Suspicious DHCPv6 Advertise Packet Detected, Possible attack using mitm6 [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:547 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:546
Detected DHCPv6 Advertise in traffic dump using Suricata

This way you can detect DHCPv6 Advertise packets in the traffic, which may indicate an attempted attack using mitm6. It would also be useful to write a signature for the DHCPv6 Reply message that is used by the DHCPv6 server (in our case, the mitm6 attacker is a DHCPv6 server, only malicious)

According to RFC 8415 for DHCPv6 Reply, the code is 7 (07)

RFC 8415 (DHCPv6 Reply)
Byte 07 (DHCPv6 Reply)

Signature to detect DHCPv6 Reply:

alert udp any any -> any 546 (msg:"Suspicious DHCPv6 Reply Packet Detected, Possible attack using mitm6"; content:"|07|"; depth:1; offset:0; reference:url,https://blog.exploit.org/caster-neurotransmitter/; sid:1000001; rev:1;)

There:

alert - indicates the type of rule. In this case, alert indicates that a warning will be generated when the rule is triggered;

udp - indicates the transport layer protocol to which the rule will respond. udp indicates that the rule applies to UDP traffic;

any any -> any 546 - the first any indicates any source IP address, the second any indicates any source port, the arrow -> indicates the direction of traffic from source to destination, the third any indicates any destination IP address, 546 indicates the destination port, which is the standard port for DHCPv6 clients;

msg: "Suspicious DHCPv6 Reply Packet Detected, Possible attack using mitm6" is the message that will be displayed when the rule is triggered;

content:"|07|" is an indication of the specific packet content that must be detected for the rule to be triggered. |07| means that the rule is looking for a packet that has the byte 07 in the specified position. An entry in the form |07| is used to denote a hexadecimal value in the content.

depth:1 - specifies how deep in the packet to search for the specified content means that only the first byte of the packet should be checked;

offset:0 - defines the initial position in the packet from which the content check starts. 0 means that the check starts from the beginning of the packet;

reference:url, - link to an external resource where you can learn more about the detected security problem;

sid:1000001 - the unique rule identifier (SID, or Signature ID). This is a number that uniquely identifies a rule in a rule set;

rev:1 - indicates the version of the rule. This is a number that is incremented when the rule is updated or modified.

Verify that the signature works:

caster@kali:/var/lib/suricata/rules$ sudo suricata -c /etc/suricata/suricata.yaml -r /mnt/hgfs/neurotransmitter/mitm6.pcap
i: suricata: This is Suricata version 7.0.3 RELEASE running in USER mode
i: threads: Threads created -> RX: 1 W: 4 FM: 1 FR: 1   Engine started.
i: suricata: Signal Received.  Stopping engine.
i: pcap: read 1 file, 195 packets, 15654 bytes
caster@kali:/var/lib/suricata/rules$ cat fast.log | grep -i "DHCPv6 Reply"                                     
05/11/2024-15:11:18.554896  [**] [1:1000001:1] Suspicious DHCPv6 Reply Packet Detected, Possible attack using mitm6 [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:547 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:546
Detected DHCPv6 Reply packet

In this way, it is possible to detect mitm6 attacks, by which an attacker imposes itself as a DNS server on the IPv6 layer.

Malicious WPAD Response over IPv6

Because an attacker using mitm6 can spoof DNS, an attacker can exploit WPAD to intercept and manipulate web traffic, such as:

  • DNS Spoofing: An attacker can send spoofed DNS responses for WPAD requests, forcing clients to download PAC files from a malicious server. This allows the attacker to control web traffic by routing it through their proxy server;
  • Man-in-the-Middle (MitM) Attack: With spoofed proxy settings, an attacker can intercept, modify, or block web traffic.

However, it is possible to write a signature that would detect malicious DNS responses against WPAD:

alert udp ::/0 53 -> any any (msg:"Malicious WPAD Response over IPv6"; byte_test:1,&,0x7F,2; content:"|00 04|wpad"; nocase; fast_pattern; reference:url,https://blog.exploit.org/caster-neurotransmitter/; sid:1000002; rev:1;)

alert - indicates the type of rule. In this case, alert indicates that a warning will be generated when the rule is triggered;

udp - indicates the transport layer protocol to which the rule will respond. udp indicates that the rule applies to UDP traffic;

::/0 53 is the source IP address and port. ::/0 means any IPv6 address, and 53 is the standard DNS port;

-> - indicates the direction of traffic - from source to destination;

`msg: "Malicious WPAD Response over IPv6" is the message that will be displayed when the rule is triggered;

byte_test:1,&,0x7F,2; - used to check a specific flag in the DNS header:

  • DNS header starts with 12 bytes. At position 2 (given the offset, where 0 is the first byte) is the part of the header that includes the operation control flags (such as QR, OPCODE, AA, TC, RD, RA, Z, and RCODE);
  • The 0x7F mask is applied to this byte to check if the highest (most significant) bit is set. In the DNS context, this is the QR bit, which indicates whether the message is a request (0) or a response (1)

This byte_test:1,&,0x7F,2 is used to ensure that the packet is a DNS response and not a request. This is important because the signature is aimed at detecting malicious DNS responses associated with WPAD. An attacker can use spoofed DNS responses to manipulate WPAD settings and redirect traffic through a malicious proxy;

content:"|00 04|wpad" is the packet content that must be detected to activate the signature. |00 04| is a byte sequence followed by the string "wpad";

nocase is an option specifying that the comparison should ignore letter case;

fast_pattern - a directive that optimizes the search for this signature by using the longest content string as the primary filter;

sid:1000002 - the unique rule identifier (SID, or Signature ID). This is a number that uniquely identifies the rule in the rule set;

rev:1 - indicates the version of the rule. This is a number that is incremented when the rule is updated or modified.

Verification of this signature:

caster@kali:/var/lib/suricata/rules$ sudo suricata -c /etc/suricata/suricata.yaml -r /mnt/hgfs/neurotransmitter/mitm6.pcap
i: suricata: This is Suricata version 7.0.3 RELEASE running in USER mode
i: threads: Threads created -> RX: 1 W: 4 FM: 1 FR: 1   Engine started.
i: suricata: Signal Received.  Stopping engine.
i: pcap: read 1 file, 195 packets, 15654 bytes
caster@kali:/var/lib/suricata/rules$ sudo cat fast.log | grep "Malicious WPAD"                                            
05/11/2024-15:11:40.135471  [**] [1:1000002:1] Malicious WPAD Response over IPv6 [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:53 -> fe80:0000:0000:0000:0000:0000:6216:0001:58464
05/11/2024-15:11:40.088230  [**] [1:1000002:1] Malicious WPAD Response over IPv6 [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:53 -> fe80:0000:0000:0000:0000:0000:6216:0001:52836
Detected WPAD Response over IPv6

This is how you can detect malicious DNS responses against WPAD.

Deconstruction II: Responder

Responder is a pentester tool used to spoof LLMNR/NBT-NS/MDNS protocols for the further purpose of capturing Windows credentials. This is accomplished by "poisoning" LLMNR/NBT-NS/MDNS requests, where the attacker impersonates a service requested by legitimate hosts. Responder consists of two parts:

  • Sniffer - analyzes the airwaves for LLMNR/NBT-NS/MDNS protocols;
  • Poisoner - responds to name resolution requests for LLMNR/NBT-NS/MDNS, which causes the attacker to impersonate the requested resource. And then the attacker is able to obtain a NetNTLMv2-SSP hash of the account on the Windows machine, this is accomplished by raising a false SMB server.

Probably one of the most popular pentester tools when it performs internal security analysis, but Responder can also be found on the network. It's not even the tool itself, it's the protocols that are the problem, the values of the headers of which will be used to write the signature.

Keep in mind that LLMNR and MDNS can operate at the IPv6 level. Therefore, the written signatures will support IPv4 and IPv6

LLMNR Poisoning Detection

This is what the LLMNR Response packet generated by Responder when attacking a Windows machine looks like. It is the byte sequence |80 00 00 01 00 01| that indicates that this packet is an LLMNR Response. A signature will be written for this byte sequence.

LLMNR Poisoning
Attacker: 10.10.140.151, Victim: 10.10.140.148
LLMNR Poisoning Scheme

Signature for LLMNR Poisoning detection:

alert udp any 5355 -> any any (msg:"LLMNR Response Packet Detected, Possible LLMNR Poisoning"; flow:stateless; reference:url,https://blog.exploit.org/caster-neurotransmitter/; content:"|80 00 00 01 00 01|"; sid:1000003; rev:1;)

There:

alert - indicates the type of rule. In this case, alert indicates that a warning will be generated when the rule is triggered;

udp - indicates the transport layer protocol to which the rule will respond. udp indicates that the rule applies to UDP traffic;

any 5355 - Source IP and port parameters. This specifies that the source IP address can be anything and the source port is 5355, which is the standard port for LLMNR;

-> - a direction symbol to indicate that traffic is going from source to destination;

any any - destination IP and port parameters. Indicates that the destination IP and port can be any;

msg: "LLMNR Response Packet Detected, Possible LLMNR Poisoning" is the message that will be displayed when the rule is triggered;

flow:stateless - specifies that traffic processing and inspection is independent of the state of the connection. A common practice for UDP traffic where there is no connection established before sending data, connectionless protocol;

reference:url, - a link to an external resource where you can learn more about the detected security issue

content:"|80 00 00 00 01 00 00 01|" - the content being searched for in the packet, a byte sequence representing a specific part of the LLMNR packet, namely the response, which may be an indicator of an attack;

sid:1000003 -the unique rule identifier (SID, or Signature ID). This is a number that uniquely identifies a rule in a rule set;

rev:1 - indicates the version of the rule. This is a number that is incremented when a rule is updated or modified.

Signature check for LLMNR Poisoning:

caster@kali:/var/lib/suricata/rules$ sudo suricata -c /etc/suricata/suricata.yaml -r /mnt/hgfs/neurotransmitter/responder.pcap
i: suricata: This is Suricata version 7.0.3 RELEASE running in USER mode
i: threads: Threads created -> RX: 1 W: 4 FM: 1 FR: 1   Engine started.
i: suricata: Signal Received.  Stopping engine.
W: pcap: 1/6th of packets have an invalid checksum, consider setting pcap-file.checksum-checks variable to no or use '-k none' option on command line.
i: pcap: read 1 file, 214 packets, 38861 bytes
caster@kali:/var/lib/suricata/rules$ cat fast.log | grep "LLMNR Poisoning"         
05/11/2024-15:04:02.651598  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5355 -> 10.10.140.148:52336
05/11/2024-15:04:02.649755  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5355 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:52336
05/11/2024-15:04:07.722616  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5355 -> 10.10.140.148:61719
05/11/2024-15:04:02.692005  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5355 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:57503
05/11/2024-15:04:02.653821  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5355 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:65405
05/11/2024-15:04:02.694108  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5355 -> 10.10.140.148:57503
05/11/2024-15:04:02.657869  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5355 -> 10.10.140.148:65405
05/11/2024-15:04:10.150776  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5355 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:59962
05/11/2024-15:04:12.189707  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5355 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:56977
05/11/2024-15:04:02.704418  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5355 -> 10.10.140.148:59840
05/11/2024-15:04:14.201634  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5355 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:57234
05/11/2024-15:04:14.203445  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5355 -> 10.10.140.148:57234
05/11/2024-15:04:10.152137  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5355 -> 10.10.140.148:59962
05/11/2024-15:04:14.207770  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5355 -> 10.10.140.148:53272
05/11/2024-15:04:02.699597  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5355 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:59840
05/11/2024-15:04:07.718321  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5355 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:61719
05/11/2024-15:04:07.724518  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5355 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:51006
05/11/2024-15:04:07.728870  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5355 -> 10.10.140.148:51006
05/11/2024-15:04:10.154647  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5355 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:62533
05/11/2024-15:04:10.161463  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5355 -> 10.10.140.148:62533
05/11/2024-15:04:12.184020  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5355 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:55869
05/11/2024-15:04:12.187332  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5355 -> 10.10.140.148:55869
05/11/2024-15:04:12.192088  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5355 -> 10.10.140.148:56977
05/11/2024-15:04:14.205514  [**] [1:1000003:1] LLMNR Response Packet Detected, Possible LLMNR Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5355 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:53272
Detected LLMNR Poisoning in traffic

This is how LLMNR Poisoning can be detected with Suricata.

NBT-NS Poisoning Detection

This is what the NBT-NS Response packet generated by Responder when attacking a Windows machine looks like. The byte sequence |85 00 00 00 00 00 00 00 00 01| indicates that this is an NBNS Response packet, which is a characteristic of Responder's utility to impersonate the requested host. It is this sequence of bytes on which the detection will be written. In this context, the attacker at 10.10.140.151 has sent an NBNS request from a legitimate Windows machine at 10.10.140.148

NBT-NS Response Packet
NBT-NS Poisoning Scheme

NBT-NS Poisoning Detection Signature:

alert udp any 137 -> any 137 (msg:"NBT-NS Response Packet Detected, Possible NBT-NS Poisoning"; flow:stateless; reference:url,https://blog.exploit.org/caster-neurotransmitter/; content:"|85 00 00 00 00 01|"; sid:1000004; rev:1;)

There:

alert - indicates the type of rule. In this case, alert indicates that a warning will be generated when the rule is triggered;

udp - indicates the transport layer protocol to which the rule will respond. udp indicates that the rule applies to UDP traffic;

any 137 -> any 137 are the source and destination network addresses and ports. "any" indicates any IP address, and 5353 indicates the port that is used by the MDNS protocol;

msg: "NBT-NS Response Packet Detected, Possible NBT-NS Poisoning" is the message that will be displayed when the rule is triggered;

flow:stateless - specifies that traffic processing and inspection is independent of the state of the connection. A common practice for UDP traffic where there is no connection established before sending data, connectionless protocol;

reference:url, - a link to an external resource where you can learn more about the detected security issue

content:"|85 00 00 00 00 00 00 00 01|" - the content that is being searched for in the packet, a byte sequence representing a specific part of the MDNS packet, namely the response, which can be an indicator of an attack;

sid:1000004 - the unique rule identifier (SID, or Signature ID). This is a number that uniquely identifies a rule in a rule set;

rev:1 - indicates the version of the rule. This is a number that is incremented when a rule is updated or modified.

Verification of this signature:

caster@kali:/var/lib/suricata/rules$ sudo suricata -c /etc/suricata/suricata.yaml -r /mnt/hgfs/neurotransmitter/responder.pcap
i: suricata: This is Suricata version 7.0.3 RELEASE running in USER mode
i: threads: Threads created -> RX: 1 W: 4 FM: 1 FR: 1   Engine started.
i: suricata: Signal Received.  Stopping engine.
W: pcap: 1/6th of packets have an invalid checksum, consider setting pcap-file.checksum-checks variable to no or use '-k none' option on command line.
i: pcap: read 1 file, 214 packets, 38861 bytes
caster@kali:/var/lib/suricata/rules$ cat fast.log | grep "Possible NBT-NS Poisoning"
05/11/2024-15:03:52.667265  [**] [1:1000004:1] NBT-NS Response Packet Detected, Possible NBT-NS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:137 -> 10.10.140.148:137
05/11/2024-15:03:55.695511  [**] [1:1000004:1] NBT-NS Response Packet Detected, Possible NBT-NS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:137 -> 10.10.140.148:137
05/11/2024-15:04:02.643623  [**] [1:1000004:1] NBT-NS Response Packet Detected, Possible NBT-NS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:137 -> 10.10.140.148:137
Detected NBT-NS Poisoning

NBT-NS Poisoning can be detected with such a signature.

MDNS Poisoning Detection

Responder can also poison MDNS. Unfortunately, it cannot be completely disabled in the infrastructure, because it is used by printers, Apple devices, Chromecast and other legitimate services on which the normal operation of the infrastructure may depend. But even in this case you can write a signature to detect MDNS Poisoning attack.

MDNS Response Packet
MDNS Poisoning Scheme

It is the byte sequence |84 00 00 00 00 00 00 00 00 01| that indicates that it is the MDNS Response packet that Responder is using to poison. I will write a signature on this byte sequence:

alert udp any 5353 -> any 5353 (msg:"MDNS Response Packet Detected, Possible MDNS Poisoning"; flow:stateless; reference:url,https://blog.exploit.org/caster-neurotransmitter/; content:"|84 00 00 00 00 01|"; sid:1000005; rev:1;)

There:

alert - indicates the type of rule. In this case, alert indicates that a warning will be generated when the rule is triggered;

udp - indicates the transport layer protocol to which the rule will respond. udp indicates that the rule applies to UDP traffic;

any 5353 -> any 5353 are the source and destination network addresses and ports. "any" indicates any IP address, and 5353 indicates the port that is used by the MDNS protocol;

`msg: "MDNS Response Packet Detected, Possible MDNS Poisoning" is the message that will be displayed when the rule is triggered;

flow:stateless - specifies that the processing and inspection of traffic is independent of the state of the connection. A common practice for UDP traffic where there is no connection established before sending data, connectionless protocol;

reference:url, - a link to an external resource where you can learn more about the detected security issue

content:"|84 00 00 00 00 00 00 00 00 01|" - content that is searched for in the packet, a byte sequence representing a specific part of the MDNS packet, namely the response, which can be an indicator of an attack;

sid:1000005 - the unique rule identifier (SID, or Signature ID). This is a number that uniquely identifies a rule in a rule set;

rev:1 - indicates the version of the rule. This is a number that is incremented when a rule is updated or modified.

Checking this signature:

caster@kali:/var/lib/suricata/rules$ sudo suricata -c /etc/suricata/suricata.yaml -r /mnt/hgfs/neurotransmitter/responder.pcap
i: suricata: This is Suricata version 7.0.3 RELEASE running in USER mode
i: threads: Threads created -> RX: 1 W: 4 FM: 1 FR: 1   Engine started.
i: suricata: Signal Received.  Stopping engine.
W: pcap: 1/6th of packets have an invalid checksum, consider setting pcap-file.checksum-checks variable to no or use '-k none' option on command line.
i: pcap: read 1 file, 214 packets, 38861 bytes
caster@kali:/var/lib/suricata/rules$ cat fast.log | grep "Possible MDNS Poisoning"                                      
05/11/2024-15:04:02.644495  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5353 -> 10.10.140.148:5353
05/11/2024-15:04:02.647777  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5353 -> 10.10.140.148:5353
05/11/2024-15:04:02.645660  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5353 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:5353
05/11/2024-15:04:02.649453  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5353 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:5353
05/11/2024-15:04:02.688394  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5353 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:5353
05/11/2024-15:04:02.687508  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5353 -> 10.10.140.148:5353
05/11/2024-15:04:02.689623  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5353 -> 10.10.140.148:5353
05/11/2024-15:04:02.696541  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5353 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:5353
05/11/2024-15:04:07.712160  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5353 -> 10.10.140.148:5353
05/11/2024-15:04:07.715941  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5353 -> 10.10.140.148:5353
05/11/2024-15:04:07.714057  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5353 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:5353
05/11/2024-15:04:10.148777  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5353 -> 10.10.140.148:5353
05/11/2024-15:04:07.723384  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5353 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:5353
05/11/2024-15:04:10.159420  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5353 -> 10.10.140.148:5353
05/11/2024-15:04:10.153749  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5353 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:5353
05/11/2024-15:04:12.180204  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5353 -> 10.10.140.148:5353
05/11/2024-15:04:10.162762  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5353 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:5353
05/11/2024-15:04:12.184453  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5353 -> 10.10.140.148:5353
05/11/2024-15:04:12.181944  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5353 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:5353
05/11/2024-15:04:14.197360  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5353 -> 10.10.140.148:5353
05/11/2024-15:04:14.201315  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} 10.10.140.151:5353 -> 10.10.140.148:5353
05/11/2024-15:04:12.190414  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5353 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:5353
05/11/2024-15:04:14.199816  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5353 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:5353
05/11/2024-15:04:14.206438  [**] [1:1000005:1] MDNS Response Packet Detected, Possible MDNS Poisoning [**] [Classification: (null)] [Priority: 3] {UDP} fe80:0000:0000:0000:020c:29ff:fe4d:cc91:5353 -> fe80:0000:0000:0000:cf5d:312a:57d3:301a:5353
Detected MDNS Poisoning

This is how you can detect MDNS poisoning on your network using Suricata IDS signatures.

Outro

In this research I demonstrated the ability to detect Poisoning attacks on Windows machines using Suricata. I would not call my work complex, the most important thing is to understand how the protocol works at a lower level and what static elements can be grasped to write a special signature. I hope my article will be a solution to the question "What to do if we need to protect the network from mitm6 and we can't turn off IPv6 :("

Subscribe to exploit.org

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
[email protected]
Subscribe