Have you already heard about THOR Thunderstorm,  a self-hosted THOR as a service? In this blog post, we will show how you can leverage THOR Thunderstorm to level up your email infrastructure security.

THOR Thunderstorm is a web API wrapped around THOR, which accepts file uploads and returns matches in JSON format. It can process thousands of samples per minute sent from any device within the network. The abilities are seemingly endless, from scanning exotic OSs to integrating custom services (e.g., mail server). Check out this introduction blog for a taste of the many use cases of THOR Thunderstrom. Lets get started with some background on Postfix and Milter.

The Postfix mail server is a popular and highly configurable Mail Transfer Agent (MTA) used for routing and delivering email messages within a network or across the Internet. Similar to the Sendmail MTA, it can use Milter (protocol) to scan incoming emails for spam or malware. On incoming emails, compatible MTAs use the Milter protocol to communicate with an extra service, which also speaks the Milter protocol. This extra service scans the email and responds with its findings. Based on the response of the extra service the MTA can filter, discard, or quarantine the email. In this blog post, we are releasing an open-source implementation of a Milter Service called “postfix2thunderstorm” which allows you to scan emails using THOR Thunderstorm: https://github.com/NextronSystems/postfix2thunderstorm .

Supercharging your Postfix involves three things:

First, you need to set up THOR Thunderstorm – our manual will help you here. Make sure that there are the appropriate firewall rules in place to allow communication between the Milter service and THOR Thunderstrom.

Second, you need the “postfix2thunderstorm” service itself. You can find setup and usage instructions in the GitHub repo. Make sure that Postfix is able to reach this service via the network.

Last, you need to configure Postfix to “speak” to the “postfix2thunderstorm” service. To do this, add the following to your Postfix config (/etc/postfix/main.cf) and restart it:

# See https://www.postfix.org/MILTER_README.html for more information
# IP/Port of host where the postfix2thunderstorm service is running  
# (might be a good idea to make it the localhost (or use TLS)) 
smtpd_milters = inet:<IP>:<Port> 
# default action in case of error/timeout/... 
milter_default_action = accept  

• https://thor-thunderstorm-setup-guide.nextron-systems.com/en/latest/
• https://github.com/NextronSystems/thunderstorm-collector
• https://github.com/NextronSystems/thunderstormAPI

In case you need additional help, drop us a line.

SIGMA Log-Source

Before we delve deeper, Let’s take a step back and talk a bit about how the log-source attribute is used in Sigma rules.

Every Sigma rule requires a section called log-source that indicates as the name suggests, the log source on which this detection will fire. A typical example would look like this:

product: windows
category: process_creation

The “product” indicates that this rules is targeting the “Windows” product and a specific category called “process_creation” is used to indicate that this rule is using “Process Creation” events. You can read the full explanation of every field in the specification

To someone who isn’t familiar with Sigma or logging a couple of question will arise:

• Is “Process Creation” category using events “Sysmon/EventID 1” or maybe “Microsoft-Windows-Security-Auditing/EventID 4688”?
• The next question that arises: How would we collect these logs?

This is where the log-souce-guides enter the picture.

-Log-Source Guides

Starting from today, if you navigate to the Sigma main rule repository, you’ll see a new folder called “rules-documentation” this will be the location of the aforementioned “log-source-guides“ and future documentation projects teased here.

The log-source-guides will have a simple structure that reflects available log sources. So in the example of “process_creation” for the Windows product:

Structure

Now that we established the location of these guides, let’s talk about their structure and the information they provide. Every logsource guide will provide the following information:

Event Source(s)

This section will describe the source(s) used by the log-source. As a quick way for the reader to know exactly which channel or ETW provider is required to be able to receive the events.

Logging Setup

This section describe a step by step guide on how to enable the logging and which events are to be expected by enabling it. Let’s take the “Credential Validation” audit policy.

• The “Subcategory GUID” is the GUID for this specific audit policy which can be used with the auditpol command to enable the log (as we’ll see in a little bit).
• “Provider” indicates the exact ETW provider that is responsible for emitting these events.
• “Channel” is the Event Log channel where the generated events are emitted.
• “Event Volume” indicates the amount of logs to be expected by enabling that audit category or EventID.
• “API Mapping” is a direct link to jsecurity101TelemetrySource project.
• “EventIDs” are the events generated by enabling the policy or log.

Next comes the section on how you’ll be able to enable the log in question – in this example either via Group Policy or by using Auditpol.

Note: This section will obviously be different depending on the logs. Enabling Sysmon logs will be different than enabling Security logs.

Full Event(s) List

This section while not always be present and is meant to be a collection of all events generated by the event sources in question. It’s there as a quick reference for any event. As every event is linking to the MSDN documentation when possible.

Event Fields

The last section contains the specific event fields used by every event. While this section will be complete for certain log sources such as “process_creation”, it’s still a work in progress for logs such as security and will be populated over time.

The idea behind this is to provide the fields that the event generates as a reference. Since SIGMA rules aim to be as close to the original logs as possible and leave field mapping to the back end.

Linking Log-Source Guides and Rules

To make these log-source guides easily accessible. Every Sigma rules will now link to their respective logsource documentation via a unique ID that will be added to the “definition” section. Here is an example:

As part of this initial release documentation will be available for the for the following log-sources:

• product: windows / service: security
• product: windows / category: process_creation
• product: windows / category: ps_module
• product: windows / category: ps_script

In the coming weeks and months we’ll keep adding more documentation to cover every available log-source.

Sigma Log-Source Checker

As part of this release we’re also providing a new script we’re calling “sigma-logsource-checker“. The idea behind this script is to provide the user the ability to know which logs to enable based on the SIGMA rules they’re using.

It takes a Sigma rules folder as input, parses all the used log-source and Event IDs and suggests the Audit policies and logging configurations that should be enabled.

As an optional feature, It can also parse the XML output of gpresult

gpresult /x [results.xml]

and then suggests configuration changes based on current policy:

Note: This version will only check the Security Audit policy and PowerShell log configuration. We’ll keep improving it as we go along.

You can have a look at this today by visiting the Sigma HQ main repository

Valhalla Front Page Now Shows Sigma Rule Information

The Valhalla front page already shows Sigma rule information. The grey bars show the number of new Sigma rules created per day.

Two new tables on the front page list new Sigma rules and the rule categories. The first table contains new rules with rule title, description, creation date, a reference link and an info page.

After almost half a year of development, we are pleased to announce the release of our free version of the Aurora Agent named Aurora Lite.

The Aurora agent is a Sigma-based endpoint agent that offers maximum transparency, flexibility, and confidentiality. It doesn’t require an additional kernel driver but uses the native Event Tracing for Windows (ETW). Other detection modules like the “Cobalt Strike Beaconing Detector” or the “LSASS Dump Detector” provide detection capabilities that exceed the scope of pure Sigma matching. 

Aurora Lite is a limited but free version of the endpoint agent. It lacks some features, has no additional detection modules, and cannot be used with the comfortable ruleset and configuration management in ASGARD Management Center. The complete list of limitations can be found here.

Regardless of these limitations, we believe that even the free version can compete with other commercial endpoint agents and provides similar detection coverage. 

Captured Pre-Release Web Session

The following recorded video session includes information about our new Sigma-based EDR agent called “Aurora” and the free “Aurora Lite”. It’s a preview of the agent with information on its features, limits, advantages and a live demo.

The release is scheduled for December 2021. Follow us on Twitter or subscribe to the newsletter to get updates about the development of Aurora.