AN1497: Analytic 1497
Processes (e.g., bash, python, custom binaries) dynamically linking libcrypto/libssl for RSA key exchange, then creating external connections with abnormal certificate validation or handshake anomalies. Defender observes syscall traces and outbound asymmetric key exchanges from non-SSL-native processes.
Analyst context for executives and security teams
This analytic matters because it points to Linux processes that are not normally SSL/TLS clients but dynamically load libcrypto/libssl, perform RSA key exchange, and then make external connections with certificate-validation or handshake anomalies. For leaders, the value is not “detecting encryption” by itself; it is validating whether the organization can see suspicious encrypted outbound behavior from scripts, shells, or custom binaries that may otherwise blend into normal network traffic.
Executive priority
Prioritize this as a coverage validation item for Linux server and workload environments where outbound connectivity, custom automation, or unmanaged binaries can create blind spots. It supports decisions around SOC telemetry investment, incident response readiness for encrypted command-and-control-like behavior, and audit evidence that outbound encrypted sessions are monitored beyond standard web proxy logs. Because ATT&CK supplies no tactic, relationship, or detection logic for this analytic, it should be treated as a detection engineering lead rather than a complete control requirement.
Technical view
SOC and detection teams should validate whether Linux hosts generate usable evidence for: process identity, dynamic library loading of libcrypto/libssl, syscall traces, outbound network connections, and TLS/RSA handshake or certificate-validation anomalies. Focus on non-SSL-native processes named in the description examples, such as bash, python, or custom binaries, while accounting for legitimate automation, package managers, monitoring agents, and internal tools that may load crypto libraries or initiate encrypted sessions. Since no official detection query is provided, teams should build and test local logic against known-good Linux workloads before alerting at high severity.
Likely telemetry
- Linux process execution metadata
- Dynamic library load events for libcrypto and libssl
- Syscall traces showing network activity and cryptographic library usage
- Outbound network connection records from Linux hosts
- TLS handshake metadata, including asymmetric key exchange indicators where available
Detection direction
- Validate that endpoint telemetry can associate a Linux process with loaded libcrypto/libssl libraries and subsequent outbound connections.
- Tune for non-SSL-native or unexpected processes rather than all crypto-library usage, because many legitimate Linux applications use libcrypto/libssl.
- Correlate host evidence with network TLS metadata or certificate anomaly data to reduce false positives.
- Review blind spots where containers, ephemeral workloads, custom binaries, or limited EDR/syscall collection prevent process-to-network attribution.
- Establish baselines for administrative scripts, Python tooling, monitoring agents, and internal automation before operationalizing alerts.
Mitigation priorities
- Ensure Linux endpoint logging or EDR coverage captures process execution, library loading, and network connection context for critical servers and workloads.
- Constrain unnecessary outbound connectivity from Linux systems through network egress controls and approved destinations where operationally feasible.
- Maintain certificate and TLS inspection or metadata collection policies consistent with privacy, legal, and operational requirements.
- Review allowed use of custom binaries and scripts on production Linux systems, especially those with internet access.
- Use incident response playbooks that include triage of suspicious encrypted outbound sessions by process, user, binary path, destination, and certificate/handshake characteristics.
Analyst notes and limits
The supplied object is a detection analytic for Linux only. It describes suspicious behavior involving dynamic linking of libcrypto/libssl, RSA key exchange, outbound external connections, and abnormal certificate validation or handshake anomalies. No tactics, technique relationships, aliases, labels, or official detection query are supplied, so this take emphasizes coverage validation and local analytic design rather than definitive ATT&CK mapping.
This assessment uses only the supplied STIX fields, external reference, and relationship context. There are no relationships, no official detection logic, and no stated ATT&CK tactics. Local environment baselines are required to determine whether specific processes, libraries, destinations, or TLS anomalies are suspicious.
Analytic 1497
Processes (e.g., bash, python, custom binaries) dynamically linking libcrypto/libssl for RSA key exchange, then creating external connections with abnormal certificate validation or handshake anomalies. Defender observes syscall traces and outbound asymmetric key exchanges from non-SSL-native processes.
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 | eab68944af8c… |
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 AN1497Open 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.