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.
Wednesday, May 12, 2010
Saturday, May 8, 2010
Simulating the User Experience: Part 2
In my last post I discussed the problem I found with winexe and how it did not set all the Windows environment variables needed to simulate a complete user experience. This problem was preventing some malware from running in my malware analysis sandnet - a problem I needed to overcome.
The way I looked at it, I had 3 options:
Using winexe to run 'cmd /c malware.exe' was out as this was the method I was using before. I then tried creating a batch script to run the malware and executing it with winexe. No luck there either; the environment variables weren't created. Finally, I had an idea...what if I scheduled a job to run the malware? If I scheduled it as the user it should inherit all of the correct variables and run correctly.
To test it out I created a batch script (named test.bat) in the Windows system that would run set and redirect the output into a file. I then ran the following command (from the Linux box):
Success!!! When the script ran and dumped the environment variables into a file, all 30 were there! The next step was to create a script to run the malware in the system.
The automation script was modified to upload the malware to the Windows box along with a batch script that performs the following commands:
Why delete the scheduled job? When scheduling the job, it is scheduled to run every minute. By deleting the scheduled job there's no worry the malware will run more than once. Why schedule it to run every minute? Call it paranoia. :)
After making the modifications to my automation script and testing it, I ran it with the Koobface sample that started all my problems and...success! The results showed the sample ran correctly, dropped the right files and set the right registry keys. Tests with additional malware have shown that its working correctly as well.
This test got me thinking...how do publicly available sandnets work? Are they setting the environment settings correctly? I'll discuss this in the part 3 of this post.
The way I looked at it, I had 3 options:
- Modify the source code for winexe to get it to work as I wanted. However, this was more than I wanted to do at this time. Maybe later.
- Use a program like webjob to provide another means to remotely execute the program. However, this would require me to modify the Windows analysis host which, for reasons I won't go into, is a huge PITA. Any solution that required me to modify the host was out for now.
- Figure out a way to remotely execute the malware on the Windows system using already present tools and still get the user environment I wanted.
Using winexe to run 'cmd /c malware.exe' was out as this was the method I was using before. I then tried creating a batch script to run the malware and executing it with winexe. No luck there either; the environment variables weren't created. Finally, I had an idea...what if I scheduled a job to run the malware? If I scheduled it as the user it should inherit all of the correct variables and run correctly.
To test it out I created a batch script (named test.bat) in the Windows system that would run set and redirect the output into a file. I then ran the following command (from the Linux box):
winexe -U administrator%mypass //192.168.1.5 'schtasks /create /tn testjob /tr c:\temp\test.bat /sc minute /mo 1 /ru administrator /rp mypass'
Success!!! When the script ran and dumped the environment variables into a file, all 30 were there! The next step was to create a script to run the malware in the system.
The automation script was modified to upload the malware to the Windows box along with a batch script that performs the following commands:
schtasks /delete /tn jobname /fThe automation script then schedules a job to run the uploaded script. When the scheduled job kicks off, the batch file runs. The batch file deletes the scheduled job and run the malware.
start c:\path\to\malware.exe
Why delete the scheduled job? When scheduling the job, it is scheduled to run every minute. By deleting the scheduled job there's no worry the malware will run more than once. Why schedule it to run every minute? Call it paranoia. :)
After making the modifications to my automation script and testing it, I ran it with the Koobface sample that started all my problems and...success! The results showed the sample ran correctly, dropped the right files and set the right registry keys. Tests with additional malware have shown that its working correctly as well.
This test got me thinking...how do publicly available sandnets work? Are they setting the environment settings correctly? I'll discuss this in the part 3 of this post.
Simulating the User Experience: Part 1
Part of malware analysis, especially automated malware analysis, is to simulate the user environment as closely as possible. After all, our goal is to determine how malware behaves when it is run by a user. For the last few months I've worked on an automated malware analysis system which I thought did just that.
Let me explain my automated analysis system. It is similar to the one I described in my Hakin9 articles last year. Basically I have a host system running Linux that executes an automation script. The automation script starts up a VM, launches some monitoring tools, uploads and executes the malware, records the results and performs cleanup. In all, it takes about 5-7 minutes per malware, depending on the settings I am running. So far it performed extremely well and cut my analysis time down dramatically.
Imagine my frustration this week when I ran a new Koobface sample in it only to find the malware didn't do anything. It would launch, perform some start-up operations, then exit. No registry modifications, no process injection, no network traffic. However, when I would manually launch it or run it through ThreatExpert, it would run fine.
In looking closer, I found out that the malware was trying to place a copy of itself in the %APPDATA% directory. Since %APPDATA% is an environment variable for the user, it should have been set - or so I thought.
I took a step back and started to examine the method I was using to execute the malware. My "host" system which executes the automation scripts runs Linux. In order to execute the malware in the Windows system, smbclient is used to upload the malware and winexe is used to execute it. After some thought, I came up with a theory that winexe was not setting all of the environment variables when it executed malware. I was right.
It turns out that in a default Windows XP SP3 system, 30 environment variables are set. With the way I was running winexe (--system --interactive=1), only 22 of the variables were set - %APPDATA%, %CLIENTNAME%, %HOMEDRIVE%, %HOMEPATH%, %LOGONSERVER%, %SESSIONNAME%, %USERDOMAIN% and %USERNAME% are missing.
To make sure it wasn't because of the way I was running winexe, I ran a number of tests. Each test consisted of running winexe with different settings. The command that was run was "cmd.exe /c set > outfile". To be fair, I also tested PsExec (from another Windows system). These are the results I found:
It turns out that no matter what options you use, winexe does not set the environment variables above. Note that I also ran winexe with the --runas option and got the same results. PsExec sets all of the environment variables, except when you specify it to run as SYSTEM. This makes sense as most of those variables are used to specify user settings and SYSTEM would not have those.
Obviously, winexe wasn't going to cut it any more because it wasn't setting a complete user environment which, in turn, was preventing malware from running. So, what to do? Winexe was my only way to remotely execute a program on a Windows system from a Linux system (without modifying the Windows system and installing other programs). To find out what I did, you'll have to stay tuned for part 2! :)
As a side note, if anyone knows of another program similar to winexe, please let me know. Also, if anyone knows of a way to get winexe to run correctly, I'd love to hear it.
Let me explain my automated analysis system. It is similar to the one I described in my Hakin9 articles last year. Basically I have a host system running Linux that executes an automation script. The automation script starts up a VM, launches some monitoring tools, uploads and executes the malware, records the results and performs cleanup. In all, it takes about 5-7 minutes per malware, depending on the settings I am running. So far it performed extremely well and cut my analysis time down dramatically.
Imagine my frustration this week when I ran a new Koobface sample in it only to find the malware didn't do anything. It would launch, perform some start-up operations, then exit. No registry modifications, no process injection, no network traffic. However, when I would manually launch it or run it through ThreatExpert, it would run fine.
In looking closer, I found out that the malware was trying to place a copy of itself in the %APPDATA% directory. Since %APPDATA% is an environment variable for the user, it should have been set - or so I thought.
I took a step back and started to examine the method I was using to execute the malware. My "host" system which executes the automation scripts runs Linux. In order to execute the malware in the Windows system, smbclient is used to upload the malware and winexe is used to execute it. After some thought, I came up with a theory that winexe was not setting all of the environment variables when it executed malware. I was right.
It turns out that in a default Windows XP SP3 system, 30 environment variables are set. With the way I was running winexe (--system --interactive=1), only 22 of the variables were set - %APPDATA%, %CLIENTNAME%, %HOMEDRIVE%, %HOMEPATH%, %LOGONSERVER%, %SESSIONNAME%, %USERDOMAIN% and %USERNAME% are missing.
To make sure it wasn't because of the way I was running winexe, I ran a number of tests. Each test consisted of running winexe with different settings. The command that was run was "cmd.exe /c set > outfile". To be fair, I also tested PsExec (from another Windows system). These are the results I found:
| winexe | |||
|---|---|---|---|
| no settings | interactive | interactive + system | |
| %APPDATA% | |||
| %CLIENTNAME% | |||
| %HOMEDRIVE% | |||
| %HOMEPATH% | |||
| %LOGONSERVER% | |||
| %SESSIONNAME% | |||
| %USERDOMAIN% | |||
| %USERNAME% | |||
| psexec | |||
|---|---|---|---|
| no settings | interactive | interactive + system | |
| %APPDATA% | X | X | |
| %CLIENTNAME% | X | X | |
| %HOMEDRIVE% | X | X | |
| %HOMEPATH% | X | X | |
| %LOGONSERVER% | X | X | |
| %SESSIONNAME% | X | X | |
| %USERDOMAIN% | X | X | |
| %USERNAME% | X | X | |
It turns out that no matter what options you use, winexe does not set the environment variables above. Note that I also ran winexe with the --runas option and got the same results. PsExec sets all of the environment variables, except when you specify it to run as SYSTEM. This makes sense as most of those variables are used to specify user settings and SYSTEM would not have those.
Obviously, winexe wasn't going to cut it any more because it wasn't setting a complete user environment which, in turn, was preventing malware from running. So, what to do? Winexe was my only way to remotely execute a program on a Windows system from a Linux system (without modifying the Windows system and installing other programs). To find out what I did, you'll have to stay tuned for part 2! :)
As a side note, if anyone knows of another program similar to winexe, please let me know. Also, if anyone knows of a way to get winexe to run correctly, I'd love to hear it.
Subscribe to:
Posts (Atom)