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.


Parent technique rank


Organizations affected


Confirmed threats


Why do adversaries use Rename System Utilities?

Adversaries rename system utilities to circumvent security controls and bypass detection logic dependent on process names and process paths. Renaming or moving 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.

From a very 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.

How do adversaries Rename System Utilities?

Adversaries either rename system binaries, relocate them, or perform some combination of renaming and relocation. Employment of this technique often follows a similar pattern: an initial payload (e.g., a malicious script or document) copies or writes a renamed or relocated system binary, which is then used to execute additional payloads and/or establish persistence.

In 2020, we observed adversaries renaming AdFind, an open source tool that extracts information from Active Directory. Microsoft reported that the adversaries behind Solorigate used a renamed version of AdFind for domain enumeration. The following example provided by Microsoft shows AdFind renamed as csrss.exe in an apparent attempt to masquerade as the Client Server Runtime Subsystem process, as this command identifies domain administrators. Interestingly, this example shows “double masquerading”—both renaming the utility as well as choosing a name that mimics a different legitimate process.

C:\Windows\system32\cmd.exe /C csrss.exe -h breached.contoso[.]com -f (name=”Domain Admins”) member -list | csrss.exe -h breached.contoso[.]com -f objectcategory=* > .\Mod\mod1.log

As we recommend in our Bazar blog post, looking for any use of adfind.exe may help you find adversaries in your environment. If that’s too noisy, looking for a renamed adfind.exe file can be a useful detection strategy to identify threats.

The operators of Egregor ransomware also used this technique in 2020, with a different system utility. These operators renamed psexec.exe as pse.exe and used it to redirect rundll32.exe to load a malicious DLL file (b.dll in the below example):

"C:\WINDOWS\pse.exe" -n 5 \\[redacted].0.0.0 -s rundll32.exe C:\WINDOWS\b.dll,DllRegisterServer -passegregor[####]



Collection requirements

Process metadata

Third-party tooling or native logging features that offer access to process metadata (e.g., process names, internal names, known paths, etc.) are among the most effective data sources for observing or identifying renamed system utilities.

Most of our confirmed threat detections relating to renamed system utilities involve adversaries renaming known system binaries. 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.

Detection opportunities

Our detection guidance for finding renamed system utilities can be categorized into four basic control groups that reliably offer insight into the true identity of a binary: known process names, paths, hash values, and command-line parameters. To detect deviations from what is known or expected, consider the following.

For known process names: Consider alerting on any activity where the process name does not match a list of known process names given an internal name. As an example, the internal name for powershell.exe is PowerShell, and its known process names include powershell.exe, powershell, posh.exe, and posh.

For known process 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.

For known hash values: While process names may change, the hash value associated with them should not. Therefore, if you have a list of matching hash values in an environment, consider alerting on or examining any that have a different process name. Since adversaries typically copy binaries that are already on disk, a renamed system utility should have the same hash as the original. You can find these deviations by investigating the suspect hash and reviewing observed paths.

For known command-line parameters for system processes: Considering 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.

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.


Getting Started With Atomic Red Team

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:
Data sourceTelemetry
Data source:

Process monitoring


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

Data source:

Process command-line parameters


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

Data source:

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.

Data source:

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.

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.

Brian Donohue
Sr. Information Security Specialist
Brian has been writing about and researching information security for the last decade. He started his career as a journalist covering security and privacy. He later consulted as a threat intelligence analyst, researching adversaries and techniques for a variety of major banks, retailers, and manufacturers. At Red Canary, Brian helps guide research publication and technical messaging efforts.
Brian has been writing about and researching information security for the last decade. He started his career as a journalist covering security and privacy. He later consulted as a threat intelligence analyst, researching adversaries and techniques for a variety of major banks, retailers, and manufacturers. At Red Canary, Brian helps guide research publication and technical messaging efforts.