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:

	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.