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

(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 tha ti’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.

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

Project Sauron Overview

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

Custom Event Views (Left) and Custom Event Channels (Right)

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%MicrosoftEvent ViewerViews” 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 operations

Enabled WEC Subscriptions with 1 DC connected

• 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

• A domain members version (preview custom view in release 1.3) which covers the events from Jessica’s MSAU 2015 Ignite session Monitoring what matters – Windows Event Forwarding for everyone (even if you already have a SIEM.)
• A pre-canned .DLL for AD Certificate Services (AD-CS) to collate Issues, Pending, Revoked certificate and service operations.
• Custom views for the WEC server to allow further quick discovery eg… Show RC4, AES128 and AES256 Kerberos AS requests

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.