Another Persistence Method Reported Overnight On Twitter? How Tanium Can Help

Registry configurations designed to be used for troubleshooting and development are now a means of covert persistence due to the lack of visibility by security tools like Autoruns. Here, we highlight three key ways Tanium modules, including Trace and Detect, can be used to rapidly determine the existence of this relatively unknown persistence mechanism.

(Image: Bruno Glätsch / Pixabay)

What do you do when you see a new persistence method reported overnight on Twitter? One idea: Use Tanium to quickly review any current activity and configure rapid alerting when it happens. All before breakfast.

On April 10, Oddvar Moe (@oddvarmoe) took to Twitter to share his blog post, Persistence Using Globalflags in Image File Execution Options – Hidden from autoruns.exe, which discusses a persistence mechanism via registry configuration that silently executes a process following the termination of another “watched” process. This method is not currently included in the persistence locations enumerated by Sysinternals Autoruns from Microsoft.

The use of Global Flags gives developers a means of launching a process after another process has terminated. This represents a blind spot currently, due to the fact that Autoruns doesn’t enumerate these configurations. They are either set through the use of the gflag.exe, a utility found in the developers tools from Microsoft, or can be done with changes to the registry by an administrator account.

Unless a machine is being used for troubleshooting or for development work, the existence of these registry configurations are highly suspect and should be investigated. This will be done below, and serves as an example scenario demonstrating how rapidly you can take newly disclosed details and evaluate your own environment.

Here, we highlight how Tanium modules, including Trace and Signals, can be used to rapidly determine the existence of this relatively unknown persistence mechanism in three key ways:

• By looking at the current state of registry settings;
• By examining the history of registry changes with Trace; and
• By establishing real-time alerting for changes to these registry settings in the future.

About the issue

Moe’s blog post points out three registry modifications that establish an execution trigger which launches a process whenever a monitored process terminates. What’s more, when the monitored process terminates, the second process is launched silently. Meaning if there is a graphical interface, it launches in the background. Attackers can use this feature as a means of maintaining persistence; having their code execute following the termination of a process of their choosing until the registry keys are removed.

Details of this Windows feature are documented by Microsoft here.

For testing, the script below makes the registry modifications that cause evil.exe to run any time notepad.exe terminates.

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe” /v GlobalFlag /t REG_DWORD /d 512 reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe” /v ReportingMode /t REG_DWORD /d 1 reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe” /v MonitorProcess /d "C:\temp\evil.exe"

Current activity

Looking for signs of this technique already in use across the enterprise is possible via Tanium.

There may be legitimate uses of this technique in some environments, so careful review should be undertaken to determine if existing configurations are malicious or benign. One starting point is looking for the SilentProcessExit registry hive. In most environments this should be an empty or non-existent key. Three sensors will be used for this investigation:

1. Registry Key Subkeys – This shows any processes that trigger execution upon their termination. Figure 1, below, shows “notepad.exe” as the only subkey under SilentProcessExit.
2. Registry Key Value Names – This shows which subkeys exist. Figure 1 shows MonitorProcess and ReportingMode as the two Registry Value Name entries.
3. Registry Value Data – This data shows the process configured to launch when the monitored process terminates. Figure 1 shows the data for the two entries.

Figure 1: Example entry used for testing in this article.

In Figure 2, below, the Tanium Registry Key Subkeys sensor shows the notepad.exe subkey entry under the SilentProcessExit key.

Figure 2: Searching for SilentProcessExit using the Registry Key Subkeys sensor.

Sensor: Registry Key Subkeys Registry Key Subkeys[HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit] from all machines

For any subkeys returned by the Registry Key Subkeys sensor, investigators should copy the KeyPath value and use it as a parameter to the Registry Key Value Names sensor to verify that a MonitorProcess entry exists (see Figure 3). If a MonitorProcess entry exists, the ReportingMode entry should be present as well.

Figure 3: Registry Key Value Name sensor used to discover subkeys.

Sensor: Registry Key Value Names Registry Key Value Names[HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe] from all machines

To determine which process will execute for a given MonitorProcess entry, both the KeyPath value from the Registry Key Subkeys output and the Value Name from the output of the Registry Key Value Names sensor should be provided as parameters to the Registry Value Data sensor (see Figure 4).

Figure 4: Registry Value Data sensor output.

Sensor: Registry Value Data Registry Value Data[HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe,MonitorProcess] from all machines

Using the KeyPath and Value Name from the sensor output as parameters to the Registry Value Data sensor, we see the data entry for this MonitorProcess including the path to where the process is stored on disk in Figure 4.

We also see in Figure 4 an example of hiding a process binary inside an Alternate Data Stream (ADS). ADS is a feature of the NTFS file system, which attackers can use to embed binaries so they are not seen in Windows Explorer or in normal directory listings via cmd.exe and PowerShell.exe. Notice the “:” present in the process binary name.

Our hidden executable is embedded inside the folder or NTFS directory entry, C:\Windows and has been named “cmd.exe”.

Past activities

With Tanium sensors, it is possible to search these specific registry locations across hundreds of thousands of endpoints in a matter of seconds.

But what if the registry entries were removed following the initial activity? They won’t show up with the “current state” sensors shown above. To search historical data across the enterprise, we’ll have a look at the registry using Tanium Trace data.

We start by inspecting the SilentProcessExit Registry key to see if any SetRegistryKey events have been recorded (See Figure 5).

Figure 5: Trace Registry Keys of Values sensor output.

Sensor: Trace Registry Keys or Values Get Trace Registry Keys or Values[unlimited, 1523639748493|1523643347493, 0, 0, 10, 0, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit, , SetValueKey, , , ] from all machines

The “key” column contains an entry for the executable that, when terminated, will cause the MonitorProcess executable to launch. The expanded key column data is: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe

Since Trace doesn’t record Value Data, we know at this point a process was configured to trigger another process but not where that process is located. However, we can open a Live Connection via Trace and have a look.

Alerting

In addition to searching the current state and historical data of the enterprise, a Tanium Detect Signal can provide real-time alerts when these registry keys are configured in the manner described above.

group(Registry.key_path contains '\\SilentProcessExit\\' AND Registry.value_name contains 'MonitorProcess’)

With this Signal deployed, whenever any process establishes persistence under the SilentProcessExit key by creating a MonitorProcess entry, a real-time alert will fire in the Tanium Detect interface and these alerts can be forwarded to SIEM or notification systems.

As with any Tanium Detect alert, you can select the alert and pivot into a Trace Live Connection to investigate the activity further (see Figure 6). Here, we see the process activity in detail. In this instance, our malicious process is again embedded as an ADS, but this time in a C:\System directory entry.

Figure 6: Signals alert and option to establish a live connection with Trace.

Next, we see the process tree view in Trace (see Figure 7). Of note, the parent process of the malicious process is WerFault.exe, the Windows Error Reporting service. Also note the malicious process launches under the same user account context and not as SYSTEM.

Figure 7: Process Visualization within Trace.

The process hash is highlighted in red indicating that the Tanium Reputation service has classified this file as malicious.

Now, we can take the hash and file specifics and move to Tanium Protect to block future execution of this process. We can also clean up the registry and kill any existing processes using standard Tanium actions.

Example Signals

Below, we can see Tanium Detect Signal alerts corresponding to various ways of enabling this persistence mechanism (see Figures 8-13).

Figure 8: Signal alert when adding the MonitorProcess entry via batch file.

Figure 9: Signal alert when adding the GlobalFlag entry with a batch file.

Figure 10: Signal alert for adding the MonitorProcess entry manually using the Regedit.exe GUI.

Figure 11: Signal alert when using PowerShell to modify the registry.

Figure 12: Registry file with configuration changes.

Figure 13: Merging the registry file from Figure 12 generated this alert.

One other note. An IOC alert will display the ADS in the details view, including hash color enrichment, as shown in Figure 14.

Figure 14: An IOC scan hit for the binary based on the hash.

Summary

The process outlined in this article shows how Tanium can rapidly determine the existence of a relatively unknown persistence mechanism by looking at the current state of registry settings, by examining the history of registry changes with Trace, and finally establishing real-time alerting for changes to these registry settings in the future. If you’d like to learn more, join me in the Tanium User Community and let’s discuss.

Interested in seeing Tanium in action? Schedule a one-to-one demo or attend our weekly webinar. Talk to our Tanium experts at our upcoming events.

About the Author: Scott Langendorf is a Director on the Tanium EDR team. He joined Tanium in fall 2015 after having been Senior Manager at a global engineering corporation under attack by nation-state groups. With eight years of experience in cybersecurity, Scott joined Tanium to help advance security products, recognizing the importance of rapid endpoint visibility, alerting and data agility for defense and hunt teams. He has also worked at NASA on the Space Station electrical power system and as an IT manager in the energy sector when APT1 was just being discovered.