Carbon Black & VMware Announce Expanded Partnership to Secure the Software-Defined Data Center (SDDC) Learn more

Hunting the White Rabbit: Detecting Metasploit Meterpreter Using Carbon Black

hunting the white rabbit: Detecting metaspoit meterpreter using carbon black
bent2
October 21, 2015 / Ben Tedesco

Brief Overview:

Carbon Black can detect Metasploit Meterpreter using the following watchlist:

childproc_name:”rundll32.exe” AND digsig_result:”Unsigned” AND path:c:\windows\*

This article is similar to my previous post, which I wrote while attending DEFCON23. In that post I described how one could use Carbon Black to detect PowerShell Empire.

While attending SANS Seattle 2015, my class used the Metasploit Meterpreter to compromise a host. Naturally, my hunting instincts kicked in and I fired up my victim workstation armed with Carbon Black in an effort to see what could be done to catch this nasty tool. I was shocked by how simple it was to detect the instant when the Metasploit process first deployed Meterpreter on the box!

First, I needed to setup my lab to begin my analysis:

I fired up Metasploit and generated a Meterpreter payload that leveraged the “windows/smb/psexec” exploit.

ted2

After configuring the options for my Meterpreter, it looked something like what is shown below:

ted3

From here, all that was left to was to launch the exploit at my victim machine.

ted4 ted5

Once the Meterpreter session was established with the victim, all that was left for me to do was launch a command shell and “interact” with the system for a little while.

ted6

After playing around a bit longer on the victim machine, I began to ask myself how can/should one detect this sort of activity using Carbon Black?

I decided to probe the environment just a bit longer in an effort to determine how the Meterpreter “lived” on the victim machine. I hoped that this might give me an idea how I might hunt for this process. The first thing that I wanted to find out was what our Meterpreter’s process ID was on the victim machine.

ted7

From here, I went ahead and remotely pulled the task list from the victim to discover the process name associated with PID 3364. I was intrigued when I saw that rundll32.exe had a PID of 3364.

ted8

Sure enough, when I ran a “netstat –abno” on the victim, the rundll32.exe process indeed had an “ESTABLISHED” connection back to our attacker system.

ted9

As I felt that I may have determined my first Meterpreter IOC, I decided to transition the focus of my research to Carbon Black in an effort to see if I could confirm this behavior.

Out of curiosity, I wanted to check to see if any external threat intelligence sources had detected Metasploit in the environment. However, when I checked the Carbon Black alerts dashboard, the only alerts referred to several netcat sessions that were generated by unrelated activity earlier in the day.

ted10

Given that other threat intelligence sources weren’t able to detect the attacker system’s activity on the endpoint, I started to consider what I had seen as I worked within the Meterpreter. My first real break came when I remembered that each of these processes needed to connect back to my command-and-control server—maybe here is where I could find a thread to pull as I began my hunt for IOCs on the Carbon Black side.

I decided to perform a process search and query all processes that established a connection with my attacker system (10.10.75.1).

ted11

The results were quite interesting! EVERY single process connecting to my server was launched by rundll32.exe! This confirmed what I had seen from the attacker’s perspective in this incident and was my first significant step to discovering my IOCs in Carbon Black!

ted12

Of course, I had to dig deeper. When I opened up the process analysis dashboard for one of the rundll32.exe processes, my jaw dropped. As plain as day, the entire attack chain was right here (as shown below)! I could plainly see how the randomly named Metasploit process (“nxqgkcuu.exe”) had spawned rundll32.exe (with the PID of 3364). This rundll32.exe process then made a connection back to my attacker system and launched several command shells that in turn launched several other processes!

ted13

It is also interesting to note that I saw a number of other processes had connected to my Attacker system. If this were a true incident, we would have clicked the “search” link to have seen what those other processes were (shown above).

Now that I had found the Meterpreter instance in Carbon Black, my next goal was to develop a watchlist that could be used to trigger an alert whenever a new Meterpreter payload executed within the environment.

I selected the randomly named Metasploit payload (“nxqgkcuu.exe”) used to launch rundll32.exe. In analyzing this process, I noted two additional IOCs that could be added to the rundll32.exe IOC discovered earlier:

ted20

ted14

Given that now I had three solid IOCS, I wanted to verify them by seeing if they would detect all six Meterpreter parent processes that spawned the six instances of rundll32.exe I found earlier. Sure enough, this search discovered every Metasploit Meterpreter process I had run in the environment!

ted21

ted15

Once I could accurately pinpoint instances of Meterpreter in my environment, the only thing left for me to do was to set up the alerting to ensure that I would be notified of any future occurences of the Metasploit Meterpreter in my environmet. To do this, I simply selected “Add Watchlist” from the search options menu and enabled the appropriate alert notification options from the “Add Watchlist” view.

ted16 ted17

To check if my watchlist was functioning correctly, I viewed the Watchlists dashboard. As expected, I could see each of the detected processes along with the alerting options and the watchlist hit count timeline.

ted18

As a final check, I revisited the triage alerts dashboard. This time we see it is populated with the alerts generated by the “METASPLOIT: Meterpreter” watchlist I created using the IOCs listed above.

ted19

Using a host-based, real-time, kernel-level monitoring agent that leverages a big data back-end correlation engine is the only way to effectively detect and respond to threats like Metasploit.

As demonstrated in this post, Carbon Black will detect and identify serious breaches that would go undetected by a traditional IDS/IPS.

The Bit9 + Carbon Black integration takes the detection phase one step further by providing the security team a mechanism to instantly alert on and respond to a breach using the Bit9 enforcement engine. Once notified of malicious activity, Bit9 can automatically respond to the breach by banning the malicious process (thus killing any currently running processes on the endpoint). Bit9 also can be configured to automatically elevate the level of enforcement on the compromised system, thus preventing other malicious binaries from executing and ensuring near real-time breach defense and remediation.

– –
Benjamin Tedesco is a technical services consultant working at Bit9 + Carbon Black as a digital forensics and incident response SME. He assists Carbon Black customers by enabling them to leverage the Bit9 + Carbon Black tool suite in their existing incident response and detection capabilities. Before coming to Bit9 + Carbon Black, Benjamin was responsible for leading a number of high-profile APT hunt-and-detection engagements. Currently, he is pursuing a master’s degree in information security and forensics at Penn State University.

To connect with Ben, drop him a line on LinkedIn: https://linkedin.com/in/bentedesco

 

TAGS: bit9 / Carbon Black / Hunting Ben Tedesco / Metasploit / Meterpreter / White Rabbit

Related Posts