Overview

BeaconDNS is an external listener that uses DNS queries and responses to establish a covert C2 channel. DNS-based C2 is slow but extremely difficult to block, since DNS resolution is required for almost all network activity.

Characteristics

PropertyValue
NameBeaconDNS
TypeExternal
ProtocolDNS
AgentBeacon
PlatformsWindows, Linux, macOS

Creating a BeaconDNS Listener

  1. Open the Listeners tab
  2. Click Create
  3. Select BeaconDNS
  4. Configure:
    • Name — Unique name (e.g., dns-covert)
    • Domain — The DNS domain you control (NS records must point to your server)
    • Bind Host/Port — Typically 0.0.0.0:53
  5. Click Start

Prerequisites

To use DNS-based C2, you need:

  1. A domain you control — Register a domain or use a subdomain
  2. NS records — Configure the domain’s NS records to point to your teamserver’s IP
  3. Port 53 access — The server must be able to bind to UDP port 53

DNS Configuration Example

If your teamserver IP is 203.0.113.50 and your domain is c2.example.com:

  1. Create an A record: ns1.example.com203.0.113.50
  2. Create an NS record: c2.example.comns1.example.com

How It Works

  1. The agent encodes C2 data into DNS queries (e.g., TXT, A, AAAA queries for subdomains of your C2 domain)
  2. The DNS queries traverse the target network’s DNS resolver chain
  3. They arrive at your teamserver (which is authoritative for the C2 domain)
  4. The listener decodes the query, processes the data, and encodes the response in DNS reply records
  5. The agent receives the DNS response containing task data

Use Cases

  • Air-gapped or heavily filtered networks — When HTTP/TCP are blocked, DNS often works
  • Last-resort channel — Fallback when all other protocols are blocked
  • Low-and-slow operations — Acceptable for operations where speed isn’t critical
  • Restricted environments — Corporate networks that only allow DNS egress

Limitations

  • Slow — DNS packets are small; large transfers take significant time
  • Bandwidth — Limited by DNS query/response sizes (typically ~250 bytes per message)
  • Detection — High-volume DNS queries to a single domain can trigger alerts
  • Reliability — DNS caching and TTLs can affect communication reliability

OPSEC Notes

  • Use a domain that looks legitimate (not evil-c2.com)
  • Keep query volumes low to avoid triggering DNS anomaly detection
  • Consider using DNS over HTTPS (DoH) proxies if available
  • Monitor DNS query rates to stay below detection thresholds
  • DNS logging is increasingly common — assume queries may be recorded