| name | hunting-for-dns-based-persistence |
| description | Hunt for DNS-based persistence mechanisms including DNS hijacking, dangling CNAME records, wildcard DNS abuse, and unauthorized zone modifications using passive DNS databases, SecurityTrails API, and DNS audit log analysis. |
| domain | cybersecurity |
| subdomain | threat-hunting |
| tags | ["dns","persistence","threat-hunting","passive-dns","dns-hijacking","subdomain-takeover","securitytrails"] |
| version | 1.0 |
| author | mahipal |
| license | Apache-2.0 |
| nist_csf | ["DE.CM-01","DE.AE-02","DE.AE-07","ID.RA-05"] |
Hunting for DNS-based Persistence
Overview
Attackers establish DNS-based persistence by hijacking DNS records, creating unauthorized subdomains, abusing wildcard DNS entries, or modifying NS delegations to redirect traffic through attacker-controlled infrastructure. These techniques survive credential rotations, endpoint reimaging, and traditional remediation because DNS changes persist independently of compromised hosts. Detection requires passive DNS historical analysis, zone file auditing, and monitoring for unauthorized record modifications. This skill covers hunting methodologies using SecurityTrails passive DNS API, DNS audit logs from Route53/Azure DNS/Cloudflare, and zone transfer analysis.
When to Use
- When investigating security incidents that require hunting for dns based persistence
- When building detection rules or threat hunting queries for this domain
- When SOC analysts need structured procedures for this analysis type
- When validating security monitoring coverage for related attack techniques
Detection Gaps & Validation
- Passive DNS has sampling gaps. SecurityTrails free tier (50 queries/month) and similar feeds miss fast-flux and short-lived records, so absence in passive DNS is not proof of safety.
- Dangling CNAME → subdomain takeover is the most-missed path: a CNAME pointing to a deprovisioned cloud resource (released S3 bucket, Azure App Service, Heroku app) lets an attacker claim it with no access to your DNS account at all.
- Wildcard
* records mask malicious subdomains from enumeration; NS/MX delegation hijack survives host reimaging and credential rotation.
- DoH/DoT resolution bypasses internal DNS logging — endpoints resolving via 1.1.1.1/8.8.8.8 over 443 won't appear in your resolver logs.
- Validate the hunt fires: create a test CNAME to a released cloud resource and confirm your takeover/dangling-record detection flags it; diff a fresh zone export (AXFR or provider API) against the baseline and confirm an injected record is caught.
- FP tuning: legitimate CDN/SaaS CNAMEs, dynamic DNS, marketing/transient subdomains, and cloud auto-provisioned records.
Prerequisites
- SecurityTrails API key (free tier provides 50 queries/month)
- Access to DNS provider audit logs (Route53, Azure DNS, Cloudflare, or on-premises DNS)
- Python 3.9+ with requests library
- DNS zone file access or AXFR capability for internal zones
- Historical DNS baseline for comparison
Steps
Step 1: Baseline DNS Records
