AN0564: Analytic 0564
Suspicious outbound HTTPS connections where the TLS Server Name Indication (SNI) does not match the HTTP Host header, indicating potential use of domain fronting to mask C2 traffic via CDNs.
Analyst context for executives and security teams
This analytic matters because it focuses on a common visibility gap in encrypted outbound traffic: whether the TLS Server Name Indication and the HTTP Host header agree. A mismatch can indicate domain fronting, where traffic appears to be going to an expected CDN-facing domain while the application request is directed elsewhere. For leaders, the decision value is not that this analytic proves command-and-control activity, but that it tests whether the organization can inspect and correlate the right network metadata to spot suspicious outbound HTTPS behavior on Windows systems.
Executive priority
Prioritize this as a validation item for SOC and incident response readiness where Windows endpoints are allowed broad outbound HTTPS access through CDNs or cloud-hosted services. The key business question is whether security teams have enough network and endpoint telemetry to distinguish normal CDN/application behavior from suspicious SNI-to-Host mismatches, and whether exceptions are documented for audit and response decisions.
Technical view
For Windows environments, validate whether monitoring can correlate TLS SNI values with HTTP Host headers for outbound HTTPS sessions. Because the ATT&CK object provides no official detection logic, tactics, or relationships, teams should treat AN0564 as a detection design requirement rather than a complete rule. SOC teams should test visibility across proxy, firewall, secure web gateway, network sensor, and endpoint/network telemetry sources, then tune against known legitimate CDN and application patterns before alerting at high severity.
Likely telemetry
- TLS metadata, especially Server Name Indication values
- HTTP request metadata, especially Host headers where available
- Outbound HTTPS connection records from Windows systems
- Proxy, firewall, secure web gateway, or network sensor logs that can correlate TLS and HTTP fields
- Destination domain, IP, CDN, and connection timing metadata for triage context
Detection direction
- Validate that SNI and HTTP Host header values can be captured and compared for the same outbound HTTPS session.
- Tune carefully for legitimate CDN, proxy, and application behaviors that may create benign mismatches.
- Use the analytic as suspicious context rather than proof of command-and-control, since the supplied ATT&CK fields only state potential masking of C2 traffic.
- Confirm coverage gaps where encrypted traffic, privacy controls, or logging architecture prevent HTTP Host visibility.
- Document approved mismatching patterns so SOC triage can focus on unknown or unexpected destinations.
Mitigation priorities
- Establish or improve outbound HTTPS logging through approved network control points before relying on this analytic.
- Define acceptable CDN and cloud service usage patterns for Windows systems and maintain allowlisted exceptions where justified.
- Limit unmanaged direct outbound access where business operations allow, so suspicious egress patterns are more observable and enforceable.
- Ensure incident response playbooks include review of SNI, Host header, destination domain, and endpoint context when this behavior is observed.
- Use findings to support compliance evidence around egress monitoring, logging completeness, and exception management.
Analyst notes and limits
AN0564 is a detection analytic for Windows in the enterprise ATT&CK domain. The supplied description identifies suspicious outbound HTTPS connections where TLS SNI does not match the HTTP Host header, indicating possible domain fronting to mask C2 traffic via CDNs. No ATT&CK relationship context, tactics, aliases, labels, or official detection implementation were supplied.
This take is limited to the official STIX fields and external reference provided. It does not establish active exploitation, attribution, confirmed maliciousness, or guaranteed detectability. Local network architecture, TLS inspection policy, proxy design, logging depth, and legitimate application behavior are required to determine practical coverage and alert fidelity.
Analytic 0564
Suspicious outbound HTTPS connections where the TLS Server Name Indication (SNI) does not match the HTTP Host header, indicating potential use of domain fronting to mask C2 traffic via CDNs.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 56ca2b801d0a… |
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 AN0564Open 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.