after realizing that our Elastic Defend DNS data collected in our Windows machines has some data missing, we found some threads here in the community about it:
According to the posts it is expectad behavior that we cannot see destination ips connected to process information for DNS requests collected by Elastic Defend. Since these posts are about 5 years old, but it looks like this behavior has not changed until now I wanted to ask: is there with the current version any way to get the full information of a DNS request on a client, especially the connection of destination ip and process information? Are there existing plans on the side of Elastic to collect this data in the (near) future?
We only allow DNS through our internal DNS servers, so we still have the deprecated "DNS Activity to the internet" SIEM rule enabled, and everytime we get a hit here, we try to understand which process is trying to use its own DNS settings - we were hoping to get this information with Defend, and were a little bit disapointed after seeing that this data is not available at all.
If there are currently no ways to achieve this and no plans to get this in the future, I would really like to repeate the feature request of @nemhods in the second link I posted above - I think seeing this information would be very helpfull in many scenarios.
I do think we're working on some of the features in the second post. DNS is a personal annoyance of mine. In the past DNS was "Easy" but today with the "DNS over *" protocols and full encryption, unless you are also doing a SSL interception proxy on all of your outbound traffic, there is no lossless DNS monitoring.
You are definitely set up better that most. Only allowing DNS through your DNS server is the most complete solution that I know of. I've seen lists of the known "DNS over *" revolvers and would encourage you to route them to your internal server as well, though the TLS negotiation will fail unless you have a proxy with the right certificates.
I think for some of the improvements we're putting together we will hopefully be able to associate process with the activity, but I'm not sure yet. I think that will largely be for UDP based DNS clients that are not using the system resolver.
I don't know if the rules team would generally publish one or not, but for your setup, with the TCP events combined with a list of known DoH, DoQ and DoT servers, you should be able to setup a rule stack side that would identify TCP connections to those IP addresses which should enable you to identify the process attempting to use those services even though it wouldn't contain the content of the domain look up.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
