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:

• 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.

I decided to start with the third option. I knew I couldn't use winexe to directly execute the malware as I wouldn't get the correct environment variables set. But, what if I used winexe to execute another program to launch the malware?

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 /f
start c:\path\to\malware.exe

The 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.

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.