Use intrusion detection signatures to block traffic at network boundaries.
MITRE mitigation sourceAdversaryGraph public intelligence page
This page is part of Threat Matrix, the public browser workspace for the main AdversaryGraph platform. Use it for ATT&CK pivots, actor and technique context, similarity leads, detection coverage review, and analyst-ready investigation paths.
Validation disclaimer: TTP overlap, actor similarity, generated summaries, and coverage findings are investigation leads, not attribution proof or operational validation without analyst review.
Main AdversaryGraph project Documentation Malware Analysis GitHub
Asymmetric Cryptography
Adversaries may employ a known asymmetric encryption algorithm to conceal command and control traffic rather than relying on any inherent protections provided by a communication protocol. Asymmetric cryptography, also known as public key cryptography, uses a keypair per party: one public that can be freely distributed, and one private. Due to how the keys are generated, the sender encrypts data with the receiver’s public key and the receiver decrypts the data with their private key. This ensures that only the intended recipient can read the encrypted data. Common public key encryption algorithms include RSA and ElGamal. For efficiency, many protocols (including SSL/TLS) use symmetric cryptography once a connection is established, but use asymmetric cryptography to establish or transmit a key. As such, these protocols are classified as Asymmetric Cryptography.
Open detection, hunting, mitigation, and evidence workspace
Detection logic
SSL/TLS inspection is one way of detecting command and control traffic within some encrypted communication channels. SSL/TLS inspection does come with certain risks that should be considered before implementing to avoid potential security issues such as incomplete certificate validation. In general, analyze network data for uncommon data flows (e.g., a client sending significantly more data than it receives from a server). Processes utilizing the network that do not normally have network communication or have never been seen before are suspicious. Analyze packet contents to detect communications that do not follow the expected protocol behavior for the port that is being used.
Observed actors
Correlated CTI and IR reports
1200km CTI repository · explicit report mentionCTI Research: Sandworm / APT44
1200km CTI repository · explicit report mentionCTI Research: Sandworm / APT44
1200km CTI repository · explicit report mentionATT CK as a Working Tool Theory and Hands On Practical Usage
1200km Medium · authored report mentionCTI Research Sandworm APT44
1200km Medium · authored report mention
Cyber Knowledge context
Use these routes to move from the ATT&CK behavior into explanation, implementation, evidence handling, validation, and defensive operations. Relevance is generated from explicit identifiers/names and governed topic mappings; it is not attribution evidence.
Cyber Threat Intelligence (CTI) · Tactic learning route · 24/100Disassembly, decompilation, and code-led analysis
Malware Analysis & Reverse Engineering · Tactic learning route · 24/100Module 5 — Threat hunting
Blue Team & Defensive Security · Tactic learning route · 24/100
MITRE mitigations
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 inte…
MITRE mitigation sourceMITRE detection strategies and analytics
- 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.
- 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.
- AN1498 · Analytic 1498 — Applications or launchd services invoking RSA or public-key routines from the Security framework, followed by outbound SSL/TLS sessions with unrecognized certs or anomalous handshakes. Defender observes unified logs of API calls and suspicious network entropy.
- AN1499 · Analytic 1499 — VMware services (hostd, vpxa) unexpectedly negotiating asymmetric crypto sessions to external endpoints outside vCenter or update servers. Defender sees encrypted handshakes in logs inconsistent with baseline ESXi communication patterns.
- 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.