August 2, 2012

Cridex Analysis using Volatility

Update 1 -  August 5, 2012 - located at end of post


Update 2 -  August 7, 2012 - located at end of post


I had read previous analysis reports about Cridex from various sites as M86 Security and Kahu Security. At the time, I filed this under "another banking trojan" to track, and moved on to to other things.  However Cridex once again piqued my interest when I saw an excellent analysis by Kimberly at StopMalvertising.  I took particular attention to her listing of the Cridex C&C servers she observed, as several of these IP blocks were familiar to me. More on this later.   Having obtained the same Cridex sample analyzed by Kimberly,  I was interested to see how Volatility could be used to analyze it.  This Cridex sample had MD5 hash, 734aadd62d0662256a65510271d40048. I executed the sample and dumped the memory for analysis.  A copy of this memory dump is linked at the bottom of this post.

Using the Volatility 'plist' command, we can see a list of the running processes. However it's instructive to use this in conjunction with the 'psscan' command in order to see those processes that have terminated, are unlinked, or hidden.  In this case, no discrepancies between the two commands jump out at me, but I do notice a couple of things.   First, I see a process, reader_sl.exe, PID1640 start exactly at the same time as its parent process, explorer.exe, PID1484.  I see that the parent process ID for explorer.exe is 1464, which is not listed in either 'pslist' or 'psscan'.  reader_sl.exe is a supposedly a safe process, associated with Adobe Speed Launcher, but the launch chain for this seems odd, so I'll keep note of this for now. Next, I see a second wuauclt.exe process start about 15 seconds after the first.  This isn't a major flag, but just something to note.

pslist command
psscan command

The next useful Volatility command that I use for malware analysis is the 'connections' and the 'connscan' commands. Again, running both of these will allow you to see variances, as 'connscan' will show artifacts from previous connections.

connections & connscan commands
Note that 'connections' shows that PID 1484, explorer.exe had an active connection to remote IP address 41.168.5.140 on port 8080.  'connscan' shows an artifact of a previous connection by PID 1484 to remote IP address 125.19.103.198, also on port 8080.  A quick 'whois' shows:

41.168.5.140
netname: NEOTEL
descr: NEOTEL PTY LTD
country: ZA

125.19.103.198
descr: Bharti Tele-Ventures Limited
descr: NEW DELHI
country: IN

Next, running 'sockets' and 'sockscan' will show any listening sockets that may have been initiated by a running process. As in 'conscan', 'sockscan' will show any detected artifacts from previous sockets.  In this case, we see that PID 1484, explorer.exe, opened a listening socket on port 1038 approx. 2 minutes after PID 1484 was created. 

sockets and sockscan commands
Running the 'malfind' command against our two suspect processes yields the following:


malfind command on PID 1484 & 1640
In this output, we see that the explorer.exe, PID1484 and reader_sl.exe, PID1640 processes have a PE section located at 0x1460000 and 0x3d0000 respectively.  By using the "-D" switch, 'malfind' can dump those identified segments to a dump directory for further analysis. 

We now enumerate the mutant/mutex objects for the two processes under review.  Note that I used the Volatility 'handles' command, with a subtype selection of "Mutant" in order to specifically select the mutant/mutexes associated with PID 1484 and 1640.  The 'mutantscan' command will give additional information such as its signaled state, its client ID, and which thread acquired the mutant.

process mutexes for PID 1484 & 1640
Via some Google queries, we learn that several of these mutex objects have been seen in other malware, notably:
  • 746bbf3569adEncrypt
  • _SHuassist.mtx
  • SHIMLIB_LOG_MUTEX
  • XMR8149A9A8
Next, we'll dump the VAD segments of each of these processes, run 'strings',  and look for anything interesting. 

vaddump command
'strings' output section from PID 1484, explorer.exe

'strings' output section from PID 1640, reader_sl.exe

Note the advantage of dumping the VAD segments as opposed to the entire process memory is that you can see which VAD node section the 'strings' hit was located.  In this section, we find a list of banks and financial institutions.   Here is the contents of the Cridex configuration specifically containing references to financial institutions. 



In addition to the list above, examining these VAD dumps also shows HTML code referencing or representing web pages of various financial organizations.  The code seems to indicate that these sections are part of the web injection code that is used to obtain personal information from the banking customer.  In my test of Cridex, I did not launch a web browser or continue additional interaction with my infected host.  If I had visited a URL containing these strings, it is believed that Cridex would attempt to log or capture my input, and redirect that personal information back to the controller.

While we're looking for strings, let's see what shows up for the IP addresses 41.168.5.140 & 125.19.103.198 that were seen in the Volatility "connscan" command.


Searching for the directory path after the IP addresses gives us another related IP address, 188.40.0.138:

So via various string searches and some grepping in the VAD dump directory for PID1484 & PID1640 we find these IP addresses of interest:
  • 190.81.107.70
  • 41.168.5.140
  • 85.214.204.32
  • 210.56.23.100
  • 211.44.250.173
  • 125.19.103.198
  • 188.40.0.138
Maltego lets me draw a pretty picture of the IPs, country of registration, and ASN.

Cridex IP addresses, ASN, and country of registration.
Doing some additional research, I noted that at one time or another, several domain names (now suspended) utilized all of the above listed Cridex IPs (except for 188.40.0.138). In fact, these domains each utilized the same 11 to 14 IP addresses, including the Cridex IPs for their DNS "A" records during their brief activity.  Looking at the 'whois' for a sample of these domains shows an entirely different set of IPs used for their NS records... but I digress.
domain:        VALIDATORONMEE.RU
nserver:       ns1.validatoronmee.ru. 62.213.64.161
nserver:       ns2.validatoronmee.ru. 195.62.52.69
nserver:       ns3.validatoronmee.ru. 62.76.191.172
nserver:       ns4.validatoronmee.ru. 41.66.137.155
nserver:       ns5.validatoronmee.ru. 83.170.91.152
nserver:       ns6.validatoronmee.ru. 85.214.204.32
state:         REGISTERED, NOT DELEGATED, UNVERIFIED
person:        Private Person
registrar:     NAUNET-REG-RIPN
admin-contact: https://client.naunet.ru/c/whoiscontact
created:       2012.04.10
paid-till:     2013.04.10

 domain:        POLUICENOTGO.RU
nserver:       ns1.poluicenotgo.ru. 62.76.41.3
nserver:       ns2.poluicenotgo.ru. 62.213.64.161
nserver:       ns3.poluicenotgo.ru. 195.88.242.10
nserver:       ns4.poluicenotgo.ru. 41.66.137.155
nserver:       ns5.poluicenotgo.ru. 83.170.91.152
nserver:       ns6.poluicenotgo.ru. 85.214.204.32
state:         REGISTERED, NOT DELEGATED, UNVERIFIED
person:        Private Person
registrar:     NAUNET-REG-RIPN
admin-contact: https://client.naunet.ru/c/whoiscontact
created:       2012.04.15
paid-till:     2013.04.15

 domain:        VITALITYSOMER.RU
nserver:       ns1.vitalitysomer.ru. 62.213.64.161
nserver:       ns2.vitalitysomer.ru. 195.62.52.69
nserver:       ns3.vitalitysomer.ru. 62.76.191.172
nserver:       ns4.vitalitysomer.ru. 41.66.137.155
nserver:       ns5.vitalitysomer.ru. 83.170.91.152
nserver:       ns6.vitalitysomer.ru. 85.214.204.32
state:         REGISTERED, NOT DELEGATED, UNVERIFIED
person:        Private Person
registrar:     NAUNET-REG-RIPN
admin-contact: https://client.naunet.ru/c/whoiscontact
created:       2012.04.10
paid-till:     2013.04.10
There is much more that you can do with this Cridex memory dump. For example, you can use 'apihooks' on the two processes, then drop into 'volshell' and browse through the pages. You could find the loaded DLLs, or extract a process of interest.  

For your added research, I've posted a link to the Cridex memory image below.  I didn't extract other forensic objects for this sample, but as I mentioned in my last post, I plan to do that for other samples going forward.
-------------------------------------------------------------------------------------------------------------------------------

Update 1 - August 5, 2012


In the comments section, Tamer Hassan posted a question referencing PID 1464. That PID is most likely a terminated process where 'psscan' didn't find any associated remnants. However it might be interesting to search for references to executable files.  Since we know that PID 1464 was the parent to PID 1484, it's worth looking for registry artifacts typically used by malware.  Volatility allows you to carve through the the registry that is resident in memory and display subkeys, values, and data. In this example, I looked for keys and values associated with "Software\Microsoft\Windows\CurrentVersion\Run" This is accomplished via the 'printkey' command:

python vol.py -f /home/ezio77/cridex.vmem --profile=WinXPSP2x86 printkey -K "Software\Microsoft\Windows\CurrentVersion\Run"

Since 'printkey' will go through all hives, you will get multiple hits related to the key in your search.  After displaying multiple hives each with a Last Update date of either 2012-04-12 or 2012-04-13,  you'll see the following:

Registry: \Device\HarddiskVolume1\Documents and Settings\Robert\NTUSER.DAT
Key name: Run (S)
Last updated: 2012-07-22 02:31:51 
Subkeys:
Values:
REG_SZ        KB00207877.exe  : (S) "C:\Documents and Settings\Robert\Application Data\KB00207877.exe"

Perhaps KB00207877.exe was PID 1464?  It's not clear via Volatility at this point, but it's most likely just a copy of the original with an updated registry key. Referring to Microsoft's encyclopedia entry for "Worm:Win32/Cridex.G", they reference:

subkey: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
Sets value: "KB<eight-digit number>.exe"
With data: "%AppData%\KB<eight-digit number>.exe"

Additionally, the VirusTotal analysis for this sample shows references to this naming convention as well. (Scroll to bottom and select "Additional Information")

In any case, it's good info for further analysis, including examining other registry hives.
-------------------------------------------------------------------------------------------------------------------------------

Update 2 - August 7, 2012

Michael Ligh, was kind enough to drop me a note about the parent of 'explorer.exe'. Michael is one of the key contributors to the Volatility project, as well as one of the authors of the "Malware Analyst's Cookbook and DVD" . He referenced an excerpt from his book where it explains that the parent of 'explorer.exe' is 'userinit.exe', which upon completion, will terminate, leaving 'explorer.exe' without a parent.  From the "Malware Analyst's Cookbook", pg 585:
Details aren’t available for the process with Pid 1536 (which appears to have created
explorer.exe). However, based on what you know about the boot sequence,
Pid 1536 probably belonged to userinit.exe—but it has since exited. Winlogon.exe
launches userinit.exe, which in turn launches explorer.exe. Once userinit.exe is
finished, it terminates, leaving explorer.exe without a parent process. It is still possible
to determine a process’s parent, even after the parent exits, by looking at the
_EPROCESS.InheritedFromUniqueProcessId field.
Many thanks Michael! 

-------------------------------------------------------------------------------------------------------------------------------
cridex_memdump.zip (40MB)
-------------------------------------------------------------------------------------------------------------------------------


Posted by at 4 comments:
Labels: , , ,

July 31, 2012

Sharing of Forensically Interesting Objects

As I go through various forensic cases and malware studies, I often find myself producing memory dumps of the host systems under examination.  I also dump registry hives and other objects related to my analysis.  I gave some thought as to whether there would be a benefit to the community in my sharing of these objects.  A few months back, I had a nice email exchange with Harlan Carvey of the Windows Incident Response blog.  We discussed various ways in which the malware analysis community could better collaborate with the forensics community, particularly in the area of sharing objects for analysis.  I had mentioned my thoughts as far as sharing memory dumps and other objects from various malware cases that I was working on.  Harlan encouraged me to move forward on this, and provide forensically "interesting" objects, just short of a disk image that would require Microsoft licensing.

So going forward, I will be posting analysis of various malware, along with objects consisting of memory dumps, registry hives, pcaps, and anything else that might be interesting.  You can use analysis tools such as Volatility or Mandiant's Redline with the memory dumps, while RegRipper is a very cool tool to use on registry hives.  It would be great to hear feedback on how you'll be using these objects, and the tools used in your analysis.

I'll rely on the community to let me know what is useful, and what else they might like to see.  I'd also be happy to take in any samples or items for analysis, which I'll post, as well as the objects.  None of what I post here will be related to my dayjob. It will be only what I research for myself, my other efforts, or as part of DeepEnd Research.

Please feel free to contact me with any ideas or suggestions. I'm looking forward to making this a useful resource for all who are interested!  Many thanks to Harlan for the encouragement!


Posted by at 4 comments:
Labels: , , , ,
Subscribe to: Posts (Atom)