Cridex Malware Memory Analysis
Cridex Malware Memory Analysis
We will run several volatility commands in this tutorial using a simple case scenario: the Cridex malware,
ready? Let’s begin!
Prerequisite
I’ll assume you’ve already downloaded and installed volatility on your computer
The dump we will analyze can be downloaded on the opensource volatility dumps platform and
can be found https://github.com/volatilityfoundation/volatility/wiki/Memory-Samples
Dump analysis
The very first command to run during a volatile memory analysis is: imageinfo, it will help you to get
more information about the memory dump
With -f specifying your dump file and imageinfo the volatility plugin you want to use. You should obtain
the following result:
We now have the computer OS from which this memory dump comes from (WinXPSP2x86). The
investigation can now begin, we can specify to volatility the OS profile (--profile=WinXPSP2x86) and try
to find what happened on the victim’s computer.
Let’s see what were the running processes using the pslist plugin.
An alternative to the pslist plugin can be used to display the processes and their parent
processes: pstree
At first glance we can notice an odd process named “reader_sl.exe” with the “explorer.exe” as parent
process (PPID) which was one of the last processes running on the machine.
Let’s run a last command before investigating deeper into these two processes. psxview will list
processes that are trying to hide themselves while running on the computer, this plugin can be really
useful.
Well, except in our case ;) no processes seem to be hidden, if so you’ll see “False” in the first two
columns (pslist and psscan).
Let’s get back to this investigation, after seeing the running processes, a good thing to do is to check the
running sockets and open connections on the computer. To do this we’ll use these different
plugins: connscan, netscan and sockets
The connscan plugin is a scanner for TCP connections, while sockets will print a list of open sockets and
finally netscan (which cannot be used in our example due to the profile used) will scan a Vista (or later)
image for connections and sockets.
In our scenario, two TCP connections are used by the process with PID 1484 (by looking at our command
history outputs we can easily link the PID 1484 to the process explorer.exe). We can see that one of this
TCP connection is still open, the one using port 1038 and communicating with the destination IP address
41.168.5.140.
Let’s now take a look at the last commands ran, by using cmdscan, consoles and cmdline plugins.
The first two plugins: consoles (which extracts command history by scanning for
_CONSOLE_INFORMATION) and cmdscan (which extracts command history by scanning for
_COMMAND_HISTORY) did not contain any information in their buffers.
However, the cmdline plugin which display process command-line arguments did give us interesting
information. Indeed, we now have the full path of the processes launched with PID 1484 and 1640. The
“Reader_sl.exe” process is getting more and more suspicious…
So far, we know that this process was launched by the explorer process, is supposed to be a classic
Adobe reader application, however we observed a running connection towards an external IP used by
this very same process…
Let’s not jump to conclusions too quickly and let’s take a look at the concerned executable and the
analysis of this latter using respectively procdump and memdump by specifying the -p 1640 (its PID)
and --dump-dir (the directory where we want to extract theses dumps).
The first file “executable.1640.exe” is a restitution of the executable “Reader_sl.exe” and the dump
extracted “1640.dmp” represents the addressable memory of the process.
Then, a simple analysis of these files can be done by using the “strings” linux command, be patient
usually the dumps contains lots of information. In our scenario, we are looking for a relation between
the piece of information already retrieved from the dump (especially the opened tcp connection
towards the 41.168.5.140 IP) and this 1640 process.
I used the grep command combined with the -C #NUMBER to get the previous and next lines, thus giving
us more context for the information found. Here we can clearly see that the executable “Reader_sl.exe”
is communicating towards the destination IP 41.168.5.140 using POST requests, potentially exfiltrating
information from the victim’s computer.
By being patient enough and by reading the extracting dump using the strings command, we can find
these interesting domains:
either by doing a static analysis and reversing the executable to see concretely what commands
the executable uses and its aim
or — since I’m not currently at ease with reverse analysis — try a dynamic analysis by using a
sandbox or online tools that analyzes potentially malicious executable
So let’s take the second option and analyze the files using VirusTotal, probably the most famous website
for suspicious file and website analysis, I also like using: HybridAnalysis for this kind of analysis.
executable.1640.exe (VirusTotal)
executable.1640.exe (HybridAnalysis)
Clearly the executable is recognized as malicious by these two sandboxing websites with high detection
scores!
It is now time to sum up the different investigations we’ve made and our findings with the analyzed
dump:
Bank domains and 41.168.5.140 found in the dump of the process 1640
If the “cridex.vmem” dump was extracted from a user’s computer we could then conclude that the
computer is infected by a trojan.
Prevention
Let’s say this dump was found on an employee’s computer, who is working for a big company, as a
Forensic investigator you’ve managed to analyze the volatile memory dump and found the malicious
exe.
However, this executable might have been sent by a phishing campaign to all the company employees,
so you now need to extract IOCs (Indicators of Compromise) to qualify this Cridex trojan as much as
possible and thus help the SOC team to detect other potential infected computers.
The first IOC found in the dump was the C&C IP address: 41.168.5.140, to see if other IP addresses are
used we can for example try and search in the process dump file for the following pattern
“/zb/v_01_a/in/” which is the path queried by the malware (“41.168.5.140:8080/zb/v_01_a/in/”).
We found another IOC: 188.40.0.138! Let’s see if we can associate these IPs with possible hostnames
using a passive DNS. For this case we’ll use a public passive DNS service named Mnemonic:
results for 188.40.0.138
------------------------
Record Type Query Answer First seen Last seen # times TTL
a paypalconfirmaccount.com 188.40.0.138 2014-04-01 15:32...
a dedi53.flk1.host-h.net 188.40.0.138 2012-08-06 15:42 ...
a www.sandtonslippers.co.za 188.40.0.138 2012-12-27 04:21 ...
a www.horizoncottages.co.za 188.40.0.138 2012-12-24 03:11 ...
a blog.anafricanvilla.co.za 188.40.0.138 2012-12-14 05:11 ...
a www.capetowncity.co.za 188.40.0.138 2012-10-16 17:37 ...
a derwenthouse.co.za 188.40.0.138 2012-10-23 02:36 ...
a www.derwenthouse.co.za 188.40.0.138 2012-10-16 18:27 ...
a www.villastjames.com 188.40.0.138 2012-11-07 20:00 ...
a www.capescape.co.za 188.40.0.138 2012-10-31 15:33 ...
a www.wind-rose.co.za 188.40.0.138 2012-10-23 02:39 ...
a wind-rose.co.za 188.40.0.138 2012-10-23 02:38 ...
a static.138.0.40.188.... 188.40.0.138 2012-08-06 16:43 ...
a blog.leeuwenvoet.co.za 188.40.0.138 2012-08-06 15:41 ...
a www.therocks.co.za 188.40.0.138 2012-08-06 15:41 ...
a www.leeuwenvoet.co.za 188.40.0.138 2012-08-02 20:17 ...results for 188.40.0.138
------------------------
Record Type Query Answer First seen Last seen # times TTL
a paypalconfirmaccount.com 188.40.0.138 2014-04-01 15:32 ...
a dedi53.flk1.host-h.net 188.40.0.138 2012-08-06 15:42 ...
a www.sandtonslippers.co.za 188.40.0.138 2012-12-27 04:21 ...
a www.horizoncottages.co.za 188.40.0.138 2012-12-24 03:11 ...
a blog.anafricanvilla.co.za 188.40.0.138 2012-12-14 05:11 ...
a www.capetowncity.co.za 188.40.0.138 2012-10-16 17:37 ...
a derwenthouse.co.za 188.40.0.138 2012-10-23 02:36 ...
a www.derwenthouse.co.za 188.40.0.138 2012-10-16 18:27 ...
a www.villastjames.com 188.40.0.138 2012-11-07 20:00 ...
a www.capescape.co.za 188.40.0.138 2012-10-31 15:33 ...
a www.wind-rose.co.za 188.40.0.138 2012-10-23 02:39 ...
a wind-rose.co.za 188.40.0.138 2012-10-23 02:38 ...
a static.138.0.40.188.... 188.40.0.138 2012-08-06 16:43 ...
a blog.leeuwenvoet.co.za 188.40.0.138 2012-08-06 15:41 ...
a www.therocks.co.za 188.40.0.138 2012-08-06 15:41 ...
a www.leeuwenvoet.co.za 188.40.0.138 2012-08-02 20:17 ...
Deletion
If in fact this Cridex malware is found on other machines by the SOC team, you should either use an
antivirus that can detect and eradicate the threat (using the anti-viruses that were able to detect our
malicious executable) but also see if this malicious trojan is persistent or not.
Indeed, most malwares try to make their execution automatic at every system startup, hence making
their deletion difficult. To see if this is the case with Cridex we can take a look at the registry entries
used during the system startup.
The hivelist plugin allow us to print the list of registry hives. The printkey plugin will help us to see the
content of a registry key its subkeys and values. Let’s now use the -K option to navigate towards the
registry key path we are looking for.
$ volatility -f cridex.vmem --profile=WinXPSP2x86 printkey -K
"Software\Microsoft\Windows\CurrentVersion\Run"Volatility Foundation Volatility Framework 2.6
Legend: (S) = Stable (V) = Volatile
----------------------------
Registry: \Device\HarddiskVolume1\Documents and Settings\Robert\Local Settings\Application
Data\Microsoft\Windows\UsrClass.dat
Key name: Run (S)
Last updated: 2011-04-13 00:55:13 UTC+0000
Subkeys:
Values:
----------------------------
Registry: \Device\HarddiskVolume1\Documents and Settings\Robert\NTUSER.DAT
Key name: Run (S)
Last updated: 2012-07-22 02:31:51 UTC+0000
Subkeys:
Values:
REG_SZ KB00207877.exe : (S) "C:\Documents and Settings\Robert\Application
Data\KB00207877.exe"
----------------------------
Registry: \Device\HarddiskVolume1\WINDOWS\system32\config\default
Key name: Run (S)
Last updated: 2011-04-12 20:31:49 UTC+0000
Subkeys:
Values:
----------------------------
Registry: \Device\HarddiskVolume1\Documents and Settings\LocalService\Local Settings\Application
Data\Microsoft\Windows\UsrClass.dat
Key name: Run (S)
Last updated: 2011-04-13 00:55:13 UTC+0000
Subkeys:
Values:
----------------------------
Registry: \Device\HarddiskVolume1\Documents and Settings\NetworkService\NTUSER.DAT
Key name: Run (S)
Last updated: 2011-04-13 00:49:16 UTC+0000
Subkeys:
Values:
----------------------------
Registry: \Device\HarddiskVolume1\Documents and Settings\LocalService\NTUSER.DAT
Key name: Run (S)
Last updated: 2011-04-13 00:49:28 UTC+0000
Subkeys:
Values:
----------------------------
Registry: \Device\HarddiskVolume1\Documents and Settings\NetworkService\Local Settings\Application
Data\Microsoft\Windows\UsrClass.dat
Key name: Run (S)
Last updated: 2011-04-13 00:55:13 UTC+0000
Subkeys:
Values:
As you can see, the only hive that has been recently modified is the following registry
“\Device\HarddiskVolume1\Documents and Settings\Robert\NTUSER.DAT”. Let’s confirm that the
concerned executable named “KB00207877.exe” is linked with our trojan:
Since the executable is found in the memory dump of our trojan executable, we are now sure that
Cridex modified the starting up registry key of the victim’s computer to make itself persistent. Deleting
this “KB00207877.exe” is needed to make a good cleanup of the infected machine.
Analysis Summary
This is the end of this basic Cridex malware analysis. I hope you liked this blog post! Below, is a short
sum up of the different Volatility commands used to analyze this dump:
You should now be able to “flag” (resolved) basic Forensics challs especially these following ones (found
on the famous RootMe platform):
Have fun! :)