Audit File Access and Change in Windows

One of the bigger problems that we come across is auditing of file systems – specifically, you want to know who read, modified, deleted or created files in a shared area. This is not an unreasonable task, but it is different in every single operating system. Windows has built-in facilities for doing this. We just need to do a few things to get the information into Splunk.

• Object Access Auditing needs to be turned on
• The Shared Folder needs to have auditing enabled
• You need to collect and interpret events from the system

To turn on object access auditing, you need to alter the local security policy. This can be done centrally via a group policy object or it can be done on the local machine. You may even have this turned on already. To turn on object access audit using the local security policy, following this process:

1. Open up Administrative Tools -> Local Security Policy, or run secpol.msc
2. Open Local Policies -> Audit Policy
3. Right-click on “Object Access Audit” and select Properties
4. Ensure “Success” and “Failure” are both checked
5. Click on OK, then close the Local Security Policy window.

You can do a similar thing in group policy – create a new group policy object, edit it, open Computer Configuration and find the Local Security Policy, then adjust as described above, save it and then apply it to some machines in the normal manner. Once it is distributed (which happens roughly every 4 hours by default), your selected systems will have audit forced on.

The next piece is to turn on auditing for a specific folder (and all its sub-folders and files). You normally do this for only a select few places and users, since the information generated is very chatty. For each folder, following this process:

1. Open up the File Explorer by right-clicking and selecting Run As Administrator.
2. Browse to the folder you want to turn auditing on.
3. Right-click on the folder and select Properties.
4. Select the Security Tab.
5. Click on Advanced, then Auditing.
6. Click on Add
7. Enter the name of the users you wish auditing (Everyone is usually a good choice!), click on Find Now to ensure it is registered, then click on OK
8. Check the Successful and Failed boxes, then click on OK
9. Close the windows by clicking OK

Remember that the exact process changes slightly between versions of Windows Server, so be aware that the exact paths may be slightly modified, but they will be called the same thing.

You should be able to see audit information in your Security event log. The final step is to make that information appear in a Splunk instance. I generally install the Splunk Universal Forwarder on the host and deploy the Splunk_TA_windows to the host. This is an essential add-on that collects the Windows Security Event Log by default for you.

Once you are gathering the data, you will see four distinct event codes produces. On NT5 systems (Windows Server 2003 and prior), event codes 560 (open object) and 562 (close object) are produced. On NT6 systems (Windows Server 2008 and later), codes 4656 (open object) and 4658 (close object) are created. Here is an example of Event Code 4656

A handle to an object was requested.
Subject:
   Security ID:  SHELL\ahall
   Account Name:  ahall
   Account Domain:  SHELL
   Logon ID:  0x1ff76
Object:
   Object Server:  Security
   Object Type:  File
   Object Name:  C:\Finance\Accounts.xlsx
   Handle ID:  0x994678
Process Information:
   Process ID:  0xff1
   Process Name:  C:\Program Files\Microsoft Office\Office15\EXCEL.EXE
Access Request Information:
   Transaction ID:  {00000000-0000-0000-0000-000000000000}
   Accesses:  READ_CONTROL
     SYNCHRONIZE
     ReadData 
     ReadEA
     ReadAttributes   
   Access Mask:  0x120089
   Privileges Used for Access Check: -
   Restricted SID Count: 0

You can see the person who is accessing the resource, the resource itself and the program used to access the resource are all available. In addition, the Logon ID is available. If you have Account Logon Audit turned on, then a logon EventCode (528, 540, 4624) will have been logged from the same machine with the same Logon ID. In addition, you can see how long the file was opened by looking for a corresponding close from the same host with the same Handle ID.

On my search head, I have defined a new event type called “windows-fileaudit” – this is defined in eventtypes.conf, but you can also define it in the Manager. Add this to your eventtypes.conf:

[windows-fileaudit]
search = sourcetype=WinEventLog:Security (EventCode=560 OR EventCode=562 OR EventCode=4656 OR EventCode=4658)

As an example, let’s find all the accesses to the C:\Finance area on host FINANCE, who opened the files and how long they had them open for.

eventtype=windows-fileaudit host=FINANCE Object_Type=”File” Object_Name=”C:\\Finance\\*” | eval CodeType=if(EventCode=560 OR EventCode=4656,”Open”,”Close”) | transaction startswith=CodeType=Open endswith=CodeType=Close host Handle_ID | table _time Security_ID Object_Name Process_Name duration

One word of warning in closing. The object access audit security log events are extremely chatty, so you may want to look at methods of controlling what gets indexed, and perhaps set up a small free version of Splunk to allow you to discover how much data will be logged before moving the data over to your main Splunk index.

Related posts:

• Detecting Early Signs of Compromise by Splunking Windows Sysinternal
• Monitoring Local Administrators on Windows Hosts
• Monitoring Processes on Windows