DET0715: Detection of Masquerading
DET0715 is a MITRE ATT&CK mobile detection strategy for identifying Masquerading behavior. The business significance is that mobile artifacts that look leg...
Analyst context for executives and security teams
DET0715 is a MITRE ATT&CK mobile detection strategy for identifying Masquerading behavior. The business significance is that mobile artifacts that look legitimate can weaken user trust, SOC triage, and mobile security controls because names, locations, appearance, or metadata may be manipulated to avoid attention. For leaders, the value is not in assuming a specific campaign, but in validating whether mobile security processes can distinguish trusted applications, services, or files from lookalikes on Android and iOS environments associated with the related ATT&CK technique T1655.
Executive priority
Treat this as a control-validation and evidence-readiness issue for mobile security. Security leaders should ask whether the organization has reliable mobile application inventory, application provenance checks, user reporting paths, and incident response procedures for suspicious apps or artifacts that imitate legitimate ones. Because the ATT&CK object does not provide a formal detection description, priority should be placed on confirming what evidence is actually available before claiming detection coverage in audits, risk reviews, or managed detection reporting.
Technical view
SOC, detection engineering, and IR teams should map this strategy to the related mobile ATT&CK technique T1655, Masquerading, which covers manipulation of artifact names, locations, appearance, or metadata to appear benign. Validation should focus on whether mobile telemetry can expose suspicious discrepancies such as misleading application names, unexpected package or bundle identity, abnormal metadata, or artifacts that resemble legitimate services. The supplied ATT&CK fields do not define tactics, platforms for the detection strategy, or specific analytics, so teams should avoid treating DET0715 as a complete rule and instead use it as a detection coverage objective tied to Android and iOS context from the related technique.
Likely telemetry
- Mobile device management or enterprise mobility inventory records
- Mobile application inventory and installation history
- Application metadata, package or bundle identifiers, signing or provenance evidence where available
- Mobile security or endpoint alerts related to suspicious applications or artifacts
- User reports of confusing, lookalike, or unexpected mobile applications
Detection direction
- Validate whether mobile inventory shows both display names and stronger identifiers such as package, bundle, signing, or provenance attributes where available.
- Tune review logic to look for inconsistencies between an artifact’s visible name or appearance and its underlying identity or source.
- Account for false positives from legitimate application rebranding, localization, enterprise-wrapped apps, testing builds, or administrative renaming practices.
- Use the relationship to T1655 as the analytic scope: focus on artifacts manipulated to appear legitimate or benign, not generic mobile malware detection.
- Document coverage gaps clearly because the official ATT&CK detection text for DET0715 is not provided.
Mitigation priorities
- Establish authoritative mobile application allowlists or approved software catalogs for managed devices.
- Require application source, identity, and provenance checks in mobile device management or mobile security workflows where available.
- Educate users and help desks to report lookalike or confusing mobile apps without relying only on visual names or icons.
- Ensure IR playbooks include steps for collecting mobile app metadata and comparing it against approved baselines.
- Use compliance and risk reporting to distinguish between having a policy for approved mobile apps and having telemetry that proves masquerading can be investigated.
Analyst notes and limits
This take is based on the DET0715 detection strategy object and its relationship to ATT&CK mobile technique T1655, Masquerading. The source object itself has no official description, no official detection guidance, no tactics, and no platforms specified. The Android and iOS context comes from the related T1655 technique, not from the DET0715 object fields.
ATT&CK provides sparse fields for this detection strategy, so the guidance must remain high-level. Local device management architecture, mobile OS mix, application sourcing model, logging depth, and privacy constraints will determine whether practical detection or investigation is feasible. No active exploitation, attribution, or guaranteed detection coverage is implied.
Detection of Masquerading
No official description is available in the imported ATT&CK source object.
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 | T1655 | Masquerading | This object detects Masquerading. |
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 | 6b5152c3e26b… |
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]
mitre-attack DET0715Open 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.