2

Sometimes in some network captures that include my DNS server, I find there are failed lookups for what seem like invalid requests.

When viewed in Wireshark these show up with what looks like escaped bytes outside the ASCII range.

An example from Wireshark's query.name > Copy > Bytes > Hex Stream is:

Raw: 03777777128b68481cc5116ceb53bade651327d982751903636f6d00`
As Python bytes: \x03www\x12\x8bhH\x1c\xc5\x11l\xebS\xba\xdee\x13'\xd9\x82u\x19\x03com\x00

You can see there's part of the usual DNS query format there:

  • Signal for 3 bytes, then www
  • Signal for 18 bytes, then... gibberish.
  • Signal for 3 bytes, then com

I can't figure out what the middle bit is supposed to be.

I'm familiar with Punycode for international characters, and I'm reasonably sure that's not what this is.

I don't have access to the hosts that are making the requests. I know some malware tries to resolve things like this, so I'm curious about whether this might indicate the presence of malware.

Edited to add:

Here is a screenshot of the DNS response, as seen by Wireshark: enter image description here

5
  • 3
    Please provide a small packet capture if at all possible. The payload is a good start, but I would like to fully understand the larger context. (flags set, etc.)
    – Andrew B
    Oct 27, 2014 at 22:28
  • I'll add a screenshot later; I don't think I can disclose the IPs and such. FWIW the example I gave was from a response to an A record request, saying "No such name," of course. No exotic flags were set that I could see.
    – bbayles
    Oct 28, 2014 at 2:02
  • @AndrewB, I've added the screenshot of Wireshark's dissection. I have other similar ones, but this should be the one that matches the response name I mentioned.
    – bbayles
    Oct 28, 2014 at 16:26
  • Looks like you caught the reply...can we get a query too?
    – Andrew B
    Oct 28, 2014 at 17:22
  • I only get the responses, unfortunately.
    – bbayles
    Oct 28, 2014 at 18:03

1 Answer 1

1

Punycode is an ASCII encoding, so you are correct that this appears to be garbage. We'd need to see the entire packet to state more than that. I've broken that string up into ASCII and hex byte boundaries below so that it's easier to perceive the packet structure.

(if someone spies a mistake, just edit it in directly)

[03] www
[12][8b] hH
[1c][c5][11] l
[eb] S
[ba][de] e
[13] ' [illegal DNS ASCII: byte 0x27]
[d9][82] u
[19][03] com
[terminating null byte 0x00]

  • Punycode doesn't use bytes above the 7-bit ASCII boundary, which ends at hexadecimal 7F.
  • Even if we were to assume an illegal attempt to embed UTF-8 bytes within this string, those begin with a start byte in the range of hex C2 through F4. The byte immediately following the initial www is hex 12 (form feed) followed by 8B, which is a continuation byte. Definitely not valid UTF-8.

At this point, we're left with three possibilities:

  1. Data corruption
  2. Packets that are designed to exploit a vulnerability
  3. An attempt to encode non-DNS data over the DNS protocol in order to circumvent firewalls, such as VPN software. I haven't spent much time researching implementations of the this, so cannot comment on the likelihood of this being the case. If that's what is happening, I would assume the leading "www" and trailing "com" to be a weak attempt at fooling rudimentary deep packet inspection.
1
  • I thought (1) was unlikely, since all but the middle part is OK, but I agree it's possible. (2) was something I was worried about, but it doesn't seem to be obvious what it's trying to do. (3) is interesting, and I've seen this in the wild before, but not with so little data (and not in the query string). Possibility (4) I think is "someone screwed up a program that causes requests to be generated," but it's a hard thing to Google.
    – bbayles
    Oct 28, 2014 at 2:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .