Ruslan Rakhmetov, Security Vision
When organising an IS management system in a company, many tasks are related to securing endpoints (workstations and servers) running Windows and Linux. The choice of protection means is large, but certain limitations are imposed by the budgets allocated for IS and compatibility of the considered protection systems with specific operating systems. Often, security solutions are required to implement security functions that are either inbuilt in the OS itself or freely distributed software. An example of such functionality is maintaining detailed logs of security events and transferring them to SIEM systems, given that IS analysts are usually interested in starting and stopping processes and services, network connections, changing endpoint configurations, and specific rare events indicating malicious activity. Analysing these events can help identify cyber incidents, and audit logs can provide valuable insights in a cyberattack investigation. One of the most useful tools for the SOC analyst is endpoint protection solutions (EDR, Endpoint Detection and Response), which combine detailed security logging, monitoring and blocking of dangerous activities, and centralised management. However, EDR systems of this type are not cheap, so in some cases it is advisable to consider some free utilities that at least partially implement the required functionality. One of such programmes is Sysmon (short for System Monitor) from the official Microsoft Sysinternals Suite, which is installed on Windows and Linux and allows you to perform an in-depth audit of OS operation in order to detect cyberattacks. This utility is well established among cybersecurity researchers and SOC centre analysts alike. In this article we will tell you in detail about Sysmon and give you recommendations on how to configure and use it.
According to the description on the official Sysmon page, this utility is designed to monitor and record system actions, it is installed as a service and driver, and also has the functionality of preventing unauthorised changes to its operation using Protected Process Light (PPL) technology. This technology is used in operating systems older than Windows 8.1 and allows you to protect critical digitally signed system processes from exposure to PPL or malicious user actions. Installing the Sysmon utility driver allows deeper access to OS operation data and starts collecting events as soon as the device is switched on, which helps detect stealthy RPOs running before the main OS components start. The fact that Sysmon events are recorded in the standard Windows log (Applications and Services Logs - Microsoft - Windows - Sysmon / Operational) simplifies the centralised collection of audit events into the SIEM system. The principle of data collection by the Sysmon utility is to make kernel callbacks to the Windows kernel, use Event Tracing for Windows (ETW for short), and make API calls to Windows telemetry providers. In Linux, Sysmon is based on the sysinternalsEBPF library, which uses eBPF technology to collect information about the operation of processes, system calls, and sockets. Sysmon events in Linux are written to the standard /var/log/syslog file.
The current version of the Sysmon utility for Windows has the following functionality:
- Logs process creation events with the startup command line and parent process data;
- Records the hash sum value of the process executable file using SHA1, MD5, SHA256, IMPHASH algorithms;
- Records driver and DLL downloads with their digital signatures and hash sums;
- Records raw access to discs and volumes;
- Logs network connections with the initiator process name, destination IP address, host name and port number;
- Detects changes in file creation date;
- Allows you to block the creation of EXE, DLL, SYS files in specific directories, with specific hash sums, created by specific parent processes;
- Allows to create flexible XML configurations with control objects to take into account all peculiarities of the environment.
To install Sysmon in a Windows environment, the following steps will be required:
1. Download the distribution from https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon.
2. optionally: create an XML file with Sysmon configuration.
3. Install sysmon (example for x64 architecture):
C:\folder\sysmon64.exe -accepteula -i C:\folder\sysmonconfig-export.xml, where sysmonconfig-export.xml is the configuration file, sysmon64.exe is the installer file.
Running the installation from a network folder is supported. The executable file of the Sysmon service after installation is located in the C:Windows/sysmon64.exe directory.
To install Sysmon in a Linux environment (for example, on Ubuntu), you will need to perform the following steps:
1. Register the Microsoft key and repository on the system:
wget -q https://packages.microsoft.com/config/ubuntu/$(lsb_release -rs)/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
2. Get an up-to-date list of packages:
sudo apt-get update
3. Install the utility:
sudo apt-get install sysmonforlinux
sudo sysmon -accepteula -i /opt/sysmon/config.xml , where config.xml is the configuration file
Let's consider the types of events that the Sysmon utility captures in the Windows environment:
1. Event ID 1: Process creation - the process creation event is logged with the start command line, parent process data, ProcessGUID value;
2. Event ID 2: A process changed a file creation time - changes in the file creation date are logged, as this technique is often used by attackers to hide traces of malicious activity;
3. Event ID 3: Network connection - logs the network activity of processes with the process path, protocol (TCP or UDP), destination IP address, hostname, port number;
4. Event ID 4: Sysmon service state changed - Sysmon service start and stop are registered;
5. Event ID 5: Process terminated - logs the termination of processes with the time, GUID and process ID;
6. Event ID 6: Driver loaded - logs the loading of drivers into the OS with their digital signatures and hash values;
7. Event ID 7: Image loaded - the loading of modules (DLL libraries) into the processes memory is registered with the indication of the process name, digital signatures and hash-sums of the loaded modules;
8. Event ID 8: CreateRemoteThread - this event registers the creation of a thread of one process in the address space of another process, i.e. code injection and migration of one process to another, which is often used as a method of hiding malicious activity;
9. Event ID 9: RawAccessRead (Direct Read Access) - direct access to discs and volumes is logged (specifying the process that gained access and the name of the disc/volume), which is often used by attackers to hide unauthorised access to data;
10. Event ID 10: ProcessAccess - access by one process to the memory of another process is logged, which is used by attackers to obtain sensitive information processed by critical system processes (e.g. the Lsass.exe process, which processes OS user credentials);
11. Event ID 11: FileCreate - file creation and overwriting is logged, which allows detecting the creation of VPO files in common directories (temporary folders, network download folders, autorun directories);
12. Event ID 12: RegistryEvent (Object create and delete) - registers the creation and deletion of registry keys and values, which allows monitoring the state of certain registry branches frequently used by the VPO;
13. Event ID 13: RegistryEvent (Value Set) - registers the change of values in the registry;
14. Event ID 14: RegistryEvent (Key and Value Rename) - registers changes to the names of keys and values in the registry;
15. Event ID 15: FileCreateStreamHash (FileCreateStreamHash) - the creation of an alternative data stream is registered, for example, when downloading files from the Internet and setting MOTW tags by browsers with the hash sum of the file;
16. Event ID 16: ServiceConfigurationChange - Sysmon configuration change is registered;
17. Event ID 17: PipeEvent (Pipe Created) - the creation of a named channel is registered, which is often used by the VPO to exchange data between processes;
18. Event ID 18: PipeEvent (Pipe Connected) - a named channel connection between a client and a server is registered;
19. Event ID 19: WmiEvent (WmiEventFilter activity detected) - WMI event filter creation activity is detected - WMI event filter creation is registered, which is often used by the VPO to trigger;
20. Event ID 20: WmiEvent (WmiEventConsumer activity detected) - WMI event consumer creation activity detected - WMI event consumer creation is logged, which is often used by the VPO as a method of entrenchment in a compromised system;
21. Event ID 21: WmiEvent (WmiEventConsumerToFilter activity detected) - WMI event consumer connection to event filter activity detected - event consumer connection to WMI event filter activity detected;
22. Event ID 22: DNSEvent (DNS query) - a DNS query from a process is registered regardless of the response received from the DNS server;
23. Event ID 23: FileDelete (File Delete archived) - deletion of a file with its copy saved in the Sysmon archive directory (by default, the C:\Sysmon folder is used) is registered;
24. Event ID 24: ClipboardChange (New content in the clipboard) - the change of the clipboard content is registered;
25. Event ID 25: ProcessTampering (Process image change) - attempts to hide processes using ‘Herpaderping’ and ‘Hollowing’ techniques are registered;
26. Event ID 26: FileDeleteDetected (File Delete logged) - file deletion is logged;
27. Event ID 27: FileBlockExecutable (FileBlockExecutable creation is blocked) - detection and blocking of executable file creation is logged;
28. Event ID 28: FileBlockShredding - detection and blocking of file deletion using special utilities (for example, using SDelete utility from Sysinternals package) is registered. 29;
29. Event ID 29: FileExecutableDetected - detection of executable file creation is registered.
For Linux-systems the events of Event ID 1, 3, 4, 5, 9, 11, 16, 23 types are registered, the descriptions of which correspond to those given above.
Note that XML configurations for Sysmon can be deeply customised to match the peculiarities of any infrastructure. As an example, the configurations below can be used, which are accompanied by comments from the authors and also take into account data from the MITRE ATT&CK project to match logged events with attacker techniques:
https://github.com/olafhartong/sysmon-modular
https://github.com/ion-storm/sysmon-config
https://github.com/SwiftOnSecurity/sysmon-config
https://github.com/microsoft/MSTIC-Sysmon/tree/main/linux/configs
