AN1762: Analytic 1762
An application generates, imports, or accesses asymmetric keypairs (e.g., RSA/ECC), uses a public key to encrypt outbound data or establish encrypted sessions, and transmits resulting ciphertext in structured communication patterns. Detection correlates keypair lifecycle activity + asymmetric crypto API usage + data transformation + background execution context + network transmission, especially when inconsistent with expected application functionality.
Analyst context for executives and security teams
This analytic matters because it focuses on Android apps that create or use asymmetric keys, encrypt outbound data, and transmit ciphertext in patterns that may not match the app’s expected purpose. For leaders, the value is not simply “crypto is present”; many legitimate apps use RSA, ECC, and encrypted sessions. The business question is whether mobile security, SOC, and incident response teams can distinguish normal application encryption from suspicious background data protection and transmission behavior.
Executive priority
Prioritize this as a mobile security and incident readiness validation item. It can support decisions about Android application risk, mobile telemetry coverage, and whether security teams have enough evidence to investigate suspicious encrypted outbound activity. Because the ATT&CK object provides no specific tactic, relationship context, or official detection logic, it should be treated as a coverage and assurance analytic rather than proof of malicious activity.
Technical view
For Android environments, validate whether monitoring can correlate five evidence areas: asymmetric keypair generation/import/access, asymmetric cryptographic API use, data transformation into ciphertext, background execution context, and network transmission. The key detection challenge is context: legitimate apps commonly use public-key cryptography, so SOC teams should compare observed crypto and network behavior against expected application functionality, user activity, app category, and approved enterprise use.
Likely telemetry
- Android application inventory and package metadata
- Mobile device management or mobile threat defense application activity records
- Android cryptographic API usage indicators where available
- Keypair lifecycle events such as generation, import, or access where observable
- Process or application background execution context
Detection direction
- Do not alert on asymmetric cryptography alone; tune around correlation between key lifecycle activity, crypto API usage, data transformation, background execution, and outbound transmission.
- Validate whether encrypted outbound communication is consistent with the app’s declared and expected business function.
- Use application allowlists, enterprise-approved app catalogs, and known app behavior baselines to reduce false positives.
- Investigate background execution combined with repeated structured ciphertext transmission, especially where user interaction or business justification is absent.
- Document telemetry gaps, because Android may not expose all cryptographic API or key lifecycle details depending on device management, OS controls, and collection architecture.
Mitigation priorities
- Establish an approved Android application inventory and remove or restrict apps that are not required for business use.
- Use mobile device management or equivalent controls to enforce application governance and visibility on Android devices.
- Baseline expected network behavior for high-risk or business-critical mobile applications.
- Ensure incident response playbooks include steps for triaging suspicious Android app encryption and outbound transmission behavior.
- Retain mobile network and application telemetry long enough to support investigation and compliance evidence needs.
Analyst notes and limits
The supplied object is a detection analytic, not an ATT&CK technique. No tactics, relationships, aliases, labels, or official detection implementation are provided. The analytic’s value is in correlating Android app cryptographic behavior with network transmission and expected functionality. Local baselines are essential because asymmetric encryption is normal in many legitimate mobile applications.
This take is limited to the official STIX fields, external reference, and supplied relationship context. There is no official detection text, no relationship mapping to techniques or mitigations, and no evidence of active exploitation, attribution, impact, or guaranteed detectability. Applicability beyond Android is not supported by the supplied object.
Analytic 1762
An application generates, imports, or accesses asymmetric keypairs (e.g., RSA/ECC), uses a public key to encrypt outbound data or establish encrypted sessions, and transmits resulting ciphertext in structured communication patterns. Detection correlates keypair lifecycle activity + asymmetric crypto API usage + data transformation + background execution context + network transmission, especially when inconsistent with expected application functionality.
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.1 | Current bundle | 88135fd969db… |
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 AN1762Open 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.