How to audit File / Directory delete Operations on a Windows System using security auditing

How to audit File / Directory delete Operations on a Windows System using security auditing.

Article created 2007-12-12 by Andre Lorbach.

This article will guide you in how to setup Windows and MonitorWare Agent to track file and directory deletion processes. It is also possible to use EventReporter instead of MonitorWare Agent, however this article will target the more powerful MonitorWare Agent. The guide works both on Workstation and Server versions of Windows.

You can download a preconfigured configuration from here, which you can import on your target system. The configuration sample will have comments for better understanding. The MonitorWare Agent Client can import the XML/REG configuration file by using the “Computer Menu”.

A typical scenario of a small to middle sized company. The employees access a file server and store their documents on it. Suddenly an important document is missing. Who deleted it? And more important when was the file deleted? Oh two months ago? To bad our backups don’t go that far, the document is gone forever … ! Wouldn’t it be great to know if a file is deleted, when it was deleted and also who did delete the file? Maybe it was the revenge of an employee who got fired a few weeks ago?

Using Windows Security Auditing and the EventLog Monitor of MonitorWare Agent, you can set up an environment where you exactly know if a file is deleted, when it is deleted and by whom it is deleted.

1. Windows Settings
1.1 Turn on Security Auditing
1.2 Add Auditing to the folders / drives you want to monitor
1.3 Configure Windows Security EventLog Size
1.4 Testing File Deletion
2. Configuring MonitorWare Agent
2.1 Download and Install MonitorWare Agent
2.2 Setup Basics in MonitorWare Agent
2.3 Use File Logging to store File Deletion
2.4 Create an Email alert

1. Windows Settings

1.1 Turn on Security Auditing

Our first step is to enable “Audit Object access” in the Audit Policy. If your machine is a Workstation like Windows XP / Vista, open the “Local Security Settings” from the “Control Panel->Administrative Tools”. If you want to enable security auditing for the whole domain, or only domain controllers, open the “Domain Security Policy” or “Domain Controller Security Policy” from the “Administrative Tools”. In this article, we will use the “Local Security Settings” on a Windows XP machine.

Enable the “Audit object access” policy here. This will also enable object logging we do not need, but the filters in MonitorWare Agent will deal with these events later.

1.2 Add Auditing to the folders / drives you want to monitor

Now we can configure the Security properties for the drives or directories we want to monitor for file / directory deletions. In order to do so, right click the object you want to monitor and click on properties. In our sample, we will use the whole drive C:\. Once you switched to the security tab, click on the “advanced” button.

This will open advanced configuration options, switch to the “Auditing” tab and click on the “Add” button. Select “Successful” for the “Delete” and “Delete Subfolder and Files“, and also for “Failed” if you want to monitor failed deletion attempts as well. Once you have done this and confirm your changes by clicking on “Apply“, it may take a while until the system begins to record audit records. Good time to get a cup of coffee.

If you want to monitor other file operations, go ahead and activate them. However you will need to enhance the filter rules for MonitorWare Agent later by yourself.

1.3 Configure Windows Security Event Log Size

The System defaults are different from Windows to Windows Version. We need to make sure that event logging is continuous, otherwise the event log will fill up at some time, and no events can be written into it anymore. In our example, we will use 16MB of Maximum log size (Can be up to 256MB) and “Overwrite events as needed“.

1.4 Testing File Deletion

For this sample, we created a folder called “sharing” on the drive C:\ and shared it as a network folder. Then we added a file called document.doc into this folder, and deleted it. All done over the network share.

Then we open the Computer Management Console, and take a look into the Windows Security EventLog. You will see that a bunch of events is being generated for each file we delete. The Event which is interesting for us is the first Event with ID 560. We will filter this event by certain parameters later using MonitorWare Agent. This event contains all information’s we need to determine which file was deleted, when it was deleted and by whom.

2. Configuring MonitorWare Agent

2.1 Download and Install MonitorWare Agent

So if you haven’t done so already, go to www.mwagent.com and download the latest MonitorWare Agent Version. It is always recommended to use the latest Version of MonitorWare Agent. Once the Download is done, go ahead and install it. You may have to restart after installation, this depends on your System.

2.2 Setup Basics in MonitorWare Agent

Start the MonitorWare Agent Client and skip the wizard on startup. First we create new “Event Log Monitor” Service. Uncheck all event log types and only select “Security“, as this is the only event log needed to achieve our goal. Then save the settings.

Now we need to create some basic rules and filter to preprocess the event log entries. The first rule we create is called “DiscardProcessing” and will discard events if certain filters match. We only want to process Events with ID 560. Then there is the Param14 property which will contain “Accesses” masks from the event entry. The event log message will show DELETE, Read_Control and so on, but the parameters actually are RAW which means we have to deal with numbers.

Here is the list for the most common access mask numbers and their meaning:
1537 = Delete
1538 = Read_CONTROL
1541 = synchronize
4416 = ReadData(or List Directory)
4417 = WriteData(or Add File)
4418 = AppendData (or AddSubdirectory or CreatePipeInstance)
4419 = ReadEA
4420 = WriteEA
4423 = ReadAttributes
4424 = WriteAttributes

While examining the event log I noticed that there are multiple Events generated with ID 560 for each file deletion. The first is also generated if you rename a file and contains the mask “SYNCHRONIZE”. We do not want to process these events, so we add a filter to avoid these. The third filter we add will contain the Access Mask we want to process, in our example here this will be “%%1537” which is DELETE.

Do not forget to add a “Discard” action into this rule.

A few more rules are needed in order to post process the username and domain of the user who deleted the file. If a user deletes a file on the local system, Param8 and Param9 will hold the username and domain which we need to log. If a user deletes a file on a remote system, Param11 and Param12 is important to us.

So the first rule and its actions will initialize the properties del_username and del_domain with Param8 and Param9. Please import the configuration sample to see the actions in detail.

The other two rules will be used to check if Param11 and Param 12 are empty, so not set with a useful value. If they contain any useful information, we will overwrite the del_username / del_domain property with these Params. Using this method, we can be sure to always know exactly who deleted the file.

2.3 Use File Logging to store File Deletion

The most common way to store logged operations like this is to use write a logfile. So lets create a new “Write to file” Action. Set a file path and base name of your choice, and switch the file format to “Custom”. As you can see, you can now define your own line format. In our example, I have chosen a rather simple file format, where the values are separated by comma. So you might load them into Excel later, or another other application which can load csv files.

Use the following custom line format:
%timegenerated%, %Param2%, %del_domain%\%del_username%%$CRLF%

So you will see the time the file was deleted, the deleted file (which is %Param2%) and the username and domain name. Feel free to customize the line format to your needs.

2.4 Create an Email alert

You might want to be alerted by email. But be warned, I recommend to reduce the folders and location you monitor for file deletions. Otherwise you will receive many unwanted emails. It is also possible to add custom filters to avoid emails for certain paths and filenames. Kindly filter the %Param2% property in this case.

In order to receive email alerts, create a new rule and add a new “Forward via Email” action.

Use the following subject format:
File ‘%Param2%’ deleted on Server ‘%source%’

Use the following message format:
TThe file ‘%Param2%’ was deleted on server ‘%source%’ Time:%timegenerated% Username: %del_username% Domain: %del_domain% Complete Eventmessage: %msg%

Final Thoughts

I hope this article will help you solving your tasks or shows you the potential of MonitorWare Agent, and what you can archive with it. Feel free to email me for recommendations or questions. Of course, the outlined actions are only samples and you may do other things with them, for example store log records to a database table instead of storing them to file.

On the recycle bin: if a local file is deleted via Windows explorer, it is by default moved to the recycle bin and not actually deleted. However, the above mentioned events are still generated. This may be especially useful if you monitor e.g. a very important file via an email alert. There may be chances to undelete it even from the recycle bin.

How To setup Windows centralized Monitoring

Article created 2007-10-26 by Florian Riedl
Article updated 2011-05-23 by Tom Bergfeld

Please Note: This article is valid for EventReporter, WinSyslog and MonitorWare Agent in addition to MonitorWare Console!

Windows systems monitoring is really important for all small to large sized environments. The MonitorWare line of products helps to accomplish this important task. This article is to help you establish a small setup to monitor your Windows systems.

This article is strictly task focused. It does not describe why the systems should be monitored nor does it provide any further background. Please see the respective backgrounds or each of the products documentation on this. This article is a step-by-step description of what you need to do in order to centrally monitor your Windows systems.

Centralized Event Reports

In this step-by-step guide, we want to monitor the windows eventlog on all of our client machines (which can be done either with EventReporter or MonitorWare Agent) and then forward the logfiles to a central log server which writes the data into a database (can be done with WinSyslog or MonitorWare Agent). After this, MonitorWare Console should read the data from this database and automatically generate event summaries for the monitored servers.

This guide focuses on a typical small to medium business topography with a single geographical location and five windows clients and a central hub server. All systems are well connected via a local ethernet. Event reports from all machines should be stored in a database. The administrator shall receive daily consolidated event reports.

What you need

In this guide, I am focusing on building a solution with Adiscon’s EventReporter, WinSyslog and MonitorWare Console. (Please note that you can use and configure MonitorWare Agent in the same way like either WinSyslog or EventReporter because it is our main product which has all the features of the other two products too. Please also see our article on which product to choose if you are in doubt which one is right.)
This combination allows you to centralize all your event logs and reports on them. Free 30 day trial versions are available at the respective product sites (links below), so you can try our products without the need to buy anything. You need to run the following products:

One EventReporter (alternative: MWAgent) for each system that is to be monitored. In our scenario, this means 6 copies, one for each client and one for the central hub server, if you want to monitor the hub server as well.
One WinSyslog (alternative: MWAgent) to receive and store event reports from the EventReporter (alternative: MWAgent) monitoring agents.
One MonitorWare Console to automatically generate consolidated reports based on the gathered log data. MonitorWare Console is a very comprehensive tool that helps you to carry out sophisticated analysis of your system. For more information about MonitorWare Console, please refer to its manual.

Notes:

You need administrative privileges on each of the machines. This is required both for installation and configuration. Make sure you log on with a sufficiently privileged user account.
You need a database to store the events. Recommended are MySQL or MSSQL databases, but you could use a JET database as well.
To deliver MonitorWare Console reports, you need a mail server capable of talking SMTP (most modern servers support this)

Step 1 – Download Software

You should check the web sites for new versions if you downloaded your copies a while ago as security and monitoring is a short lived business, and new product versions can appear quickly. Please visit www.eventreporter.com/en/download, eventually www.mwagent.com/en/download, www.winsyslog.com/en/download and www.mwconsole.com/en/download/ to download the latest versions of EventReporter, MWAgent, WinSyslog and MonitorWare Console.

Step 2 – Installing WinSyslog/MWAgent

Identify the system; WinSyslog or MWAgent (and probably MonitorWare Console) should run on. Take a note of its IP address or host name. You’ll need this value when configuring the EventReporter clients. For our example, I assume this system has an IP address of 192.168.0.1.

Run the WinSyslog/MWAgent setup with default parameters. When setup has finished, it automatically is configured to operate as a simple Syslog server. However, it does not yet use a database as we need it to. We’ll later set it up to write data into the database.

Step 3 – Install EventReporter/MWAgent

Run the EventReporter/MWAgent setup program on all systems that should be monitored. This means you need to run it on all five clients and the central hub server (as mentioned above that it is also to be monitored).

For larger installations (with many more servers) there are ways to set it up in a simpler fashion, but in a scenario like ours, it is faster to install it on each machine manually. You can install it with the default settings. When setup has finished, the program automatically is configured to operate simply to report events. However, it does not yet create the log in our database we need. So we will go ahead and change this on each of the machines or by launching it on one machine and remotely connecting to the others. It is your choice. In this sample, I use the EventReporter/MWAgent on each machine (it is easier to follow).

Step 4 – Configuring the Central Agent

The steps described are for setting up your WinSyslog/MWAgent installation on your central hub server. Some steps will be described in a mini-guide, so be sure to follow the links:

1. Start WinSyslog/MWAgent.

2. Select your language – in this example, I use English, so it might be a good idea to choose English even if that is not your preference. You can change it any time later, but using English makes it much easier to follow this guide here.

3. We will now create a ruleset for logging into a database. You can see the detailed steps in the following guide. It describes setting up the action and the ODBC datasource. In this example, a JET database will be used, but you can adapt these steps to let the ODBC driver point to a different database. For setting up the database, please refer to the software producer. Immediate troubleshooting can be done with us, too.
How to create a ruleset for database logging?

4. Now that we have created our ruleset, we are ready to configure the receiving service. Again, follow the mini-guide for the specific steps. We will create a SETP server. With this, we will be able to receive the eventlog data from our agents on our central hub server. Why not using syslog? Because syslog will change the format of the log message and for creating reports we need the correct format.
How to create a SETP server service?

5. Make sure you press the “Save” button – otherwise your changes will not be applied. The only thing left is to start/restart the service with the Play button. Once done, your central agent is ready to receive the log data and store it into your database.

Step 5 – Configuring the Reporting Agents

The steps you will take now will show you how to setup your EventReporter/MWAgent to monitor your Windows Events and forward them via SETP to your central hub server from Step 4. The procedure is the same as above. Follow the links to the miniguides for a detailed description of the respective step.
Please Note: If you use MonitorWare Agent on your central hub server, then you do not need to install EventReporter. You can do these configuration parts in MWAgent, too. You just have to make sure, that the service uses the correct ruleset!

1. Start WinSyslog/MWAgent

2. Again, you can select the language to use. And again, I suggest using English, as this makes the guide easier to follow.

3. We will now setup a new ruleset for forwarding the log data to our central host. Please make sure, that you insert the IP 192.168.0.1 (respective the IP you noted and which belongs to your central hub server) into the forward SETP action. This is crucial or else your central hub server will not receive any data.
How to create a Forward vis SETP Action?

4. After creating the ruleset, we will now create the service which will poll the eventlog data for forwarding via SETP. The service we are going to create is the EventLog Monitor. It will check in set time intervals for new events and if some occurred, they will be processed by the ruleset. Here are the steps for this procedure:
How to create the EventLog Monitor Service?

5. Again, make sure you press the “Save” button – otherwise your changes will not be applied. The only thing left is to start/restart the service with the Play button. Once done, you reporting agent will begin to poll the log data from your eventlog and forward it via SETP to your central hub.

Step 6 – Installing and Configuring MonitorWare Console

Now we will turn to MonitorWare Console. To keep traffic low, you could set this up on your central hub server as well. This will give MonitorWare Console direct access to the database and helps to perform better. In the following guide, we show you how to install MonitorWare Console and do the basic configuration steps:
MonitorWare Console 3.x – Installation and Configuration Steps

Step 7 – Generating Reports with MonitorWare Console Manually

This section explains how the reports can be generated with MonitorWare Console manually. Since “System Status” Report is most comprehensive report that tells a detailed description about the network, in this section I will explain this report only. Please note, that the procedure for generating any report is almost the same.
How To Generate Reports with MonitorWare Console 3.x Manually

Step 8 – Scheduling the Generation of Reports with MonitorWare Console

This section explains how the reports can be generated with MonitorWare Console automatically using Job Manager. With Job Manager, you can generate all the reports based on a pre-defined schedule and ask it to either store it in some location on the hard disk or send it to specified recipient via email. Once again, I will explain the scheduling of System Status Report in this section. Please note that, the procedure for scheduling any report is the same.
How To Schedule Reports with MonitorWare Console 3.x

You are done!

Well, this is all you need to do to configure the basic operations. Once you are comfortable with the basic setup, you can enhance the system with local pre-filtering of event, enhanced logging and alerting (with MonitorWare Agent) and changing report options (with MonitorWare Console).

I hope this article is helpful. If you have any questions or remarks, please do not hesitate to contact us at support@adiscon.com.

Supported Windows Versions: Windows 7 / 2008 / Vista / 2003 / XP

Intrusion Detection via the Windows Event Log

Step-By-Step Guides

Article created 2003-05-09 by Rainer Gerhards.

Intrusion Detection via the Windows Event Log

The Windows event log provides multiple evidence of potential intrusions. We will discuss what to look for when checking the event log.

We have used Windows 2000 Server while creating this text. There may be differences for other versions, so you might want to check if you are using a different environment.

Detecting Failed Logons

Numerous failed logons are a good indication that someone is trying to guess user passwords. This is typically done using a so-called “dictionary attack”, where a list of words often used as passwords (the dictionary) is simply tried on a given account. If the account password is carefully chosen, not only the dictionary attack fails but there are many failed logon events. Even if the password is contained in the dictionary, chances are quite good that it is not in the first 5 to 10 words the attacker tries. Windows allows you to lock out an account that has too many invalid password attempts. If the configured threshold is reached, the account will be disabled for a given period of time and Windows will also log event in the security event log.

Configuring Windows

By default, Windows does not check for those kind of attacks. It must be turned on by the administrator. This is done in the “Account Lockout Policy” (part of the “Account Policies”). On a single server, this is configured with the “Local Security Settings” administrative tool. In a domain environment, this is part of the group policy set that is to be applied. Below is a snapshot of a typical configuration for it:

Please note that this policy does not apply to the build-in administrator account. It will never be locked out. This is another very good reason to rename it.

Activating this policy does not automatically write events to the Windows Event Log when an user is locked out by the system. To see these, you also need to turn on auditing. This is done with the same tool, under the “Local Policies”, “Audit Policy”. There, you need to enable at least “Success” audits for the “Audit account management”. This is circled in the screen-shot below.

Please note that I have also enabled Logon-related events in the screenshots. We will later see why I have done this.

With these settings, we will receive an security event 644 as soon as an account is locked out.

Screenshot of the 644 Event

Important: our testing has shown that the 644 security event does not occur under all Windows versions. While testing with Windows 2000 without a service pack, these events did not occur. After applying service pack 3, they appeared. So be sure to check that the events occur in your environment.

If the 644 event is not generated on your systems and you are not able to patch it to the service pack level that makes it appear, you can alternatively look into the 693 logon failure events. When someone tries to use a locked out account, they look as follows:

Please note the reason text. This reason only happens when an account is locked out. However, this reason does only occurs after the account has been locked out. The login failure leading to the lockout still has the normal “invalid password” text in it. As such, lockouts may be left undetected or detected only after the incident when using this event as notification. Not only for this reason we highly recommend to apply the most recent service pack.

Creating Rules for MonitorWare Agent

Now that we have the proper events present in the Windows Security Event Log, we can build MonitorWare Agent rules to detect unusual patterns. Please keep in mind that the rule set must be either bound to an event log monitor service or be included from another rule set that is bound to one. Without that, the rule set will not be executed. We will not explain this process here in this chapter. We just focus on the filters and rule set itself.

We will create a rule that fires if our 644 event is seen:

We use an email action to notify the admin once this happens:

Of course, we could also have done other things. Good example might be sending a syslog message to a syslog server specifically monitoring such events. The proper action is mainly depending on your intended result.

This rule detects attacks that will lead to an account becoming locked out. It will also fire if a user actually mistypes his password often enough to become locked out. This rule does not help against attacks where the user id changes together with the password. There are some tools out doing so.

Fortunately, we can detect those attacks, too. The key to it is counting failed logons. If the number of failed logons reaches a threshold within a given amount of time, we can suspect that something is wrong. Of course, the threshold is different for different types of machines. A web server, for example, that is just serving web pages and where only administrators and web authors log on, the number of failed logons should be really low. On a busy file server, on the other hand, that threshold should probably be much higher. As such, the actual numbers we use in our sample here should be treated with care. They need to be replaced by some values that match your typical environment and expectations. If in doubt, consult your past event logs to find out what is normal.

We have two different event ids to look at: the 529 event is generated when somebody logs onto the machine itself. This must not be an interactive logon. It can also be a logon via the network, via the web server, the ftp server or any other logon that is done either by the user himself or a process on his behalf on the local machine.

There is also the 681 event. That event is logged whenever the security authority authenticates a user. This event typically is logged on domain controllers when domain users authenticate. A domain controller can log this event even when no local logon happens afterwards. Also, as any domain controller can authenticate a user, the 681 event can occur on every domain controller. Thus, the amount of those events on a single domain controller can not reliable be used to detect the threshold. On a stand-alone server, event 681 is logged together with 529.

For our needs, this means we should monitor the 529 event if we are interested in the local failed logon activity and the 681 if our scope is the network. In the later case, it might be helpful to ensure that security events from all domain controllers are passed to a central MWAgent. Only this ensures that MWAgent has the full overview over network logon activity.

In our sample, we monitor a stand-alone server. So our filter looks like this:

Please note the area red encircled. This is the important part here. The “Fire Only if Event Occurs” setting means that there must be at least 10 failed logons within 60 seconds. If there are fewer, the filter will not apply, even though the filter condition would otherwise apply. Similarly, the “Minimum Wait Time” specifies that at least 120 seconds need to have passed since the last time this filter condition fired. Again, if the last match was more recent, the filter condition as whole does not evaluate as true. So with the above filter, we will receive a notification at most once every 2 minutes (120 seconds).

Obviously, the two global filter conditions need to be adjusted to your environment.

Detecting Suspicious Configuration Changes

There are many opinions on what a suspicious configuration change might be. In this sample, we assume we are dealing with an already configured web server. It again is a stand-alone server. There is not much need for configuration changes once a machine has reached this stage. Obviously, some of the notifications we generate here are overdone on a typical domain controller. Nevertheless, the example should provide an idea of what to look for.

Events we are interested in are these:

Account Management
- 624 – User Account Created
- 626 – User Account Enabled
- 627 – Password Change Attempted
- 628 – User Account Password Set
- 629 – User Account Disabled
- 630 – User Account Deleted
- 631 – Security Enabled Global Group Created
- 632 – Security Enabled Global Group Member Added
- 633 – Security Enabled Global Group Member Removed
- 634 – Security Enabled Global Group Deleted
- 635 – Security Enabled Local Group Created
- 636 – Security Enabled Local Group Member Added
- 637 – Security Enabled Local Group Member Removed
- 638 – Security Enabled Local Group Deleted
- 639 – Security Enabled Local Group Changed
- 641 – Security Enabled Global Group Changed
- 642 – User Account Changed
- 643 – Domain Policy Changed
System Events
- 512 – Windows is starting up
- 513 – Windows is shutting down (you will probably not see this event before the system is restarted)
- 516 – Internal resources allocated for queuing of security event messages have been exhausted, leading to the loss of security event messages
- 517 – The security log was cleared
Policy Change
- 608 – A user right was assigned
- 609 – A user right was removed
- 610 – A trust relationship with another domain was created
- 611 – A trust relationship with another domain was removed
- 612 – An audit policy was changed
- 768 – A collision was detected between a namespace element in one forest and a namespace element in another forest

Events in bold are uncommon on nearly all types of machines. Depending on the role a server is playing, events not shown in bold can occur as part of day-to-day operations. On such servers, they should obviously not trigger alarms. Again, on a fully configured web server in product, we would like to see neither of them.

We create two rules in MonitorWare Agent, one for the highly suspicious events and one for the others. Let’s start with the highly suspicious ones:

And this one holds the filter conditions for the other suspicious events:

In order for this rule-sets to work, we also need to tune our auditing settings. We now need to audit “System Events” and “Policy Change, too. This will lead us to these policy settings:

Tag: Windows