Blocking a command and control domain often does not end the intrusion: well-built implants carry a second, third or tenth way home and switch to it as soon as the first one fails. MITRE ATT&CK tracks this as T1008 Fallback Channels: adversaries may use fallback or alternate communication channels if the primary channel is compromised or inaccessible, to maintain reliable command and control and to avoid data transfer thresholds. The practical consequence is that containment itself can trigger the fallback. This guide explains the fallback designs recorded in ATT&CK v20, how to find them before you block, the detections that catch the switch, and a containment sequence that closes every channel at once. It is written for SOC analysts, incident responders, threat hunters and network engineers, and stays defensive. For C2 as a whole, see the Command and Control (C2) Guide; for beacon analytics, the Beaconing and C2 Detection Guide.
Key takeaways
- Your block is the trigger. Many implants fall back only when the primary channel fails, so the first observable switch often follows your own containment action.
- Scope every channel before blocking any. Extract the full configuration (servers, ports, protocols, web services, generation algorithms) from memory or samples, then block all of it in one window.
- Fallbacks change shape, not just address. ATT&CK records HTTP falling back to DNS, TCP to HTTP, port 443 to 80 or 8080, and primary servers to GitHub, calendar or social media services.
- Default-deny egress shrinks the fallback menu. If servers can only reach a short list of destinations through a proxy, most alternate protocols and ports fail closed.
- Keep watching after closure. Some fallbacks wake on a timer: ATT&CK records Ebury switching to a domain generation algorithm after three days without contact.
What T1008 covers in ATT&CK v20
T1008 is a Command and Control technique with no sub-techniques. ATT&CK v20 lists ESXi, Linux, macOS and Windows as platforms. It describes a design property rather than a protocol, so it almost always appears alongside the technique that carries each channel: T1071 Application Layer Protocol (including T1071.004 DNS), T1095 Non-Application Layer Protocol, T1102 Web Service, T1568 Dynamic Resolution (including T1568.002 Domain Generation Algorithms), T1572 Protocol Tunneling and T1090 Proxy. It is closely related to T1104 Multi-Stage Channels, where different stages of an implant use different channels by design rather than as a backup.
The ATT&CK procedure examples fall into six fallback designs. Knowing which design you face tells you where to look for the rest of the configuration.
| Fallback design | Examples recorded in ATT&CK v20 | What it means for containment |
|---|---|---|
| Server list (same protocol) | DustySky has two hard-coded domains; TAINTEDSCRIBE picks from five hard-coded IPs and waits 60 seconds before trying another; TinyTurla and Kwampirs cycle through server lists; Bumblebee and Bazar use backup servers | Blocking one address only rotates the implant to the next; extract the whole list |
| Protocol fallback | OilRig's ISMAgent falls back to DNS tunnelling if HTTP fails; FIN7's Harpy uses DNS as backup; RDAT uses HTTP when DNS fails; QUADAGENT uses HTTPS, HTTP and DNS; RainyDay switches between TCP and HTTP; Mis-Type falls back from raw TCP to HTTP | Proxy blocks alone are not enough; DNS resolution and raw outbound sockets must also be controlled |
| Port fallback | S-Type uses port 80 then 443 or 8080; SideTwist uses 443 with 80 as fallback; XTunnel receives a fallback port from its server | Port-specific blocks fail; filter by destination and process, not port |
| Web service or dead drop fallback | Crutch used a hard-coded GitHub repository as fallback; APT41 used a Steam community page; BlackEnergy a social network page; MiniDuke used web search when its social media channel failed; GlassWorm used Google Calendar as backup C2 | Traffic goes to legitimate, widely allowed services; detection must focus on the process making the request |
| Generated or retrieved addresses | Ebury begins using a DGA after three days without operator contact; Stuxnet can generate new C2 domains; CharmPower retrieves a new domain from an S3 bucket every 360 loops; PipeMon switches domain on a set date | Fallback can be dormant for days; plan for weeks of monitoring after closure |
| Redundant footholds | Uroburos can use up to 10 channels between implants; UNC3886 employed layers of redundancy across network devices, hypervisors and virtual machines; Night Dragon used company extranet servers as secondary C2 | The fallback may be another compromised system inside your estate, not an external server |
The open source Mythic framework, recorded under T1008 as a tool, supports a list of C2 URLs as fallback in case one IP or domain is blocked. Assume any framework-based intrusion may have the same property.
ATT&CK also records two recent supply chain cases where a fallback used the victim's own developer accounts: TeamPCP Cloud Stealer can use the victim's GitHub account if its primary exfiltration POST fails, and Mini Shai-Hulud established fallback channels to exfiltrate to GitHub when other infrastructure was unreachable. The GlassWorm campaign layered Solana transactions, Google Calendar event titles and a direct IP address, which made takedown of any one channel ineffective.
Finding the fallback before you block
The single most useful thing a responder can do against T1008 is to learn the full channel configuration before touching any of it.
- Capture memory first: many implants hold their configuration only in memory. Acquire memory from at least one affected host before isolation or reboot.
- Extract the configuration: through malware analysis (in-house or a trusted provider), recover every server, port, protocol, web service URL, generation seed and timer. Public reporting on the same family often lists fallback behaviour; check the ATT&CK software page for the family.
- Look sideways in telemetry: query DNS, proxy, firewall and EDR network logs for the same process, hash or JA3/JA4-style fingerprint reaching any other destination, and for other hosts reaching the known destinations.
- Check internal relays: look for internal hosts acting as proxies or relays for the implant (internal port forwarding, SMB named pipes, peer-to-peer traffic between workstations). See the T1090 Proxy Defensive Guide.
- List identity-based channels: where the implant uses a cloud or developer service, note which account or token it uses. That credential is part of the channel and must be revoked with it.
Detecting the switch
MITRE's detection strategy DET0499, Behavioral Detection of Fallback or Alternate C2 Channels, looks for new outbound connections on uncommon ports or protocols following disruption or blocking, often from processes that normally have no network activity. Its analytics name Sysmon Event IDs 3 (network connection) and 22 (DNS query) on Windows, auditd outbound connection records on Linux, unified log and flow data on macOS, and vmkernel and vpxd logs on ESXi, with network flow data on every platform.
| Signal | Data source | Why it indicates a fallback |
|---|---|---|
| Process with a recently blocked destination starts contacting a new one | EDR network events, Sysmon Event ID 3, proxy logs | Classic server-list rotation after a block |
| Same process moves from HTTP(S) to DNS: high query volume, long or high-entropy subdomains to one parent domain | Sysmon Event ID 22, resolver logs, protective DNS | Protocol fallback to DNS tunnelling |
| Outbound on 53, 80, 8080 or high ports direct to the internet, bypassing the proxy | Firewall and flow logs | Protocol or port fallback when proxy-aware traffic fails |
| Non-browser process reaching code hosting, calendar, social or file sharing APIs | Proxy logs with process attribution, EDR | Web service or dead drop fallback |
| Burst of NXDOMAIN responses from one host | Resolver logs | DGA fallback cycling through unregistered domains |
| Hypervisor or management interface talking to unusual external addresses | ESXi vmkernel, vpxd and network logs | Fallback from appliances and hypervisors, which often lack EDR |
The strongest rule is a correlation with your own response: after any C2 block, watchlist the affected hosts and process hashes for new external destinations for at least 30 days (our recommendation, extended to cover any timer found in the configuration). For DNS and other tunnelled fallbacks see the T1572 Protocol Tunnelling Defensive Guide.
Prevention: narrowing the fallback menu
ATT&CK v20 maps M1031 Network Intrusion Prevention to T1008: network signatures for specific malware families can block traffic at the network level, though signatures are tied to known protocols and change over time. Structural controls do more because they work against families you have not seen yet.
- Default-deny egress for servers: servers reach only the destinations they need, through a proxy where possible (NIST SP 800-53 SC-7(5)). Alternate ports and raw sockets then fail, and the fallback menu shrinks to whatever the proxy allows.
- Force DNS through controlled resolvers: block direct outbound DNS and DNS over HTTPS to unapproved resolvers, and use a protective DNS service that blocks newly registered and known-bad domains. This removes most DNS and DGA fallbacks.
- Restrict web service access by process: allow code hosting, file sharing and calendar APIs from the browsers and tools that need them, not from every process on a server.
- Segment management planes: hypervisors, network devices and appliances should not have general internet access (M1030 Network Segmentation).
- Monitor outbound traffic as a control: NIST SP 800-53 SI-4(4) calls for monitoring inbound and outbound communications for unusual or unauthorised activity.
Choosing your egress model
| Model | Fallback resistance | Fits |
|---|---|---|
| Open egress with blocklists | Low: every fallback not on a list works | Not recommended for servers |
| Proxy-enforced web, open DNS | Medium: DNS and raw socket fallbacks still work | Transitional state for user networks |
| Proxy-enforced web, controlled DNS, port restrictions | High for user networks | Most organisations, user and server segments |
| Destination allowlist per server role | Highest: unknown destinations fail closed | Servers, OT gateways, hypervisors, regulated estates; needs good application inventory |
Smaller organisations without a proxy can still get most of the benefit from a protective DNS service, blocking outbound DNS except from their resolvers, and host firewalls that deny outbound traffic from servers by default.
A containment sequence that closes every channel
- Observe quietly: do not block known C2 while you scope. Watch the channel, capture memory and collect network evidence for the full dwell period.
- Build the full block set: all servers, domains, ports, protocols, web service URLs, internal relays and the credentials or tokens used for service-based channels.
- Prepare host containment: stage EDR isolation for every affected host, and plan for systems without EDR (appliances, hypervisors) by isolating at the switch or firewall.
- Execute in one window: apply DNS sinkholes, proxy and firewall blocks, host isolation and credential revocation together, so no channel survives to warn the operator or receive the fallback.
- Watch for the switch: run the detections in the previous section on the affected hosts and their neighbours. Any new outbound attempt is a missed channel; add it and repeat.
- Eradicate and rebuild: remove the implant, rebuild where integrity is uncertain, and keep the watchlist running through any dormant timer.
The full incident process is in the Incident Response Guide.
Where identity fits
Web service fallbacks increasingly run on accounts and tokens: a GitHub repository, a cloud storage bucket, an OAuth-connected calendar or a bot token. When the fallback uses the attacker's own account, the provider's abuse process is the takedown route. When it uses the victim's account or a stolen token, the token is part of the C2 channel and revoking it closes that path. Inventory the developer and SaaS tokens present on affected hosts and revoke them during the containment window. See the Secrets Management Guide and How to revoke a leaked GitHub personal access token.
Measuring it
- Re-contact rate: percentage of contained C2 incidents where a new channel appeared after containment (target trending to zero).
- Configuration extraction rate: share of C2 incidents where the full channel configuration was recovered before blocking.
- Server egress allowlist coverage: percentage of servers on destination allowlists or proxy-only egress.
- Direct DNS egress: count of hosts resolving through anything other than approved resolvers, trending to zero.
- Post-containment watch duration: days of active monitoring after closure, compared with the longest timer found in the configuration.
Framework mapping
| Framework | Reference | Relevance to T1008 |
|---|---|---|
| MITRE ATT&CK v20 | T1008; T1071, T1095, T1102, T1104, T1568, T1572, T1090 | Technique and the channel techniques it combines with |
| MITRE ATT&CK mitigations | M1031; M1030, M1037 (our additions) | Network intrusion prevention, segmentation, traffic filtering |
| NIST SP 800-53 Rev 5 | SC-7, SC-7(5), SI-4, SI-4(4), IR-4 | Boundary protection with deny by default, outbound monitoring, incident handling |
| NIST CSF 2.0 | DE.CM-01, RS.MI-01 | Network monitoring and containment |
Common failure patterns
- Block first, scope later: the known domain is blocked on day one, the implant rotates, and the incident is closed while traffic continues on the backup.
- Port-based thinking: blocking 443 to an address while the implant falls back to 80 or 8080 on another.
- DNS left open: web egress is proxied, but hosts can still resolve arbitrary domains directly, so DNS tunnelling fallbacks work.
- Trusted service blind spot: code hosting, calendar and social media services are allowed for every process, so dead drop fallbacks never stand out.
- No watch after closure: monitoring stops when the ticket closes, missing date or inactivity triggered fallbacks.
- Appliances forgotten: hypervisors and network devices with their own footholds keep a channel open after every endpoint is clean.
Practitioner checklist
- Capture memory and extract the full channel configuration before blocking any C2 indicator.
- Query DNS, proxy, firewall and EDR telemetry for every destination the implicated processes and hashes have reached.
- Block all servers, protocols, ports, web service paths and tokens in a single coordinated window with host isolation.
- Deploy post-containment watchlists for at least 30 days, longer if a timer is found.
- Move servers to destination allowlists or proxy-only egress, and block direct outbound DNS.
- Restrict non-browser processes from reaching code hosting, file sharing and calendar APIs on servers.
- Remove general internet access from hypervisors, network devices and appliances.
- Track re-contact rate after containment as the headline measure for this technique.
Standards and references
- MITRE ATT&CK: T1008 Fallback Channels
- MITRE ATT&CK: T1104 Multi-Stage Channels
- MITRE ATT&CK: M1031 Network Intrusion Prevention
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
- Microsoft Learn: Sysmon
- MITRE ATT&CK: Crutch (S0538)
Related NHI Mgmt Group resources: Command and Control (C2) Guide · Beaconing and C2 Detection Guide · T1090 Proxy Defensive Guide · Incident Response Guide