• Oracle

DNS Threat Hunting With Gigasheet

DNS is the backbone of the Internet. It converts hostnames into computer readable IP addresses and vice versa.

At the same time, DNS can be misused by malicious threat actors for various malware and other nefarious activities.


DNS Threat Hunting - Cobalt Strike and more

In this blog post, I will focus on how to hunt for most common use cases for DNS attacks.

  • Cobalt Strike Beacon Detection

  • Detect Queries with Base64 Encoded Strings

  • Looking for communication to Dynamic DNS domains

Cobalt Strike Beacon Detection


The DNS Beacon is a favorite Cobalt Strike feature. This payload uses DNS requests to beacon back to you. These DNS requests are lookups against domains that your Cobalt Strike C2 server is authoritative for. The DNS response tells Beacon to go to sleep or to connect to you to download tasks and also tells the Beacon how to download tasks from C2 server.


During the initial exploitation, the threat actors associated with Cobalt Strike used PowerShell scripts to deploy DNS TXT record stagers into memory. During execution, PowerShell would make iterative DNS TXT queries, which would return encrypted data to be concatenated and then executed in memory. These queries followed a pattern matching:


aaa.stage.[encryptedstage].MaliciousDomain.com,

baa.stage.[encryptedstage].MaliciousDomain.com,

post.1.[encryptedstage].MaliciousDomain.com

post.[EncryptedData].[RandomValue].MaliciousDomain.com


We will now look for domain that contains ‘aaa.stage.’ or ‘post.1’ using Gigasheet.

1. The DNS log is now uploaded and filtered to look for ".stage" or "post."

Cobalt Strike Query Filter

2. Now we have the log that's communicating to Cobalt Strike Beaconing servers.

Cobalt Strike DNS

Detect Queries with Base64 Encoded Strings


Also known as DNS exfiltration/DNS Tunneling, a mechanism commonly used to leak data to the C2 server by carrying data in its payloads. This is carried out simply by encoding the data correctly and without abusing the UDP size limits.

Let's now try looking for this using DNS logs in Gigasheet.


A simple filter to look for queries that matches "==." gives you the below results that shows which machine is responsible and where the file (encoded filename) is being sent to.


Detect Base64 Threat Hunting

Looking for Communication to Dynamic DNS domains


Malicious actors often abuse legitimate Dynamic DNS services to host malicious payloads or interactive command and control nodes. Attackers will automate domain resolution changes by routing dynamic domains to countless IP addresses to circumvent firewall blocks, block lists as well as frustrate a network defenders analytic and investigative processes.


This Gigasheet search will look for DNS queries to find a match against a list of suspicious dynamic domains.


1. Upload both files - Dynamic DNS domain list and DNS logs.


2. Open the DNS logs and use the function and click on "Cross file lookup"

3. Once you choose "Cross file lookup", enter or search the column to match in the current sheet, select the lookup file name and enter/search the lookup column name. See below.



4. If there is an exact match, the value "true" will be listed in a column right in the end. Filter that column to give only "true" values.

Malicious DNS

The “true“ value here represents that the source machines (listed under IP.SRC) are infected and are communicating to DNS servers that are potentially hosting malicious payloads or command and control nodes to interact with the victim machine.

Don't have a Gigasheet account? No problem, it's free to sign up here!

Recent Posts

See All