Odd Packet: Any ideas where this comes from?
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
6451 06a1 43c6: Source MAC. The OUI is a assigned to HP
8100 00a7 : VLAN tag
0800 : ethernet type for IPv4
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
Flags: 0x0000 (this is a query)
Queries: 1, Answers: 0, Name Servers: 0, Additional records: 0
Query: 05 55 32 31 30 38 00 -> U2108
Type: 00 ff - "ANY"
Please comment or use our contact form to let us know if you have seen traffic like this.
| Application Security: Securing Web Apps, APIs, and Microservices | Washington | Dec 13th - Dec 18th 2024 |
Comments
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
Aug 5th 2016
8 years ago
Tom
Anonymous
Aug 7th 2016
8 years ago