New Detection Rules for Exchange Exploitation Activity

Mar 18, 2021 | Alert, Newsletter, THOR, THOR Lite

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?

Mar 12, 2021 | Newsletter, THOR, THOR Lite

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.  

APT_MAL_ASP_DLL_HAFNIUM_Mar21_1
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

Feb 3, 2021 | Newsletter, THOR, THOR Cloud

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

Jan 6, 2021 | Newsletter, Nextron, THOR, THOR Lite

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. 

New Features: Progress Bar and HTML Report Filter Functions

Dec 23, 2020 | Newsletter, THOR, THOR Lite

We would like to inform you about three new comfort features that will be available in the upcoming THOR versions including THOR Lite. 

Improved HTML Reports

The new HTML reports allow analysts to filter elements that turn out to be false positives and remove them from the current view. It also adds useful lookup functions for Virustotal, RiskIQ and VALHALLA. 

Filter and remove false positives in your analysis

Apply filters directly from the modules menu and reduce the events to events from module X only

Direct lookups on Virustotal, RiskIQ and VALHALLA right from the report

The new report functions will be available in the upcoming THOR v10.5.10 and THOR TechPreview v10.6.3, which will be released in January 2021. 

Smart Progress Bar

Due to ongoing demand, we’ve added a progress bar to all longer running modules and a progress indicator to all the other modules. So far, we’ve avoided adding a progress bar or any kind of command line output that works with control characters to reduce the risks of side effects caused by THOR running in non-interactive sessions, e.g. with Splunk Forwarders’ scripted input. 

But THOR version 10 is able to determine if it is running in an interactive session and enables the progress bar only in these cases.

Progress bar in “Filescan” module

Progress bar in “Eventlog” module

New Option in Interrupt Menu

Another feature to highlight is the option to skip a module that doesn’t finish or seems to be stalled. 

The interrupt menu (CTRL+C) offers another option (X) to skip the current module and continue with the next one.

Performance Refactoring in THOR v10.5.9 and THOR TechPreview v10.6.2

Dec 19, 2020 | Newsletter, THOR

We are glad to announce significant performance improvements in the latest versions of THOR.

We’ve refactored several processing units to bulk scan elements that have previously been checked each at a time. These changes affect the modules “Eventlog”, “Registry”, “RegistryHive” and “Logscan”. 

The performance improvements are impressive, especially on systems with big Windows event logs or log files on disk, but also on systems that contain a lot of registry hives like domain controllers or multi-user systems. 

As these changes result in significant speed benefits, we’ve decided to exclude some elements from the “max-file-size” limit.

In the past, log files or registry hives bigger than “max-file-size” (default 12MB) have been skipped in normal scan modes. Only in intense (–intense) and lab scanning mode (–fsonly / –lab in TechPreview) these files have been included and analyzed with the respective modules.

THOR v10.5.9 and THOR v10.6.2 TechPreview now include these elements in their deeper analysis during file system scans. This could lead to longer scan times in some cases. We believe that overall scans turn out to be suprisingly faster and would be interested in feedback on the scan durations in your environments. 

THOR 10 Legacy for Windows XP and Windows 2003

Dec 17, 2020 | Newsletter, THOR, YARA

We’ve been working on a legacy version of our scanner THOR 10 for a while and started our closed BETA, which is available to all current customers on special request.

The THOR legacy version does not include the following modules/features:

  • Module: Eventlog scanning
  • Feature: Deeper process analysis for injection, Doppelgaenging, hollowing etc. using PE-Sieve

THOR Legacy runs on:

  • Windows XP x86
  • Windows Server 2003 x86 / x64
  • Windows Vista x86 / x64
  • Windows Server 2008 x64

We offer only limited support for this version and don’t plan to release it for old Linux or macOS versions.

THOR 10 Legacy on Windows Server 2003

THOR 10 Legacy on Windows XP

Please contact us if you are interested in participating in the closed BETA. 

THOR Forensic Lab License Features

Nov 11, 2020 | Newsletter, THOR

THOR version 10.6, which is currently available as TechPreview, introduces several new features that facilitates the use of THOR in a digital forensics lab. Since not all of the features provided with the “Forensic Lab” license type are well-known, we would like to introduce all features that are unique to that special license type in this blog post.

Forensic Lab License Features

  • Multi-threaded scanning (improves scan speed significantly on multi-core systems)
  • Multi-instance scanning (run multiple THOR processes on a single machine)
  • Memory dump scanning (use the so-called DeepDive on dumped data, e.g. memory images)
  • Dropzone mode (monitor folder for new files, scan them and generate events) 
  • Hostname replacement (replace hostname in log messages with a given string)
  • Virtual drive mapping (Map a mounted drive e.g. S: to a virtual drive e.g. C: to allow lookups for files mentioned in analyzed entries; more info here)

Multi-Threaded Scanning

Multi-threaded scanning allows users on forensic workstations to make full use of the system’s CPU cores. Multi-threading isn’t available in all modules but the ones with the biggest run time: 

  • File Scan
  • Registry Scan
  • Eventlog Scan

It is also available in DropZone mode, which means that dropping dropping 12 files in the monitored folder would create 12 threads scanning these files in parallel. 

We plan to refactor the following modules to support multi-threading:

  • DeepDive

Multi-Instance Scanning

Multi-instance scanning means that you can start multiple executables of THOR on a single workstation.

This is often needed in lab environments to process mounted disk images in parallel and create separate reports for these two cases. 

Memory Image Scanning

We provide a module named “DeepDive” that analyzes files of any size by reading big chunks of data and applying YARA rules to the chunks of data, showing YARA matches within that data with offset and matching strings / bytes. 

It is not meant for the analysis of disk images but memory dumps, crash dumps or even PCAP files.  

Dropzone Mode

The drop zone mode allows you to monitor a given folder for new files. All files dropped to that folder will be scanned and then deleted. Customers use  text and syslog output to report back findings.

The drop zone mode helps you to integrate THOR in a bigger analysis environment. We recommend dropping files in their original form with the correct filename and extension, since some of the rules make use of these meta data values.

Side note: If you like the idea of a drop zone, you’ll love THOR Thunderstorm.

Other Comfort Features

Other features relate to command line parameters that help you with different aspects of disk image scanning your forensic lab. We’ve added these features over the years based on a lot for feedback from DFIR specialists and BETA program users. 

There’s a Thunderstorm Coming

Oct 1, 2020 | Newsletter, THOR, Thunderstorm, YARA

We are proud to announce a groundbreaking new scan mode named “Thunderstorm” that we’ve integrated into preview builds of the upcoming THOR version 10.6.

This mode of operation turns THOR into a RESTful web service that is able to process thousands of samples per minute sent from any device within the network.

Think of it as your ultra-fast on-premise scan service, wich is bundled with more than 13,000 hand-crafted YARA rules focusing on persistent threats and forensic artefacts.

Collect files and submit them for analysis from any operating system and any hardware platform. The possibilities are limitless.

With this blog post, we’d like to highlight some of these new possibilities.

Thunder rolls, lightning strikes & the hammer flies across the sky.
God of the weather,
chariot of the storm,
master of rain & torrents.
Son of the strength
of Mother Earth,
I ask you to grant me that strength for myself.

Norse Poem

What is THOR Thunderstorm?

A RESTful web service that receives samples and returns a scan result. It is feature-rich and very fast.

Use Cases

Use Case 1 – Remote File Collection

During forensic investigations, automated file collection (ESI) from one or multiple remote systems can be combined with THOR Thunderstorm to improve the forensic anylsis.

Alerts and warnings produced by THOR Thunderstorm highlight interesting elements in file data, registry hives, eventlog files and more.

Use Case 2 – ICS Networks

ICS networks are mission critical, requiring immediate and high-availability. The installation of an endpoint agent or running a portable scanner is often out of question.

With THOR Thunderstorm, you just have to collect and submit the files.

Use Case 3 – Out of Reach Devices

Since file collection is a lot easier than endpoint scanning, all you need is way to export the remote system’s files or directly send them to THOR Thunderstorm.

Imagine that you can collect and submit files from network devices, telephone systems or embedded devices.

Use Case 4 – Out of Reach Operating Systems

File collection scripts for many old or usually unsupported operating systems allow you to upload samples for analysis.

Select files based on size, age or type and schedule frequent upload tasks to analyze only new or modified files. 

Use Case 5 – S3 Bucket Scanning

We’ve been working with our partner Adolus to showcase a tuned version of AirBnb’s BinaryAlert in which the standard YARA analyzer has been replaced by THOR Thunderstorm.

By using it in a container that scales with the demand, you can process millions of files in a few minutes.

Flexibility

Most operating system provide tools to walk the file system and submit files via HTTP. The following examples are intentionally short and compact to inspire you with their simplicity. Think of all devices that you could analyze this way. No agent, no portable scanner, just simple file submission via HTTP.

Windows 10 Batch

This example shows a simple batch file that walks recursively over a given folder an submits all files. You could extend it to the whole disk and reduce the submission to certain file extensions (e.g. exe, bat, ps1, js).

Linux Web Server

This examples shows how easy it is to get all files in a web server root checked by THOR Thunderstorm just by using bash, find and curl.

 

Thunderstorm Components

The following slide lists the different components that can be used with THOR Thunderstorm. We provide a server installer script, collectors, a Python API client and update scripts. 

In addition to the Thunderstorm server we provide a set of simple sample collection tools called Thunderstorm Collectors, a Python-based API library with command line client and a set of helper scripts. 

Thunderstorm Collectors

The Thunderstorm Collector repository contains a Go based collector, precompiled for many different operating systems and architectures as well as collectors scripts (Batch, Bash, PowerShell).

We have pre-build collectors for Windows, Linux, macOS, AIX, Solaris on x86, x64, Arm, PowerPC, MIPS, RISC-V, Plan9, S390x (IBM Z) architectures.

These collectors allow you select files based on age, size and type for submission to a Thunderstorm server.

It is easy to set up a task like: 

“Select all files that have been created or modified within the last 24 hours and submit them to Thunderstorm for analysis. Run this task daily.”

Low CPU and RAM Usage

A collection task requires 0.75-2% of the CPU and 20MB memory. 

Any OS, Any Arch

Our collectors run on any operating system and processor architecture

High Speed

It allows ultra fast collection runs. (Our tests: Win 10, collect last 3 days, any type, full disk = 3 minutes run)

Thunderstorm API Client

We provide a Python module and Python based API client that supports multi-threaded submission to the THOR Thunderstorm service.

Modes of Operation

Service Mode

The service can be started in two scan modes:

  • Pure YARA
  • Full-Featured

Pure YARA

In the pure YARA mode (–pure-yara) THOR Thunderstorm only applies the 13,000 internal and all custom YARA rules to the submitted samples. It’s leightweight and super fast.

Full-Featured

The full-featured mode is the default. In this mode Thunderstorm also parses and analyses Windows Eventlogs (EVTX), registry hives, memory dumps, Windows error reports (WER) and more. It’s not just a YARA scan, but a full forensic processing.

More Features

Completely On Premise

THOR Thunderstorm can be installed on any internal system and runs as a service within your network

Sample Storage

Store suspicious or all transmitted samples with a reference to the source system to facilitate the deeper analysis

Forensic Modules

THOR Thunderstorm supports the analysis of different file types that get collected for forensic analysis purposes (e.g. EVTX files, Registry Hives)

Custom Signatures and IOCs

Add you own YARA signatures, Sigma rules, hash and filename IOCs and apply them to incoming samples

SIEM Integration

THOR Thunderstorm offers many ways to output information (Text, JSON, Syslog), which makes it easy to integrate the findings into your favorite SIEM system

Web GUI and API Documentation

The API documentation is embedded into the web service itself. You can even send requests right from the browser to test it live.

The Web GUI contains important information about the service like the signature set version, uptime, number of processed and queued samples and much more. 

It contains some graphs that help you to assess the actual server load and processing speed. 

It also contains links to the API documentation, the Python API library and the Thunderstorm Collectors for your convenience. 

 

On The Roadmap

The following tasks are on our roadmap for THOR Thunderstorm

  • Collector service that uses file system notifications to submit new files in real-time
  • Cortex Analyzer
  • ICAP Support (allows interfacing with Web Proxies)
  • File format support: PCAP, MFT
  • Recursive extraction of nested archives
  • Docker setup guide

Getting Started

Please use the “GET STARTED” button in the upper right corner or this link to request more information.

The release slide deck contains more detailed information on some of the mentioned aspects.

 

THOR v10.6 TechPreview

Oct 1, 2020 | Newsletter, THOR, Thunderstorm

We are proud do announce the version 10.6 of THOR, which is the first one that gets released as a TechPreview. We’ve discussed the split-up into THOR and THOR TechPreview in a previous post.  

The following post describes the most important new feature of the THOR v10.6 TechPreview version.

THOR Thunderstorm

THOR 10.6 is the first version that support a new mode of operation – a RESTful web API service named THOR Thunderstorm. THOR Thunderstorm is able to receive thousands of samples per minute via web requests, scans them and returns a scan result. 

We’ve outlined many use cases and features of THOR Thunderstorm in a separate blog post. 

THOR Thunderstorm requires a separate license named “service license” to run. 

 

Multi-Threaded Scanning

Especially the customers with a lab license should be happy to hear that we’ve implemented multi-threaded scanning. 

From now on, THOR can use multiple threads to process elements (files, registry keys, events in eventlog etc.). 

This can boost the scan speed on mounted images significantly. Our tests on a 16 Core system showed a scan speed improvement of 1400%. 

Reworked Quick Scan

Quick scan (–quick) is used when fast scan results are crucial. It usually takes less than 25 minutes to complete. This is achieved by skipping elements in the scan. Quick in versions previous to 10.6 do the following: they skip the Eventlog scan and scan only a set of 40+ highly relevant folders on disk. 

The new quick scan doesn’t skip whole modules or directories anymore. For all previously skipped elements the new quick scan evaluates if they have been modified or created within the last 72 hours and scans only these elements. 

This way the new quick scan is much more intense but should  be only slightly slower. 

Other Changes

  • We’ve changed the ambigious “–fsonly” flag to “–lab” to indicate the best settings for scanning in a forensic lab (the old flag is still usable but hidden in the usage description)
  • Virtual drive name mapping (used in lab scans to map the actual mount point to the original one)
  • Minor changes to some log lines (extended field values) 

Getting Started

Customers can download the THOR TechPreview version 10.6 in the Downloads section of the customer portal or use thor-util in it’s newest version to download that version with the flag “–techpreview”. ASGARD version 2.5.3 also supports scan runs with THOR TechPreview.