DET0347: Detection Strategy for Masquerading via Legitimate Resource Name or Location
DET0347 is a detection strategy object for finding masquerading where an adversary names or places resources to look legitimate. The business issue is that...
Analyst context for executives and security teams
DET0347 is a detection strategy object for finding masquerading where an adversary names or places resources to look legitimate. The business issue is that this behavior can let suspicious files, keys, or other resources blend into trusted locations and delay triage, containment, and audit reconstruction. Because the ATT&CK object provides no official detection logic, organizations should treat it as a prompt to validate whether their SOC can distinguish expected resource names and locations from lookalikes or misplaced items in the environments relevant to the related technique.
Executive priority
Prioritize this as a resilience and investigation-readiness question: can the organization prove what is normally allowed to exist in trusted paths, namespaces, or resource locations, and can analysts quickly identify deviations? This matters for SOC efficiency, incident response scoping, compliance evidence, and control assurance because masquerading can undermine controls that rely on name, path, or location trust. Budget and ownership should focus on telemetry quality, asset/application baselines, and clear response procedures rather than assuming default tool coverage.
Technical view
The supplied strategy detects ATT&CK T1036.005, Match Legitimate Resource Name or Location, associated with stealth and listed for Containers, ESXi, Linux, and macOS. SOC and detection teams should validate whether they collect resource creation, modification, execution, and placement evidence from those environments and whether detections compare observed names/locations against known-good baselines. IR teams should be ready to review suspicious resources that approximate legitimate names, appear in commonly trusted locations, or differ subtly from expected paths, ownership, signing, package, or deployment context where such data is available.
Likely telemetry
- File and directory creation, modification, rename, and execution events
- Process execution metadata including executable path, command line, parent process, and user context
- Container image, container filesystem, and workload deployment metadata where applicable
- ESXi host file, datastore, process, and administrative activity logs where available
- Linux and macOS endpoint telemetry for path, permissions, ownership, hashes, and launch or persistence context
Detection direction
- Validate coverage against the related technique rather than this object alone, because the official detection field is not provided.
- Build or review detections that flag resources with legitimate-looking names in unexpected locations, or unexpected resources placed in trusted locations.
- Tune against environment-specific baselines to reduce false positives from legitimate software updates, package managers, admin scripts, developer tooling, and container build processes.
- Check for blind spots in non-Windows environments specifically listed by the related technique: Containers, ESXi, Linux, and macOS.
- Avoid relying only on filename or path reputation; include contextual signals such as parent process, user, deployment source, ownership, permissions, hash, and first-seen time where collected.
Mitigation priorities
- Establish and maintain inventories of approved software, workload artifacts, trusted directories, and expected resource locations.
- Harden write access to trusted locations and administrative paths so only authorized processes and identities can place or modify resources there.
- Use change control and deployment pipelines to create reliable baselines for what should exist in container, ESXi, Linux, and macOS environments.
- Ensure endpoint, host, and workload logging is retained long enough to reconstruct when a suspicious resource appeared and what identity or process created it.
- Document triage playbooks for lookalike names and unexpected trusted-location placement, including ownership verification and containment decision points.
Analyst notes and limits
This take is derived from the detection strategy metadata and its relationship to T1036.005. The most useful local work is baseline validation: what names and locations are legitimate in the organization, who can modify them, and whether SOC tooling can see deviations across the related platforms.
The ATT&CK object has no official description, no official detection text, no tactics, and no platforms of its own. Platform and tactic context comes only from the related T1036.005 technique. No active exploitation, actor attribution, impact, or guaranteed detection coverage is stated by the supplied fields.
Detection Strategy for Masquerading via Legitimate Resource Name or Location
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 |
|---|---|---|---|
| Enterprise | T1036.005 | Match Legitimate Resource Name or Location Sub-technique | This object detects Match Legitimate Resource Name or Location. |
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 | f47403f3b8f5… |
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 DET0347Open 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.