Out reader submitted to us several "odd packets". Of course, I can't resist to figure out what is exactly going on here: The packets appear to include a lengthy pre-ample, but I have no idea what would cause this. After the pre-ample, we got what looksl ike a normal Link-Local Multicast Name Resolution Packet. Maybe some kind of packet logging tool sending packets over the wire to a logging system? Here is the sample packet:
0x0000: 0000 2900 0033 0000 3700 0000 0000 0000 0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 0x0030: 0000 0100 5e00 00fc 6451 06a1 43c6 8100 0x0040: 00a7 0800 4500 0033 355a 0000 0111 599b 0x0050: XXXX XXXX e000 00fc c59d 14eb 001f 0c38 0x0060: 8669 0000 0001 0000 0000 0000 0555 3231 0x0070: 3038 0000 ff00 01
I highlighted the unexplained prefix in red. The reminder appears to be a normal multicast DNS packet:
0x0030: .... 0100 5e00 00fc 6451 06a1 43c6 8100 0x0040: 00a7 0800
0100 5e00 00fc : Destination MAC for multicast address used
0x0040: .... .... 4500 0033 355a 0000 0111 599b 0x0050: XXXX XXXX e000 00fc IPv4, normal header length (20 bytes), TOS=0 Total Datagram Length: 0x33 (51) IP ID: 0x355a, no fragmentation flags, no offset TTL: 1 Protocol: 0x11 (UDP, 17) IP checksum: 0x599b Source IP: [obfuscated, since it was a public routable IP] Destiation IP: 126.96.36.199 - LLMNR Multicast Name Resolution, RFC4795 UDP Header 0x0050: .... .... .... .... c59d 14eb 001f 0c38 Source Port: 50589 Dest. Port: 5355 (normal port for LLMNR) UDP Length: 31 bytes UDP Checksum: 0x0c38 mDNS Payload 0x0060: 8669 0000 0001 0000 0000 0000 0555 3231 0x0070: 3038 0000 ff00 01
Query ID: 0x8669
Query: 05 55 32 31 30 38 00 -> U2108
Please comment or use our contact form to let us know if you have seen traffic like this.
Defending Web Applications Security Essentials - SANS Munich July 2019
Aug 5th 2016
2 years ago
Ethernet hardware should filter preambles, how was this packet captured?
The below would somewhat explain the traffic in my eyes.
(Straight from the RFC)
LLMNR is designed to prevent reception of queries sent by an off-link
attacker. LLMNR requires that responders receiving UDP queries check
that they are sent to a link-scope multicast address. However, it is
possible that some routers may not properly implement link-scope
multicast, or that link-scope multicast addresses may leak into the
multicast routing system. To prevent successful setup of TCP
connections by an off-link sender, responders receiving a TCP SYN
reply with a TCP SYN-ACK with TTL set to one (1).
When LLMNR is utilized as a secondary name resolution service,
queries can be sent when DNS server(s) do not respond. An attacker
can execute a denial of service attack on the DNS server(s), and then
poison the LLMNR cache by responding to an LLMNR query with incorrect
information. As noted in "Threat Analysis of the Domain Name System
(DNS)" [RFC3833], these threats also exist with DNS, since DNS-
response spoofing tools are available that can allow an attacker to
respond to a query more quickly than a distant DNS server. However,
while switched networks or link-layer security may make it difficult
for an on-link attacker to snoop unicast DNS queries, multicast LLMNR
queries are propagated to all hosts on the link, making it possible
for an on-link attacker to spoof LLMNR responses without having to
guess the value of the ID field in the query.
Aug 5th 2016
2 years ago
As for my reading of the RFC, LLMNR operates at layer 4, the transport layer on the OSI modle so it would not explain the long jumbled preamble. But the remark about preamble/frame start being striped at the hardware is dead on, what used to capture this packet?
Aug 7th 2016
2 years ago