The short version: Cisco Technology, Inc. was granted US12671698B2 on June 30, 2026, for a method that detects domain fronting — a technique that hides the true destination of an encrypted session behind a benign-looking domain — by first learning the set of IP addresses a domain normally resolves to and then flagging sessions that reach an address that is atypical for that domain and is known to support fronting. It is an issued grant, classified under CPC H04L 63/1416 (network monitoring for detecting attacks or intrusions).

Domain fronting exploits a gap between what a network sees and where traffic actually goes. Large services are commonly hosted across multiple content delivery networks (CDNs) for resiliency and latency, which means many unrelated domains can share the same front-end infrastructure and the same pool of IP addresses. In a fronted connection, the outer, visible layer — the DNS lookup and the TLS handshake’s server name — names an innocuous domain, while the inner HTTP request, encrypted and invisible to a passive observer, addresses a different host on that shared infrastructure. Because the payload is inside TLS, a monitoring device cannot simply read the true target. The technique has legitimate uses in censorship circumvention, but it is also used by malware to disguise command-and-control traffic as ordinary requests to a trusted CDN.

How the disclosed method works

The grant approaches the problem through network location context rather than payload inspection. The abstract states the core insight directly:

This disclosure describes techniques and mechanisms for detecting and alerting on domain fronting within a network using network location context. Popular services are often hosted by multiple CDNs to increase resiliency and decrease latency. The techniques described herein utilize this insight to identify anomalous encrypted sessions by first creating a baseline of domain name resolutions for a given customer site. The techniques may then look for encrypted sessions destined to an IP address that is anomalous for the given domain name and is known to support domain fronting.— Detecting and alerting on domain fronting within a network, US12671698B2

Independent claim 1 turns that insight into a sequence of steps. A system first collects Domain Name System (DNS) response data from devices within a network for a domain that is hosted across a plurality of network sites, and uses that data to generate a baseline of the IP addresses and hosting providers that normally serve the domain. Dependent claim 18 describes building that baseline as a histogram of IP addresses, their associated autonomous systems, and DNS fields — a statistical profile of where a name is supposed to land. The method then receives network data for traffic destined to the domain and identifies connections whose destination IP address is atypical relative to the baseline. For each such connection it performs a DNS query to a DNS server the endpoint previously used, to obtain the expected IP addresses; when the observed destination is not among them, the connection is correlated with domain fronting and an alert is generated.

Several dependent claims describe how the alert is qualified and acted on. Claim 5 uses intelligence feeds to assign a severity level to the alert. Claim 6 conditions the alert on signals including whether the connection reaches a hosting provider different from the one normally associated with the domain, whether that provider is known to support fronting, and connection metadata such as round-trip time and time-to-live. Claim 7 goes further than detection: it describes determining that a connection is to a hosting provider that supports domain fronting and then blocking that connection. The independent claims are cast in the standard three forms — a method, a system, and a non-transitory computer-readable medium — so the same detection pipeline reads onto software, an appliance, and stored instructions.

Where it sits in the field

The method is notable for what it does not require: it does not decrypt the session, and it does not depend on reading the inner HTTP Host header. Instead it treats an unexpected resolution — an encrypted session going to an address the domain has never been seen to use — as the observable signal, and confirms it against a fresh DNS lookup. That places the technique in the encrypted-traffic-analytics tradition, where the goal is to reason about sessions from their metadata and network context when the contents are opaque. The named inventors, David Arthur McGrew and Blake Harrell Anderson, are associated with that line of Cisco research. The classification, H04L 63/1416, is the intrusion- and attack-detection subclass, alongside H04L 63/1425 for anomaly-based detection that also appears on the record.

The grant is one entry in a cluster of security-related patents Cisco received in the same June 30 issue. US12671643B2 is directed to evaluating anomaly-detection mechanisms by correlating the outputs of multiple detectors over time, and US12670434B2 describes converting hierarchical JSON into fixed-length feature vectors to train multiple-instance-learning models for cybersecurity. US12671677B2 covers bidirectional data obfuscation within unsecured runtime environments, and the data-center traffic-analytics grant US12670003B2 synchronizes sensor telemetry across nodes for flow analysis. Read together, the group sits squarely in network-visibility and detection tooling.

The practical takeaway for defenders: domain fronting has been a persistent blind spot precisely because the malicious signal is encrypted, and this method offers a metadata-and-baseline route to surfacing it — building a per-site expectation of where a domain resolves, then treating a session to an out-of-profile CDN address as something to alert on, score for severity, and optionally block. What a granted patent documents is an approach and its claimed scope; whether a given deployment sees fronting in practice depends on the baseline quality and the traffic it is watching. The record describes the mechanism; it does not, by itself, describe a shipping configuration.