Set Advanced Audit Settings via Local Group Policy

If advanced audit settings are changed in the local group policy, the following file is modified:

%WINDIR%system32grouppolicymachinemicrosoftwindows ntauditaudit.csv

If no advanced audit settings were applied to the system before, the audit.csv file will be created. The grouppolicy folder is hidden. To view it in the Windows File Explorer, enable the “Show hidden files, folders, and drives” option in the Folder Options.

Figure 2-4 shows an example of the audit.csv file content.

The Machine Name column should always be empty.

The Inclusion Settings column shows which auditing settings are set for a specific subcategory.

The Exclusion column was designed for use with per-user auditing policies, but because per-user policies don't have group policy settings to configure them, this column is always empty.

The Setting Value column shows a numeric value associated with the Inclusion Setting column value:

• 0: No Auditing
• 1: Success
• 2: Failure
• 3: Success and Failure

After the audit.csv file is created/modified, it is merged with the local advanced audit settings in the Local Security Authority (LSA) policy database. LSA policy database is located in the HKLMSECURITYPolicy registry key. Auditing settings are stored in the Default value of the HKLMSECURITYPolicyPolAdtEv registry key. The existing setting for the subcategory will be replaced by the settings from the local group policy, except those set to “Not Configured” in group policy.

Set Advanced Audit Settings via Domain Group Policy

Advanced audit settings modification using domain group policy is similar to the process for local group policy that was explained in the previous section. After domain policy is applied, group policy settings are copied locally to the %WINDIR%GroupPolicyDataStoresysvolDOMAIN_NAMEPolicies folder. Each group policy has its own folder in this directory, named by its group policy GUID. The group policy folder, if any advanced audit settings were enabled, has a group_policy_foldermachinemicrosoftwindows ntauditaudit.csv file in it. Here is an example of the audit.csv path for one of the group policies applied to the machine in the lab domain:

C:WindowsSystem32GroupPolicyDataStoresysvolhqcorp.localPolicies{6AC1786C-016F-11D2-945F-00C04fB984F9}MachineMicrosoftWindows NTAuditaudit.csv

The audit.csv file has the same structure as discussed in the “Set Advanced Audit Settings via Local Group Policy” section.

After the audit.csv file is created/modified, it is also merged with the local advanced audit settings in the Local Security Authority (LSA) policy database. The process is the same as for local group policy.

Set Advanced Audit Settings in the Local Security Authority (LSA) Policy Database

The only way to modify advanced audit settings in the LSA Policy Database using built-in Windows tools is to use auditpol, which directly communicates with it.

To modify auditing settings for a subcategory, you need to execute the following command:

auditpol /set /subcategory:SUBCATEGORY_GUID_OR_NAME {options}

This command should be executed in an elevated command-line processor, not PowerShell. You already know how to find a GUID for a subcategory. The {options} section can have two parameters:

• /success: Enable success auditing setting
• /failure: Enable failure auditing setting

These two parameters may have one of the following two values assigned:

• enable: Enable setting
• disable: Disable setting

For example, if you need to enable Success auditing and disable Failure auditing (assuming it was enabled) for the Logoff subcategory, you may use one of the following commands:

• auditpol /set /subcategory:{0CCE9216-69AE-11D9-BED3-505054503030} /success:enable /failure:disable
• auditpol /set /subcategory:"Logoff" /success:enable /failure:disable

It is also possible to change settings for multiple subcategories by listing them one after another, separated by a comma: /subcategory:{0CCE9216-69AE-11D9-BED3-505054503030},{0CCE9240-69AE-11D9-BED3-505054503030}. This works only for GUIDs, not for subcategory names.

Read Current LSA Policy Database Advanced Audit Policy Settings

The only way to get current advanced audit settings directly from a local LSA Policy Database using built-in Windows tools is to use the auditpol tool, which directly queries information from it.

You can use the following command to get current settings:

auditpol /get /category:*

Advanced Audit Policies Enforcement and Legacy Policies Rollback

The new “Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings” group policy setting was introduced for the Windows Vista and Windows Server 2008 operating systems, which enforce the use of new advanced audit subcategories instead of legacy categories.

This group policy setting is located under the Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options group policy path. If it is enabled, legacy audit settings do not affect advanced audit subcategories settings. This group policy setting is enabled by default. It modifies the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa registry key's scenoapplylegacyauditpolicy value.

Possible values:

• 0: Disabled
• 1: Enabled

Table 2-2 contains a dependency scheme between legacy and advanced audit categories for operating systems starting from Windows Vista and Windows Server 2008.

For example, if the “Audit policy change” category is enabled for Success in legacy audit settings and some additional requirements (discussed in the following section) are met to permit the use of legacy settings, then all subcategories under the Policy Change advanced category will be enabled for Success auditing.

Manage Auditing and Security Log

The “Manage auditing and security log” group policy setting controls the SeSecurityPrivilege user privilege assignment . If an account or group is added to this group policy setting, the account or group members will have SeSecurityPrivilege user privilege on the host.

SeSecurityPrivilege allows managing the security event log, which allows viewing the log, changing the size of the log, clearing the log, and so on. It also allows viewing or setting an object's System Access Control List (SACL). SACL is used to store auditing settings for an object. The object in this case is any auditable object, such as registry keys, files or folders, processes, threads, and so on.

This group policy setting is located at the following path: Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesUser Rights Assignment.

See Chapter 11 for more information about user rights and privileges.

Generate Security Audits

The “Generate security audits” group policy setting controls the SeAuditPrivilege user privilege assignment to the accounts on the machine.

SeAuditPrivilege allows adding records to the security event logs. This privilege is required to use the ReportEvent() function from AdvApi32.dll. Event reporting functions are discussed in the “Windows Auditing Event Flow” section later in this chapter.

This group policy setting is located at the following path: Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesUser Rights Assignment.

Security Auditing Policy Security Descriptor

Security auditing policy has its own security descriptor that controls access to it. To view it, use the auditpol /get /sd command. The security descriptor is stored as a Security Descriptor Definition Language (SDDL) string. It contains only Discretionary Access Control List (DACL) Access Control Entries (ACEs) (D: section). DACL contains information about access permissions set on an object. See Chapter 10 for more information about SDDL. Here is an example of an audit policy security descriptor for Windows 10:

D:(A;;DCSWRPDTRC;;;BA)(A;;DCSWRPDTRC;;;SY)

• A: Allow access ACE type
• DCSWRPDTRC:
  • DC: Delete All Child Objects
  • SW: All Validated Writes
  • RP: Read All Properties
  • DT: Delete Subtree
  • RC: Read Permissions
• BA: BUILTINAdministrators group
• SY: Local System account

By default, the preceding security descriptor is set for the local security auditing policy on all Windows versions starting with Windows Vista.

You can set the security descriptor for the local auditing policy using the auditpol /set /sd: DESCRIPTOR_SDDL_STRING command.

To view or set the security descriptor for the local auditing policy using the auditpol tool, the account must have the SeSecurityPrivilege.

There is no group policy setting you can use to set the local auditing policy security descriptor. It is stored in the following registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaAuditAuditPolicy, with a value of AuditPolicySD.

Group Policy: “Audit: Shut Down System Immediately If Unable to Log Security Audits”

If this group policy setting is enabled, it causes the system to stop if a security audit event cannot be logged for any reason. It is a requirement for Trusted Computer System Evaluation Criteria (TCSEC)-C2 and Common Criteria certification to prevent auditable events from occurring if the audit system is unable to log them.

This policy modifies the following registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa, with a value of crashonauditfail. Possible values are:

• 0: Disabled
• 1: Enabled

It is also possible to modify the crashonauditfail value using the auditpol command:

• Disable: auditpol /set /option:CrashOnAuditFail /value:disable
• Enable: auditpol /set /option:CrashOnAuditFail /value:enable

If the crashonauditfail registry key value is modified, the event shown in Listing 2-1 is generated in the security event log.

The 4906 event shows the new value for the crashonauditfail registry key value.

If, for example, crashonauditfail is set to 1 and the security event log retention method is set to “Do not overwrite events ( Clear logs manually ),” and the event log reaches its maximum size, then the system will stop and the screen shown in Figure 2-5 will appear (Windows Server 2016).

Stop code 0xc0000244 has the following meaning: {Audit Failed} An attempt to generate a security audit failed.

The group policy setting path is Computer ConfigurationPoliciesWindows SettingsSecurity SettingsLocal PoliciesSecurity Options.

Group Policy: Protected Event Logging

Protected Event Logging is a new feature that allows Windows components and applications to encrypt their event logs using the Cryptographic Message Syntax (CMS) standard and asymmetric cryptography. For now the only application that supports protected event logging in Windows is PowerShell v5 and higher. Using this feature, PowerShell can write encrypted events in the PowerShell event log.

To enable this feature, you need to provide a certificate with a public key that will be used for encryption. Then you can use the Unprotect-CmsMessage PowerShell cmdlet to decrypt the event log.

The “Protected Event Logging” group policy setting is supported only by Windows 10 and Windows Server 2016. It is located at the following group policy path: Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsEvent Logging.

Group Policy: “Audit: Audit the Use of Backup and Restore Privilege”

The “Audit: Audit the use of Backup and Restore privilege” group policy setting allows you to enable full privilege use auditing, which includes the SeBackupPrivilege and SeRestorePrivilege privileges. Enabling it can cause a lot of heavy event logging. This group policy setting is explained in more detail in Chapter 11.

The associated registry value is HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa, fullprivilegeauditing. Possible values:

• 40: Disabled
• 41: Enabled

The group policy setting path is Computer ConfigurationPoliciesWindows SettingsSecurity SettingsLocal PoliciesSecurity Options.

Group Policy: “Audit: Audit the Access of Global System Objects”

The “Audit: Audit the access of global system objects” group policy setting works in conjunction with the “Audit object access” auditing subcategory setting. It enables default SACL on global system objects.

Global system objects are temporary kernel objects that have had names assigned to them by the application or system component that created them. These objects are most commonly used to synchronize multiple applications or multiple parts of a complex application. Because they have names, these objects are global in scope and, therefore, visible to all processes on the device. These objects all have a security descriptor; but typically, they do not have a SACL assigned. If you enable this policy setting and it takes effect at startup time, the kernel assigns a SACL to these objects when they are created. This policy setting does not affect container objects.

Usually, detailed access monitoring of access requests to global system objects, such as mutexes and semaphores, is not required and also generates a high volume of events.

This group policy setting is located at the following path: Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options.

The associated registry value is HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa, auditbaseobjects. Possible values are:

• 0: Disabled
• 1: Enabled

Audit the Access of Global System Container Objects

The “Audit: Audit the access of global system objects” policy setting discussed earlier does not enable auditing for global system container objects. Container objects might contain other global system objects. You can modify the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa, auditbasedirectories registry key value in order to enable this default SACL on global system container objects. Possible values for this key are:

• 0: Disabled
• 1: Enabled

Windows Event Log Service: Security Event Log Settings

The Windows Event Log service has its own settings for the security event log. These settings are stored in the local registry under the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEventLogSecurity registry key. Some of the settings also have group policy settings associated with them and can be configured using event log properties in the Event Viewer application (Figure 2-6).

The group policy settings are located under the following group policy path: Computer Configuration PoliciesAdministrative TemplatesWindows ComponentsEvent Log ServiceSecurity.

The following sections discuss the most common security event log settings.

Security Event Log Security Descriptor

Security event log security descriptor can be configured using the “Configure log access” group policy setting. But starting from Windows 10 and Windows Server 2016 the new “Configure log access (legacy)” policy setting was introduced. The path to this group policy setting is Computer ConfigurationPoliciesWindows SettingsSecurity SettingsEvent Log.

Table 2-3 shows differences between operating system versions for security event access control settings.

OPERATING SYSTEM	“CONFIGURE LOG ACCESS” REGISTRY VALUE	“CONFIGURE LOG ACCESS (LEGACY)” REGISTRY VALUE
Pre-Windows 10 and pre-Windows Server 2016	HKLMSoftwarePoliciesMicrosoftWindowsEventLogSecurity, ChannelAccess	Group policy setting does not exist
Windows 10 and Windows Server 2016	HKLMSoftwarePoliciesMicrosoftWindowsEventLogSecurity, ChannelAccess	HKLMSystemCurrentControlSetServicesEventLogSecurity, CustomSD

For Windows 10 and Windows Server 2016 it is recommended to set both policies for maximum application compatibility.

The “Configure log access” and “Configure log access (legacy)” group policy settings allow you to modify access rights for the security event log. The value for these group policy settings should be in Security Descriptor Definition Language (SDDL) format. SDDL format is described in Chapter 10.

To view current security event log security descriptor on the machine, use the wevtutil gl security command. The parameter that contains the SDDL string for the security descriptor is channelAccess. Figure 2-7 shows an example of the output for the wevtutil gl security command on a Windows Server 2016 machine.

Let's decode the SDDL string shown in Figure 2-7: O:BAG:SYD:(A;;0xf0005;;;SY)(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)

• O:BA: Owner of the object (security event log) is Built-in Administrators (BA) group
• G:SY: Primary group is Local System (SY)
• D:: The beginning of DACL section
• (A;;0xf0005;;;SY)
  • A: Allow access ACE type
  • 0xf0005: Full access
  • SY: Local System account
• (A;;0x5;;;BA)
  • A: Allow access ACE type
  • 0x5: Read, Clear
  • BA: BUILTINAdministrators group
• (A;;0x1;;;S-1-5-32-573)
  • A: Allow access ACE type
  • 0x1: Read
  • S-1-5-32-573: BUILTINEvent Log Readers group

Table 2-4 contains information about event log access permissions that may help you to understand SDDL ACEs.

HEXADECIMAL VALUE	ACCESS RIGHT
0x1	Read
0x2	Write
0x4	Clear
0xf0000	Full Access

The default value for security event log security descriptor depends on the operating system version. For all Windows versions starting from Windows Vista and Windows Server 2008 the default security descriptor is always the same as shown in Figure 2-7:

• Local System: Full access
• Built-in Administrators: Read, Clear
• Event Log Readers: Read

Any Write (0x2) access permissions in the security event log security descriptor are ignored, because write access to the security event log is controlled by the SeAuditPrivilege (“Generate security audits” group policy setting).

Windows Auditing Policy Flow

Figure 2-8 shows the policy flow components and interactions between them. The numbers in the figure match the step numbers in the discussions that follow.

An auditing policy management application, such as auditpol.exe, Group Policy Editor (gpedit.msc), or domain policy processing (Group Policy Client service), invokes auditing-related functions in advapi32.dll (Advanced API) to set or read auditing policy settings. The following functions might be used to set or get current auditing policy settings:

• LsaSetInformationPolicy (PolicyAuditEventsInformation): Set auditing settings for the host.
• LsaQueryInformationPolicy (PolicyAuditEventsInformation): Get current auditing settings for the host.
• AuditSetPolicy: Set auditing settings for the host.
• AuditQueryPolicy: Get current auditing settings for the host.

Some differences in the process take place prior to Step 1 related to processing of legacy and advanced audit policies involving the audit.csv file. These differences are explained later in this section.

Windows Auditing Event Flow

Figure 2-9 shows the event flow components and interactions between them.

Multiple components report security events in both kernel and user modes. In Figure 2-9 these reporting methods and components are numbered using white circles and dotted lines:

1. User-Mode Windows Components: Multiple Windows components use private APIs from the AuthZ.dll library to report a security event. LSASS.exe has the RPC audit interface, which handles requests from these functions.
2. Applications (User Mode): Windows applications may use multiple public AuthZ.dll functions, such as the AuthzReportSecurityEvent or AuthzReportSecurityEventFromParams functions, to report a security event. LSASS.exe has the RPC audit interface, which handles requests from these functions.
3. Applications (reporting event for Kernel Mode): User-mode applications can also trigger security events by calling NTDLL.dll NT*AuditAlarm functions, such as NtOpenObjectAuditAlarm or NtPrivilegeObjectAuditAlarm. These function calls are handled by the Format & Policy component in the Security Reference Monitor's SeAudit routine.
4. Drivers: Drivers report events in the kernel mode using kernel routines such as SeReportSecurityEvent or SeReportSecurityEventWithSubCategory. These routine calls are handled by the Format & Policy component in the Security Reference Monitor's SeAudit routine.
5. Object Manager and other kernel components: Kernel components use private kernel-mode audit APIs to report a security event.
6. Internal LSA components: Internal LSA components may also report a security event using internal LSA audit APIs.

There are two main event flows: events reported to LSASS.exe and events reported to NTOSKRNL.exe. The following sections discuss both of them.