DET0667: Detection of Asymmetric Cryptography
DET0667 is a mobile ATT&CK detection strategy for identifying behavior related to asymmetric cryptography used to conceal command-and-control traffic. Its...
Analyst context for executives and security teams
DET0667 is a mobile ATT&CK detection strategy for identifying behavior related to asymmetric cryptography used to conceal command-and-control traffic. Its business value is not that encryption is inherently malicious, but that unmanaged or unexpected cryptographic use in mobile apps can reduce visibility into adversary communications and complicate incident response.
Executive priority
Security leaders should treat this as a visibility and assurance question: can the organization recognize when Android or iOS mobile activity uses asymmetric cryptography in ways that may hide command-and-control traffic? This matters for mobile threat monitoring, incident triage, compliance evidence around security logging, and prioritizing controls where mobile devices or apps support sensitive business operations.
Technical view
The supplied ATT&CK object has no official detection text, tactics, or platform field, but it detects mobile technique T1521.002, Asymmetric Cryptography, whose related platforms are Android and iOS. SOC and detection teams should validate whether mobile telemetry, network monitoring, app analysis, or endpoint/mobile security tooling can surface suspicious use of public-key cryptography in application traffic or code paths. Detection logic should avoid treating all asymmetric cryptography as malicious; the key task is distinguishing expected protocol or application behavior from anomalous cryptographic use associated with concealed C2.
Likely telemetry
- Mobile network traffic metadata and destination patterns
- Mobile application behavior or runtime telemetry where available
- Mobile device security or MDM/MAM logs, if collected
- Application package/static analysis indicators related to cryptographic library use
- TLS/protocol metadata where visibility is permitted and lawful
Detection direction
- Inventory what mobile telemetry is actually collected for Android and iOS environments before assuming DET0667 coverage.
- Tune for unexpected or unusual asymmetric cryptography use in mobile apps rather than encryption alone, since legitimate apps commonly use public-key cryptography.
- Correlate cryptographic indicators with network destinations, app reputation, device context, and other suspicious mobile behaviors.
- Document blind spots where privacy controls, BYOD limitations, encrypted traffic, or lack of mobile endpoint telemetry prevent useful detection.
- Use this detection strategy as supporting context for T1521.002 rather than as a standalone alerting specification, because no official detection logic is provided.
Mitigation priorities
- Prioritize mobile asset and application visibility so defenders know which Android and iOS devices and apps are in scope.
- Establish approved mobile app and network-use baselines to make anomalous cryptographic behavior easier to assess.
- Ensure incident response procedures include collection and analysis options for relevant Android and iOS artifacts.
- Where appropriate, strengthen mobile security monitoring and app vetting controls without attempting to block legitimate asymmetric cryptography broadly.
- Maintain audit-ready evidence of mobile monitoring coverage, known gaps, and compensating controls.
Analyst notes and limits
This take is based on the detection strategy object DET0667 and its relationship to T1521.002, Asymmetric Cryptography, in the mobile ATT&CK domain. The strongest practical use is as a coverage-validation prompt for mobile C2 visibility, not as a complete detection rule.
The official object provides no description, no detection text, no tactics, and no platform list. Android and iOS are inferred only from the related ATT&CK technique. Local telemetry, mobile management model, privacy constraints, and application inventory are required to determine feasible detection coverage.
Detection of Asymmetric Cryptography
No official description is available in the imported ATT&CK source object.
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 |
|---|---|---|---|
| Mobile | T1521.002 | Asymmetric Cryptography Sub-technique | This object detects Asymmetric Cryptography. |
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.0 | Current bundle | 5f4cd350f5ff… |
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 DET0667Open 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.