News and blog
NXLog main page
  • Products
    NXLog Platform
    Log collection
    Log management and analytics
    Log storage
    NXLog Community Edition
    Integrations
    Professional Services
  • Solutions
    Use cases
    Specific OS support
    SCADA/ICS
    Windows event log
    DNS logging
    MacOS logging
    Solutions by industry
    Financial Services
    Government & Education
    Entertainment & Gambling
    Telecommunications
    Medical & Healthcare
    Military & Defense
    Law Firms & Legal Counsel
    Industrial & Manufacturing
  • Plans
  • Partners
    Find a Reseller
    Partner Program
  • Resources
    Documentation
    Blog
    White papers
    Videos
    Webinars
    Case Studies
    Community Program
    Community Forum
  • About
    Company
    Careers
  • Support
    Support portals
    Contact us

NXLog Platform
Log collection
Log management and analytics
Log storage
NXLog Community Edition
Integrations
Professional Services

Use Cases
Specific OS support
SCADA/ICS
Windows event log
DNS logging
MacOS logging
Solutions by industry
Financial Services
Government & Education
Entertainment & Gambling
Telecommunications
Medical & Healthcare
Military & Defense
Law Firms & Legal Counsel
Industrial & Manufacturing


Find a Reseller
Partner Program

Documentation
Blog
White papers
Videos
Webinars
Case Studies
Community Program
Community Forum

Company
Careers

Support portals
Contact us
Let's Talk Start free
NXLog search
  • Loading...
Let's Talk Start free
February 20, 2023 deploymentsiem

Our customers asked - Collecting Windows DNS resolved address with NXLog

By Tamás Burtics

Share
ALL SIEM STRATEGY SECURITY ANNOUNCEMENT DEPLOYMENT COMPLIANCE COMPARISON RSS
dns log

Windows DNS Server log collection is essential yet complex, primarily because Windows DNS Server provides logs in various places in different forms containing a vast amount of information. Nevertheless, we all know that DNS Server log collection is paramount in IT security. Getting it right can be challenging.

The Windows DNS Server section in the NXLog user guide offers a comprehensive guide on collecting log records from a Windows DNS Server. In this post, I will elaborate on capturing the resolved address from logs you can collect from Event Tracing for Windows (ETW) providers.

The resolved address can be critical in identifying malicious DNS activity; however, its importance is often overlooked, as it is challenging to collect. Thankfully, NXLog’s advanced data capturing and parsing capabilities allow us to gather the resolved address and present it in a form that can be easily understood and further processed.

Capturing the DNS resolved address

The starting point of this post was a customer query about how to capture the resolved address. However, we need some more corresponding data (metadata) to see the resolved address' context and to make well-informed conclusions, so I added the most obvious ones.

The most critical information for incident response is the following:

  • Timestamp

  • Endpoint hostname

  • Domain

  • Account name

  • The query

  • What that query resolved to

  • When the query was resolved

Collecting the above gives you a better overview of how a query looks and what it resolves to. The resolved address is the most interesting piece of data to gather because the original Windows event is a payload in binary data with hexadecimal representation. Being able to interpret the resolved address is a unique feature in NXLog. NXLog can decode this data and retrieve it.

What is the expected output?

So far, we know what data we would like to gather. Still, I would like to lay down some expectations on how I imagine the output. It is worth solidifying your thoughts before so you can ingest a particular configuration into your log collection strategy.

I’ve engineered a real-life scenario of what you, as the reader, would consider a suitable and informative output log:

  • The output must be human-readable

  • It must be easy to process by machines/software (if you want to send the data to a SIEM solution, for example)

  • The log must only contain what we need (noise free)

  • It must have appropriate naming (depends on your individual need, but we do it to our needs here)

  • The output must be as small as possible (to help with our SIEM and storage costs)

  • Should only contain specific EventIDs (only what we need)

This is the wish list. I would also like some additional background information here:

  • First of all, you need to enable the Analytic trace channel on your Windows host (instructions on the Microsoft website)

  • Our input module im_etw will then collect events and parse them into fields on the fly. The field names that will be populated with data can be found (here)

  • The DNS user queries can be traced in the Microsoft-Windows-DNSServer provider with Event IDs 256-259 (reference, '256' is undocumented) In this post we will only focus on Event ID 256 and Event ID 257

Start with the basics - default ETW configuration

In the first configuration, I would like to show a basic setup using the im_etw module, as it is interesting to see how much value you can get from a little extra effort.

Example 1. Collecting DNS Server logs from the ETW provider Microsoft-Windows-DNSServer

This configuration uses the im_etw module to collect all logs from the Microsoft-Windows-DNSServer ETW provider, then outputs it in pretty printed JSON format.

nxlog.conf
<Extension json>
    Module         xm_json
    PrettyPrint    TRUE
</Extension>

<Input etw>
    Module         im_etw
    Provider       Microsoft-Windows-DNSServer
    Exec           to_json();
</Input>

The resulting nested JSON file contains a wealth of data about a single event. It collected and parsed the following fields for an example DNS response event (EventID: 257) with lookup "National Aeronautics and Space Administration" presented in JSON pretty print format.

Although it contains a wealth of data, it also contains a lot of noise. It is never a good idea to collect every single log from a system, and it is rarely a good idea to parse and send every part of a single log for further processing. It is always worth looking at the log file and thinking about what you need. As usual, there is no silver bullet. Every scenario is different, and yours is too.

output.json
{
    "SourceName": "Microsoft-Windows-DNSServer",
    "ProviderGuid": "{EB79061A-A566-4698-9119-3ED2807060E7}",
    "EventID": 257,
    "Version": 0,
    "ChannelID": 16,
    "Channel": "Microsoft-Windows-DNS-Server/Analytical ",
    "LevelValue": 4,
    "Level": "Information ",
    "OpcodeValue": 0,
    "TaskValue": 1,
    "Category": "LOOK_UP ",
    "Keywords": "9223372036854775810",
    "EventTime": "2022-01-04T14:46:56.932456+00:00",
    "ExecutionProcessID": 1848,
    "ExecutionThreadID": 3632,
    "EventType": "INFO",
    "SeverityValue": 2,
    "Severity": "INFO",
    "Hostname": "WIN-VO0N2RBUVE4",
    "Domain": "NT AUTHORITY",
    "AccountName": "SYSTEM",
    "UserID": "S-1-5-18",
    "AccountType": "User",
    "Flags": "33152",
    "TCP": "0",
    "InterfaceIP": "127.0.0.1",
    "Destination": "127.0.0.1",
    "AA": "0",
    "AD": "0",
    "QNAME": "nasa.gov.",
    "QTYPE": "1",
    "XID": "28411",
    "DNSSEC": "0",
    "RCODE": "0",
    "Port": "60346",
    "Scope": "Default",
    "Zone": "..Cache",
    "PolicyName": "NULL",
    "PacketData": "0x6EFB81800001000200000000046E61736103676F760000010001C00C0001000100000258000434000E74C00C0001000100000258000417162778",
    "ParsedPacketData": {
        "dns.id": 28411,
        "dns.flags.recursion_desired": "true",
        "dns.flags.truncated_response": "false",
        "dns.flags.authoritative": "false",
        "dns.opcode": "QUERY",
        "dns.flags.query_or_response": "true",
        "dns.response.code": "NOERROR",
        "dns.flags.checking_disabled": "false",
        "dns.flags.authentic_data": "false",
        "dns.flags.recursion_available": "true",
        "dns.query": [
          {
            "dns.query.name": "nasa.gov",
            "dns.query.type": "A",
            "dns.query.class": "IN"
          }
        ],
        "dns.answer": [
          {
            "dns.answer.name": "nasa.gov",
            "dns.answer.type": "A",
            "dns.answer.class": "IN",
            "dns.answer.ttl": 600,
            "dns.answer.data": "52.0.14.116"wp-admin/https://kb.nxlog.co
          },
          {
            "dns.answer.name": "nasa.gov",
            "dns.answer.type": "A",
            "dns.answer.class": "IN",
            "dns.answer.ttl": 600,
            "dns.answer.data": "23.22.39.120"
          }
         ]
       },
    "AdditionalInfo": "VirtualizationInstance:.",
    "EventReceivedTime": "2022-01-04T14:46:57.912861+00:00",
    "SourceModuleName": "ETW",
    "SourceModuleType": "im_etw"
}

If you look at this JSON file, it contains a nested section: ParsePacketData. I will use that to parse the resolved address in the following example.

Taking the configuration to the next level

In this section, I will build on the basic configuration above and tune it to all the needs we set out at the beginning of the post.

Example 2. Collecting DNS Server logs from the Microsoft-Windows-DNSServer ETW provider and applying advanced parsing of the log data.

This configuration file does the advanced parsing I wrote about earlier. I look at each configuration block individually, so you understand it.

nxlog.conf
<Extension _json> (1)
    Module             xm_json  
    PrettyPrint        TRUE     
    Unflatten          TRUE
</Extension>

<Extension cleanup> (2)
    Module             xm_rewrite
    Keep               Hostname, EventID, Channel, Domain, Category, QNAME, dns.answer, Source, Destination, DNSResolvedAddress, dns.query, dns.response.code
    Rename             dns.answer, DNS_Response_ALL
    Rename             QNAME, DNS_Query
    Rename             dns.query, DNS_Query_ALL
    Rename             Hostname, DNS_Server
    Rename             DNSResolvedAddress, DNS_Response_IPv4
    Rename             Source, DNS_Host_Source
    Rename             Destination, DNS_Host_Destination
    Rename             dns.response.code DNS_Code
</Extension>

<Input etw> (3)
    Module             im_etw
    Provider           Microsoft-Windows-DNSServer
    ParsePacketData    TRUE
    <Exec>
        if $EventID NOT IN (256, 257) drop();
        parse_json($ParsedPacketData);
        to_json();
        $DNSResolvedAddress = extract_json("$.dns.answer");
        $DNSResolvedAddress =~ /^.*dns\.answer\.data\":\"(\d+\.\d+\.\d+\.\d+)\".*$/;
        $DNSResolvedAddress = $1;
        cleanup->process();
        to_json();
    </Exec>
</Input>
1 The first extension block is responsible for the JSON formatting. It is called with the to_json() procedure from other modules. In addition, it pretty-prints the JSON output, and the Unflatten directive removes the JSON files' nesting.
2 The second extension block is responsible for rewriting fields. The Keep directive defines what fields to keep, and then the Rename directive sets the renaming.
3 The input block collects logs from the Microsoft-Windows-DNSServer ETW provider, where the ParsePacketData directive enables the further parsing of the nested content from the previous output example. The Exec block within the input block sets the two EventIDs to collect and drops everything else. Then, it parses the resolved address field.

As you can see below, the output is very different this time. Even though it contains two log messages (the query and the response), it is much shorter than the previous one. It only includes information that is valuable or of interest. In theory, if you were only interested in the resolved address, you could only collect Event ID 257. However, it gives you better context to see the corresponding query.

output.json
{
    "EventID": 256,
    "Channel": "Microsoft-Windows-DNS-Server/Analytical ",
    "Category": "LOOK_UP ",
    "DNS_Server": "WIN-VO0N2RBUVE4",
    "Domain": "NT AUTHORITY",
    "DNS_Host_Source": "10.0.1.1",
    "DNS_Query": "nasa.gov.",
    "DNS_Code": "NOERROR",
    "DNS_Query_ALL": [{"dns.query.name":"nasa.gov","dns.query.type":"A","dns.query.class":"IN"}],
    "DNS_Response_IPv4": null
}
{
    "EventID": 257,
    "Channel": "Microsoft-Windows-DNS-Server/Analytical ",
    "Category": "LOOK_UP ",
    "DNS_Server": "WIN-VO0N2RBUVE4",
    "Domain": "NT AUTHORITY",
    "DNS_Host_Destination": "10.0.1.1",
    "DNS_Query": "nasa.gov.",
    "DNS_Code": "NOERROR",
    "DNS_Query_ALL": [{"dns.query.name":"nasa.gov","dns.query.type":"A","dns.query.class":"IN"}],
    "DNS_Response_ALL": [{"dns.answer.name":"nasa.gov","dns.answer.type":"A","dns.answer.class":"IN","dns.answer.ttl":164,"dns.answer.data":"52.0.14.116"},{"dns.answer.name":"nasa.gov","dns.answer.type":"A","dns.answer.class":"IN","dns.answer.ttl":164,"dns.answer.data":"23.22.39.120"}],
    "DNS_Response_IPv4": "23.22.39.120"
}

Closing thoughts

There are a few conclusions we can draw by having read the article. The first is that collecting DNS logs is essential, and the information gathered from them is paramount. Furthermore, you need to do more (well, less) than just collecting all logs; you need to gather only the necessary ones. Filtering and trimming your logs to only collect what you need gives you better visibility of what is essential and reduces costs by having less data to manage. Finally, the importance of the right log collection strategy must be addressed, where you have a clear vision of what you want and how to get it done.

NXLog Platform is an on-premises solution for centralized log management with
versatile processing forming the backbone of security monitoring.

With our industry-leading expertise in log collection and agent management, we comprehensively
address your security log-related tasks, including collection, parsing, processing, enrichment, storage, management, and analytics.

Start free Contact us
Disclaimer

While we endeavor to keep the information in this topic up to date and correct, NXLog makes no representations or warranties of any kind, express or implied about the completeness, accuracy, reliability, suitability, or availability of the content represented here. We update our screenshots and instructions on a best-effort basis.

The accurateness of the content was tested and proved to be working in our lab environment at the time of the last revision with the following software versions:

NXLog EE version 5.7.7898
Windows Server 2016

Last revision: 20 February 2023

  • DNS
  • Windows
  • Our customers asked
Share

Facebook Twitter LinkedIn Reddit Mail
Related Posts

DNS Log Collection on Windows
8 minutes | May 28, 2020
DNS Log Collection on Linux
8 minutes | May 14, 2020
Making the most of Windows Event Forwarding for centralized log collection
6 minutes | December 17, 2018

Stay connected:

Sign up

Keep up to date with our monthly digest of articles.

By clicking singing up, I agree to the use of my personal data in accordance with NXLog Privacy Policy.

Featured posts

Announcing NXLog Platform 1.6
April 22, 2025
Announcing NXLog Platform 1.5
February 27, 2025
Announcing NXLog Platform 1.4
December 20, 2024
NXLog redefines log management for the digital age
December 19, 2024
2024 and NXLog - a review
December 19, 2024
Announcing NXLog Platform 1.3
October 25, 2024
NXLog redefines the market with the launch of NXLog Platform: a new centralized log management solution
September 24, 2024
Welcome to the future of log management with NXLog Platform
August 28, 2024
Announcing NXLog Enterprise Edition 5.11
June 20, 2024
Raijin announces release of version 2.1
May 31, 2024
Ingesting log data from Debian UFW to Loki and Grafana
May 21, 2024
Announcing NXLog Enterprise Edition 6.3
May 13, 2024
Raijin announces release of version 2.0
March 14, 2024
NXLog Enterprise Edition on Submarines
March 11, 2024
The evolution of event logging: from clay tablets to Taylor Swift
February 6, 2024
Migrate to NXLog Enterprise Edition 6 for our best ever log collection experience
February 2, 2024
Raijin announces release of version 1.5
January 26, 2024
2023 and NXLog - a review
December 22, 2023
Announcing NXLog Enterprise Edition 5.10
December 21, 2023
Raijin announces release of version 1.4
December 12, 2023
Announcing NXLog Enterprise Edition 6.2
December 4, 2023
Announcing NXLog Manager 5.7
November 3, 2023
Announcing NXLog Enterprise Edition 6.1
October 20, 2023
Raijin announces release of version 1.3
October 6, 2023
Upgrading from NXLog Enterprise Edition 5 to NXLog Enterprise Edition 6
September 11, 2023
Announcing NXLog Enterprise Edition 6.0
September 11, 2023
The cybersecurity challenges of modern aviation systems
September 8, 2023
Raijin announces release of version 1.2
August 11, 2023
The Sarbanes-Oxley (SOX) Act and security observability
August 9, 2023
Log Management and PCI DSS 4.0 compliance
August 2, 2023
Detect threats using NXLog and Sigma
July 27, 2023
HIPAA compliance logging requirements
July 19, 2023
Announcing NXLog Enterprise Edition 5.9
June 20, 2023
Industrial cybersecurity - The facts
June 8, 2023
Raijin announces release of version 1.1
May 30, 2023
CISO starter pack - Security Policy
May 2, 2023
Announcing NXLog Enterprise Edition 5.8
April 24, 2023
CISO starter pack - Log collection fundamentals
April 3, 2023
Raijin announces release of version 1.0
March 9, 2023
Avoid vendor lock-in and declare SIEM independence
February 13, 2023
Announcing NXLog Enterprise Edition 5.7
January 20, 2023
NXLog - 2022 in review
December 22, 2022
Need to replace syslog-ng? Changing to NXLog is easier than you think
November 23, 2022
The EU's response to cyberwarfare
November 22, 2022
Looking beyond Cybersecurity Awareness Month
November 8, 2022
GDPR compliance and log data
September 23, 2022
NXLog in an industrial control security context
August 10, 2022
Raijin vs Elasticsearch
August 9, 2022
NXLog provides native support for Google Chronicle
May 11, 2022
Aggregating macOS logs for SIEM systems
February 17, 2022
How a centralized log collection tool can help your SIEM solutions
April 1, 2020

Categories

  • SIEM
  • STRATEGY
  • SECURITY
  • ANNOUNCEMENT
  • DEPLOYMENT
  • COMPLIANCE
  • COMPARISON
logo

Subscribe to our newsletter to get the latest updates, news, and products releases. 

© Copyright 2024 NXLog FZE.

Privacy Policy. General Terms of Use

Follow us

  • Product
  • NXLog Platform 
  • Log collection
  • Log management and analysis
  • Log storage
  • Integration
  • Professional Services
  • Plans
  • Resources
  • Documentation
  • Blog
  • White papers
  • Videos
  • Webinars
  • Case studies
  • Community Program
  • Community forum
  • Support
  • Getting started guide
  • Support portals
  • About NXLog
  • About us
  • Careers
  • Find a reseller
  • Partner program
  • Contact us