S0524: AndroidOS/MalLocker.B
AndroidOS/MalLocker.B is a variant of a ransomware family targeting Android devices. It prevents the user from interacting with the UI by displaying a screen containing a ransom note over all other windows. [1]
Analyst context for executives and security teams
AndroidOS/MalLocker.B matters because it represents Android ransomware behavior that can make a device unusable by placing a ransom note over other windows. For leaders, the practical issue is not only malware removal; it is whether the organization can quickly identify affected Android devices, preserve evidence, restore user productivity, and prove mobile controls are working.
Executive priority
Prioritize this as a mobile resilience and incident-readiness issue for environments that allow Android devices to access business data. Key questions: which Android devices are managed, what app sources are permitted, who can see risky permissions or suspicious app identity changes, and how quickly can a locked-out device be contained or recovered without disrupting operations? The object has no ATT&CK-provided detection text, so assurance should come from validating local mobile telemetry and response procedures rather than assuming coverage.
Technical view
SOC, mobile security, and IR teams should validate controls against the ATT&CK relationships supplied for this malware: obfuscated files or information, broadcast receivers, device lockout, and matching legitimate names or locations. On Android, review whether tooling can inspect installed packages, app manifests, broadcast receiver registrations, permission and device-administrator state, overlay-like behavior, suspicious package names/icons, and obfuscated or packed application content. Because no tactics or official detection guidance are provided, detections should be behavior- and artifact-led, not tactic-led.
Likely telemetry
- Managed Android device inventory from MDM/EMM or mobile security tooling
- Installed application package metadata, names, icons, signing/certificate details, and install source where available
- Android app manifest details, including broadcast receiver declarations or runtime registrations where visible
- Permission and device-administrator status changes relevant to lockout or over-window behavior
- Mobile security alerts for obfuscated, packed, encrypted, or otherwise hard-to-analyze application content
Detection direction
- Validate visibility into Android applications that display persistent content over other windows or otherwise inhibit user interaction.
- Hunt for suspicious combinations: obfuscated application content, broadcast receiver usage, lockout-like behavior, and app identity that mimics legitimate names, icons, package names, or locations.
- Tune carefully because broadcast receivers and some overlay-style behaviors can be used by legitimate Android apps; prioritize combinations of behaviors and suspicious app provenance rather than single indicators alone.
- Confirm whether mobile alerts are correlated with device inventory and user impact signals, such as reports of lockout or unusable UI.
- Document blind spots where unmanaged Android devices, personal devices, or limited mobile telemetry prevent inspection of installed apps, permissions, or package metadata.
Mitigation priorities
- Establish or validate Android device management coverage for devices that access business resources.
- Control application sourcing and installation policy, especially for unmanaged or unknown apps.
- Review policy and monitoring for high-risk permissions and device-administrator capabilities associated with lockout scenarios.
- Maintain incident procedures for isolating, recovering, re-enrolling, or replacing locked-out Android devices while preserving needed evidence.
- Use mobile security review and threat intelligence processes to assess apps that use obfuscation, impersonate legitimate app identity, or register event-driven execution mechanisms.
Analyst notes and limits
This take is based on the supplied ATT&CK software object S0524 and its relationships to T1406, T1624.001, T1629.002, and T1655.001. The strongest supported defensive angle is Android mobile ransomware readiness: device lockout, UI obstruction, app obfuscation, event-triggered execution via broadcast receivers, and legitimate-name/location mimicry.
ATT&CK provides no official detection text, no tactics for this object, and no supplied evidence of current activity, attribution, prevalence, or customer exposure. Local Android management coverage, mobile telemetry depth, and app governance determine how actionable these recommendations are.
AndroidOS/MalLocker.B
AndroidOS/MalLocker.B is a variant of a ransomware family targeting Android devices. It prevents the user from interacting with the UI by displaying a screen containing a ransom note over all other windows. [1]
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.
Techniques used
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 | T1624.001 | Broadcast Receivers Sub-technique | AndroidOS/MalLocker.B has registered to receive 14 different broadcast intents for automatically triggering malware payloads. CitationMicrosoft MalLockerB |
| Mobile | T1406 | Obfuscated Files or Information | AndroidOS/MalLocker.B has employed both name mangling and meaningless variable names in source. AndroidOS/MalLocker.B has stored encrypted payload code in the Assets directory, coupled with a custom decryption routine that assembles a .dex file by passing data through Android Intent objects. CitationMicrosoft MalLockerB |
| Mobile | T1629.002 | Device Lockout Sub-technique | AndroidOS/MalLocker.B can prevent the user from interacting with the UI by using a carefully crafted "call" notification screen. This is coupled with overriding the `onUserLeaveHint()` callback method to spawn a new notification instance when the current one is dismissed. CitationMicrosoft MalLockerB |
| Mobile | T1655.001 | Match Legitimate Name or Location Sub-technique | AndroidOS/MalLocker.B has masqueraded as popular apps, cracked games, and video players. CitationMicrosoft MalLockerB |
All related ATT&CK context
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 | 19b160f571af… |
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]
Microsoft MalLockerB
D. Venkatesan. (2020, October 8). Sophisticated new Android malware marks the latest evolution of mobile ransomware . Retrieved October 29, 2020.
Open source URL -
[2]
mitre-attack S0524Open 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.