Practical Analysis 3: DLL Injection

In this last case, we will look at DLL injection which is somewhat similar to the process injection which
we have already discussed. In this technique, instead of injecting some code in other processes' space, we
inject a DLL in the context of the target process. Programs use DLLs (dynamic link libraries) to work
dynamically and according to their use cases in different scenarios. Attackers use this technique to force
load a malicious DLL under the context of a process and that process executes the code present in that
DLL.
The case 3 file is stored at /home/analyst/memorydumps/DllInjectionCase3.mem
Volatility is installed under /home/analyst/Volatility3/vol.py
Note: Terminate the machine from previous lessons and connect to the new machine for this lesson. Case
3 file is stored in this lab and is not available in the previous connected lab.
We start with the PsList command as usual:r
Command: python3 /home/analyst/volatility3/vol.py -f
/home/analyst/memorydumps/DllInjectionCase3.mem windows.pslist

We look for rogue processes or suspicious looking processes to kickstart our investigation. We have
already discussed this methodology so we will jump directly into finding the malicious DLL. We will
make use of Malfind again to find traces of an injection.
Command: python3 /home/analyst/volatility3/vol.py -f
/home/analyst/memorydumps/DllInjectionCase3.mem windows.malfind
We see the process name spoolsv.exe on top. “spoolsv” is a print spooler service in Windows which is
responsible for handling print jobs. Whenever we want to print a document, the instructions are carried
out by this service. We again see Hex code, some assembly instructions, and instead of file header info,
we see a Windows path. This is because in the process injection case, raw shellcode was injected into the
process. Here, a file (DLL) is injected, so we see its path. Great, now we have the name and path of a
malicious file which we can use for threat hunting.
So, we know there’s a DLL named Winsrvc.dll in the downloads directory. The DLL name sounds like a
legitimate DLL name, but no such DLL exists natively in Windows. We have the Process ID of our
malicious process so we dump that process, or even better, we dump out all the file(s) related to the
process, including DLLs. We can also dump all DLLs running at the time of acquisition.
Command: python3 /home/analyst/volatility3/vol.py -f
/home/analyst/memorydumps/DllInjectionCase3.mem windows.dlllist | grep Winsrvc

We only need this specific DLL, so we will dump this:

Command: python3 /home/analyst/volatility3/vol.py -f
/home/analyst/memorydumps/DllInjectionCase3.mem windows.dlllist –pid 1656 –dumpe
This command will dump all DLL(s) related to the process spoolsv.exe with PID 1656. We know the
name of the injected DLL, so we will rename it to distinguish it from other DLL(s) and analyze it further.

In real investigations, we would analyze it in depth. For our exercise, we will upload this to VirusTotal to
see the results:

We can see that this is malicious. This malicious DLL was created using the MSFvenom payload for this
exercise and was used for a reverse connection. We can now use the netscan plugin to see:
Command: python3 /home/analyst/volatility3/vol.py -f
/home/analyst/memorydumps/DllInjectionCase3.mem windows.netscan | grep rundll32
One interesting thing to note in this case is that we will see that the C2 connection is being made by a
legitimate process “rundll32.exe” instead of our injected process “spoolsv.exe”. This is because execution
of DLL(s) is handled by rundll32.exe in Windows. So, although the DLL is executed in the context of the
spoolsv.exe process, it is actually being handled by rundll32.exe. We see the same attacker IP as in
previous cases.
So far, IOCs collected in this case are:
1- 192.168.230.128
2- Winsrvc.dll and its hash
We would hunt for these IOCs in a real scenario to find and stop any other infections.