Fallback Channels (T1008) is a command and control technique. Adversaries use fallback or alternate communication channels if the primary channel is compromised or inaccessible. MITRE says this keeps command and control reliable and helps avoid data transfer thresholds. Platforms are ESXi, Linux, macOS and Windows.
How attackers use it
The idea is resilience. If you block the main route, the compromised host tries another. That could be a different port, a different protocol, or a different destination. MITRE does not tie it to one tool. The behavior is the same across malware families, which is why signatures alone are a weak answer.
For a defender, this means that blocking a bad destination is the start of the work, not the end. After a block, watch what the host does next.
How to detect it
MITRE's analytic is about behavior after disruption:
- Windows: connections on uncommon ports or protocols after C2 disruption or blocking, often from processes that normally have no network activity.
- Linux: outbound connections on alternate ports or using covert transport such as ICMP or DNS from processes that are not network-intensive, following blocked traffic.
- macOS: outbound fallback traffic from low-profile or background launch agents using unusual protocols or destinations after the primary channel went quiet.
- ESXi: outbound traffic from host management services or guest-to-host interactions over unusual interfaces, such as backdoor API endpoints or external VPN tunnels.
The most useful trick is to treat your own blocks as a detection source. When your proxy or firewall blocks a connection from a host, put that host on a short watch list for the next day. Then look for new destinations, ports or protocols from the same host.
Useful data sources include firewall and proxy logs, DNS logs, and process attribution on endpoints.
How to reduce the risk
MITRE lists Network Intrusion Prevention. Network signatures can mitigate activity at the network level. MITRE notes that signatures are often based on unique indicators within a protocol, may be specific to one adversary or tool, and will likely differ across malware families and versions.
So combine them with restrictive egress. A default deny policy on outbound traffic makes the fallback channels harder, because the new port or protocol is also blocked. Allow DNS only through your own resolvers, and watch for ICMP and DNS volume that does not fit.
A short field guide to fallback behavior
Fallback behavior has a few recognizable shapes, and it helps to know them before you read logs.
- Port switching. The same destination, a different port, after the first one is blocked.
- Protocol switching. A host that was using web traffic moves to DNS or ICMP, which MITRE names for Linux.
- Destination switching. A new address or name, often after the first was blocked or taken down.
- Interface switching. On ESXi, traffic through management or guest interfaces that are not the normal route.
In each shape, there is a trigger and a response. If you can see the trigger, which is your own block, you can look for the response in the minutes and hours that follow.
Turning your blocks into a tripwire
Most organizations block thousands of connections per day, and nobody reads them. Make them useful with a simple rule. When a host has a blocked connection to a category you care about, such as a known bad destination or an uncommon port, add that host to a watch list for 24 hours. During the watch, any new external destination, new port or new protocol from that host raises an alert.
The rule costs little. It uses logs you already have, and it targets exactly the behavior MITRE describes.
Low-activity processes
MITRE notes several times that the process involved often has no network activity normally. That is a strong filter. Build an inventory of the processes that make outbound connections on each server class. A process outside the list that opens a connection, especially on an unusual port, is far more interesting than a browser doing the same.
Hardening the egress path
- Default deny outbound from servers and allow only what each role needs.
- Resolve DNS only through your own resolvers, and block direct DNS to the internet.
- Inspect or limit ICMP leaving the network.
- Keep management interfaces for hypervisors and network devices off the internet and off general networks.
With those in place, the fallback has nowhere to go, and each attempt becomes a log entry.
After an incident
When you clean up a host that used C2, remember that blocking one destination does not prove the adversary is gone. Review all outbound connections from that host over the whole period, not just the one you found. Ask which other destinations it contacted, and block them together. Then watch the host and its neighbors for a week.
Check your own environment
- Do servers have default deny on outbound traffic, with a short allowlist?
- Do you log blocked connections, and do you review them by source host?
- Are ESXi management interfaces blocked from the internet?
- Can a workstation reach the internet on any port, or only through a proxy?
The demo below walks through how an incident unfolds and how the review afterward improves controls, which is where fallback behavior often gets noticed.
Click through it at your own pace, or open it full screen.
Quick check
Why does blocking the first C2 destination not end the problem?
The technique exists so the host can switch to a different port, protocol or destination. After a block, watch the same host for new outbound behavior.
What does MITRE say about signature-based mitigation?
Signatures are often based on unique indicators of a specific tool or adversary and will likely be different across malware families and versions, so they cover only part of the problem.
