Contents

Domain vs Host Name vs FQDN Implementation

Domain vs Host Name vs FQDN Implementation

This guide will show you how to label FQDNs, Domains, and Hostnames (for both source/destination) commonly found in logs for Endpoint, DNS, HTTP, SSL, SMB, Radius, URLs, etc…
However, there is an incredible amount of ambiguity, in logging, regarding the values for a Domain, Hostname, and FQDN (fully qualified domain name).

Therefore, we are going to (try) to clear up this ambiguity in order to properly implement a schema. The order of this guideline is as follows (skip to Implementation if you have already read the definitions and problem framing)

  1. Explain the Common Definitions, apart from this schema, for these three terms.

  2. Show some examples that cause ambiguity in these common definitions.

  3. Outline and guideline for how to perform the Implementation for this schema

Common Definitions

The following are the most common definitions for a Domain, Hostname, and FQDN. We will use the example value bob-berto-pc.bigwheel.corporation.local as the example to visualize the definitions.

FQDN

The absolute (entire) value of the DNS hierarchy from the lowest level to the top level domain (TLD). Consists of the Hostname and Domain. This is best defined in this Wikipedia article on FQDN.
example FQDN value = bob-berto-pc.bigwheel.corporation.local

Hostname

The name of a host, device, node, or entity that is separate from the FQDN and Domain. Think of this in the context of running the “hostname” command.
example Hostname value = bob-berto-pc

Domain

The (DNS) hierarchy that encompasses multiple hosts (ie: a Windows Active Directory environment).
example Domain value = bigwheel.corporation.local

Examples of Ambiguity

Lets use some common examples that will (hopefully) begin to illustrate the ambiguity in being able to determine what is “truly” the FQDN, Hostname, or Domain from a logging perspective.

Background

  • Organization owns corporation.local

  • Active Directory forest at bigwheel.corporation.local

  • Another AD environment that is a sub domain of their AD forest, and is located at finance-group.bigwheel.corporation.local

  • External web server at www.corporation.local

  • Internal ISS server hosting a Wiki at wiki.bigwheel.corporation.local

  • You have logging for both endpoint, the IIS sever, DNS, HTTP, SSL, Proxy, and other network logs.

Scenario 1

HTTP request for wiki.bigwheel.corporation.local was made by an endpoint. You now have the following log sources and their field name for this value:

  1. Proxy log defining the field as hostname

  2. Endpoint log defining the field as DestinationDomain

  3. DNS log defining the field as dns_query

  4. IIS web server log defining two fields, a) destination_hostname with the value wiki and b) destination_domain with the value bigwheel.corporation.local

Scenario 1 Problem Framing

Now, because you have 4 logs that you can (and should definitely) pivot between related to this 1 HTTP request, you set out to define these fields into a common format in order to accomplish this pivoting

  • The proxy log defining the field as hostname is incorrect, we know that the hostname is actually wiki

  • The endpoint log using the verbiage DestinationDomain is incorrect, we know that Domain is actually bigwheel.corporation.local

  • The DNS log, at least took a passive stance and just labeled the value specific to the DNS application - however we are left with being able to pivot from this DNS query to the other log sources (if we don’t change it)

  • The IIS log correctly labels the fields. However, this is a very critical piece that in many scenarios you may not have this level of intimate knowledge into the environment. The endpoint log that belongs to the same (AD) domain as the web server, had no knowledge of the destination’s hostname or (AD) domain! Also, you may be just placing a network sensor for incident response.

Scenario 2

Endpoint makes an HTTP request to an external IP (Destination IP) with the HTTP Host header set via the command line in cURL of mwi2xha9lpqn41lo. For example, the command curl --header "Host: mwi2xha9lpqn41lo" http://8.8.8.8/ was used. You now have the following log sources and their field name for this value:

  1. Proxy log defining the field as hostname

  2. Endpoint log defining the field as DestinationDomain

Scenario 2 Problem Framing

Now, because the connection was direct to an IP, we don’t have a DNS log but we have two log sources with the same value that we would want to pivot on.

  • The value has no clear indication of whether its a FQDN, Hostname, or Domain. It is just random characters and doesn’t even include any TLD. Whether this is malicious or not, is irrelevant - this sort of things happens consistently whether by mistake or malicious intent and for the purpose of this guideline - we are interested in normalizing fields into a schema…before we take the next step of determining the intent of malicious, mistake, or bad practice/hygiene.

  • Also, lets say the Host header wasn’t set and instead the command , and instead the command curl http://8.8.8.8/ was used. You now have two fields with the value 8.8.8.8 (outside of the Destination IP). Again, this is definitely not a FQDN, Hostname, or Domain - and you don’t want to delete the field either.

Implementation

Due to the ambiguity that will happen in log sources and not being able to, always let alone the majority of the time, distinguish the FQDN vs the Domain vs the Hostname as well as the confusion caused by log source’s field names - we will define definitions in order that this delineation is NOT necessary between the three. Also, provide specific examples of log sources and what to call the fields, in order to even further clear any ambiguity.

These apply to both source and destination FQDNs, Domains, and hostnames. Therefore, if you only see destination verbiage below - just replace that with source for the applicable log scenario.

Implementation Outline

FQDN

This is an optional field. Because there are many scenarios (as briefly outlined above) where one can NOT determine the true FQDN, we will leave this field as defined but should only be used if the log source has intimate knowledge that this is in fact the FQDN.

Hostname

This field should always exist if there is some sort of domain, FQDN, or hostname in the log/event.

Domain

This field is optional. Because there are many scenarios (as briefly outlined above) where one can NOT determine the true domain, we will leave this field as defined but should only be used if the log source has intimate knowledge that this is in fact the domain.

Implementation Field Examples:

  • dst_host_name

  • dst_domain

  • dst_fqdn

  • src_host_name

  • src_domain

  • src_fqdn

Implementation Examples

  1. Sysmon EventID:3 network connection event log field for DestinationHostName should be set as dst_host_name

  2. HTTP or Proxy or web server application logs (ie: IIS, Apache, NGINX, etc…), with the hostname/domain (also known as the HTTP Host header) should be set as dst_host_name
    this would include:

    • Zeek HTTP field host

    • Suricata HTTP field hostname

    • NGINX field hostname

    • IIS field vhost

  3. TLS/SSL server name (SNI) should be set as dst_host_name

    • Zeek SSL field server_name

    • Suricata TLS field sni

    • NGINX field hostname

    • IIS field vhost

  4. Kerberos service name should be set as dst_host_name

  5. Sysmon EventID:22 dns query event log field for QueryName should be set as dst_host_name

  6. DNS query name field should be set as dst_host_name

    • Zeek DNS field query

    • Suricata DNS field rrname

  7. For events/logs with URLs or URIs and the HTTP Host header (option 2) doesn’t exist, parse the hostname/domain portion out of the URL.
    For example:

    • Zeek or Suricata HTTP log, skip this because it is defined in option 2

    • PaloAlto Threat log using the field URL/Filename field as outlined here , after first renaming to url.original as defined in URL Schema, you would parse the domain/host out of this field and then set it as dst_host_name

  8. RDP client/source name should be set as src_host_name

  9. Endpoint (ie: Windows/Linux) logs that do NOT apply to the following:
    a) defined in the use cases above
    b) already defined in data dictionaries (ex: Windows Kerberos EventID:4768, Windows Logon EventID:4624)
    c) logically fit into Target or and are NOT

    1. FQDN and Domain values exist.

      • Set the field for the FQDN value as dst_fqdn

      • Copy the value for dst_fqdn into the field dst_host_name

      • Set the field for the Domain value as dst_domain

    2. FQDN and Hostname and Domain values exist

      • Set the field for the FQDN value as dst_fqdn

      • Set the field for Domain value as dst_domain

      • Set the field for the Hostname value as dst_host_name

    3. Hostname and Domain values exist

      • Set the field for the Domain value as dst_domain

      • Set the field for the Hostname value as dst_host_name

    4. Hostname value only exists

      • Set the field for the Hostname value as dst_host_name

    5. Domain value only exists

      • Set the field for the Domain value as dst_domain

      • Copy the value for dst_domain into the field dst_host_name

    6. FQDN value only exists

      • Set the field for the FQDN value as dst_fqdn

      • Copy the value for dst_fqdn into the field dst_host_name

previous

Data Types

next

Source or Destination or Target