S0536: GPlayed
Analyst context for executives and security teams
GPlayed is an Android trojan described by ATT&CK as having a broad capability set. The relationships make it material because the behavior spans credential-style prompting, SMS and contact access, location tracking, local data collection, persistence, device administrator abuse, file deletion, and web-based communications. For leaders, this is less a single malware question and more a test of whether the mobile security program can see and control risky Android app behavior before it affects identity, privacy, or device availability.
Executive priority
Prioritize GPlayed as a mobile risk coverage check for Android fleets, especially executive devices, BYOD access paths, and devices handling sensitive communications. The decision value is to confirm whether mobile governance can produce audit-ready evidence for app inventory, permissions, device administrator status, SMS/contact/location access, and suspicious network behavior. The most business-relevant risks supported by the ATT&CK relationships are identity exposure through GUI input capture, privacy exposure through contacts/SMS/location/local data access, and operational disruption through device administrator abuse, file deletion, or endpoint denial of service.
Technical view
SOC, detection, and IR teams should validate Android-focused coverage against the mapped behaviors rather than relying on the malware name alone. Key validation areas include obfuscated application artifacts, applications that download new code at runtime, suspicious overlays or GUI prompts, installed-application and device/network discovery, location access, HTTP/HTTPS command traffic, SMS control, scheduled execution, broadcast receiver persistence, device administrator permission abuse, contact/SMS/local data access, file deletion, and legitimate-name or icon masquerading. ATT&CK provides no official detection text and no tactics for this object, so local detection logic should be built from the related techniques and observed Android telemetry.
Likely telemetry
- Android app inventory and package metadata from MDM/UEM or mobile security tooling
- Application manifest data, requested permissions, icons, names, package names, and signing information
- Device administrator enrollment and permission state
- Runtime behavior showing dynamic code download or execution after installation
- Network telemetry for HTTP/HTTPS destinations, DNS, and unusual mobile app communication patterns
Detection direction
- Use behavior clusters instead of single indicators: device administrator access plus SMS control, location/contact/SMS access, dynamic code download, or masquerading is higher value than any one permission alone.
- Validate whether static analysis handles obfuscated files and legitimate-name/icon mimicry; static checks alone may miss code downloaded after installation.
- Add dynamic analysis or runtime monitoring for applications that retrieve and execute code not present in the original package.
- Tune carefully for false positives because legitimate Android apps may use web protocols, scheduled jobs, location, contacts, or SMS permissions; prioritize unusual combinations, unexpected permission requests, and apps inconsistent with business need.
- Confirm mobile telemetry coverage for BYOD and executive devices, as these are common blind spots for SOC workflows built around traditional endpoint logs.
Mitigation priorities
- Maintain enforceable Android app inventory and approval controls for managed devices.
- Restrict or review high-risk permissions such as device administrator, SMS, contacts, location, storage, and background location according to business need.
- Use mobile app vetting that includes manifest review, reputation/context checks, obfuscation review, and dynamic behavior analysis where possible.
- Limit unmanaged or untrusted apps from accessing enterprise resources, especially where mobile devices are used for identity workflows or sensitive communications.
- Prepare mobile IR procedures for isolating a device, preserving evidence, removing administrator privileges where appropriate, and determining whether local data, SMS, contacts, or location information were exposed.
Analyst notes and limits
The supplied ATT&CK object identifies GPlayed as Android malware and provides relationship-driven technique context, but it does not include official detection guidance, aliases, labels, or tactics. The Talos reference is the only non-MITRE external source listed. Treat this as a coverage and readiness prompt for Android mobile defense rather than proof of current activity in any environment.
This take is limited to the provided ATT&CK STIX fields, external references, and relationships. It does not assert active exploitation, attribution, prevalence, specific indicators, customer exposure, or guaranteed detection. Local device inventory, permission telemetry, network logs, and mobile security data are required to assess actual risk and coverage.
GPlayed
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 | T1437.001 | Web Protocols Sub-technique | |
| Mobile | T1582 | SMS Control | |
| Mobile | T1636.004 | SMS Messages Sub-technique | |
| Mobile | T1603 | Scheduled Task/Job | |
| Mobile | T1636.003 | Contact List Sub-technique | |
| Mobile | T1407 | Download New Code at Runtime | |
| Mobile | T1418 | Software Discovery | |
| Mobile | T1624.001 | Broadcast Receivers Sub-technique | |
| Mobile | T1422 | System Network Configuration Discovery | |
| Mobile | T1642 | Endpoint Denial of Service | |
| Mobile | T1655.001 | Match Legitimate Name or Location Sub-technique | |
| Mobile | T1626.001 | Device Administrator Permissions Sub-technique | |
| Mobile | T1630.002 | File Deletion Sub-technique | |
| Mobile | T1406 | Obfuscated Files or Information | |
| Mobile | T1426 | System Information Discovery | |
| Mobile | T1533 | Data from Local System | |
| Mobile | T1430 | Location Tracking | |
| Mobile | T1417.002 | GUI Input Capture Sub-technique |
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 | 3cea5048c130… |
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]
Talos GPlayed
V. Ventura. (2018, October 11). GPlayed Trojan - .Net playing with Google Market . Retrieved November 24, 2020.
Open source URL -
[2]
mitre-attack S0536Open 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.