Automated Clean-up of HAFNIUM Shells and Processes with Splunk Phantom

If you haven’t been living under a rock for the past few weeks, you've probably come across the recent Microsoft Exchange Server vulnerabilities and its associated exploits.

We’ve released a couple of blogs on this topic, concentrated on two things:

1. Detecting HAFNIUM Exchange Server Zero-Day Activity in Splunk: Explaining the vulnerabilities and associated exploits
2. Detecting Microsoft Exchange Vulnerabilities - 0 + 8 Days Later…: Sharing SPL to detect and hunt for malicious behavior withrelated to the exploits and detections you can use with Splunk Enterprise Security
    

Stop!!! The first thing you should do is to go and patch any Exchange servers you may be running, then you can come back and finish reading this blog. Microsoft's blog provides links to various tools to help in this regard.

Ok, so depending on how many Exchange servers you needed to patch, this may take hours, days, or months. No matter your situation, here are some tips and strategies that can help.

Delete Exchange Webshells Automatically with Splunk Phantom

As we were running through our tests of the exploit, I found myself continually removing webshells that were created during exploitation. As you can see in Figure 1, I got a bit lazy and forgot to delete a number of them! Can you imagine if this were a production server?

^{Figure 1: Remnants of webshells}

I said to myself, “Wouldn’t it be nice if there was a way to remove these webshells when they are detected?”. Yes, it would be; and I'm going to demonstrate how this can be done with Splunk Phantom, Splunk's security orchestration, automation, and response solution!

I built the following playbook to help combat these annoying webshells that kept popping up on my Exchange server.

In this example, I started by implementing one of our recent Splunk Enterprise Security Content Update (ESCU) detections (Detect Exchange Web Shell) created by the Splunk Threat Research team that detects the creation of webshells in the affected locations. These detections are bundled into the HAFNIUM Group analytic story within ESCU, shown in Figure 2.

^{Figure 2: HAFNIUM Group Analytic Story from ESCU}

I then enabled the Send to Phantom Adaptive Response Action (requires the Splunk Add-on for Phantom to be installed on your Splunk instance) in the Enterprise Security correlation search, shown in Figure 3.

^{Figure 3: Send to Phantom Adaptive Response action for Detect Exchange Web Shell}

After saving the correlation search and enabling it, I kicked off the exploit against my Exchange server, shown in Figure 4. Yes, I obfuscated my details, so you can’t see my stuff!

^{Figure 4: Running the Exchange server exploit}

The webshell (lfete.aspx) dropped into the owa/auth directory as shown in Figure 5.

^{Figure 5: The webshell created from the exploit run in Figure 4}

The detection picked up the webshell being written, and sent this event to Phantom, shown in Figure 6.

^{Figure 6: Detect Exchange Web Shell event created in Phantom}

With the event now being sent to Phantom, let’s look at the simple but effective playbook I wrote to gather the relevant information from the event and then delete the webshell, shown in Figure 7. The two items I collected were the hostname of the impacted system, and the full file path of the webshell that was written.

^{Figure 7: Playbook image for the delete_detected_files playbook}

If you want the full details of the playbook you can find them in my Github Repo. They will soon be placed into the Phantom Community Github Repo, which Phantom uses to synchronize playbooks with your Phantom instance. More details around this are outlined in the Use Splunk Phantom Docs. In the meantime, let me give you a quick rundown. Very simply, we are doing a step of data preparation and then executing a command and then formatting another command based on information we are gathering and then running a second command. It’s that simple!

• Step 1: Format block containing a “more” command that will extract the contents of the .aspx file which contains the webshell. This combines the “more” command with the webshell file path picked up in event.
• Step 2: Run the more command against the Exchange Server picked up in the event.
• Step 3: Format a delete command, and append the file path from the event.
• Step 4: Run the delete command on the Exchange server.
   

Done, webshell deleted, shown in Figure 8.

^{Figure 8: Webshell from Figure 5 has been deleted}

You may be thinking, "That’s great, you’ve deleted a webshell – but they can just create more (unless you’ve patched)." Yes, they can! But with this playbook set to automatically trigger whenever new webshells are detected, we are deleting them as fast as they come.

More Shells!

Terminate W3WP Spawned Processes Automatically with Splunk Phantom

Now that we’ve gotten rid of those pesky webshells, let’s move onto something more nefarious. Yes, I’m talking about reverse shells (insert spooky organ sounds here)! How can we possibly deal with those? I’m glad you asked!

After the adversary has implanted their webshell, it’s trivial for them to gain a reverse shell via something like netcat, some fancy tool like the Metasploit framework, or what I’m using in my exploit, Powercat (do you like how I’ve now tied the main picture of the blog back to this? Cute cats with automated robotic vacuums? Automation dealing with Powercat? Oh well, I tried...).

The Splunk Threat Research team released another detection as part of the HAFNIUM Group Analytic Story called “W3WP Spawning Shell” which picks up this behavior. The W3WP process itself is the IIS process running within Exchange. Whenever that process spawns the cmd.exe or powershell.exe processes, we have a match! We also have detections for the Exchange Unified Messaging process spawning cmd.exe or powershell.exe, but my exploit is making use of the W3WP process, so that’s what I will highlight here.

Within the correlation search for W3WP Spawning Shell I’ve just added a similar “Send to Phantom” Adaptive Response action to send the event to Phantom when this is detected, shown in Figure 9.

^{Figure 9: Send to Phantom Adaptive Response action for W3WP Spawning Shell}

In my exploit, I’ve chosen to launch a Powershell process that downloads the Powercat.ps1 script, runs it, and connects back to a Powercat listener that is running on another host.

As soon as this event is detected in Enterprise Security, the event is sent to Phantom, as shown in Figure 10.

^{Figure 10: W3WP Spawning Shell event created in Phantom}

Like the webshell playbook earlier, I’m gathering information from this event to use in the playbook. In this event, I’m collecting the affected Exchange Server host details, and additionally, I’m gathering the process ID of the spawned PowerShell process that was kicked off.

This can be a bit tricky though. The process that we want to terminate could actually be a child process of the one picked up in the detection. For example, the adversary could launch Powershell with a command like “cmd /c powershell.exe”. The detection would have picked up the execution of cmd, so we want to look for both that process, and any child processes that have been run.

I’ve built the playbook shown in Figure 11 to terminate both process variants.

^{Figure 11: Playbook image for the terminate_spawned_processes playbook}

Let’s go through it briefly. As before, if you want the full details of the playbook, it can be found in my Github Repo while we’re waiting for it to be added to the Phantom Community Github Repo.

• Step 1: The event returned in Splunk gives us the process ID that was spawned by the W3WP process, so in this step we’re terminating that process on the affected host.
• Step 2: This format block creates SPL to search Splunk for any child processes of the process identified in the detection.
• Step 3: This is where the Splunk search is executed by Phantom to find the process ID’s of child processes that were run.
• Step 4: Run the terminate process command for any child processes that were found in the previous search.
   

Done! A whole family of processes has just been terminated.

^{Figure 12: Reverse Powercat shell being terminated by Phantom}

Figure 12 shows the PowerShell command getting reversed back to the listening Powercat instance, then getting terminated due to the playbook being run to terminate it.

Closing

Obviously an adversary will attempt to perform additional actions like create persistence, move laterally, and more, but automated processes in your kit bag can help deal with issues very quickly when they do pop up!

Interested in learning more about Splunk Phantom and how it can help automate your security processes? Learn more about Splunk Phantom Security Orchestration and Automation.