DET0005: Renamed Legitimate Utility Execution with Metadata Mismatch and Suspicious Path
This detection strategy matters because renamed legitimate utilities are a common way to make suspicious execution look routine. For leaders, the decision...
Analyst context for executives and security teams
This detection strategy matters because renamed legitimate utilities are a common way to make suspicious execution look routine. For leaders, the decision value is whether the organization can tell the difference between an approved system/admin tool and the same tool copied, renamed, or launched from an unusual location. That distinction affects SOC triage quality, incident response speed, and confidence in audit evidence around endpoint monitoring.
Executive priority
Prioritize this as a validation item for endpoint and SOC readiness, especially across Windows, Linux, and macOS environments where legitimate utilities are heavily used by administrators and automation. The business question is not simply “do we log process starts,” but “can we prove when a trusted utility’s name, metadata, or path no longer matches expected use?” Weak coverage can allow stealthy activity to blend into normal operations and delay incident decisions.
Technical view
DET0005 is a detection strategy for ATT&CK technique T1036.003, Rename Legitimate Utilities, under the stealth tactic. The object’s name indicates a focus on renamed legitimate utility execution where file metadata does not match the presented filename and the execution path is suspicious. SOC and detection teams should validate whether endpoint telemetry preserves process image path, original filename or comparable file metadata, command line, parent process, hashes, signer information, and user context. Because the official detection text is not provided, detections should be treated as locally engineered analytics aligned to this ATT&CK relationship rather than a MITRE-supplied rule.
Likely telemetry
- Process creation events with executable path and command line
- File metadata such as original filename, product name, description, and version information where available
- File hash and digital signature or signer details
- Parent-child process relationships
- User, host, and working-directory context
Detection direction
- Compare executable name and path against embedded metadata or equivalent platform-specific attributes where available.
- Look for known legitimate utilities executing from user-writable, temporary, staging, or otherwise unusual directories, while allowing for approved software deployment and administration paths.
- Tune detections with administrator tooling baselines to reduce false positives from packaging systems, portable tools, and legitimate renamed wrappers.
- Correlate suspicious renamed utility execution with parent process, user context, host role, and recent file creation to improve triage quality.
- Validate coverage separately for Linux, macOS, and Windows because metadata availability and logging semantics differ by platform.
Mitigation priorities
- Establish an inventory and baseline of approved administrative utilities, expected names, locations, and execution patterns.
- Restrict execution from user-writable or temporary paths where operationally feasible.
- Use application control or allowlisting policies for high-risk utilities and administrative tools where supported.
- Harden endpoint logging so process, file, signature, hash, and parent-process evidence is retained for investigation.
- Review SOC runbooks so renamed utility alerts are triaged using business context, approved admin activity, and recent change records.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy, not a technique description, and it has no official description or detection content in the provided fields. The strongest supported context is its relationship to T1036.003, Rename Legitimate Utilities, which is associated with stealth and Linux, macOS, and Windows. Recommendations here are therefore framed as validation and engineering direction, not as a guaranteed MITRE detection rule.
Platforms are not specified on DET0005 itself; platform references come from the related technique context. No official detection logic, data sources, mitigations, procedures, or examples were supplied. Local environment baselines are required to determine suspicious paths, expected utility names, and acceptable administrative exceptions.
Renamed Legitimate Utility Execution with Metadata Mismatch and Suspicious Path
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.003 | Rename Legitimate Utilities Sub-technique | This object detects Rename Legitimate Utilities. |
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 | e99b08d5539b… |
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 DET0005Open 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.