April 11, 2019 at 07:05What useful things can be pulled from the logs of a Windows-based workstation
The user workstation is the most vulnerable infrastructure in terms of information security. Users may receive a letter from their working mail that seems to be from a safe source, but with a link to the infected site. Perhaps someone will download a utility useful for work from an unknown location. Yes, you can come up with more than a dozen cases, how through users malware can infiltrate into internal corporate resources. Therefore, workstations require increased attention, and in the article we will tell you where and what events to take to track attacks.
There are three useful event sources for detecting an attack at an early stage in Windows: a security event log, a system monitoring log, and Power Shell logs.
This is the main storage location for system security logs. This includes user login / logout events, access to objects, changes in policies and other security related activities. Of course, if the appropriate policy is configured.
Enumeration of users and groups (events 4798 and 4799). Malicious software at the very beginning of an attack often goes through local user accounts and local groups on a workstation to find credentials for its dark affairs. These events will help detect malicious code before it moves further and, using the collected data, will spread to other systems.
Creating a local account and changing local groups (events 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 and 5377).An attack can also begin, for example, by adding a new user to a group of local administrators.
Attempts to log in with a local account (event 4624). Good users log in with a domain account and identifying an entry under a local account may indicate the beginning of an attack. Event 4624 also includes logins under a domain account, so when processing events, you need to filter out events in which the domain is different from the name of the workstation.
Login attempt with a given account (event 4648). This happens when the process is running in “Run as” mode. In normal operation of systems, this should not be, therefore, such events should be controlled.
Workstation lock / unlock (events 4800-4803). Suspicious events include any actions that occurred on a locked workstation.
Firewall configuration changes (events 4944-4958). Obviously, when installing new software, the firewall configuration settings may change, which will cause false positives. In most cases, it is not necessary to control such changes, but it will not be superfluous to know about them.
Connecting Plug'n'play devices (event 6416 and only for WIndows 10). It is important to monitor this, if users usually do not connect new devices to the workstation, and then all of a sudden, they’ve connected it.
Windows includes 9 audit categories and 50 subcategories for fine-tuning. The minimum set of subcategories that should be included in the settings:
Logon / Logoff
Account management
Policy change
Sysmon is a built-in utility in Windows that can write events to the system log. It is usually required to install it separately.
The same events can in principle be found in the security log (by including the desired audit policy), but Sysmon provides more details. What events can be taken from Sysmon?
Creating a process (event ID 1). The system event log of security events can also tell when some * .exe has started and even show its name and start path. But unlike Sysmon, it will not be able to show the hash of the application. Malicious software may even be called harmless notepad.exe, but it is the hash that will put it in clear water.
Network Connections (Event ID 3).Obviously, there are many network connections, and you can’t keep track of everyone. But it’s important to consider that Sysmon, unlike the Security Log, can bind a network connection to the ProcessID and ProcessGUID fields, shows the port and IP addresses of the source and receiver.
Changes in the registry (event ID 12-14). The easiest way to add yourself to startup is to register in the registry. Security Log can do this, but Sysmon shows who made the changes, when, where, process ID and previous key value.
File creation (event ID 11). Sysmon, unlike Security Log, will show not only the location of the file, but also its name. It is clear that you can’t keep track of everything, but you can also audit certain directories.
And now what Security Log policies do not have, but are in Sysmon:
Change file creation time (event ID 2). Some malware may replace the file creation date to hide it from reports with recently created files.
Download drivers and dynamic libraries (event ID 6-7). Tracking the loading of DLL and device drivers into memory, verification of digital signature and its validity.
Creating a thread in an ongoing process (event ID 8). One type of attack that you also need to monitor.
RawAccessRead events (event ID 9). Read operations from disk using “\\. \”. In the vast majority of cases, such activity should be considered abnormal.
Creating a named file stream (event ID 15).An event is logged when a named file stream is generated that generates events with a hash of the contents of the file.
Creating a named pipe and connection (event ID 17-18). Tracking malicious code that communicates with other components through a named pipe.
WMI activity (event ID 19). Registration of events that are generated when accessing the system via WMI protocol.
To protect Sysmon itself, you need to track events with ID 4 (stop and start Sysmon) and ID 16 (change Sysmon configuration).
Power Shell is a powerful tool for managing Windows infrastructure, so there is a good chance that the attacker will choose it. You can use two sources to get information about Power Shell events: Windows PowerShell log and Microsoft-WindowsPowerShell / Operational log.
Data provider loaded (event ID 600). PowerShell providers are programs that serve as a data source for PowerShell to view and manage them. For example, the built-in providers may be Windows environment variables or the registry. The emergence of new suppliers must be monitored in order to identify malicious activity in time. For example, if you see WSMan appearing among providers, then a remote PowerShell session has been started.
Module journaling (event ID 4103). The events store information about each command executed and the parameters with which it was called.
Script lock logging (event ID 4104). Script lock logging shows each block of PowerShell code executed. Even if an attacker tries to hide the command, this type of event will show the actually executed PowerShell command. Even in this type of event, some low-level API calls can be recorded, these events are usually written as Verbose, but if a suspicious command or script is used in a code block, it will be registered as Warning with criticality.
Please note that after setting up the tool for collecting and analyzing these events, additional debugging time will be required to reduce the number of false positives.
Tell us in the comments what logs you collect for information security auditing and what tools you use for this. One of our areas is solutions for auditing information security events. To solve the problem of collecting and analyzing logs, we can offer a closer look at Quest InTrust , which can compress stored data with a ratio of 20: 1, and one installed instance is capable of processing up to 60,000 events per second from 10,000 sources.
There are three useful event sources for detecting an attack at an early stage in Windows: a security event log, a system monitoring log, and Power Shell logs.
Security Log
This is the main storage location for system security logs. This includes user login / logout events, access to objects, changes in policies and other security related activities. Of course, if the appropriate policy is configured.
Enumeration of users and groups (events 4798 and 4799). Malicious software at the very beginning of an attack often goes through local user accounts and local groups on a workstation to find credentials for its dark affairs. These events will help detect malicious code before it moves further and, using the collected data, will spread to other systems.
Creating a local account and changing local groups (events 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 and 5377).An attack can also begin, for example, by adding a new user to a group of local administrators.
Attempts to log in with a local account (event 4624). Good users log in with a domain account and identifying an entry under a local account may indicate the beginning of an attack. Event 4624 also includes logins under a domain account, so when processing events, you need to filter out events in which the domain is different from the name of the workstation.
Login attempt with a given account (event 4648). This happens when the process is running in “Run as” mode. In normal operation of systems, this should not be, therefore, such events should be controlled.
Workstation lock / unlock (events 4800-4803). Suspicious events include any actions that occurred on a locked workstation.
Firewall configuration changes (events 4944-4958). Obviously, when installing new software, the firewall configuration settings may change, which will cause false positives. In most cases, it is not necessary to control such changes, but it will not be superfluous to know about them.
Connecting Plug'n'play devices (event 6416 and only for WIndows 10). It is important to monitor this, if users usually do not connect new devices to the workstation, and then all of a sudden, they’ve connected it.
Windows includes 9 audit categories and 50 subcategories for fine-tuning. The minimum set of subcategories that should be included in the settings:
Logon / Logoff
- Logon;
- Logoff;
- Account Lockout;
- Other Logon / Logoff Events.
Account management
- User Account Management;
- Security Group Management.
Policy change
- Audit Policy Change
- Authentication Policy Change;
- Authorization Policy Change.
System Monitor (Sysmon)
Sysmon is a built-in utility in Windows that can write events to the system log. It is usually required to install it separately.
The same events can in principle be found in the security log (by including the desired audit policy), but Sysmon provides more details. What events can be taken from Sysmon?
Creating a process (event ID 1). The system event log of security events can also tell when some * .exe has started and even show its name and start path. But unlike Sysmon, it will not be able to show the hash of the application. Malicious software may even be called harmless notepad.exe, but it is the hash that will put it in clear water.
Network Connections (Event ID 3).Obviously, there are many network connections, and you can’t keep track of everyone. But it’s important to consider that Sysmon, unlike the Security Log, can bind a network connection to the ProcessID and ProcessGUID fields, shows the port and IP addresses of the source and receiver.
Changes in the registry (event ID 12-14). The easiest way to add yourself to startup is to register in the registry. Security Log can do this, but Sysmon shows who made the changes, when, where, process ID and previous key value.
File creation (event ID 11). Sysmon, unlike Security Log, will show not only the location of the file, but also its name. It is clear that you can’t keep track of everything, but you can also audit certain directories.
And now what Security Log policies do not have, but are in Sysmon:
Change file creation time (event ID 2). Some malware may replace the file creation date to hide it from reports with recently created files.
Download drivers and dynamic libraries (event ID 6-7). Tracking the loading of DLL and device drivers into memory, verification of digital signature and its validity.
Creating a thread in an ongoing process (event ID 8). One type of attack that you also need to monitor.
RawAccessRead events (event ID 9). Read operations from disk using “\\. \”. In the vast majority of cases, such activity should be considered abnormal.
Creating a named file stream (event ID 15).An event is logged when a named file stream is generated that generates events with a hash of the contents of the file.
Creating a named pipe and connection (event ID 17-18). Tracking malicious code that communicates with other components through a named pipe.
WMI activity (event ID 19). Registration of events that are generated when accessing the system via WMI protocol.
To protect Sysmon itself, you need to track events with ID 4 (stop and start Sysmon) and ID 16 (change Sysmon configuration).
Power Shell Magazines
Power Shell is a powerful tool for managing Windows infrastructure, so there is a good chance that the attacker will choose it. You can use two sources to get information about Power Shell events: Windows PowerShell log and Microsoft-WindowsPowerShell / Operational log.
Windows PowerShell log
Data provider loaded (event ID 600). PowerShell providers are programs that serve as a data source for PowerShell to view and manage them. For example, the built-in providers may be Windows environment variables or the registry. The emergence of new suppliers must be monitored in order to identify malicious activity in time. For example, if you see WSMan appearing among providers, then a remote PowerShell session has been started.
Microsoft-WindowsPowerShell / Operational log (or MicrosoftWindows-PowerShellCore / Operational in PowerShell 6)
Module journaling (event ID 4103). The events store information about each command executed and the parameters with which it was called.
Script lock logging (event ID 4104). Script lock logging shows each block of PowerShell code executed. Even if an attacker tries to hide the command, this type of event will show the actually executed PowerShell command. Even in this type of event, some low-level API calls can be recorded, these events are usually written as Verbose, but if a suspicious command or script is used in a code block, it will be registered as Warning with criticality.
Please note that after setting up the tool for collecting and analyzing these events, additional debugging time will be required to reduce the number of false positives.
Tell us in the comments what logs you collect for information security auditing and what tools you use for this. One of our areas is solutions for auditing information security events. To solve the problem of collecting and analyzing logs, we can offer a closer look at Quest InTrust , which can compress stored data with a ratio of 20: 1, and one installed instance is capable of processing up to 60,000 events per second from 10,000 sources.