M1020: SSL/TLS Inspection
SSL/TLS inspection involves decrypting encrypted network traffic to examine its content for signs of malicious activity. This capability is crucial for detecting threats that use encryption to evade detection, such as phishing, malware, or data exfiltration. After inspection, the traffic is re-encrypted and forwarded to its destination. This mitigation can be implemented through the following measures:
Deploy SSL/TLS Inspection Appliances:
- Implement SSL/TLS inspection solutions to decrypt and inspect encrypted traffic. - Ensure appliances are placed at critical network choke points for maximum coverage.
Configure Decryption Policies:
- Define rules to decrypt traffic for specific applications, ports, or domains. - Avoid decrypting sensitive or privacy-related traffic, such as financial or healthcare websites, to comply with regulations.
Integrate Threat Intelligence:
- Use threat intelligence feeds to correlate inspected traffic with known indicators of compromise (IOCs).
Integrate with Security Tools:
- Combine SSL/TLS inspection with SIEM and NDR tools to analyze decrypted traffic and generate alerts for suspicious activity. - Example Tools: Splunk, Darktrace
Implement Certificate Management:
- Use trusted internal or third-party certificates for traffic re-encryption after inspection. - Regularly update certificate authorities (CAs) to ensure secure re-encryption.
Monitor and Tune:
- Continuously monitor SSL/TLS inspection logs for anomalies and fine-tune policies to reduce false positives.
Analyst context for executives and security teams
SSL/TLS inspection is a control for reducing the visibility gap created by encrypted traffic. For leaders, the key issue is not simply decrypting traffic; it is deciding where inspection is justified, legally acceptable, operationally safe, and integrated well enough to help find command-and-control activity that hides behind proxies, domain fronting, or encrypted channels.
Executive priority
Prioritize this as a visibility and governance decision. Encrypted traffic can limit SOC and incident response evidence, especially for ATT&CK command-and-control behaviors related to Proxy, Domain Fronting, and Encrypted Channel. Executives should ask whether critical network choke points are covered, whether privacy and regulated traffic exclusions are documented, whether certificate management is sustainable, and whether inspection outputs are usable in SIEM or NDR workflows for audit and incident evidence.
Technical view
Validate that SSL/TLS inspection policies are deliberately scoped by application, port, or domain and placed at meaningful network choke points. The relationship context ties this mitigation to command-and-control techniques including T1090, T1090.004, T1573, and T1573.002, so SOC teams should focus on whether decrypted or metadata-enriched traffic can expose proxy use, domain-fronting inconsistencies, and encrypted C2 patterns. Because ATT&CK provides no official detection text for this mitigation, detection engineering should treat inspection as an enabling control rather than a detection by itself.
Likely telemetry
- SSL/TLS inspection appliance logs
- Decryption policy match and bypass logs
- Certificate authority and re-encryption events
- SIEM alerts generated from inspected traffic
- NDR observations from decrypted or enriched network traffic
Detection direction
- Confirm whether inspection logs are actually forwarded to SIEM and NDR tools rather than retained only on the inspection appliance.
- Tune around relationship-driven behaviors: proxy-mediated C2, HTTPS domain-fronting indicators such as mismatched TLS SNI and HTTP Host values where visible, and encrypted-channel traffic patterns.
- Track policy bypasses and excluded categories because privacy, financial, and healthcare exclusions can create expected blind spots.
- Validate that threat intelligence correlation is used conservatively and reviewed for false positives.
- Document that SSL/TLS inspection improves content visibility but does not guarantee detection of custom encryption, unsupported protocols, or traffic excluded by policy.
Mitigation priorities
- Start with governance: define which traffic may be decrypted and which sensitive or regulated categories must be excluded.
- Deploy inspection at critical network choke points where it can provide meaningful coverage without disrupting business traffic.
- Configure decryption rules by application, port, or domain and maintain documented exceptions.
- Integrate inspected traffic and logs with SIEM, NDR, and threat intelligence workflows.
- Maintain trusted certificate management for re-encryption, including regular CA updates.
Analyst notes and limits
This is a mitigation object, not a technique detection definition. Its strongest decision value is helping organizations close encrypted-traffic visibility gaps that can affect C2 investigation and response. The supplied relationships support relevance to Proxy, Domain Fronting, Encrypted Channel, and Asymmetric Cryptography command-and-control behaviors.
ATT&CK does not specify platforms, tactics, or official detection guidance for M1020 itself. Local network architecture, legal requirements, privacy policy, certificate infrastructure, SIEM/NDR integrations, and traffic exclusions are required to judge whether this control is appropriate or effective in a given environment.
SSL/TLS Inspection
SSL/TLS inspection involves decrypting encrypted network traffic to examine its content for signs of malicious activity. This capability is crucial for detecting threats that use encryption to evade detection, such as phishing, malware, or data exfiltration. After inspection, the traffic is re-encrypted and forwarded to its destination. This mitigation can be implemented through the following measures:
Deploy SSL/TLS Inspection Appliances:
- Implement SSL/TLS inspection solutions to decrypt and inspect encrypted traffic. - Ensure appliances are placed at critical network choke points for maximum coverage.
Configure Decryption Policies:
- Define rules to decrypt traffic for specific applications, ports, or domains. - Avoid decrypting sensitive or privacy-related traffic, such as financial or healthcare websites, to comply with regulations.
Integrate Threat Intelligence:
- Use threat intelligence feeds to correlate inspected traffic with known indicators of compromise (IOCs).
Integrate with Security Tools:
- Combine SSL/TLS inspection with SIEM and NDR tools to analyze decrypted traffic and generate alerts for suspicious activity. - Example Tools: Splunk, Darktrace
Implement Certificate Management:
- Use trusted internal or third-party certificates for traffic re-encryption after inspection. - Regularly update certificate authorities (CAs) to ensure secure re-encryption.
Monitor and Tune:
- Continuously monitor SSL/TLS inspection logs for anomalies and fine-tune policies to reduce false positives.
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 | If it is possible to inspect HTTPS traffic, the captures can be analyzed for connections that appear to be domain fronting. |
| Enterprise | T1573.002 | Asymmetric Cryptography Sub-technique | SSL/TLS inspection can be used to see the contents of encrypted sessions to look for network-based indicators of malware communication protocols. |
| Enterprise | T1573 | Encrypted Channel | SSL/TLS inspection can be used to see the contents of encrypted sessions to look for network-based indicators of malware communication protocols. |
| Enterprise | T1090 | 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.1 | Current bundle | 31b4b00c4184… |
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 M1020Open 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.