Adversary C2 sits on the same CDN edge address as your payroll provider — how do you block it?

## The mistake this question is testing An indicator arrives as an address. Nothing about the address tells you it belongs to one tenant, and on modern hosting it usually does not. A single CDN edge or SaaS front end can terminate connections for thousands of customer hostnames, so 'block the address' and 'block the adversary' are different actions with different blast radii. The way out is to pick an enforcement point by **what it can see**. ## What each control on the path can actually see **Egress firewall.** Matches the five-tuple: source address, source port, destination address, destination port, protocol. That is the entire vocabulary. It cannot distinguish two hostnames sharing one address, because at that layer they are the same flow. Deny the address and both services die. **Forward proxy.** For plaintext HTTP it sees the request line and the Host header, so it can act on a full URL. For TLS it receives a `CONNECT host:443` request, and where clients connect transparently it reads the Server Name Indication field in the ClientHello. Either way it holds the **name** before the tunnel carries anything, so it can deny one hostname on a shared address. It does not see the body of an encrypted session unless it terminates TLS, which is a separate decision with its own consequences. **DNS sinkhole.** Acts on the name the client asked for and answers with an address you control. Clean separation of two tenants, and the sinkhole hit is itself a useful detection. Its weakness is that it only ever sees queries: an implant with a hardcoded address never asks, a client pointed at an external resolver asks somewhere else, and DNS-over-HTTPS hides the query inside a TLS session to a resolver you do not run. ## Reading the record Two proxy entries to the same destination address, one an exfiltration-sized upload through a sanctioned file-sync service and one an ordinary payroll session, is the whole problem in two lines. The `dst` field is identical; the `host` field is not. Only a control that keeps the `host` field can act on one and spare the other. ## What you enforce, and what you write down 1. **Enforce the name.** Push the hostname — or the full URL if you have it and the proxy supports path matching — into the proxy's destination list. This is the narrowest thing that stops the traffic. 2. **Allow-list the range explicitly.** Add the CDN or shared-hosting prefix to a maintained allow-list of things you will never deny at the address layer, each entry carrying an owner and a one-line reason. The point is not that you would not block it today; it is that six months from now a bulk push must hit a documented refusal rather than an accident. The engineer maintaining that list will never be able to enumerate every CDN range in existence, which is exactly why the entries need reasons rather than being a bare list of numbers. 3. **Keep a detection on the address.** Enforcement at the name layer is bypassable — no SNI, encrypted ClientHello, a direct-to-address connection, a different resolver. A flow or proxy detection on the address keeps you seeing contact even when the block does not fire, and its hits tell you whether the implant switched methods. 4. **Do not swap the block for blindness.** If you decide the collateral risk is too high to enforce at all on that path, the indicator must still be matched; declining to block is never declining to look. ## The directions to keep straight - A proxy deny on a hostname proves that a client asked for that name and was refused. It does not prove the client had no other route to the same destination. - An empty sinkhole log proves that no matching query reached your resolver. It does not prove the destination was never contacted. - A flow record to the shared edge address proves bytes moved to that address. It cannot tell you which tenant on that edge received them, because the record carries no payload and no name. That last point is why the address-layer detection is a supplement, not a verdict: it tells you to go and look at the proxy or endpoint record that still holds the name.