The most common mobile malware disguise is also the simplest: an app that calls itself "Google Play Protect", "System Update" or the user's bank, with the right icon and a plausible package name. ATT&CK for Mobile v20 tracks this as Masquerading (T1655), a Defense Evasion (TA0030) technique on Android and iOS, with one sub-technique, Match Legitimate Name or Location (T1655.001). It is used to persuade users to install and trust the app, to stop them removing it, and to make it blend in with system components during review. This page is for mobile security engineers, MDM administrators and incident responders: the forms masquerading takes, the procedure examples ATT&CK records, the platform signing rules that limit it, and how to detect impostor apps with inventory, vetting and forensics. For the wider matrix, see the MITRE ATT&CK for Mobile Guide; the enterprise equivalent is covered in the T1036 Masquerading Defensive Guide.
Key takeaways
- Name and icon are not identity. On mobile the trustworthy identifiers are the package name or bundle ID together with the signing certificate and install source; display names and icons can be copied freely.
- Security tools are a favourite disguise. ATT&CK v20 records Anubis and GodFather imitating Google Play Protect, and XLoader for Android posing as a security application.
- Repackaging is masquerading too. Several families, including DoubleAgent, GoldenEagle and SimBad, were inserted into real apps so the result looks and behaves like the original.
- Android signing stops in-place replacement. An update is accepted only if its certificate matches the installed app, so an impostor must use a different package name or reach users who do not have the real app.
- ATT&CK maps one mitigation. M1011 User Guidance: install only from authorised app stores. Managed fleets should turn that into enforced policy.
What T1655 covers
ATT&CK defines Masquerading as manipulating features of artifacts so they appear legitimate or benign to users or security tools: the name, location or appearance of an object is manipulated or abused. This includes changing file metadata, tricking users into misidentifying the file type and using legitimate task or service names. ATT&CK also counts renaming abusable system utilities to evade monitoring as masquerading. The parent technique carries its own procedure examples where the disguise goes beyond a name: LightSpy, for example, has masqueraded a Mach-O executable as a PNG file.
T1655.001 Match Legitimate Name or Location
The sub-technique covers matching or approximating the name or location of legitimate files or resources. ATT&CK's examples are giving an artifact the name and icon of a trusted application such as Settings, or using a package name that matches a trusted application, such as com.google.android.gm. Adversaries may also use the same icon as the app they mimic. Most mobile procedure examples sit here.
| Form | Example from ATT&CK v20 | What gives it away |
|---|---|---|
| System or security app name | Anubis requested accessibility privileges while masquerading as "Google Play Protect"; Mandrake can mimic "Storage Settings"; WolfRAT used "Google service" and "Flash update" | Not a system app on the device's OEM image; installed from an unknown source |
| System-like package name | BOULDSPY installed as com.android.callservice; Android/AdDisplay.Ashas used a com.google.xxx package name | Package namespace does not match its signing certificate |
| Popular consumer or banking app | Fakecalls posed as Korean banking apps; Chameleon as CoinSpot and the IKO banking app; FakeSpy as postal service apps; Tiktok Pro as TikTok | Signing certificate differs from the genuine publisher |
| Fake update | ViperRAT second stage as "WhatsApp Update"; FrozenCell as updates to chat apps; BRATA as WhatsApp updates | Genuine apps update through their store, not by a separate app |
| Repackaged real app | DoubleAgent in trojanised Voxer and TalkBox; X-Agent for Android in a repackaged artillery app; ViceLeaker by Smali injection | Same name and functions, different certificate |
| Government or institution identity | Android/SpyAgent used the Korean police app icon; NGate used a profile image impersonating Brazil's Caixa Econômica Federal | Distribution outside the official store |
| Same package name as a real app | DocSwap used the same package name and similar structure as a legitimate VPN app | Certificate mismatch; cannot update the real app in place |
ATT&CK also lists groups and campaigns using the sub-technique, including APT-C-23, Bouncing Golf, MoustachedBouncer and PROMETHIUM's C0033 campaign. Attribution is as the ATT&CK pages state it.
Platform controls that limit masquerading
Android
- Signing continuity: Android's documentation states that when installing an update the system compares the certificates in the new version with those in the existing version and allows the update only if they match; an app signed with a different certificate must use a different package name and installs as a completely new app. So an impostor cannot silently replace an installed genuine app.
- Play Protect: scans installed apps daily, checks apps from any source and works to block harmful installs. Keep it on and do not let users disable it on managed devices.
- Play Integrity app verdict: your own apps can check appRecognitionVerdict; UNRECOGNIZED_VERSION means the certificate or package name does not match Google Play records, a direct signal of a repackaged copy. See APK Signing.
- Restricted settings: on Android 13 and later sensitive settings such as accessibility can be blocked for apps the user was told to download until the user allows restricted settings, which raises the cost of the "Play Protect needs accessibility" lure.
iOS and iPadOS
- Distribution control: iOS apps are installed through Apple's distribution channels or enterprise and MDM deployment, so the main masquerading risk is an impostor that reaches users through those channels or through enterprise distribution. On supervised devices MDM can restrict which apps are installed.
- Configuration profiles: impostor "update" or "security" profiles are another disguise. Lockdown Mode blocks configuration profile installation, which suits high-risk users; enrol devices in MDM before enabling it.
- Parity note: the v20 iOS procedure examples for T1655 are fewer than for Android; LightSpy's executable disguised as a PNG is one. Do not assume the gap means iOS users are not targeted with impostor apps.
Detection
ATT&CK v20's detection strategies for T1655 and T1655.001 use application vetting and management evidence. On Android they correlate permission grant state from the Android Enterprise device policy controller, manifest and requested-permission review, and install events for the impersonating app. On iOS they correlate code-signing entitlements and Info.plist privacy usage descriptions, display names very close to a known app catalogue entry, bundle IDs inside a known system namespace, and network flow metadata from a per-app VPN or content filter.
| Check | Source | Platform | Flag when |
|---|---|---|---|
| Display name similarity | MDM app inventory compared with an approved catalogue | Both | Name close to a known app or system component but different package or bundle ID |
| Namespace and certificate match | App vetting, MTD | Both | Package or bundle ID in com.google, com.android or com.apple style namespace without the matching publisher certificate |
| Install source | MDM inventory; Play Integrity appAccessRiskVerdict UNKNOWN_INSTALLED | Android | "System" or "security" app installed from outside Play or the managed store |
| Permission mismatch | DPC permission grant state, manifest review | Android | A utility, update or player app holding accessibility, SMS or notification access |
| Hidden icon | MTD agent, forensic review | Android | App with no launcher icon that is not a known system component (Mandrake falls back to a fake name only when it cannot hide) |
| Known indicators | Consensual forensic analysis with MVT | Both | Match against published spyware indicators |
For investigation steps, see the Mobile Forensics Guide and the Mobile Spyware Infection Response Playbook.
Mitigations
| Control | Source | How to apply it |
|---|---|---|
| M1011 User Guidance | ATT&CK v20 mapping | Teach users to install only from authorised stores, that genuine apps update through the store, and that Play Protect never asks for accessibility access |
| Managed install sources | Addition (M1012 Enterprise Policy) | Block unknown sources on Android Enterprise; use managed App Store distribution on supervised iOS |
| Approved app catalogue | Addition | Publish package names and publisher certificates for approved apps so inventory checks can compare |
| Integrity checks in your own apps | Addition (M1002 Attestation) | Use Play Integrity app verdicts on Android and App Attest on iOS to refuse repackaged clients; see Mobile App Attestation |
| Brand monitoring | Addition | Watch app stores and download sites for apps using your organisation's name or icon, and request takedown |
Where identity fits
A repackaged copy of your own app is a client identity problem. If the backend accepts any client that presents the right API key, an impostor app can talk to it and harvest user credentials and tokens. Treat the app as a non-human client: issue per-installation credentials after attestation, avoid static API keys in the bundle, and reject requests from unrecognised app versions. The Applebee's breach, where a database password was found by decompiling an Android app, shows how much a client bundle can expose to anyone who unpacks it, which is the first step in building a convincing repackaged copy.
How to implement
- Build the catalogue. List approved apps with package name or bundle ID and publisher certificate fingerprint.
- Compare inventory. Run the similarity, namespace and install source checks against MDM inventory in report-only mode for two weeks.
- Triage findings. Expect OEM and carrier apps on Android to need allow listing per model.
- Enforce. Block unknown sources and mark devices with confirmed impostors non-compliant.
- Protect your own apps. Add attestation checks to your backends, starting in log-only mode, then reject unrecognised versions.
- Roll back narrowly. If a legitimate app is flagged, add it to the catalogue rather than disabling the check.
Measuring it
- Percentage of installed apps on managed devices that match the approved catalogue by identifier and certificate.
- Number of apps installed from unknown sources on managed Android devices.
- Share of your own app's API traffic from clients that pass attestation.
- Time to takedown for impostor apps using your brand.
Common failure patterns
- Trusting the display name. Inventory reports that show only app names cannot tell "Google Play Protect" from an impostor.
- Allow listing by package name alone. Without the certificate, a same-name sideloaded package on a device without the real app passes.
- Helpdesk scripts that grant accessibility. The Anubis lure works because users are used to granting it when asked.
- Static API keys in your app. A repackaged client reuses them and looks identical to the backend.
- Ignoring OEM variance. Without per-model baselines, real system apps create noise and teams stop looking.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| ATT&CK for Mobile v20 | T1655 and T1655.001 (TA0030 Defense Evasion); M1011 | Technique, sub-technique and mapped mitigation |
| Related techniques | Mobile T1660 Phishing; T1474 Supply Chain Compromise; T1453 Abuse Accessibility Features; Enterprise T1036 Masquerading | Delivery, follow-on abuse and enterprise counterpart |
| NIST SP 800-53 Rev 5 | CM-11 User-installed Software; CM-7 Least Functionality; SR-11 Component Authenticity; SI-3 Malicious Code Protection | Install control and authenticity |
| NIST CSF 2.0 | PR.PS-02; DE.CM-09 | Software control and monitoring |
| ISO/IEC 27001:2022 Annex A | A.8.1 User endpoint devices; A.8.7 Protection against malware; A.8.19 Installation of software on operational systems | Endpoint, malware and installation controls |
Practitioner checklist
- Maintain an approved app catalogue with identifiers and certificate fingerprints.
- Block installs from unknown sources and keep Play Protect on.
- Alert on system-like names or namespaces that do not match the expected publisher.
- Flag utility or update apps holding accessibility, SMS or notification access.
- Remove helpdesk instructions that ask users to allow restricted settings.
- Add attestation checks to your own app backends and drop static API keys.
- Monitor stores and download sites for impostors of your brand.
- Keep a consent-based MVT process ready for suspected spyware.
Standards and references
- MITRE ATT&CK: Masquerading, Mobile T1655
- MITRE ATT&CK: Match Legitimate Name or Location, Mobile T1655.001
- Android Developers: Sign your app
- Android Developers: Play Integrity API integrity verdicts
- Google: Google Play Protect
- Android Help: Allow restricted settings
- Apple Support: About Lockdown Mode
- Mobile Verification Toolkit documentation
Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · APK sideloading · Android Banking Trojans Guide · Mobile Malware Guide