Use Sysmon to

Leverage Threat-Intel

Microsoft Windows continues to dominate computer desktop operating systems in business enterprise environments. Consequently, cybersecurity analysts will continue to develop and refine their Windows cybersecurity capabilities. The Windows operating system is fairly transparent by exposing most of the file system and operating system files (especially if you have administrator-level privileges to the operating system). As a result, both computer administrators and Windows hackers ("hackers") have full access to all the files and features of Windows to manipulate it any way. Unfortunately, hackers tend to know more about Windows and its internal workings than the administrators. Administrators are burdened by the requirement to keep systems operating, available and properly maintained. Whereas, hackers are focused on examining the specific files, processes, memory and other specific operating system interactions to make the operating system conduct unauthorized activities.

Fortunately, there have been multiple research efforts to identify nearly every conceivable manner in which a hacker may influence Windows to do what it wants. These efforts have resulted in the development of various bodies of knowledge with labels such as "threat intelligence", "indicators of compromise", and "attack patterns". Examples include various computing artifacts such as:

  • IP addresses
  • Domain Names
  • File Names
  • File Hashes
  • Email Headers
  • Strings

In order to give administrators a fighting chance against hackers, they need to be able to scope their efforts to monitoring and observing computing artifacts commonly leveraged or left behind by hackers in their attacks. Fortunately, a taxonomy has been developed that has identified those artifacts.

Structure Threat Information eXperession (STIX)

STIX is a language and format to document and exchange cyber threat intelligence. But what is "cyber threat intelligence"? There is vigorous debate on its definition among researchers, scholars, vendors and governments. Among them, the Center for Internet Security offers a reasonable explanation:

"Cyber threat intelligence is what cyber threat information becomes once it has been collected, evaluated in the context of its source and reliability, and analyzed through rigorous and structured tradecraft techniques by those with substantive expertise and access to all-source information. Like all intelligence, cyber threat intelligence provides a value-add to cyber threat information, which reduces uncertainty for the consumer, while aiding the consumer in identifying threats and opportunities. It requires that analysts identify similarities and differences in vast quantities of information and detect deceptions to produce accurate, timely, and relevant intelligence.

Rather than being developed in an end-to-end process, the development of intelligence is a circular process, referred to as the intelligence cycle. In this cycle requirements are stated; data collection is planned, implemented, and evaluated; the results are analyzed to produce intelligence; and the resulting intelligence is disseminated and re-evaluated in the context of new information and consumer feedback. The analysis portion of the cycle is what differentiates intelligence from information gathering and dissemination. Intelligence analysis relies on a rigorous way of thinking that uses structured analytical techniques to ensure biases, mindsets, and uncertainties are identified and managed. Instead of just reaching conclusions about difficult questions, intelligence analysts think about how they reach the conclusions. This extra step ensures that, to the extent feasible, the analysts’ mindsets and biases are accounted for and minimized or incorporated as necessary.

The process is a cycle because it identifies intelligence gaps, unanswered questions, which prompt new collection requirements, thus restarting the intelligence cycle. Intelligence analysts identify intelligence gaps during the analysis phase. Intelligence analysts and consumers determine intelligence gaps during the dissemination and re-evaluation phase."

See What is Cyber Threat Intelligence?, Center for Internet Security, https://www.cisecurity.org/what-is-cyber-threat-intelligence/, downloaded June 13, 2018.

The primary products of cyber threat intelligence is a better understanding of the manner, method and means of an attack, and probably attribution to a person or entity. From a technical perspective, computing artifacts are also identified with reasonable certainty as indicators of the specific attack. To facilitate the use of these artifacts for administrators to use to protect, detect and respond to the attack, a common taxonomy defining the relevant artifacts was developed. STIX defines a machine-readable format for the computing artifacts identified by the cyber threat intelligence. (NOTE: The most up-to-date “STIX, CybOX, and TAXII Supporters” lists are now available on the OASIS website for both Products and Open Source Projects.)

Below is a partial screenshot from an example definition of a malicious URL indicator in the STIX format (JSON):

See Sighting of an Indicator, OASIS, https://oasis-open.github.io/cti-documentation/examples/sighting-of-an-indicator, downloaded June 13, 2018.

The full-version of this STIX definition is intended to define and share an identified malicious URL with others so that they can ingest it into their tools (intrusion detection/prevention, web filters, etc.) to protect, detect and respond to a similar attack. Additional examples can be found here. A fundamental byproduct of the STIX effort is a definition of the primary computing artifacts as indicators generated or left-behind by a cyber threat. Accordingly, STIX has defined and documented those indicator types as "Cyber Observable Objects" or "Cyber Observables"

Cyber Observables

STIX defines "cyber observables" as "the facts concerning what happened on a network or host but not necessarily the who or when, and never the why". STIX Version 2.0. Part 4: Cyber Observable Objects (July 19, 2017), section 1. These "facts" are defined a objects and their properties in the cyber domain that describes computer data relevant to:

  • Malware characterization
  • Intrusion detection
  • Incident response and management
  • Digital forensics

As of June 13, 2018, there are 18 defined objects and their associated properties. The list is below with links to their specific property definitions:

  • Artifact - encapsulates the content of a Raw Artifact
  • Autonomous System - AS number, name, and name of Regional Internet Registry
  • Directory - file system directory (e.g. c:\\windows\\system32)
  • Domain - network domain name
  • Email Address - a single email address
  • File - properties of a file (e.g. name, hash, magic number)
  • IPv4 - one or more IPv4 IP address using CIDR notation
  • IPv6 - one or more IPv6 IP addresses using CIDR notation
  • MAC Address - a single Media Access Control (MAC) address
  • Mutex - properties of a mutual exclusion (mutex) object
  • Network Traffic - arbitrary network traffic that originates from a source and is addressed to a destination
  • Process - common properties of an instance of a computer program as executed on an operating system
  • Software - high-level properties associated with software, including software products
  • URL - properties of a uniform resource locator (URL)
  • User Account - an instance of any type of user account, including but not limited to operating system, device, messaging service, and social media platform accounts
  • Windows Registry Key - properties of a Windows registry key
  • X.509 Certificate - the properties of an X.509 certificate (e.g. certificate subject, serial number, algorithm)

The above list is fairly comprehensive and addresses nearly all of the types of indicators involved in hacking activity. The challenge for administrators and information security professionals is instrumenting their information technology infrastructure to log, analyze and alert on all of these indicators. Generally, there is not one tool that can collect and analyze all of these indicators. As a result, business enterprises are forced to purchase and integrate various tools to attempt to collect and correlate the information such as:

  • Firewalls
  • Intrusion Detection and Prevention
  • Web Proxies
  • Netflow Analysis Tools
  • Anti-Virus
  • Host-Based Intrusion Prevention
  • File Integrity Monitoring
  • Artificial-Intelligence Host Security Applications
  • Security Event and Information Management (SEIM) Systems

To illustrate, here is a generalized table of the observable indicators and where those indicators are most likely recorded/detected: storage disk, memory or over the network.

What you immediately notice is that memory or RAM (random access memory) processes and observes every computing artifact that would affect a system. The issue is that information is not stored for a very long time in memory and it goes away when the machine is rebooted or simply overtime as memory addresses are reused. Capturing a copy of all information in memory can be done in cases where the activity being investigated is ongoing or fairly recent. Otherwise, logging of computer activity to the local disk or forwarded to another long-term storage solution is required. This also applies to capturing network activity which usually requires monitoring and logging at points external to the subject workstation or server.

Generally, logging tools like SIEMs are very expensive. What can we do to leverage the tools made available to us by Microsoft to instrument our workstations (and servers) to monitor, capture and log as many of the STIX cyber observables as possible?

Sysmon Captures STIX Cyber Observables

The challenge is to implement and configure tools in the Windows operating system that are already part of Windows or owned by Microsoft (e.g. free to use but from a trusted source) that collect and log these observable artifacts on a host over time for incident detection and analysis. Sysmon is a unique tool in that it is able to collect most of the relevant STIX Cyber Observables and it is provided by Microsoft free of charge.

Sysmon is a Windows Systinternals tool that operates as "a Windows system service and device driver that, once installed on a system, remains resident across system reboots to monitor and log system activity to the Windows event log. It provides detailed information about process creations, network connections, and changes to file creation time. By collecting the events it generates using Windows Event Collection or SIEM agents and subsequently analyzing them, you can identify malicious or anomalous activity and understand how intruders and malware operate on your network."

Installing Sysmon is a fairly trivial process. Here is a video on installing Sysmon as a service and viewing the events generated using Event Viewer.

Below is the list of every event monitored and logged by Sysmon which are stored in "Applications and Services Logs/Microsoft/Windows/Sysmon/Operational" folder in Event Viewer. Source: https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon#event-filtering-entries.

Event ID 1: Process creation

The process creation event provides extended information about a newly created process. The full command line provides context on the process execution. The ProcessGUID field is a unique value for this process across a domain to make event correlation easier. The hash is a full hash of the file with the algorithms in the HashType field.

Event ID 2: A process changed a file creation time

The change file creation time event is registered when a file creation time is explicitly modified by a process. This event helps tracking the real creation time of a file. Attackers may change the file creation time of a backdoor to make it look like it was installed with the operating system. Note that many processes legitimately change the creation time of a file; it does not necessarily indicate malicious activity.

Event ID 3: Network connection

The network connection event logs TCP/UDP connections on the machine. It is disabled by default. Each connection is linked to a process through the ProcessId and ProcessGUID fields. The event also contains the source and destination host names IP addresses, port numbers and IPv6 status.

Event ID 4: Sysmon service state changed

The service state change event reports the state of the Sysmon service (started or stopped).

Event ID 5: Process terminated

The process terminate event reports when a process terminates. It provides the UtcTime, ProcessGuid and ProcessId of the process.

Event ID 6: Driver loaded

The driver loaded events provides information about a driver being loaded on the system. The configured hashes are provided as well as signature information. The signature is created asynchronously for performance reasons and indicates if the file was removed after loading.

Event ID 7: Image loaded

The image loaded event logs when a module is loaded in a specific process. This event is disabled by default and needs to be configured with the –l option. It indicates the process in which the module is loaded, hashes and signature information. The signature is created asynchronously for performance reasons and indicates if the file was removed after loading. This event should be configured carefully, as monitoring all image load events will generate a large number of events.

Event ID 8: CreateRemoteThread

The CreateRemoteThread event detects when a process creates a thread in another process. This technique is used by malware to inject code and hide in other processes. The event indicates the source and target process. It gives information on the code that will be run in the new thread: StartAddress, StartModule and StartFunction. Note that StartModule and StartFunction fields are inferred, they might be empty if the starting address is outside loaded modules or known exported functions.

Event ID 9: RawAccessRead

The RawAccessRead event detects when a process conducts reading operations from the drive using the \\.\ denotation. This technique is often used by malware for data exfiltration of files that are locked for reading, as well as to avoid file access auditing tools. The event indicates the source process and target device.

Event ID 10: ProcessAccess

The process accessed event reports when a process opens another process, an operation that’s often followed by information queries or reading and writing the address space of the target process. This enables detection of hacking tools that read the memory contents of processes like Local Security Authority (Lsass.exe) in order to steal credentials for use in Pass-the-Hash attacks. Enabling it can generate significant amounts of logging if there are diagnostic utilities active that repeatedly open processes to query their state, so it generally should only be done so with filters that remove expected accesses.

Event ID 11: FileCreate

File create operations are logged when a file is created or overwritten. This event is useful for monitoring autostart locations, like the Startup folder, as well as temporary and download directories, which are common places malware drops during initial infection.

Event ID 12: RegistryEvent (Object create and delete)

Registry key and value create and delete operations map to this event type, which can be useful for monitoring for changes to Registry autostart locations, or specific malware registry modifications.

Sysmon uses abbreviated versions of Registry root key names, with the following mappings:

Key nameAbbreviation

HKEY_LOCAL_MACHINEHKLM

HKEY

HKEY_USERS

HKU

HKEY_LOCAL_MACHINE\System\ControlSet00x

HKLM\System\CurrentControlSet

HKEY_LOCAL_MACHINE\Classes

HKCR

Event ID 13: RegistryEvent (Value Set)

This Registry event type identifies Registry value modifications. The event records the value written for Registry values of type DWORD and QWORD.

Event ID 14: RegistryEvent (Key and Value Rename)

Registry key and value rename operations map to this event type, recording the new name of the key or value that was renamed.

Event ID 15: FileCreateStreamHash

This event logs when a named file stream is created, and it generates events that log the hash of the contents of the file to which the stream is assigned (the unnamed stream), as well as the contents of the named stream. There are malware variants that drop their executables or configuration settings via browser downloads, and this event is aimed at capturing that based on the browser attaching a Zone.Identifier “mark of the web” stream.

Event ID 17: PipeEvent (Pipe Created)

This event generates when a named pipe is created. Malware often uses named pipes for interprocess communication.

Event ID 18: PipeEvent (Pipe Connected)

This event logs when a named pipe connection is made between a client and a server.

Event ID 19: WmiEvent (WmiEventFilter activity detected)

When a WMI event filter is registered, which is a method used by malware to execute, this event logs the WMI namespace, filter name and filter expression.

Event ID 20: WmiEvent (WmiEventConsumer activity detected)

This event logs the registration of WMI consumers, recording the consumer name, log, and destination.

Event ID 21: WmiEvent (WmiEventConsumerToFilter activity detected)

When a consumer binds to a filter, this event logs the consumer name and filter path.

Event ID 255: Error

This event is generated when an error occurred within Sysmon. They can happen if the system is under heavy load and certain tasked could not be performed or a bug exists in the Sysmon service. You can report any bugs on the Sysinternals forum or over Twitter (@markrussinovich).

Mapping the STIX cyber observables to the Sysmon Event IDs, we can see that it covers a good amount of the information you need to identify and detect threats.

The greatest benefit with using Sysmon is that it acts as a recorder for memory artifacts relevant to threat-intel correlation. Usually, you would need to be lucky and conduct a live memory acquisition on a device while an attack was in progress to obtain a lot of the information Sysmon captures overtime. With Sysmon, you can now capture the artifacts on the host without any additional acquisition tools or networking logging devices. You are only limited by the amount of storage you assign to the events. You can adjust the amount of storage for Sysmon logs through Windows Event Viewer.

First, open Windows Event Viewer and open the "Applications and Services Logs/Microsoft/Windows/ Sysmon/Operational" folder.

Next, Right-mouse click on the "Operational" logs item and click on "Properties" to open the dialogue box that will allow you to adjust settings for the log.

Finally, adjust the "Maximum log size (KB)" options as you desire and click on the "Apply" button.

If you wanted longer term storage of Sysmon and other windows events, you should consider using Windows Event Forwarding and Windows Event Collector capabilities. Description on how to use those features are beyond the scope of this document. However, here are two essential links to Microsoft resources to get you started:

If you already have a logging system such as Splunk or others, they have their own agents and means of collecting and receiving Windows events. In addition to the Sysmon documentation there are other open source resources available to assist with configuring and tuning Sysmon to your needs. SwiftOnSecurity/sysmon-config GitHub project is one of many resources that attempt to assist with configuring optimally.

Conclusion

The U.S. Computer Emergency Readiness Team continues to publish alerts on malware and attack techniques, which include multiple indicators of compromise (e.g. IP addresses, file names, domain names) in STIX format (see TA18-49A as an example) or enumerated ad hoc to help organizations determine whether that threat exists on their network. However, those indicators (STIX Cyber Observables) are not useful unless organizations have way to record those relevant indicators on their network and are able search through them. Sysmon is a cost-effective solution that does that and enables every Windows-based organization to better leverage the threat-intel resources they receive on a daily basis in order to protect their network. Although this article focused on Sysmon, you should definitely assess cybersecurity tools based on the relevant artifacts that it can observe and record using the STIX Cyber Observables as a base set.