New Feature in THOR v10.1 – Remote Scanning

THOR v10.1 features a mode of operation that is especially helpful in incident response or compromise assessment scenarios – remote scanning. 

Imagine that you’re in a firefighting scenario – a breach has been confirmed and management wants to have quick results on the extent of the compromise. 

The new remote scanning feature called “THOR Remote” allows you to perform triage scans on hundreds of remote systems from a single admin workstation. You can think of it as an integrated PsExec. 

No scripting, no agents, no hustle.  

Benefits

  • No agent
  • No scripting
  • Painless scans of many remote systems

Requirements

  • Available on Windows only
  • Accessible remote ports (135/tcp, 445/tcp)
  • Account with local admin rights

All you need is the new version 10.1 of THOR and a command line of an admin user with the required privileges and open Windows ports (135/tcp, 445/tcp) on the remote systems.

THOR will then switch into a new mode of operation and present a command line interface showing scan information and a scrollable pane for each log file. (see screenshot)

THOR writes the log files to a local folder on the admin workstation or sends them via SYSLOG to your SIEM system.  

You can also define a number of concurrent scans (workers) and delay the scan starts to distribute the load evenly among the target systems. This is beneficial when you scan numerous virtual machines running on a few host systems. 

A complete triage scan of your internal domain can’t be more comfortable. 

THOR 10 Fusion Released

THOR 10 Fusion has arrived. 

It replaces our successful scanners THOR 8 and SPARK and combines the best of both worlds. It is a completely new code base that features all modules of our 4 year old compromise assessment flagship THOR 8 and the speed and extra features of our triage scanner SPARK.

You can find an overview of the major changes in this article.

Download

All customers with an active contract (rental license) and license pack users can download THOR 10 from the “downloads” section in the customer portal.

You can find the new manual as PDF in that section and the ‘./docs’ folder of the downloaded program package. 

 

Updates

Please note that signatures updates will be much more frequent due to the decoupling of program and signature files. Make sure to use thor-util version 1.8 or higher. 

We plan to release new signature packs every 1-3 days and new program binaries about once a month. 

The old scanners will receive updates until mid-2019. However, these updates will be less frequent. 

 

ASGARD

After upgrading to ASGARD version 1.10 you’ll immediately see the new scanner in all menus. 

THOR 10 will be the new default for newly scheduled scan jobs. Old scan jobs will not be touched.

Updates of program binaries and signatures can now be managed separately from the “Updates” section. 

 

Changes to Consider

All the old command line options stayed the same as in THOR 8. However, we’d like to bring some addition features and changes to your attention. 

  • The THOR 10 program package now also contains a 64-bit executable (thor-x64.exe), which should produce much better process memory detection results. (ASGARD automatically selects the right binary)
  • Custom settings are now configured via ./conf/thor.yml and not ./conf/thor.cfg.
  • The active modules per scan mode and the log contents have been reworked. You can’t make a comparison with previous THOR 8 scan data. The log format (default) stayed the same, so that old field extractions should still work. 
  • The log contents are more detailed and more consistent (e.g. timestamp format).
  • THOR has more output options (SYSLOG formats and JSON log file output, see manual).
  • Scan durations will change. The scanner is faster but has more active features like “archive YARA scanning” (better detection for Office document macro droppers).
  • Sigma scanning is available, but has to be activated with “–sigma”. It uses all rules from the public rule repository.

See the already mentioned article for more changes. 

 

Get THOR

Check our license packs for many DFIR and SOC scenarios or request a trial of our new scanner.

Questions

If you have any questions, please contact via the support link in the customer portal. 

THOR 10 Fusion – Major Changes

In anticipation of our new scanner THOR 10 Fusion, we would like to show you some of the exciting new features and upcoming changes. 

Modes and Feature Cleanup

We’ve reviewed and reworked all scan modes in order to clarify the overview of active modules and features for the user. 

In the past, it wasn’t always clear which module and feature has been auto-deactivated and auto-activated during the scan runs. 

We’ve dropped the “–fast” mode, which was rarely used intentionally but auto-activated on Workstations.

Most of the modules have been completely rewritten. 

Due to higher scan speeds we didn’t have to make many compromises. The “default” scan should take roughly as long as with THOR 8 but is much more intensive. 

Modules like the “Rootkit” module have been split up in two different sections, one with important and less dangerous checks and one with less relevant checks that could lead to an Antivirus intervention (e.g. Double Pulsar check).

This refactoring allows us to activate the module in “Soft” scan mode and set e.g. “Double Pulsar” as extra feature for that module, which is activated in “Default”, “Quick” and “Intense” scan mode. 

Separate Program and Signature Updates

Former versions of THOR have been shipped and upgraded as a complete package.

The new thor-util allows you to upgrade program files and signatures separately.

We’ll try to publish new signature packs as fast as new YARA signatures get published in VALHALLA 

Time Stamp Harmonization

The timestamps in all the different modules have been harmonized to ANSIC standard.

This was an important step to allow the creation of meaningful timelines of the discovered events. 

Configuration Files Become Scan Templates

THOR 10 uses so-called scan templates in YAML format, instead of the old config file format.

The parameters in these scan templates reflect 1:1 the command line parameters. With these new scan templates it is easy to define a set of parameters for your scan and ship them as the default scan template. 

You can even mix the configurations from multiple scan templates, e.g. define a default template and separate templates with different syslog targets for each branch office.  

 

JSON and Key/Value Output

You can choose from multiple options to influence the output format of the log files and SYSLOG messages sent to  remote servers. 

We handle log messages internally as objects and can easily render JSON or Key/Value pair outputs. 

This greatly simplifies the SIEM integration of all output streams. 

 

Difference Scan

The difference scan makes use of the THOR DB and checks only elements on disk that have been created or changed since the last scan start.

This is a new ultra fast scan mode, albeit susceptible to timestomping attacks. 

Sigma Scanning

THOR 10 inherits the Sigma scanning feature from SPARK and can now apply Sigma rules to local Eventlog entries (Windows) or log files (Windows, Linux and macOS). 

Find more information on the Sigma scanning feature in this older blog post

 

Better Process Memory Matches

Process memory matches now show the matching strings or code sequences found in the memory of scanned processes. 

Tagged Matches

Since our YARA rules are tagged during the integration into VALHALLA, all of them have tags including the MITRE ATT&CK tags, that help your analysts putting matches into context. 

ASGARD Integration

THOR 10 integrates seamlessly with ASGARD and shows up as third scanner next to THOR 8 and SPARK. 

The “Updates” section will show separate update settings for the scanner’s program components and signatures. 

The ASGARD menu to create new THOR 10 hunts contains all command line options dynamically extracted from the current executable.

This way it adapts to all future features and command line options that will be integrated into THOR 10 over time. 

These are only some of the changes coming with THOR 10 Fusion.

We are in schedule and excited to release it in July.

Upcoming : THOR 10 “Fusion”

We are proud to announce the upcoming release of THOR 10 code named “Fusion”.

It will replace our scanners THOR 8 and SPARK before the end of this year. Both of the current scanners will still receive updates until the end of this year. 

THOR 10 “Fusion” combines the advantages of our current scanners, the intensive analysis capabilities of THOR with the unmatched flexibility and speed of SPARK.

It features all modules of THOR 8, including Registry, SHIM Cache, Eventlog, Mutex, WMI, Service and Autoruns analysis.   

It runs on all major operating systems – Windows, Linux and macOS.

With THOR 10 “Fusion” you will not have to decide between an intense or fast scan anymore. THOR 10 provides the best of both worlds. 

We plan to release THOR 10 in July this year. Follow us on twitter or subscribe to the newsletter for updates.

Customers will get a separate notification with changes and instructions for an upgrade.  

Remarks on Products and Services

We constantly improve the quality of our products and services, add features and create new bundles. Follow ups with our customers showed that not all of these changes reach their attention. They are often surprised and excited to hear about these features, free tools or license bundles. This is a list of the changes that often go unnoticed.

1. Scanner licenses allow you to run THOR and SPARK

Customers who have bought scanner licenses to scan Servers and Workstations, be it an Enterprise or Host-based license, can use both our scanners THOR and SPARK. If you have bought an Enterprise license for THOR in the past, you are also allowed to download and use this license with SPARK on Linux or macOS endpoints. Download SPARK from the “Downloads” section in the customer portal.

2. SPARK applies Sigma rules on endpoints

Customers are often surprised to hear that. We have customers that are not allowed to collect logs on endpoints due to legal restrictions but they are able to start executables like our scanner SPARK on endpoints, which is able to apply Sigma rules on local Eventlogs. This way, they can apply detection rules on systems that they do not actively monitor. The blog post – SPARK uses Sigma Rules in Eventlog Scan has more information on that feature.

3. Some contracts include a free ASGARD Management Center and Analysis Cockpit

Enterprise customers with a valid support contract for our scanners are eligible for a free ASGARD Management Center, which is able to control and schedule scans on up to 10.000 end points and an Analysis Cockpit, that allows you to ingest and analyze the logs of up to 50.000 end points in a comfortable manner.

Customers with more than 10.000 licensed endpoints are eligible for additional ASGARD Management Centers and a MASTER ASGARD, which is the central management for multiple ASGARD systems. 

See the Video Tutorials page to learn how these systems can help you with you daily management and analysis tasks. If you are interested in these systems and your account status, please contact your account manager.

4. YARA signature overview in Customer Portal

The customer portal contains a CSV with information on all 9973 YARA rules in our signature set (as of 16.02.2019). This way you can verify if a certain threat group or campaign is covered by our rules or not. You can find that CSV in the “Software Information” section together with binary hashes and an update server status on all our products.

5. Kibana can be installed together with ASGARD Analysis Cockpit

We do not support this coexistence but prepared everything to make it easier for you to install Kibana next to our own interface to analyze the collected log data. The analysis cockpit manual has a chapter that explains how to install Kibana on an Analysis Cockpit. The Analysis Cockpit wraps Kibana and serves access as reverse proxy providing a common authentication. You can manage the service from within the “Settings” section of the Analysis Cockpit.

Feedback

If you have any feedback, questions on these features, please let us know.

MASTER ASGARD – One ASGARD to Rule Them All

We are glad to announce our new product MASTER ASGARD, a central control for a set of ASGARD systems.

MASTER ASGARD is designed to control multiple instances of ASGARD, which itself supports up to 10,000 endpoint agents. Using MASTER ASGARD you are able to control more than 100,000 end points from a single central location. 

This control includes:

  • Run distributed THOR and SPARK scans
  • Schedule distributed THOR and SPARK scans
  • Manage and distribute IOCs
  • Collect files and memory from Windows and Linux end systems

 

 

Here are some screenshots:

Management of multiple ASGARDs

Evidence Collection

Distributed Scans

MASTER ASGARD will be available for BETA program customers at the end of February and to the full customer base in May 2019.  

ASGARD v1.7.2 with File and Memory Collection

Our brand new ASGARD 1.7 comes with a shiny new feature: Evidence Collection

The evidence collection feature allows you to collect files or main memory from connected end systems.

The memory and file collection tasks provide a throttling option to reduce the upload speed of the dump files in order to save bandwidth and avoid higher response times of servers or workstations. 

The file collection feature allows you to get a single file, the contents of a folder with or without its sub directories. You can set size limits for each file and the whole archive.

The “Evidence Collection” tab lists all active and completed tasks. 

A log shows you the details of all the collection tasks.

ASGARD version 1.7.2 has been released today and can be upgraded via the “Updates” section. 

Please note that the memory collection on Linux endpoints is integrated but not fully supported. 

 

YARA Rule Sets and Rule Feed

As previously announced our YARA rule packs and feeds will be available in March/April 2019. We’ve put a lot of effort into a internal system named “Mjolnir” that parses, normalizes, filters, tags and automatically modifies our rule base, which contains more than 9000 YARA rules. 

This system will now fill a database of tagged YARA rules – the basis of our new YARA services. 

The services will be divided into two categories:

  • YARA Rule Set
  • YARA Rule Feed

YARA Rule Set

The YARA rule set consist of more than 7000 YARA rules of different categories that are used in our scanners.

Some of our rules use extensions (external variables) that are only usable in our scanner products. These rules, experimental, third party and other classified rules will not be part of the purchasable rule set. 

YARA Rule Feed 

The YARA rule feed is a subscription on our rules. The feed always contains the rules of the last 90 days, which is between 250-400 YARA rules. 

Rule Samples

The quality of the rules in the rule set are comparable to the rules in our public “signature-base” repository. 

Some good examples for the different rule categories are:

Quality and Focus

The rules are tested against a data set of more than 350 TB of goodware. The goodware file repository consists of Windows OS files, several full Linux distributions and a big collection of commercial and free software. 

However, false positives are always possible. We do not recommend any destructive action on a signature match, like delete or blocking.

The main focus of our rules are:

  • Threat Hunting
  • Classification
  • Anomaly Detection
  • Compromise Assessment 

Subscribe to our Early Access Mailing List

THOR 8.53 Feature: Diff Mode

With the upcoming version 8.53 of THOR, we’re testing a new feature called “Difference” or “Diff” mode (–diff).

The idea behind “Diff” mode is that a scan could be much faster, if it would only consider elements that have been created or changed since the last scan on that system. We can apply this principle to various modules and increase scan speed massively.

Diff mode is currently supported in the long running modules

  • Filesystem – files with MAC timestamps older than the last scan (start) will be skipped
  • Registry – registry keys with last modification dates older than the last scan (start) will be skipped
  • Eventlog – runs until it reaches eventlog entries with timestamps older than the last scan (start)

Diff mode requires the use of THOR DB, which is the default but could have been disabled with “–nothordb”. This is necessary to determine information from the last scan, e.g. “when did it start” but also “which modules were used in the last scan”.

The main advantage is an incredible fast scan. Our tests showed that scans in “Diff” mode complete within 5 and 15 minutes. In “Diff” mode, the longest running module is “ProcessCheck” with run times between 3 and 6 minutes.

The main disadvantage of “Diff” mode is the inability to detect Timestomping attacks, in which attackers or malware changes the timestamps of files and other elements.

ASGARD Analysis Cockpit 2.2 Feature Overview

Later this month the new version 2.2 of ASGARD Analysis Cockpit will be released. These are the most important new features.

The Optimize Button

The new “Optimize” button allows you to add all unassigned log lines to existing cases with matching filters. It is possible that you miss some events when creating a new case, either by the wrong selection or due to the fact that new log lines can arrive at any time via SYSLOG or log file import in the background.

Now it is possible to add all unassigned log lines to previously created cases by using the “Optimize” button.   

It will not remove previously assigned log lines from existing cases. It just helps you to clear up the base lining section by removing events that are related to existing cases but haven’t been assigned to these cases yet.

You can later review all automatic assignments in the “Automatic Event Assignment” protocol.

Notification Settings

The new “notification” settings allow you to create notification rules for the following type of events:

  1. Log lines that are automatically assigned to an existing case
  2. Status changes of cases

The current supported actions are:

  1. Syslog Forwarding
  2. Email Notification

This allows you to define flexible rules for many different events. You may e.g. create a rule that sends an email notification whenever a new “Incident” case is opened. 

You could also forward all incoming log lines that are automatically assigned to a case of type “Incident” to your remote SIEM system. (each syslog message will be extended by two new fields: case_type and case_id)

An email for a opened “Incident” case will then look like this:

The attachments of these emails contain the included log lines (text) and a JSON with all case information in machine readable form.

File Importer

The File Importer status view has been improved so that it shows the number of total files in queue and the number of processed files.

Improved Reporting

The new improved reporting allows you to generate reports not only for a given period of time (e.g. last month) but custom queries on the ElasticSearch database. E.g. you can generate report for the scans on your SuSE linux systems only. 

The reports contain more panels and information on the data set. 

The data from all reports can be downloaded as JSON file. 

Upgrade to 2.2

The upgrade will be visible in the “Updates” section of your Analysis Cockpit once it is released. See the change.log notes for a full list of changes.