S0539: Red Alert 2.0
Red Alert 2.0 is a banking trojan that masquerades as a VPN client.[1]
Analyst context for executives and security teams
Red Alert 2.0 is an Android banking trojan described by MITRE as masquerading as a VPN client. The business issue is not only “malware on a phone”; it is trust abuse on mobile devices that may handle banking, identity prompts, SMS messages, contacts, call logs, and web traffic. The ATT&CK relationships show behaviors that can undermine mobile authentication and user trust, including GUI input capture, SMS control, collection of SMS/contact/call data, runtime code download, obfuscation, and web-based command-and-control patterns.
Executive priority
Prioritize this as a mobile identity and fraud-readiness concern where Android devices are used for workforce access, banking, executive communications, or SMS-based verification. Leaders should ask whether mobile device management, app vetting, permission governance, and incident response playbooks can identify a fake trusted app, revoke access, preserve evidence, and support affected users quickly. The most material control decisions are whether the organization can see risky app permissions, unexpected device administrator grants, SMS access, dynamic code loading, and suspicious web traffic from mobile endpoints.
Technical view
For SOC, detection engineering, and IR teams, validate Android telemetry around applications posing as legitimate services, especially VPN-themed apps, and correlate that with the related ATT&CK behaviors: obfuscated files or information (T1406), runtime code download (T1407), GUI input capture (T1417.002), installed software discovery (T1418), web protocol C2 (T1437.001), dead drop resolver behavior (T1481.001), non-standard ports (T1509), SMS control (T1582), device administrator permission abuse (T1626.001), call log/contact/SMS collection (T1636.002/T1636.003/T1636.004), and matching legitimate names or locations (T1655.001). Because MITRE provides no official detection text for this object, local detection should be based on observed mobile permissions, app metadata, device admin state, network behavior, and user-reporting workflows rather than a single signature.
Likely telemetry
- Android app inventory and package metadata, including name, icon, installer source, version, and requested permissions
- Mobile device management or enterprise mobility management records for device administrator permission grants and app installation events
- Android permission usage or audit data for SMS, contacts, call log, and accessibility or overlay-style sensitive prompt behavior where available
- Network telemetry for mobile devices, including HTTP/HTTPS destinations, unusual protocol-port pairings, and access to external web services that may act as resolvers
- Mobile threat defense or app reputation analysis results covering obfuscation, dynamic code loading, and suspicious runtime behavior
Detection direction
- Validate whether security tooling can alert on newly installed Android apps that request SMS, contacts, call log, or device administrator privileges, especially when the app branding suggests a trusted utility such as a VPN client.
- Tune detections for combinations of behaviors rather than single permissions, since VPN clients and security apps may legitimately use network permissions; higher-risk combinations include VPN-like branding plus SMS access, device admin requests, dynamic code download, obfuscation, or suspicious web traffic.
- Review visibility for runtime code download because static app-store or pre-installation checks may miss behavior introduced after installation, as described in related technique T1407.
- Correlate mobile network traffic using web protocols, dead drop resolver patterns, and non-standard ports with suspicious app inventory and permission events to reduce false positives.
- Account for blind spots: personal/BYOD Android devices, limited mobile network inspection, encrypted web traffic, sparse endpoint telemetry, and lack of official MITRE detection guidance for this malware object.
Mitigation priorities
- Start with mobile application governance: restrict or review installation of unapproved Android apps on managed devices, with special scrutiny for apps impersonating trusted utilities such as VPN clients.
- Enforce least privilege for mobile apps by monitoring and limiting SMS, contacts, call log, and device administrator permissions where business use does not justify them.
- Strengthen mobile identity controls so compromise of SMS messages or GUI credential prompts does not become a single point of failure; prioritize phishing-resistant or app-based controls where appropriate to the environment.
- Ensure MDM/EMM processes can remove or quarantine suspicious apps, revoke device administrator grants when possible, and trigger credential reset or access revocation workflows during mobile malware response.
- Build IR playbooks for Android malware cases that include evidence preservation, user communication, banking or fraud escalation paths when relevant, and validation of whether sensitive data stores such as SMS, contacts, or call logs were exposed.
Analyst notes and limits
The supplied ATT&CK object identifies Red Alert 2.0 as Android malware and a banking trojan masquerading as a VPN client, with technique relationships that describe evasion, credential/input capture, discovery, C2-related web communications, SMS control, elevated device control, and collection of call/contact/SMS data. The strongest defensive value is to treat this as a test case for mobile app trust, permission oversight, and mobile incident response readiness rather than as a standalone indicator list.
MITRE does not provide official detection guidance, tactics are not specified in the supplied object, and no aliases or labels are listed. The external reference is limited to the Sophos write-up and the MITRE page. This take does not assert current activity, attribution, customer exposure, or guaranteed detection. Local assessment requires the organization’s Android management model, mobile telemetry availability, app inventory, and legal/privacy constraints for mobile evidence collection.
Red Alert 2.0
Red Alert 2.0 is a banking trojan that masquerades as a VPN client.[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 | T1407 | Download New Code at Runtime | Red Alert 2.0 can download additional overlay templates.CitationSophos Red Alert 2.0 |
| Mobile | T1582 | SMS Control | Red Alert 2.0 can send SMS messages.CitationSophos Red Alert 2.0 |
| Mobile | T1417.002 | GUI Input Capture Sub-technique | Red Alert 2.0 has used malicious overlays to collect banking credentials.CitationSophos Red Alert 2.0 |
| Mobile | T1636.003 | Contact List Sub-technique | Red Alert 2.0 can collect the device’s contact list.CitationSophos Red Alert 2.0 |
| Mobile | T1636.004 | SMS Messages Sub-technique | Red Alert 2.0 can collect SMS messages.CitationSophos Red Alert 2.0 |
| Mobile | T1626.001 | Device Administrator Permissions Sub-technique | Red Alert 2.0 can request device administrator permissions.CitationSophos Red Alert 2.0 |
| Mobile | T1655.001 | Match Legitimate Name or Location Sub-technique | Red Alert 2.0 has masqueraded as legitimate media player, social media, and VPN applications.CitationSophos Red Alert 2.0 |
| Mobile | T1481.001 | Dead Drop Resolver Sub-technique | Red Alert 2.0 can fetch a backup C2 domain from Twitter if the primary C2 is unresponsive.CitationSophos Red Alert 2.0 |
| Mobile | T1509 | Non-Standard Port | Red Alert 2.0 has communicated with the C2 using HTTP requests over port 7878.CitationSophos Red Alert 2.0 |
| Mobile | T1437.001 | Web Protocols Sub-technique | Red Alert 2.0 has communicated with the C2 using HTTP.CitationSophos Red Alert 2.0 |
| Mobile | T1406 | Obfuscated Files or Information | Red Alert 2.0 has stored data embedded in the strings.xml resource file.CitationSophos Red Alert 2.0 |
| Mobile | T1636.002 | Call Log Sub-technique | Red Alert 2.0 can collect the device’s call log.CitationSophos Red Alert 2.0 |
| Mobile | T1418 | Software Discovery | Red Alert 2.0 can obtain the running application.CitationSophos Red Alert 2.0 |
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 | d3956702f842… |
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]
Sophos Red Alert 2.0
J. Chandraiah. (2018, July 23). Red Alert 2.0: Android Trojan targets security-seekers. Retrieved December 14, 2020.
Open source URL -
[2]
mitre-attack S0539Open 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.