What is useful you can get out of the logs of the workstation based on Windows
The user workstation is the most vulnerable spot of the infrastructure in terms of information security. Users may receive an email from a secure source, but with a link to an infected site. It is possible that someone will download a utility that is useful for work from an unknown place. Yes, you can come up with more than a dozen cases, as through users of malware can be embedded in corporate resources. Therefore, workstations require special attention, and in the article we will tell where and what events to take to track attacks.
To detect attacks at the earliest stage in Windows, there are three useful event sources: security event log, system monitoring log and Power Shell logs.
This is the main storage location for system security logs. This includes events for users to sign in / out, access to objects, changes in policies and other security related activities. Of course, if the appropriate policy is configured.
')
Search of users and groups (events 4798 and 4799). Malicious software at the very beginning of the attack often enumerates local user accounts and local groups on a workstation to find credentials for their dark business. These events will help detect malicious code before it moves on and, using the collected data, spread to other systems.
Creating a local account and changes in 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 the local administrators group.
Attempts to login with a local account (event 4624). Respectable users log in with a domain account and identifying the login under a local account can signify the start of an attack. Event 4624 also includes entries under the domain account, so when processing events you need to filter events in which the domain is different from the name of the workstation.
Attempt to log in with the specified account (event 4648). This happens when a process runs in the Run as mode. In the normal operation of the systems this should not be, therefore, such events should be controlled.
Lock / unlock the workstation (events 4800-4803). The category of suspicious events includes any actions that took place on a locked workstation.
Firewall configuration changes (events 4944-4958). Obviously, when installing a new software, the configuration of the firewall configuration may change, which will cause false positives. To control such changes in most cases is not necessary, but knowing about them will definitely not be superfluous.
Connecting devices Plug'n'play (event 6416 and only for WIndows 10). It is important to keep an eye on this if users usually do not connect new devices to the workstation, and then suddenly once - and connected.
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 Windows utility that can write events to the system log. It is usually required to install it separately.
These same events can in principle be found in the security log (by including the required audit policy), but Sysmon gives more details. What events can be taken from Sysmon?
Process creation (event ID 1). The system security event log can also tell when any * .exe is running and even show its name and startup path. But unlike Sysmon will not be able to show the application hash. Malicious software can even be called harmless notepad.exe, but it is the hash that will bring it to light.
Network connections (event ID 3). Obviously, there are a lot of network connections, and not to keep track of everyone. But it is important to note that, unlike Security Log, Sysmon is able to bind the network connection to the ProcessID and ProcessGUID fields, shows the port and IP addresses of the source and destination.
Changes in the registry (event ID 12-14). The easiest way to add yourself to autostart is to register in the registry. Security Log can do this, but Sysmon shows who made the changes, when, from where, the process ID and the 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 will not follow everything, but you can also audit certain directories.
And now what the Security Log policies do not have, but it is in Sysmon:
Change file creation time (event ID 2). Some malware can replace the date the file was created to hide it from reports with recently created files.
Download drivers and dynamic libraries (event ID 6-7). Tracking of loading into memory of DLL and device drivers, verification of digital signature and its validity.
Creating a thread in a running process (event ID 8). One type of attack, for which you also need to follow.
RawAccessRead events (event ID 9). Disk read operations with “\\. \”. In most cases, such activity should be considered abnormal.
Creating a named file stream (event ID 15). An event is registered when a named file stream is created that generates events with a hash of the contents of the file.
Creating named pipe and connections (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 using the 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 chances are high that the attacker will choose him. Two sources can be used to get data about Power Shell events: Windows PowerShell log and Microsoft-Windows PowerShell / Operational log.
A data provider has been loaded (event ID 600). PowerShell providers are programs that serve as a data source for PowerShell to view and manage. For example, embedded providers may be Windows environment variables or the system registry. The emergence of new suppliers should be monitored in order to identify malicious activity in time. For example, if you see that WSMan has appeared among the suppliers, it means that a remote PowerShell session has been started.
Module logging (event ID 4103). The events store information about each command executed and the parameters with which it was called.
Logging script blocking (event ID 4104). Script Blocking Logging shows every executed block of PowerShell code. Even if an attacker tries to hide a command, this type of event will actually show the executed PowerShell command. Even in this type of event some low-level API calls can be executed, these events are usually recorded as Verbose, but if a suspicious command or script is used in a block of code, it will be recorded as Warning critical.
Please note that after setting up the tool to collect and analyze these events, additional time will be needed for debugging to reduce the number of false positives.
Tell us in the comments what logs are collected for the audit of information security and what tools for this use. 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 by a factor of 20: 1, and one of its installed instances is capable of processing up to 60,000 events per second from 10,000 sources.
To detect attacks at the earliest stage in Windows, there are three useful event sources: security event log, system monitoring log and Power Shell logs.
Security Event Log
This is the main storage location for system security logs. This includes events for users to sign in / out, access to objects, changes in policies and other security related activities. Of course, if the appropriate policy is configured.
')
Search of users and groups (events 4798 and 4799). Malicious software at the very beginning of the attack often enumerates local user accounts and local groups on a workstation to find credentials for their dark business. These events will help detect malicious code before it moves on and, using the collected data, spread to other systems.
Creating a local account and changes in 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 the local administrators group.
Attempts to login with a local account (event 4624). Respectable users log in with a domain account and identifying the login under a local account can signify the start of an attack. Event 4624 also includes entries under the domain account, so when processing events you need to filter events in which the domain is different from the name of the workstation.
Attempt to log in with the specified account (event 4648). This happens when a process runs in the Run as mode. In the normal operation of the systems this should not be, therefore, such events should be controlled.
Lock / unlock the workstation (events 4800-4803). The category of suspicious events includes any actions that took place on a locked workstation.
Firewall configuration changes (events 4944-4958). Obviously, when installing a new software, the configuration of the firewall configuration may change, which will cause false positives. To control such changes in most cases is not necessary, but knowing about them will definitely not be superfluous.
Connecting devices Plug'n'play (event 6416 and only for WIndows 10). It is important to keep an eye on this if users usually do not connect new devices to the workstation, and then suddenly once - and connected.
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 Windows utility that can write events to the system log. It is usually required to install it separately.
These same events can in principle be found in the security log (by including the required audit policy), but Sysmon gives more details. What events can be taken from Sysmon?
Process creation (event ID 1). The system security event log can also tell when any * .exe is running and even show its name and startup path. But unlike Sysmon will not be able to show the application hash. Malicious software can even be called harmless notepad.exe, but it is the hash that will bring it to light.
Network connections (event ID 3). Obviously, there are a lot of network connections, and not to keep track of everyone. But it is important to note that, unlike Security Log, Sysmon is able to bind the network connection to the ProcessID and ProcessGUID fields, shows the port and IP addresses of the source and destination.
Changes in the registry (event ID 12-14). The easiest way to add yourself to autostart is to register in the registry. Security Log can do this, but Sysmon shows who made the changes, when, from where, the process ID and the 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 will not follow everything, but you can also audit certain directories.
And now what the Security Log policies do not have, but it is in Sysmon:
Change file creation time (event ID 2). Some malware can replace the date the file was created to hide it from reports with recently created files.
Download drivers and dynamic libraries (event ID 6-7). Tracking of loading into memory of DLL and device drivers, verification of digital signature and its validity.
Creating a thread in a running process (event ID 8). One type of attack, for which you also need to follow.
RawAccessRead events (event ID 9). Disk read operations with “\\. \”. In most cases, such activity should be considered abnormal.
Creating a named file stream (event ID 15). An event is registered when a named file stream is created that generates events with a hash of the contents of the file.
Creating named pipe and connections (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 using the 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 chances are high that the attacker will choose him. Two sources can be used to get data about Power Shell events: Windows PowerShell log and Microsoft-Windows PowerShell / Operational log.
Windows PowerShell log
A data provider has been loaded (event ID 600). PowerShell providers are programs that serve as a data source for PowerShell to view and manage. For example, embedded providers may be Windows environment variables or the system registry. The emergence of new suppliers should be monitored in order to identify malicious activity in time. For example, if you see that WSMan has appeared among the suppliers, it means that a remote PowerShell session has been started.
Microsoft-WindowsPowerShell / Operational log (or MicrosoftWindows-PowerShellCore / Operational in PowerShell 6)
Module logging (event ID 4103). The events store information about each command executed and the parameters with which it was called.
Logging script blocking (event ID 4104). Script Blocking Logging shows every executed block of PowerShell code. Even if an attacker tries to hide a command, this type of event will actually show the executed PowerShell command. Even in this type of event some low-level API calls can be executed, these events are usually recorded as Verbose, but if a suspicious command or script is used in a block of code, it will be recorded as Warning critical.
Please note that after setting up the tool to collect and analyze these events, additional time will be needed for debugging to reduce the number of false positives.
Tell us in the comments what logs are collected for the audit of information security and what tools for this use. 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 by a factor of 20: 1, and one of its installed instances is capable of processing up to 60,000 events per second from 10,000 sources.
Source: https://habr.com/ru/post/447522/
All Articles