Enhancing Event Auditing in Windows with Sysmon for Security Experts

We should clarify upfront that this article will not address issues related to deliberate log cleaning or improper configuration of audit policies in a domain (Audit Policy). Instead, we will focus on how to enhance the informativeness and capabilities of event auditing by using the System Monitor (Sysmon) utility in a Windows environment (from Windows 7 for client nodes and from Windows Server 2008 R2 for servers).

Sysmon

You can download the utility from the Microsoft Docs website in the Windows Sysinternals section. Windows Sysinternals, created by Mark Russinovich and others, includes many other useful utilities, so take the time to explore them. Also, check out the collection of resources on GitHub.

For this article, we’ll use a special pre-built package available on GitHub, which includes the Sysmon Threat Intelligence Configuration file from ION-STORM. It is specifically designed for identifying cybersecurity incidents and can serve as a solid foundation for creating your own configuration files.

The utility can be installed individually on each workstation or using Group Policy in the domain. The configuration file mostly specifies the complete standard paths for various software:

In a specific IT infrastructure, this might require some tweaking. For example, corporate policy might dictate that programs be installed on the D:\ drive instead of C:\. The toolset is highly flexible, allowing you to configure any rules aimed at monitoring specific actions or excluding them from your view.

After installation, you will have a new log (Channel) called Microsoft-Windows-Sysmon/Operational. In this log, Sysmon highlights 18 task categories, including: Process Create, Network Connect, Driver Load, ProcessAccess, and File Create.

Network Interaction Auditing

Let’s move on to the practical application of Sysmon.

Imagine the network interaction between two nodes: Node A is contacting Node B, and this contact is not authorized, raising suspicion of a cybersecurity incident. Traces of this network interaction will be searched for in the operating system as a last resort, starting instead with active network equipment. What information can a firewall or router provide if it is monitoring this network interaction?

We can only see the source IP_1 and the destination IP_2. Essentially, additional efforts will be required: you’ll need to analyze node A (IP_1) in a semi-automatic or manual mode to identify the real source of the network activity. It’s important to remember that if the network activity doesn’t extend beyond the network segment controlled by the firewall, or if relevant events are not logged by the firewall—as often happens—then nothing will be found in the logs.

Let’s say you managed to deploy a sniffer at this moment or preemptively divert traffic through a SPAN port to create a PCAP file. What will this accomplish?

We can see who, where, and, if we’re very lucky, with what tool—in this case, PuTTY. However, there’s no information on the application’s installation location, the executable file’s name, or its creation date. While these might seem like trivial attributes for PuTTY, they become crucial when you’re tracking traces of unauthorized actions or malware. Additionally, a malicious program might pose as a legitimate application, prompting you to dismiss a security incident as a false positive based solely on the application’s name retrieved from a network traffic dump.

Now, let’s take a look at the Microsoft-Windows-Sysmon/Operational channel. It contains the following event:

We can see who communicates where, using what, along with additional network interaction parameters (protocol, port). Now, in the same channel, we’ll locate the Process Create event using the ProcessGuid field value to gather more information about the source of this network activity.

We can see that a process has been created, and the hash value of the file that spawned this process has been identified. Now, you can verify this file using its hash:

• Using corporate “whitelists” of approved software;
• Checking against the manufacturer’s official website for software compliance;
• In Threat Intelligence service rankings;
• On platforms like VirusTotal.

It is worth noting that in network nodes where there are restrictions on installing antivirus protection tools (such as dispatcher terminals, technological workstations, and the like), hash analysis—particularly the automated kind through correlation with Threat Intelligence services, for example in Security Information and Event Management (SIEM) systems—can serve as an effective compensating measure for combating malicious software.

In continuing with the theme of tracking file-related activities, it is important to note that by default, the specified configuration file allows monitoring the creation of files in the operating system that could potentially be sources of information security incidents. This includes digital certificates, executable files, library files, PowerShell files, RDP files, MS Office files with macro support, as well as files created in specific directories of the file system.

Files or actions that lead to changes in registry settings are also subject to logging. For example, associating the DOCM file type, which was first used in the operating system when the file Doc1.docm was created, with the MS Word application:

For a security professional, it might be of interest when a malicious file re-associates legitimately assigned corporate applications for certain file types, thereby “forcing” the use of a vulnerable application. Another example is the alteration of operating system registry keys that affect the boot parameters of the OS, aiming to lower its security level after the next reboot (such as disabling antivirus or other information protection tools).

Centralized Collection and Storage of Events

To ensure centralized collection and storage of event logs from all network nodes, and to limit an attacker’s ability to clear logs on a compromised node, it is common to consolidate data on a dedicated node. This node should have the Windows Event Collector service running. As a result, events will appear in the Forwarded Events log.

You need to take the following steps on each workstation, either individually or by using group policies within the domain:

• Add the user, under whose name the “COLLECTOR” events will be collected, to the local group “Event log reader”.
• Run the command as an administrator (Run as) to execute it.
• Run the command as an administrator (Run as) to execute it and obtain the string channelAccess: DATA.
• Run the command as an administrator (Run as) to execute it and obtain UID_COLLECTOR.
• Run the command as an administrator (Run as) to execute it and grant extended access rights to the Microsoft-Windows-Sysmon/Operational channel for the COLLECTOR account.
• Add this node to a specially created Subscription for centralized collection and storage of events on a designated node running the Windows Event Collector service.

Conclusion

Our experience has shown that standard logging tools are often insufficient for a comprehensive analysis of suspicious network events, especially when it comes to targeted attacks on organizations. In such cases, Sysmon can be a highly promising solution, with its potential applications limited only by the imagination of the cybersecurity specialist using it.