ASGARD 2.11 Release

We are glad to announce a new ASGARD Management Center (AMC) release with exciting new features and improvements.

Sigma LogWatcher

LogWatcher is a new service that applies Sigma rules to Windows Eventlog entries. It uses the big public Sigma rule base and has access to the upcoming private Sigma rule feed maintained by Nextron Systems. It’s the first additional service that can be managed and configured in the new “Service Control” section. (add the “Service Control” right to roles to enable the section for these roles)

Improved LDAP Support

The new LDAP configuration now supports all kinds of different selection options to authenticate against Microsoft Active Directory.

Improved IOC Management

The IOC Management moved into the Scan Control section and now allows you to import single or groups of IOCs in a special interface that abstracts from the underlying format required by THOR.

A ruleset contains IOC groups which contain IOCs. Integrated checks verify the provided expressions and give you direct feedback. 

Persistent Column Settings per User

Each user can now configure the table views in each section according to their needs, which persist across sessions.

Performance Improvements

The new version improves the performance of large installations (>10,000 endpoints) significantly. 

THOR and THOR TechPreview Support

It’s now possible to scan with all kinds of THOR version, the current stable version Tech Preview versions and even THOR Lite. 

 

Before you update:

  • the upgrade can take up to one hour in large installations, so please wait and do not reboot during the installation
  • the API has been completely revised so that old API endpoints that you currently use may not work anymore
  • to prevent an inconsistent state, you have to upgrade the Master ASGARD before upgrading the connected ASGARDs

More changes:

  • improved stability and error handling of THOR scans
  • extended CSV output and availability in many more sections
  • requirements for password complexity has been increased

TryHackMe Training Room for THOR Lite

Since THOR and THOR Lite are tools written for digital forensic experts, they can be difficult to use. There is often a steep learning curve in the beginning.

We’d like to help new users pass these first steps in a playful way by providing a TryHackMe challenge in which you analyse a compromised system using THOR Lite.

You’ll learn how to download and run it, interpret the results, write your own signatures and include your own IOCs for a custom threat. 

The room is meant for first time THOR or THOR Lite users.

Target Audience: DFIR professionals, administrators, security analysts
Duration: ~3 hours (without the download of the VM)

You’ll work with a prepared virtual machine that you’re required to download during the training.

Requirements:

  • VMWare or VirtualBox
  • 13 GB download and 23 GB of disk space
To access the TryHackMe room

  1. visit https://tryhackme.com
  2. create an account
  3. access the page “My Rooms”
  4. enter the room code “thorlite”, then “Enter room”

and start with the training lab.

Please help us and send your feedback to feedback@nextron-systems.com

THOR 10.6.11 with Support for Apple M1 Architecture

The newest version 10.6.11 of THOR for macOS now has support for Apple’s M1 platform. 

The THOR scanner binary is now a “universal” binary that runs on both supported platforms. 

You can find a list of supported architectures and operating systems in the respective chapter of the online documentation.

Silent Scanning – Compromise Assessment with THOR Lite on a Compromised Exchange 2019 Server

The following video shows a compromise assessment with our free THOR Lite scanner on a Microsoft Exchange 2019 server detecting ProxyShell and ProxyToken exploitation.

We’ve done no post-editing in this video. You can jump to all findings using the video chapters. You’ll see log entries, web shells and a modified IIS server configuration as reported by HuntressLabs in various reports. We added some Synth-wave tracks to create the right atmosphere. Enjoy.

By the way, we compiled a blog article regarding compromise assessments of Exchange servers with THOR Lite to detect ProxyLogon exploitation with some recommendations that still apply. You can find that blog post here

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

ASGARD Analysis Cockpit Version 3

ASGARD Analysis Cockpit is our on-premise soft-appliance that helps you analyze large amounts of THOR log data. The new version 3, which has just been released, adds many new usability features and views. This blog post lists some of the changes. 

Analysis Cockpit 3 has a new look with many features that improve usability.

Filtering the log data to select a group of events to include into a case has never been easier. The search bar has been modified to support the most common use cases with feedback from numerous analysts. 

The idea is to allow a user reach a certain intended view with as few clicks and interactions as possible. 

New case creation forms, which are much more compact and add a new event selection type named “condition”. 

It adds many views focussed on assets like scans of each asset or findings per asset.

Extensive reporting section and for HTML and PDF reports

It allows to create reports

  • by business unit
  • comparison between time frames and group scans
  • highlights on lateral movement
  • highlights on remediated systems

Two-Factor-Authentication (2FA, OTP) and improved LDAP support

A new “Notifications” sections allows you to review all triggered notifications that have been sent via SYSLOG, E-mail oder Webhook to a remote system.

These notifications are configured by the user and may include e.g.

  • New event added to incident case
  • Case type changed from “open” to “request evidence”

Other improvements:

  • Massive performance improvements
  • Improved API for SOAR, Sandbox, SIEM integration
  • Views for real-time events generated by ASGARD’s 2.10 new Eventlog watcher with Sigma rules
  • Provides additional endpoint related information like installed software and list of local users (Windows only)
  • Improved flexibility in case management section 
  • Sidebar with context information
  • CSV exports from almost any view
  • Direct Virustotal & Valhalla lookups from the event details

ASGARD Analysis Cockpit version 3 has been released this month. An upgrade from Analysis Cockpit version 2 is possible and includes an export of the case data and re-import of all previously indexed log data with the help of a guide that is part of the new online manual. New customers find the installer ISO in the “Downloads” section of the customer portal.

New Detection Rules for Exchange Exploitation Activity

Last week, we’ve released a blog post on how to detect HAFNIUM activity with the use of THOR Lite. Since our first set of rules, we’ve added several important new rules from fellow researchers and moved even more rules from our commercial set into the open source rule set.

This alone would be reason enough to recommend another scan. But during the last three days, we’ve added a special group of rules (see below) and fixed some bugs in the code base of THOR that could have lead to false negative on some of the relevant log files (exclusion under certain conditions).

We therefore recommend a signature update, an upgrade to THOR v10.5.12 (THOR TechPreview v10.6.4) and a new scan run to uncover traces of hacking activity using the newest detection rules.

The following sections explain the extended coverage.

Compiled ASPX Files

We’ve added rules for the compiled ASPX files that often remain on a system even in cases in which an attacker has removed the original web shell.

These are perfect rules to uncover actual post-exploitation attacker activity and not “just an exploitation” and a webshell drop.

You can find more information on the creation and meaning of these forensic artefacts in this Trustwave blog post.

(Source: Trustwave)

Improved Generic Webshell Coverage

Arnim Rupp provided many improvements to its public rule set that detect all kinds of webshells based on generic characteristcs. 

Frequent updates improved these rules and extended the coverage to include the newest unknown webshells mentioned in the most recent reports. 

More Filename IOCs

Over the last few days we’ve added many new filename IOCs mentioned in reports by ESET and others. 

The ESET report mentions and lists IOCs of 10 different APT groups exploiting the Exchange vulnerbility and leaving traces on compromised systems.

Rule Improvements

We’ve improved several rules to extend their coverage.

E.g. the rule that looked for POST requests to a single letter JavaScript file now looks for a certain pattern that includes exploitation attempts with the new Metasploit module.

Due to all the mentioned improvements and bugfixes, we recommend another scan run on your Exchange servers. The following commands upgrade THOR and its signature set.

THOR
thor-util.exe upgrade

THOR Lite
thor-lite-util.exe upgrade

Remember these recommendations from the initial blog post:

  • If you’ve installed Exchange on a drive other than C: use `–allhds`
  • Use `–sigma` feature when scanning with THOR (not available in THOR Lite)
  • Add the following exclusion to the file `./config/directory-excludes.cfg` to skip all mailbox directories:

\\(MDBDATA|Mailbox|Mailbox Database)\\

Which extra value provides THOR in Exchange ProxyLogon related assessments?

Since we’ve decided to migrate many of the HAFNIUM / Exchange vulnerability related signatures into the open source signature database of our free scanner THOR Lite, both users of the free and the commercial version started asking questions of coverage and if a scan of the respective other version is still recommended.

This blog post tries to shed some light on the issue by pointing out the differences between both scanners regarding coverage, scan intensity and availability of signatures.

The obvious advantage of THOR Lite – which is usually one of the disadvantages – is the immediate availability of untested new YARA signatures. While users usually prefer tested signatures that won’t cause hundreds or thousands of false positives, in case of the ProxyLogon vulnerability, new releases of rules cannot be fast enough.

So the obvious and only advantage of THOR Lite is that it receives rule updates multiple times a day, while THOR currently gets new signatures every 1-2 days.

The signature release schedule is as follows: 

  • THOR Lite (untested): on every commit in the repository
  • VALHALLA (goodware tested): once per day
  • THOR (goodware tested, full CI tests on 20+ operating systems): currently every 1-2 days, normally 1 per week

A good example of a rule that caused several false positives and, as a consequence, some trouble is an experimental rule named APT_fnv1a_plus_extra_XOR_in_x64_experimental, which even triggered on files from the Microsoft software catalogue.

It has never been quality tested and has only been in the community signature set used in THOR Lite.

Since we just extend our coverage with every new signature, users who use the ruleset released on Monday the 8th should at least see all different types of exploitation attempts, successful or unsuccessful. They also see many types of web shells, old and new, tools like PowerCat and Nishangs PowerShell one-liner as well as LSASS process memory dumps and other more generic indicators.

So both scanners provide a reasonable coverage and should indicate a successful attack.

THOR may not have the newest signatures, but it provides the bigger rule set with many generic signatures for all kinds of malicious activity, including post-exploitation activity. The following list tries to cover the advantages of a THOR scan in contrast to a THOR Lite scan.

Undisclosed Signatures

We have included many rules in the open source signature set that we use for LOKI and THOR Lite, but not all of them. As stated in a previous post, we have kept some of the more elaborate ones secret to avoid attackers evading the detection in future attacks. 

These rules include detection for specific forensic evidence that is often still present on a once compromised system even when the attackers have already removed the previously dropped web shells. 

This rule e.g. looks for compiled DLLs that we believe are generated once a dropped web shell gets executed at least once and often resides on a compromised system after the attackers removed their tools, data and web shells.  

They are usually not detected by Antivirus software and proved to be a good indicator for a successful compromise and actual malicious activity. 

More Modules, Better Coverage

As you can see in the scanner comparison table, the full THOR version provides many different modules in which it scans different elements of an operating system to discover traces of hacking activity. 

We apply many different IOCs like filename patterns, hash values and keywords in these modules to provide the best possible coverage. Find more information on THOR’s IOC scanning in this blog post. 

In regards to the HAFNIUM and ProxyLogon activity, we’ve seen enterprise customers with additional findings in

  • the Eventlog (Sigma scanning) and
  • Scheduled Task module

Other modules that could reveal HAFNIUM activity and are not available in THOR Lite are: MFT, ShimCache, Registry

Better Overall Coverage

The following graph aims to visualise the coverage differences of both scanners only in relation to the HAFNIUM / ProxyLogon activity. In all other cases, the coverage provided by THOR is much higher, since it uses a signature database with more than 14,000 YARA rules and applies these signatures in more than 20 different modules. 

As you can see, especially payloads/evidence used the “delivery” and “exploitation” phase are covered very well by both scanners, but THOR is much better when it comes to detecting post exploitation activity and backdoors or activity other than the described HAFNIUM group activity.

ESET has just recently published a report in which it mentions activity of more than 10 different APT groups.

As this vulnerability attracts more and more threat groups, it gets more and more important to cover as many shells, tools and techniques as possible and widen the view for other actors.  

We continue to provide IOCs and signatures regarding that threat in both scanners and also merge rules provided by community members as quickly as possible. 

THOR Seed v0.18 Improves Integration with Microsoft Defender ATP

A new version of THOR Seed improves the integration with Microsoft Defender ATP by handling the script termination caused by exceeded timeouts. Due to a runtime limit for all scripts in the Live Response library we had to configure previous versions of THOR Seed to perform a reduced scan that tried to finish within that runtime limit.

This lead to two major issues:

  • Only a reduced set of modules could be activate and a limited set of elements could be scanned
  • Some script runs were terminated before completion

THOR Seed version 0.18 is now able to handle this situation and provides guidance on how to proceed. 

While resolving this issue we noticed that only the script run gets terminated but not the sub process, which is the actual THOR scan. So, the execution of “thor-seed.ps” gets interrupted but the sub process “thor64.exe” keeps on running in the background. 

After a terminated script run, you can now simply “run thor-seed.ps1” a second time and get the info that the THOR process in the background is still running. 

It includes the location of the log file and shows the last 3 lines of that file so that you can review the scan progress. 

After the scan has been completed, THOR Seed shows a message that it cannot start a new scan until the log files and HTML reports have been reviewed and removed from the system. 

It includes all necessary commands for you to just copy, paste and execute them.

A new guide explains all the steps and describes the integration in more detail. 

The release version can be found here.

Please contact us for a current version of that document in case you encounter any issues due to outdated information. 

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. 

GDPR Cookie Consent with Real Cookie Banner