Let’s start with the basics. Windows security events monitoring.

Originally published in 2015.

Security logs collection and analysis is crucial for security incident detection and response. There are many tools that can help in this activity but they can be only as good as the data that is sent to them.

This guide concentrates on providing recommendations and ideas to consider when planning log collection approach for Windows operating system.

System Audit Policy

Windows security events are stored in Security.evtx file. Its contents should be the main focus of Windows OS security logs collection and monitoring. The type of events that are generated on a particular machine is controlled by the System Audit Policy which can be checked on local machine by running the auditpol /get /category:* command. Each category has a set of event IDs associated with it. Below is the list of recommended configuration options together with a list of associated event IDs that can be used as a reference.

Not all noisy events could be excluded as it is not possible to achieve this level of granularity by modifying the System Audit Policy settings. However, they could still be filtered out on the log collection layer.

The recommended approach presented below aims to be a good balance between keeping important forensics information while saving log management platform processing power and storage requirements. Having said that it is important to understand that some changes may drastically influence the amount of generated events what can potentially have a negative impact on the existing log collection environment. For that reason it is recommended to test every modification on limited number of machines before applying them on all member servers. It can also happen that depending on the given machine’s role in the network the landscape of generated event types and their number will be significantly different.

Account Logon

This category tracks all logon attempts made using domain accounts on a Domain Controller. If it is enabled on a local machine it will also track local logon attempts. Information that can be collected from events in this category will be often duplicated by the events that belong to the Logon/Logoff category but thanks to this one authentication attempts for domain accounts can be tracked even if we don’t have logs from the target member machine.

It is recommended to enable auditing of this category only on Domain Controllers.

Account Management

This category tracks changes made to the domain and local accounts and groups.

Detailed (process) tracking

This category tracks changes made to objects in AD. It can provide information (represented by a code) about which field was modified providing a good way to help maintain security policy assumptions and to track for disallowed settings being configured for AD objects.

Note that defining which properties should be audited and for which objects must be additionally defined on per object basis.

Logon/Logoff

This category tracks log on events related to a local computer. Events in this category supplement the Account logon category for instance by providing information about the actual logon types. Also in some cases (NTLM related) events logged in this category will provide information about IP addresses of authenticated clients which is not visible in the Account logon category events. For Domain Controllers this category tracks direct log on attempts made to them but not the attempts made to member servers authenticated by DC.

In short words this category is more about tracking a session on a target machine while the Account logon category is more about tracking authentication process performed using a Domain Controller.

*- Consider enabling on machines where NPS is configured

Object access

This is by far the noisiest category in the audit policy. It is used to track any kind of access to Windows objects (aside of Directory objects which are tracked by Directory service access). It is configured on two levels. The first one is about setting the desired audit policy on subcategories. The second one is about configuring what kind of access and made by whom to audit. This is configured on a per object basis (files, registry keys, services).

Getting the second level right is the most crucial thing to avoid flood of events. Good approach is to define critical objects and access types that you want to monitor for them. Start with Read data, Write data, Delete files and Change permissions accesses for crucial objects. Monitor the number of events closely especially on busy file servers. Definitely avoid applying the same configuration on all member servers.

While events is this category are very useful for forensics then defining too extensive list of monitored objects and access types can get both monitored systems and log collection solutions overwhelmed with these events.

*- Enabling this can provide useful information about network activity of a given machine especially name of the process that initiated a connection but it can result in huge event numbers. So if you can afford it then leave it audited but normally collecting logs/flows from firewall devices is enough to provide network context.

Policy change

This category tracks policy changes on local systems. It can provide important insight on changes made to important security settings. This category should be configured for Domain Controllers. It can disabled on member servers.

Privilege use

This category tracks usage of privileges assigned to users inside User Rights Assignment. In practice the events logged here do not provide very insightful information unless usage of some particular privileges needs to be tracked. From forensics standpoint these events could provide a bit more insight on malicious activities of a user but given the rates at which they are generated it is rather not worth to enable full auditing here.

System

Part of events generated in this category may provide some indicators of uncommon system actions or behavior. As it is not very noisy it can be partially audited.

From MS Technet:

“By auditing success and failure events in the system event category, you can notice unusual activity that may indicate that an intruder is attempting to gain access to your computer or your network.

The number of audits that are generated when this setting is enabled tends to be relatively low, and the quality of information that is gained from the events tends to be relatively high.”

Top events of interest

While collecting all relevant security events is crucial to facilitate incident response and forensics processes then monitoring all of them in real time might not be an efficient approach. That’s why it is worth to keep a closer look on the selected number of events. This approach should help in creating meaningful dashboards that could help in spotting anomalies in monitored environment. Below is a list of events that can be used in a whitelist filter to keep a closer look at them in real time.

4625 An account failed to log on
4649 A replay attack was detected
4697 A service was installed in the system
4698 A scheduled task was created
4699 A scheduled task was deleted
4700 A scheduled task was enabled
4706 A new trust was created to a domain
4719 System audit policy was changed
4720 A user account was created
4725 A user account was disabled
4726 A user account was deleted
4727 A security-enabled global group was created
4728 A member was added to a security-enabled global group
4731 A security-enabled local group was created
4732 A member was added to a security-enabled local group
4738 A user account was changed
4739 Domain Policy was changed
4740 A user account was locked out
4754 A security-enabled universal group was created
4756 A member was added to a security-enabled universal group
4794 An attempt was made to set the Directory Services Restore Mode administrator password
4799 A security-enabled local group membership was enumerated
4817 Auditing settings on object were changed
5038 Code integrity determined that the image hash of a file is not valid
5136 A directory service object was modified
5137 A directory service object was created

It is also worth to look at the most rarely executed processes and processes executed from user’s home directory by monitoring:

4688 A new process has been created

Going beyond standard events

While deploying a well-tuned Audit Policy is a major part of collecting important security information there are some additional things that can be done to improve visibility on Windows systems’ security without any need of installing 3rd party products.

AppLocker

From MS Technet: “AppLocker is a new feature in Windows 7 and Windows Server 2008 R2 that replaces the Software Restriction Policies feature. AppLocker contains new capabilities and extensions that reduce administrative overhead and help administrators control how users can access and use files, such as executable files, scripts, Windows Installer files, and DLLs.”

In short words AppLocker can be used to put restrictions on what software/scripts/executables can be safely run in a protected environment.

Enabling AppLocker on a machine will result in additional events being generated in the Application and services event log for AppLocker. The one interesting from security monitoring perspective are listed below.

8002  <File name> was allowed to run (exe and dll)
8003  <File name> was allowed to run but would have been prevented from running if the AppLocker policy were enforced (exe and dll)
8004  <File name> was not allowed to run (exe and dll)
8005  <File name> was allowed to run (script or msi)
8006  <File name> was allowed to run but would have been prevented from running if the AppLocker policy were enforced (script or msi)
8007  <File name> was not allowed to run (script or msi)

The great thing about AppLocker is that it can be run in Audit only mode that is useful for initial fine tuning of rules.

Planting credentials

One of the common methods used by attackers with local admin privileges on compromised machines to obtain valid credentials involves extracting them from memory. If successful it can provide clear text passwords, usernames and NTLM hashes of other users who were logging in on the compromised machine.

A neat way to make leaked credentials usage detection easier is to plant credentials for not existing users on some high risk/likely to compromise servers. When someone tries to use such account it will be immediately known that the credentials have leaked.

Planting the credentials must be scripted so they survive in memory. This can be done using runas command with /netonly option. It is important to understand that no actual user accounts are created here so these credentials can’t be used to do any harm.

Below is the example showing how this works.

Planting credentials in memory: