Complete Guide to Windows File System Auditing - Varonis

Windows file system auditing is an important tool to keep in your cybersecurity forensics toolbox. 

Read on to learn more about file system auditing on Windows, and why you will need an alternative solution to get usable file audit data.

• Reasons to Audit File Systems
• How to Enable File System Auditing
• Windows File System Auditing Scenarios
• Windows File Activity Audit Flow
• Interpreting File System Accesses
• Windows Event Log Limitations
• What to Consider: Scalability
• Varonis Windows File System Auditing

Why is Windows File System Auditing Important?

When you experience a cyberattack – it’s no longer an if – you have to be able to pinpoint exactly what the attacker viewed, changed, or stole. This kind of insight requires a complete file system auditing system. 

File system auditing is a requirement for any modern data security strategy, but file analysis is the better alternative. File analysis processes and normalizes the raw file audit data so you can use the information easier. A comprehensive file analysis log will show you what data an attacker or malicious insider tried or succeeded in accessing and stealing. 

How to Enable Windows File System Auditing

Step 1: Enable Audit Policy

First, go to the Domain Controller (DC) and update the Group Policy (GPO) to enable file auditing. 

Right click on the Group Policy you want to update or create a new GPO for file auditing. In the right-click menu, select edit to go to the Group Policy Editor.

*I created a new GPO called “File Auditing” for the purposes of this example. 

In the Group Policy editor, click through to Computer Configuration -> Policies -> Windows Settings -> Local Policies. Click on Audit Policy.

You can add many auditing options to your Windows Event Log. The option for file auditing is the “Audit object access” option.

Double-click “Audit object access” and set it to both success and failure.

To enable your new GPO, go to a command line and run ‘gpupdate /force’.

Verify that your policy is set correctly with the command ‘gpresult /r’ on the computer that you want to audit.

Step 2: Apply Audit Policy to Files and/or Folders

Next, tell Windows exactly which files and/or folders that you want to audit. Here is the procedure to set auditing up for your folders. 

1. Right-click the file or folder in Windows Explorer. Select Properties.

2. Change to the Security tab and click Advanced.

3. Click the Auditing tab and then Continue.

4. Add the Users or Groups that you want to audit and check all of the appropriate boxes.

Step 3: Open Event Viewer 

Once you have enabled the Auditing GPO and set the file/folder auditing, you will see audit events in the Security Event Log in Windows Event Viewer.

But what does that information mean to an IR team that is trying to figure out what happened during the latest cyberattack? Let’s dig into what these event log messages actually tell us.

Windows File System Auditing Scenarios

Read on to learn more about different auditing situations including who read, edited or deleted a given file.

How to Track Who Read a File on Windows File Server

Finding who opened a file in the Windows audit is straightforward. Simply look for event ID 4663. Every Windows Event Log entry has an event ID, which describes what happened during that event. ID 4663 means that an “Attempt was made to access an object.” You will see a success or failure message as part of the event, the name of the file or object, as well as the user and process that made the access attempt.

In the above screenshot, the itadmin user read the file “test – Copy.txt.”

How to Track Who Changed a with Windows File Auditing

In Windows File Auditing, you don’t know if the file got changed or not. You can tell when a file got opened, and what process opened that file. 

What we can see from this event ID 4663 is that itadmin opened the file “Editing this file.txt” in notepad, and we can assume that this file got changed.

How to Detect Who Deleted a File From Your Windows File Servers

Delete events in the Windows Event Log are event ID 4660. You can see an example of a delete operation here: 

Your first question is probably, “What file got deleted?” To find out, we have to dig into the Event Log to find a corresponding event ID 4663.

Looking at the timestamps of the two events, you can deduce that the file deleted was ‘test- Copy.txt’.

The Windows File Activity Audit Flow

Windows does not log file activity at the high level we expect and need for forensic investigation. Instead, it logs granular file operations that require further processing. 

The diagram below outlines how Windows logs each file operation using multiple event log entries:

The delete operation is a unique case in that there is a fourth event, 4660, mentioned above. The sequence is identified by the “Handle ID” event property, which is unique to this sequence (at least until a reboot).

The event that provides the most information is 4663, identifying that an attempt was made to access an object. However, the name is misleading because Windows only issues the event when the operation is complete. In reality, there might be multiple 4663 events for a single handle, logging smaller operations that make up the overall action. For example, a rename involves a read, delete, and a write operation. Also, a single 4663 event might include multiple values in the “Accesses” property which lists access rights exercised to perform the operation. Those “Accesses” serve as our guideline for the operations themselves. 

The following table provides more information about each event:

When we ask ourselves the question “who touched my files?”, the Windows Audit Log is going to have at least four different event log entries per file read that we need to filter through and correlate before we can make any quality forensic conclusions.

Interpreting File System Accesses

To identify the actual action, decode the exercised permissions as reported in the “Accesses” event property. Unfortunately, this is not a one-to-one mapping. Each file action includes many smaller operations that Windows performs, and those smaller operations are the ones logged.

The more important “Accesses” property values are:

• “WriteData” implies that a file was created or modified unless deleted
• “ReadData” is logged as part of practically any action. It implies “Access” if no “Delete” or “WriteData” is logged for the same handle and for the same file name around the same time.
• “Delete” may signify many things: delete, rename (same folder), move (to a different folder) or recycled, which is essentially a move to the recycle bin. Event 4660 with the same handle differentiate between delete or recycled for which a 4660 event is issued and a rename or move for which it is not.

Consider this only as a starting point. The analysis above is extremely simplified, and real-world implementation will require more research. Some areas for further research are:

• Differentiating delete from send to recycling bin and move from rename.
• Analyzing attributes access (with or without other access operations).
• Handling event 4659, which is similar to 4660 but is logged on a request to delete a locked file on the next reboot rather than deleting them now.
• Researching reports that events come out of order and the “request handle event” (4656) may not be the first in the sequence.

You may want to review this PowerShell Script which reads Windows events and generates from them meaningful file activity report to get a somewhat less simplified analysis. 

Pro tip:  Varonis has been auditing Windows file servers at petabyte scale for over a decade, with numerous patents related to normalization and analysis. Give it a try to save yourself time figuring out how to parse raw logs.

Windows Event Log Limitations for File System Auditing

While the Windows file activity events seem comprehensive, there are things that cannot be determined using only the event log. A few examples are:

• Create vs. modify: the only way to know if this is a new file or a modified file is to know the prior state, i.e., whether the file existed before.
• Missing information on failures: For cybersecurity, it can be important to know when someone failed to access a file. Windows file auditing only writes a single event ID 4656 for failures to access due to permissions. 
• Cut & paste: while one would assume “cut and paste” would be similar to a move operation, in practice, the behavior seems to be similar to a delete operation followed by a create operation with no relations whatsoever between the two operations.

Consider Scalability When Collecting Windows File Activity

If you are going to use the native Windows file auditing, you need to be aware of how much data you are going to collect. Collecting Windows file activity is a massive event flow and the Microsoft event structure, generating many events for a single file action, does not help. Such a collection will require more network bandwidth to transfer events and more storage to keep them. Furthermore, the sophisticated logic required may need a powerful processing unit and a lot of memory.

To reduce the overhead, you may want to:

• Carefully select which files you monitor based on the scenario you plan to implement. For example, you may want to track only system files or shares that include sensitive data.
• Limit collection of unneeded events at the source. If your collection infrastructure uses Microsoft Event Forwarding, you can build sophisticated filters based on event IDs and event properties. In our case, filter only events 4656, 4660, 4663 and optionally 4658 and only for the “Accesses” values needed.
• Limit event storage and event sizes as raw Windows events are sizable.

Windows File System Auditing With Varonis

Varonis records file activity with minimal server and network overhead – enabling better data protection, threat detection, and forensics. An alternative approach for implementing this important security and compliance measure is to use a lightweight agent on each monitored Windows system with a focus on file servers.

Varonis processes Windows file activity and translates those events into audit data that you can actually use and understand, and can handle many millions of events per hour on the largest file servers. 

Keep in mind that each one of those events in the native Windows auditing would be at least four entries, and all mixed in with all of the other logon and ticket authorization events in the Security Event Log. With Varonis, you can easily filter your search in Event Viewer by user, file server, or folder path.

From a data protection perspective, Windows file auditing isn’t fast enough to audit a significant incident like a ransomware attack. You can’t immediately open the Windows Event Log and see every file or folder the ransomware attacked. Each moment you waste trying to discover which accounts triggered the ransomware, more files might get encrypted. 

Varonis does that file event correlation for you so you can quickly filter and view the files and folders affected by the ransomware. You can export a report of the ransomware incident so you can begin the cleanup and recovery process immediately. Varonis can even trigger an immediate response to a suspected ransomware attack to disable the attack in progress.

Check out the Live Cyber Attack Workshop to see how Varonis turns basic file auditing into intelligent alerts that you can use in real life situations.