Detecting Command And Control Over Dns
Overview
Cybersecurity skill for detecting command and control over dns. Follows industry best practices and security standards.
When to Use
Trigger phrases:
"detecting command and control over dns"
"Detects command-and-control (C2) communications tunneled through DNS protocol in"
Investigating suspected DNS tunneling used for C2 communication or data exfiltration
Analyzing DNS query logs for signs of encoded payloads in subdomain strings
Classifying domains as DGA-generated vs. legitimate using statistical or ML methods
Detecting DNS beaconing patterns (regular intervals, consistent query sizes)
Hunting for Iodine, dnscat2, dns2tcp, Cobalt Strike DNS, or Sliver DNS traffic
Monitoring TXT record abuse for command delivery or staged payload download
Building DNS anomaly detection rules for SOC/SIEM deployment
Do not use for general DNS performance monitoring or DNS configuration auditing; use DNS health monitoring tools for those. For HTTP/HTTPS-based C2 detection, use network traffic analysis skills focused on web protocols.
DISCLAIMER: DNS tunneling tools referenced in this skill (Iodine, dnscat2, dns2tcp) are dual-use. They have legitimate uses (bypassing captive portals, security research) and malicious uses (C2 channels, exfiltration). Only deploy detection in networks you are authorized to monitor. Testing tunneling tools requires explicit authorization.
When NOT to Use
- When you lack proper authorization for testing
- For production systems without change management
- When the task requires legal or compliance expertise beyond technical scope
Prerequisites
- DNS query logs from recursive resolver, Zeek/Bro, Suricata, or passive DNS tap
- Python 3.9+ with
numpy, scikit-learn, pandas, tldextract, and dnspython
- Zeek (formerly Bro) with dns.log output or Suricata with DNS EVE JSON logging
- SIEM access (Splunk, Elastic, Microsoft Sentinel) for log correlation
- Passive DNS database access (CIRCL pDNS, Farsight DNSDB, or internal) for enrichment
- Wireshark/tshark for packet-level DNS inspection
- Known-good domain whitelist (Alexa/Tranco top 1M or Majestic Million)
Workflow
# Example: IOC detection
import re
IOC_PATTERNS = {
"ip": r"\b(?:\d{1,3}\.){3}\d{1,3}\b",
"domain": r"\b[a-z0-9-]+\.[a-z]{2,}\b",
"hash_md5": r"\b[a-f0-9]{32}\b",
"hash_sha256": r"\b[a-f0-9]{64}\b",
}
def extract_iocs(text: str) -> dict:
return {k: re.findall(v, text) for k, v in IOC_PATTERNS.items()}
- Define Detection Scope — Identify the specific command and control over dns techniques or indicators to hunt. Map to MITRE ATT&CK tactics/techniques where applicable.
- Collect Baseline Data — Gather historical logs and establish normal behavior patterns for command and control over dns.
- Build Detection Queries — Write detection rules, Sigma rules, or SIEM queries targeting command and control over dns indicators.
- Execute Hunts — Run queries against the collected data, starting with broad filters and narrowing down.
- Triage Results — Investigate alerts, filter false positives, and validate findings against known-good behavior.
- Document Findings — Record confirmed detections, IOCs, and affected systems. Update detection rules based on findings.
Tools
- SIEM Platform — Central log aggregation and query execution
- Sigma Rules — Vendor-agnostic detection rule format
- MITRE ATT&CK Navigator — Technique mapping and coverage analysis
Process
- Reconnaissance — Gather target information, identify attack surface, enumerate services
- Analysis/Exploitation — Execute the technique, analyze results, document findings
- Reporting — Document IOCs, write findings, provide remediation recommendations
Verification
Anti-Rationalization Table
| Rationalization |
Reality |
| "We are too small to be targeted" |
Automated attacks target everyone. Size does not matter. |
| "Security slows us down" |
A breach slows you down 100x more. Build security in from the start. |
| "We will fix it after launch" |
Vulnerabilities in production are exploited within hours. Fix before deploy. |
1---2name: detecting-command-and-control-over-dns3description: Use when detecting command-and-control (C2) communications tunneled through DNS protocol including DNS tunneling tools (Iodine, dnscat2, dns2tcp, Cobalt Strike DNS beacon), domain generation algorithms (DGA), encoded payload delivery via TXT/CNAME records, and DNS beaconing patterns. Covers Shannon entropy analysis of query subdomains, statistical anomaly detection, ML-based DGA classification, passive DNS correlation, and Zeek/Suricata signature development.4license: Apache-2.05---67# Detecting Command And Control Over Dns89## Overview1011Cybersecurity skill for detecting command and control over dns. Follows industry best practices and security standards.1213## When to Use14**Trigger phrases:**15- "detecting command and control over dns"16- "Detects command-and-control (C2) communications tunneled through DNS protocol in"171819- Investigating suspected DNS tunneling used for C2 communication or data exfiltration20- Analyzing DNS query logs for signs of encoded payloads in subdomain strings21- Classifying domains as DGA-generated vs. legitimate using statistical or ML methods22- Detecting DNS beaconing patterns (regular intervals, consistent query sizes)23- Hunting for Iodine, dnscat2, dns2tcp, Cobalt Strike DNS, or Sliver DNS traffic24- Monitoring TXT record abuse for command delivery or staged payload download25- Building DNS anomaly detection rules for SOC/SIEM deployment2627**Do not use** for general DNS performance monitoring or DNS configuration auditing; use DNS health monitoring tools for those. For HTTP/HTTPS-based C2 detection, use network traffic analysis skills focused on web protocols.2829**DISCLAIMER**: DNS tunneling tools referenced in this skill (Iodine, dnscat2, dns2tcp) are dual-use. They have legitimate uses (bypassing captive portals, security research) and malicious uses (C2 channels, exfiltration). Only deploy detection in networks you are authorized to monitor. Testing tunneling tools requires explicit authorization.303132## When NOT to Use3334- When you lack proper authorization for testing35- For production systems without change management36- When the task requires legal or compliance expertise beyond technical scope373839## Prerequisites4041- DNS query logs from recursive resolver, Zeek/Bro, Suricata, or passive DNS tap42- Python 3.9+ with `numpy`, `scikit-learn`, `pandas`, `tldextract`, and `dnspython`43- Zeek (formerly Bro) with dns.log output or Suricata with DNS EVE JSON logging44- SIEM access (Splunk, Elastic, Microsoft Sentinel) for log correlation45- Passive DNS database access (CIRCL pDNS, Farsight DNSDB, or internal) for enrichment46- Wireshark/tshark for packet-level DNS inspection47- Known-good domain whitelist (Alexa/Tranco top 1M or Majestic Million)4849## Workflow5051```python52# Example: IOC detection53import re5455IOC_PATTERNS = {56 "ip": r"\b(?:\d{1,3}\.){3}\d{1,3}\b",57 "domain": r"\b[a-z0-9-]+\.[a-z]{2,}\b",58 "hash_md5": r"\b[a-f0-9]{32}\b",59 "hash_sha256": r"\b[a-f0-9]{64}\b",60}6162def extract_iocs(text: str) -> dict:63 return {k: re.findall(v, text) for k, v in IOC_PATTERNS.items()}64```65661. **Define Detection Scope** — Identify the specific command and control over dns techniques or indicators to hunt. Map to MITRE ATT&CK tactics/techniques where applicable.672. **Collect Baseline Data** — Gather historical logs and establish normal behavior patterns for command and control over dns.683. **Build Detection Queries** — Write detection rules, Sigma rules, or SIEM queries targeting command and control over dns indicators.694. **Execute Hunts** — Run queries against the collected data, starting with broad filters and narrowing down.705. **Triage Results** — Investigate alerts, filter false positives, and validate findings against known-good behavior.716. **Document Findings** — Record confirmed detections, IOCs, and affected systems. Update detection rules based on findings.7273## Tools7475- **SIEM Platform** — Central log aggregation and query execution76- **Sigma Rules** — Vendor-agnostic detection rule format77- **MITRE ATT&CK Navigator** — Technique mapping and coverage analysis787980## Process81821. **Reconnaissance** — Gather target information, identify attack surface, enumerate services831. **Analysis/Exploitation** — Execute the technique, analyze results, document findings841. **Reporting** — Document IOCs, write findings, provide remediation recommendations8586## Verification8788- [ ] All command and control over dns procedures executed completely and documented89- [ ] Findings validated against multiple data sources90- [ ] False positives identified and filtered91- [ ] Results documented with evidence and timestamps92- [ ] Recommendations provided with risk-based prioritization9394## Anti-Rationalization Table9596| Rationalization | Reality |97|---|---|98| "We are too small to be targeted" | Automated attacks target everyone. Size does not matter. |99| "Security slows us down" | A breach slows you down 100x more. Build security in from the start. |100| "We will fix it after launch" | Vulnerabilities in production are exploited within hours. Fix before deploy. |