Detect them by hashing executables and comparing the hash to a known set of authorised binaries, regardless of file name. This catches copies that have been renamed to look legitimate or evade simple name-based rules. Pair hash checks with path, signer, and process lineage so an unchanged binary with a new name or location is still flagged.
Why hash-based matching catches renamed executables
File names are easy to change, but a binary’s hash usually changes only when the file content changes. That makes hashing useful for identifying the same executable even after it has been renamed, copied to a different folder, or wrapped in a new path. The key idea is to compare the hash against a trusted allowlist of authorised binaries, not against the file name.
That works because a rename does not alter the executable bytes. If a malware sample, rogue admin tool, or copied utility is trying to blend in by looking like a legitimate program name, the hash comparison still exposes the underlying binary identity. In practice, the hash becomes the content fingerprint, while the name is treated as just one observable attribute.
This is most useful when the file is stable enough to hash consistently. If the file is repacked, recompiled, or modified, the hash changes and the comparison may no longer identify it as the same binary. For that reason, hash matching is strongest when you are working from a curated inventory of known-good executables, installer payloads, or approved tooling images.
Why name-only checks fail in real environments
Name-based rules are brittle because attackers and even careless operators can reuse trusted-looking filenames to bypass simple detection logic. A renamed executable can still launch the same malicious payload, inherit the same embedded functionality, or continue using the same abuse path, while passing a rule that looks only at the process name.
Hash comparison closes that gap by anchoring detection to the file’s content rather than its label. This is especially valuable in environments where copied tools, portable utilities, or staged binaries are common. A file called svchost.exe is not trustworthy just because it has a familiar name, and a benign tool with an odd name is not automatically suspicious if its hash matches an approved binary.
For operational use, the practical question is not “Does the filename look right?” but “Is this exact executable content one I expect here?” That shift matters because it helps separate legitimate renames from deliberate disguise.
Make hash matching more reliable with path, signer, and lineage
Hashing is a strong first filter, but it should not stand alone. The same binary can be legitimate in one location and suspicious in another, so pairing the hash with the file path helps identify unexpected placement. Adding signer verification helps confirm whether the binary was produced by a trusted publisher and whether it has a valid signing chain.
Process lineage adds another layer of context. If an authorised binary appears under a new name but is spawned by an unusual parent process, launched from a user-writable directory, or injected into a suspicious execution chain, the event deserves escalation even when the hash is known. That combination is what turns a simple hash hit into a meaningful detection outcome.
In defensive workflows, hash, path, signer, and lineage should be treated as complementary signals. A matching hash should not automatically clear the event, and a non-matching hash should not be the only reason to investigate. The full context tells you whether you are seeing approved software, a renamed copy, or a binary being used outside its normal trust boundary.
Risk and Threat Considerations
Renamed executables are a common disguise technique because they exploit weak detection logic, especially where teams rely on filename allowlists or simple process-name rules. The risk is not just evasion, it is mistaken trust, where a malicious or unauthorised binary is allowed to run because its label looks familiar.
Failure mechanism: The attacker or operator renames a binary, places it in an unexpected path, or launches it through an unusual parent process, while the file content remains unchanged enough to preserve the same hash or to imitate an approved one closely enough for weak controls to miss it.
Impact: Security teams may miss initial execution, misclassify the process as legitimate, or lose time while triaging an event that should have been obvious from content-based matching and execution context. That can delay containment and allow further abuse of the system.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1036 — Masquerading | Renamed executables are a classic masquerading pattern. |
| Recommendation — Map renamed binaries to T1036 and alert on deceptive process naming or placement. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Hash checks verify executable integrity against trusted software inventories. |
| Recommendation — Verify executable hashes before execution and compare them to trusted baselines. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Software inventory and allowlisting depend on identifying approved binaries by content, not name. |
| Recommendation — Maintain a software allowlist keyed to approved hashes and review unexpected binaries. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | Unexpected renamed binaries are detectable as anomalous execution events. |
| Recommendation — Monitor process execution for hash, path, and lineage anomalies. | ||
Practitioner Guidance
What to verify: Validate hashes against a curated authorised-binary inventory, then confirm the file path, publisher signature, and parent-child process relationship before clearing the event. A single matching hash is useful, but it is not enough to prove the executable is expected in that context.
Common mistake: Do not tune detections to filename patterns alone. If your rule can be defeated by copying the same binary under a new name, it is not robust enough for environments where tools, malware, and admin binaries are routinely reused or repackaged.
Practitioner takeaway: Treat the hash as the binary’s identity and the filename as only a clue. The strongest detections combine content, location, signer, and lineage so that a renamed executable still stands out when it appears where it should not.
Related resources from NHI Mgmt Group
- Guide: EDR Evasion and Defence Guide
- Why do behavior-based Sigma rules usually detect malware more reliably than rules built only on file hashes or IP addresses?
- How do you detect Encrypting File System RPC abuse such as PetitPotam on Windows?
- How do you detect suspicious OAuth app file download activity in Microsoft 365?
- How do you detect DNS queries to file sharing sites such as MEGA used for exfiltration?