Demystifying SIGMA Log Sources

Demystifying SIGMA Log Sources

One of the main goals of SIGMA as a project and SIGMA rules specifically has always been to reduce the gap that existed in the detection rules space. As maintainers of the SIGMA rule repository we’re always striving for reducing that gap and making robust and actionable detections accessible and available to everyone for free.

Today we’re introducing a new contribution to the SIGMA project called log-source guides. The idea behind it is to provide specific guides on configuring a system’s audit policies so that the system actually creates the logs needed by the rules. An adequate audit policy is a crucial dependency often overlooked when deploying Sigma rules.

 

SIGMA Logsource

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

Every SIGMA rule requires a section called logsource 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 logsouce-guides enter the picture.

Logsource 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 logsource-guides and future documentation projects teased here.

The logsource-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 logsource. 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 LogSource Guides and Rules

To make these logsource 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 logsources:

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

 

SIGMA Logsource 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 logsource 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

Private Sigma Rule Feed in Valhalla and Partnership with SOC Prime

Private Sigma Rule Feed in Valhalla and Partnership with SOC Prime

We are proud to announce the integration of our private Sigma rule set in Valhalla. This rule set is used in our scanner THOR and endpoint agent Aurora. 

The rule set currently contains more than 250 quality-tested and generic rules written by Nextron’s detection engineering team. 

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.

The second table on the front page shows for which type of log source the rules have been written for.

This can help you decide if the contents of the feed align with the log data your organisation collects.

Feed Characteristics

The feed can be requested as a ZIP archive, which contains all rules in separate files or in form of one big a JSON file.

The rules included in the feed share the following features:

  • Each rules went through several stages of internal quality testing
  • Each rule is tagged with the current MITRE ATT&CK® techniques
  • Most of the rules use a more or less generic detection logic focussing on methods and not on tools

The feed is offered in a form that facilitates filtering of the rules based on levels, type or keywords. 

Future versions of the feed will include usage and false positive statistics based on anonymised data collected through Nextron Systems’ MSP partners. 

Web Access and API

The feed can be retrieved from the web page using the respective form on the Valhalla front page. Using the “demo” key, you can get the rules maintained in the public sigma repository in the streamlined form in which we offer all our rules. 

The Python module “valhallaAPI” has been updated to support the new Sigma rule feed. 

Partnership with SOC Prime

We are also excited to announce that we have entered into a partnership with SOC Prime, a renowned threat intelligence and cybersecurity content platform.

As part of this collaboration, Nextron’s detection rules will be made available in SOC Prime’s threat detection rule marketplace, providing SOC Prime’s customers with access to a wider variety of rules for identifying potential security threats. Nextron will be the first B2B partner to participate in this program, with their feed accessible to SOC Prime’s customers after a subscription update.

We believe that this partnership will provide significant value to both Nextron and SOC Prime’s customers by enhancing their ability to detect and respond to cyber threats.

Pricing

We would like to inform our customers that the subscription to our threat detection rule feed is priced at 15,000 USD per year.

However, we are currently offering the feed at a reduced price of 10,000 USD per year. This offer is only valid for new customers who subscribe within the promotional period which ends at the end of May 2023.

The subscription fee provides access to our constantly updated and comprehensive threat detection rules, which have been carefully curated by our team of cybersecurity experts. We believe that this is a valuable investment for organizations looking to enhance their security posture and mitigate the risks of cyber threats. Don’t miss out on this limited time offer and subscribe today!

Use the “Get Started” button in the upper right corner of this web page to contact our sales team for details.

How to scan ESXi systems using THOR

How to scan ESXi systems using THOR

More and more often, adversaries target and exploit Internet-facing appliances or devices with exotic or restricted operating systems. Users ask if there is a way to run a compromise assessment scan on these systems with the YARA rules used in THOR.

Following up on the exploitation of Internet-facing ESXi servers, this blog post describes ways to remotely scan remote systems like an ESXi using THOR or the free THOR Lite YARA and IOC scanners. This method can also be be used to scan other devices usually unsupported by real-time Antivirus engines or EDRs, e.g. Citrix Netscaler gateways. 

So, we plan to mount the remote file system using SSH (SSHFS) and then we instruct THOR to scan the mounted remote filesystem. 

Prerequisites

  • We need to reach port 22/tcp on the target system
  • A source system with support for sshfs (on Debian use: sudo apt install sshfs to install it)
  • A version of THOR Lite or the full THOR with a lab license

Mounting the Remote File System via SSH

First we create a new folder and mount the remote file system to that local folder:

sudo mkdir -p /mnt/esx
sudo sshfs -o reconnect root@esx1.company:/ /mnt/esx

The -o reconnect option makes sure to reconnect the

Scanning the Mount Point with THOR Lite

With THOR Lite we can now run a so-called “Filescan” on the mounted drive.

sudo ./thor-lite-linux-64 -a FileScan --alldrives -p /mnt/esx

The following scan is much more intense as it scans every single file regardless of its extension or type. Scanning every file usually leads to much longer scan times and higher network load. (be careful when using the --intense flag)

sudo ./thor-lite-linux-64 -a FileScan --alldrives -p /mnt/esx --intense

Scanning the Mount Point with THOR

With a full featured THOR and a so-called Lab license we can use the –virtual-map flag to virtually map the folder /mnt/esx to / internally. This means that signatures and filename patterns that make use of the virtual and not the actual path. We can also define a hostname that will appear in the log file using the -j flag. Otherwise the log would always contain the hostname of the scanning workstation.

sudo ./thor-linux-64 -a FileScan --alldrives -p /mnt/esx --virtual-map /mnt/esx:/ -j esx1

Using the full version, we would use a different flag combination for a more intense scan of the remote system. The full version with a lab license allows us to use the --lab flag.

sudo ./thor-linux-64 --lab -p /mnt/esx --virtual-map /mnt/esx:/ -j esx1

The --lab flag automatically activates the intense scan mode that checks every file, multi-threaded scanning, deactivates resource control and some other flags that can be useful in a lab scanning scenario.

Example Match

The following screenshot shows an example match on a malware found on systems affected by the ESXiArgs attacks. The rules and IOCs for this attack are available in THOR and the free THOR Lite version.

Other Notes

  • Test scans on our internal ESX/ESXi systems took between 8 and 30 minutes. (scans via VPN)
  • A network disconnect only pauses the scan, a forced umount crashes the scanner.
  • We tested network disconnects of 1 and 5 minutes. After a reconnect THOR just resumes the scan where it left off. 

Advantages of the full THOR version

Apart from the usual advantages of the full THOR version over THOR Lite, there are a few more reasons to use the full version in this scenario:

  • Use multiple instances on a single source system to scan many different remote systems at the same time
  • Use virtual drive mapping to allow for additional detection opportunities
  • Set a custom host name that appears in the log files (helpful when you scan many different targets)

If you’re interested in the full version, contact us using the “Get Started” button in the upper right corner. 

Virustotal Lookups in THOR v10.7

We’re glad to announce a new feature that allows users to enrich events generated by THOR with information from Virustotal

The feature is available in the full THOR v10.7 TechPreview and THOR Lite.

It can be used in any scan mode: live endpoint scanning, lab scanning, dropzone mode, or even with THOR Thunderstorm. 

Virustotal Account

You can use it with a Virustotal Enterprise account or even a free account that requires registration. 

The free account limits the number of requests per minute, but since THOR only checks findings with a particular score, only a few files are checked. 

By default THOR skips the enrichment when the quota is exhausted. The flag “–vtwaitforquota” can be used to make him wait for more quota.

Command Line Flags

The following command line flags are available:

Two lookup modes are available:

  1. Limited = hash lookups only (default)
  2. Full = hash lookup or sample upload (if hash is unknown)

A typical command line using the new feature would look like this:

thor64.exe --vtaccepteula --vtkey fb2c3babb1796f97dcd0a877e05207294110bea8a9b93a933b...

Example Match with Virustotal Information

Use API key in Scan Templates

Remember that you can make use of scan templates to avoid exposing your secret API key in command line flags.

Extending Coverage

You may already know that THOR focuses on different types of threats and handles findings differently than Antivirus software. 

The additional Virustotal lookups allow us to:

  1. increase the level of a finding that THOR would otherwise have mentioned only as ‘noteworthy’ or not at all
  2. enrich the existing alert message with information found on Virustotal to confirm the finding

Inspiration

The new lookup feature allows for some exciting detection ideas, which combine YARA rule matching and Virustotal lookups. 

YARA as Preselector for Uploads

This idea could be helpful in the case in which you know that an actor makes use of compiled Go (Golang) binaries. You could write a YARA rule that detects all compiled Go binaries for the Windows platform, set a score of 40 (noteworthy) to let the new feature pick them up, and submit them to Virustotal for analysis. (remember that you can use the –customonly flag to only apply your custom YARA rules if needed)

Check New Files with Virustotal

Imagine that you want to check all new .aspx files dropped on an MS Exchange server. You could write a YARA rule that looks for certain contents or the file extensions .aspx and give that rule a score of 40. You could then run a THOR scan on MS Exchange server setting the –lookback flag with the number of days you want to include and instructing it to scan only the C:\inetpub folder. If you schedule this scan to run daily, you will let THOR find all .aspx files changed during the last 24 hours, scan them with its own rules and check them on Virustotal for a verdict of 60+ scan engines. It’s hard to imagine better coverage for web shells than this. 

The full command line would look like this:

thor64.exe --vtaccepteula --vtkey fb2c3babb1796f97dcd0a877e05207294110bea8a9b93a933b... --lookback 1 -p C:\inetpub

FAQs

Does a low Antivirus detection rate reduce the score of the THOR matches?

No, that wouldn’t be smart, as THOR focuses on other types of threats that Antivirus software often is unable to detect. However, positive Antivirus matches increase the score for a scanned file depending on the number of Antivirus engines with matches.

THOR adds the following sub-scores based on the lookup result:

  • more than 5 engines with matches > score 40
  • more than 10 engines with matches > score 60
  • more than 20 engines with matches > score 75

What happens when the quota for lookups per minute exceeds?

THOR will not add additional information to the printed event. By default, the lookups will not slow down the scan significantly. If you see too many notice or warning level messages in your environment, adjust the --vtscore value or filter out some known false positives using the false_positive_filters.cfg file.

Can I use this feature with the free THOR Lite version and a free Virustotal account?

Yes.

Which THOR modules trigger a Virustotal lookup?

Basically, only the ‘FileScan’ module uses the lookups. But since THOR also triggers a file scan on the image file during ‘ProcessCheck’, other modules also benefit. 

Where can I register a Virustotal account?

Visit this link to register a free account. 

How can I get THOR Lite?

You can download THOR Lite here

 

 

Get the full THOR version

Apart from the usual advantages of the full THOR version over THOR Lite, there are a few more reasons to use the full version in this scenario:

  • Much bigger number of so-called “threat hunting” rules with low scores that would trigger a Virustotal Lookup
  • Multi-threaded scanning significantly reduces the scan duration

If you’re interested in the full version, contact us using the “Get Started” button in the upper right corner. 

Antivirus Event Analysis Cheat Sheet v1.11.0

We’ve updated our Antivirus Event Analysis Cheat Sheet to version 1.11.0.

  • It includes updates in several sections
  • add special identifiers for other hack tools and ransomware (sync with Sigma rule changes provided by Arnim Rupp in PR #3919 and #3924)

You can download the new version here.

Tip: to always find the newest version of the cheat sheet, use this search query.

Changes:

Extended ProxyNotShell Detection Covering OWASSRF

In a report published on the 20th of December CrowdStrike published a report of a new technique exploiting the Microsoft Exchange vulnerability called ProxyNotShell. The called the new technique OWASSRF as it uses Outlook Web Access, CVE-2022-41080 and CVE-2022-41082 to achieve remote code execution (RCE). 
PaolAlto Networks’ Unit42 released their report one day later. 

Dray Agha's Tweet

The security researcher Dray Agha noticed the proof-of-concept (POC) in an unprotected open directory used by an unknown threat actor

CrowdStrike's Report on OWASSRF

The report contains information on the exploitation, log patterns and a script to detects possible exploitation attempts

Unit42's report on OWASSRF

PaloAlto Networks Unit42 also published a report that also contains information on observed TTPs and information on a PowerShell backdoor called SilverArrow

Signatures That Detect This Attack

Exploitation

YARA (public)

SIGMA (public)

Potential OWASSRF Exploitation Attempt – Proxy
UUID: 1ddf4596-1908-43c9-add2-1d2c2fcc4797

Potential OWASSRF Exploitation Attempt – Webserver
UUID: 181f49fa-0b21-4665-a98c-a57025ebb8c7

Post-Exploitation

SIGMA (Private)

Microsoft Exchange ProxyNotShell Exploit
UUID: df23d4fb-b12b-4425-a340-8d59e2460c43

Webshell Detection Suspicious Children
UUID: 9a8e8057-32a7-432d-bf80-197dacf1a77f

Shells Spawned by Web Servers in Process Tree
UUID: 6dc0f4e1-7a11-429f-b240-d9f852cea8b3

SIGMA (Public)

Suspicious File Drop by Exchange
UUID: 6b269392-9eba-40b5-acb6-55c882b20ba6

Shells Spawned by Web Servers
UUID: 8202070f-edeb-4d31-a010-a26c72ac5600

 

 

Mjolnir Security: Blue Team Incident Response Training

Our partner Mjolnir Security offers a training named “Blue Team Incident Response Training” from 19th of September to 23rd of September.

It’s 3,5 hours a day, starting 4:00 pm and finishing 7:30 pm Eastern time. Each session will be recorded, so you’ll also be able to catch up on anything you’ve missed.

On day 4 you’ll learn how to write YARA rules and use the full potential of the THOR scanner together with ASGARD Management Center, our centralized management platform for easy scan management, incident response features and much more.

An analysis of the findings with our Analysis Cockpit is demonstrated as well as part of the training.

It’s a great opportunity to see a combination of our enterprise grade tools working seamlessly together, allowing you to get hands-on experience and a clear picture of how a full deployment would look like.

As a THOR Lite subscriber you can get a 30% discount on the training. In order to benefit from this discount, use the following discount code on checkout: NextronThorLite

Or use the direct link: https://www.eventbrite.ca/e/393153361287/?discount=NextronThorLite

Existing Nextron customers can even get a 50% discount. Please contact us for details.
The training is free for law enforcement and government agencies. We provide a contact method for said agencies to benefit from this discount.

Registration URL: https://www.eventbrite.ca/e/blue-team-incident-response-training-tickets-393153361287

Training Organizer: training@mjolnirsecurity.com

THOR TechPreview 10.7.3 Features

THOR TechPreview version 10.7.3 has been released

  • Parsing of email formats .eml / .msg to scan the attachments (RFC-6532)
  • Archive scan improved to include .cab, .7z and .gzip
  • Archive scan improved to scan nested archives recursively
  • Bulk scanning improvements to further improve the scan speed
  • HTML report generation refactoring – much lower memory usage, lower CPU load during generation
  • Internal YARA rule set refactoring (using one big set and different name spaces to improve performance)
  • Internal refactoring to make use of a unified memory mapping of files to improve performance

The TechPreview version 10.7 can be downloaded from our customer portal or by using thor-util.

New Analysis Cockpit 3.5

New Baselining Views

Over the course of the last 18 months we reviewed most of our detections regarding their success in real world scenarios. In this context “success” means, that the detection uncovered malicious activity in the wild and at the same time had a low anomaly and false positive rate. Additionally we also consider a detection to be successful that caused little or no false positives or anomalies.

All this lead to two new views within the Cockpit’s Baselining section: “Compromise Assessment Mode” and “Deep Inspection Mode”.

“Compromise Assessment Mode” includes only matches of the highly successful rules. The second mode is the “Deep Inspection Mode”. This view is basically how it used to be (the old default view). It shows all Alerts and Warnings unless they are already part of an existing case.

This new “Compromise Assessment Mode” dramatically reduces our customer’s baselining effort.

In our tests we noticed a decrease of events in the Baselining section of more than 90%. We believe that especially entities that follow our “Continuous Compromise Assessment” approach should switch into this new mode. We’ve also challenged the new mode with the post exploitation tools and techniques found in the context of HAFNIUM / Exchange exploitations in March 2021 and covered almost every aspect of the attacks in the new view.

Asset Labels

Another exciting new feature that comes with Analysis Cockpit version 3.5 is an event filter based on asset labels. This was requested by many of our customers and partners, but until now we never found a way to deliver this feature without negatively affecting the Cockpit’s performance. We solved this now by allowing two limitations to this feature. It doesn’t work for events that existed prior to the update. Secondly an event always remains linked to the asset label it had at the time the event occurred. Changing an assets label will only affect events from scans that take place after the label change.

Other Changes

  • Hidden static filters in certain views
  • Minor bugfixes and stability improvements

Release

The new Analysis Cockpit will be released in the 2nd half of August. Interested customers can get a guide to use the “preprod” version of Analysis Cockpit 3.5. 

Product Surveys – Tell us what you think

We’d like to know your opinion on our products and therefore ask you to participate in our product surveys. Each of them takes between 2 and 5 minutes of your time, depending on how much you’d like to tell us.

THOR Customer Satisfaction Survey

You find the survey here.

ASGARD Customer Satisfaction Survey

You find the survey here.

Analysis Cockpit Customer Satisfaction Survey

You find the survey here.

Public Feature Collection

We also plan to publicly collect feature requests and allow you to up- or downvote requests of other users, comment on them and get informed when a feature has been implemented.

 

GDPR Cookie Consent with Real Cookie Banner