Complete Guide to Auditing Object Access Events

“Absence of evidence is not evidence of absence.”

Evidence is the backbone of every investigation, both in regular crime and in cyber crime. The key for effective incident response when it comes (and nowadays, sooner or later it comes to everyone) is the trail of evidence that the attacker leaves behind.

It is very common for attackers to go the extra mile in their attack to destroy all available evidence – it is a known technique described by MITRE. This serves their purpose to remain undetected. Even if you detect the breach, you will have a hard time cleaning your system without knowing what the attacker left behind or reconfigured.

Our job as the defender is to make it harder for the attacker to evade us. One of the ways to do so is to properly set up your auditing workflows for object access events.

In this article we will go through the steps to set up the registry and enable file auditing. This will streamline response in case of an event or help your SOC to detect anomalies and alert on an attacker activity first.

To audit object access events, two conditions must be met:

Object access policy must be enabled
The policy should be applied to the object that needs to be audited

Enabling the Object access policy:

On your domain controller, open the group policy management view and find the audit policy you would like to edit.

This will open the group policy management window where we will edit the policy.

In this window, go to “Computer Configuration” -> “Policies” -> “Windows Settings” -> “Security Settings” -> “Local Policies” -> “Audit Policy”, find the “Audit object access” option and click on it.

This will open an editing window where you can choose to audit successful object access and failed object access. After making your selections, click “Apply”. Note that you can also choose only successful events, but this will not give you full visibility.

Now, all that’s left is to enable the new policy. This can be done by opening CMD or PowerShell with administrative privileges and executing the command “gpupdate /force”.

Applying the policy to a file domain-wide:

Now that the Object Access policy is enabled, we can move on to applying the policy to different objects.

In a domain environment, the policy can be applied to files across multiple systems by specifying file/directory paths in the group policy so that every computer with this path will automatically begin to audit this file/path.

Now you can right click in the right pane of the Group Policy Management Editor window and click “Add File…”

In the next window, choose the file or the directory you want to audit and click “OK”.

A new window will open named “Database Security for {path}. In this window, choose “Advanced”.

Next, choose the “Auditing” tab, then click on “Add” to create a new auditing entity.

Fill in the following information:

Principal: This is the users and groups you want to audit
Type: The type of the action to be performed on an object (Advised to choose “All”)
Applies to: This lets you choose what object specifically to apply the policy to.

Basic Permissions: Now choose the permissions you would like to audit and finally click “OK”

Now apply the changes and run the “gpupdate /force” command to apply the newly configured policy changes.

Applying the policy to a file in a standalone computer:

Now that the Object Access policy is enabled, we can move on to applying the policy to different objects.

First let’s apply the policy to a file/directory of our choice. To do so, open the “File Explorer” and find the directory/file you would like to audit. Then right-click on the directory/file and go to its properties. In the properties view, choose the security tab.

In the security tab, click “Advanced” and choose the “Auditing” tab. Then click on “Add” to create a new auditing entity.

Fill in the following information:

Principal: This is the users and groups you want to audit.
Type: The type of the action to be performed on an object (Advised to choose “All”).
Applies to: This lets you choose what object specifically to apply the policy to.

Basic Permissions: Now choose the permissions you would like to audit and finally click “OK”.

Applying the policy to a registry key domain-wide:

Similar to the application of the policy to a file, the policy can be applied to registry keys across multiple systems by specifying the key/subkey in the group policy. This enables automatic auditing for every computer that has this key or subkey.

In the same audit policy that was configured previously to audit object access events, go to “Computer Configuration” -> “Policies” -> “Windows Settings” -> “Security Settings” -> “Registry”. Then right click on the right pane of the group policy editor window and choose “Add Key…”.

In the newly opened window, choose the key/subkey you want to audit and click “OK”.

A new window will open named “database security for {key}”. In this window, choose “Advanced”.

Choose the “Auditing” tab. Then click on “Add” to create a new auditing entity.

Fill in the following information:

Principal: This is the users and groups you want to audit.
Type: The type of the action to be performed on an object (Advised to choose “All”).
Applies to: This lets you choose what object specifically to apply the policy to.

Basic Permissions: Now choose the permissions you would like to audit and finally click “OK”.

Now apply the changes and run the “gpupdate /force” command to apply the newly configured policy changes.

Applying the policy to a registry key in a standalone computer:

Similar to the application of the policy to a file, we will apply the policy to a registry object by first opening the registry editor and then choosing a key/subkey.

Right click on the object of choice and go to “Permissions”.

In the object’s permissions click on “Advanced”.

In the advanced settings, go to the auditing tab. Similar to applying the policy on a file, click on “Add” to add a new auditing entity.

Fill in the following information:

Principal: This is the users and groups you want to audit.
Type: The type of the action to be performed on an object (Advised to choose “All”).
Applies to: This lets you choose what object specifically to apply the policy to.

Basic Permissions: Now choose the permissions you would like to audit and finally click “OK.

The events you truly need:

Enabling object access logs will start generating many events. Some are more useful than others for our goal to audit for security anomalies. Here is a list of the events you should look for:

4656 – A handle to a Registry key or Registry Value was requested, or a handle to an object was requested.
4657 – A registry value was modified.
4658 – The handle to an object was closed.
4660 – A registry key or value was deleted or removed / An object was deleted.
4663 – An attempt was made to access a Registry key or Registry Value / An attempt was made to access an object.

File access event flow:

Whatever the action that gets performed on an audited file or directory, it triggers a chain of events. This is the order of the events that we are after in that chain:

A handle to an object was requested (4656) – This event initiates the chain of events. It is generated no matter what action was attempted on a file, who is asking for what file of directory and what are the permissions they are requesting.
An attempt was made to access an object (4663) – This is the follow-up event that tells us what operations were performed on the file.
The handle to an object was closed (4658) – This is the closing event, mainly there for timing reasons to tell us how much time it took to perform the action.
An object was deleted (4660) – This is a unique event that will be generated only if the file was deleted. There is also a similar event for events where locked files are requested to be deleted at reboot (4659)

Registry object access event flow:

Similar to the file access events, any registry object access will generate a chain of events, almost identical to the file access event:

A handle to a Registry key or Registry Value was requested (4656) – This event initiates the chain of events similar to the file access chain. It also provides information like what registry object was accessed, by whom, and with what permissions.
A registry value was modified (4657) – This event shows the modification made to the registry key, by who (or by what process), and the new/old values of the key.
An attempt was made to access a Registry key or Registry (4663) – Also an event that shows the changes in a registry object, mainly showing if the registry value was created, modified or just accessed.
The handle to an object was closed (4658) – Same as the event in file access, it indicates an end to the action performed.
A registry key or value was deleted or removed (4660) – Similar to “An object was deleted”. This event is created when a registry object is deleted.