Windows auditing capabilities came a long way especially with the release of Windows 7 and Windows Server 2008 followed by Windows Server 2012 and Windows 8 that all share the same architecture. So what does it take to set up file access auditing in Windows based environments today? What classes of file system activity would you be able to track using native tools? As folks from Microsoft admit themselves setting up Windows file access auditing should be done with a great degree of caution and it does come with some caveats. Let’s take a deeper look.
Advanced audit policies are your friend
When it comes to auditing something as voluminous as file and folder access events are you should be really picky and deliberate defining what gets audited and where. Windows gives you two levels of control: Audit Policies and SACLs. One works in conjunction with the other and unless you set up both nothing will get audited.
Audit Policy is a part of Group Policy that defines what types of audit events will be generated on computers the policy is applied to. Windows Server 2008 offers a more flexible way of configuring audit policy known as “advanced audit policy“. For each audit category it provides a set of subcategories that more accurately define types of audited events. In our case we only need to turn on the “Audit File System” subcategory within the “Object Access” category and make sure that both successful and failed access attempts will be captured.
Since Audit Policy is a part of GPO same rules apply to determine and enforce the resulting auditing configuration on the target computers. A good way to check that the required audit policy is in effect on the particular computer is by running the following command line:
auditpol /get /category:*
Caveat #1. Advanced auditing policies can be overridden by the generic audit policies (pre Windows 2008 legacy). To ensure that granular auditing policies will dominate do not forget to enable the Security Option “Audit: Force audit policy subcategory settings..” in the same GPO where granular audit policies are defined:
Setting up auditing on a folder
Now it is time to talk about SACLs.
System Access Control List is a part of every file’s or folder’s security descriptor used to determine what operations or access types on that file or folder will get audited.
Standard file management tools like Windows Explorer allow choosing a combination of more then a dozen of access types. Each access type can be turned on for auditing of successful and failed access attempts: Allow and Deny columns. The resulting selection of access types really depends on how much you want to know about the audited files and folders. Do you want to track only file modifications or you want to know about file reads as well?
It is important to remember that SACLs are applied throughout the folder hierarchy. You have an option to apply the same auditing configuration to the specified folder only, to the folder and its immediate child objects or to all subordinate files and folders. The last option is convenient and dangerous at the same time. One SACL improperly set on the volume root folder can create a flood of unnecessary events nobody would dare to keep up with.
Of course, the more files and folders and access types you choose to track the more events will be written to the event log.
Caveat #2. Set SACLs on the deepest level of folder hierarchy possible. Avoid selecting “read access” in SACL unless absolutely necessary and on certain files only. Below is an example of the recommended SACL configuration.
What actually gets audited in the Security log
Security log events that contain the “meat of the file access” are known as eventID 4663. As it will become apparent in the examples below these events represent access types that were requested by the application with regards to the particular file or folder. However it does not always mean that all those “access types” have actually been used or even some of them have been used at all on that occasion.
For example, you might get two identical 4663 events whereas only one file operation has been actually performed. Or you might get events that reveal the object of the operation and yet do not specify what exactly has been done to that object.
Caveat #3. File access auditing events in the Security log are only as good as the application used to execute that access. Events show what types of access the application requested for a given file, not necessarily operations that were executed on that file.
Inspecting file access events in Event Viewer
Now let’s take a look at the actual events that get written to the Security log when files and folders are accessed. As was said before, the main event to look for is 4663 that reads “An attempt was made to access an object”. Here is how the event looks like for different types of file access.
What characterizes this event as file deletion is the Access Request Information displayed in the bottom of its text. It clearly says “DELETE”.
Among other things this events shows the following crucial data:
1. The user account that initiated file deletion as reflected in the Security ID field of the event. As an alternative you can use the combination made of the Account Domain and Account Name fields.
2. The full path to the file that was deleted – Object Name. Note, that this is a local path on the computer.
3. The name of the process or application that conducted the file deletion on the user’s behalf – Process Name.
Caveat #4. Even though the file deletion event itself contains most of the information you’d expect to find there is one little issue with it. Each object deletion results in two identical 4663 events following one another. This “glitch” only confirms that it tracks requested access on a file system object as opposed to executed access. After all how can you delete the same file twice?
The only part that looks different from File Deletion is the type of requested access. For file modifications it reads WriteData (or AddFile). You can make an intelligent guess that the same event is used to audit access to folders thus it lists both WriteData and AddFile as one of the two possible access types depending on the type of the file system object it applies to (file or folder respectively).
File Permission Change
When you change permissions on a file you will see a familiar 4663 with Access Request showing WRITE_DAC. This is good but how do you know what exactly was changed in the file permissions?
This is where another event 4670 comes in handy. It goes right after 4663 and gives additional details in the Permissions Change section. In particular, it shows the contents of the file security descriptor reflecting both its old and new state.
Caveat #5. File Permission Change events reveal the old and new value of the security descriptor in the cryptic SDDL format which is hard to make sense of. Chances are you will need external tools to decode the security descriptor and break in down into particular permissions (ACEs) that got added or removed from a file.
If you create a new file in Windows explorer (let’s name the file “created.txt”) and go look for a single event that would capture this in the Security log you won’t find one. Instead you will get a bunch of seemingly unrelated and somewhat confusing events.
First goes a familiar 4663 reflecting an attempt to write to the folder and thus showing Access Request as WriteData (or Add File). That makes sense.
Next you will uncover another 4663 requesting Delete access on the default file name that is given by explorer to all newly created files (New Text Document.txt in this case). That kinda makes sense too..
Now, where is an event that would show the resulting name of the file that got created (e.g. “created.txt”)?
Caveat #6. File Creation is a complex operation that is comprised of a few simpler functions: adding a new entry in the directory, setting the default name to a file and then changing the file name to what was specified by user. Not all of these functions are captured in the Security log and this makes tracking file creations practically impossible.
It might strike to know that from the file system perspective file rename is no different from file creation. As such it results in the same sequence of events that we’ve just observed. And most definitely it inherits the same disadvantages.
Caveat #7. It is impossible to track file renames based on Security log events. There is no way to determine what the file name was changed to.
From the access auditing perspective folders are similar to files. The same 4663 events will show up every time you create and delete folders or change permissions on them. Strangely as it may seem but the Object Type will still say “File” in those events which makes them harder to distinguish from file related events. This is a minor inconvenience compared to another “feature” of folder access events.
Folders are containers made of files. As such every time you delete a folder or modify its permissions behind the scenes the file system actually traverses a list of its subfolders and files and performs the requested operation on them first. Subfolders in turn initiate the same procedure on their own child objects and so on. Sure enough every deletion of a child object generates its own 4663 event and thus one simple folder deletion can result in hundreds if not thousands of events in the Security log.
Caveat #8. Folder deletions and folder permission changes result in a flurry of events witnessing the same operation on each of its subordinate files and folders.
What else is missing in the Security log
So, the 4663 event will make known Who (User Name) requested what Type of Access (Requested Access Information), on what Object (File Path) and through what Application (Process Name).
What this event never mentions is where this access request came from. This can be as crucial as other pieces of a puzzle especially if we are going to audit any descent file server whose shares can be accessed from anywhere on the network.
Caveat #9: None of the file or folder access events in the Security log captures the IP address or name of the computer where the access request came from.
Finally, let’s think for a second what it would take to implement file access auditing strategy on the scale of any serious corporate network. Would it be possible to build say a PowerShell script that would query Security logs across all of the file servers and pull 4663 events so that you could analyze and build reports with file access of a given user or on a given server?
Well, it brings up the same issues that were discussed in the previous post on user logon auditing. Here is just a couple of those for a quick recap:
- File access events that have been previously read from the Security log would have to be saved in some centralized location. Otherwise your would have to analyze audit data collected from each file server one by one before you can be sure that you know all about file activity of a particular user.
- Security log has a fixed size limit and it gets rewritten every time when that limit is reached. In order to not lose any events the script would have to be invoked often enough but not too often to avoid putting too much overhead on your file servers.
Caveat #10: If you seriously consider a file auditing strategy then look for a third party solution that can address the limitations of the Security log events and automate collecting, storing and reporting of file system access events.
Speaking of third party solutions, the authors of this post have one for you. 🙂
SecureHero File System Auditor reliably addresses most of the caveats that were brought up here. Try it yourself by downloading a free trial!