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 #10
overall rank
8.4%
customers affected
250
threats detected
Threat Sounds
We can imagine adversaries humming this when deciding what to rename the system utilities they’re abusing. RiRi.exe would probably not blend in very well.
Analysis
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 often 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 or perform some combination of renaming and relocating the system binary. 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.
The following are the top 10 most commonly renamed utilities detected by Red Canary in 2023:
cmd.exerundll32.exemsbuild.execertutil.exevncviewer.exewscript.exe7zip.exeadexplorer.exeprocdump.exepsexec.exe
In past years, other commonly renamed utilities have included mshta.exe, utilman.exe, and regsvr32.exe.
Associated threats
take action
There’s no simple way to prevent an adversary from changing the outwardly presented name of a system utility, but if you redefine the way you identify system binaries—i.e., identify them based on binary metadata rather than filenames—then it’s effectively impossible to actually rename an operating system utility. As such, the best mitigatory guidance for this technique is contained in the detection section below.
However, some general best practices for investigating renamed system utilities include examining surrounding:
- parent and child processes and suspicious process access
- module loads
- network connections
- file writes or modifications (particularly the source of the renamed utility)
Visibility
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.
Command execution
The contents of commands may also contain evidence suggesting or directly showing that an adversary has renamed a system utility.
Collection
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.
Endpoint Detection and Response (EDR) tools
Most EDR tools will collect the requisite binary metadata required to uncover the true identity of a renamed system utility.
Detection opportunities
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.
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. Years 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. Also, notepad.exe is an arbitrary example here that could just as readily be any number of other executables.
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, tweetProcess 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
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
C:\Windows\Temp\notepad.exe -e JgAgACgAZwBjAG0AIAAoACcAaQBlAHsAMAB9ACcAIAAtAGYAIAAnAHgAJwApACkAIAAoACIAVwByACIAKwAiAGkAdAAiACsAIgBlAC0ASAAiACsAIgBvAHMAdAAgACcASAAiACsAIgBlAGwAIgArACIAbABvACwAIABmAHIAIgArACIAbwBtACAAUAAiACsAIgBvAHcAIgArACIAZQByAFMAIgArACIAaAAiACsAIgBlAGwAbAAhACcAIgApAA==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:
| Visibility | Telemetry | Collection |
|---|---|---|
| Visibility: Process monitoring | Telemetry: A | Collection: EDR and Sysmon Event ID 1 should collect relevant telemetry. |
| Visibility: Command monitoring | Telemetry: Command-line logging will capture the context of what is executed. | Collection: EDR and Sysmon Event ID 1 should collect relevant telemetry. |
| Visibility: Binary file metadata | Telemetry: The running notepad.exe executable will have a VERSIONINFO resource embedded within it indicating an | Collection: EDR and Sysmon Event IDs 1 and 11 should collect relevant telemetry. |
| Visibility: File monitoring | Telemetry:
| Collection: 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.