T1664: Exploitation for Initial Access
Adversaries may exploit software vulnerabilities to gain initial access to a mobile device.
This can be accomplished in a variety of ways. Vulnerabilities may be present in the applications, the services, the underlying operating system, or the kernel itself. Several well-known mobile device exploits exist, including FORCEDENTRY, StageFright, and BlueBorne. Furthermore, some exploits may be possible to exploit without any user interaction (i.e. zero-click exploits, see Exploitation for Client Execution), making them particularly dangerous. Mobile operating system vendors are typically very quick to patch such critical bugs, ensuring only a small window where they can be exploited.
Analyst context for executives and security teams
Exploitation for Initial Access on mobile devices is a business risk because a vulnerable Android or iOS device can become the entry point without the user necessarily making a mistake. The ATT&CK description highlights app, service, operating system, and kernel vulnerabilities, including zero-click-style risk, so the practical question is whether the organization can rapidly identify, update, restrict, or retire exposed mobile devices.
Executive priority
Treat this as a mobile resilience and access-governance issue, not only a malware issue. Leaders should ask whether enterprise access is conditional on current mobile security updates, whether unsupported devices are decommissioned, and whether high-risk mobile users have Mobile Threat Defense or equivalent monitoring. The strongest supported control priority is timely security updates and limiting access from devices that are behind patch expectations.
Technical view
For SOC, IR, and detection engineering teams, validate coverage across Android and iOS fleets even though ATT&CK provides no official detection text for this technique. Use the DET0666 relationship as a prompt to define a local detection strategy for suspected mobile exploitation, and test whether MDM/UEM, mobile security tooling, and incident response workflows can correlate vulnerable device state with suspicious mobile alerts. Relationship context shows this behavior is used by Pegasus for iOS and BRATA on Android, so threat intelligence and detection content should be reviewed for both iOS and Android visibility without assuming those tools guarantee coverage.
Likely telemetry
- Mobile device inventory, including Android/iOS platform, OS version, and security patch level
- MDM/UEM compliance state and enterprise access decisions for out-of-date devices
- Application inventory and version data for managed mobile apps
- Mobile Threat Defense or mobile antimalware alerts where deployed
- Records showing security update status, update failures, and unsupported or decommissioned devices
Detection direction
- Because official ATT&CK detection guidance is not provided, start by validating whether the organization can reliably identify devices exposed by missing security updates.
- Tune mobile alert review around the combination of vulnerable device state, high-risk user context, and mobile security product findings rather than relying on a single indicator.
- Check for blind spots in unmanaged BYOD, devices outside MDM/UEM control, unsupported Android/iOS versions, and devices that cannot report patch level consistently.
- Use the related software context, Pegasus for iOS and BRATA for Android, to guide threat intelligence review and platform-specific monitoring priorities, while avoiding assumptions of active targeting.
Mitigation priorities
- Prioritize M1001 Security Updates: require prompt installation of mobile security updates and track patch-level compliance.
- Purchase and retain devices with vendor or carrier commitments to timely security updates, and decommission devices that no longer receive them.
- Limit or block access to enterprise resources from devices that have not installed recent security updates; Android security patch level is explicitly supported in the mitigation context.
- Use M1058 Antivirus/Antimalware where appropriate, including Mobile Threat Defense capabilities, as an additional device-based mitigation layer rather than a replacement for patching.
- Document update and access-control evidence for audit, compliance readiness, and incident decision-making.
Analyst notes and limits
This technique is material because mobile exploitation may occur through applications, services, the OS, or the kernel, and some exploit paths may require no user interaction. The supplied relationships identify security updates and mobile antimalware/MTD as mitigations, and note use by Pegasus for iOS and BRATA on Android. Local control validation should focus on whether mobile patch posture actually affects enterprise access.
ATT&CK does not provide an official detection section or tactics for this object in the supplied data. Telemetry and detection recommendations therefore remain implementation-oriented and must be validated against the organization’s managed mobile estate, MDM/UEM coverage, mobile security tooling, and BYOD policy.
Exploitation for Initial Access
Adversaries may exploit software vulnerabilities to gain initial access to a mobile device.
This can be accomplished in a variety of ways. Vulnerabilities may be present in the applications, the services, the underlying operating system, or the kernel itself. Several well-known mobile device exploits exist, including FORCEDENTRY, StageFright, and BlueBorne. Furthermore, some exploits may be possible to exploit without any user interaction (i.e. zero-click exploits, see Exploitation for Client Execution), making them particularly dangerous. Mobile operating system vendors are typically very quick to patch such critical bugs, ensuring only a small window where they can be exploited.
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.
Groups, software, and campaigns
S0289: Pegasus for iOS
Pegasus for iOS is the iOS version of malware that has reportedly been linked to the NSO Group. It has been advertised and sold to target high-value victims.[1][2] The Android version is tracked separately under Pegasus for Android.
S1094: BRATA
BRATA (Brazilian Remote Access Tool, Android), is an evolving Android malware strain, detected in late 2018 and again in late 2021. Originating in Brazil, BRATA was later also found in the UK, Poland, Italy, Spain, and USA, where it is believed to have targeted financial institutions such as banks. There are currently three known variants of BRATA.[1][2][3]
All related ATT&CK context
Mitigation direction
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 | 52d26f7d136b… |
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 T1664Open 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.