December 30, 2013

Another look at a cross-platform DDoS botnet

I learned from a recent "Malware Must Die" post about a Linux malware sample that is associated with DNS amplification attacks.  As mentioned in the MMD post, several researchers have posted on this, or similar malware.  Since I'm particularly interested in Linux malware, especially if it has a DDoS component, I thought I'd also take a look.

I was able to get the malware to execute on my Linux sandbox and connect to the C&C.  While I've yet to see any DDoS related activity, I did pcap the C2 comms and snap an image for Volatility analysis.  Links to the pcap and memory image can be found at the bottom of this post. 

The malware was downloaded from hxxp://198.2. [.] 192.204:22/disknyp
The MD5 hash value of the sample I obtained is 260533ebd353c3075c9dddf7784e86f9
The C2 is located at 190.115.20.27:59870

Referencing the supplied pcap, the compromised host connected to the C2 at 18:46 EST. Upon connection to the C2, the compromised host sends information about the current Linux kernel, in this case, "Linux 2.6.32-33-generic-pae"

bot sending kernel info to C2

It's interesting to note that the bot's C2 communications is via a persistent connection.  Unlike typical HTTP bot check-in traffic, this bot maintains a connection to the remote host on port 59870.  Since this is all one huge session, if you attempt "Follow TCP stream" in Wireshark, it will take a bit of time to present the output.

The C2 then sends 4 bytes,  "0x04 0x00 0x00 0x00" upon which the bot sends back 27 bytes of all 0x00.

At 21:13, the C2 sends 75 bytes of hex: 

Initial 75 byte sequence from C2 to bot

Approx. every thirty seconds, the C2 sends a new 75 byte sequence to the bot, for example:

01:00:00:00:43:00:00:00:00:fd:05:00:00:00:00:00:00:01:00:00:00:01:00:00:00:80:d4:07:c6:9c:50:00:01:00:00:00:00:00:00:00:1e:00:00:00:00:04:00:00:00:04:00:00:10:27:60:ea:ac:f5:a5:8f:ac:f5:a5:8f:00:00:00:00:00:d4:07:c6:9c:50:00

01:00:00:00:43:00:00:00:00:fe:05:00:00:00:00:00:00:01:00:00:00:01:00:00:00:80:d4:07:c7:d4:50:00:01:00:00:00:00:00:00:00:1e:00:00:00:00:04:00:00:00:04:00:00:10:27:60:ea:ac:f5:a5:8f:ac:f5:a5:8f:00:00:00:00:00:d4:07:c7:d4:50:00

01:00:00:00:43:00:00:00:00:ff:05:00:00:00:00:00:00:01:00:00:00:01:00:00:00:80:d4:07:c6:9b:50:00:01:00:00:00:00:00:00:00:1e:00:00:00:00:04:00:00:00:04:00:00:10:27:60:ea:ac:f5:a5:8f:ac:f5:a5:8f:00:00:00:00:00:d4:07:c6:9b:50:00

Byte offset decimal 09 appears to be a counter, incrementing by one each time on each sequence from the C2.  The contents at decimal offset 28 and and 71 initially vary between 0xC6 and 0xC7.  This continues until 22:06 EST when the pattern changes and varied values are seen:

01:00:00:00:43:00:00:00:00:1d:06:00:00:00:00:00:00:01:00:00:00:01:00:00:00:80:73:ee:ed:f5:58:1b:01:00:00:00:00:00:00:00:0c:00:00:00:00:04:00:00:00:04:00:00:10:27:60:ea:ac:f5:a5:8f:ac:f5:a5:8f:00:00:00:00:00:73:ee:ed:f5:58:1b

01:00:00:00:43:00:00:00:00:1e:06:00:00:00:00:00:00:01:00:00:00:01:00:00:00:80:7a:e0:22:c7:58:1b:01:00:00:00:00:00:00:00:0c:00:00:00:00:04:00:00:00:04:00:00:10:27:60:ea:ac:f5:a5:8f:ac:f5:a5:8f:00:00:00:00:00:7a:e0:22:c7:58:1b

01:00:00:00:43:00:00:00:00:1f:06:00:00:00:00:00:00:01:00:00:00:01:00:00:00:80:0e:11:5f:4a:58:1b:01:00:00:00:00:00:00:00:0c:00:00:00:00:04:00:00:00:04:00:00:10:27:60:ea:ac:f5:a5:8f:ac:f5:a5:8f:00:00:00:00:00:0e:11:5f:4a:58:1b

01:00:00:00:43:00:00:00:00:20:06:00:00:00:00:00:00:01:00:00:00:01:00:00:00:80:3d:84:e6:15:5b:1b:01:00:00:00:00:00:00:00:0c:00:00:00:00:04:00:00:00:04:00:00:10:27:60:ea:ac:f5:a5:8f:ac:f5:a5:8f:00:00:00:00:00:3d:84:e6:15:5b:1b

The bot's replies again replies with a 27 byte sequence, however decimal offset 19 now has a value that will vary between 0 and 2.

00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:01:00:00:00:00:00:00:00
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:02:00:00:00:00:00:00:00
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00


Volatility

Some basic Volatility analysis of the memory image yields the following:

linux_pslist
linux_pslist
The 'disknyp' process started at 23:45 UTC with PID 1241.  Ran with user privs and no child processes were noted.



linux_lsof -p1241
linux_lsof for PID 1241
Process 'disknyp', PID 1241 has /dev/null open as well as socket:[6931]



linux_proc_maps
linux_proc_maps for PID 1241
Note that /tmp/disknyp is the path where 'disknyp' was originally executed.  Dumping the two segments at '/usr/tmp' produces two files, 'task.1241.0x8048000.vma' and 'task.1241.0x8168000.vma'.   
Running 'file' on the segments shows:
task.1241.0x8048000.vma: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
Dumping strings for that segment shows:

section of 'strings' output for PID 1241 segment 0x8048000
We note the string "fake.cfg" that was mentioned in other posts related to this malware.  Attempting to find the file in the original /tmp directory:


linux_find_file for 'fake.cfg'

linux_yarascan
Let's use the 'yarascan' plugin to see if there are any other references to 'fake.cfg' in this image.

searching for other references to 'fake.cfg' using the linux_yarascan plugin
We see that the string 'fake.cfg' is only found in PID 1241, 'disknyp'.  Again using the 'linux_find_file' plugin, we can dump the contents of 'fake.cfg' located at inode 0xed9dc088. 

Contents of 'fake.cfg'
Final Thoughts

This appears to be some Proof of Concept or "testing" malware.  There are several aspects to this sample that make me wonder if it was just put out there to see how quickly it would be detected and analyzed.
  • Analysis of the original file as downloaded from hxxp://198.2. [.] 192.204:22/disknyp that it is statically linked, not stripped.
  • The C2 communications is somewhat noisy.  Maintaining a persistent connection with checkins every few seconds is not very stealthy.
  • No attempt to hide the process.  In hours of running this, I didn't see any child processes or variance in the process on the local host.
  • 'fake.cfg' is created in the malware's working directory. 'fake.cfg' really?
  • As I mentioned earlier in the post, I have yet to see any DoS related traffic from this sample.  I'm also not aware of DoS activity being seen by other researchers.  If anyone has learned otherwise, I'd love to hear from you!

December 17, 2013

A Forensic Overview of a Linux perlbot

It's fairly old news that exploit attempts against PHP, ColdFusion, and Content Management Systems are quite common these days.  Most of these attempts target old vulnerabilities, hoping to hit enough neglected servers to make it worthwhile.   In some cases, a particular exploit may succeed against a high value server, leading to some pretty significant data leakage.  In others, the attacker is going for volume, where they can make use of a large number of compromised hosts. 

I recently noticed a PHP exploit attempt coming from several HK and CN IP addresses, so I allowed the exploit on my honeypot and documented the results. The resulting activity was very reminiscent of the the early botnet days, with IRC Command and Control, as well as the use of the compromised host as a scanning tool.  
I thought it might be interesting to show this example of a successful PHP exploit against a linux server, what it does, and how you might go about some basic analysis. I'll conclude by showing how some basic memory forensics can be performed on this type of incident using Volatility. 

In this example, the remote attacker attempts the following PHP exploit:

PHP exploit attempt against CVE-2012-1823

This exploit attempt is against an old vulnerability (CVE-2012-1823) which allows a remote attacker to inject arbitrary code via command line options within the HTTP query string.
When decoded, the attack string is:


Decoded PHP exploit string

The rest of the HTTP POST reveals the attempted commands to be executed if the exploit was successful:

Attempted command injection string

This string of commands instructs the compromised server to do the following:
  • Change working directory to /var/tmp
  • Remove any file named "a.pdf" from that directory
  • Download file "a.pdf" from a domain under the attacker's control and save it to /var/tmp. The "a.pdf" file is actually a perl script, which is given a "pdf" file extension.
  • Execute the perl script "a.pdf"
  • Finally, delete the perl script, "a.pdf"
To ensure downloading success of the remote script, the attacker repeats these instructions using 'curl', 'fetch', and 'lwp-get'.

Network packet capture reveals the overall activity of the injected script.  Upon execution, the script sleeps for awhile, then connects to the IRC C2 on 'vafel.pexit.cu.cc', port 45129.

Perl script connecting to remote IRC server on vafel.pexit.cu.cc

A short time later, the compromised host is instructed to fetch another script, "ins_h.sh" this time from m1.pexit.cu.cc
Compromised server instructed to download bash script 'ins_h.sh'
The contents of the "ins_h.sh" script shows among other things, the attacker creating hidden directories on the linux server, fetching source code of another tool (h.c), compiling it, and modifying the crontab.
Not long after this, a fair amount of assorted files were downloaded to the compromised host.  Among these include mining software, development libraries, and compiling tools. Also downloaded were a large collection of linux local privilege escalation exploits. 

After the attacker had the box configured the way he wanted it, activity related to Bitcoin and Primecoin mining soon began.   Of particular note was the use of the Stratum Mining Protocol connecting to a pool server on 37.251.139.161.

Bitcoin Stratum mining protocol traffic

Most servers that are injected with these various scripts are then used for a variety of tasks, including DDoS, vulnerability scanning, and exploiting.  The mining of virtual currency is now often seen running in the background during the attacker's "downtime".  The Internet Storm Center recently posted an entry, "The case of Minerd", which discusses the increasing use of compromised servers being used to mine virtual currency.  

Volatility

Let's now do a bit of memory forensics on the RAM image of this particular compromised host.  We'll use Volatility version 2.3.1 which has the ability to analyze Linux images.  In order to do this, you'll have to supply the appropriate Linux profile.  Creating a profile is very easy, but it needs to be done for the appropriate distribution and kernel in use.  I'd recommend bookmarking Ken Pryor's Github site, where Ken is building a repository of Linux Volatility profiles.

The system under analysis is an Ubuntu 10.04 server, with kernel version 2.6.32-33-generic-pae.
We'll first take a look at the active processes on the system via the 'linux_pslist' plugin.

'linux_pslist' output

Note the timestamps for PID 1517 (httpds) and PID 27157 (rsyslogd) are much later than those processes listed above it.  Since the earlier processes and their relative timestamps resemble a Linux startup routine, the two later processes are of interest.   Note also that these processes show a User ID and Group ID of 1002, which Ubuntu allocates to a user account.

The Volatility plugin, 'linux_psaux' behaves similar to the Linux command 'ps aux', so it is able to show  the command line arguments used at process invocation.  Running this against our image shows:

'linux_psaux' output

So the process named 'httpds', with PID 1517 was started with "/usr/bin/httpd" and process 'rsyslogd', with PID 27157 was invoked with command line arguments "-B -c".  We'll note to check 'httpd' in /usr/bin if we obtain a disk image of the compromised server.  Researching the 'rsyslogd' command, we learn that "-B" is not a valid option, so this process remains suspicious. 

While the pslist command finds running processes by walking the linked list of Linux task_struct-> tasks, the  'linux_pidhashtable' command walks the hashtable, which hashed by process identifier (pid).  This may help in finding hidden processes.

'linux_pidhashtable' output

Note the four additional  'rsyslogd' processes discovered by the 'linux_pidhashtable' plugin.

In cases like this, it's always a good practice to check the server's networking information.  Volatility has a number of networking plugins that will help identify remote connections and the processes that initiated them.  For example, the 'linux_netstat' plugin behaves just like the Linux 'netstat'  command, and will list active network connections, as well as listening sockets.  In this case, we see suspicious processes, PID 1517, and PID 27157 as the processes associated with established network connections to remote IP addresses.  
  
'linux_netstat' output

It's also a good idea to run the 'linux_route_cache' plugin, to display the routing table cache.  This may reveal any old connections that may not be seen via the 'linux_netstat' plugin.

'linux_route_cache' output

Now that we've established PIDs 1517 and 27157 as suspicious processes,  let's get a list of all the open files and paths associated with each.  Similar to using 'lsof' on a live, running Linux system, we'll use the Volatility plugin 'linux_lsof' here.  

'linux_lsof' output for PID 1517
'linux_lsof' output for PID 27157

Note that both PID 1517 and 27157 have two open files in common.  One is socket: [7916], and the other is the httpd.pid file in the hidden directory "/tmp/.ICE-unix/-log/".

Another useful Volatility plugin is 'linux_proc_maps'. This plugin will display the details of process memory, including shared libraries.  Details include the start and end location, inode and flag for each section.  This is very valuable information to be gleaned from memory during a forensic investigation.  For example, on PID 1517 we get the following:

'linux_proc_maps' output for PID 1517

We see the same hidden directory mentioned earlier, but now referring to filename 'httpds'.  The inode for this file is seen as 405961.  The 'linux_proc_maps' plugin has an output switch that allows for the dumping of the listed segments.  However to recover the complete, intact file, we need to recover it from the page cache, which holds in memory all the pages pertaining to a file.   We can do this via the 'linux_find_file' plugin.  This plugin will find the address to the file's inode, then allow you to dump the cached file contents from memory.  So for the 'httpds' file at inode 405961:

python vol.py -f /home/abc/pexit.vmem --profile=LinuxUbuntu1004_pae32-33x86 linux_find_file -F "/tmp/.ICE-unix/-log/httpds"

'linux_find_file' output for 'httpds' file

We then use the 'linux_find_file' plugin with the -O option, passing the address of the inode in order to extract the file.  After extraction, we can run 'strings' on it and see contents of significance:

'strings' of recovered 'httpds' file from hidden directory
These are just a few examples of how Volatility can assist in your forensic analysis of a compromised host.  A good deal of what is gleaned from Volatility can then be correlated to the disk image examination.  
I've posted the Linux memory image for this perlbot at the bottom of this post. Be sure to get the Linux profile, "Ubuntu1004_pae32-33.zip" from Ken Pryor's site.  You'll need it to run Volatility against this image. 

I hope this post shed some light on one example of a successful PHP exploit and the resulting script injection.  Besides ensuring that Internet facing servers are properly patched and hardened, knowing how to quickly track such a compromise should be part of best practices.  Across my honeypots, I'll see dozens of these a day, including Linux ELF files, perlbots, and vintage shells.   

While these injected perl and shell scripts are typically considered the patio gnats of the Internet, more annoying than anything else, they do have the potential to cause considerable harm. 

Memory image of pexit perlbot


November 17, 2013

Analyzing Malware? Don't forget to disable Windows Defender

Life's been pretty busy this past year.  In December 2012, I started at GWU on their security team, and in April of 2013, my father passed after a long and difficult illness.  So even though I've continued my studies in forensics, threats, and malware, I haven't written anything in quite some time.  I'm looking forward to posting again here, and at DeepEnd Research.

This post is more along the lines of "tool preparation" as it involves making some tweaks to your analysis system, especially if conducting memory forensics.

A few months ago, I was doing some malware analysis on a Windows 7 memory image.  I noticed a bunch of odd artifacts in the RAM image pertaining to some questionable domain names.  The domain names really didn't relate to the malware under analysis, so I was curious as to what was going on.   I had no AntiVirus or Microsoft's Malicious Software Removal Toolkit installed.   I had thought that I might have been using a non-sterile VM for analysis, so I tried reverting and even reinstalling Windows 7.
I noticed that an original installation of Windows 7 did not exhibit these artifacts, but after a full Windows update, they appeared.  I asked around on a few mailing lists, but most of the responses encouraged me to check for either a tainted VM, or some sort of Security software that I had neglected to consider.  That in fact, turned out to be exactly the case.  So what was it that I was seeing?

The test I did involved a very basic 'strings' dump of the full memory image, grepping for ".ru" and ".com" domains.  The results of this are seen below:

Since posting the domain list to the blog page is triggering many viewer's AntiVirus, I'll add download links for the text files.  

Note that this is a grep of the entire RAM image, not looking specifically to what process may be associated with these artifacts.  To do that, we'll use 'Volatility'

I'll first use the 'yarascan' command to search for a few of the domains in order to determine the associated process:
Volatilty 'yarascan' command used to locate strings in a process.
While many of the domains located in the full RAM image did not return any hits in Volatility, a great number of them came back to Process ID 2524, which was 'svchost.exe'.

Next, let's look at what PID 2524 shows for its loaded DLLs
Loaded DLLs for PID 2524

Note that the Command line for PID 2524 was "C:\Windows\System32\svchost.exe -k secsvcs"
which is Windows Defender.  In the loaded DLL files, you can see references to Windows Defender as well.  In 2006, Microsoft included Windows Defender as a first line defense against malware, originally as anti-spyware.  It was later superceded by "Microsoft Security Essentials" which upon installation, will disable "Windows Defender".

Dumping the VAD pages for PID 2524, and searching for our domains of interest yields the name of the VAD page where our domain can be found. A hexdump of that file shows that we're on the right track:

hexdump of the dumped VAD page where the searched domain was located

You can see by this quick analysis that Windows Defender will load a large number of domains into RAM.  It's generally good practice to minimize extraneous artifacts in a sandbox image.  Since Windows Defender is enabled by default in Windows 7, don't forget to disable it via the Services applet before snapshotting your baseline VM.

As I mentioned earlier, there were also many odd domains seen in the full RAM image, that were not associated with a process via the Volatility yarascan. I've not yet accounted for this, so if anyone has any clues or additional analysis, I'd be very happy to hear of it.

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


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!


December 12, 2011

Decoding malware SSL using Burp proxy

When performing dynamic analysis of malware, you will occasionally encounter SSL being utilized for network communication, thus preventing you from analyzing the content.  Typically Wireshark is utilized to examine network traffic at the packet level. Wireshark has an SSL dissector that allows for the decryption of SSL traffic if you provide the decryption keys. This technique is described in detail on the Wireshark wiki.   However, I prefer to use an intercepting proxy to attempt the SSL analysis. The proxy will use its own SSL server certificate to negotiate and establish an encrypted session with the remote host. Essentially you are using the proxy to "Man-in-the-Middle" the malware's connection to the remote server.

My proxy of choice is BurpSuite, however you can utilize other proxies such as Paros, Webscarab, or Fiddler.  Burp has a very cool feature called "Invisible proxying" that handles non-proxy style requests.  This can be of good use when the malware you are analyzing generates its own HTTP or HTTPS requests outside of a browser framework.

I'll first provide an example where a particular malware specimen was utilizing SSL to communicate with Craigslist.  In this case, the malware appeared to be retrieving a variety of fake postings associated with various email addresses.  The posting title and description contained what is likely encrypted data.  The following image shows Wireshark displaying SSL traffic between the malware infected host and Craigslist.  The SSL negotiation and data are evident in the stream, however being SSL, you can't read it !


However when using Burp as an intercepting proxy, you can easily see the SSL traffic and get a pretty good idea of what the malware is doing.  Here, you can see the client GET to https://post.craigslist.org


The following images show the Raw, html, and rendered page views of the server response.


Burp also allows you to export the proxied traffic to an XML file. There is also an option to Base64 encode all requests and responses. The image below shows an example of the exported data.



Now that we've seen an example of SSL decoding using Burp, I'll describe the basic setup and configuration of my environment.  You certainly don't have to use this exact setup, as I'm just describing what I do and what works for me.  Make adjustments accordingly to suit what you are using.

  • I use VMWare workstation Version 7 on an Ubuntu Linux 10.04 Server host. My guest virtual machine is Windows XP SP3. The virtual machine is setup in bridged networking mode.  I have the Burp proxy and Wireshark installed on my linux host.

  • You will need to allow the linux host to forward network traffic from the virtual machine. In order to do this, you need to enable IP forwarding via the following:
    • user@linux1:~$ sudo su
    • root@linux1:/home/user# echo 1 > /proc/sys/net/ipv4/ip_forward

    • Next, you'll need to setup an iptables rule to redirect http and https traffic to the Burp proxy which is listening by default on port 8080. This is done via:
      • user@linux1:~$ sudo iptables -P FORWARD ACCEPT
      • user@linux1:~$ sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
      • user@linux1:~$ sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports 8080

      • Boot your guest virtual machine and manually configure your network settings as follows:
        • Manually set the IP address of the guest to an unused IP address on the same subnet as your linux host
        • Set the Gateway to the IP address of the your linux host.
        • Set the DNS server IP address to that of a host on your subnet that will forward DNS requests. This isn't strictly required, as you can also set it to any public DNS server. For consistency, I set mine to my local router.

      • Turn OFF the XP Firewall.

      • Configure Burp to do invisible proxying and to listen on all interfaces.  If you don't want Burp to intercept each request, you can disable that at this time.


      • Shutdown your guest virtual machine and take a snapshot.  Restart the guest and test the proxy by browsing to any web site. You should see the traffic in Burp.  If you browse to a site using https, you will also see a browser warning error about the SSL certificate. This is because the certificate presented by Burp is not signed by a trusted authority, so the browser gives a warning.  Keep this in mind as we begin to see malware utilizing SSL certificates.  Now, you can shutdown the guest VM, revert to the recent snapshot, and be ready to go.  I also like to run wireshark on the host to match up the packet level traffic with the Burp data.   I'd recommend using a capture filter on Wireshark that only captures traffic to/from the guest VM.

      This post showed how the use of an intercepting proxy can allow you to decode an SSL traffic stream and better support your dynamic malware analysis efforts.  Decoding SSL traffic is just one small part of what can be done with this tool.  It's well worth the investment to utilize an intercepting proxy with its many other features as a routine part of your analysis process.