First steps to volatile memory analysis

P4N4Rd1
13 min readJan 13, 2019

--

Welcome to my very first blog post where we will do a basic volatile memory analysis of a malware. This post is intended for Forensic beginners or people willing to explore this field.

In this short tutorial, we will be using one of the most popular volatile memory software analyzer: Volatility. This tool will help us to inspect a volatile memory dump of a potentially infected computer. This software will help us to retrieve useful information (such as: the running processes, the last files modified or even the user’s browser history…) stored in the memory of the computer.

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 here

The Cridex malware

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

$ volatility -f cridex.vmem imageinfo

With -f specifying your dump file and imageinfo the volatility plugin you want to use. You should obtain the following result:

Volatility Foundation Volatility Framework 2.6
INFO : volatility.debug : Determining profile based on KDBG search...
Suggested Profile(s) : WinXPSP2x86, WinXPSP3x86 (Instantiated with WinXPSP2x86)
AS Layer1 : IA32PagedMemoryPae (Kernel AS)
AS Layer2 : FileAddressSpace (/home/panardin/Challs/cridex.vmem)
PAE type : PAE
DTB : 0x2fe000L
KDBG : 0x80545ae0L
Number of Processors : 1
Image Type (Service Pack) : 3
KPCR for CPU 0 : 0xffdff000L
KUSER_SHARED_DATA : 0xffdf0000L
Image date and time : 2012-07-22 02:45:08 UTC+0000
Image local date and time : 2012-07-21 22:45:08 -0400

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.

$ volatility -f cridex.vmem --profile=WinXPSP2x86 pslistVolatility Foundation Volatility Framework 2.6
Offset(V) Name PID PPID Thds Hnds Sess
---------- -------------------- ------ ------ ------ -------- ------
0x823c89c8 System 4 0 53 240 ------
0x822f1020 smss.exe 368 4 3 19 ------
0x822a0598 csrss.exe 584 368 9 326 0
0x82298700 winlogon.exe 608 368 23 519 0
0x81e2ab28 services.exe 652 608 16 243 0
0x81e2a3b8 lsass.exe 664 608 24 330 0
0x82311360 svchost.exe 824 652 20 194 0
0x81e29ab8 svchost.exe 908 652 9 226 0
0x823001d0 svchost.exe 1004 652 64 1118 0
0x821dfda0 svchost.exe 1056 652 5 60 0
0x82295650 svchost.exe 1220 652 15 197 0
0x821dea70 explorer.exe 1484 1464 17 415 0
0x81eb17b8 spoolsv.exe 1512 652 14 113 0
0x81e7bda0 reader_sl.exe 1640 1484 5 39 0
0x820e8da0 alg.exe 788 652 7 104 0
0x821fcda0 wuauclt.exe 1136 1004 8 173 0
0x8205bda0 wuauclt.exe 1588 1004 5 132 0

An alternative to the pslist plugin can be used to display the processes and their parent processes: pstree

$ volatility -f cridex.vmem --profile=WinXPSP2x86 pstreeVolatility Foundation Volatility Framework 2.6
Name Pid PPid
-------------------------------------------------- ------ ------
0x823c89c8:System 4 0
. 0x822f1020:smss.exe 368 4
.. 0x82298700:winlogon.exe 608 368
... 0x81e2ab28:services.exe 652 608
.... 0x821dfda0:svchost.exe 1056 652
.... 0x81eb17b8:spoolsv.exe 1512 652
.... 0x81e29ab8:svchost.exe 908 652
.... 0x823001d0:svchost.exe 1004 652
..... 0x8205bda0:wuauclt.exe 1588 1004
..... 0x821fcda0:wuauclt.exe 1136 1004
.... 0x82311360:svchost.exe 824 652
.... 0x820e8da0:alg.exe 788 652
.... 0x82295650:svchost.exe 1220 652
... 0x81e2a3b8:lsass.exe 664 608
.. 0x822a0598:csrss.exe 584 368
0x821dea70:explorer.exe 1484 1464
. 0x81e7bda0:reader_sl.exe 1640 1484

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.

$ volatility -f cridex.vmem --profile=WinXPSP2x86 psxviewVolatility Foundation Volatility Framework 2.6
Offset(P) Name PID pslist psscan thrdproc pspcid csrss session deskthrd ExitTime
---------- -------------------- ------ ------ ------ -------- ------
0x02498700 winlogon.exe 608 True True True True..
0x02511360 svchost.exe 824 True True True True..
0x022e8da0 alg.exe 788 True True True True..
0x020b17b8 spoolsv.exe 1512 True True True True..
0x0202ab28 services.exe 652 True True True True..
0x02495650 svchost.exe 1220 True True True True..
0x0207bda0 reader_sl.exe 1640 True True True True..
0x025001d0 svchost.exe 1004 True True True True..
0x02029ab8 svchost.exe 908 True True True True..
0x023fcda0 wuauclt.exe 1136 True True True True..
0x0225bda0 wuauclt.exe 1588 True True True True..
0x0202a3b8 lsass.exe 664 True True True True..
0x023dea70 explorer.exe 1484 True True True True..
0x023dfda0 svchost.exe 1056 True True True True..
0x024f1020 smss.exe 368 True True True True..
0x025c89c8 System 4 True True True True..
0x024a0598 csrss.exe 584 True True True True..

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

$ volatility -f cridex.vmem --profile=WinXPSP2x86 connscanVolatility Foundation Volatility Framework 2.6
Offset(P) Local Address Remote Address Pid
---------- ------------------------- ------------------------- ---
0x02087620 172.16.112.128:1038 41.168.5.140:8080 1484
0x023a8008 172.16.112.128:1037 125.19.103.198:8080 1484
$ volatility -f cridex.vmem --profile=WinXPSP2x86 socketsVolatility Foundation Volatility Framework 2.6
Offset(V) PID Port Proto Protocol Address
---------- -------- ------ ------ --------------- ---------------
0x81ddb780 664 500 17 UDP 0.0.0.0
0x82240d08 1484 1038 6 TCP 0.0.0.0
0x81dd7618 1220 1900 17 UDP 172.16.112.128
0x82125610 788 1028 6 TCP 127.0.0.1
0x8219cc08 4 445 6 TCP 0.0.0.0
0x81ec23b0 908 135 6 TCP 0.0.0.0
0x82276878 4 139 6 TCP 172.16.112.128
0x82277460 4 137 17 UDP 172.16.112.128
0x81e76620 1004 123 17 UDP 127.0.0.1
0x82172808 664 0 255 Reserved 0.0.0.0
0x81e3f460 4 138 17 UDP 172.16.112.128
0x821f0630 1004 123 17 UDP 172.16.112.128
0x822cd2b0 1220 1900 17 UDP 127.0.0.1
0x82172c50 664 4500 17 UDP 0.0.0.0
0x821f0d00 4 445 17 UDP 0.0.0.0

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.

$ volatility -f cridex.vmem --profile=WinXPSP2x86 cmdlineVolatility Foundation Volatility Framework 2.6
********************************************************************
System pid: 4
********************************************************************
smss.exe pid: 368
Command line : \SystemRoot\System32\smss.exe
********************************************************************
csrss.exe pid: 584
Command line : C:\WINDOWS\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16
********************************************************************
winlogon.exe pid: 608
Command line : winlogon.exe
********************************************************************
services.exe pid: 652
Command line : C:\WINDOWS\system32\services.exe
********************************************************************
lsass.exe pid: 664
Command line : C:\WINDOWS\system32\lsass.exe
********************************************************************
svchost.exe pid: 824
Command line : C:\WINDOWS\system32\svchost -k DcomLaunch
********************************************************************
svchost.exe pid: 908
Command line : C:\WINDOWS\system32\svchost -k rpcss
********************************************************************
svchost.exe pid: 1004
Command line : C:\WINDOWS\System32\svchost.exe -k netsvcs
********************************************************************
svchost.exe pid: 1056
Command line : C:\WINDOWS\system32\svchost.exe -k NetworkService
********************************************************************
svchost.exe pid: 1220
Command line : C:\WINDOWS\system32\svchost.exe -k LocalService
********************************************************************
explorer.exe pid: 1484
Command line : C:\WINDOWS\Explorer.EXE
********************************************************************
spoolsv.exe pid: 1512
Command line : C:\WINDOWS\system32\spoolsv.exe
********************************************************************
reader_sl.exe pid: 1640
Command line : "C:\Program Files\Adobe\Reader 9.0\Reader\Reader_sl.exe"
********************************************************************
alg.exe pid: 788
Command line : C:\WINDOWS\System32\alg.exe
********************************************************************
wuauclt.exe pid: 1136
Command line : "C:\WINDOWS\system32\wuauclt.exe" /RunStoreAsComServer Local\[3ec]SUSDSb81eb56fa3105543beb3109274ef8ec1
********************************************************************
wuauclt.exe pid: 1588
Command line : "C:\WINDOWS\system32\wuauclt.exe"

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).

$ volatility -f cridex.vmem --profile=WinXPSP2x86 procdump -p 1640 --dump-dir .Volatility Foundation Volatility Framework 2.6
Process(V) ImageBase Name Result
---------- ---------- -------------------- ------
0x81e7bda0 0x00400000 reader_sl.exe OK: executable.1640.exe
$ volatility -f cridex.vmem --profile=WinXPSP2x86 memdump -p 1640 --dump-dir .Volatility Foundation Volatility Framework 2.6
************************************************************************
Writing reader_sl.exe [ 1640] to 1640.dmp

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.

$ strings 1640.dmp | grep -Fi "41.168.5.140" -C 5ABACFPFPENFDECFCEPFHFDEFFPFPACAB
DpI8
POST /zb/v_01_a/in/ HTTP/1.1
Accept: */*
User-Agent: Mozilla/5.0 (Windows; U; MSIE 7.0; Windows NT 6.0; en-US)
Host: 41.168.5.140:8080
Content-Length: 229
Connection: Keep-Alive
Cache-Control: no-cache
>mtvR
`06!

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:

$ strings 1640.dmp | less...
*hsbc.co.uk*
*ablv.com*
*accessbankplc.com*
*alphabank.com.cy*
*baltikums.com*
*baltikums.eu*
*banesco.com.pa*
*bankaustria.at*
*banknet.lv*
*bankofcyprus.com*
*bobibanking.com*
*butterfieldonline.ky*
*cimbanque.net*
*cs.directnet.com*
*directnet.com*
*danskebanka.lv*
*ebank.laiki.com*
*ebank.rcbcy.com*
*ebemo.bemobank.com*
*e-norvik.lv*
*eurobankefg.com*
*eurobankefg.com.cy*
*ekp.lv*
*fbmedirect.com*
*hblibank.com*
*hellenicnetbanking.com*
*hiponet.lv*
*hkbea*
*ibanka.seb.lv*
*ib.baltikums.com*
*geonline.lv*
*ib.dnb.lv*
*bib.lv*
*ib.snoras.com*
*i-linija.lt*
*loyalbank.com*
*marfinbank.com.cy*
*multinetbank.eu*
*nordea.com*
*secure.ltbbank.com*
*secure.ltblv.com*
*swedbank.lv*
*norvik.lv*
*online.alphabank.com.cy*
*online.citadele.lv*
*online.lkb.lv*
...

A list of Bank domain websites. By looking at the process memory we now have more reasons to be suspicious about “Reader_sl.exe”.
Let’s now see if the executable is malicious or not.

We have two different possible ways of doing this at this point:

  • 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:

  • An odd process Reader_sl.exe PID 1640 with Explorer as a ParentPID 1484
  • An opened connection towards 41.168.5.140:8080 used by the PID 1484
  • Bank domains and 41.168.5.140 found in the dump of the process 1640
  • 1640 executable detected as malicious Trojan by Sandboxing websites

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/”).

$ strings 1640.dmp | grep -Fi "/zb/v_01_a/in/"http://188.40.0.138:8080/zb/v_01_a/in/cp.php
POST /zb/v_01_a/in/ HTTP/1.1
http://188.40.0.138:8080/zb/v_01_a/in/cp.php
http://188.40.0.138:8080/zb/v_01_a/in/cp.php

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 ...

results for 41.168.5.140
------------------------
Record Type Query Answer First seen Last seen # times TTL
a ns8.dfudont.ru 41.168.5.140 2013-01-24 09:46 ...
a support.tray-international.com 41.168.5.140 2012-09-11 ...
a seledkindoms.ru 41.168.5.140 2012-06-21 17:03 ...

At this point we should then proceed and analyze each possible hostname to see if they could be linked to our trojan (time of the DNS record correspond to the time of the infection?, legitimate website? …). We would then give those IOCs to the SOC team for a proper detection of this trojan infection on the company’s infrastructure using custom SIEM detection rules.

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.

These registry keys are stored in the following path:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run, RunOnce, RunOnceEx
We can then use the volatility tool to navigate into hives and print the content of registry keys.

$ volatility -f cridex.vmem --profile=WinXPSP2x86 hivelistVolatility Foundation Volatility Framework 2.6
Virtual Physical Name
---------- ---------- ----
0xe18e5b60 0x093f8b60 \Device\HarddiskVolume1\Documents and Settings\Robert\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat
0xe1a19b60 0x0a5a9b60 \Device\HarddiskVolume1\Documents and Settings\Robert\NTUSER.DAT
0xe18398d0 0x08a838d0 \Device\HarddiskVolume1\Documents and Settings\LocalService\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat
0xe18614d0 0x08e624d0 \Device\HarddiskVolume1\Documents and Settings\LocalService\NTUSER.DAT
0xe183bb60 0x08e2db60 \Device\HarddiskVolume1\Documents and Settings\NetworkService\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat
0xe17f2b60 0x08519b60 \Device\HarddiskVolume1\Documents and Settings\NetworkService\NTUSER.DAT
0xe1570510 0x07669510 \Device\HarddiskVolume1\WINDOWS\system32\config\software
0xe1571008 0x0777f008 \Device\HarddiskVolume1\WINDOWS\system32\config\default
0xe15709b8 0x076699b8 \Device\HarddiskVolume1\WINDOWS\system32\config\SECURITY
0xe15719e8 0x0777f9e8 \Device\HarddiskVolume1\WINDOWS\system32\config\SAM
0xe13ba008 0x02e4b008 [no name]
0xe1035b60 0x02ac3b60 \Device\HarddiskVolume1\WINDOWS\system32\config\system
0xe102e008 0x02a7d008 [no name]

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:

$ strings 1640.dmp | grep -Fi "KB00207877.exe"KB00207877.exe
C:\Documents and Settings\Robert\Application Data\KB00207877.exe(,
KB00207877.EXEn
KB00207877.exe
KB00207877.exe
C:\Documents and Settings\Robert\Application Data\KB00207877.exe(,

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:

# What type of dump am I going to analyze ?
$ volatility -f MyDump.dmp imageinfo

# Which process are running
$ volatility -f MyDump.dmp --profile=MyProfile pslist
$ volatility -f MyDump.dmp --profile=MyProfile pstree
$ volatility -f MyDump.dmp --profile=MyProfile psxview


# List open TCP/UDP connections
$ volatility -f MyDump.dmp --profile=MyProfile connscan
$ volatility -f MyDump.dmp --profile=MyProfile sockets
$ volatility -f MyDump.dmp --profile=MyProfile netscan


# What commands were lastly run on the computer
$ volatility -f MyDump.dmp --profile=MyProfile cmdline
$ volatility -f MyDump.dmp --profile=MyProfile consoles
$ volatility -f MyDump.dmp --profile=MyProfile cmdscan


# Dump processes exe and memory
$ volatility -f MyDump.dmp --profile=MyProfile procdump -p MyPid --dump-dir .
$ volatility -f MyDump.dmp --profile=MyProfile memdump -p MyPid --dump-dir .


# Hive and Registry key values
$ volatility -f MyDump.dmp --profile=MyProfile hivelist
$ volatility -f MyDump.dmp --profile=MyProfile printkey -K "MyPath"

You should now be able to “flag” (resolved) basic Forensics challs especially these following ones (found on the famous RootMe platform):

  • Forensic - Command & Control - level 2
  • Forensic - Command & Control - level 3
  • Forensic - Command & Control - level 4

Have fun! :)

--

--