AN1679: Analytic 1679
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
AN1679 is a mobile detection analytic focused on checking whether a device trusts unexpected certificate authorities or has configuration/profile settings that could weaken control of application installation or network trust. For leaders, the practical issue is assurance: if mobile devices can be made to trust unknown certificates or profiles, normal security assumptions about encrypted traffic, device configuration, and approved software sources may no longer hold.
Executive priority
Treat this as a mobile security and compliance validation item rather than a standalone alert. Security leaders should ask whether managed Android devices are routinely checked for unexpected trusted CA certificates and permissions to install unknown applications. Where iOS is in scope, the official description also points to reviewing installed Configuration Profiles via user settings or MDM APIs, but the supplied platform field for this object is Android, so iOS applicability should be confirmed against local ATT&CK mapping and device management scope.
Technical view
For SOC, mobile security, and IR teams, validate whether device posture tooling, MDM, or a mobile security product can enumerate trusted CA certificate stores and identify certificates that are unexpected for the organization. On Android, also validate visibility into applications allowed to install unknown applications. The object does not provide a formal detection statement, tactics, or relationship context, so teams should define local baselines, approved certificate authorities, and approved app-installation policy before operationalizing this analytic.
Likely telemetry
- Android trusted CA certificate store contents
- Android device settings or MDM/mobile security posture data
- List of applications permitted to install unknown applications on Android
- Mobile security product findings related to certificate-store anomalies
- Where separately in scope, iOS installed Configuration Profile inventory from device settings or MDM APIs
Detection direction
- Build an approved baseline of trusted CA certificates for managed mobile devices and alert on unknown or unexpected additions.
- Review which Android applications are allowed to install unknown applications and compare against policy-approved exceptions.
- Tune findings to account for legitimate enterprise certificates, regional carrier/OEM differences, and sanctioned testing or development devices.
- Use MDM or mobile security inventory to separate managed-device policy drift from user-owned or unmanaged-device visibility gaps.
- Because no official detection logic is supplied, require local validation before treating anomalies as high-confidence incidents.
Mitigation priorities
- Maintain an inventory of approved mobile trust anchors, configuration profiles, and app-installation policy exceptions.
- Use mobile device management or equivalent controls to enforce certificate, profile, and unknown-app-installation policies where supported.
- Define response procedures for unexpected certificates, unknown application installation permissions, or unexpected profiles, including user verification and device remediation.
- Document mobile posture checks as compliance evidence for managed-device control assurance.
Analyst notes and limits
This analytic is most useful as a control validation and posture-monitoring check. Its value depends on whether the organization can distinguish sanctioned enterprise certificates and profiles from unexpected ones, and whether Android unknown-app-installation permissions are centrally visible.
The supplied ATT&CK object has no tactic, no official detection text, and no relationship context. The platform field lists Android, although the official description also discusses iOS Configuration Profiles and MDM APIs. Any iOS use should be treated as description-derived context and validated separately against local scope.
Analytic 1679
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 | 8bd9f6cd956e… |
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 AN1679Open 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.