technique T1036.003

Rename System Utilities

A behavior that’s inherently suspicious in the context of one process can be completely normal in the context of another, which is precisely why adversaries rename system utilities to throw defenders off.

Pairs with this song


Sub-technique rank


Percent of customers affected


Total threat volume

Analysis Icon


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:

  • cmd.exe
  • mshta.exe
  • wscript.exe

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 mshta.exe.

Visibility icon



Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.

From a high level, detection or prevention of renamed system utilities requires two things: you must be able to observe suspicious behaviors independent of their origin and you must be able to recognize the true identity of any given system utility. Optics relating to processes, their metadata, and file creation—much of which are available through native log sources, EDR, and other security products—are critical for gaining visibility into renamed system utilities.

Process monitoring

At a minimum, you’ll need to track process execution if you want to have visibility into the execution of renamed processes.

Process metadata

Third-party tooling or native logging features that offer access to process metadata (e.g., process names, internal names, hashes, etc.) are among the most effective data sources for observing or identifying renamed system utilities. This telemetry is a must-have for investigations, where you can inspect the metadata for a given file to see if anything is amiss, but it’s also useful for detection.

File monitoring

Sometimes seeking out renamed or relocated binaries involves looking at executables running from unusual directories. In these cases, file monitoring may offer visibility that you can use to develop detection analytics.

Collection Icon



Note: The collection sections of this report showcase specific log sources from Windows events, Sysmon, and elsewhere that you can use to collect relevant security information.

Sysmon Event ID 1: Process creation

Sysmon process start events (Event ID 1) are a fantastic collection method for detecting renamed system utilities. The key event fields that are exposed to enable detection are Image and OriginalFileName. OriginalFileName is a binary attribute that an adversary is unlikely to modify and can be compared against the filename on disk present in the Image field.

Icon-threat detection


Perhaps the most effective method for finding renamed system utilities is to compare the name embedded directly into the binary file (i.e., its internal name) with its externally presented name and generate alerts whenever those two names are different or deviate from what is expected. You can also compare expected process paths to the actual process paths—basing expected paths on what is normal for the binary given its internal name—to detect relocated system binaries that have not been renamed.

Our detection guidance for finding renamed system utilities can be categorized into four basic groups that reliably offer insight into the true identity of a binary:

  • known process names
  • paths
  • hash values
  • command-line parameters

We published a blog in 2021 describing how you can profile System32 binaries, collect and store their expected metadata, and use the information to build detection analytics for masquerading and DLL Search Order Hijacking. Nearly a year later, we still stand by this article as a resource for detecting renamed or relocated binaries. However, also take into account the following high-level advice to detect deviations from what is known or expected.

Unexpected internal process name or hash

Consider alerting on any activity where the apparent process name is different from the internal process name or where the apparent process name executes with an unexpected hash value. While process names may change, the hash values and internal names associated with them should not. This is easier said than done, and requires the ability to collect internal names or hash values for System32 binaries and actively cross reference that list with active process execution. As an example, the internal name for powershell.exe is “PowerShell,” and its known process names include powershell.exe, powershell, posh.exe, and posh. As such, the following pseudo-analytic is an example of how you might catch renamed instances of PowerShell. You could swap out Notepad or PowerShell for any other commonly renamed system utility.

process_name == notepad.exe
internal_name == PowerShell
hash_value != [expected hash value for PowerShell in your environment]*

*Note: There are dozens of different hashes for different versions of PowerShell.

The following test demonstrates renaming cmd.exe to notepad.exe in an attempt to evade naive detection logic that expects cmd in the process command line:

copy %comspec% %CD%\notepad.exe
notepad.exe /c echo tweet, tweet

Process is executing from an unusual file paths

Consider alerting on any activity where a process path does not match a list of known process paths given an internal name. As an example: the known expected process path associated with cscript.exe (based on its internal name) should be system32, syswow64, and winsxs.

Processes executing with unusual command lines

Consider detecting any apparent processes executing in conjunction with command-line parameters that are generally associated with a different process. As an example, Invoke-Expressions (iex) are associated with PowerShell, so it would be highly suspicious to see an invoke expression in a command line associated with a process that appears to be something other than PowerShell. For example:

process != powershell.exe
command_line_includes ('iex' || 'invoke-expression')*

*Note: This is an extremely limited example that would almost certainly require extensive tuning.

Weeding out false positives

Looking for process names (e.g., regsvr32.exe) outside of expected paths will generate false positives because many software developers bundle specific versions of a system process. For example, we often run into false positives on rundll32’s unexpected paths for certain antivirus software. Identify any tools that exhibit this behavior and add them as exclusions to your toolset.

Because anyone can name a process whatever they want, you might see false positives on process names that are not the actual system utility. Cross reference internal name information to avoid tripping on a random process named rundll32 instead of the real rundll32 that was relocated or renamed.

Testing Icon


Start testing your defenses against Rename System Utilities using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.

Getting started

View atomic tests for T1036.003: Rename System Utilities. In most environments, these should be sufficient to generate a useful signal for defenders.

Run this test on a Windows system using Command Prompt:
copy C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe C:\Windows\Temp\notepad.exe


What to expect

The above test will execute an encoded PowerShell command while masquerading as notepad.exe.

Running it will print “Hello, from PowerShell!” to the terminal. Decoded, the command runs the following obfuscated PowerShell code:

& (gcm ('ie{0}' -f 'x')) ("Wr"+"it"+"e-H"+"ost 'H"+"el"+"lo, fr"+"om P"+"ow"+"erS"+"h"+"ell!'")

Deobfuscated, it is equivalent to the following:

Invoke-Expression "Write-Host 'Hello, from PowerShell!'"
Useful telemetry will include:

Process monitoring


A notepad.exe process will start which is a masqueraded version of powershell.exe.


EDR and Sysmon Event ID 1 should collect relevant telemetry.


Command monitoring


Command-line logging will capture the context of what is executed.


EDR and Sysmon Event ID 1 should collect relevant telemetry.


Binary file metadata


The running notepad.exe executable will have a VERSIONINFO resource embedded within it indicating an OriginalFilename of PowerShell.EXE.MUI. This data point can be used to indicate that notepad.exe is a deviation from the expected powershell.exe filename.


EDR and Sysmon Event IDs 1 and 11 should collect relevant telemetry.


File monitoring


powershell.exe will be copied to C:\Windows\Temp\notepad.exe. Under normal conditions, PowerShell should not execute from the C:\Windows\Temp directory under typical conditions.


EDR and Sysmon Event ID 11 should collect relevant telemetry.

Review and repeat

Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:

  • Were any of your actions detected?
  • Were any of your actions blocked or prevented?
  • Were your actions visible in logs or other defensive telemetry?

Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.