Why does an implant pick HTTPS to a permitted destination over a hard-coded IP on a custom port?
answer
- the path has to already exist
- nothing new is opened on the way out
- it travels with everyone else's browsing
- blocking cost decides whether it survives
basics
~20 sBecause the path already exists. In a fully proxied estate an arbitrary address on an odd port has no route outward at all, while port 443 to a destination the organisation already permits needs no new opening and looks like ordinary browsing.
solid answer
~50 sThe carrier is chosen before the first outbound request, and the code does not get to invent a path. In an estate where every request must traverse a forward proxy and only the internal resolver may speak outward, a compiled-in address on a custom port simply never leaves: nothing forwards it, and the operator loses the foothold they just worked to get. HTTPS to a destination the business already reaches - a large hosting or content-delivery domain, a service the organisation is contractually obliged to permit - uses the path that exists, needs nothing opened, and arrives mixed in with the same requests every employee makes. It is also block economics: a compiled-in address costs the operator nothing and dies at the first block, while a destination the victim cannot afford to stop reaching survives being noticed.
go deeper
Be ready to say why an outbound path has to already exist before code can use it, and why 443 to a well-known destination is the cheapest such path in a corporate network.
Explain what the proxy mediates on that path, and why a compiled-in address on a custom port never leaves a fully proxied estate rather than merely being noticed.
Show the block economics: judge which destinations your organisation could realistically stop reaching, and argue why address blocking only prices out the cheap end of the market.
Own the tradeoff between an allow-listed egress posture and the business friction it creates, and be able to state exactly what residual channel each exception accepts.
### The choice, and when it is made A command channel is the path from code on a victim host back to whoever is operating it. The choice of *carrier* - which protocol, which port, which destination - is made when the implant is built, before it has ever spoken to its operator. Everything else about the intrusion is negotiable later; this is not, because a foothold that cannot reach out is worth nothing. ### Why arbitrary egress is a dead end Consider an estate with no direct outbound path at all: every web request must traverse an authenticating forward proxy, and the internal resolver is the only thing permitted to talk to the outside world. Code that opens a socket to `203.0.113.10:4444` in that estate does not get filtered - it gets *nowhere*. There is no default route for it, no device configured to relay it, and no fallback. The operator loses the host silently. This is why carrier choice is a design constraint rather than a stealth preference. The implant has to use a path the estate maintains for its own reasons: HTTP through the proxy, or name resolution through the resolver. Those are the two doors, and both are held open by the business, not by the attacker. ### What a permitted destination actually buys Three things, and they are different from each other: 1. **A route.** Port 443 to a name in a category the proxy allows is relayed because relaying it is the proxy's job. Nothing has to be opened, disabled, or reconfigured on the victim's side. 2. **Company.** The same destination is being reached all day by real users and real software updaters. The implant's requests are not the only ones going there, which raises the cost of separating them from everything else. 3. **Block resistance.** This is the part candidates usually miss. A destination is only useful for as long as the victim tolerates it. A throwaway address costs nothing to abandon *and* nothing to block. A destination the organisation is contractually or operationally obliged to reach cannot be closed without breaking the business, so blocking it is a decision with a price attached. ### The economics behind the two ends of the market The contrast is sharp. Commodity crimeware compiles in an address or a cheap throwaway name. It is disposable by design: the operator expects to lose implants and compensates with volume. Against a fully proxied estate it often never connects once. A well-resourced operator pays for the other side of that trade. They acquire presence on infrastructure the victim already permits - shared hosting, a large provider, a service the organisation is obliged to reach - and accept the constraints that come with it: shared tenancy, provider policy, the risk of the account being pulled, ongoing cost and re-registration. What they buy is a channel that survives being identified, because the counter-move costs the victim something. This is what *well-resourced* predicts in practice. Not exotic code - infrastructure the defender cannot cheaply take away. ### The control class that bites Blocking an address is a tax on the cheap end of the market. It works against the compiled-in destination and does nothing against the operator who can buy another permitted-looking one. The control class that removes what this technique depends on is the one that removes *arbitrary permitted egress*: default-deny outbound with an allow-listed set of destinations, so that landing on something inside the list stops being free. That posture has a real business cost, which is exactly why most estates do not have it and why the technique keeps working. ### What the choice does not buy A permitted destination does not make the request unmediated. It still goes through the proxy, it still names a destination, and it still has to be authenticated on the way out in an estate that demands it. The operator gains permission, not invisibility - and confusing those two is the most common error in reasoning about this.
- What does the operator give up by using a large shared hosting destination instead of their own address?Control and predictability. The destination is shared with real customers, can be reassigned or pulled by the provider without warning, and has to be paid for or re-registered. They also inherit the provider's own limits on request size, rate and content. What they buy for that is a path the victim already permits and cannot cheaply close.
- Which control class actually takes away what this choice depends on?One that removes arbitrary permitted egress, not one that blocks an address. Under default-deny outbound with an allow-listed destination set, choosing a permitted carrier stops being free - the operator has to land on something already inside the list. Blocking single addresses only prices out the commodity end of the market, because a resourced operator buys another permitted-looking destination.
A courier who can only leave through the staffed front door does not cut a hole in the wall - they walk out carrying the same kind of parcel everyone else is carrying.
saying these in an interview costs you the question
- Says the implant just opens a socket to any address it likes
- Thinks HTTPS hides the destination from the proxy
- Assumes an unusual port is stealthier than 443
- Treats blocking one address as removing the channel