Category: Threat Hunting

In this post I will explore how DNS can be abused to establish a C2 covert communication channel using sliver and how to hunt for it using two tools of mine: YAPSBT and Blue Notebooks.

But before that, let’s have a quick overview about DNS.

What is DNS and how does it work?

DNS stands for Domain Name System and it is a protocol of the early 80s.
Today it is one of the most important and common protocol in network communications.

Often defined as the phonebook of the Internet, its purpose is to translate domain names to IP addresses (and the opposite) making it easier for humans to read and remember website names, system names, host names…

It is such a critical component in network communications that firewalls and security devices are sure to have policies to allow DNS queries and replies to pass through.

Because of this and because DNS is ubiquitous, there may be a lack of attention towards DNS vulnerabilities and exploitation.

To better explain how DNS works we need a scenario: a user opens up a web browser and navigates to the website https://wintermute.kuang11.com.
The first stop of the query is the DNS recursor which is a DNS server running on a router, a firewall, a Windows or Linux server…
If it does not have information about wintermute.kuang11.com in its cache, it needs to reach out to other servers.

DNS is a hierarchical system that can be thought of as a tree where the apex are the Root Nameservers.
There are 13 of them around the world, but their instances are well over 1000.

Root Nameservers are identified by a “.” (dot) in Fully Qualified Domain Names (FQDNs) and they are the first stop for the DNS Recursor.
In our scenario, the FQDN is wintermute.kuang11.com..

When the query reaches a Root Nameserver, an answer is sent back with information about the Authoritative Nameservers for the Top-Level Domain (TLD).
The TLD portion of wintermute.kuang11.com. is .com.

There are several Top-Level Domain Nameservers, each holding information about specific extensions such as .com, .net, .org, .edu… and countrycode-TLDs such as .it, .de, .fr…
The TLD Nameserver sends back to the DNS Recursor information about the Authoritative Nameservers for the domain.
The domain portion of wintermute.kuang11.com. is kuang11.com.

This is usually the last step since the Authoritative Nameserver for the domain (and its subdomains) sends to the Recursor the IP Address needed by the requesting system.

As you can see, the resolution of a query always starts at the apex of the DNS tree and climbs down, collecting a piece of information at each step.
Answers are cached for some time before they are purged from the DNS cache (which happens for every endpoint device and resolver).
Once that happens, the process repeats.

DNS uses record types to indicate the type of information needed by the client:
- A: IPv4 address(es)
- AAAA: IPv6 address(es)
- CNAME: Canonical Name, used to refer to a Nameserver rather than to an IP address
- MX: Mail Exchange
- NS: NameServer Name
- TXT: Text strings
What is C2 over DNS and how does it work?

A Command-and-Control communication channel is a tunnel between compromised systems and a C&C server.
When this type of communication is established the incident has already happened, meaning the attack is almost at the last stage of the Cyber Kill Chain.

Once a host has been infected by malware or has been exploited in other ways, and has effectively established a covert communication channel with the remote C2 server (acting as Authoritative Nameserver for the domain), it will beacon out at a specific time interval to retrieve commands to execute (infiltration or exfiltration of data, scanning, tracking, enumeration, pivoting to other systems, privilege escalation…).

The beaconing activity may go undetected because:
- DNS ubiquity and importance makes it one of the most used protocols and one of the easiest to forget and scrutinize
- The compromised host does not talk directly to the C&C server because DNS way of working adds a layer of obscurity
- Beacon activities may be far among them and only sticks out when analyzing packet captures hours and hours long (12/24h)
- Queries and Answers have encoded or encrypted subdomains that cannot be decoded or decrypted by inline security devices
Usually, the communication among compromised hosts and the C2 server uses DNS records type A, AAAA, MX, CNAME, and TXT.

Demonstration

Scenario: a Windows Server machine has been compromised and has already established a successful covert channel with the C2 Server which is the Authoritative NameServer for kuang11.com and its subdomains.

Setting up the research lab
- Threat Hunt Box: a Linux server acting as a router between the other boxes, equipped with tcpdump, yapsbt, zeek, RITA and ELK in a container
- DNS Server: a Linux server acting as DNS Server running named (bind9) resolving local zone to the Attack Box and forwarding other requests to a resolver
- Attack Box: a Kali Box with Sliver listening on port UDP 53
- Victim Box: a Windows Server Box
How to hunt

Hunting for beaconing activities means looking for recurring outbound connections and domains with a huge amount of subdomains with high entropy scores.

Number of subdomains

As we already know, a C2 communication channel is based on encoded or encrypted subdomains and resource records: when the client checks if the remote server is online, when the client checks if there are any instructions, when the clients sends the output or there is inflitration or exfiltration of data; all of that is converted into encoded or encrypted sudomains and resource records.

This means that the total amount of subdomains grows very quickly (hundreds or even thousands) and only few companies worldwide such as Google, Akamai, Amazon, Microsoft can afford to maintain such a big infrastructure.

Entropy

Encoding and encryption are operations that produce high-entropy strings. Note that not all high-entropy subdomains are evil but most are.

In both YAPSBT and Blue Notebooks there is a function to calculate the Shannon Entropy of (lowercase) subdomains.

Yes! Another Packet Sniffer for the Blue Team

YAPSBT is a tool I’m working on for packet sniffing, you can read more here.
There is a new plugin for C2 over DNS which prints to screen information about queries like the FQDN and the entropy score of the subdomain. It works against live traffic and PCAP files.

As it can be seen the output of the command is sent from the compromised host back to the C2 server as encoded data in subdomains in queries of Type A.

YAPSBT can dissect DNS queries to retrieve the record types, the FQDNs and the entropy of subdomains.
It can also save the sniffed packets to a PCAP file by simply interrupting the capture (CTRL+C).

The plugin can also be used against the PCAP file.

Tips

YAPSBT syntax to sniff live traffic:
```
sniffer.py -i <interface> --bpf 'udp port 53' -a dns_c2_beacons
```
YAPSBT syntax to replay a PCAP file:
```
sniffer.py -r <pcap file> --bpf 'udp port 53' -a dns_c2_beacons
```
In the DNS plugin, dns.py, you should uncomment line 48 when sniffing live traffic while it could be useful when replaying a PCAP file.
```
 47             query_entropy: float = shannon_entropy(".".join(subdomain[:-2]))
 48             #sleep(1)
 49             return "IP: {0:<16} Type {1:<7} ID {2:<10} Query {3:<35} Subd entropy: {4}".format(pkt[IP].src, qtype, pkt[DNS].id, pkt[DNS].qd.qname.decode(), query_entropy)
```
Blue Notebooks

Blue Notebooks is a collection of Jupyter Notebooks focused on Threat Hunting (at the moment there is only a Notebook about C2 over DNS but more is on the way!) built on scapy and pandas.

Instead of PCAP files, these Notebooks ingest Zeek log files, so let’s convert the PCAP file we just saved to Zeek logs.
I use the Docker implementation of Zeek from ActiveCountermeasures.
```
zeek readpcap <absolute path to the pcap file> <absolute path to the destination folder>
```
Running the cells will create two pandas’ Dataframes: one showing the total number of unique subdomains and one sorting the subdomains by entropy in descending order.

Conclusions

What I have shown and explained is just a demonstration of hunting using custom built tools.

When properly monitored and logged, network traffic can reveal a lot about what is going on.
In the case of C2 over DNS an easy way of detection consists of beaconing activity, calculating the total amount of unique subdomains per domain and the entropy of said subdomains over a period of at least 12 hours.

In the next posts I will keep exploring how to hunt C2 communications in a SIEM (ELK and Splunk) and how to use Sysmon to collect network traffic logs in Windows.

RFCs
- RFC 1035 – Domain names – implementation and specification (ietf.org)
- RFC 1034 – Domain names – concepts and facilities (ietf.org)
Articles
Documentations and Github Repositories
Videos
- Threat Hunting Shorts – C2 over DNS | Chris Brenton (youtube.com)
C2 over DNS – Threat Hunting

–––––––

Nov 7
All right, here we are!

Since this is the first post for my blog, I would like to share a WIP (Work In Progess) tool for packet sniffing.
Hopefully, with time, it will become a useful tool for Incident Response and Threat Hunting.

Components

The tool is written in Python and is built on the awesome Scapy library.

For those who don’t know what Scapy is… Scapy is a library that allows for advanced packet crafting, but for our needs, we are more interested in its parsing capabilities. Scapy can read packets and dissect them, making each part of them easily accessible.

The main file is just a Python script that reads pcap files or listens to live traffic and processes each packet in turn.
This file also imports custom modules placed in the plugins folder. Each function, then, can be passed as argument for specific actions on the packets.

The folder tree is structured like this:
```
├── sniffer.py
└── plugins
        ├── ftp.py 
        ├── ip.py
        ├── netbios.py
        └── ...
```
The tool also supports the BPF syntax to further filter packets.

Usage

A list of supported switches:
```
-r, --read: pcap file(s) to parse

-b, --bpf: BPF syntax to filter packets

-i, --interface: interface to read live packets from

-a, --action: Specify which plugin function to call
```
Example:
```
sniffer.py --read file.pcap --bpf 'udp port 53' --action dns_c2_beacon
```
Github Repository

Here is the link to the repo.

I’m not a programmer, so expect errors in my code.
Any help and ideas are appreciated.

Please bookmark this page as it will be updated in the future as new features are added to the tool.

Last update: 31/10/2024
YAPSBT – Yes! Another Packet Sniffer for the Blue Team!

–––––––

Sep 23

Category: Threat Hunting

What is DNS and how does it work?

What is C2 over DNS and how does it work?

Demonstration

Setting up the research lab

How to hunt

Number of subdomains

Entropy

Yes! Another Packet Sniffer for the Blue Team

Tips

Blue Notebooks

Conclusions

RFCs

Articles

Documentations and Github Repositories

Videos

C2 over DNS – Threat Hunting

Components

Usage

Github Repository

YAPSBT – Yes! Another Packet Sniffer for the Blue Team!