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.
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.