Windows File Activity Monitoring

Note: This blog is the second in a 4 part series, followed by a webinar to review all the challenges with File System access auditing. Sign up now for the webinar “Challenges with Relying on Native File System Logging“. Register now.

In our first post of the series, we discussed some of the challenges with native file system access auditing techniques, from the configuration all the way to one’s ability to easily understand the resultant data. In this post, we will dive into how to configure file access auditing on a Windows File Server, and will take a closer look into the challenges with interpreting critical access events.  

Before We Start…

As with any effective audit strategy, a good understanding of your use cases and business needs are a must to avoid the possible system impact caused by “over auditing”, configuring a wider audit scope than is actually needed.  The more audit policy settings chosen and the more files and folders audited, the more work the file server has to do to log the events, the more storage is required to accommodate the volume of events, and the more difficult it is for the admin to parse through the volume of data to understand who is accessing what.

Before enabling an audit policy, make sure to:

• Understand where your organization’s most critical data exists in order to prioritize which files and folders need to be audited
• Determine the amount of storage that will be required to accommodate the chosen audit settings

Configuring File Access Auditing on a Windows File Server

The audit policy can be enabled through Group Policy from the domain level, or via Local Security Policy in the case of a single file server. For the purpose of this blog post, we will enable an advanced audit policy through Group Policy on a Domain Controller running Windows Server 2016 R2

1) Create a new Group Policy Object through Group Policy Management and provide a suitable name

2) Right Click the newly created GPO which will launch the Group Policy Management Editor window

Advanced Audit Policy Configurations, first introduced in Windows Vista, allow administrators to be more selective in the types and number of events to be returned than they would be able to with the basic audit policy settings. For the case of auditing file access, the basic audit policy provides a single setting for “object access”, while the advanced policy provides 14 sub categories.

For our use case, we will need to enable the following sub categories:

• Audit File System
• Audit Handle Manipulation

While “Audit File System” allows you to audit user attempts to access file system objects, without configuring “Audit Handle Manipulation, you will not have full visibility into failed access attempts.

3) Navigate to Computer Configuration –> Windows Settings –> Advanced Audit Policy Configuration –> Audit Policies –> Object Access

4) Double click “Audit File System” and select “Configure the following audit events”, “Success”, and “Failure”

5) Click “Apply” and “OK”.

6) Double click “Audit Handle Manipulation” and select “Configure the following audit events”, “Success”, and “Failure”

7) Click “Apply” and “OK”.

8) In “Group Policy Management”, link the newly created GPO with the OU containing your file servers by right-clicking the OU and selecting “Link an existing GPO…”, followed by “Group Policy Update”

9) Navigate to the properties of the Security log on the target Windows File Server to configure the “Maximum log size ( KB )”  and event handling setting in the case the event log size is reached

10) Configure the SACL by navigating to the security tab of the target folders’ properties, clicking advanced, navigating to the Auditing tab, and clicking Add

Assuming these folders contain your organization’s most critical assets, you most likely want to monitor access events from all users. For the purpose of this blog, we will monitor all access attempts by all users through the “Everyone” group.

Challenges with Interpreting Critical Access Events

Now that we’ve configured the Advanced Audit Policy and the SACL, we can dive into the log entries returned for some of the most common, and even critical, access event scenarios

Noise Events with File Access

The largest challenge once auditing is enabled is to effectively manage and consume the data that is produced. For example, let’s examine the following scenario:

1. A user opens a Microsoft Word document on a file share
2. The user edits the document
3. The user saves and closes the document

These common actions would ultimately result in over 200 events being written to the event log, an unwieldy amount of data for any person to sift through for a single access attempt. Consider the amount of times this sequence of events will occur during standard working hours and how much harder the task of monitoring file access becomes!

Temporary Files

Let’s take a deeper look into the scenario illustrated above where a user opens a Microsoft Word document, edits it, and then saves and closes it. The table below describes some of the events that will be returned.

Event ID	Description	Details
4663	An attempt was made to access an object	This event identifies operations performed against a file or folder such as ReadData, WriteData, or Delete.
4656	A handle to an object was requested	This is the first event recorded when attempting to access a file and includes the type of access that is being requested.
4658	The handle to an object was closed	This identifies when a handle to an object was closed and is useful in determining how long a file was opened.
4660	An object was deleted	This will identify when an object was deleted, but in order to find which object, you must relate this to a corresponding 4656 event.
4670	Permissions on an object were changed	This shows when permissions to a file or folder were changed and the before/after values using Security Descriptor Definition Language (SDDL).

Table 2: Event IDs returned when a user opens, edits, saves, and closes a Microsoft Word Document

We know that we will get 39 events with Event ID 4663, which can be a very useful event to help understand how users interact with Office documents. However, in this case, nearly half of these events are logged against files that don’t actually exist – temporary files.

Microsoft Office leverages temporary files in order to automatically save data during editing, free up memory, and prevent data loss. While this ultimately provides the end user with a better experience, the admin tasked with managing the audit trail is provided a huge headache.  Now, in order to make sense of what objects are being accessed, the admin has to not only correlate several different Event IDs together, but has to also sift through and discard the events related to these temporary files.

Permission Changes

A good example of an important, but difficult to understand event is event 4670 which identifies when a permission changes on a file or folder. These events are integral to monitor changes that can put sensitive data at risk, such as adding a folder permission for the Domain Users group.

In the case of a Windows File Server, the event that is logged has a lot of useful information including:

• The person performing the permission change
• The permissions before and after the change, represented using the Security Descriptor Definition Language (SDDL)

There are several things that make this event difficult to work with

• The Security descriptor needs to be translated from SDDL to something human readable
• Once translated, the security descriptors have to be compared to actually identify the changed permission
• Without visibility into Active Directory, you will not know the principals’ whose permissions have changed – you will only have their SID

Moves

The ability to monitor the movement of files from one location to another can be critical in scenarios where a user’s documents are missing and need to be found. Unfortunately, relying on native event logs for this information can be tricky and require some manual efforts. Regardless of how a file is moved, whether it is a drag-and-drop or cut-and-paste, several events will be generated as a result of this action, many of which are 4663 events. In order to actually understand where a file is moved, it is necessary to correlate 4663 events that have a matching Handle ID.  

Several additional 4663 events will be created as a result of the move, requiring additional manual filtering to exclude these noise events.

As we’ve explored through this blog post, Microsoft event logs do not provide a viable way to answer basic questions around who has accessed, moved, or changed your files. Turning file access auditing on provides an unmanageable amount of data which is ultimately meaningless without manual efforts.

In our next blog post, we will dive into configuring file access auditing on a NetApp CMode File System leveraging native OnTap functionality and will explore some of these unilateral challenges, highlighting the areas where NetApp deviates from Windows.

In the meantime, click here to learn more about the STEALTHbits Activity Monitor!