Why do adversaries rename system utilities?
Adversaries rename system utilities to circumvent security controls and bypass detection logic that’s dependent on process names and process paths. Renaming system utilities allows an adversary to take advantage of tools that already exist on the target system and prevents them from having to deploy as many additional payloads after initially gaining access.
Renaming a system utility allows the adversary to use a legitimate binary in malicious ways—while adding layers of confusion to the analytical process. For example, a behavior might be inherently suspicious in the context of one process name but completely normal in the context of another. Therefore, adversaries would seek to cloak their suspicious behaviors inside the context of a non-suspect process name.
For example, if
notepad.exe never makes network connections, then it would be trivial to detect an adversary using that process to reach out to an external IP address and pull down a payload. However, if you rename that process to
chrome.exe, then an external network connection and file download would be seemingly innocuous.
How do adversaries rename system utilities?
There isn’t much variance in the ways that adversaries rename system utilities. They either rename the binary, relocate it, or perform some combination of renaming and relocating. The technique often follows a predictable pattern: the initial payload (e.g., a malicious script or document) copies a system binary, gives it a new name, and, in some cases, moves it to a new location before using it to execute additional payloads, establish persistence, or perform other malicious actions.
Note: Whether renaming or relocating, the adversary does not change the binary metadata associated with the utility. An adversary who manipulates binary metadata is effectively introducing an arbitrary, non-native binary, which is outside the scope of this technique.
Some commonly renamed utilities include the following:
While there are numerous other examples of binaries that adversaries may choose to rename, this analysis focuses on the small handful we observed most often throughout the year.
We detect renamed versions of
cmd.exe more often than any other binary, by a wide margin. As is nearly always the case, adversaries rename
cmd.exe to circumvent detection techniques that look for the explicit execution of that process. Though we see less of it, adversaries also rename
wscript.exe for precisely the same reason, and they frequently move
wscript.exe into a directory that isn’t
system32 when they do so. Last and also least frequently, we’ve also known adversaries to rename