Auditing File Shares with the Windows Security Log

EventTracker November Newsletter
By Randy Franklin Smith

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.

A network share object was added.

Subject:
Security ID:  W8R2\wsmith
Account Name:  wsmith
Account Domain:  W8R2
Logon ID:  0x475b7

Share Information:
Share Name:  \\*\AcmeAccounting
Share Path:  C:\AcmeAccounting

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 log management solution like EventTracker, which can be configured to filter 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.

A network share object was checked to see whether client can be granted desired access.

Subject:
Security ID:  SYSTEM
Account Name:  WIN-KOSWZXC03L0$
Account Domain:  W8R2
Logon ID:  0x86d584

Network Information:
Object Type:  File
Source Address:  fe80::507a:5bf7:2a72:c046
Source Port:  55490

Share Information:
Share Name:  \\*\SYSVOL
Share Path:  \??\C:\Windows\SYSVOL\sysvol
Relative Target Name: w8r2.com\Policies\{6AC1786C-016F-11D2-945F-00C04fB984F9}\Machine\Microsoft\Windows NT\Audit\audit.csv

Access Request Information:
Access Mask:  0x120089
Accesses:  READ_CONTROL
SYNCHRONIZE
ReadData (or ListDirectory)
ReadEA
ReadAttributes

Access Check Results:
READ_CONTROL: Granted by Ownership
SYNCHRONIZE: Granted by D:(A;;0x1200a9;;;WD)
ReadData (or ListDirectory): Granted by D:(A;;0x1200a9;;;WD)
ReadEA: Granted by D:(A;;0x1200a9;;;WD)
ReadAttributes: Granted by D:(A;;0x1200a9;;;WD)

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:\docs\file.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.