DET0196: Domain Fronting Behavior via Mismatched TLS SNI and HTTP Host Headers
This detection strategy is about finding possible domain fronting: HTTPS traffic where the TLS SNI value and the HTTP Host header point to different domain...
Analyst context for executives and security teams
This detection strategy is about finding possible domain fronting: HTTPS traffic where the TLS SNI value and the HTTP Host header point to different domains. For leaders, the practical issue is that this behavior can make command-and-control traffic appear to be going to a trusted CDN or shared hosting service, complicating egress control, SOC triage, and incident scoping.
Executive priority
Prioritize this as an egress visibility and incident-readiness question: can the organization prove when outbound HTTPS traffic is using mismatched destination indicators, and can analysts distinguish legitimate CDN behavior from suspicious command-and-control patterns? The business value is stronger resilience against covert external communications and better evidence for security operations, compliance reviews, and response decisions.
Technical view
DET0196 detects ATT&CK technique T1090.004 Domain Fronting, associated with command-and-control across Linux, macOS, Windows, and ESXi environments. SOC and detection engineering teams should validate whether network monitoring can correlate TLS SNI with HTTP Host headers for outbound HTTPS sessions, especially where traffic traverses CDNs or other multi-tenant services. Because the DET0196 object does not provide official detection logic, local baselining and exception handling are essential.
Likely telemetry
- Outbound TLS metadata, including SNI
- HTTP Host header data where visible
- Proxy, secure web gateway, or network sensor logs that can correlate TLS and HTTP fields
- DNS resolution context for observed domains
- Egress destination metadata for CDN or shared hosting services
Detection direction
- Look for mismatches between TLS SNI and HTTP Host values in the same connection or session.
- Prioritize review of mismatches involving CDN or multi-tenant hosting infrastructure, consistent with the related Domain Fronting technique description.
- Baseline legitimate business applications that may produce unusual CDN-related patterns to reduce false positives.
- Confirm whether encrypted traffic inspection, proxy placement, or sensor visibility is sufficient to observe both fields; if not, document the blind spot.
- Correlate with other command-and-control indicators rather than treating a header mismatch alone as proof of malicious activity.
Mitigation priorities
- Establish authoritative outbound web monitoring points for internet-bound HTTPS traffic.
- Review egress policies for unmanaged direct-to-internet traffic that bypasses proxy or logging controls.
- Maintain allowlists or policy controls for approved CDN-backed services where operationally feasible.
- Ensure SOC playbooks include triage steps for SNI/Host mismatches and escalation criteria for possible command-and-control.
- Use incident response readiness exercises to confirm analysts can retrieve relevant proxy, TLS, DNS, and network evidence.
Analyst notes and limits
The ATT&CK object supplied is a detection strategy with no official description or detection text, so the take relies on the relationship to T1090.004 Domain Fronting and its provided description. Treat this as a validation prompt for visibility and analytics rather than a complete detection specification.
Platforms and tactic are inferred only from the related T1090.004 technique, not from DET0196 itself. The supplied data does not identify specific tools, adversaries, active exploitation, detection logic, or guaranteed telemetry availability. Local network architecture determines whether SNI and Host header comparison is possible.
Domain Fronting Behavior via Mismatched TLS SNI and HTTP Host Headers
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1090.004 | Domain Fronting Sub-technique | This object detects Domain Fronting. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | c92bad183954… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0196Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.