IP masquerading¶

The frontend hides the C2 behind a normal-looking domain. The blue team’s first impression lands on a brochure site, not a beacon endpoint.

Domain selection¶

Buy two types of domain per operation:

• One for workstation reverse shells: a profile that fits the target’s expected outbound web traffic. Marketing, news, SaaS, software updates.

• One for server callbacks: something that fits server-to-server traffic. Telemetry endpoints, package mirrors, monitoring APIs.

Mixing the two on a single domain is loud. A workstation talking to an “update server” once a week is fine; a workstation talking to a “monitoring API” is suspicious.

Aging and reputation¶

• Avoid freshly registered domains. Many DNS-layer filters block any domain younger than seven to thirty days.

• Buy domains that are at least a few months old. Drop-catch services and aged-domain marketplaces sell these, but vet for prior abuse history.

• Check reputation against URLhaus, VirusTotal, Cisco Talos, and the major DNS filters before going live.

• Avoid TLDs with a poor reputation (.tk, .top, .xyz often get scored down even when clean).

Categorisation¶

Web filters route allow and deny decisions through category vendors (Cisco Talos, Palo Alto, Symantec, Bluecoat). A new domain sits in “uncategorised” by default, which many enterprises block outright. Submit the cover site to each vendor’s recategorisation portal once it is serving real-looking content.

One domain per operation¶

Burn the domain at the end of the engagement. Reusing names across operations links them under shared reputation lookups. Park the old DNS at a sinkhole or remove it entirely.

Cover content¶

The frontend serves plausible content on / and on any path the beacon does not claim. A static brochure site is enough. Keep it boring; do not link to anything on the open web from it.