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: Ethernet Header
0x0030: .... 0100 5e00 00fc 6451 06a1 43c6 8100
0x0040: 00a7 0800
0100 5e00 00fc : Destination MAC for multicast address used IPv4 Header 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: 224.0.0.252 - 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.
--- |
Johannes 4043 Posts ISC Handler Aug 5th 2016 |
Thread locked Subscribe |
Aug 5th 2016 4 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. |
Anonymous |
Quote |
Aug 5th 2016 4 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?
Tom |
Anonymous |
Quote |
Aug 7th 2016 4 years ago |
Sign Up for Free or Log In to start participating in the conversation!