M0920: SSL/TLS Inspection
Break and inspect SSL/TLS sessions to look at encrypted web traffic for adversary activity.
Analyst context for executives and security teams
SSL/TLS inspection is a defensive control for making encrypted web traffic visible enough to assess for adversary behavior. In the supplied ATT&CK context, its main decision value is around ICS environments where encrypted traffic or proxy-mediated communications can otherwise hide activity from network monitoring.
Executive priority
Treat this as a visibility and governance decision, not just a tooling feature. Leaders should ask where encrypted traffic crosses important trust boundaries, whether inspection is appropriate for operational technology constraints, and whether exceptions create blind spots around connection proxy behavior. The business value is improved incident decision-making and stronger evidence that network monitoring can see relevant traffic where policy and architecture allow.
Technical view
For SOC, detection engineering, and IR teams, validate whether SSL/TLS inspection is deployed at the network paths where proxy or intermediary communications would matter. Because ATT&CK provides no platform or detection text for this mitigation, local architecture is decisive: identify inspected versus uninspected flows, exception lists, certificate handling, and logging produced by inspection points. Use the relationship to T0884 Connection Proxy to focus validation on traffic moving through intermediaries, trusted network relationships, or regular cross-network communications.
Likely telemetry
- SSL/TLS inspection device logs and policy decisions
- Web proxy or secure gateway logs where present
- Network flow metadata for inspected and bypassed encrypted sessions
- Certificate, handshake, and decryption failure events where collected
- Allowlist, bypass, and exception records for encrypted traffic
Detection direction
- Confirm which encrypted sessions are actually inspected and which are bypassed due to policy, technical constraints, or operational exceptions.
- Tune monitoring around proxy-like or intermediary communication paths, especially where trusted networks regularly exchange traffic.
- Correlate inspection telemetry with network flow metadata so teams can see both content-aware findings and blind spots in encrypted traffic visibility.
- Review false-positive risk from legitimate proxies, gateways, and trusted partner communications before treating intermediary traffic as suspicious.
- Document gaps explicitly because the ATT&CK object supplies no official detection guidance or platform scope.
Mitigation priorities
- Prioritize inspection at high-value trust boundaries and network paths where encrypted traffic could obscure adversary activity.
- Define governance for decryption exceptions, including operational, privacy, and certificate-handling constraints.
- Maintain logs that show inspection outcomes, bypass decisions, and failures so SOC and IR teams can prove what was visible during an investigation.
- Validate that SSL/TLS inspection supports monitoring for Connection Proxy-related behavior without disrupting critical ICS communications.
- Periodically review inspected coverage against current network trust relationships and proxy architectures.
Analyst notes and limits
This is an ICS ATT&CK mitigation, not a technique. The only explicit mitigation relationship supplied is to T0884 Connection Proxy, so the take focuses on encrypted traffic visibility around proxy or intermediary communications. No vendor, platform, or active threat context is provided.
ATT&CK provides a short description and no official detection text, tactics, or platforms for this object. Local network architecture, inspection policy, exception handling, and operational constraints are required to determine practical coverage and risk.
SSL/TLS Inspection
Break and inspect SSL/TLS sessions to look at encrypted web traffic for adversary activity.
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 |
|---|---|---|---|
| ICS | T0884 | Connection Proxy | If it is possible to inspect HTTPS traffic, the captures can be analyzed for connections that appear to be 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 | 7e78dc9e90ce… |
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 M0920Open 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.