Using Sysinternals System Monitor (Sysmon) in a Malware Analysis Lab

System Monitor (Sysmon) is a new tool by Mark Russinovich and Thomas Garnier, designed to run in the Windows system's background, logging details related to process creation, network connections, and changes to file creation time. This information can assist in troubleshooting and forensic analysis of the host where the tool was installed prior to the incident that's being investigated. Let's take a look at the role that System Monitor might play in a malware analysis lab, possibly supplementing tools such as Process Monitor and Wireshark.

Installing System Monitor

To experiment with System Monitor in your lab, download the tool from its website and extract the the archive's contents into the desired folder (e.g., "C:\Program Files\Sysmon") of your Windows laboratory system. Then, open the Administrator command prompt, change into that location (e.g., "cd C:\Program Files\Sysmon") and install the tool by running the command:

sysmon -i -n

The "-i" parameter directs the tool to install its service and driver. The "-n" parameter asks it to log network connections, in addition to capturing process and file creation time events. You'll be asked to interactively accept the EULA, after which the tool will install itself and start running in the background.

To view the events captured by System Monitor, open Event Viewer on the system ("eventvwr.exe") and navigate to Applications and Services Logs/Microsoft/Windows/Sysmon/Operational. According to the tool's documentation, on older systems the events are written to the System event log.

Using System Monitor to Track an Infection

To experiment with System Monitor, I infected my laboratory system with a variant of Pandemiya malware. I was curious how System Monitor would compare to other tools I use in the lab, namely Process Monitor and Wireshark.

After activating the tools, I ran the malicious executable pand.exe by double-clicking on it off the lab system's desktop. System Monitor showed the following event:

ProcessId 3936
Image C:\Users\REM\Desktop\pand.exe
CommandLine "C:\Users\REM\Desktop\pand.exe"
Hash EF91785633465F1C6F133068832943378D02A22B
ParentProcessId 1336
ParentImage C:\Windows\Explorer.EXE
ParentCommandLine C:\Windows\Explorer.EXE

We can see that the specimen began running as pand.exe (process ID 3936.) As expected, its parent was Explorer.EXE (process ID 1336). The logged event includes the SHA1 hash of the malicious file. You can look up threat details associated with this hash using online services such as TotalHash and VirusTotal. If I wanted to use a different hashing algorithm, I could have specified this configuration option when installing System Monitor. (Please note that I omitted some of the details that System Monitor logged for the sake of brevity.)

For comparison, here are the relevant events captured by Process Monitor, which presents a consistent perspective on Windows Explorer launching the specimen:

Another relevant event logged by System Monitor is captured below. It shows pand.exe (process ID 3936) launching a child process named gjswaxr.exe (process ID 3964) from C:\ProgramData:

ProcessId 3964
C:\ProgramData\gjswaxr.exe
CommandLine "C:\ProgramData\gjswaxr.exe" /sd 3936
Hash EF91785633465F1C6F133068832943378D02A22B
ParentProcessId 3936
ParentImage C:\Users\REM\Desktop\pand.exe
ParentCommandLine "C:\Users\REM\Desktop\pand.exe"

Note that the hash of gjswaxr.exe is identical to that of pand.exe. This suggests that the malicious program copied itself into C:\ProgramData and assigned itself a different name. We can also see in the System Monitor event that gjswaxr.exe was launched with the "/sd 3936" parameter, which corresponds to the ID of its parent process pand.exe.

A corresponding set of events in Process Monitor's log is shown below. You can see similar details, including the command line of the new process and its parent's process ID. Because Process Monitor logs more event types that those handled by System Monitor, we could have seen other data in Process Monitor's log, such the creation of the gjswaxr.exe file by pand.exe. (I'm not showing those events for the sake of brevity.)

Looking further at the events captured by System Monitor, we can see the following activity associated with Windows Explorer, which is represented by the Explorer.EXE process (ID 1336):

ProcessId 1336
Image C:\Windows\Explorer.EXE
Protocol tcp
SourceIp 192.168.132.130
SourcePort 49161
DestinationIp 192.168.175.134
DestinationPort 80
DestinationPortName http

Windows Explorer is initiating a TCP port 80 connection to 192.168.175.134. Further analysis shows that the malware we're examining drops and injects a malicious DLL into Explorer.EXE and other processes, but those details are outside the scope of this article. (Strange that it's connecting to a non-public, RFC 1918 IP address, right?)

As you might expect, Process Monitor captures this activity as well, as shown in the screenshot below:

Wireshark shows a consistent perspective on this activity, confirming that the connection is an HTTP request, which you might research further. (P4ND3M1CB00BF4C3 might make for a nice indicator of compromise.)

There's much more to the analysis of this malware specimen, but we'll wrap it up now, given that my goal was to start experimenting with System Monitor.

The Usefulness of System Monitor

In my laboratory experiments so far, System Monitor didn't provide a lot of value beyond the details I could already see using Process Monitor. However, I find it useful to have multiple tools that provide similar information from slightly different vantage points. Sometimes, one utility offers better insights than you could gather from another tool. (When using System Monitor, keep in mind that like other Sysinternals utilities, it does not try to conceal itself from malware.)

System Monitor seems to be designed to be most useful not in a malware analysis lab, but in the wild. When preemptively installed on production systems, the tool can capture helpful details for system administrators, incident responders and forensic investigators. In that scenario, it's very useful to have Sysmon running silently in the background, collecting interesting events and reporting them to a log collection facility. System Monitor, therefore, is a welcome addition to the DFIR professional's toolkit.

— Lenny Zeltser

Lenny Zeltser teaches malware analysis at SANS Institute. He is active on Twitter and writes a security blog.