Wednesday, May 12, 2010

Simulating the User Experience: Part 3

In the first two parts of this blog series, I detailed an issue I found where not all of the user environment variables were set for a program run with winexe. This was causing an issue during analysis of some malware since the samples were looking for those variables. As a work-around, a batch script was uploaded to the Windows sandbox and scheduled to run. When the scheduled job ran, all of the environment variables were set and the malware ran as it normally would.

The whole situation got me thinking - are public sandboxes setting all of the environment variables? As was seen, some malware rely on these variables and if they aren't set the malware won't run. If someone were to use a public sandnet to test malware that relies on these variables and the malware didn't run, they could be under the false impression that the program is benign.

Before I go on I should state that this post is not a knock against public sandboxes. They provide a great service to the security community. I did not do this to find any weaknesses in them to exploit or publish maliciously. My goal here was to determine which sandboxes, if any, miss some variables that may be required for malware to run.

To test this, I wrote a program that would obtain the environment variables and write each one to its own registry key/value pair. Since the public sandboxes report any registry modifications made by the program, I would be able to see all of the environment variables available to the program. This program was then uploaded to a number of different public sandboxes and the results analyzed. The sandboxes I used were Anubis, Comodo, CWSandbox, Joebox, ThreatExpert, BitBlaze and the Norman Sandbox.

In my testing, none of the sandboxes set all 30 of the environment variables I originally saw in my test. BitBlaze set 29; Anubis, Comodo, CWSandbox and Joebox set 28; and the Norman Sandbox only set 16. For some reason, ThreatExpert did not report anything back from my program - this could be a problem with my program or some type of security measure on their part.

* Note: I will not say which variables were and were not set. That information could be used by malware to determine it was running in one of these sandnets and that is not my purpose.

Due to the way the malware is executed in my system, I think that having only 28 or 29 environment variables is a perfectly normal variation. Therefore, my conclusion to all of this is that with the exception of Norman Sandbox, the sandnets appear to be setting the variables they should and represent a likely variation in the systems malware would run on.

As for Norman Sandbox, they are setting a small number of environment variables. This is perhaps a likely scenario for some systems. However, the variation of such a small amount being set would concern me as I don't know if all malware would work as it normally would. Only further testing can tell.

9 comments:

Anonymous said...
This comment has been removed by a blog administrator.
Mike said...

It is interesting that Norman Sandbox sets less environment variables than the winexe command.

I have used CWSandbox once before and it didn't provide me with same type and clarity of information that the setup you described in Hakin9. I prefer your setup.

Luke said...

would wmi work? I am absolutely horrible at this but something like the following?


#!/usr/bin/env python
import sys, shutil, wmi
#import win32com.client

ip = "192.168.1.5"
tmpDest = "\\\\" + ip + "\\C$\\"
malware = "malware.exe"

shutil.copyfile(malware, tmpDest + malware)

c = wmi.WMI(ip,user=r"192.168.1.5\UserID", password="SecretPassword")
#locator = win32com.client.Dispatch("WbemScripting.SWbemLocator")
#wmi = locator.ConnectServer(ip,"root/cimv2",id,pw)

command = "cmd /c c:\\" + malware
process_id, result = c.Win32_Process.Create(
CommandLine=command,
ProcessStartupInformation=process_startup
)
if result == 0:
print "Process started successfully: %d" % process_id
else:
raise RuntimeError, "Problem creating process: %d" % result


I have no real python abilities so this is probably completely broken also note that this is windows focused (i know, breaks the whole point of your question about using Linux) but using win32com.client I think you can do the same thing. You would have to rejigger process creation part and I don't think I ever looked into that before moving everything over to Windows only and the easier way of doing things with Tim Golden's WMI module. I will look it up at some point since it's becoming apparent that I will have to move back to a more generic and portable solution to the wmi things I do.

cheers,

Tyler said...

Luke,

I think your client would work, but isn't the wmi library only windows? My host-OS is Linux.

However, I would think that using WMI in the guest to execute it (via winexe) might work. I'll have to try that out.

Luke said...

There's a linux version of win32com.client. I think it may be part of Samba somewhere. I did have an older version of it running at some point in time.

I think it also had winexe bundled at one point... let me see here's a link I have in some notes.

There was something else I had to compile and install to get the Python parts to work.

Unknown said...

Would you be willing to share your tools and automation/scripts used for behavioral malware analysis? Im trying to build a test environment/lab to automate malware naalysis and sounds like you have a good setup.

Thanks

Tyler said...

clementines - send me an email and i'll send you the files. Soon I'll have a centralized place to put everything, but I don't have anything right now.

Unknown said...

I cant find your email addy anywhere lol.

Tyler said...

securityshoggoth at gmail dot com