My next class:

Odd Packet: Any ideas where this comes from?

Published: 2016-08-05. Last Updated: 2016-08-05 12:05:26 UTC
by Johannes Ullrich (Version: 1)
2 comment(s)

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.

 

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Keywords:
2 comment(s)
My next class:

Comments

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.
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

Diary Archives