When dealing with an incident it can often happen that your starting point is a suspicious IP. For example, because the IP is showing a suspicious beaconing traffic pattern (i.e. malware calling home to its C2 server for new instructions). One of the questions you will have is what is causing this traffic. It can really help your investigation when you know which process (or sometimes processes) are involved. However, answering this question is challenging when you have to deal with the following:

An IT infrastructure where a non-transparent proxy is used for all outgoing network traffic (this is the case in many enterprise networks).
No other sources, except a memory dump, are available to you where you could find this information.

In this blog post I will explain how you can solve this with Volatility and strings.

Lab Setup

I have created a small lab setup to simulate an infrastructure where communications to the internet need to go through a web proxy.

The host with IP 172.31.0.250 is the internal web proxy server. This server forwards the traffic to the gateway and sends back the result to the client. The endpoint with IP 172.31.16.50 is used to perform our memory forensics on.

Generating network traffic

To make it as realistic as possible, the endpoint 172.31.16.50 is used to setup multiple connections to hosts on the internet using different applications. One of these applications is connecting to IP 35.178.122.152. The intention is to identify which process is responsible for communicating with this IP.

The problem

The effect of a non-transparent proxy on network connections

The goal for this blog is not to explain in detail how a web proxy works. If you want to have more details about this topic, I can recommend reading the following blog post: https://parsiya.net/blog/2016-07-28-thick-client-proxying---part-6-how-https-proxies-work/.

When an endpoint wants to communicate to the internet within an IT infrastructure that requires all internet traffic have to pass a proxy. It will ask the internal web proxy server to connect to the external host and send back the results.

Applications communicating to the internet over a non-transparent proxy are not directly communicating with the host on the internet, but ask the proxy to do that. That is why you will not see something like the following within your network connections:

In the above netstat output it is pretty easy to identify which process did setup a connection to which exact external IP and port (e.g. Chrome.exe communicates to the external IP 108.177.126.138 over port 443). However, when dealing with a non-transparent proxy you will see something completely different.

These are the same network connections using the same applications. But this time all external connections are going through a proxy. Therefore all external communications seems to be going to the internal host 172.31.0.250 (the internal proxy server) over port 8080:

The Volatility plugin netscan will show similar output from which it seems that all outgoing connections are to internal hosts 172.31.0.250:

Solving the problem

Let's have a look at how to pinpoint a particular IP address to a process using Volatility and strings. Instead of strings you could also use another utility, as long as the output contains the decimal byte offset and its corresponding string.

Strings
You have to start off by locating all physical memory address locations of the IP 35.178.122.152 within your memory dump (remember that this was the IP related to the suspicious beaconing pattern). You can use Linux strings for this with 2 passes to include both ASCII and (little-endian) Unicode strings (-el). You set the parameter -td strings to include the byte offset in decimal format for every string. You will later need this offset for Volatility. The output of strings is written to the file out-linux-strings:

With some luck it could be the case that grepping for your suspicious IP within the strings output, that you can already spot the source without the need to use Volatility. Take note that this will not always be the case. Just grepping for the IP or using Bulk extractor to search through your memory dump can be of much help to find out more.

From the file out-linux-strings you grep all the lines that have a match on the IP 35.178.122.152 and output it to another file search-strings:

Volatility
You will use the file search-strings as input for the Volatility plugin strings. This plugin expects as input a file in the form <decimal_offset>:<string>, or <decimal_offset> <string>. The plugin will output the corresponding process ID and virtual address where the string can be found within the memory dump. Write the output of Volatility to the file out-strings:

With some basic Linux tools you can create a list of involved processes and do a count on number of occurrences. You can clearly see that process with ID 3008 is having a major role with 116 hits regarding the communications to IP 35.178.122.152 (the entries with FREE can be ignored as it is related to free memory which is no longer associated with a process. It can however contain valuable information).

When using the Volatility plugin pslist you can also find the corresponding process name taskhostex.exe for PID 3008:

Mission accomplished!
Please tell me if you have another way to solve this problem that involves memory forensics.

Update

Andrew Case (Volatility Core Developer) replied with another way on how you can try to solve this using the Volatility plugin yarascan: https://twitter.com/attrc/status/975675012307935232