Domain Generation Algorithms

T1568.002 is one of three Dynamic Resolution sub-techniques, next to Fast Flux DNS (T1568.001) and DNS Calculation (T1568.003), and it sits in Command and Control. It is a symptom of an infection that has already run. Unit 42 puts it plainly: a DGA cannot harm you by itself, it makes the malware harder to block. In your logs it shows up right after execution, at each reboot and whenever the main C2 stops answering.

MITRE's procedure list reads like a catalog of commodity malware and espionage tooling: QakBot, Ursnif, Bazar, AsyncRAT, Astaroth, ShadowPad, Conficker and APT41. A DGA hit therefore says little about who is behind it. Recovering the algorithm means reverse engineering the sample, which MITRE calls time and resource intensive, and malware that mixes in a per-instance seed makes the future domains unpredictable even then.

The variant to know is the registered DGA. Infoblox describes actors that generate domains, register all of them, and either use them at once or age them for months. Because the names resolve, the NXDOMAIN burst that traditional DGAs produce mostly disappears, and the algorithm stays private to the actor instead of sitting in a sample you can reverse. Infoblox reports some actors maintaining more than 80,000 domains at a time and says traditional DGAs are less common than they were five to seven years ago.

Several ordinary things look like this. Content delivery networks, update services and cloud storage endpoints use machine-generated hostnames that score high on entropy. Chromium-based browsers send random single-label lookups on their own, and the answers normally come back NXDOMAIN. An application pointed at a retired hostname retries it all day, and a vulnerability scanner or an internal red team running DNS brute force makes thousands of failed lookups by definition.

The discriminator is distinct names per process. A retry loop produces many failures for one name, a scanner usually runs from a host you can name, and browsers are a known image you can exclude. A DGA produces many different names from an executable that has no business resolving them, most of them failing. Combine the failure burst with name scoring and process context, and review the first week of alerts to build the allowlist before you rely on the rule.

Start with the host and the process. Take the image path, the hash and the parent process from the DNS event, and check whether the binary is signed and where it lives. Then look at the lookups themselves. The one name that resolved is your live C2 candidate, so record its answer, its registration date from RDAP and its history in passive DNS, and look for connections from the same host to that address right after the lookup.

Block and scope. Add the resolved domain and address to the blocklist or sinkhole, but do not stop there: the algorithm will produce a new list tomorrow, so the lasting fix is removing the malware. Search resolver logs for other hosts querying the same names and the same pattern, because one infection often means a family that landed on several machines. If threat intelligence identifies the family and its algorithm, pre-block the upcoming domains, though MITRE notes this is expensive and a per-instance seed defeats it.

For registered DGAs, work from the infrastructure instead of the failures. Cluster the resolved names by registrar, creation date and name servers, and treat a group of recently registered, similar-looking domains seen from one host as one campaign. Finish by reimaging or cleaning the host according to what the process turned out to be, and rotate any credentials that were present on it.