Archive for the ‘VMware’ Category

Random Malware Analysis

2009/05/22 1 comment

Having recently been left with several hours to kill with nothing but a laptop and my virtual lab I thought I’d try my hand at some rudimentary malware analysis. For a random live sample I selected the most recent submission to my Nepenthes Server.

$ tail -n1 /opt/nepenthes/var/log/logged_submissions
[2009-05-21T19:10:59] -> creceive:// 93715cfc2fbb07c0482c51e02809b937

To start with I wanted to get an idea of what I was dealing with, so I passed the file’s hash to VirusTotal’s Hash Search utility; and promptly found that VirusTotal had no knowledge of this particular hash. Means we could be dealing with a completely new malware strain or variant! or more likely a polymorphic binary creating a unique file signature…

The question was promptly answered when transferring the binary to my analysis machine by AVG, ‘Threat detected: worm/Allaple.b’. Not wanting to take the word of a single AV vendor I proceeded to upload the binary itself to VirusTotal (have I mentioned I like VirusTotal yet?). Sure enough most AV engines agree with AVG’s analysis although there was some dissention over which version of Allaple the sample was. Most AV engines (37/40) flagged file as malicious (Comodo, nProtect and PrevX gave the binary a clean bill of health.)

Beginning with some static analysis, the ‘strings’ utility is always a safe place to start. As I’m using a Windows platform for this analysis I use the SysInternals strings binary. This revealed little, other than confirming the binary is a windows executable (usual ‘!This program cannot be run in DOS mode.’ string) and a reference to Kernal32.dll and some function names (FindFirstVolumeW, GetShortPathNameA, GetConsoleAliasesLengthW, AddConsoleAliasA, GetModuleHandleW, CreateProcessA, GetUserDefaultUILanguage, LocalReAlloc, SetHandleInformation, SetConsoleCursorInfo).

As there was limited information available from a plaintext strings search my next step was to see if the binary had been packed. For this I used PEiD utility, PEiD initially stated that there was ‘Nothing Detected’ although the entropy found within the file (7.93) caused PEiD to suggest that the binary had indeed been packed.

With some basic static analysis undertaken (this could/should have been taken further but my RE/assembly-fu is a bit rusty, especially at 3am) I changed tact and went with some initial behavioural analysis. For an initial run I utilised iDefense’s SysAnalzer tool written by David Zimmer. SysAnalyzer is a great utility for automating behavioural analysis and capturing system changes, from it’s download page:

SysAnalyzer is an automated malcode run time analysis application that monitors various aspects of system and process states.
SysAnalyzer was designed to enable analysts to quickly build a comprehensive report as to the actions a binary takes on a system.

The tool snapshots (not to be confused with VM snapshots) the state of the system, runs a given binary, then snapshots the system after execution before comparing the two snapshots. This can provide some detailed, succinct information to an analyst, but may miss any dynamic and temporary system changes. One weakness (or strength, depending on your perspective) that SysAnalyzer has is that it does not sandbox the malicious binary from the analysis system. Meaning that if the binary is destructive it *will* hose the system it is being analysed on, obviously if you’re utilising virtualisation and snapshop functionality this shouldn’t be an issue.

On starting the analysis, the malicious executable promptly errored (usual Windows’ ‘executable has failed, please send all information to Microsoft’ type pop-up) and SysAnalysis stated that the system was unchanged by the binary. Well that was disappointing, possible some form of VM detection causing the malware to shut down?

Not to be denied, I re-ran the process: Again the executable crashed with Microsoft’s pop-up, but this time SysAnalysis saw some system changes, from API and registry calls to the creation of new processes. However on further analysis the new processes and files were all only related to the DWWIN.exe executable which, as explained here, is part of Windows itself and is the cause of the pop-ups discussed above.

One aspect that may be causing the binary to lock up is that it is isolated from the network. From experience some malware will perform an initial lookup to an external resource, if the code can’t access said resource the malware assumes it is on a closed system and shuts down. To test this theory I re-ran the executable (this time manually, without the SysAnalysis utility) with Wireshark sniffing all network interfaces. As expected the binary crashed with the same error pop-up, reviewing the wireshark capture no traffic was generated outbound to any resource from the infected host.

Another possible reason for malware to refuse to run is newer VM detection techniques. However no evidence of this is present in the API calls captured by SysAnalysis, nor can I find any reference to VM detection capabilities present within the Allaple family from a search of the web. Ideally to test this theory the malware would be executed on a natively installed OS to bypass any potential VM detection. Unfortunately at this stage I do not have resources available to sacrifice a physical machine in this manner, so analysis must stop here.

One final possibility is simply that the binary is defective, just because the malware is spreading does not necessarily mean that the payload delivered upon exploitation is fully functional. It is not uncommon to have one malware strain being propogated by an entirely different strain. This is rapidly becoming more prevelant as ‘cybercrime’ (I hate that phrase) matures with the recent emergence of crimeware-as-a-service.

What-ever the reason for the binary failing to have any perceivable impact on the system, the behaviour that has been observed during this sample’s execution does not match that which is expected from other analysis of the Allaple.b malware strain. Sophos’ analysis for example, states that upon infection Allabple.b will:

  • When first run W32/Allaple-B copies itself to [system]\urdvxc.exe.
  • The W32/Allaple-B is registered as a COM object.
  • W32/Allaple-B installs itself as a service with the name “MSWindows”.

No evidence of this behaviour has been seen during analysis, nor are any of the changes present on the system post infection. This is a good example of why there isn’t always a need to panic when AV picks up a malicious item. Until the infection has been analysed in more depth there is no way of knowing how scary the compromise and infection is.

Andrew Waite


VMware ESXi updates

2009/04/14 Comments off

A couple of SANs ISC diaries (“Recent VMware updates available” and “VMware exploits – just how bad is it?“) should be a concern for anyone running a VMware lab (or VMware production environment). The ISC diaries explain the situation better than I could, but to cut a long story short the exploits allow a malicious user/payload to escape the guest system and gain direct access to the host.

Looks like I know what I’ll be doing after work tonight. I’ll try to document the update process as I go, watch this space…

Andrew Waite

Categories: Exploit, Lab, VMware

Sec610 Reverse Engineering Malware Demo

2009/03/23 1 comment

I spent a very interesting hour with Lenny Zeltser (and others) around a week ago with a live demo of part of Lenny’s Sec610 course. For those interested in taking the course, or malware in general, then I’d suggest that if the demo is a representative sample of the course then you’re likely to really enjoy it. If you’re interested the webcast session was recorded; I’m not going to provide the link here as I do not know if it is intended for public consumption, but I’m sure if you contact SANS they’ll be able to hook you up.

I don’t want to give to much away but the demo session focused on reversing an unfamiliar binary that was a dummy MSN application for password harvesting. A lot of the overall tools and theory would have been fairly straightforward for anyone with knowledge in this area, basic RE tools (VMWare, OllyDbg & Wireshark etc.) were covered as related. The demo also focused on some more specialised and less well known (at least to me) tools. Mostly these were system monitoring utils and snapshot status gathering tools to get a better feel for what the malware was up to.

The main utilities that caught my attention were fakeDNS and MailPot, these tools are designed to fake standard systems to allow the malware to communicate with external sources in a safe environment. These come part of the Malcode Analysis Pack that is distributed by iDefense. Until this point I have been using fully blown (virtual) servers to run sandboxed DNS, SMTP, etc. services for malware anaylsis, I’m hoping these utilities should reduce the implementation time required for specific analysis, leaving more time and resources available to focus on the malware itself.

Andrew Waite

dd, netcat and system recovery

Simple scenario
a linux server (Debian in this case) has run out of hard-disk capacity (4GB) and needs to be migrated to a larger capacity hard drive (6GB). Should be simple, vmware even provides a nice method to merely expand the virtual hard disk capacity. However, I’m doing this for the purposes of practice and training with various tools; as such I’m going to assume we’re working with physical hardware and this option isn’t available (despite the fact the machines being used are virtuals within my lab, I know….)

(*N.B. if following these steps on your own hardware substitute all IP addresses, device and filepaths as relevent to your environment. This is just the process that worked in my scenario, if working with your own equipment ensure that you know the impact of each command before running anything, your mileage may vary. If unsure contact an expert for further advice)

Servers involved

  • Debian Server:
  • Acquisition Server:

Data Acquisition
To transfer the data from the original server I used only free and freely available tools. To start the Debian server was booted from CD with Knoppix (note: nearly any Linux live CD would have been suitable for this task, previously I would have used Helix, but this is unfortunately no longer free).

Once booted, an image was collected via the venerable dd and transferred to the acquisition server via the equally venerable netcat.
Debian $ dd if=/dev/sda1 | nc 2000
Acquisition $ nc -lp 2000 | dd of=/mnt/sda1/debian-sda1.dd

I always name my images with the device or mount point that was captured. It is easy to forget further down the line whether you had imaged a partition or entire block-level device, this is the best way I have found to document what is contained in the image.

Depending on your connection speeds and hard disk capacities this transfer can take a long time, in my case the initial image capture took a little under 30 minutes. This can be unnerving the first few times through the process (especially if you are working under time constraints) is that the nc/dd combination does not provide any progress status.

One tip I’ll share is to ensure the netcat sessions are initiated via console sessions. In previous scenarios I have been remotely SSH’d to one of the servers and initiated the image transfer, only to have my remote session timeout and kill the dd/nc processes 😦 not a nice thing to experience…

Once the image transfer completes you can verify the integrity of the acquired image by hashing; as people of started discovering issues with some hashing algorithms it is worth hashing with several algorithms for complete peace of mind. In this scenario I used the utilities md5sum and sha1sum as forensic integrity isn’t an issue in this scenario.

Prepare new drive
At this point I powered down the Debian server, deleted the original hard drive, created a new drive with larger capacity and rebooted, again with Knoppix. The drive was partitioned with fdisk, I’ll not go into specific as there are plenty of great tutorials regarding partition available elsewhere.

Replicate Data
Next task is to copy the data back from the acquisition server, this is basically a reverse of the initial dd/nc commands:
Debian $ nc -lp 2000 | dd of=/dev/sda1
Acquisition $ dd if=/mnt/sda1/debian-sda1.dd | nc 2000

Configure server to use new hard disk
At this point the re-migrated data can be mounted and utilised, is currently not bootable and it’s filesystem will not take advantage of the additional storage capacity. The latter of these issues is easily dealt with, again from within a Knoppix boot running the below command will expand the file system to it’s capacity:
$ resize2fs /dev/sda1

To allow the system to boot from the new drive grub was re-installed with the below command:
$ grub-install –root-directory=/mnt/sda1/ /dev/sda/
And with that the system boots as before, but with additional capacity required to continue operating in a useful manner.

Andrew Waite

Categories: Lab, VMware

Lab environment

2009/02/16 1 comment

I’m currently in the process of getting my lab environment in place so I’ve got a safe (and secure) place to test all of my projects and thoughts. To assist I’ve been reading Michael Gregg’s “Build your own security lab“, it is a good resource and comes with some good tools (like a trial of Core Impact). However, it may not provide too much you didn’t already know if you’ve got some experience in the field.

For hardware I picked up an HP Proliant ML110 from Ebuyer at a great rate. I’ve since upgraded the RAM to 5GB (will max it to 8gig as needed and finances allow), this has become a great virtualised server running VMWare ESXi.

Going forward I intend to add in a Cisco switch (probably 2960) to segregate my lab network from my home net, whilst still mixing physical hardware with virtual.

Andrew Waite

Categories: InfoSec, Lab, VMware