S0323: Charger
Analyst context for executives and security teams
Charger matters because it turns an Android phone into both a data-loss and availability problem: ATT&CK describes it as stealing contacts and SMS messages, and as able to lock the device and demand ransom if it receives administrator permissions. For leaders, the practical issue is whether corporate Android devices have enough app governance, permission visibility, and recovery playbooks to prevent a single malicious app from exposing personal/business communications or disrupting mobile-dependent staff.
Executive priority
Prioritize this behavior where Android devices support executives, field operations, regulated communications, or any workflow that relies on SMS. The key business questions are: which devices can install unapproved apps, who can grant device administrator privileges, whether contacts/SMS/location permissions are monitored, and how quickly the organization can recover a locked mobile device. For vulnerability and lifecycle planning, the related ATT&CK context highlights older Android versions prior to Android 7 as materially different for passcode-reset abuse by apps with Device Administrator access.
Technical view
SOC, mobile security, and IR teams should validate coverage around Android app inventory, permission grants, device administrator enrollment, suspicious access to contacts/SMS/location APIs, obfuscated application content, and device lockout behavior. ATT&CK provides no official detection text or tactics for Charger, so detection engineering should be built from the described behaviors and relationships: Obfuscated Files or Information, Location Tracking, Contact List access, and Endpoint Denial of Service. Treat this as a mobile endpoint and MDM visibility problem, not only a malware-signature problem.
Likely telemetry
- Android MDM/UEM app inventory, install source, package metadata, and version history
- Application permission state for contacts, SMS, location, and background location where available
- Device Administrator, device owner, or profile owner grant and change events
- Mobile threat defense or sandbox/static-analysis findings for obfuscated APK content
- Signals of contacts, SMS, or location data access by newly installed or untrusted apps, where the platform/tooling exposes them
Detection direction
- Confirm whether Android telemetry can actually show the permissions and administrator state needed to distinguish suspicious apps from legitimate managed apps.
- Tune detections around risky combinations: newly installed or unapproved app plus contacts/SMS/location permissions, obfuscation indicators, or Device Administrator privileges.
- Review allowlisted business apps that legitimately need contacts, SMS, or location access to reduce false positives while preserving scrutiny of unusual permission changes.
- Create IR triage logic for reports of sudden device lockout or ransom messaging, especially when paired with recent app installation or admin-permission approval.
- Because ATT&CK provides no official detection guidance for Charger, document local assumptions and validate them with controlled testing in managed Android environments.
Mitigation priorities
- Use MDM/UEM policy to control approved Android applications and monitor high-risk permission requests.
- Restrict or tightly govern Device Administrator, device owner, and profile owner privileges; alert on unexpected grants.
- Prioritize upgrade or replacement planning for older Android devices where Endpoint Denial of Service behavior is more relevant per ATT&CK context.
- Maintain mobile recovery procedures, including backup, device re-enrollment, wipe/reprovisioning, and user reporting paths for lockout events.
- Review whether sensitive workflows depend on SMS and ensure mobile compromise is considered in incident response and compliance evidence collection.
Analyst notes and limits
The ATT&CK object is specific to Android malware and is tied to one cited public source. Relationship context expands the defensive view to obfuscation, location tracking, contact list access, and mobile endpoint denial of service. The object has no listed tactics and no official detection text, so defenders should treat this as a behavior-driven validation exercise using their own MDM, mobile threat defense, and Android fleet data.
This take uses only the supplied ATT&CK fields, references, and relationships. It does not assert current activity, attribution, prevalence, customer exposure, or guaranteed detection. Local Android versions, MDM configuration, app approval process, and available mobile telemetry determine actual risk and coverage.
Charger
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 | T1642 | Endpoint Denial of Service | Charger locks the device if it is granted admin permissions, displaying a message demanding a ransom payment.CitationCheckPoint-Charger |
| Mobile | T1430 | Location Tracking | Charger checks the local settings of the device and does not run its malicious logic if the device is located in Ukraine, Russia, or Belarus.CitationCheckPoint-Charger |
| Mobile | T1406 | Obfuscated Files or Information | Charger encodes strings into binary arrays to make it difficult to inspect them. It also loads code from encrypted resources dynamically and includes meaningless commands that mask the actual commands passing through.CitationCheckPoint-Charger |
| Mobile | T1636.003 | Contact List Sub-technique | Charger steals contacts from the victim user's device.CitationCheckPoint-Charger |
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.1 | Current bundle | aae508cb5a45… |
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]
CheckPoint-Charger
Oren Koriat and Andrey Polkovnichenko. (2017, January 24). Charger Malware Calls and Raises the Risk on Google Play. Retrieved January 24, 2017.
Open source URL -
[2]
Charger
(Citation: CheckPoint-Charger)
-
[3]
mitre-attack S0323Open 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.