Auditing File Shares with the Windows Security Log

Over the years, security admins have repeatedly asked me how to audit file shares in Windows.  Until Windows Server 2008, there were no specific events for file shares.  The best we could do was to enable auditing of the registry key where shares are defined.  But in Windows Server 2008 and later, there are two new subcategories for share related events:

• File Share
• Detailed File Share

File Share Events

This subcategory allows you to track the creation, modification and deletion of shared folders (see table below).  You have a different event ID for each of those three operations.  The events indicate who made the change in the Subject fields, and provides the name the share users see when browsing the network and the patch to the file system folder made available by the share.  See the example of event ID 5142 below.

The bad news is that the subcategory also produces event ID 5140 every time a user connects to a share.  The data logged, including who accessed it, and their client IP address is nice, but the event is logged much too frequently.  Since Windows doesn’t keep network logon sessions active if no files are held open, you will tend to see this event frequently if you enable the “File Share” audit subcategory.  There is no way to configure Windows to produce just the share change events and not this access event as well.  Of course, that’s the point of a SIEM and log management platform which is at the heart of Netsurion Open XDR, which filters out the noise.

5140	A network share object was accessed
5142	A network share object was added.
5143	A network share object was modified
5144	A network share object was deleted.

Detailed File Share Events

Event ID 5140, as discussed above, is intended to document each connection to a network share, and as such it does not log the names of the files accessed through that share connection.  The “Detailed File Share” audit subcategory provides this lower level of information with just one event ID – 5145 – which is shown below.

This event tells identifies the user (Subject fields), the user’s IP address (Network Information), the share, and the actual file accessed via the share (Share Information) and then provides the permissions requested and the results of the access request.  This event actually logs the access attempt and allows you to see failure versions of the event as well as success events.

Be careful about enabling this audit subcategory because you will get an event for every file accessed through network shares each time the application opens the file.  This can be more frequent than imagined for some applications like Microsoft Office.  Conversely, remember that this category won’t catch access attempts on the same files if a locally executing application accesses the file via the local patch (e.g. c:docsfile.txt) instead of via a patch.

You might also want to consider enabling auditing on individual folders containing critical files and using the File System subcategory.  This method allows you to be much more selective about who, which files and what types of access are audited.

For most organizations, enable the File Share subcategory if it’s important to you to know when new folders are shared. You will probably want to filter out the 5140 occurrences.  Then, if you have file level audit needs, turn on the File Access subcategory, identify the exact folders containing the relevant files and enable auditing on those folders for the specific operations (e.g. Read, Write, Delete) needed to meet your audit requirements.  Don’t enable the Detailed File Share audit subcategory unless you really want events for every access to every file via network shares.