How to audit sensitive file changes using out of the box Windows Tools

Defending critical assets

In the wake the of the British Airways breach I thought I would shed some light on a technique to help detect and alert (help respond) to events that may affect critical business processes by modifying critical or sensitive files. We are going to start with a simple scenario using out of the box tools.

Auditing Critical Files

Windows Server comes with a number of security features including object access auditing, in this post we are going to take a brief look at enabling monitoring of sensitive data files. The example we are going to use are monitoring for changed to the web.config file used my .net web applications.

To start with in our example machine, we are going to need to enable audit object access either using local policy or preferably group policy (it should be noted you need to think about log volume, collection and retention/rotation).

Once this is enabled we now need to configure auditing on the relevant file or folder. In this example we are going to look at the web.config file located in c:\inetpub\wwwroot

Using file explorer we navigate to the file in question, right click and select properties. Once in properties, select the security tab:

Click ADVANCED

Then click on the Auditing tab:

Click continue:

Then click Add

Click select a principal, for this demo we will use the EVERYONE principal.

Since this file will often be read by the IIS processes we will audit only writes:. Click OK then OK.

We are now going to edit this file in notepad++.

Using the Windows Event viewer we can filter the log as follows:

This will show only file system object access auditing as below:

Now the problem with just auditing the write permission is that a delete will not be logged.

We can see here in the security event log that the modify if logged. Next, we are going to delete the file. As you can see below the event is logged.

Ok so, apologies for the mass of screenshots but I figured it’s good to show the steps required to not only configure, but also test the functionality (testing a control is just as important as configuring one in the first place!).

Breadcrumbs

So now we have an audit trail, but what we don’t have is an alerting system. Now there are a ton of tools on the marketplace but since this is more about function over form (and catering for all kind of potential budgets and constraints) I figured we’d go for out of the box tools only (If you need some help with tool selection you know who to call!). Ok so, what can we do to alert on our workgroup web server? Have no fear, as long as we aren’t operating in the stone ages (i.e. < Windows 7/Server 2012) we can use task scheduler feature.

So, fire up task scheduler and click on Event Viewer Tasks and Click Create Task:

Now we need to configure the task properties:

We are going configure this to run as SYSTEM (in the real world we would likely use a service account). Once the general page is configured we need to configure some triggers, so click on Triggers, then click New Trigger:

Select on an event and custom:

Click New Event Filter:

Now we are going to select paramers such as the following (you may want to get more creative with XML to get specific events, but for this demo here is a simple config to trigger on any file system audit log in the last hour)

Click OK

And click OK for a final time:

Now click on the Actions tab:

Click New:

Now we have three options:

Start a program
Send an e-mail (deprecated)
Display a message

Now my general advice would be to use the run a program feature to send an email, text or API all a messenger services however we are going to use the program feature to just send a message using msg.exe

There are more options on conditions and settings, however for this demo we are just going to configure the following in settings:

We are going to use the queue event feature:

Right finally after many clicks and a small level of config we have auditing and alerting (all be it very primitive, not the kind of alerting you want for production servers, but good enough for our demo).

On the click of OK we have the following configured:

I now restore the web.config file and we have an alert:

So, there we have it, a simple yet effective way to alert on critical file write events, I would advise using a solution with greater level of capability (even just using some PowerShell to grab the events from the event log and email them would be more effective than this), however no matter what your budget is, the ability to detect and respond to critical file change is included in the operating system. This method is fairly basic, and an advanced attacker could work around this, however it just shows some of the breadth and depth of security features included inside the windows toolkit!

If you are thinking of using the power shell route here’s something to get you started, ideally you would build a better hashtable query, however it depends upon the scope of files you want to monitor etc.

Get-WinEvent -FilterHashtable @{logname=’security’;id=4663} | select -Property * | Select-String -SimpleMatch “web.config”

Don’t worry if you are a running services on UNIX/LINUX etc. you can also achieve the same using AUDITD and some Python/Shell script of a tool like http://entrproject.org/. However, once again using a SIEM solution would likely be a better business option. We’ll be writing some posts in the near future to showcase some solutions which are more suitable for a larger deployment.

Summary

It’s important to not only prevent cyber-attacks but also detect and respond. Today we’ve looked at an out of the box method of detecting a critical file modification event which would enable us to respond. Remember security doesn’t have to break the budget, and as demonstrated here, it helps to know what you are protecting. Hopefully this helps you understand a simple scenario and some of the potential, with additional solutions (ERD/SIEM etc.) you can go to another level to cover the breadth and depth of your business technology assets! Stay safe, stay secure!

In the next post on the detect and protect series we look at using OSSEC to upgrade from out single server out of the box solution to having a central interface, log integrity reporting and alerting: