- AccessChk: View effective permissions on files and folders - Thu, Apr 13 2023
- Read NTFS permissions: View read, write, and deny access information with AccessEnum - Wed, Mar 29 2023
- Kill Windows a process with Tskill and Taskkill - Mon, Mar 13 2023
Collecting events generated in your environment is required not only for maintaining security, but also to meet compliance standards, especially for large enterprises or public companies that need to adopt CIS or similar standards.
If malicious activity occurs, proper security logs help you to detect the activity and identify its source. Without the logs, you will most likely never know that something happened, or it will be discovered after it is too late.
For example, if you have an employee who copies sensitive corporate data to a USB stick and gives it to your competition, but the action is not logged or stopped by a data loss prevention system (DLP), it will be impossible to identify the user and prove the incident occurred. But if you have a proper event recorded, with username and filenames, it will be hard for user to deny such activity.
Security log configuration
A properly configured audit policy will generate quite a lot of events, especially on servers such as domain controllers or file servers that are frequently accessed. Audit events are written to the Windows Security log. The default maximum log size, which is 128 MB, can only store a few hours' worth of data on a frequently used server. Be sure to configure the maximum size large enough to give you at least few days' worth of events. Ideally, the best practice is to forward specific events to systems such as SCOM, SysLog, or other SIEM tools.
Another item to configure is the retention method. The default option, if not defined by GPO, is Overwrite events as needed. With this configuration, you can be sure that events are always recorded and the log will not run out of space. On the other hand, if you do not forward events, they will be lost once overwritten.
Retention methods for the security log
With the other two options, you need to make sure the log can store a specific number of days or manually take care of the clearing.
Audit policy vs advanced audit policy
Configuration of the audit policy was the only option available prior to Windows Server 2008 R2.
Audit policy configuration
The capabilities of the audit policy were limited, so Microsoft introduced the advanced audit policy. The advanced audit policy enables more granularity with regard to the events that should be collected. There are 10 categories with more than 50 options to configure.
Advanced Audit Policy configuration
The rule of thumb here is only to configure the advanced audit policy, as configuring both can lead to unexpected events.
Let's take a look at each category and the best practice for its configuration. The convention is:
Name of the setting: recommended value
Account logon
Audit Credential Validation: Success, Failure
Allows you to audit events generated by validation tests on user account logon credentials. For domain accounts, the event is generated on the domain controller. Causes a high volume of events.
Account management
Account management settings allow administrators to track changes and events to detect malicious, authorized, or accidental activities.
Audit Application Group Management: Success, Failure
Audit Distribution Group Management: Success, Failure
Audit Security Group Management: Success, Failure
These settings enable corresponding group management activities, such as security group creation, adding or removing users, and so forth.
Audit Computer Account Management: Success, Failure
Audit User Account Management: Success, Failure
Audit computer and user account management, such as user account creation, password reset attempts, account was disabled, and SID history changes.
Detailed tracking
Audit PNP Activity: Success
Event is recorded when a plug-and-play device (such as a USB stick) is detected by the system. Email or other notification can be sent to IT staff to alert unapproved devices usage.
Audit Process Creation: Success
Audits when a new process is created, such as a user starting Wireshark to capture network traffic.
DS access
The two settings below are valid only for domain controllers and record any access or changes to objects having a system access control list (SACL) in Active Directory.
Audit Directory Service Access: Success, Failure
Audit Directory Service Changes: Success, Failure
Event 5136 shows my modification to the Domain Admins group (Object) when my account, named leos (Attribute), was added (Operation).
Directory Service changes event 5136
Logon/Logoff
Audit Account Lockout: Success, Failure
Records events for accounts that were locked due to bad password attempts.
Audit Group Membership: Success
Records the groups in which a user was a member at the time of logon. For domain accounts, the event is logged on domain controllers; for local accounts, it is logged on the local computer.
Audit Logoff: Success
Audit Logon: Success, Failure
These two options report user logon or logoff from the system. An event is logged on a local computer if the access is interactive or on a remote computer if the access is over a network (access to a shared folder).
Audit Other Logon/Logoff Events: Success, Failure
Audits events such as Remote Desktop session reconnect, workstation lock and unlock, etc.
Audit Special Logon: Success
Records logon events with administrator-equivalent privileges.
Object access
Audit Other Object Access Events: Success, Failure
Audits events related to COM+ objects and Task Scheduler jobs (job created, updated, or deleted).
Audit Removable Storage: Success, Failure
Audits access to removable drives, as mentioned in the example at the beginning of this post (data being copied to USB and given to the competition).
Policy change
Audit Policy Change: Success, Failure
Reports changes to system audit policy changes, such as enabling DS access auditing.
Audit policy change
Audit Authentication Policy Change: Success
Audits changes such as domain trust creation, modification, or removal, as well as granting user rights to allow logon locally, via Remote Desktop Services or as a batch job.
Audit Authorization Policy Change: Success
Audits changes not covered in the Authentication Policy Change, mentioned above, such as changes to the Encrypted File System policy or SeCreateTokenPrivilege (create a token object).
Privilege use
Audit Sensitive Privilege Use: Success, Failure
Creates a log event when a user (or a service account) uses any of the following sensitive privileges:
- Acts as part of the operating system
- Backs up files and directories
- Creates a token object
- Debugs programs
- Enables computer and user accounts to be trusted for delegation
- Generates security audits
- Impersonates a client after authentication
- Loads and unloads device drivers
- Manages auditing and security log
- Modifies firmware environment values
- Replaces a process-level token
- Restores files and directories
- Takes ownership of files or other objects
Note that this kind of configuration will create a high volume of events. However, it might be really useful to discover malicious activity.
System
Audit IPsec Driver: Success, Failure
Reports multiple events generated by IPsec driver activity, such as integrity checks, incorrect security parameter index (SPI), and so on.
Audit Other System Events: Success, Failure
Captures all kinds of events related to the Windows Firewall service.
Audit Security State Change: Success
Captures events related to the system security state, such as Windows startup, shutdown, or system time change.
Audit Security System Extension: Success, Failure
Includes events such as service installation in the system or loading of a security package by the Local Security Authority.
Audit System Integrity: Success, Failure
Captures events related to system integrity, such as an invalid hash value of a system image file. This might indicate corruption or an unauthorized change to the file.
Subscribe to 4sysops newsletter!
Conclusion
Over the years, Microsoft has integrated really powerful auditing capabilities into Windows Server systems. As you can see, it is possible to audit pretty much everything. Please be aware that, as always with security, you need to find a working balance for your environment. If you configure the audit policy as mentioned in this article, but your security log maximum size is only 256 MB with no event forwarding, you will find yourself just a couple of hours of logs, which is pretty much useless.
