Targeted Forensics: Mapping a Process to a Malicious Command and Control

Introduction To The Targeted Forensic Series

Host and network forensics are very important parts of incident response and can provide a security operations team with additional insight and indicators into cyber attacks. However, forensics can be daunting at times, and the amount of time it takes to perform full analysis of a hard drive does not result in a fast and efficient response to an incident. Instead of deep dive analysis, an organizations strategy should shift to a more targeted approach in which the analyst focuses the investigation to answer a very specific question related to the incident. This type of analysis is most commonly referred to as “Sniper Forensics”. The term comes from the analogy of a sniper taking aim at a specific target, instead of using a grenade launcher to take out a building.  Sniper forensics is applied using the Alexiou Principle by answering the following questions:

  1. What question are you trying to answer?
  2. What data do you need to answer that question?
  3. How do you extract/analyze that data?
  4. What does the data tell you?

In this series of blogs, I will provide tutorials on how to perform host and network forensics using this targeted approach. Over time, a incident handler will have a repository of these procedures and when cyber incidents that require additional analysis arise, these procedures can be used to efficiently and effectively respond.

 

Mapping a Process To A Malicious Command and Control

What question are you trying to answer?

Scenario: Network traffic shows a host communicating to a known malicious command and control (C2). It is your goal to find out which process is making the malicious outbound connection.

 For this example, we will be searching for the process that made the connection to the IP address “10.10.10.1”.

 What data do you need to answer that question?

  1. Full memory capture of the compromised host
  2. Known malicious C2 

How do you extract/analyze that data? 

Tools: Volatility

Procedure

For XP or Windows Server 2003

  1. By using Volatility you can easily extract both active and terminated network connections from the memory dump. To do so, you will us the below modules in Volatility
    1. Psxview: Searches for different process objects in memory to identify hidden or terminated processes. The different types of process ojects it searches for are:

i.      PsActiveProcessHead – Active and sometimes terminated processes

ii.      EPROCESS – Active Processes

iii.      ETHREAD  – Active Threads

iv.      PspCidTable – Can identify hidden processes

v.      Csrss.exe – Can identify active, hidden and terminated processes

  1. Connections: Shows the active and established network connections at the time of the memory capture
  2. Connscan: Can extract previously terminated network connections. This module will have some false positives but can also provide additional artifacts that the connections module cannot
  1. First we are going to run the “psxview” module from Volatility which will give a list of active/terminated/hidden processes and their corresponding Process ID (PID). In order to do this, open up a command shell and navigate to the directory where Volatility is and run the below command. Refer to Figure 1 for a sample output
    1. Command: “volatility psxview –f Filepath_of_memory_dump”

Figure 1 (2)

Figure 1: Psxview Sample Output

 

  1. The next step will be to extract the network connections from memory, we will do this by using the Volatility commands, “connections” and “connscan”. The commands to run are below and Figure 2 shows a sample output.
    1. Command: “volatility connections –f Filepath_of_memory_dump”
    2. Command: “volatility connscan –f Filepath_of_memory_dump”
Figure 2 (2)
Figure 2: Connscan Sample Output

For Windows Vista, Server 2008 and Windows 7

  1. For Windows Vista and above, it gets a whole lot easier as there is just one module to run and that is “netscan”. “Netscan” essentially combines the use of “psxview”, “connections” and “conscan”, as well as some other modules that are not applicable. Run the below command to execute the “netscan” module. Figure 3 shows a sample output.
    1. Command: “volatility netscan –profile=memory_profile –f Filepath_of_memory_dump”

Figure 3 (2)

Figure 3: Netscan Sample Output

What does the data tell you?

For this example, we can see in Figure 2 that the C2 is mapped to the PID 1604. If we map PID 1604 to the corresponding process name from Figure 1, we will find that “Explorer.exe” is the process that established the connection to the C2. This is easily malicious since there is no legitimate circumstance where “Explorer.exe” should have an established network connection. In Figure 3, the malicious process may not be as obvious as “Explorer.exe”, however, since we already had the intelligence that the malicious C2 is “10.10.10.1” it is just a matter of mapping the C2 with the process name, which would be, “heumm.exe”.

Possible Next Steps:

You might consider the below next steps as part of your analysis. However your next actions should take into account the overall objective of the investigation to ensure that you do not perform more analysis than needed.

  1. Extract process from memory for further analysis
  2. Examine hard drive for additional artifacts/indicators related to malicious process identified

Leave a Reply

Your email address will not be published. Required fields are marked *

17 thoughts on “Targeted Forensics: Mapping a Process to a Malicious Command and Control”

  1. Thanks for this very pertinent introduction.One spoiler alert though: small and medium sized business can not (“never in a million years”) do all that without outside help. The problem that i have witnessed with this is that in SMEs one tends to hire “the best bid” – and those guys may well have criminal inclinations of their own. It is very difficult to find affordable security analysts and not fall prey to exactly the type of guys you want to keep at bay.