Domain Fronting: The Hidden Risk in Trusted Traffic

Executive TL;DR 

• Major cloud platforms have made traditional domain fronting harder. However, attackers still want to hide malicious traffic inside infrastructure that organisations already trust.
• Newer variants use domain borrowing, weak CDN domain validation, HTTP/2 connection reuse, encrypted DNS, and Encrypted Client Hello. Each technique reduces what network defenders can see.
• A reputable domain, a valid certificate, or a connection through a major cloud provider tells you very little about whether the activity behind it is legitimate.
• Attackers pair network evasion with valid accounts, stolen sessions, and legitimate admin tools. Much of the activity looks trustworthy because it operates through legitimate systems.
• Most traditional controls score domains, IP addresses, certificates, and initial connections separately from one another. That’s exactly the seam attackers work in.
• Most organisations cannot block entire cloud platforms or privacy protocols without disrupting legitimate operations. Instead, they need to correlate endpoint, identity, DNS, network, and behavioural telemetry.
• Red team operations test whether evasive command-and-control traffic can move through trusted cloud and web infrastructure. They also reveal whether existing controls can detect and contain it.

Why Domain Fronting Exploits Trusted Network Traffic

Most enterprise security programmes apply some notion of reputation to outbound traffic. A connection to an unfamiliar server gets extra scrutiny. A connection to a recognised cloud platform, CDN, software vendor, or collaboration tool usually does not. 

That’s a reasonable trade-off in principle — modern businesses run on shared infrastructure, and blocking a major cloud platform because one tenant misuses it would break far more than it fixes. Attackers know this too, and they build around it. 

Domain fronting earned its name by hiding the real destination of an HTTPS connection behind a different, permitted one. The big providers have since restricted classic domain fronting. But academic testing keeps finding CDNs where some form of it still works. A peer-reviewed study at the 2024 ACM Web Conference tested 30 providers and found 22 — including major names like Akamai and Fastly — still permitted a version of domain fronting under the configurations evaluated.

The takeaway is not that every CDN is exploitable — it is narrower and more uncomfortable than that. The assumption underneath domain fronting is still very much alive: 

Infrastructure reputation is not the same thing as behavioural legitimacy. 

For an executive audience, that reframes the problem. It is less about one network technique and more about whether the organisation can tell legitimate cloud activity apart from an adversary using the exact same infrastructure, encryption, and protocols. 

Traditional Domain Fronting Became Harder — Not Irrelevant 

Classic domain fronting works by putting different destination names at different layers of an HTTPS connection. The Server Name Indication in the TLS handshake points to something permitted. Once the encrypted session is up, the HTTP request quietly names a different destination hosted on the same shared infrastructure. A control that only sees the outer connection sees something trustworthy. 

MITRE ATT&CK catalogues this as Domain Fronting, sub-technique T1090.004 — adversaries concealing command-and-control traffic through CDNs and other shared services.

The major providers pushed back. Amazon CloudFront now checks the relationship between the SNI, HTTP Host header, certificate, distribution, and AWS account, and can reject requests that fail with an HTTP 421. Microsoft did something similar across Azure Front Door and its CDN services, enforcing against requests where the TLS and HTTP destinations do not align with the permitted routing configuration.

Between them, these changes closed off basic mismatch-based fronting on the biggest platforms. But they did not remove the attacker’s underlying requirement for a covert channel — they just forced the technique to move. 

How Domain Borrowing Extends Modern Domain Fronting

Traditional domain-fronting detection often boils down to one question: does the SNI match the HTTP Host header? Domain borrowing exists specifically to make that question stop mattering. 

Rather than presenting one domain at the TLS layer and a different one inside the HTTP request, domain borrowing can keep the SNI, Host header, and presented certificate all consistent with each other. The connection looks internally coherent even while an attacker abuses the domain or CDN routing relationship behind it.

Research presented at Black Hat Asia walked through how an operator could connect directly to CDN edge infrastructure, skip normal DNS resolution, and use a “borrowed” hostname consistently across both the TLS and HTTP layers. The same research showed how wildcard certificates and loose custom-domain validation could make the traffic look cryptographically clean. 

That shifts the defensive problem. A gateway can no longer lean on catching an obvious contradiction between the visible hostname and the encrypted request underneath it. It also has to work out whether: 

• the endpoint normally talks to that service at all;
• the hostname resolved through an authorised DNS path;
• the destination IP lines up with recent DNS activity;
• the process making the connection is one you’d expect to see;
• the traffic volume, timing, and request pattern match normal application behaviour;
• the certificate and CDN routing relationship are genuinely legitimate. 

None of that shows up as a contradiction. The connection can be technically valid while the behaviour behind it is anything but. 

How Weak Domain Verification Enables Network Evasion

CDNs need to let customers associate their own domains with shared infrastructure, and how carefully a provider confirms that a customer actually controls that domain determines how safe the whole arrangement is. Weak or inconsistent verification can let an unauthorised party claim, route, or otherwise abuse a hostname that appears to belong to a completely different, reputable organisation. 

A large-scale 2024 study built a tool called DVAHunter to test domain-verification practices across 45 CDN providers. Examining around 89 million subdomains, the researchers flagged more than 332,000 as potentially exposed to domain abuse, and tied these weaknesses to covert communication, domain borrowing, domain fronting, and outright domain hijacking.

That does not mean attackers actively compromised every flagged domain. It means the trust chain running from domain ownership through CDN routing to certificate presentation has systemic weak points, and those weak points are common enough to matter. 

For business leadership, this splits into two distinct risks. 

The first is that your own infrastructure gets used against you. Dangling DNS records, abandoned cloud resources, stale CDN configurations, and poorly governed certificates can quietly turn company-owned names into attacker infrastructure. 

The second is subtler: trusted third-party infrastructure can camouflage someone else’s attack entirely. A security control may hand out confidence based on a domain, certificate, or provider reputation without ever asking who actually controls the route behind it. 

Domain and certificate governance, in other words, aren’t just website-maintenance chores. They’re part of enterprise attack-surface management, whether the team responsible thinks of them that way or not. 

How HTTP/2 and HTTP/3 Enable Modern Evasion Techniques

Modern web protocols are built for efficiency. HTTP/2 lets multiple requests travel concurrently over one connection, and under the right conditions a client can reuse an existing connection for more than one origin — as long as the server is authoritative for those origins and its certificate covers the requested host. 

The HTTP/2 specification itself flags the risk: connection reuse can send requests to an unintended origin in deployments where a middlebox picks the backend server based on the initial TLS SNI. Its advice to servers is blunt — reject misdirected requests rather than assuming an established connection is enough proof of authorisation on its own.

None of this is malicious by design. Connection reuse is a normal performance feature, and most of the time it behaves exactly as intended. The exposure shows up when a security device, reverse proxy, or application gateway treats the first request on a connection as a trust decision that covers everything that follows. 

An attacker working this angle typically: 

1. establishes a permitted connection through a trusted hostname;
2. keeps that connection open;
3. sends later requests carrying a different authority or destination;
4. relies on a proxy or backend that never re-checks each request independently. 

Put simply: a trusted connection does not make every request inside it trustworthy. Security controls built on the assumption of one TLS handshake per destination can lose the plot once connections are multiplexed, coalesced, and reused across origins. 

How Encrypted Client Hello Reduces Network Visibility

Encrypted Client Hello is, at its core, a privacy improvement to TLS. HTTPS has always encrypted the contents of a session, but historically left part of the initial handshake — including the Server Name Indication naming the requested hostname — visible in the clear. Network security products used that visibility to categorise destinations, apply filtering rules, and decide what needed a closer look. 

Encrypted Client Hello encrypts the sensitive parts of the ClientHello under the server’s public key. RFC 9849 now defines the mechanism. From a privacy standpoint, that’s a genuine win — it makes it much harder for a network observer to work out which specific service a user is reaching behind shared infrastructure. 

From an enterprise-security standpoint, though, it also removes a source of visibility defenders have relied on for years.

ECHidna Turns the Visibility Gap Into a Real Threat

That trade-off stopped being theoretical with ECHidna, a remote-access trojan found during targeted activity against Japanese organisations. Research presented at Virus Bulletin’s VB2025 conference found the malware using Encrypted Client Hello for its command-and-control traffic — hiding the actual destination inside the encrypted ClientHello while presenting ordinary shared cloud infrastructure to anyone watching from outside. Vendors are already responding: Cisco’s Secure Firewall documentation describes a detection signature, released in October 2025, that flags connections to known ECH-capable CDN providers — giving defenders visibility into where ECH traffic is going, even if not what’s inside it.

That case matters because it moves this out of the “protocol theory” bucket. Privacy-preserving infrastructure can also hand adversaries concealed destination information, less useful hostname-based filtering, thinner passive telemetry, a ride on large trusted providers, and a harder time for defenders trying to separate malicious sessions from ordinary encrypted browsing. 

None of that makes Encrypted Client Hello malicious — treating it that way would mistake a protocol feature for attacker behaviour. What it does mean is that detection strategies need to keep working once destination metadata stops being available. 

Domain Fronting Is Only One Part of the Attack Chain

Network camouflage matters because of what it makes possible afterwards. An attacker with a quiet command-and-control channel can use it to harvest credentials, move laterally, plant persistence, or operate trusted admin systems undisturbed. The evasion technique gets the attention, but the real business risk sits in what it is hiding. 

How Domain Fronting Connects to Identity and Persistence

That chain overlaps with several risks we have already written about: 

• When Your Own Tools Become a Devastating Security Threat looks at adversaries operating through legitimate admin tools and native system capabilities — an evasive network channel is much harder to spot when the endpoint activity looks like ordinary administration too.
• Modern Credential Theft: Why Identity Is the New Attack Surface covers how valid credentials and trusted auth paths let attackers inherit legitimacy instead of having to keep bypassing controls.
• Token Theft and the Hidden Persistence Problem shows how stolen sessions let attackers keep operating even after a password reset.
• Shadow Admins in Active Directory: The Hidden Privilege Problem looks at the indirect permissions and delegated paths that can turn an ordinary-looking account into an administrative foothold.
• Active Directory Exploitation: The Hidden Risks of ADCS explains how valid certificates and identity infrastructure can quietly deliver privilege escalation and durable authentication.
• How to Validate Attacker Persistence Is Removed covers the risk of clearing the visible indicators while leaving alternative access or command channels intact.

Why Network Evasion Must Be Treated as One Attack Chain

These are not six separate problems — they’re stages of the same operational story: attackers gain or inherit trusted access, legitimate tools keep the endpoint activity looking unremarkable, hidden privilege paths widen their control, cloud and CDN infrastructure hides the communications, persistence survives a narrow clean-up effort, and leadership ends up with an incomplete picture of whether the attacker was actually evicted. 

Judged on its own, network evasion looks like a niche technical problem. Judged as part of that chain, it is considerably more dangerous. 

Short, anonymised example from a red team engagement where outbound controls looked restrictive on paper, but an approved cloud service, CDN, proxy, or common web protocol still gave the team an effective way out. 

Cover: what the organisation believed the control restricted; what was actually permitted; what telemetry did or didn’t catch it; and what business objective the team could have reached from there. 

Avoid naming the customer, the exact payload, or anything that would reproduce as usable infrastructure. 

Why Traditional Controls Miss Modern Domain Fronting Techniques

A lot of network-security architecture still leans on four types of evidence: destination address, domain reputation, visible SNI, and certificate validity. Each is still useful. None is enough on its own. 

Reputation is not authorisation. A well-known cloud platform hosts thousands or millions of unrelated customers, and its reputation can’t vouch for every tenant, workload, route, or request running through it. 

Encryption narrows the view. As more handshake and application metadata gets encrypted, passive network devices simply see less. Controls increasingly have to correlate network activity with endpoint processes, identity sessions, DNS requests, application behaviour, and what the asset is actually for. 

Certificates confirm identity, not intent. A valid certificate tells you a connection was set up with infrastructure authorised for a given hostname. It says nothing about whether the process behind it is benign or whether the application-layer behaviour is what you’d expect. 

Mismatch detection only covers the oldest variant. Comparing SNI against the HTTP Host header is still worth doing — MITRE lists it as a detection opportunity — but domain borrowing and encrypted-handshake techniques are a reminder that a matching value is not proof of anything.

Blocking whole clouds creates its own risk. Blocking entire CDNs, public cloud address ranges, or encrypted protocols outright is just as likely to break legitimate services as it is to meaningfully slow down a capable attacker. That’s the asymmetry organisations are up against: the attacker only needs one permitted path through, while the business has to keep thousands of legitimate ones open. 

How to Detect Domain Fronting and Encrypted Network Evasion

Losing cleartext network metadata does not make detection impossible — it just changes which signals actually matter. Modern detection needs to correlate across several dimensions at once. 

Endpoint Context 

Which process opened the connection? Was it expected to talk externally at all? Did an unusual parent process launch it? Is it using a normal system or application networking library, and does the execution chain match what this user or device is actually for? 

DNS and name resolution

Did the endpoint resolve the hostname before connecting? Through an authorised resolver? Is the endpoint using a public DNS-over-HTTPS service outside policy? Does the destination IP actually match the DNS response that was observed, and are HTTPS or service-binding records showing up unexpectedly? 

Identity and session activity

Did the connection follow a suspicious sign-in or token event? Is the account operating from an unfamiliar device, or has it recently picked up new permissions? Is the session one that survived a credential rotation it shouldn’t have? 

Network behaviour. 

Is the traffic periodic or machine-like? Are the connections unusually long-lived? Do request sizes and intervals resemble beaconing? Is a rarely used CDN suddenly talking to privileged systems, or is the endpoint reusing connections across origins it shouldn’t be touching? 

Fingerprinting and protocol telemetry

JA4 and the wider JA4+ family give a way to characterise TLS clients, TCP behaviour, HTTP requests, and related attributes — useful for telling an expected browser or business application apart from an implant trying to imitate one. Treat this as one signal among many rather than a verdict; a determined operator can alter or mimic protocol fingerprints. Its value comes from being combined with process, identity, destination, timing, and asset context, not from standing alone. 

Domain-fronting-specific detection models.

Detection research is advancing too — a 2025 IEEE study, FakeApp, demonstrated a high-precision method for spotting domain fronting in live network traffic by combining protocol signals rather than relying on any single indicator. It is a reminder that the detection side of this problem is moving roughly as fast as the evasion side.

What Red Team Operations Should Validate 

Proving that an operator can open an encrypted outbound connection is not, by itself, worth much. The real question is whether the organisation can detect, investigate, and contain a realistic chain of activity that runs through infrastructure and protocols it already trusts. 

Egress assumptions

Can an endpoint reach out through CDNs, cloud platforms, reverse proxies, or encrypted DNS services that the security team assumes are already well controlled? 

Cross-layer correlation

Can the SOC actually connect an unusual network session back to the process, identity, DNS event, and privilege activity that produced it? 

Protocol-aware inspection

Do gateways and proxies validate each request on its own merits, or do they extend trust to an entire connection once the first request clears? 

Cloud and domain governance

Are abandoned records, stale CDN configurations, untracked certificates, and unmanaged external services creating attack surface that attackers could claim or abuse?

Detection without visible hostnames

Can analysts still investigate when the final destination is encrypted, shared, unavailable, or represented only by “a major cloud provider”? 

Containment and eviction

If an evasive channel turns up, can the organisation pull the endpoint foothold, kill the associated sessions, close off compromised identity paths, and confirm no alternative channel is still open? 

Any of these tells you more than checking whether a firewall has a signature labelled “domain fronting.” 

Executive Actions 

For CISOs and technology leadership, the priority is not buying another isolated detection feature — it is finding out whether the controls already in place still work once the usual destination context disappears.

Reduce Unnecessary Outbound Trust

• Define which outbound services are actually required. Work out which cloud services, CDNs, public resolvers, remote-access platforms, and software distribution services each business unit genuinely needs. “Allow all major cloud providers” is not an egress strategy. 
• Enforce authorised DNS paths. Endpoints should use approved enterprise DNS unless there’s a documented reason not to. Security teams should detect and govern unauthorised DNS-over-HTTPS or DNS-over-TLS use rather than quietly tolerate it.NS-over-TLS use should be visible and governed, not quietly tolerated.

Strengthen Domain and Gateway Governance

• Review domain and certificate ownership. Inventory external domains, subdomains, certificates, CDN configurations, cloud endpoints, and DNS records. Clear out dangling records and flag anything without a clear owner.
• Test proxy and gateway request validation. Confirm controls check each hostname, authority, and request individually rather than trusting an entire multiplexed connection off the back of its first transaction.

Correlate Detection and Validate the Full Attack Chain

• Correlate network and endpoint telemetry. A connection to trusted infrastructure should get more interesting, not less, when it is launched by an unexpected process, service account, admin server, or privileged workstation.
• Update incident-response assumptions. Response plans need to account for command channels riding shared cloud infrastructure, encrypted DNS, session theft, and persistence that does not rely on malware. Blocking one domain or resetting one password won’t necessarily remove the attacker.
• Validate the whole chain. Red team and adversary-simulation exercises should test whether the organisation can spot the combination — evasive communications, trusted-tool abuse, identity compromise, privilege escalation, persistence — rather than whether one network indicator gets blocked. 

Operational Takeaways 

• Major providers have constrained classic domain fronting, but they have not eliminated it. The underlying evasion model is still very much viable.
• Domain borrowing removes the mismatch a lot of older detections were built around.
• Weak domain verification can turn reputable hostnames and shared cloud infrastructure into attacker resources.
• HTTP/2 and HTTP/3 push controls to validate individual requests, not just the connection they arrived on.
• Encrypted Client Hello improves privacy and, in the same move, reduces the value of hostname-based inspection.
• Domain reputation, valid certificates, and major cloud providers are context — not proof of anything.
• Detection increasingly depends on correlating identity, endpoint, DNS, process, and network behaviour together.
• Offensive validation is one of the few ways to know whether the security programme can recognise attacker behaviour when everything about the connection looks technically fine. 

The Real Question for Leadership 

Domain fronting is not primarily a firewall problem. It is a trust problem. 

Enterprises run more and more of their operations through shared cloud platforms, encrypted protocols, CDNs, remote services, and trusted digital identities. All of that is necessary for the business to function — and all of it also hands adversaries scalable infrastructure and operational cover. 

So the right question for leadership is not “does our firewall block domain fronting?” It is closer to: can we still identify malicious activity when the connection, certificate, domain, account, and tooling all appear completely legitimate? 

Configuration reviews alone won’t answer that. Red team operations and adversary simulation are how organisations find out whether their egress controls, identity monitoring, endpoint telemetry, security operations, and incident-response process actually work together under realistic attacker conditions — because the most dangerous communication channel in your environment may not look malicious at all. It may just look like the rest of the business. 

FAQ 

What is domain fronting? 

Domain fronting is an evasion technique that hides the real destination of HTTPS traffic behind a different, permitted domain, typically using shared infrastructure like a CDN. 

Is domain fronting still possible? 

The classic SNI-versus-Host-header mismatch has been restricted by several major providers, but academic research keeps finding providers and configurations where it still works. Related techniques achieve the same goal through different mechanisms. 

What is domain borrowing? 

Domain borrowing keeps the visible SNI, HTTP Host header, and presented certificate all consistent with each other, which weakens controls that only detect fronting through a hostname mismatch. 

Is Encrypted Client Hello malicious? 

No — it is a TLS privacy feature that protects destination information during the handshake. The concern is that malware and command-and-control infrastructure can use that same privacy to cut down on network visibility. 

Can organisations simply block Encrypted Client Hello? 

They can govern or restrict it in managed environments, but blocking it outright carries privacy, compatibility, and operational costs. What’s appropriate depends on the organisation’s architecture, risk profile, and ability to lean on other telemetry. 

Can valid certificates be trusted? 

They confirm certain things about server identity and encrypted transport. They don’t confirm that the application, user, process, request, or behaviour behind the connection is legitimate. 

How can security teams detect modern domain-fronting variants? 

By correlating DNS, TLS, HTTP, endpoint process, identity, connection pattern, certificate, and asset context together. Single indicators like domain reputation or hostname alignment increasingly aren’t enough on their own. 

How does red teaming help? 

It tests whether attackers can actually establish evasive communications, operate through trusted services, and reach business-critical objectives without being caught — and whether the security team can correlate what they’re seeing across endpoint, identity, network, and cloud controls. 

---

wizlynx group is a CREST-accredited offensive security company headquartered in Switzerland, operating across Europe, North America, Latin America, and Asia. wizlynx group specializes in penetration testing, red teaming, adversary simulation, social engineering, and advanced security assessments for enterprise clients.