AN1496: Analytic 1496
Processes not typically associated with encryption loading asymmetric crypto libraries (e.g., rsaenh.dll, crypt32.dll) and subsequently initiating outbound TLS/SSL connections with abnormal certificate chains or handshakes. Defender correlates process creation, module load, and unusual encrypted sessions.
Analyst context for executives and security teams
This analytic matters because it focuses on an unusual combination: a Windows process that normally should not handle encryption loads asymmetric crypto libraries such as rsaenh.dll or crypt32.dll, then starts outbound TLS/SSL traffic with abnormal certificate or handshake characteristics. For leaders, the value is in validating whether the organization can connect endpoint behavior to encrypted network behavior quickly enough to support triage and incident decisions.
Executive priority
Prioritize this as a coverage validation item for SOC and incident response readiness on Windows estates. The business question is not whether encryption is bad, but whether defenders can distinguish expected encrypted business traffic from unexpected processes creating suspicious encrypted sessions. This supports resilience, audit evidence for monitoring coverage, and faster decisions when outbound encrypted communications appear abnormal.
Technical view
SOC and detection teams should validate correlation across three evidence points named in the analytic: process creation, module load, and unusual outbound TLS/SSL sessions. Because no ATT&CK tactic or relationship context is supplied, treat this as a behavior-focused detection analytic rather than a complete attack narrative. Tune around known Windows processes, browsers, update agents, security tools, and business applications that legitimately load cryptographic libraries and initiate TLS connections.
Likely telemetry
- Windows process creation events
- Windows module or DLL load telemetry for rsaenh.dll, crypt32.dll, and similar asymmetric crypto libraries
- Outbound network connection metadata from Windows hosts
- TLS/SSL handshake metadata
- Certificate chain details and certificate validation anomalies
Detection direction
- Validate that endpoint telemetry can show which process loaded the crypto library and when.
- Validate that network telemetry can expose abnormal TLS/SSL handshakes or certificate chains without requiring decrypted content.
- Correlate process creation, module load, and outbound TLS/SSL timing rather than alerting on any single event alone.
- Build allowlists or baselines for processes normally associated with encryption to reduce false positives.
- Investigate gaps where endpoint tools do not capture module loads or where network monitoring lacks TLS certificate and handshake metadata.
Mitigation priorities
- First, ensure Windows endpoint logging and network telemetry are retained and can be joined by host, process, and time.
- Next, define expected encrypted-traffic behavior for common business applications, browsers, update mechanisms, and security tools.
- Then, review egress monitoring and certificate validation practices so abnormal TLS/SSL sessions can be surfaced for triage.
- Finally, use incident response playbooks to guide review of unexpected processes that load cryptographic libraries and initiate suspicious outbound encrypted connections.
Analyst notes and limits
This object is a MITRE ATT&CK detection analytic for Windows. It provides a concise behavior description but no official detection implementation, no tactics, and no relationship context. The strongest operational use is as a validation prompt for endpoint-network correlation and TLS metadata coverage.
The supplied fields do not identify a specific technique, adversary, campaign, impact, or active exploitation. Coverage and severity depend on local Windows telemetry quality, TLS/SSL visibility, baseline maturity, and the ability to distinguish legitimate encrypted application behavior from abnormal sessions.
Analytic 1496
Processes not typically associated with encryption loading asymmetric crypto libraries (e.g., rsaenh.dll, crypt32.dll) and subsequently initiating outbound TLS/SSL connections with abnormal certificate chains or handshakes. Defender correlates process creation, module load, and unusual encrypted sessions.
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 | 0259b53f000d… |
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 AN1496Open 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.