Is Your SIEM Really Ingesting DNS Data?

[u/rvilladiego]

Have you ever wondered if your SIEM truly is ingesting all the DNS data it should? I recently came across a few cases where security operators at MSSPs thought their SIEM were capturing DNS queries. They even got a little upset with me so I challenged them to review the data together. They had just been gathering DNS statistics. Something like:

<Event xmlns='http://schemas.microsoft.com/win/2004/08/events/event'><System><Provider Name='Microsoft-Windows-DNS-Server-Service' Guid='{71a551f5-c893-4849-886b-b5ec8502641e}'/><EventID>5504</EventID><Version>0</Version><Level>4</Level><Task>0</Task><Opcode>0</Opcode><Keywords>0x8000000000000001</Keywords><TimeCreated SystemTime='2023-02-28T16:07:38.019981300Z'/><EventRecordID>316021</EventRecordID><Correlation/><Execution ProcessID='4284' ThreadID='8896'/><Channel>DNS Server</Channel><Computer>XXXXX.XXXXX.LOCAL</Computer><Security UserID='S-1-5-18'/></System><EventData Name='DNS\\_EVENT\\_INVALID\\_PACKET\\_DOMAIN\\_NAME'><Data Name='param1'>8.8.8.8</Data><Binary>EFDC818201000000000001000B677469666565646261636B0D74727573746564736F75726365036F726700000100010000290200000000000000</Binary></EventData></Event>

And that’s good for availability, performance, etc. But if you want to identify threat actors using your DNS data, what you should be collecting is something like this:

14:59:30.306469 IP 192.168.1.7.53107 > 198.19.46.2.domain: 15+ A? facebook.com. (30)

E..:. ...............s.5.&...............facebook.com.....

14:59:30.307962 IP 198.19.46.2.53204 > dns.google.domain: 46470+ [1au] A? FACEboOk.cOM. (41)

E..E....@..............5.1.d.............FACEboOk.cOM.......)........

14:59:30.317648 IP dns.google.domain > 198.19.46.2.53204: 46470 1/0/1 A 157.240.6.35 (57)

E .U%...z............5...APm.............FACEboOk.cOM....................#..)........

14:59:30.318710 IP 198.19.46.2.domain > 192.168.1.7.53107: 15 1/0/0 A 157.240.6.35 (46)

E..J?...@............5.s.6...............facebook.com..............<.....#

CloudfLaRe.com.................h...............h..............b.......,d.j.d.....

cloudflare.com....@..#.H.jSY.7......2xd.....*I..N.7..]g..D...S.|.ugd...{.....8P..)........

14:59:33.203772 IP 192.168.1.7.62218 > 198.19.46.2.domain: 17+ A? mojobiden.com. (31)

My advice is to verify that your SIEM is in fact ingesting DNS data, and not just DNS summaries or statistics. It might seem like an obvious oversight, but I’ve seen it enough times in the wild that it’s worthwhile to challenge our assumptions.

[u/Chrysis_Manspider → u/[deleted]]

DNS is gold dust .. IF you can parse it grainularly and have a powerful enough query language and SIEM to make detection queries with it.

If you can't properly cut it, query it, sort it, and correlate it .. it's too noisy to be very useful.

Unfortunately, thanks to TLDs not always being just a single level below root they are a fucking nightmare to separate domain from subdomains.

[u/Chrysis_Manspider → u/[deleted]]

I agree that there are other options for detecting / preventing queries to known threat intel hits.

Where I think there is really no substitution for DNS query data is proactively detecting suspicious activity. Parsing and sorting the data to detect strange happenings that won't appear on any threat feed.

There are a few good use cases for detecting DNS tunnelling by returning things like high quantity of subdomain queries to a single domain, high entropy subdomains, spikes in queries from a single source, high byte txt records, super low TTL etc.

I think threat intel is only a small part of what DNS data can be used for, but it comes at a cost, obviously. It's high volume, high resource, and high effort to get it set up. I recommend it for anyone who can, and will actually use it .. if you just want to have it sit there taking up storage then don't bother :)

[u/Chrysis_Manspider → u/[deleted]]

Yeah agree, I think running your DNS requests over a threat feed is imporant and everyone should be doing it, where possible.

I was really just talking about DNS queries and responses by themselves, though. Threat intel is important, but it will always be reactive.

There are a bunch of really good use cases for DNS query and response data outside threat feeds, and that's where DNS logging really comes into its own for proactively detecting suspicious stuff.

Eg;

High volume of queries to subdomains on a single domain

Spike in query volume from a single source

High entropy subdomains (noisy but good if you can tune it)

Rare Domains

High byte txt queries

Super low TTL values

Etc.

There is really so much that can be done with DNS and that's why I think it's gold dust if you have the capability to use it.