AN1725: Analytic 1725
The defender correlates application TLS trust customization activity with subsequent outbound encrypted sessions that bypass enterprise interception visibility or fail only under enterprise inspection conditions. The analytic looks for an app establishing its own certificate or public-key trust logic, then initiating HTTPS sessions to destinations not aligned with approved app behavior, especially from background state or without recent user interaction. Higher-confidence observations come from Android runtime/framework telemetry showing custom trust manager, certificate validation override, or pin validation logic immediately preceding network connection attempts, combined with network evidence of failed-inspection patterns or opaque direct TLS sessions.
Analyst context for executives and security teams
This analytic matters because some Android apps can create their own TLS trust logic, which may reduce the enterprise’s ability to inspect or validate encrypted traffic. For leaders, the practical issue is not simply “encrypted traffic exists”; it is whether mobile applications can communicate in ways that bypass approved inspection paths, behave differently under enterprise inspection, or send opaque HTTPS traffic inconsistent with expected app behavior.
Executive priority
Prioritize this where Android devices or managed mobile apps are part of business operations and where encrypted mobile traffic visibility is an audit, data protection, or incident response requirement. Security leaders should ask whether mobile monitoring can connect application behavior to network behavior, whether approved app communication baselines exist, and whether inspection failures are treated as actionable risk rather than routine noise.
Technical view
For SOC, detection engineering, and IR teams, the key validation point is correlation: Android runtime or framework evidence of custom trust manager behavior, certificate validation override, or pin validation logic should be linked in time to outbound HTTPS sessions. Higher-value triage comes when those sessions are to destinations not aligned with approved app behavior, occur from background state, occur without recent user interaction, or show failed-inspection or opaque direct TLS patterns. No ATT&CK detection logic or relationships were supplied, so teams must define local baselines and thresholds.
Likely telemetry
- Android runtime or framework telemetry showing custom trust manager activity
- Evidence of certificate validation override or certificate/public-key pin validation logic
- Application state context, including background execution and recent user interaction
- Outbound HTTPS connection metadata from Android devices
- Network evidence of enterprise TLS inspection failure patterns
Detection direction
- Validate that mobile telemetry can attribute TLS trust customization to a specific Android application before the network connection occurs.
- Tune detections around correlation rather than single events, because custom certificate or pinning behavior may be legitimate in some applications.
- Compare destinations against approved app behavior to reduce false positives and highlight unexpected communication paths.
- Review whether background-state HTTPS sessions without recent user interaction are observable and triaged differently from user-driven activity.
- Check for blind spots where enterprise TLS inspection cannot see direct encrypted sessions or where failed inspection is logged only at the network layer without app context.
Mitigation priorities
- Establish and maintain approved communication baselines for managed Android applications.
- Ensure mobile, endpoint, and network telemetry can be correlated for app identity, runtime trust behavior, connection timing, and destination.
- Define handling procedures for enterprise inspection failures, including when they require SOC triage or incident response escalation.
- Review mobile application security and governance requirements for certificate validation, trust customization, and approved network behavior.
- Use compliance and audit evidence to demonstrate that encrypted mobile traffic visibility gaps are known, risk-assessed, and monitored where feasible.
Analyst notes and limits
This is a mobile ATT&CK detection analytic for Android, not a technique description. Its decision value is in validating whether defenders can connect application-level TLS trust customization with subsequent encrypted network behavior and inspection gaps.
The supplied ATT&CK object provides no tactic, no official detection procedure, and no relationship context. This take does not infer exploitation, attribution, impact, or coverage. Local app inventories, MDM/mobile telemetry, network logs, and enterprise inspection architecture are required to determine relevance and implement detection safely.
Analytic 1725
The defender correlates application TLS trust customization activity with subsequent outbound encrypted sessions that bypass enterprise interception visibility or fail only under enterprise inspection conditions. The analytic looks for an app establishing its own certificate or public-key trust logic, then initiating HTTPS sessions to destinations not aligned with approved app behavior, especially from background state or without recent user interaction. Higher-confidence observations come from Android runtime/framework telemetry showing custom trust manager, certificate validation override, or pin validation logic immediately preceding network connection attempts, combined with network evidence of failed-inspection patterns or opaque direct TLS 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.1 | Current bundle | 04a5c4e79d4b… |
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 AN1725Open 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.