The user workstation is the most vulnerable point of the infrastructure in terms of information security. Users may receive a letter to their work mail that seems to be from a safe source, but with a link to an infected site. Perhaps someone will download a utility useful for work from an unknown place. Yes, you can come up with more than a dozen cases of how malware can infiltrate internal corporate resources through users. Therefore, workstations require increased attention, and in this article we will tell you where and what events to take to track attacks.
To detect an attack at an early stage, Windows has three useful event sources: the security event log, the system monitoring log, and the Power Shell logs.
Security Log
This is the main storage location for system security logs. This includes events of user login / logout, access to objects, policy changes and other security-related activities. Of course, if the appropriate policy is configured.
Enumerating users and groups (events 4798 and 4799). Malware at the very beginning of an attack often enumerates local user accounts and local groups on a workstation to find credentials for its dark deeds. These events help detect malicious code before it moves on and uses the collected data to spread to other systems.
Local account creation and changes in local groups (events 4720, 4722-4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 and 5377). The attack can also start, for example, by adding a new user to the local administrators group.
Local login attempts (event 4624). Respectable users log in with a domain account, and detecting a login under a local account can mean the beginning of an attack. Event 4624 also includes domain logins, so when handling events, you need to filter out events where the domain is different from the workstation name.
An attempt was made to log in with the specified account (event 4648). This happens when the process is running in βRun asβ (run as) mode. In the normal operation of the systems, this should not happen, so such events should be controlled.
Workstation lock/unlock (events 4800-4803). Suspicious events include any activity that took place 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, there is no need to control such changes, but it will definitely not be superfluous to know about them.
Connecting Plug'n'play devices (event 6416 and only for WIndows 10). It is important to keep track of this if users usually do not connect new devices to the workstation, and then suddenly they did.
Windows includes 9 auditing categories and 50 sub-categories for fine-tuning. The minimum set of subcategories that should be enabled in the settings:
Logon/Logoff
- logon;
- log off;
- 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 utility built into Windows that can write events to the system log. It usually needs to be installed separately.
These same events can in principle be found in the security log (by enabling the appropriate 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 you when some *.exe was launched and even show its name and launch 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 bring it to clean water.
Network connections (event ID 3). Obviously, there are a lot of network connections, and you can't keep track of everyone. But it is important to keep in mind that Sysmon, unlike the same Security Log, can bind a network connection to the ProcessID and ProcessGUID fields, shows the port and IP addresses of the source and destination.
Changes in the system registry (event ID 12-14). The easiest way to add yourself to autorun is to register in the registry. The Security Log can do this, but Sysmon shows who made the changes, when, from where, the process ID and the previous value of the key.
File creation (event ID 11). Sysmon, unlike the 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 is not in the Security Log policies, but is in Sysmon:
Change of file creation time (event ID 2). Some malware can spoof the creation date of a file to hide it from recent file reports.
Loading drivers and dynamic libraries (event ID 6-7). Tracking the loading of DLLs and device drivers into memory, checking the digital signature and its validity.
Creation of a thread in a running process (event ID 8). One of the types of attack, which also needs to be monitored.
RawAccessRead events (event ID 9). Disk read operations with β.β. In the vast majority of cases, such activity should be considered abnormal.
Create a named file stream (event ID 15). The event is registered when a named file stream is created that generates events with a hash of the file's contents.
Create 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 the WMI protocol.
To protect Sysmon itself, you need to monitor events with ID 4 (stop and start Sysmon) and ID 16 (change Sysmon configuration).
Power Shell Logs
Power Shell is a powerful Windows infrastructure management tool, so chances are high that an attacker will choose it. There are two sources you can use to get data 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. For example, built-in providers can be Windows environment variables or the system registry. The emergence of new suppliers must be monitored in order to detect malicious activity in time. For example, if you see that WSMan has appeared among the providers, then a remote PowerShell session has been started.
Microsoft-WindowsPowerShell/Operational log (or MicrosoftWindows-PowerShellCore/Operational in PowerShell 6)
Module logging (event ID 4103). Events store information about each executed command and the parameters with which it was called.
Script blocking logging (event ID 4104). Script blocking logging shows each executed block of PowerShell code. Even if an attacker tries to hide the command, this event type will show the PowerShell command actually executed. Also in this type of event, some low-level API calls in progress can be recorded, these events are usually recorded as Verbose, but if a suspicious command or script is used in a block of code, it will be logged as critical Warning.
Please note that after setting up a 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 audits 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 suggest taking a closer look at , which can compress stored data at a ratio of 20:1, and one installed copy is capable of processing up to 60000 events per second from 10000 sources.
Source: habr.com