Analyzing Malicious Processes

[Nytro]

Analyzing Malicious Processes

Posted on 2013/11/11 by jackcr

Today I tweeted “Analysis techniques are individually developed. Show people processes and let them be creative”. SO I wanted to write this post to describe a method I use to analyze processes on hosts that are suspected of being compromised.

When attackers gain access to your network they will need to perform certain activities in order to accomplish their goals. Very often these activities will result in executables being ran and processes started as a result. Identifying these processes is very important, but what do you do after is where you begin to earn your money. For this post I will be using a memory image from the jackcr-challenge which I created last year. If you are interested in tackling this challenge it can be downloaded from the link on the right side bar or you can follow this link https://docs.google.com/file/d/0B_xsNYzneAhEN2I5ZXpTdW9VMGM/edit.

When looking at processes pay attention to the start times. We should be focusing on ones that have started around the same time frame that we are investigating (if the machine has been rebooted after the initial compromise then this method will obviously not work). Remember that attackers will very often leverage windows tools so don’t discount processes that seem like they would be non-malicious just because it was executed from a legitimate Microsoft executable. It’s also a good idea to pay attention to spawned processes as well a parent processes. If cmd.exe was spawned from iexplore.exe it may be cause for some concern.

Looking at our memory image we start by inspecting the process listing.

The above command will display the following output.

At first glance the cmd.exe process may seem a little suspicious but is was spawned from explorer.exe and is responsible for mdd.exe which collected the memory dump. The PSEXECSVC.exe process looks a little suspicious though. When psexec.exe is executed on a client machine it will copy the psexecsvc.exe binary over a smb connection to the destination and start a service as well as create a named pipe in which commands will be executed over. This may very well be an admin performing maintenance on the server, but not knowing for sure warrants investigation.

The first thing I will want to look at are the ip’s that have been communicating to this machine on ports 135 and 445 since I know psexec communicates over these. As these connections may not be established any longer I will use the Volatility plugin, connscan, which has the ability to locate closed tcp connections as it scans for _TCPT_OBJECTS which may still reside in memory.

Based on the output we have 3 machines that we may need to validate and possibly investigate after performing analysis on this machine. We will also use these ip’s when analyzing the process strings. Before looking at the strings I want to look at the open handles to the process as it may give some clues to additional items that may need to be investigated. At this point I mainly want to look at open file handles.

The above command will produce the following output. We can see the named pipe created by the execution of psexec on the client machine, but not really anything else that would steer my investigation.

The output can be large so I initially like to start with a smaller subset that I think may give some results I’m looking for. At this point I will broaden my search to see if I can find anything else of interest.

We can see in the below output that we have a hostname that’s tied to this process. If this turns out to be a malicious process we will need to immediately contain that host to prevent further lateral movement and investigate for additional compromises.

As processes start, the operating system will allocate up to 2GB of virtual address space for that process to execute in. I like to think of processes as a container of activity. If I specifically look at that container I should see activity that is directly related to the activity I’m looking for. This is important because when looking at memory strings it’s very easy to to find things that look really bad only to find out that they are part of an AV signature or part of a legitimate connection. It is also much easier to analyze a small section of memory than the entire memory dump.

Using the volatility plugin memdump we can dump the entire contents of a process into a binary file.

We should create a strings file with both ascii and unicode strings as it’s much faster to grep through ans ascii file than a binary file. By default I like to prepend each string with the byte offset incase I need to locate that string in the dump file. We can use the following 2 commands to produce this file.

Very often when attackers want to execute commands on compromised machines they will create batch scripts to perform these tasks. Just searching the strings file for “echo off” we are able to, not only confirm that this host is compromised, but gain insight into what happened on this machine as well as identify indicators to look for on our network.

The 3 batch scripts identified performed the following actions:

1. Rar’d up the contents of C:\Engineering\Designs\Pumps

2. Created a scheduled task to copy wc.exe to the system32 directory and execute it at 04:30

3. Collected system information and directed the output to the file system.dll

Searching the process data for the ip’s I was able to locate these log files in memory indicating a login to this machine using the sysbackup account which was the same username identified in the batch script. The host that initiated the login was also the host identified in the handles output.

Knowing that this machine is confirmed compromised there are some additional actions we must take in hopes of limiting the scope of the incident.

1. Search network for any directories named webui in the system32 directory

2. Attempt to locate wc.exe in memory or on the host itself to determine capabilities (typicaly locating in memory would be much faster then collecting on the host).

3. Collect and analyze data from 3 ip’s seen making port 445 connections

4. Search network for presence of wc.exe, ra.exe, system.dll

5. Search logs for 540 / 4624 type 3 logon attempts from suspicious ip’s as well as machines using the sysbackup account.

6. Change the sysbackup credentials as well as all user credentials on the compromised machines (domain and local)

7. Determine what files were rar’d

8. Look for possible data exfil in network traffic

There is a lot of additional data in these memory images and I encourage you to have a look at them if you’ve not already done so.

Again I hope this helps somebody out there and let me know if you have any questions or comments.

Sursa: Analyzing Malicious Processes