ASGARD: Check your Signature Versions

It came to our attention that under certain circumstances, after the upgrade to ASGARD 2.11, some ASGARD instances lost their scheduled task to automatically assign the newest signatures to scan jobs . We advice customers to review their update configuration if they are affected. Go to Updates > Scanners and Signatures. If you are affected the column ‘Automatically use newest version’ shows ‘not configured’.

In order to resolve this issue, you need to schedule a time for signature updates. Use the action button with the clock icon. We recommend an interval of 1 day (see the screenshot).

After you have entered the new schedule, you should see the configured date and interval in the “Automatically use newest revision” column.

The same mechanism is used to configure when new THOR versions should be used for scans. We recommend to use the default, which is also a daily update interval.

Nextron Products Unaffected by Log4j Vulnerability CVE-2021-44228

We have reviewed our products in order to identify services that use the vulnerable log4j library. Only Elastic Search in ASGARD Analysis Cockpit uses log4j but is NOT vulnerable. 

“Elasticsearch is not susceptible to remote code execution with this vulnerability due to our use of the Java Security Manager. Elasticsearch on JDK8 or below is susceptible to an information leak via DNS which is fixed by a simple JVM property change.”

Source: https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476

Even older and EOL products like ASGARD v1 are not affected.

Other products don’t use JAVA or log4j.

Visit the New Online Manuals

We’ve converted all our PDF based user manuals into shiny new online versions.

The new online versions are hosted on Github and converted into web pages with the help of ReadTheDocs. 

This way we can update them with new information much faster than before and allow anyone to share and access them. 

 

 

We’ve added links to the user manuals to every product page and the footer of this website. The links in the customer portal have also been updated.

You can find the new manuals here:

We’ll replace the PDF manuals in the installation packages as soon as possible. Please let us know if you can still find outdated manuals anywhere in new update or download packages.

End-of-Life ASGARD Analysis Cockpit Version 2

Nextron announces the end-of-sale and end-of-life dates for the ASGARD Analysis Cockpit version 2. Customers with active service contracts will continue to receive support until June 30, 2022, as shown in the table below.

End of Life Announcement Date The date the document that announces the end-of-sale and end-of-life of a product is distributed to the general public. 06.05.2021
End of Sale Date The product is no longer for sale after this date. 30.04.2021
End of Software Maintenance The last date that Nextron may release any final software maintenance releases or bug fixes. After this date, Nextron will no longer develop, repair, maintain, or test the product software. 31.05.2022
Last Date of Support The last date to receive applicable service and support for the product as entitled by active service contracts or by warranty terms and conditions. After this date, all support services for the product are unavailable, and the product becomes obsolete. 30.06.2022

THOR Process Memory Matches with Surrounding Strings

Following THOR’s approach of showing suspicious elements, it is not feasible to completely avoid false positives. Therefore we always try to provide as much information as possible for an analyst to assess such a suspicious element as quickly as possible.

Users liked the DeeDive feature in which a string match on a chunk of data does not only include the matching string but also the surrounding strings, which help enormously to evaluate the criticality of a matching YARA signature. 

The TechPreview version of THOR 10.6 now introduces this extra information in many other modules. 

The following example shows a false positive in which the string ‘ -p 0x53A4C60B’ matched on the process memory of the ‘svchost.exe’ process with the full command line as ‘svchost.exe -k ClipboardSvcGroup -p’.   

In previous versions THOR you would only see the matching string, but the new versions will also show the 40 bytes before and after the string match. (in the example it has been set to 100 bytes by using `–string-context 100`)

This helps analysts to assess the match more easily without having a process memory dump. In the example above, analyst can review that data block in which the string match occurred and see that it has been within HTML text that has been copied to memory. It could be an analyst system on which someone handling forensic reports copied sections from one document to another, but it’s certainly not the threat, which the YARA rule tried to detect. 

This feature will be available in the upcoming THOR TechPreview 10.6.4. 

VALHALLA API 1.1 Changes

We’ve made some changes to VALHALLA and released version 1.1 and valhallAPI version 0.5 to reflect these changes.

The new modified date shows when this rule has last been modified. 

See this example.

The modified date will also appear in the JSON feed and metadata of the text feed.

Rules now contain a “hash1” value, which is one of the samples from which it has been derived.

The API offers two new endpoints named “keyword” and “keyword-matches”, which allow two new lookups. (customers only)

The “keyword” lookup is not very spectacular and simply returns a list of rule meta data based on a certain keyword. 

However, the “keyword-matches” endpoint adds a new vector. It combines a keyword lookup on the rules with a lookup on matches created by these rules. 

E.g. by providing the keyword “Turla”, you get a list of sample hashes on which Turla related rules matched in the past.

The new valhallaAPI client and Python module in version 0.5 allow to use these features.

You can upgrade your current version with

pip3 install valhallaAPI --upgrade

Sigma Scanning with THOR

Our compromise assessment scanner THOR is able to apply Sigma rules during the local Eventlog analysis. This can help any customer that has no central SIEM system or performs a live forensic analysis on a system group that does not report to central monitoring. 

By running THOR on these systems with activated Sigma feature, THOR becomes a kind of a distributed and portable SIEM.

Since the Sigma scan module isn’t active by default, we thought it a good idea to explain how to activate an use it in the best possible way. 

Open Source Rule Set

By default THOR uses the open-source Sigma rule set with more than 500+ rules provided by the Sigma project on their Github page

Since our head of research is also one of the project maintainers, it was reasonable to combine the detection capabilities of Sigma with THOR’s scanning functionality on the endpoint. 

We comply with Sigma’s DRL (Detection Rule License) by including the rule authors in the event data produced by these rules.  

Custom Sigma Rules

You can easily add you own Sigma rules by placing them in the “./custom-signatures/sigma” sub folder.

THOR’s Sigma Config

The THOR default configuration for Sigma can be found in the Sigma repository. 

This configuration shows you, which Windows Eventlogs and Linux/Unix log files get analyzed by the Sigma module in THOR.

 

Sigma Scanning

To activate the Sigma module simply use the “–sigma” flag (or “sigma: True” in a YML config file).

You can start a THOR scan that analyzes the local Eventlog and activates the Sigma feature with:

thor64.exe -a Eventlog --sigma

To run a Sigma scan on a single Eventlog e.g. Sysmon’s log, use the “-n” flag.

thor64.exe -a Eventlog --sigma -n "Microsoft-Windows-Sysmon/Operational"

To include the Sigma feature in a standard THOR scan and check only the last 3 days of the Windows Eventlogs to reduce the scan duration, use:

thor64.exe --sigma -lookback 3

Sigma Matches

Once a Sigma rule matches on a log entry, you’ll see it listed in one of the REASON’s that lead to the classification of an event. 

The following example shows the detection of a China Chopper (Caidao) ASP web shell. That web shell has been detected by multiple Sigma rules. 

  1. Webshell Detection With Command Line Keywords 
  2. Shells Spawned by Web Servers
  3. Whoami Execution

Getting Started

Since this feature isn’t available in THOR Lite, please contact us via the “Get Started” button in the upper right corner and get a free trial voucher. Most customers that use THOR with Sigma choose one of our THOR license packs, especially the SOC Toolkit Pack, which was geared to the needs of today’s SOC teams. 

Upcoming Master ASGARD v2

In the first week of June, we plan to release Master ASGARD v2.

Master ASGARD is an ASGARD version that is able to connect to and control an unlimited number of ASGARD servers.

While each ASGARD supports 25,000 connected endpoints, a Master ASGARD server can control an theoretically unlimited amount of ASGARD servers and thus an unlimited amount of end systems. We plan to support installations with up to 500,000 end systems until we get confirming performance and system load statistics from our customers’ setups.

With Master ASGARD v2 we will also change the way in which you install Master ASGARD.

From now on the ASGARD platform can be upgraded to a Master ASGARD by the installation of special license. You simply upgrade an already installed ASGARD to a Master ASGARD.

Master ASGARD 2 features

  • MISP integration and IOCs triage scans on all connected endpoints
  • Remote Console on all connected endpoints
  • Playbook runs on all connected endpoints
  • Evidence collection from all connected endpoints
  • License management for all connected ASGARDs
  • Key material backup of all connected ASGARDs
  • THOR version management of all connected ASGARDs

Master ASGARD 2 does not support

  • direct upgrade from Master ASGARD version 1
  • the control of ASGARDs running on version 1

Please contact sales@nextron-systems.com for more information on Master ASGARD v2.

 

THOR Lite – Free YARA and IOC Scanner

THOR Lite – Free YARA and IOC Scanner

We are proud to announce the release of THOR Lite. It is a trimmed-down version of THOR v10 with a reduced feature set and the open source signature base used in LOKI and the now obsolete scanner SPARK Core.

It uses the completely rewritten code base of THOR v10 “Fusion” and is therefore faster, more thorough and stable than SPARK.

 

As you can see in the table below, we’ve come a long way since 2012. We’ve phased out the old THOR version based on Python and SPARK in 2019. Today, we’re replacing the community version of SPARK named SPARK Core with a community version of THOR v10, named THOR Lite. 

There are two main differences between THOR Lite and THOR: 

  1. Reduced feature set
  2. Open source signature base

Apart from that, you’ll get a fully maintained and tested scanner pre-compiled for the Windows, Linux and macOS platform. A limited support is available via the issues section on the github page for auxiliary scripts.

Upgrading from SPARK Core

There is no direct upgrade path from SPARK Core, since SPARK Core and THOR Lite are completely different products and have different upgrade paths.

New users have to subscribe to the newsletter to get download links and a free license. You can subscribe and download THOR Lite using the link on the product page

SPARK Core users that already have a valid license can use the following download links to download THOR Lite:

THOR Lite for Windows
THOR Lite for Linux
THOR Lite for macOS

Important: These download packages do not include a license. You need to subscribe on the product page to receive a valid license OR use your existing SPARK Core license with THOR Lite. 

Issues

Please report problems in the issues section of THOR Lite’s helper scripts github page

GDPR Cookie Consent with Real Cookie Banner