Share via

Introducing Project Sauron - Centralised Storage of Windows Events - Domain Controller Edition

  • Article

(Nearly) every customer I visit is lacking comprehensive security auditing in their downlevel DEV and UAT environments and sometimes even in their production environment. This scenario exists for a number of reasons. For some larger customers, the security logs roll so quickly that it's considered "too hard" to even bother trying to archive them without a SIEM in place. Sometimes they have a project already  "planned" or "in-flight" to deploy <insert product name here> that will capture all the required events but it is still months away (or longer). One that i'm hearing a lot more of lately "we used to store everything but our SIEM is now to expensive and we can only store some of it". I find this one so amusing since the cost of large volume storage has dropped so dramatically.

 

Without an effective security audit trail, the ability to discover when changes were made or possibly even track a breach during a security incident response becomes near impossible.

 

Project Sauron aims to resolve a number of these issues using the built-in security capabilities of Windows to store the appropriate events.

 

Windows Event Forwarding is in no way new, however the ability to create custom destination for forwarded events has always been difficult. My previous blog post explained how to create custom event logs for this purpose however it was quite tedious to build anything greater than a few destinations and I wanted to create lots of destinations, not just a few.

Using the Project Sauron Framework, the deployment of centralised Windows Event Collector (WEC) server becomes almost simple. Using custom WEC subscriptions, the required events are forwarded into dedicated event channels and dedicated .evtx file. Creation and deployment of your own custom solution (would love to hear your ideas) or re-using one the pre-built solutions can have you operational in matter of hours not months. The diagram below gives an example of how the framework can be used.

[caption id="attachment_535" align="alignleft" width="1024"]Project Sauron Overview Project Sauron Overview[/caption]

I want to be very clear, Project Sauron is in no way intended to be a SIEM. It's goals are to:

  • Allow organisations to forward and store specific events of different values and frequency events into separate buckets for basic viewing and/or future import into a SIEM
  • Provide rudimentary viewing buckets for quick glance at low volume but high value long term events
  • Enable the capability to collect security audit events in DEV/TEST style environments that for whatever reason are not monitored by a SIEM.
  • Reduce the attack surface of high value assets by eliminating the requirement for yet another C2 agent with local system privileges.
  • Enable highly network isolated environments that can't connect to on-premises SIEM's or a cloud security monitoring solution keeping the native format to allow manual future analysis through manual imports and analysis.

WEC subscriptions are based on XPath filters in which we define which particular events we want our clients to forward to the collector. Conveniently, Event Viewer Custom Views use exactly the same filtering mechanisms as well and we exploit this relationship as part of the framework.

I commonly see Event Viewer custom views used on Domain Controllers to filter out the noise of security logs and that is how this all began. A customer was targeting multiple DC's one-by-one with a custom view to piece together a change that been made all the whilst racing against the pending security log overwrite that was coming in the next 20 minutes (this was a 100,000+ user organisation with a standard 2GB security log on the DCs). I figured, why not send those particular events of interest to a dedicated channel on a WEC server.

By spending the time to craft the appropriate XPath filters, we can then build the corresponding dedicated event log channel .evtx file and subsequently a WEC subscription to bring it all together. With the appropriate WEF/WEC configuration and the Event Channels along with WEC Subscriptions enabled, the configured source machines will begin to forward their events. Low volume events such as eg.. user and group creation may take 3 years to fill up the dedicated 1GB default .evtx file whereas high volume events like Kerberos TGS requestions might take 3 hours and be archived create a new 1GB .evtx file.

[caption id="attachment_536" align="aligncenter" width="874"]Custom Event Views (Left) and Custom Event Channels (Right) Custom Event Views (Left) and Custom Event Channels (Right)[/caption]

By spending the time to craft and validate the appropriate XPath filters, we now have the building blocks to build the corresponding event channels with associated .evtx log file.

Whilst custom event views (displayed on the left) are simply .XML files that live in the "%programdata%\Microsoft\Event Viewer\Views" folder on your machine and their display mimics the file system folder structure, Custom event channels (displayed on the right) require the construction of a dedicated  manifest file and the compilation of a .DLL to allow Windows to create them.

The framework simplifies the creation of all of these components by executing multiple scripts against a master input CSV file which defines the events and their configuration.

Whats in the Framework?

The scripts in framework perform the following tasks with the master Input CSV file.

  1. Create the custom views .xml files and place them in %programdata%
  2. Creates the manifest file and provides instructions to use the Windows SDK to compile and load the .dll
  3. Prepares the Event Channels b to receive events and subsequently archive the existing .evtx once it hits 1GB
  4. Import the WEC subscription configurations ready to be enabled (manual intervention required to enable by default)

I will go through the full process in a future blog posts, but if you want to get started, the following steps will give you an idea of how the solution operates.

Quickest Start - No Configuration Changes
1. Grab the latest release of Project Sauron from https://github.com/russelltomkins/Project-Sauron/releases

2. Extract the "Domain Controllers" custom views to "%programdata%\Microsoft\Event Viewer\Views" on your management host.

3. As an appropriately privileged user, Open Event Viewer and target a Domain Controller. Peruse through the custom views to understand the types of events that would be forwarded from each Domain Controller to the collector.

Quick Start - WEC Server and Domain Controller Changes

Prep - The WEC server and Domain Controllers must be prepped to have the WEC server configured and WEF on the Domain Controllers succesfully talking to it. Details of the requirements can be found in Jessicas' blog post here.

1. Grab the latest release of Project Sauron from https://github.com/russelltomkins/Project-Sauron/releases and extract to a folder on your nomiated WEC subscription server.

2. Copy the DCEvents.dll and DCEvents.man file to "C:\Windows\System32"

3. Launch an administrative PowerShell and change to the directory with the Project Sauron files
4. Load the custom events channels by executing "wevtutil.exe im c:\windows\system32\dcevents.man"

5. Prepare the custom event channels by Executing ".\Prepare-EventChannels.ps1 -InputFile DCEvents.csv -LogRootPath D:\Logs". If you omit the -LogRootPath paremeter, the script will default to "D:\Logs" as the location for the .evtx files.

6. Create and import (disabled) the WEC subscriptions by executing ".\Create-Subscriptions.ps1 -InputFile .\DCEvents.csv".

7. Choose and enable the WEC subscriptions you wish to enable. There is no "select-all" but you can select the first subscription, hold SHIFT and select the last subscription then right-click enable.

[caption id="attachment_525" align="aligncenter" width="1024"]WEC Subscriptions Enabled WEC Subscriptions with 1 DC connected[/caption]

Once the Domain Controllers connect to the WEC server, they will receive the appropriate subscriptions and begin to sending the appropriate events.

Some quick notes:

  • Your Domain Controllers in this scenario need to have the appropriate Advanced Audit Subcategories enabled.
  • You don't have to enable every subscription at once. Enable a single subscription or just a category eg.. the Object Management category to understand how it works.
  • The logs folder will have NTFS compression enabled. This reduces .evtx size by roughly half
  • Once an individual .evtx log file hits 1GB, it will be archived by the Event Log service and a new one created.
  • ZIP Compressing the .evtx file will result in an rough 60-70MB file.
  • If your having issues, check the "Windows Event-Forwarder" plugin on the DC to confirm it has connect the WEC server and succesfully received subscriptions.
  • A script to manage the compression of the archived (non-active) .evtx files is nearly completed.
  • All .PS1 and the pre-canned .DLL file is AuthentiCode signed. Your machines will (should) not trust my signing certificate by default but should validate they have not been tampered with.

The Future

Phew ... there is soo much more to all of this, but hopefully once you get it running it's value will be apparent, even it is just keeping events around to import into a future SIEM.

Please let me know what you think in the comments or improvements/ideas via the GitHub repository which I'm still slowly learning how to use.

More posts to come

Russ

Comments

  • Anonymous
    May 08, 2017
    It is pretty cool tech, it would be nice if you guys would put together a real product for all of this. When I was implementing our WEC server I was impressed with the capabilities, but some areas are extremely limiting. It would be nice to be able to forward only specific events to the server rather than forwarding all and filtering at the server. A nice reporting tool would be great as well.
    • Anonymous
      May 08, 2017
      Hey Matthew. Agreed some of limitations are frustrating, especially the lack of full XPath functions. In regards to not filtering at the server level, it could be achieved if you forward all security events to an initial WEC server and then perform the filtering there before forwrarding off to a second server. Obviously, you now have 2 servers to manage, extra storage and 2 subscription sets but it is achievable. Reporting side, custom event views can be created where you simply need to update the username for it to work, crude but it works. The .evtx files can be easily exported to CSV then put into whatever you want as well and I plan to provide a few basic scripts around that as well, primariliy for the object management events.
  • Anonymous
    May 09, 2017
    Nice name ! Is it related to this ?Just asking for a friend, he likes to collect sate-sponsored rootkits.
    • Anonymous
      May 11, 2017
      No relation at all ... simply a name a colleague envisioned when I described what it can do :)
  • Anonymous
    May 09, 2017
    This sound relevant to me but I don't know what SIEM or WEC mean. Not everyone consuming public docs are subject matter experts so it's usually a good idea to define acronyms at least once (first use). Thanks.
    • Anonymous
      May 11, 2017
      Updated a few entries to hopefully make things clearer.
  • Anonymous
    May 10, 2017
    Good work! Many customers could make use of this. Thank you and continue! ;)
    • Anonymous
      May 11, 2017
      Thanks. The more visibility in any customer environment the better!
  • Anonymous
    October 09, 2017
    The comment has been removed
    • Anonymous
      October 25, 2017
      The comment has been removed