We’ve made a short video demo to showcase the new THOR 10 feature called “THOR Remote”, which allows you to perform compromise assessment scans on multiple remote systems – no agent or scripting required.
We are working on a THOR scanner version that brings our well-known compromise assessments and thousands of YARA rules to IBM’s AIX®.
Subscribe here to get noticed once beta testing and a stable version is available.
* no advertisements – just two emails, one for the beta program and another one once it gets released
This module checks registered Events in the system environment as they are used by advanced malware and rootkits.
We have checked for malicious Events before, in the Rootkit module, but these checks were hardcoded. We’ve spun out that section and can now provide regular updates in a separate signature file.
The “Events” module extends our set of rootkit related modules that already include the “Mutex” and “Named Pipe” modules.
THOR v10.2 features an unencrypted table in THOR DB that shows timing information for the scanned elements. This could help you identifying elements that lengthen scans significantly and determine a time range in which certain elements have been scanned.
A new switch “–reduced” allows to limit events to “Warning” and “Alert” types only.
Other Changes
We’ve just released an updated version of our Antivirus Event Analysis cheat sheet. You can download version 1.7.2 here.
The major changes are:
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
Requirements
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 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.
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.
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.
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.
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.
See the already mentioned article for more changes.
Check our license packs for many DFIR and SOC scenarios or request a trial of our new scanner.
If you have any questions, please contact via the support link in the customer portal.
In anticipation of our new scanner THOR 10 Fusion, we would like to show you some of the exciting new features and upcoming changes.
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.
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.
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.
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.
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.
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.
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.
Process memory matches now show the matching strings or code sequences found in the memory of scanned processes.
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.
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.
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.
With this post, we would like to demonstration the YARA rule creation process for the so-called “threat hunting” rule category that we use in VALHALLA.
We noticed that many interested parties thought that “threat hunting” YARA rules are just rules with lower scores indicating a lower certainty. But in fact, they’re our most successful rules. The reason behind this is that they focus on anomalies as they appear in obfuscated samples and we’re not just talking about different forms of encoding.
Looking at the current table named “Successful YARA Rules in Set” on the VALHALLA start page, you’ll see many rule names that start with “SUSP_” for “suspicious”.
These rules don’t match on a specific threat / malware but detect
So, these rules cannot be used for classification but they’re certainly priceless to detect new unknown threats.
Processing different samples from various threat groups we often notice patterns in malicious code that looks as if it could be used for a generic “threat hunting” rule.
The MuddyWater sample (8f0c6a09d1fca3d0002d3047733b50fe5153a33436d576c5020f0a21761242f1) contains the following base64 encoded block.
While looking at this code block you can see repeating patterns even before decoding it just by scrolling over it.
A good analysts asks himself “could this pattern serve as a signature?”.
To answer the question he decodes the base64 encoded chunk and gets a script with the following content:
He’ll notice a block of hex encoded values in a list. It seems that the obfuscation of the lower level (hex) can be detected in the upper layer (base64). So, by using a combination of these two forms of obfuscation, the attackers provide us a pretty specific pattern to detect a malicious – or rather – a highly suspicious code.
Next we try to figure out the exact usable patterns and put them to the test with different offsets. We use simple regular expressions in CyberChef to highlight matches.
For our YARA rules, we don’t want to use regular expressions but byte patterns with place holders. Even for this task we can make use of CyberChef.
The output can be used in a YARA rule that looks like this:
To us it is not surprising that a test with the rule returned a lot of samples with low or no AV detection at all. We tested the hash list of the samples retrieved from a Virustotal Retrohunt with Munin and got the following results:
As you can see, it’s not possible to verify the results based on the AV detection ratio. However, it’s a good sign that other threat hunting rules or even rules for known webshells from our ruleset match on these samples as well. We typically evaluate the false positive rate of this type of rules with the help of the file names (e.g. c99.php, virus.txt, *_codexgigas, Virusshare_*) and some spot checks.
You’ll also note that the rule matches many different content types – emails (.eml), executables, web shells, scripts. That’s one of the reasons why we love these rules so much.
The second screenshot contains some reassuring matches of the customized older version of the LaZagne credential dumper used by MuddyWater and apparently also encoded in the described form. (b8e97c96aa18916c15eea5c78d5a20b966aa45f332a5ea4d9ac2c87ebe5adff6)
You can find a full munin result file of the retrohunt matches here.
The YARA rule will be pushed to the signature-base that we provide for the community and will also be available in a streamlined form in the VALHALLA demo feed very soon.
I hope you liked it.
For more information like this, please subscribe to the newsletter or follow us on twitter: @thor_scanner
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.
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.
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.
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.
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.
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.
If you have any feedback, questions on these features, please let us know.