Analyzing and Detecting a VMTools Persistence Technique

Introduction

It is always fun to reexplore previously discovered techniques or pick back on old research that was put on the wayside in hopes to maybe finding something new or different. Recently, I stood up an ESXi server at home and decided to take a quick peak at the VMware directory structure after installing the VMware Tools (vmtools) package in a Windows 10 Virtual Machine.

Among the directory contents were some batch files that I forgot about and the very interesting binary – VMwareToolBoxCmd.exe. After some quick Googling, it did not take take long to land on Adam’s (@Hexacorn) incredible blog to find these two very informative post about VMwareToolBoxCmd.exe, OS fingerprinting, and a privileged persistence technique with VMware Tools:

In this quick post, we will analyze this persistence technique and discuss a few strategies for detecting potential abuse.

The Technique

As Adam describes, VMwareToolBoxCmd.exe is a utility command for capturing VM information or changing the configuration of various and sundry virtual machine settings. One feature is to control batch scripts that can be configured to run based on VM state operations including power (power on), shutdown (power off), resume (from suspended state), and and suspend (entering suspended stated) as noted in the command utilities script help subcommand:

There are several built-in batch scripts in the VMware Tools directory, but this does not preclude someone from using and enabling a custom script. For example, the following command script can be used to specify the execution of a custom script when the VM is powered on:

VMwareToolboxCmd.exe script power set "c:\evil\evilscript.bat"
VMwareToolboxCmd.exe script power enable

The command sequence itself is not as interesting as what it actually does. In the following Sysmon screenshot, we can see that content is actually written to the tools.conf file in \ProgramData:

Upon further inspection, the contents of this file appear as follows:

Coincidently, there is another operation for resume under the powerops section directive. This was added previously by me to show that 1) batch files are not the only thing that can be configured and 2) the tools.conf file is the key component what enables the script execution functionality.

Note: For a complete example of what a configuration file may look like, take a look at tools.conf.example in the same \ProgramData directory or this sample file in VMware’s open-vm-tools repository.

After a quick shutdown and power-on, we can see our batch file payload (notepad.exe) is executed by cmd.exe as a child process of vmtoolsd.exe under the context of NT AUTHORITY\SYSTEM:

Defensive Considerations

Consider the following detection opportunities:

Sysmon

For event collection with Sysmon, consider monitoring tools.conf write (modification) events with an experimental rule. The following rule can be added to @SwiftOnSecurity‘s Sysmon-Config under the EVENT 11: “File created” section or under @olafhartong‘s Sysmon-Modular “11_file_create” rules:

<TargetFilename>C:\ProgramData\VMware\VMware Tools\tools.conf</TargetFilename>

Elastic Security

I’ve been digging into the Elastic Stack in recent months and felt that it would be a great opportunity to build a simple rule in Elastic Security. Conveniently, Elastic was kind enough to implement a rule creation wizard. Leverage this by selecting Elastic Security in Kibana, navigating to “Rules”, then selecting “Create New Rule”:

I created this ‘custom’ rule based on the Event Query Language (EQL) of another rule [License: Elastic License v2]:

file where event.type != "deletion" and
file.path :
(
"C:\ProgramData\VMware\VMware Tools\tools.conf"
)

After walking through the wizard and enabling the rule, I modified the tools.conf file which triggered this alert:

Of note, the community can contribute to Elastic’s open-source Detection Rules repository. There is a set of instructions to leverage a Python utility to help with the creation and validation process (outlined here).

Other Detection Opportunities

*Environment: In some environments, it is very plausable that operational power scripts/commands may already be enabled for legitimate reasons. If such is the case, audit the tools.conf file for target scripts and monitor accordingly. Although custom scripts can be specified, the following (default) operational state scripts are included with VMware Tools (in the \VMware Tools directory) and may be worth monitoring:

• poweroff-vm-default.bat
• poweron-vm-default.bat
• resume-vm-default.bat
• suspend-vm-default.bat

*Hunt: As shown in a previous screenshot, the parent process for the launched process is vmtoolsd.exe. Consider monitoring or hunting for suspicious child processes. Additionally, monitoring for VMwareToolBoxCmd.exe command usage could be opportunistic in some environments.

Conclusion

As always, thank you for taking the time to read this post.

~ bohops