Odd Packet: Any ideas where this comes from?

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. --- Johannes B. Ullrich, Ph.D. STI\|Twitter\|LinkedIn I will be teaching next: Intrusion Detection In-Depth - SIEM Summit & Training 2019	Johannes 3631 Posts ISC Handler
Subscribe	Aug 5th 2016 3 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 3 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 3 years ago

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

I will be teaching next: Intrusion Detection In-Depth - SIEM Summit & Training 2019

Johannes

3631 Posts
ISC Handler

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

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