Security, et al

Randy's Blog on Infosec and Other Stuff

«  In search of great techno... | Pay Attention to System S... »

Auditing File Shares with the Windows Security Log

Thu, 02 Jan 2014 15:22:25 GMT

This article was first published in EventTracker’s EventSource Newsletter:http://www.eventtracker.com/newsletters/auditing-file-shares-windows-security-log/#open

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

  • File Share

  • Detailed File Share

File Share Events

The good news is that 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 3 operations.  The events indicate who made the change in the Subject fields and provides the name of 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 the subcategory also produces event ID 5140 each and every time a user connects to a share.  The data logged, which includes 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 a lot if you enable “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 itself and the actual file accessed via the share (Share Information) and then provides the permissions requested and the results of the access request.  As you can see this event actually logs the access attempt and therefore you will see failure versions of the event as well as success events. 

But be careful about enabling this audit subcategory because you will get an event for each and every file accessed through network shares – every time the application opens the file.  That can be much more frequent than you’d imagine 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. 

Instead you might 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 I suggest enabling the File Share subcategory if it’s important to you to know when new folders are shared.  But you will probably want to filter out all those occurrences of 5140.  Then if you have file level audit needs, turn on the File Access subcategory, identify the exact folders containing the relevant files and then enable auditing on those folders for the specific operations (e.g. Read, Write, Delete) necessary 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.

email this digg reddit dzone
comments (0)references (0)

Related:
Auditing Privileged Operations and Mailbox Access in Office 365 Exchange Online
5 Indicators of Endpoint Evil
Understanding the Difference between “Account Logon” and “Logon/Logoff” Events in the Windows Security Log
Severing the Horizontal Kill Chain: The Role of Micro-Segmentation in Your Virtualization Infrastructure

Comments disabled

powered by Bloget™

Search


Categories
Recent Blogs
Archive


 

Additional Resources