AN1500: Analytic 1500
Encrypted sessions detected with asymmetric key exchange anomalies on non-standard ports or with invalid/malformed certs. Defender correlates NetFlow/IPFIX with IDS/IPS detecting RSA exchanges outside expected TLS flows.
Analyst context for executives and security teams
This analytic is about spotting encrypted network sessions that do not look like normal TLS: asymmetric key exchange activity on unexpected ports or sessions using invalid or malformed certificates. For leaders, the value is not that encryption is bad; it is that unusual encrypted traffic can hide command-and-control, tunneling, or policy bypass from routine inspection. The business question is whether network security teams can distinguish approved encrypted services from suspicious encrypted sessions on network devices.
Executive priority
Prioritize this where network devices are a key control point for segmentation, internet egress, remote access, or regulated data paths. It supports resilience and audit readiness by testing whether NetFlow/IPFIX and IDS/IPS evidence can be correlated to explain anomalous encrypted traffic, especially when ports and certificates do not match expected TLS behavior. Budget and control discussions should focus on visibility quality, certificate inspection/metadata collection, and SOC workflows for encrypted traffic triage rather than assuming encryption makes traffic unobservable.
Technical view
ATT&CK provides this as a detection analytic for Network Devices. The supplied description points to correlation between NetFlow/IPFIX and IDS/IPS detections of RSA exchanges outside expected TLS flows, especially on non-standard ports or with invalid/malformed certificates. SOC and detection engineering teams should validate that network telemetry captures session metadata, port/protocol context, certificate-related indicators where available, and IDS/IPS alerts in a way that can be joined by time, source, destination, and flow identifiers. Because no tactic or official detection logic is supplied, local baselining is required to define what counts as expected TLS behavior in the environment.
Likely telemetry
- NetFlow/IPFIX records from network devices
- IDS/IPS alerts related to asymmetric key exchange or RSA exchange behavior
- Network session metadata including source, destination, port, protocol, timestamps, and byte counts
- TLS or certificate metadata where collected, including certificate validity or malformed certificate indicators
- Approved service inventories or baselines for expected encrypted traffic and standard ports
Detection direction
- Validate that NetFlow/IPFIX and IDS/IPS data can be correlated across the same network path and time window.
- Baseline approved TLS and other encrypted services by port, destination, and business owner before treating non-standard ports as suspicious.
- Tune for sessions where asymmetric key exchange behavior appears outside expected TLS flows, especially when paired with invalid or malformed certificate indicators.
- Review false positives from internally managed services, test environments, legacy appliances, scanners, and custom applications that may use non-standard ports or unusual certificates.
- Document blind spots where encrypted traffic bypasses monitored network devices, where certificate metadata is not collected, or where IDS/IPS visibility is limited.
Mitigation priorities
- Maintain an inventory of approved encrypted services, ports, and expected certificate practices.
- Improve network visibility first: ensure NetFlow/IPFIX, IDS/IPS, and certificate/session metadata are retained and searchable for SOC investigations.
- Enforce network egress and segmentation policies so unusual encrypted sessions are easier to identify and investigate.
- Strengthen certificate hygiene for internal and external services to reduce noise from invalid or malformed certificates.
- Create incident response playbooks for anomalous encrypted sessions that include ownership lookup, destination reputation/context review, and containment decision points.
Analyst notes and limits
This object is a detection analytic, not a full ATT&CK technique entry. The strongest supported use case is defensive validation of network monitoring for anomalous encrypted sessions on Network Devices. There are no supplied relationships, tactics, aliases, or official detection implementation details, so the take emphasizes telemetry readiness and correlation rather than a specific adversary behavior chain.
ATT&CK did not provide official detection logic, related techniques, tactics, procedures, or relationship context for this object. Conclusions about risk, prioritization, and tuning require local evidence such as approved service baselines, network architecture, certificate practices, and available IDS/IPS and flow telemetry.
Analytic 1500
Encrypted sessions detected with asymmetric key exchange anomalies on non-standard ports or with invalid/malformed certs. Defender correlates NetFlow/IPFIX with IDS/IPS detecting RSA exchanges outside expected TLS flows.
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 | 57acdc578dcd… |
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 AN1500Open 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.