Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1655: Masquerading

Adversaries may attempt to manipulate features of their artifacts to make them appear legitimate or benign to users and/or security tools. Masquerading occurs when the name, location, or appearance of an object, legitimate or malicious, is manipulated or abused for the sake of evading defenses and observation. This may include manipulating file metadata, tricking users into misidentifying the file type, and giving legitimate task or service names.

Renaming abusable system utilities to evade security monitoring is also a form of Masquerading

MobileT1655TechniqueObject v1.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Masquerading on mobile is the abuse of names, locations, icons, package identifiers, or metadata so an app or artifact looks trusted when it is not. For leaders, the risk is that users and security tools may make the wrong decision: a fake “Settings,” banking, messaging, or otherwise familiar-looking app can survive longer because it appears normal.

Executive priority

Prioritize this as a mobile trust and incident-readiness issue. ATT&CK maps this technique to Android and iOS and to multiple mobile malware entries, including malware described as stealing credentials, bank account information, SMS, VoIP recordings, or cryptocurrency. Executives should ask whether the organization can prove what mobile apps are installed, where they came from, who signed them, and whether lookalike apps would be noticed before an incident depends on user reporting alone.

Technical view

SOC, mobile security, and IR teams should validate coverage for Android and iOS app identity mismatches: display name or icon resembling a legitimate app, package or bundle identifiers approximating trusted apps, suspicious file/resource placement, manipulated metadata, or renamed utilities. Because no official ATT&CK detection text is provided for T1655, teams should treat DET0715 as a detection-strategy reference to operationalize locally and test against their actual MDM/UEM, mobile threat defense, app inventory, and application analysis data.

Likely telemetry

  • MDM/UEM mobile app inventory and install history
  • App package/bundle identifiers, display names, icons, file locations, and metadata
  • Application signing certificate or developer identity information where available
  • Install source or distribution channel, including managed catalog, app store, email, messaging, or uncontrolled source indicators
  • Mobile threat defense or endpoint alerts related to suspicious applications or renamed utilities

Detection direction

  • Compare installed app names, icons, package names, bundle identifiers, and signing identities against known-good baselines for approved applications.
  • Tune for trusted-looking names or locations paired with untrusted signing, unexpected install source, or absence from the managed app catalog.
  • Review sub-technique T1655.001 context: matching legitimate names, locations, icons, or package names is a concrete detection use case.
  • Account for false positives from legitimate rebrands, regional variants, OEM applications, enterprise test builds, and sanctioned sideloading.
  • Use the related software mappings as threat-informed test cases, but do not assume local exposure without environment evidence.

Mitigation priorities

  • Start with M1011 User Guidance: train users to verify app source, publisher, permissions, and unexpected prompts before trusting familiar-looking mobile apps.
  • Maintain an approved mobile app inventory so defenders can distinguish legitimate business apps from lookalikes.
  • Where organizational policy allows, prefer managed distribution channels and reduce reliance on uncontrolled installation paths.
  • Build IR procedures for quickly collecting app identity, install source, signing, and device inventory evidence when a masquerading suspicion is reported.
  • Use compliance and audit evidence to show that mobile app governance, user guidance, and monitoring are operating, not merely documented.
Analyst notes and limits

The most useful local validation question is whether the organization can distinguish a legitimate trusted app from a visually similar or similarly named mobile artifact at scale. This technique is especially material where mobile devices are used for identity, banking, messaging, executive communications, or regulated workflows.

ATT&CK provides no official detection text and no tactics for this object. The supplied data supports Android and iOS scope, M1011 User Guidance, DET0715 as a related detection strategy, and several related software mappings, but it does not prove active exploitation or detection coverage in any specific environment.

Official MITRE ATT&CK definition

Masquerading

Adversaries may attempt to manipulate features of their artifacts to make them appear legitimate or benign to users and/or security tools. Masquerading occurs when the name, location, or appearance of an object, legitimate or malicious, is manipulated or abused for the sake of evading defenses and observation. This may include manipulating file metadata, tricking users into misidentifying the file type, and giving legitimate task or service names.

Renaming abusable system utilities to evade security monitoring is also a form of Masquerading

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Related techniques

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.

1 rows
Domain ID Name Relationship / procedure
Mobile T1655.001 Match Legitimate Name or Location Sub-technique Match Legitimate Name or Location subtechnique of this object.
Associated objects

Groups, software, and campaigns

Malware Mobile

S9004: Crocodilus

Crocodilus is an Android banking Trojan that was discovered in March 2025. Crocodilus targeted users worldwide, including Turkey, Poland, Argentina, Brazil, Spain, the United States, Indonesia and India. Crocodilus has been customized based on the target location. For example, Crocodilus mimicked major Turkish and Spanish banks for users in Turkey and Spain, while users in Poland saw Facebook advertisements that promoted Crocodilus to claim bonus points.[1][2]

Android
Malware Mobile

S1208: FjordPhantom

FjordPhantom is a malicious Android application first discovered in September 2024 with targets in Southeast Asia, specifically Indonesia, Thailand, and Vietnam. FjordPhantom was distributed through email and messaging applications. Once installed, the application launches a virtualization solution to steal important information, such as bank accounts, and to manipulate the user interface. The malicious activity from the virtualization solution runs alongside legitimate banking applications.[1]

Android
Malware Mobile

S9006: VajraSpy

VajraSpy is Android malware distributed via trojanized messaging and news applications. It has been used to target individuals in Pakistan and India since at least 2021 and has been delivered through the Google Play Store, malicious domains, and other uncontrolled distribution channels. VajraSpy is attributed with high confidence to Patchwork which has used the malware to conduct targeted espionage, primarily against devices in Pakistan.[1][2][3]

Android
Malware Mobile

S1225: CherryBlos

CherryBlos is an Android malware that steals credentials and redirects cryptocurrency to adversary-controlled wallets. CherryBlos was labelled Robot 999 in its first appearance in April 2023; since then, various aliases have been used, including GPTalk, Happy Miner, and SynthNet. The threat actors behind CherryBlos uploaded the malware to different Google Play regions, such as Malaysia, Vietnam, Indonesia, Philippines, Uganda, and Mexico.[1]

Android
Malware Mobile

S1185: LightSpy

First observed in 2018, LightSpy is a modular malware family that initially targeted iOS devices in Southern Asia before expanding to Android and macOS platforms. It consists of a downloader, a main executable that manages network communications, and functionality-specific modules, typically implemented as `.dylib` files (iOS, macOS) or `.apk` files (Android). LightSpy can collect VoIP call recordings, SMS messages, and credential stores, which are then exfiltrated to a command and control (C2) server.[1]

AndroidWindowsiOS
Relationship explorer

All related ATT&CK context

uses · Malware S9004: Crocodilus Mobile subtechnique of · Technique T1655.001: Match Legitimate Name or Location Mobile uses · Malware S1208: FjordPhantom Mobile detects · Detection Strategy DET0715: Detection of Masquerading Mobile uses · Malware S9006: VajraSpy Mobile mitigates · Mitigation M1011: User Guidance Mobile uses · Malware S1225: CherryBlos Mobile uses · Malware S1185: LightSpy Mobile
Mitigations

Mitigation direction

Mitigation Mobile

M1011: User Guidance

Describes any guidance or training given to users to set particular configuration settings or avoid specific potentially risky behaviors.

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
b1f71caa88dd36cb...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle b1f71caa88dd…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    NIST Mobile Threat Catalogue APP-14
    Open source URL
  2. [2]
    NIST Mobile Threat Catalogue APP-31
    Open source URL
  3. [3]
    mitre-attack T1655
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use