Fallback Channels

A command and control channel is simply the route an implant uses to reach whoever is operating it. A fallback channel is the alternative route the implant is built to use when the first one does not work: a different destination, a different port, a different protocol, or all three. The purpose is resilience. An operator who loses contact the first time a network changes, a service goes down or a control blocks them has lost their access entirely, and building in a second route is the cheapest possible insurance against that.

The property that matters for detection is that this technique is defined by a RELATIONSHIP between attempts rather than by any one of them. A fallback connection, examined on its own, looks like an ordinary outbound connection, because that is exactly what it is. What identifies it as a fallback is the attempt that failed before it.

Implants are commonly configured with a list of destinations rather than a single one, and they work down it. Some rotate on a schedule regardless of success, which produces a regular pattern. Most simply try the next entry when the current one fails, which produces no pattern at all beyond the failure and the success sitting near each other in time.

There is a second use that is less about resilience and more about reconnaissance. An attacker who does not know an estate's egress policy does not need to: they can let the network answer the question. Attempt a route, observe whether it was permitted, and move to the next. Each denial is information, and the eventual success tells them precisely what the policy allows. From the defender's side this is the most useful form to recognise, because the attacker has effectively mapped the egress policy in the logs, and the same records that show them what worked show you what they tried.

A fallback channel also frequently differs from the primary in KIND and not only in address. Falling back from one protocol to another, or from a conventional port to an unconventional one, is common, which is why this technique so often appears alongside the ones covering unusual ports and tunnelling.

Data source: Network policy telemetry from the egress control point, covering attempts that were denied as well as connections that were permitted, read together with the flow records for the connections themselves

Work in both directions from whichever half you already have.

From a suspect connection, look BACKWARD. The useful question is not whether this destination is bad, which is frequently unanswerable, but whether the same source tried to reach somewhere else first and was stopped. A denial from the same host shortly before turns an ambiguous outbound connection into a sequence, and a sequence is a decision by something on that host rather than an accident.

From a denied attempt, look FORWARD. A source that was blocked and then connected successfully somewhere else is the same finding approached from the other side, and this direction is the more productive one to run routinely, because denials are recorded by the control point whether or not anything ever alerted.

Correlate on source and time, and keep the window narrow: what makes the pair meaningful is proximity, and a wide window will pair unrelated events from a busy host with each other. Compare the two legs as well as noting that both exist, because the ways they DIFFER are the interesting part. A fallback to a different destination on the same port, and a fallback to the same sort of destination on a very different port, say different things about what the implant was configured to work around.

Denied outbound attempts are constant in any real estate and overwhelmingly benign. Misconfigured agents, software checking for updates against endpoints the policy does not allow, clients still calling services that were decommissioned and monitoring that was pointed somewhere before a network change all generate them continuously. A denial on its own carries almost no information.

The discriminator is the SEQUENCE, from a single source, within a narrow window: a denial, followed by a successful connection from that same host to a destination or a port it has no established reason to use. Each half is unremarkable and the pair is not.

Two shapes rule themselves out quickly. A host that is denied over and over and never succeeds is usually broken rather than compromised, because a fallback that never falls back to anything achieved nothing. A host that is denied and then succeeds against a destination it reaches routinely anyway has simply retried, which is what well behaved software does. What survives both is a host that was stopped, changed something about where or how it was going, and then got out.

• MITRE ATT&CK: T1008 Fallback Channels

No range covers this technique yet; the write-up above landed first. Ranges are added continuously; the ones live today are on the training ladder.