You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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 beDstIp
?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.
The text was updated successfully, but these errors were encountered: