What is domain-based command and control?¶
The practical answer¶
Domain-based command and control uses a domain name to direct compromised systems towards control infrastructure.
The key evidential caution¶
The dangerous assumption is that resolving a suspicious domain proves successful command and control.
It does not.
A device may perform a DNS lookup without completing a connection.
The domain may resolve to several addresses.
It may be hosted behind a content-delivery or cloud service.
The domain may change destination over time.
Evidence to preserve¶
Investigators should preserve:
Key points¶
- the full domain
- DNS query and response
- resolved addresses
- timestamps
- time-to-live values
- certificate details
- network connections
- process responsible
- registration and hosting information
- historical resolution where available
The same domain may be used for websites, APIs, redirection or control traffic.
The process and traffic pattern matter.
Evidential limits¶
Do not assume the registrant is the offender. Registration details may be false, privacy-protected, compromised or linked to a reseller.
A domain may also be generated automatically or rotated frequently.
Where the domain is still active, preservation and provider requests may be urgent.
Domains may also be used only briefly before rotating to another name or address. Historical DNS data, certificate records and malware configuration may help reconstruct that change. Current resolution should not be treated as proof of where the domain pointed during the incident.
Preserve any domain-generation logic or fallback domains found in malware configuration, because they may reveal alternative control routes not seen in the available logs.
Record that distinction explicitly.
Operational takeaway¶
Separate DNS resolution, connection and command activity, and preserve the domain’s historical hosting and registration context before drawing attribution conclusions.