Sandboxing with Sysmon

My Sysmon use cases were mostly around analyzing malware activity in a sandboxed environment, where in the past, I had to orchestrate few utilities to collect process and network activity logs from various sources. The issue with this approach is that sometimes the focus tends to shift towards organizing collected data more than analyzing it.

In the last update to Sysmon View, I introduced two new features:

  • Visualization of Process creation hierarchy.
  • Ability to import network packet capture for correlation with the Sysmon Network event

The second feature helps in advancing analysis, by looking up the packet payload data, tracing the entire network session conversation or even analyzing the usage of a non-standard ports (MITRE T1065).

Importing a network capture file

To experiment with the packet import functionality, we need an exported XML from Sysmon event log (check GitHub on how to import logs to Sysmon View) and a matching packet trace file (PCAP/PCAPNG, captured within the same events log time frame), once Sysmon logs are imported, add/import the network trace file:


Tshark is needed for all of this to work, it is used to convert the PCAP/PCAPNG files into JSON format for parsing; it is also used to extract (filter) packets later. Tshark is part of the Wireshark installation, and its path must be set in Sysmon View preferences as shown here (Wireshark is also needed to view extracted packets)


Upon successfully importing Sysmon events and network packets, Sysmon View will be able to correlate any Sysmon network events with a matching network conversation (packets), the event’s “details” box will display a link to indicate that a matching network capture exists for a specific event


Clicking this link will run Wireshark with a temporary generated file (in the form of Capture_Year_Month_Day_Hour_Minute_Second.pcapng) with a Wireshark filter matching network event source, destination (IP and Port) and transport (TCP or UDP)


As mentioned earlier, a time-matching Sysmon and network logs need to be generated, to help make this task more productive, I created a small command line utility, “Sysmon Box”…

Sysmon Box


While testing Sysmon View I spent a good deal of time and effort trying to generate logs from both, Sysmon and Wireshark, so, to save time spent in orchestring the toolset, I created “Sysmon Box” to help in automating this process, here is a description of what the tool will do when running the following command (Sysmon needs to be readily installed):

SysmonBox -in Wi-Fi
  • Start capturing traffic (using tshark in the background, this is why specifying the capture interface using the -in option is mandatory, it will be passed to tshark)
  • Generate Sysmon and traffic logs, when done, hit CTRL + C to end the session
  • Sysmon Box will stop traffic capture, dump all captured packets to a file and then export Sysmon events logged between the start and end times of the session using EVT utility
  • Finally, it will build a Sysmon View database file (backup existing database, if any) with imported data, all you have to do is to run Sysmon View from the same folder or copy the database file (SysmonViewDB) to the same folder as Sysmon View (keep the captured packets files in the same location, they will be referenced by Sysmon View)

With Sysmon Box and View combined, you have a mini (tiny) sandbox utility for analyzing behavior at process and network levels.

Sysmon View Database

If you use Sysmon Box or Sysmon View to import data, you can skip using Sysmon View GUI and use the database directly for analysis, the database is a SQLite database that can be accessed by any free database client tool.

As an example, the following query is used to list all hashes captured by Sysmon


Here is the output


Similarly, you can extract other information, such as registry keys, DNS queries or do a full-text search or building more complex queries to identify malware behavior; the data model allows for correlating more data, beyond what Sysmon is actually logging (e.g. geo-mapping, VirusTotal ratings, network traffic, etc.). Additionally, this database file can be shared with other analysts, Threat Intel, etc. as a full “running session”.


  • The full data model for Sysmon View database is published on Github
  • All tools are uploaded to Github

Stay safe.

Sysmon View 1.4 released!


My last blog entry was about Sysmon View 1.2, since then, Sysmon View went through many changes and updates, related to bug fixing, enhancements and recently, the addition of the new WMI events.

WMI Events and All Events View

Sysmon View can now import the WMI events (WMIFilter, WMIConsumer, and WMIBinding), however, there is no way to actually view those events in Sysmon View directly, only because the first view was meant to focus on binaries logically grouped using the GUID field, and the second view was a geo-mapping of the IP addresses from Network events. This was an issue for events like WMI and “Driver loaded” events, which lead to creating the third “All Events” view…


The 3rd view works like a pivot table by grouping related events of the same type, or of the same session (GUID), can sort by event time and have a detailed search through any imported events. Furthermore, expanding events provides access to their ID’s that look like hyperlinks, by clicking an ID number (this is an ID from the database itself, not a Sysmon generated data) you can invoke the detailed view of that event, view related sessions and query virus total for more information (hashes and IP addresses)

Here is the screenshot of an imported Sysmon log from a ransomware running session, with events grouped by type


Searching for the “delete” word reveals the use of vssadmin.exe with the same word passed as an argument, from there, I was able to track back to all the events sequence related to that session…


Open Database

Sysmon View generates an SQLite database for all the imported events, this database can be loaded by any instance of Sysmon View (for example, passed from another analyst). The database can be read by any application or script, it contains summaries of hashes, executables, IP addresses, ports, geo mappings, registry entries, which are all logically linked through a binary file name or a session (executable GUID)


In the case Sysmon View UI is not sufficient, another UI can be created using the database, and Sysmon View can be used as an import utility (work on progress to create a command line interface)

Sysmon Shell – Release 1.1

I have just uploaded a new version of Sysmon Shell (v1.1)


Here is the list of updates:

  • Added new configuration options to include or exclude an entire event log, for example (Surprisingly missing in version 1.0):
    <PipeEvent onmatch=”include”/> or <PipeEvent onmatch=”exclude”/>
  • If you are using Sysmon for malware analysis, you might find the last tap marked “Logs Export” useful, as it allows exporting Sysmon logs to an XML file, for example (the exported XML log files can be loaded into Sysmon View for analysis and visualization) the export feature has 3 options:
    • Export only
    • Export and clear Sysmon event log (to mark new analysis starting point)
    • Export, backup evtx file, and clear the event log


  • In case you are applying Sysmon configuration using Sysmon Shell and not directly using Sysmon, the hash of Sysmon image being executed will be used to run the configuration command will show in the preview pane


The new version can be found on my Github

Please contact me to report any bugs or suggestions

Visualizing & Tracking Sysmon events with Sysmon View 1.2

With Sysmon View 1.1, I was able to view Sysmon logs visually. However, this drawn image was somehow incomplete as I was unable to track the entire process hierarchy (maybe because I was busy laying down the foundation). With version 1.2, following a process through its hierarchy is now possible, additionally, when investigating an event, it is easy now to get to (trackback) all other events related (associated) to the same session.

Example: in the following image, let’s track the history of events related to “AcroRd32.exe” process


Double-clicking on the “process create” event reveals the details of this event (notice that the “Parent process GUID” is being highlighted as a hyperlink), the “event details” is showing “Explorer.exe” as the parent process…


New to Sysmon View 1.2: Before proceeding further, let’s talk about the new events details window. In this window, you can retrieve all event’s data, and query virus total for hash information as shown in the next screenshot (You will have to get an API key to enable virus total queries). In the case of network events, query Virus Total for IP and domains information, including whois data, in addition to “jumping” to the logged registry keys in regedit.


Now back to our topic, clicking “Parent process GUID” link will bring up the parent process session (in this example, Explorer.exe) and all events associated with it


To go further deeper, repeat the same steps recursively: let’s go to the details of the “process create event” of “Explorer.exe”, which shows the parent process as “userinit.exe”


Again… lets get the details of “userinit.exe” parent process though the details of the process create event details…


Which reveals “winlogon.exe” as the parent process, lets further dig behind the parent process “winlogon.exe” details…


You got the idea…

Now you might be asking what the hyperlink of “Process GUID” does, well, it will re-draw (visualize) the same session under investigation again, so why the duplication? well, its not, this is feature is needed for the “Map view”…


When selecting a destination country (Map View will be available if you enabled geo ip setting when importing the XML log data), then all network events related to that “destination” will be listed, now to track back to all events within the context of a running session, click the “Process GUID” field…


And from there, it’s easy to track that process hierarchy or any other event associated with it

For any questions or suggestions, please contact me by email.