Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DNSEssentials detection not working as they should #11663

Open
tbethe opened this issue Jan 14, 2025 · 0 comments
Open

DNSEssentials detection not working as they should #11663

tbethe opened this issue Jan 14, 2025 · 0 comments

Comments

@tbethe
Copy link

tbethe commented Jan 14, 2025

Describe the bug
I believe most of the DNSEssentials detection are broken, but it's quite fundamental and has been there for so long, I fear I am simply not understanding what is going on here. It really seems wrong though. I would like for someone to confirm that this is indeed wrong or explain to me why these detections are indeed correct.

Some contexts of how I understand DNS logging:

As far as I understand, or at least the logging that I am working with, the device that does the logging are the DNS server on the network. They log the queries/responses they get when querying on behalf of clients on the internal network and they log the queries/responses they send back to the clients.

For example, client A queries example.com to resolver X. Resolver X resolves it with some public resolver and relays the response back to client A. In this case you'd get at least 4 entries in the DNS table.

  • Request from client A to resolver X
  • Request from resolver X to outside
  • Response from outside to resolver X
  • Response resolver X to client A.

What the detections look for:

Let's take the 'Excessive anomaly based NXDOMAIN DNS queries detected' as an example.

The description states the intent of this detection: This rule uses anomaly decompose to generate an alert when a client requests an excessive number of DNS queries that return NXDOMAIN (meaning the domain does not exist). This helps identifying C2 communications.

However, the implementation is as follows: The detection looks for logs of type NXDOMAIN (these will always be responses, never queries) and summarized on SrcIp. This is the crux. Should this not be DstIp?

In responses, the SrcIp will always be the resolver! The client will never send responses back to the resolver. An organisation will have just a handful of DNS resolvers at most, so in reality we are detecting if the whole organization has excessive DNS queries which return NXDOMAIN. This is not the purpose of the detection at all.

If we summarized on DstIp, we could monitor if an individual client is making excessive queries which return NXDOMAIN, which is the intent of the detection, following the description.

The other detections ('Identifying DGA via DNS failures' and 'Failures from multiple clients') have the same flaw. I did not check the 'Rare static threshold based client observed with high reverse DNS lookup count' detection yet.

There are other issues with these detections, such as some detections completely ignoring everything that is not rDNS and not filtering for rDNS queries that refer to local IPs, such as 10.0.x.x ranges etc.

Thanks in advance to anymore looking into this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant