AN0012: Analytic 0012
Execution of binaries where the on-disk filename does not match PE metadata such as OriginalFilename or InternalName. Often observed with renamed LOLBAS or system binaries like rundll32, powershell, or psexec.
Analyst context for executives and security teams
This analytic focuses on a practical Windows defense problem: binaries that execute under a filename that does not match their embedded PE metadata, such as OriginalFilename or InternalName. For leaders, the value is in finding cases where trusted or common tools may have been renamed, including examples such as rundll32, powershell, or psexec. That matters because renamed system or LOLBAS-style binaries can complicate triage, weaken allow/deny assumptions based only on file path or filename, and delay incident response decisions.
Executive priority
Prioritize this as a control-validation and SOC-readiness question for Windows environments: can the organization compare what a process is called on disk with what the executable metadata says it is? This supports incident decision-making, audit evidence for endpoint monitoring maturity, and budget prioritization for endpoint telemetry quality. Because no ATT&CK tactic, relationship context, or official detection logic is supplied, this should be treated as a detection engineering coverage check rather than a standalone risk conclusion.
Technical view
SOC and detection teams should validate whether Windows endpoint telemetry captures process execution events with image path, on-disk filename, and PE metadata fields such as OriginalFilename and InternalName. Detection logic should look for mismatches between the executed filename and PE metadata, with particular attention to renamed system or LOLBAS-style binaries referenced by MITRE, such as rundll32, powershell, or psexec. Tuning is required because legitimate software packaging, updaters, copied admin tools, or enterprise scripts may produce metadata/name mismatches. Since MITRE provides no official detection procedure and no relationships, local baselining is essential.
Likely telemetry
- Windows process execution telemetry
- Executable image path and on-disk filename
- PE metadata fields, especially OriginalFilename and InternalName
- Endpoint detection and response process metadata
- File inventory or executable metadata collection where available
Detection direction
- Confirm that endpoint telemetry includes both the executed filename and PE metadata; filename-only process logs are not sufficient for this analytic.
- Build or validate logic that compares the on-disk filename to OriginalFilename and InternalName values in the PE header.
- Baseline legitimate filename-to-metadata mismatches in the environment before alerting broadly.
- Review mismatches involving common system or administration binaries referenced by MITRE, including rundll32, powershell, and psexec.
- Tune for false positives from software installers, renamed administrative utilities, application packaging, and scripted operations.
Mitigation priorities
- Ensure Windows endpoint logging or EDR configuration captures process execution and PE metadata needed for comparison.
- Reduce reliance on filename or path alone when designing allowlists, blocklists, and triage rules.
- Establish a known-good baseline for approved administrative tools and software that may be renamed or copied.
- Document detection coverage and tuning decisions as evidence for SOC readiness and compliance-oriented monitoring reviews.
- Use incident response playbooks that require analysts to inspect binary metadata, execution context, and provenance when renamed binaries are observed.
Analyst notes and limits
The supplied object is a detection analytic for Windows and describes execution of binaries where the on-disk filename does not match PE metadata. It cites renamed LOLBAS or system binaries as common examples. No tactic, official detection text, labels, aliases, or relationship context were supplied, so this take frames the object as a detection engineering and telemetry validation opportunity rather than a complete ATT&CK technique narrative.
This assessment is limited to the official STIX fields, external reference, and supplied relationship context. No official detection logic, mitigations, ATT&CK tactic mapping, related techniques, or evidence of active exploitation were provided. Local environment telemetry and baselines are required to determine practical detection quality and alert severity.
Analytic 0012
Execution of binaries where the on-disk filename does not match PE metadata such as OriginalFilename or InternalName. Often observed with renamed LOLBAS or system binaries like rundll32, powershell, or psexec.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | c4ea21f5a339… |
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 AN0012Open 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.