T1461: Lockscreen Bypass
An adversary with physical access to a mobile device may seek to bypass the device’s lockscreen. Several methods exist to accomplish this, including:
* Biometric spoofing: If biometric authentication is used, an adversary could attempt to spoof a mobile device’s biometric authentication mechanism. Both iOS and Android partly mitigate this attack by requiring the device’s passcode rather than biometrics to unlock the device after every device restart, and after a set or random amount of time.[1][2] * Unlock code bypass: An adversary could attempt to brute-force or otherwise guess the lockscreen passcode (typically a PIN or password), including physically observing (“shoulder surfing”) the device owner’s use of the lockscreen passcode. Mobile OS vendors partly mitigate this by implementing incremental backoff timers after a set number of failed unlock attempts, as well as a configurable full device wipe after several failed unlock attempts. * Vulnerability exploit: Techniques have been periodically demonstrated that exploit mobile devices to bypass the lockscreen. The vulnerabilities are generally patched by the device or OS vendor once disclosed.[3][4]
Analyst context for executives and security teams
Lockscreen Bypass matters because a lost, stolen, seized, or briefly unattended Android or iOS device can become a direct path to enterprise data if the screen lock can be defeated. The ATT&CK entry covers physical-access scenarios such as biometric spoofing, passcode guessing or observation, and exploitation of lockscreen vulnerabilities. For leaders, this is less about a single malware alert and more about whether mobile access to email, identity sessions, cloud apps, and regulated data remains protected when the device itself is in someone else’s hands.
Executive priority
Prioritize this as a mobile resilience and compliance-control issue: supported devices, prompt security updates, enforceable EMM/MDM policy, and conditional access based on device posture are the business controls that determine exposure. Executives should ask whether unsupported or unpatched mobile devices can still reach enterprise resources, whether wipe/lock/passcode policies are enforced, and whether incident response has a clear process for lost or physically compromised devices.
Technical view
ATT&CK lists Android and iOS platforms, with no tactic or official detection text provided. SOC, mobile security, and IR teams should validate coverage through mobile device management posture, security patch level, lock policy configuration, and available device security events rather than expecting a universal lockscreen-bypass log. Relationship context shows Security Updates (M1001) and Enterprise Policy (M1012) as mitigations, and notes Android software relationships including Chameleon, Escobar, BRATA, and VajraSpy using this technique. Treat those relationships as threat-intelligence context for Android monitoring, not proof of local exposure.
Likely telemetry
- EMM/MDM inventory showing OS version, device model, security patch level, and support status
- EMM/MDM compliance records for passcode, biometric, lock timeout, failed-unlock wipe, and encryption-related policies where available
- Conditional-access or mobile access logs showing blocked or allowed enterprise access from noncompliant or outdated devices
- Lost/stolen device reports, remote lock/wipe actions, and incident response case notes
- Mobile threat defense or endpoint mobile alerts where deployed
Detection direction
- Confirm what mobile platforms actually expose: many lockscreen bypass attempts may not generate detailed telemetry available to the SOC.
- Alert on devices that fall out of compliance for patch level, passcode policy, lock timeout, or wipe-after-failed-attempts settings.
- Tune conditional-access monitoring to identify enterprise access from devices that are outdated, unsupported, or missing required EMM/MDM posture.
- Correlate lost/stolen reports and remote wipe/lock events with cloud, email, and identity session activity from the same user or device.
- Use the Android malware relationships as enrichment for mobile threat hunting, while avoiding assumptions that those families are present without local evidence.
Mitigation priorities
- Maintain prompt mobile security updates and block or limit enterprise access from devices without recent security updates, consistent with M1001.
- Prefer devices and carriers with clear security update commitments; decommission devices that no longer receive updates.
- Use EMM/MDM enterprise policy to enforce strong lockscreen requirements, lock timeout, failed-attempt controls, and compliance-based access.
- Require rapid reporting and response procedures for lost, stolen, or physically accessed devices, including remote lock or wipe where appropriate.
- Review exceptions for executives, privileged users, and high-risk roles because physical access to their devices may carry higher business impact.
Analyst notes and limits
This technique consolidates older ATT&CK objects for Biometric Spoofing and Device Unlock Code Guessing or Brute Force. The relationship set provides useful mitigation and Android software context, but the object itself has no ATT&CK tactic and no official detection guidance. Defensive value comes from validating mobile governance, posture enforcement, and incident handling rather than from a single detection rule.
The supplied ATT&CK fields do not provide detailed detection logic, event IDs, exploit-specific indicators, or guaranteed telemetry sources. Local EMM/MDM capabilities, OS versions, device models, user roles, and conditional-access architecture are required to determine real coverage and residual risk.
Lockscreen Bypass
An adversary with physical access to a mobile device may seek to bypass the device’s lockscreen. Several methods exist to accomplish this, including:
* Biometric spoofing: If biometric authentication is used, an adversary could attempt to spoof a mobile device’s biometric authentication mechanism. Both iOS and Android partly mitigate this attack by requiring the device’s passcode rather than biometrics to unlock the device after every device restart, and after a set or random amount of time.[1][2] * Unlock code bypass: An adversary could attempt to brute-force or otherwise guess the lockscreen passcode (typically a PIN or password), including physically observing (“shoulder surfing”) the device owner’s use of the lockscreen passcode. Mobile OS vendors partly mitigate this by implementing incremental backoff timers after a set number of failed unlock attempts, as well as a configurable full device wipe after several failed unlock attempts. * Vulnerability exploit: Techniques have been periodically demonstrated that exploit mobile devices to bypass the lockscreen. The vulnerabilities are generally patched by the device or OS vendor once disclosed.[3][4]
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.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Mobile | — | Biometric Spoofing | Biometric Spoofing revoked by this object. |
| Mobile | — | Device Unlock Code Guessing or Brute Force | Device Unlock Code Guessing or Brute Force revoked by this object. |
Groups, software, and campaigns
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]
S1092: Escobar
S9006: VajraSpy
VajraSpy is Android malware distributed via trojanized messaging and news applications. It has been used to target individuals in Pakistan and India since at least 2021 and has been delivered through the Google Play Store, malicious domains, and other uncontrolled distribution channels. VajraSpy is attributed with high confidence to Patchwork which has used the malware to conduct targeted espionage, primarily against devices in Pakistan.[1][2][3]
S1083: Chameleon
Chameleon is an Android banking trojan that can leverage Android’s Accessibility Services to perform malicious activities. Believed to have been first active in January 2023, Chameleon has been observed targeting users in Australia and Poland by masquerading as official applications. A new variant of Chameleon has expanded its targets to include Android users in the United Kingdom and Italy.[1][2]
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.3 | Current bundle | 32ec1e96081a… |
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]
SRLabs-Fingerprint
SRLabs. (n.d.). Fingerprints are not fit for secure device unlocking. Retrieved December 23, 2016.
Open source URL -
[2]
TheSun-FaceID
Sean Keach. (2018, February 15). Brit mates BREAK Apple’s face unlock and vow to never buy iPhone again. Retrieved September 18, 2018.
Open source URL -
[3]
Wired-AndroidBypass
Andy Greenberg. (2015, September 15). Hack Brief: Emergency Number Hack Bypasses Android Lock Screens. Retrieved December 23, 2016.
Open source URL -
[4]
Kaspersky-iOSBypass
Chris Brook. (2016, November 17). iOS 10 Passcode Bypass Can Access Photos, Contacts. Retrieved December 23, 2016.
Open source URL -
[5]
mitre-attack T1461Open 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.