Dynamic Resolution (T1637) is mobile malware computing where its command and control (C2) server is, instead of carrying a fixed address that defenders can block. ATT&CK describes malware sharing an algorithm with the adversary's infrastructure, so both sides can derive the same domain name, IP address or port at the same time. Blocking one domain then achieves little, because the next one is already scheduled. MITRE ATT&CK v20 lists T1637 under Command and Control for Android and iOS, with one sub-technique, Domain Generation Algorithms (T1637.001). This guide is for mobile security engineers, DNS and network security teams and SOC analysts: what the technique looks like on a phone, what ATT&CK's v20 analytics measure, and which network controls you need to see it at all. For the matrix overview see the MITRE ATT&CK for Mobile Guide.
Key takeaways
- It defeats static blocklists. ATT&CK notes a DGA can produce thousands of candidate domains, which makes blocking, tracking and takedown harder.
- The recorded cases are all Android. ATT&CK v20 lists the technique for both platforms but its four procedure examples (FluBot, Mandrake, Rotexy, SharkBot) are Android malware.
- No mitigation is mapped. ATT&CK v20 maps no mitigation to T1637, so the defence is network visibility and app control rather than a device setting.
- Failed lookups are the signal. ATT&CK's analytics look for bursts of NXDOMAIN responses from one app, high-entropy labels and a successful lookup to a young domain shortly after.
- You need DNS data per app. Android network activity logging records the package name with each lookup; on iOS the equivalent visibility comes from per-app VPN or Network Extension flow data.
What T1637 covers
ATT&CK's parent technique covers any algorithm that adjusts C2 parameters dynamically: the domain, the IP address or the port. T1637.001 is the specific case of procedurally generated domain names, which ATT&CK notes can be used for C2 or for distributing malicious applications. The technique mirrors Enterprise Dynamic Resolution (T1568) and its DGA sub-technique (T1568.002), and it is one of several ways mobile malware keeps its channel alive alongside Application Layer Protocol. See the MITRE ATT&CK T1071 Application Layer Protocol guide for the channel itself.
| Software (ATT&CK v20) | What ATT&CK records | Defensive lesson |
|---|---|---|
| FluBot (S1067) | Can use DGAs to connect to the C2 server | Fast domain rotation makes takedown slow; per-app DNS anomaly detection works where blocklists lag |
| Mandrake (S0485) | Has used domain generation algorithms | Long-lived spyware still needs a reachable channel; lookups are where it shows |
| Rotexy (S0411) | Procedurally generates subdomains for C2 | Generated labels may sit under a fixed parent domain, so watch subdomain entropy, not only registered domains |
| SharkBot (S1055) | Keeps DGAs as a backup in case hardcoded C2 domains are unavailable | A sudden burst of failed lookups can follow a successful takedown of the primary domain |
For iOS, ATT&CK v20 lists the platform but records no procedure example. Treat iOS coverage as a matter of the same network analytics, not of known families.
How DGA traffic looks on a mobile network
An infected app tries generated names in sequence. Most do not exist, so the resolver answers NXDOMAIN. When the adversary has registered one of the names for the current period, a lookup succeeds and the app connects. Three things follow for defenders:
- Volume: many distinct hostnames from one app in a short window, far beyond its normal destinations.
- Shape: long, random-looking labels with high character entropy, unlike the CDN and API names a legitimate app uses.
- Age: the domain that finally resolves is often recently registered.
Encrypted DNS changes where you can see this. If an app or the device sends DNS over HTTPS or TLS to a resolver you do not control, a network monitor sees only the resolver connection. Point managed devices at a resolver you operate or contract, so the lookups stay visible. See the Encrypted DNS Enterprise Guide.
Detection: ATT&CK v20 analytics
ATT&CK v20 detection strategies DET0613 (Dynamic Resolution) and DET0669 (Domain Generation Algorithms) each have an Android and an iOS analytic. All share ATT&CK's rule: alert on a sequence or state change inconsistent with the device and app baseline, and do not infer unobserved activity from management state alone.
| Analytic | Platform | Data sources | Tunable fields (ATT&CK defaults) |
|---|---|---|---|
| AN1667 | Android | App vetting traces of rapid InetAddress.getByName() or DnsResolver calls; enterprise network logs (DnsEvent, ConnectEvent); VPN flow metadata | NXDOMAIN threshold 20 per device per app in the window (10 when tightened); window 60 s; 30 s from last NXDOMAIN to success; 10 distinct hostnames; 30-day per-app domain baseline |
| AN1668 | iOS | Entitlements and Info.plist keys from app vetting; Network Extension, per-app VPN or secure web gateway flow metadata | NXDOMAIN threshold 20 per device; window 60 s; 30 s to success; 30-day destination baseline; MDM app catalogue |
| AN1765 | Android | Permission grant state from the DPC; proxy or gateway DNS and HTTP(S) inspection; enterprise network logs | Entropy 3.5 bits (Shannon); label length 12 characters; 10 high-entropy queries in 60 s; domain age 30 days |
| AN1766 | iOS | App vetting; proxy or gateway inspection; Network Extension or per-app VPN flow metadata | Same entropy, length, count, window and domain age defaults as AN1765 |
ATT&CK states that these defaults should be calibrated from your own fleet DNS baseline. On Android, network activity logging is enabled with DevicePolicyManager.setNetworkLoggingEnabled() by a device owner (Android 8.0 or later) or a work profile owner (Android 12 or later). Google's documentation is explicit about its limits: it records DNS lookups that resolve a hostname and TCP connection attempts, it does not record UDP or connections made without a lookup, and batches of up to 1,200 events are deleted if not retrieved promptly. Google describes DNS events for lookups that resolve a hostname, with an address count of zero when a name did not resolve, so resolver or gateway logs remain the more complete source for an NXDOMAIN burst; use network logging for the successful lookup and the connection that follows.
Metrics that show it is working
- DNS visibility: percentage of managed devices whose DNS reaches a resolver or gateway that logs per device.
- Per-app attribution: share of DNS events that carry an app identifier (package name or per-app VPN tag).
- Baseline age: apps with at least 30 days of destination history, as the analytics require.
- Time to block: median time from a DGA alert to the domain being blocked at the resolver and the app being removed.
- False positive rate: confirmed malicious alerts against total, reviewed monthly while tuning thresholds.
Prevention and response
- Control DNS for managed devices. Send DNS from managed devices or the work profile through a protective DNS service or your own resolver. CISA's Protective DNS service, for example, filters queries against threat intelligence to stop resolution of known malicious domains and supports encrypted DNS. See the Protective DNS Guide.
- Route work traffic through a managed tunnel. Always-on VPN on Android (Android 7.0 or later) or per-app VPN on iOS gives the gateway the flow data the iOS analytics rely on.
- Baseline before you alert. Collect 30 days of per-app destinations, then switch the NXDOMAIN and entropy analytics on in report-only mode; tune before paging anyone.
- Close the delivery path. All four recorded families are Android malware, so app control matters as much as DNS. Disallow unknown sources on managed devices and keep Google Play Protect on.
- Respond at the device, not only the domain. A blocked DGA domain will be replaced. Identify the app from the log's package name, remove it through MDM, and check the device for the collection and exfiltration that the C2 channel supports.
Rollback: resolver blocks and gateway policy are reversible within minutes; keep an allow-override path so a false positive on a legitimate app's CDN can be cleared without turning the analytic off.
Where identity fits
Banking trojans in this list use the C2 channel to receive targets and send back stolen credentials and one-time passcodes. The domain is disposable; the stolen tokens are not. When a DGA alert fires on a managed device, revoke the sessions and refresh tokens of accounts used on that device, including mobile app tokens for corporate APIs. See the Mobile Access Credentials guide.
Common failure patterns
- Relying on domain blocklists alone. A DGA is designed to outrun them; the per-app behaviour is the durable signal.
- DNS you cannot see. Devices using an external encrypted resolver hide every lookup from the network team.
- Alerting before baselining. Ad SDKs and CDNs can look random; untuned entropy rules bury analysts in noise.
- Treating Android network logs as complete. They skip UDP, supporting DNS queries and connections made without a lookup.
- Cleaning the domain, not the device. Blocking the current domain without removing the app just moves the malware to the next one.
Framework mapping
| Framework | Reference | Why it applies |
|---|---|---|
| ATT&CK Enterprise | T1568 Dynamic Resolution; T1568.002 Domain Generation Algorithms | The Enterprise equivalent; network analytics carry over |
| NIST SP 800-53 Rev. 5 | SI-4 System Monitoring; SC-7 Boundary Protection; SC-20 Secure Name/Address Resolution Service | Monitor, filter and control name resolution at the boundary |
| NIST CSF 2.0 | DE.CM-01; PR.PS-05 | Monitor networks for adverse events; stop unauthorised software |
Practitioner checklist
- Point DNS for managed devices or work profiles at a resolver that logs per device.
- Enable Android network activity logging where you are device or work profile owner, and retrieve batches promptly.
- Deploy always-on VPN (Android) or per-app VPN (iOS) for work traffic.
- Build a 30-day per-app destination baseline before switching on DGA alerts.
- Start the ATT&CK defaults in report-only mode and tune entropy, length and NXDOMAIN thresholds to your fleet.
- Disallow unknown sources on managed Android devices.
- On a confirmed alert, remove the app, block the domain and revoke tokens used on the device.
Standards and references
- MITRE ATT&CK: Dynamic Resolution (T1637)
- MITRE ATT&CK: Domain Generation Algorithms (T1637.001)
- Android Developers: Network activity logging
- Android Developers: VPN
- CISA: Protective Domain Name System Resolver
- Google: Google Play Protect
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · DNS Logging and Detection Guide · Protective DNS Guide · Android Banking Trojans Guide · Mobile Malware Guide