Practical Analysis 2: Process Injection

In this case, we are going to discuss process injection. Process injection is a technique in which some
piece of code is run in the address space of some other process. Attackers actively use this method to run
malicious shellcode in a legitimate process context. This way, they can evade defense mechanisms and
hide their tracks.
The case 2 file is stored at /home/analyst/memorydumps/ProcessInjectionCase2.mem
Volatility is installed under /home/analyst/Volatility3/vol.py
We will learn to detect if any possible memory injections occurred using the Volatility framework. We
start by seeing all running processes using PsList.
Command: python3 /home/analyst/volatility3/vol.py -f
/home/analyst/memorydumps/ProcessInjectionCase2.mem windows.pslist

In real analysis, we would first look for any odd parent-child process relation, or any suspicious/random
named process to detect any rogue processes. Seeing the output of PsList, we cannot spot any suspicious
processes or any odd PID-PPID relations. We can also try to see any suspicious command line arguments
using CmdLine.
Command: python3 /home/analyst/volatility3/vol.py -f
/home/analyst/memorydumps/ProcessInjectionCase2.mem windows.cmdline

Now the plugin relative to this case is named “MalFind”. The MalFind command helps find hidden or
injected code/DLLs in user memory space, based on characteristics such as virtual address descriptor
flags and permissions set on each process VAD. We have already discussed in detail how memory
injection occurs in task 2. Here, we will focus only on finding injections in memory image.
Now let’s try this plugin and see what we get as output.
Command: python3 /home/analyst/volatility3/vol.py -f
/home/analyst/memorydumps/ProcessInjectionCase2.mem windows.malfind
We immediately see the svchost.exe process on top. svchost.exe shouldn’t show this behavior under
normal circumstances. Let’s take note of this Process ID which is “1776”. We see some Hex code, its
ASCII equivalent, and below it, some assembly instructions. We will get back to this, but first let’s scroll
down

We see another process here but this is a false positive. Because this process is a Microsoft Defender
antimalware engine which shows such behavior because it runs in memory with full
“EXECUTE_READWRITE” permissions to work efficiently. It needs to read code in other processes'
memory space to detect possible intrusions like in our case. You would see “MsMpEng.exe” in many
cases in the output of the Malfind plugin. Attackers can also abuse this by making their binary name as
this one. So it’s always better to validate that this indeed is a legitimate binary. We can do that by either
dumping this process or trailing back the parent-child process relation.
Now back to our svchost.exe process. We know something suspicious is going on since a possible process
injection occurred in a svchost.exe process. To move further, we can dump this process, do reverse
engineering, or use online/offline sandboxes to learn about its behavior. We will not do this as it's outside
the scope of this course. The Hex and ASCII are the header information of this file. If we do some
research based on the Hex code or strings, we find that this particular pattern is often found in C2
beacons/Meterpreter Shells. In this example, Meterpreter shellcode was injected into the process for
demonstration. This can be any process, but I showcased svchost.exe because we also discussed this in
case 1. Now we know this is a C2 beacon. We can see any active/closed connections using the netscan
plugin. We will grep the results with 1776 as we have identified the malicious process and suspect that it's
a C2 beacon.
Command: python3 /home/analyst/volatility3/vol.py -f
/home/analyst/memorydumps/ProcessInjectionCase2.mem windows.netscan | grep 1776

We can see that the infected host communicated with the IP “192.168.230.128” on port 4444 which is a
Metasploit default port. This confirms that C2 communication was made and in real scenarios we would
block this IP from our network and hunt for the IOCs found across the network in case of network-wide
infections.
So, from this analysis we have obtained the following IOCs
1- 192.168.230.128
2- svchost.exe (Process ID 1776) and it's hash
We can then perform an in-depth forensics investigation after containing the threat.