With this blog post we would like to inform you that our End-of-Life (EOL) products THOR 8 and SPARK will reach their End-if-Service-Life (EoSL) on 31th of October 2020.
From this day onwards, product and signature updates will not be available anymore.
Please consider upgrading to THOR 10, which is available for all relevant platforms and architectures.
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:
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.
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.
Please report problems in the issues section of THOR Lite’s helper scripts github page.
People often tell us that EDR product X already does IOC scanning and that they don’t have to check for these indicators a second time using our scanners. Especially when it comes to network wide sweeps for traces of activity due to an ongoing incident I recommend scanning a second time with one of our scanners or a tool of similar quality.
This blog post explains why.
People usually spend a fair amount of time on selecting threat intel feeds and interesting indicators for their scans. However when it comes to the actual application of these indicators they seem to be satisfied with the simplest form of checks.
Especially when we look at C2 or Filename IOCs I can easily explain the difference between the „compulsory“ and „freestyle“ methods of IOC scanning.
A plain „compulsory“ filename IOC check would walk the disk or query a database looking for a certain filename, right?
However if you think about it for a second and ask yourself „where else could we check for that filename?“ you’ll realize that the following elements could also contain the malicious filename:
Actually we often see that during lateral movement attackers access systems, run their tools remotely, copy the output, delete the output files and leave no file system traces behind. Our scanners use the locations mentioned above and others to detect them although all the files have already been removed from disk. That’s the „freestyle“ method.
The same counts for the C2 IOCs. The „compulsory“ plain method would check the system’s network connections.
The „freestyle“ method also includes checking for these C2 IOCs in the following locations:
It is sad to see great indicators from expensive feeds used into tools that do „IOC scanning“ the „compulsory“ way missing so many interesting spots.
If all you have is a hammer, everything looks like a nail.
So – the next time when someone tells you that their tool checks for IOCs on the endpoint, your question should be „How and where do you check for these IOCs?“.
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.
SPARK Version 1.17.0 adds extensive STIXv2 support.
This allows you to easily extend SPARK’s signature bases with IOCs from any sandbox, analysis or threat intel platforms that support STIXv2 export by placing the exported [cci]*.json[/cci] files in the [cci]./custom-signatures[/cci] folder.
These types are applied in different modules:
As we have announced in May, the old “thor-upgrade.exe” is already out-of-support and the old update servers accessed by “thor-upgrade.exe” will be decommissioned at the end of October.
The new all-round utility “thor-util.exe” now supports all of the features provided by the old “thor-upgrade.exe” including NTLM Authentication with corporate proxy servers.
The only valid update servers that should be accessible to get updates from November onward are:
The “thor-util” utility is part of the THOR and SPARK packages and can also be downloaded from the Customer Portal in the “Downloads” section.
If you are a customer and don’t have access to the Customer Portal yet, please contact us or the respective partner.
The new SPARK v1.14.16 supports the sample quarantine protocol named Bifrost.
With Bifrost you’re able to send suspicious samples that THOR or SPARK detect on endpoints directly to a central server for analysis.
A Bifrost server is shipped in form of a Python script with THOR and SPARK. (./tools sub folder)
You can also activate the Bifrost server on our ASGARD platform.
We use a public key in the utilities to encrypt the files for our scanners so that admins, Antivirus engines and attackers won’t be able to read the contents of the files.
After encryption, place the encrypted IOC files in the “./custom-signatures” directory and the encrypted YARA rules in the “./custom-signatures/yara” directory.
Examples:
thor-util.exe encrypt case44.yar thor-util.exe encrypt case44-hashes.txt thor-util.exe encrypt case44-hashes.txt case44.yar thor-util.exe encrypt case44.*
You can use the “upgrade” feature in both tools to get the newest version of the utility.
thor-util upgrade
The upcoming ASGARD version 1.5 comes with a IOC management section in which you can manage your own set of IOCs in text files, YARA and Sigma rules.
You can then select each of the folders when creating a new scan run with THOR or SPARK. Selecting one of these folders will not include the sub folders.
You can schedule and run scans with different IOC, Sigma and YARA rule sets. You can review the included custom signatures in the scan details.
The following features are not yet implemented in v1.5 but on the roadmap for ASGARD v1.6:
On the right you can see a simple Sigma rule that checks the “System” eventlog for traces of password dumper activity. The detection section contains 1+ identifiers (selection, keywords, quarkspwdump) that can be defined freely by the rule author. These selectors are used in the condition to build the rule.
It also contains a description, references, possible false positives and a level.
Wouldn’t it be great if you could apply Sigma rules on the endpoint?
This way you are able “query” the standalone systems that are not connected to your SIEM and uncover otherwise common blind spots in your environment.
We ship the current rule set, which is part of the public Sigma repository and contains more than 200 rules with our SPARK program package in an encrypted form. (*.yms)
You can add your own Sigma rules to the “./custom-signatures/sigma/” folder in the SPARK program directory.
To activate Sigma scanning, use the new “–sigma” parameter.
Currently only SPARK supports this feature and there are no plans to implement this in THOR as well.
The feature is currently free for all customers but may become a premium feature that has to be licensed separately by the end of the year depending on the customer’s plan.
See the comparison table for a complete overview on all features.
