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.

THOR Log Conversion to CSV

THOR Log Conversion to CSV

We are excited to announce that the upcoming version 1.11 our tool, THOR Util, now has the capability to convert log output files from both the default and JSON format into CSV files. This new feature will make it easier for users to analyze their log data and extract the information they need.

With the ability to convert log files into CSV, users can now import their log data into their favorite spreadsheet software and manipulate it to create custom reports and visualizations.

This will save time and increase productivity, as users will no longer need to manually parse and extract data from their log files.

We recommend taking a look at Modern CSV as alternative to Microsoft Excel for this kind of task.

 

THOR Util has many more functions to post-process THOR logs, and this new feature further expands its capabilities.

E.g. Did you know that you can use the “report” function to generate a single combined HTML report for a set of log files from different end systems?

You can find more information on THOR Util and its features here.

Users registered as beta testers can already test the functionality available in the nightly unstable builds of THOR 10.7 TechPreview and THOR Lite.

The release is planned for calendar week 11, 2023.

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. 

Sigma Rule Feed in Valhalla

Nextron Systems has always supported the Sigma project, investing hundreds of work hours into creating and maintaining the community rules shared in the public Sigma rule repository. Apart from the community support, we’ve created a set of internal detection rules for our products, THOR and Aurora, that we kept confidential for various reasons and didn’t share publicly.

Today we are glad to announce that we’ve started feeding these rules into the Valhalla service.

Similarly to the YARA feed, we’ve integrated all types of Sigma rules, publicly shared and private rules.

Using the “demo” API key, you can retrieve all public rules in a structured form from Valhalla.

The private Sigma rule feed contains 190 Sigma rules at the date of this blog post and is expected to grow by 600 rules every year. The following table from the front page of the Valhalla web service shows the different categories and the number of rules per category.

The Sigma rules can be retrieved in plain text or JSON format.

The JSON format allows users to filter or select based on certain values without parsing the rules, e.g., “only select rules that have been modified in the last 7 days”. 

Getting started

We offer the Sigma feed subscription independently of the YARA rule subscription at a much lower price. If you’re interested, please get in touch with your sales representative for pricing information or fill out this form.

 

ASGARD 2.14 Release

We’ve just released the new ASGARD Management Center version 2.14 with important new features. This blog posts lists the most important changes in dedicated chapters. The whole change log can be found at the end of the article. 

Broker Network

The Broker Network allows you to proxy connections to an ASGARD through a so called Broker.

The Broker is a hardened connection proxy that brokers connections to an ASGARD Management Center. Brokers can be exposed to the Internet and allow users to roam between the corporate network and their home network without the need for a permanent VPN connection. They can also load balance connections. 

Two more components are required to maintain a Broker Network: a Gatekeeper and a Lobby.

The Gatekeeper is an application layer firewall that filters malformed or unverifiable requests. The Lobby is a dedicated system to manage and accept new request from yet unverified agents.

The use of the new Broker Network and its components is optional and requires a so-called “Broker License”. Please contact us for more details.

ASGARD Query Language

The new ASGARD query language allows to filter the list of assets based on complex conditions.

It can also be used to select targets for scans or other tasks. 

Advanced Target Selection

Currently, the target selection only allows the selection of target groups based on their label. All target groups are combined with a logical OR. 

The new target selection allows you to include and exclude groups of assets based on their tags. 

E.g., you can now create a job that runs on all systems with the tag “linux” and exclude all systems with the tag “munich”. You can also combine them with a logical AND and instruct ASGARD to run tasks only on systems that have e.g. the labels “windows” AND “berlin”.

The result of this change is that you no longer need to label everything you want to select as target.

New Maintenance Tasks

New predefined tasks allow you to reconfigure or move an agent from one ASGARD Management Center to another one. 

 

Other Important Changes and Improvements

  • Repeated installation of ASGARD agents will not cause duplicate assets
  • Manual deletion of assets from Asset View
  • Multiple UI improvements
  • The new ASGARD agent will not send his agent log via syslog by default anymore. This has to be enabled individually.

Full Change Log

  • Feature: Broker Network support
  • Feature: Search and select assets with queries, e.g. ‘hostname ends with “-dev” OR labels = “dev”‘
  • Feature: Optionally create group tasks with an asset query instead of labels
  • Feature: The agent config can now be maintained from ASGARD, e.g. change proxy settings
  • Feature: Move agent to a different ASGARD
  • Feature: Automatically resume THOR scans that have been terminated due to shutdown signals (e.g. on reboot)
  • Feature: Added a lot new ASGARD features to Master ASGARD, e.g. manage and download agent installers, manage Broker Network
  • Feature: Allows to delete assets
  • Feature: Delete agent installers
  • Feature: Added diagnostic checks to diagnostic download packs
  • Feature: Support unix filepath format in playbooks for Windows targets
  • Feature: Detect assets that run with same key material, e.g. cloned assets
  • Feature: Forward THOR and Aurora events via rsyslog
  • Feature: Migrate key material from old agent config on agent re-installation
  • Feature: Added more columns in some tables, e.g. ‘creator’ in service configurations or ‘active since’ in services
  • Feature: Download ASGARD users as CSV
  • Feature: Set description for remote consoles
  • Feature: New default playbook “Collect Agent Log” (requires an agent update)
  • Feature: Bulk task / scan creation
  • Change: Require min. TLS 1.3 for all agent connections. To disable min. TLS 1.3, set “LegacyTLS=1” in the ASGARD config file.
  • Change: Disable “Add and activate” button for “Add group task”, if “Scheduled start” is set
  • Change: Allow “–nohtml” flag for THOR
  • Change: Set scan status to error if THOR scan result does not contain ‘THOR scan finished’ message
  • Change: Collect stdout/stderr at the end of each playbook step instead of streaming it directly to ASGARD
  • Change: Automatically set THOR’s max runtime to unlimited and removed THOR’s max runtime argument from THOR flag list
  • Change: Ignore deprecated sigma rules
  • Change: Improved compression level of some generated zip files
  • Change: Allow stop of group tasks without starting it
  • Change: Improved diagnostics for synchronization with Analysis Cockpit
  • Change: Disabled syslog debug log on agents by default, added option to agent installer to enable syslog
  • Change: Added key usage and SAN to self-signed TLS certificate for UI on installation
  • Bugfix: Security fixes
  • Bugfix: Fixed missing ‘Default response mode’ in Sigma ruleset details
  • Bugfix: Fixed some missing Aurora flags
  • Bugfix: Fixed non-working save button for global Sigma false positive filter list
  • Bugfix: Fixed NaN when removing the score of an IOC
  • Bugfix: Fixed a bug in event caching in offline mode of Aurora Agent and LogWatcher
  • Bugfix: Fixed ‘Windows 11’ detected as ‘Windows 10’
  • Bugfix: Fixed missing LastLogon date in local users table
  • Bugfix: Disable deletion of the own user
  • Bugfix: Added “x86_64” in addition to “amd64” for agent installer rpm packages to support older yum/rpm
  • Bugfix: Fixed wrong YARA rule count after uploading YARA rules
  • Bugfix: Fixed “in a few seconds” last seen timestamps that have been caused by either a wrong server or browser clock
  • Bugfix: Removed some Aurora and Sigma error messages in ASGARD log after fresh installation
  • Bugfix: Removed a race condition between automatic and manual update checks that may cause corrupt product version numbers
  • Bugfix: Fixed missing “enabled/disabled service” history entries on ASGARDs that are connected to a Master ASGARD
  • Bugfix: Fixed corrupt network interfaces search in asset table for new assets that had no interrogate job yet
  • Bugfix: Fixed a bug in motd config that causes some error messages after a fresh installation
  • Bugfix: Removed c2 file name prefix from some compiled custom signatures
  • Bugfix: Fixed non-working obfuscated agent for AIX

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

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. 

Follina CVE-2022-30190 Detection with THOR and Aurora

The Follina 0day vulnerability (CVE-2022-30190) in Microsoft Windows is actively exploited in-the-wild and highly critical. This blog posts lists some important web resources and the signatures that detect exploitation attempts.

Kevin Beaumont's Blog Post

Kevin’s post contains links to tweets of researchers that discovered the 0day exploit, information on the timeline, and mitigations

Huntress Labs Blog Post

Explains the exploit in more detail

Counter Measures

Recommended counter measures by Benjamin Deplhy

Signatures Detecting Follina / CVE-2022-30190 Attacks

Check for matches with the following rules:

YARA

Rules shared in the public signature-base and used in THOR and THOR Lite

Only available in THOR

Sigma

Public Sigma rules used in Aurora, THOR and Aurora Lite

Private Sigma rules only available in Aurora

  • Sdiagnhost Loading System.Management.Automation.dll – 1a4a0e9c-e47d-492c-800f-545f83fac88a
  • Sdiagnhost Calling Suspicious Descendant Process – 8655fa4b-e956-4ed4-b20d-151dfd8c802d
GDPR Cookie Consent with Real Cookie Banner