AN1745: Analytic 1745
On Android, the user can use the device settings menu to view trusted CA certificates and look for unexpected or unknown certificates. A mobile security product could similarly examine the trusted CA certificate store for anomalies. Users can use the device settings menu to view which applications on the device are allowed to install unknown applications.
On iOS, the user can use the device settings menu to view installed Configuration Profiles and look for unexpected or unknown profiles. A Mobile Device Management (MDM) system could use the iOS MDM APIs to examine the list of installed Configuration Profiles for anomalies.
Analyst context for executives and security teams
AN1745 is a mobile detection analytic focused on checking whether a device trusts unexpected certificate authorities or has settings/profiles that could weaken app and network trust. For leaders, the value is governance and assurance: if users, mobile security tooling, or MDM cannot verify trusted CA stores, unknown-app installation permissions, or configuration profiles, the organization may miss device trust changes that affect secure access and audit confidence.
Executive priority
Prioritize this analytic where Android devices are used for business access, especially in BYOD or lightly managed mobile environments. The business question is whether security teams can prove that mobile devices accessing corporate resources have expected certificate trust settings and controlled application installation permissions. Because ATT&CK provides no tactic mapping, relationships, or detection logic here, treat this as a control-validation and compliance-evidence analytic rather than a standalone alerting strategy.
Technical view
For Android, validate whether users, mobile security products, or management tooling can inspect the trusted CA certificate store for unexpected or unknown certificates and identify applications allowed to install unknown applications. The official description also references iOS configuration profile review through device settings or MDM APIs, but this object’s platform field is Android, so iOS coverage should be tracked separately unless your ATT&CK mapping explicitly includes it. SOC and IR teams should define what ‘expected’ certificates and app-install permissions look like for managed devices, then compare observed state against that baseline.
Likely telemetry
- Android trusted CA certificate store inventory or inspection results
- Android settings state showing which applications are allowed to install unknown applications
- Mobile security product findings related to certificate-store anomalies
- MDM or mobile management inventory where available
- User- or support-reported screenshots/settings observations when automated telemetry is unavailable
Detection direction
- Confirm that the organization has a known-good baseline for trusted CA certificates on managed Android devices.
- Alert or review when unfamiliar, unexpected, or policy-violating CA certificates appear in the trusted store.
- Review which Android applications are permitted to install unknown applications and compare against policy-approved exceptions.
- Tune for legitimate enterprise certificates, regional carrier/OEM differences, and approved administrative tooling to reduce false positives.
- Because no official detection logic is provided, document local detection criteria, data sources, thresholds, and triage steps before treating this as SOC-ready.
Mitigation priorities
- Establish and maintain mobile device configuration baselines for trusted certificates and unknown-app installation permissions.
- Use mobile security or MDM capabilities, where available, to inventory and periodically review certificate stores and relevant device settings.
- Limit unknown-app installation permissions to approved use cases and require documented business justification.
- Create user guidance for checking trusted certificates or profiles when automated management is not available.
- Include this evidence in mobile compliance readiness activities, especially for devices that access corporate email, identity systems, cloud apps, or sensitive data.
Analyst notes and limits
This is best interpreted as a mobile posture and anomaly-review analytic rather than a complete behavioral detection. Its strength is helping defenders validate whether device trust settings are observable and governed. The object has no relationship context and no tactic mapping, so local policy, MDM scope, and mobile asset inventory will determine practical value.
ATT&CK did not provide official detection logic, tactics, aliases, labels, or relationships for this object. The platform field lists Android, while the official description also discusses iOS configuration profiles; iOS statements should therefore be treated as source-description context, not as a platform assertion for this analytic. No active exploitation, attribution, impact, or guaranteed detection coverage is implied.
Analytic 1745
On Android, the user can use the device settings menu to view trusted CA certificates and look for unexpected or unknown certificates. A mobile security product could similarly examine the trusted CA certificate store for anomalies. Users can use the device settings menu to view which applications on the device are allowed to install unknown applications.
On iOS, the user can use the device settings menu to view installed Configuration Profiles and look for unexpected or unknown profiles. A Mobile Device Management (MDM) system could use the iOS MDM APIs to examine the list of installed Configuration Profiles for anomalies.
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 | 73078545193f… |
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 AN1745Open 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.