Identify Threats with DNS Logging
One of the essential and critical techniques for identifying, mitigating, and preventing malwares / spywares among users and devices, without installing an Endpoint Protection at the client machines, is through DNS.
Briefly; when a machine requests to resolve malicious / suspicions domain to an IP, or vice versa, via a DNS query request, which could be even triggered by a malware/spyware without the knowledge of the user - this DNS query will be sent to the DNS Server for resolution. This gives the DNS Server a unique position in the network infrastructure as it is, in this case, the 1st exist point to this DNS client. The DNS Server should be at least configured to log the DNS Queries/Responses generated by the DNS clients for further analysis and audit.
In other words, DNS is the first protocol/service triggered for any client or server activity, regardless if it is legitimate or malicious, intentional or unintentional, initiated from managed devices or unmanaged, and so on.
From DNS security perspective, the DNS Server should be configured to:
1- Identify malicious activities: this is done by enabling the DNS logging, such as DNS Debug Logging on a Microsoft DNS server, in order to maintain the history for the domains/IPs requested to be resolved from every client
2- Mitigate and Prevent malicious communication: this is done by blacklisting malicious and undesired domains/IPs from getting resolved recursively. This is also commonly known as DNS Sinkhole, DNS Firewall, or DNS Response Policy Zone. Refer to DNS Domain Blacklisting and Sinkhole Overview for additional information.
Unfortunately, most of the enterprises usually overlook the importance of the DNS logging in their network either unintentionally, or due to the implementation challenges discussed and solved with the DNS Centric solution.
Why DNS Logging is important for Network Security?
Since DNS is one of the most essential network protocols used in our world, it is very important to maintain the historical information for DNS. The DNS Server in many situations would be the first exist service to the client in the network. This is mainly due to the fact that almost all clients need to communicate with the DNS for one reason or another.
DNS is the first protocol/service triggered for any client or server activity, regardless if it is legitimate or malicious, intentional or unintentional, initiated from managed devices or unmanaged, and so on.
This gives the DNS log file a unique importance, as it is now a trusted data source for information that will help you identify:
1- If you have botnets and infected users in your network. This is mainly identified by cross checking the requested domains from the log file with a list of malicious domains, helping you identify which clients are trying to resolve the malicious domain(s) in order to communicate with C&C (Command and Control) and botnets.
2- If clients are trying to resolve undesired sites/URL and the frequency of such activity.
3- If someone is trying to attack your DNS server by exhausting the machine resources, such as via NXDomain attacks.
4- Who went Where, When, How many times, and what was the response. This will provide you with a valuable statistical information, audit, and analysis about the clients.
5- ….and more….
There are several articles in the Web that add to the above, explain why DNS logging is important, and how to make use of the DNS logs messages and files. Below are some few quotes:
1- “The logfiles of your DNS resolver contain a wealth of information on the Internet activity of your users and their machines and can be filtered for signs of attacks and malware. In general, you would be baselining the logfiles for normal usage, and then be looking for normal anomalies. Here are some ideas to get you started, including what you can find out from DNS logs.” Source: https://www.petri.com/dns-security-information-source
2- “Criminals will exploit any Internet service or protocol when given the opportunity. Here are six signs of suspicious activity to watch for in the DNS.” Source: http://www.darkreading.com/
3- “DNS monitoring is so important for security investigations, as well, because it allows researchers to map out components that can help determine everything from the type of infrastructure supporting the attack to finding its source.” Source: http://blogs.cisco.com/security/overcoming-the-dns-blind-spot
For more information, also refer to:
There are as well multiple none-security related reasons that DNS Logging will help you to identify, such as if the DNS service is operating normally, or if you need to track down any issues with DNS queries, resolutions, updates, web page not found - 404 error, email delivery error, cannot find a server by its a URL path, and so on.
Because of all the above, the DNS Centric solution is a Must Have!
How to Identify malicious activities with Microsoft DNS Debug Log?
The 1st and easiest step is Enabling the DNS Debug Logging at your Microsoft DNS Server. Once enabled, the Microsoft DNS Server will log every DNS query/response to/from the MS DNS Server based on the DNS Debug Logging settings configuration.
Yet, few challenges at this level might start to kick in.
The Microsoft DNS Debug feature was not purposely built to achieve what we have been talking about. It was initially created to be used for troubleshooting only, and over a limited period of time.
With that being said, there are multiple challenges and limitation that you would face with the Microsoft DNS Debug Logging feature being enabled, and this it what the DNS Centric solution was purposely built to solve and alleviate.
The following are the Challenges:
1- Limited File Size: The MS DNS Debug log file has a limited size of (1GB max). Whenever this file is filled, the MS DNS server will stop writing new logs to the file. The solution is to use a Microsoft Automatic DNS Log Backup tool to intelligently backup the “dns.log” file and create a new/empty “dns.log” either when it reaches a certain file size, or based on a schedule (date/time/period). This is part of the DNS Centric solution. More details at: “Auto Archive DNS Log Files”.
2- Format of the Log File: The log messages in the “dns.log” file are very challenging to read and understand. Besides, it is a plain text, which is not presented in a tabular form, making it very difficult to make sense out of the data being presented by the log file. The solution is to use the “MS DNS Log to CSV” tool, which will convert the “dns.log” file to a tabular format such that you can sort, search, and analyze the data easily. This is part of the DNS Centric solution. More details at: “MS DNS Log to CSV”.
3- Cross check the log data with other databases: If the data at the “dns.log” file is in a plain text with an awkward format, you won’t be easily able to cross check a list of malware domains with the “dns.log” data for example. The solution is to first convert the data to CSV with “MS DNS Log to CSV” tool, and then use “CSV Match & Merge” tool in order cross check two CSV files together. Currently, and by the time of this posting, this tool is available as online tool for free, but with file size limitation. The unlimited file size tool will be released as part of DNS Centric.
Hints on enabling DNS Logging
Ideally, enabling the DNS Logging for the discussed used case will be at the Internal DNS Server. It can even be enabled on a DNS Caching Server, yet enabling DNS Logging only at the DNS Caching/Recursive Server, in this case, will prevent you from identifying the source IP addresses of the clients and devices sending the DNS query requests. Below are some hints:
1- Enable the dns logging at the internal DNS server to identify the clients.
2- Enable the dns logging on the DNS Caching/Recursive layer. This will dramatically reduce the DNS log file size, yet you won’t be able to identify the source devices and clients.
3- Specify what do you want to log on the DNS Servers.
Network Consideration Hint:
From Security and Audit perspective, you should always consider blocking any outbound/egress DNS traffic (UPD / TCP 53) at the perimeter routers/firewalls generated by a none-DNS Server. This way you insure that you only allow all outbound Internet and recursive DNS queries to be generated by your DNS Server, which will give a comprehensive visibility on your DNS traffic when logging is enabled. Otherwise, some clients might try to use an Open Resolver (like Google DNS 188.8.131.52 or 184.108.40.206) for recursive DNS queries, which will result in bypassing your internal DNS Server, and consequently either losing some of the DNS logs and information, or additional efforts would be required in case you are using an additional network monitoring / logging solutions resulting in a scattered and soiled log databases for the DNS audit. Of course, internal DNS traffic should be allowed between the DNS Clients and the DNS Servers, yet needs to be logged.
DNS Centric Use Case: Identify Malicious Activities By Matching Bad Domains With DNS Log Data
In this use case, we will use this tool to perform domain name matching between two different CSV files, ‘dns.log’ (after converting it to CSV) and a list of malicious domains in CSV, then merge the two.
This use case will be very useful to identify what users are trying to communicate with (example: malicious/undesired domains), by cross matching a list of domains with your DNS log data, after converting the ‘dns.log’ to CSV.
The following is an example on how to identify the machines that are trying to communicate with malicious and suspicion sites, or infected by malwares:
1- Enable DNS Debug Logging on your Windows DNS Server. More at http://www.networkstr.com/dnscentric/enabling_dns_debug_logging
2- Convert the ‘dns.log’ file generated by your Windows DNS server to CSV. Get the tool from http://www.networkstr.com/dnscentric/dns_log_converter. Example:
Note: In order to better manage your ‘dns.log’ files, use the “Auto Archive DNS Debug Logs” tool available at http://www.networkstr.com/dnscentric/auto_archive_dns_log_files
3- Get a list of the latest malicious domains in CSV. Such as:
d. …. Many other sites that list the malicious domains are available online
e. Or you can have your own list of domains that you need to identify the source of the DNS queries for.
4- Once you have the DNS log data converted to CSV, for example “dns.csv”, and you have the list of malicious/monitored domains, use the “Merge_CSV” tool to cross check the list with your DNS Log data –i.e ‘dns.log’. The result will be saved in CSV. The output will then tell you which machines communicated with malicious domains for example.
Result of this example:
5- For even a further analysis, if needed, you can convert the output CSV (created by the Merge_CSV tool) into a DNS Debugging Log format, such as “dns_malware_domains.log’ for example, and import it to Windows DNS Log Analyser. The Windows DNS Log Analyser is a free tool, which can help you in examining Microsoft Windows DNS log files in a graphical presentation with useful statistics.
6- Last but not least, you can block the malicious domains queried by DNS clients at your DNS Server. More at: http://www.networkstr.com/domain-dns-blacklisting-sinkhole/tool
DNS Related Tools and Articles:
Donate - Support Networkstr
Support Networkstr.com to continuo being online!
Help us build these products:
Thank You for your support!