Rename Legitimate Utilities is ATT&CK T1036.003, a Stealth technique for Linux, macOS and Windows. The attacker takes a tool that is already on the box, or one that security teams know well, and gives it a different name so that rules keyed on the original name stop matching.
How attackers use it
MITRE describes two cases. In the first, security monitoring or control exists for legitimate utilities an adversary can abuse. These include built-in binaries and tools such as PsExec, AutoHotKey and IronPython. Renaming the utility, for example rundll32.exe, may get around those controls.
In the second, a legitimate utility is copied or moved to a different directory and renamed, so that detections based on the tool running from a non-standard path do not fire.
The procedure examples on the page are specific. One group moved and renamed a script to a .txt file. Another renamed rundll32.exe and mshta.exe. A third used a renamed copy of rundll32.exe in a ProgramData subfolder to proxy DLL execution. One malware family copied and renamed the Windows curl command into a randomly named folder at the root of the C drive.
How to detect it
The MITRE detection strategy is built around a metadata mismatch plus a suspicious path:
- Windows: execution of binaries where the file name on disk does not match PE metadata such as OriginalFilename or InternalName. This is common with renamed living-off-the-land binaries and with tools like PsExec.
- macOS: renamed or relocated native utilities with uncommon names or non-default paths, such as renamed osascript, bash or curl.
- Linux: renamed common utilities such as bash, nc, python or sh run from atypical directories or under names meant to mislead defenders.
The practical takeaway: log the original file name from the binary's own metadata next to the name on disk, and the full path. A rule that says rundll32 should only run from System32 is much stronger when it keys on the original file name rather than the current one.
How to reduce the risk
MITRE lists one mitigation, restrict file and directory permissions. Use file system access controls to protect folders such as C:\Windows\System32 so that ordinary accounts cannot place or rename binaries there.
Beyond that, application control that decides by signer or hash rather than file name takes away much of the benefit of renaming. That follows from the technique itself, not from a specific MITRE statement, so treat it as a design suggestion.
Check your own environment
On Windows PowerShell, compare each running executable's file name with the name stored in its version info:
Get-Process | Where-Object { $_.Path } | ForEach-Object {
$v = (Get-Item $_.Path).VersionInfo
[pscustomobject]@{ Name = $_.ProcessName; Path = $_.Path; Original = $v.OriginalFilename }
} | Where-Object { $_.Original -and ($_.Original -notlike "$($_.Name)*") }
Expect some benign results. Look for system tool names running from unusual folders, or system tools running under other names.
Quick check
Why does a path-based rule still miss a renamed utility copied to another folder?
If the rule says a tool is fine only in its normal folder, or suspicious when it runs from elsewhere, copying and renaming it can make it match neither the name nor the path the rule expects. Checking the original file name in metadata or the hash closes the gap.
