My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Odd DNS Requests that are Normal

Published: 2019-04-16. Last Updated: 2019-04-16 04:05:07 UTC
by Johannes Ullrich (Version: 1)
4 comment(s)

If you ever heard me talk about DNS, you will know that I am a big fan of monitoring DNS queries, and I think DNS query logs are the best "band for the buck" log source to detect anomalous behavior. Everything that happens on your network, good or bad, tends to be reflected in DNS.

But there are a couple common "odd" DNS request types that are often mistaken for malicious, or unusual but are actually quite normal. Here are my favorite once:

- Anti Malware Checks:

I got an example from Sophos Anti Virus here, but other vendors use a similar technique:

0.0.3.0.0.0.0.0.0.2.0.0.0.0.1.01.00.sfi_unknown.f.01.mac.sophosxl.net
0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.sfi_unknown.b.f.01.mac.sophosxl.net
3.1o19sr00s2s17s4qp3759pn9ro30n2n4n941on29s3s35qppp742380s6487np3.poqp0r741pn37393648s20n65203rn4o44387s5831o276q6s5rqsr16n809qp4.86752ss34q9sns005o.35n2s0s521p9rn7o75q0r479rpqq7o0oq6r6o20p.i.01.mac.sophosxl.net
3.1o18sr00s2s17s4qp3759pn9ro30n2n4n941on29s3s35qppp742380s6487np3.poqp0r741pn37393648s2779qp6or2108n4o66o276n931p8287709r73q098rp.86752ss34q9sns005o3pp76q83qr6344r79q7rpns9.485n1675n4750q4n.i.01.mac.sophosxl.net
0.0.3.0.0.0.0.0.0.2.0.0.0.0.1.01.00.sfi_unknown.f.01.mac.sophosxl.net
0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.sfi_unknown.b.f.01.mac.sophosxl.net
3.1o19sr00s2s17s4qp3759pn9ro30n2n4n941on29s3s35qppp742380s6487np3.poqp0r741pn37393648s20n65203rn4o44387s5831o276q6s5rqsr16n809qp4.86752ss34q9sns005o.35n2s0s521p9rn7o75q0r479rpqq7o0oq6r6o20p.i.01.mac.sophosxl.net
3.1o18sr00s2s17s4qp3759pn9ro30n2n4n941on29s3s35qppp742380s6487np3.poqp0r741pn37393648s2779qp6or2108n4o66o276n931p8287709r73q098rp.86752ss34q9sns005o3pp76q83qr6344r79q7rpns9.485n1675n4750q4n.i.01.mac.sophosxl.net

At first sight, you may mistake these requests for typical DNS covert channels. But they are actually associated with Sophos Antivirus. The reason for these queries is that Anti-Malware uses DNS to check if certain files are malicious. The software will send a hash of the file to the vendor and receive back an indication if the file is malicious or not. This will also allow the vendor to compile statistics on the popularity of certain software which will then often be used to compile risk scores (sorry... feed a machine learning AI engine that will protect you from 0-day attacks... or something like this if you read the vendor ads for various products like this). In some ways, this is an exfiltration activity. Just not malicious.

- Mail Servers

We all know that clients usually try to resolve A or AAAA records. But let's take a look at the snapshot below of the records types from a quick query log sample (collected via bro in this case):

The high percentage of PTR records may appear odd. In this case, however, the network includes a busy mail server. Mail servers, for anti-spam filtering, often resolve IP addresses to match forward and reverse resolution.

- Other .arpa hostnames

Talking about PTR records. Pretty much everybody reading this, probably knows about in-addr.arpa and ipv6.arpa and how it is used for reverse resolution. But these are not the only ".arpa" records you see. One record I see more and more is ipv4only.arpa. This record is used to detect if the host is on an IPv6 only network, and DNS64 is used to map IPv4 addresses to IPv6. This record should resolve to 192.0.0.170/171. Only the A record exists. For a AAAA query, you will not get an answer unless your name servers (do to DNS64), is making one up. There are actually a few more .arpa hostnames but this is the one I usually see quite frequently.

- develooper.com

When I saw this first, it looked like a typosquatting domain to me. But the company behind this domain is an active contributor to a number of open source projects, and in my case, it was their contribution of resources to perl.org that triggered the DNS requests.

Any odd DNS requests that you ran down to only find them to be harmless?

 

 


 

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

Keywords:
4 comment(s)
My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Comments

Thx Johannes for sharing,

Another odd DNS is SPF/DMARC and others in TXT records ☺

Best Regards
@Rmkml
There are some strange .io domains that I traced back to a company that exfiltrates available wifi network that way in order to find one that can be used.
A great IOC detection tool is to simply monitor for and alert on TXT record queries to the Internet. Filter out all mail servers first and then monitor. Apple devices like to query for a few specific URLs so filter those URLs out as well. Once you've done that it will be remarkably quiet.

For the last several years every pen tester has tried to use DNS Tunneling against us and hundreds of TXT record queries occurring within a few seconds when there have been none for weeks is a pretty good indicator. :-)

If you have a Check Point firewall enable its IPS signature for DNS Tunneling. It stopped every attempt at DNS Tunneling that anyone threw against it using all variations and never false positived ones in all of the years it has been enabled.
You also should monitor for and alert on devices trying to make direct DNS queries to the Internet instead of going through your designated Forwarders. That can be poorly designed software (or a poorly designed network) but often is newly installed malware just looking to see if it has a path to the Internet.

One newer cause, though, is internal DNS servers (Microsoft) attempting to do queries directly to the Internet to validate DNSSEC signatures. That can be turned off with a registry key so they're not all trying to do it individually but will instead use the chain of internal DNS servers you've set up. I think that started with Server 2010. "newer cause" because DNSSEC is still very slowly gaining traction after all these years.

One older cause is ******* admins hard-coding their favorite DNS servers on systems rather than using the designated ones. Blocking this behavior at the firewall is a good way to stop it and detect it.

Diary Archives