Volatility Write-up


This room was published on TryHackMe. It teaches the basics of Volatility 2 by walking you through a memory sample of an infected Windows XP host.

Examining Our Patient

For Volatility 2 you will need to find out the profile of the memory images. After taking the memory image you should always check the version of the operating system. But if this is not possible then you can use the imageinfo command, so Volatility can suggest you some profiles. If there are more then one profile, you have to do some trial and error until you find the right profile. Volatility 3, which is currently in beta phase, can determine the profile by itself.

After downloading and unzipping the memory sample you can determine the profile by running the following command:

volatility -f cridex.vmem imageinfo
Output of imageinfo paramter

Now test both profiles with the pslist plugin:

vol.py -f cridex.vmem --profile=WinXPSP2x86 pslist
Output of pslist plugin

Both of them will produce the same output, but for this CTF we will use the WinXPSP2x86 profile.

In the output we can see the offset in RAM, and further informations about a process:

  • Name
  • Process ID
  • Parent Process ID
  • Number of threads
  • Number of handles
  • Date and time when the process started and exitted

Note that this plugin searches the PsActiveProcessHead doubly linked list to find processes. So malware that detaches itself from this list won’t show in this output.

The smss.exe process has the process ID 368.

At this point you would search for processes that are suspicious or are not typical for Windows XP. Also open network sockets can be examined with the netscan plugin:

vol.py -f cridex.vmem --profile=WinXPSP2x86 netscan

Note that this won’t output anything, because netscan is only supported for 32- and 64-bit Windows Vista, Windows 2008 Server and Windows 7 memory dumps. For Windows XP you would use the sockets plugin:

vol.py -f cridex.vmem --profile=WinXPSP2x86 sockets
Output of the sockets plugin

This plugin walks through the singly-linked list of socket structure. At this point you would search for suspicious network traffic from processes.

ETHREAD contains fields that identify the parent process of a child process. By searching in this field you can find hidden processes. The psxview plugin can be utilized to find hidden processes:

vol.py -f cridex.vmem --profile=WinXPSP2x86 psxview
Output of psxview plugin

The process csrss.exe was not shown by the pslist plugin.

The ldrmodules plugin can help us find DLLs of a Wow64 process. This module compares the list of processes and checks if the DLLs are in the PEB. Also this plugin can produce a large amount of output, so it is good when you redirect the output to a text file to analyze it.

vol.py -f cridex.vmem --profile=WinXPSP2x86 ldrmodules | tee "ldrmodules.txt"
Output of the ldrmodules plugin

As you can see the csrss.exe process has “InLoad”, “InInit” and “InMem” columns set to “False”. This can indicate that the DLL has been unlinked from the Process Environment Block.

The command malfind can be used to find malicious executables (DLLs or shellcode) inside each process. You can also dump this code by specifying a directory after the -D flag:

vol.py -f cridex.vmem --profile=WinXPSP2x86 malfind -D dumps

This will dump 12 executables in my case:

Dumped executables

To get a list of all DLLs in memory, you can use the dlllist command: vol.py -f cridex.vmem --profile=WinXPSP2x86 dlllist

You can use the dlldump plugin to dump DLLs of a specific process. In this case we will be dumping the DLLs of the suspicious csrss.exe process:

vol.py -f cridex.vmem --profile=WinXPSP2x86 dlldump --pid=584 -D dllDumps
Dumped DLLs

This gives us 12 DLLs.

Post Actions

You can now further analyze the samples. For examples by utilizing static analysis techniques like reverse engineering. But to get an idea if this samples were ever detected you can use sites like e.g. VirusTotal. After checking the first dump we can see that this is the “Cridex” worm. This worm was used as banking malware. The worm’s C2 infrastructure utilized P2P networks and proxy servers. Also symmetric encryption was used to deliver configuration files from the C2 server. (VirusTotal, Kaspersky Threats)




Passionate about Cyber Security. I am publishing CTF writeups and Cybersecurity content!

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

SQLite vs PostgreSQL

Python Function Guide: Day 10

The Main Layout of your Front End App

How to create your first Slack bot mockup

Creating, Editing & Deleting users in cPanel’s User Manager

From Dev Bootcamp to IBM in 365 Days.

Corporate Strategy Case Study Analysis Psychology

MYSQL Kafka Connect Tutorial on Docker

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


Passionate about Cyber Security. I am publishing CTF writeups and Cybersecurity content!

More from Medium

Belkasoft Write-up: CTF 4

FORGE — HackTheBox WriteUp

HTB Write-up — Paper

Active Directory Certificate Services: Domain Dominance