Product Surveys – Tell us what you think

We’d like to know your opinion on our products and therefore ask you to participate in our product surveys. Each of them takes between 2 and 5 minutes of your time, depending on how much you’d like to tell us.

THOR Customer Satisfaction Survey

You find the survey here.

ASGARD Customer Satisfaction Survey

You find the survey here.

Analysis Cockpit Customer Satisfaction Survey

You find the survey here.

Public Feature Collection

We also plan to publicly collect feature requests and allow you to up- or downvote requests of other users, comment on them and get informed when a feature has been implemented.

 

Log4Shell Detection with Nextron Rules

The Log4Shell vulnerability (CVE-2021-44228) in log4j is actively exploited in-the-wild and highly critical. This blog posts lists some important web resources and the signatures that detect exploitation attempts.

Explanation of the Vulnerability

LunaSec reported first on the vulnerability.

Canary-based Vulnerability Detection

Use this method to detect vulnerable applications and services in your organisation.

Grep / ZGrep Detection Ideas

Different detection patterns and idea to detect exploitation attempts in log files using grep and zgrep.

Log4Shell Detector Python Script

A python script that can be used to detect even the most obfuscated versions of the malicious payload. 

List of Advisories by Vendors

Big collection of advisories and statements by different vendors that use JAVA and log4j. 

List of Vulnerable Software with PoCs

Incomplete list of software products that have proven to be vulnerable.

Log4Shell Vulnerability Scanner (Local Files)

Scans the file system of application servers for vulnerable versions of the log4j module.

Fenrir Log4Shell Release

A bash based IOC scanner that can be used on any Linux/Unix system to detect traces of the attack and vulnerable log4j versions.

Signatures Detecting Log4Shell Attacks

Check for matches with the following rules:

Exploitation

YARA

Sigma

Post-Exploitation

Look for matches with the following rules that trigger on activity observer in-the-wild.

YARA

Sigma

ASGARD Users

It takes us few days to release new rules. The rules that we wrote over the weekend may not be available on Monday 13th of December. ASGARD users that want to use the signatures that are still in our QS, can activate the option for these signatures in “Settings > Advanced > Show Signature SigDev Option”. 

After changing the setting, new scans show an additional option in the dropdown menu. 

Please contact our support in case of any questions. 

THOR Users

Users of our scanner THOR also need to use the signature version that’s in development to get the newest signatures that detect log4j exploitation. 

Retrieve that signature pack with:

thor-util.exe update –sigdev

Reasons Why to Use THOR instead of THOR Lite

We have received reports from customers that were approached by service providers that offered compromise assessments with our scanner THOR. Subsequently, it appeared, however, that these providers used THOR Lite in their engagements and, when asked about this, argued that THOR Lite would be “just as good as the full version”.

In this article we would like to explain why this is not the case.  

1. The Small Rule Set

The rule set of THOR Lite is much smaller. While THOR uses more than 16,000 YARA rules, THOR Lite only uses the open source signature base, which has ~4000 rules. Of these 4000 rules, 800 are old webshell rules, 300 are written for old Equation Group implants that should be long gone, many others were written for past threat group activity.

Don’t get us wrong – these rules were good at their time and the set contains solid generic rules for some kinds of threats but the effectiveness of the older rules decreases and it is less and less likely that they catch something significant.

The number 4000 compared to 16,000 doesn’t mean that you would still see 1/4 of what THOR is able to detect – honestly, it’s rather 1/30. 

2. The Limited Modules

It is correct that the filesystem often contains evidence, but not traces of adversary activity are not always visible on the filesystem. It’s not unusual that adversaries remove their tools when they’ve finished their job.

Therefore the full version of THOR runs more than 25 modules that look for the IOCs and apply YARA rules in many different locations like the Eventlog, SHIM Cache, Registry and performs checks for hidden implants that can only be identified with their mutex or a handshake on a certain named pipe.

The screenshot on the right shows all disabled modules and features in the Lite version. 

Findings in these other modules aren’t just evidence of a compromise but often point to other techniques used by the attackers or other systems that are also affected.

THOR Lite lacks not only depth of visibility with a much smaller rule set but also breadth due to the limited set of modules and features.

All modules and features disabled in the Lite version

The Few Exceptions

There are a few exceptions to the rule of very limited visibility in THOR Lite.

  • To showcase what the full version is able to detect, we’ve included all available signatures for the various campaigns against Microsoft Exchange, namely ProxyShell and ProxyLogon. Scanning Exchange servers for this kind of threat is almost as good as using the full version of THOR.
  • The few generic detection rules provide a good coverage of common threats, like webshells and crypto miners. Arnim Rupp provided a great set of generic webshell detection rules that are able to highlight new, yet unknown web shells of all kinds (ASP, JSP, PHP etc.).
  • The coverage of some well-known hack tools like Mimikatz is also pretty good. 

For whom is THOR Lite intended?

THOR Lite is meant as a free community edition to showcase the functionality.

It is meant to be used by private individuals or small organisations without a budget that face common threats like crypto miners and crime groups. 

From time to time, we add sets of rules and IOCs to detect dangerous threats with high importance and / or a wide spread – e.g. Exchange vulnerability exploiting, crypto coin miners, Ransomware worms like WannaCry.  

Test Drive the Full Version

We recommend a test drive of the full version on compromised or possibly compromised systems to see the big difference in detection capabilities. We also offer affordable license packs for small organisations and give attractive discounts on license packs that are used by IR teams all over the world.

Just use the “get started” contact form and state that you’d like to test the full version of THOR.

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

Use YARA math Module Extension in THOR TechPreview and THOR Lite

Not long ago, we’ve created a pull request for the official YARA repository on Github, that would introduce new functions in the `math` module to improve the flexibility in cases in which a sample is heavily scrambled or obfuscated. These cases require further statistical evaluations that go beyond the currently available “entropy”, “mean” or “deviation” functions.

The example on the right shows a heavily obfuscated PHP web shell, as used by a Chinese actor. 

You immediately notice the high amount of “%” characters, but since each of them is preceded and followed by different characters, it’s difficult to find atoms that are long enough to maintain an acceptable performance / stability of that rule. 

 

If you could, you would formulate a rule like this: “Detect files smaller 400 bytes, that begin with ‘<?’ and consist of at least 25 percent ‘%’ characters”. 

Well, the new module extension allows you to do exactly that.

Read the documentation provided with the pull request for details on all three new functions:

  • count(byte/string, offset, size)
  • percentage(byte, offset, size)
  • mode(offset, size)

While the first two functions are self-explanatory, the “mode” function isn’t. It is is a term used in statistics for the most common value.

For your convenience, we’ve already patched our versions of THOR TechPreview and THOR Lite to support these extensions of the “math” module. You need at least v10.6.6 to use the new function in your rules. 

We wish you good hunting. 

THOR 10.6.8 TechPreview with ETW Watcher to Detect CobaltStrike Beacons

THOR TechPreview version 10.6.8 will introduce a completely new module named ETW Watcher, which runs in a separate thread and monitors the systems during a scan run. As its name indicates, the ETW Watcher module makes use of Event Tracing for Windows (ETW). 

So, whenever you start a scan run on an end system, one thread performs all the usual checks while another thread analyses certain event channels and correlates events to detect malicious activity.

Consider it an agent-less, portable, short term EDR. 

The first task of this new module is the detection of C2 beaconing activity as e.g. used in attacks that utilize Cobalt Strike.

The following screenshots show messages created by the ETW Watcher module. Since all of our modules apply a so called message enrichment, you’ll also notice further messages before and after the highlighted events. These additional messages are generated during the enrichment of the original event.

“Enrichment” means that we add additional information to the original event – e.g. if a file path is given in the original message, THOR tries to find that file, scans it using the “FileScan” module and adds information to the original event. The same is true for process ID values. This adds as much meta data as possible and helps analysts to assess the event as quickly and easily as possible.  

The example above shows a beacon detection that mentions a process named “fnord.exe” frequently calling out to 10.0.2.15 via HTTP and TCP. Message enrichment shows the result of a file scan above (red alert message; appears before the actual event because the enrichment happens before the message composition). 

The next example shows the result of a “hashdump” command sent to the beacon. It causes the beacon to open a handle to the LSASS process memory, which THOR detects and reports as a Warning level message.

The next example shows a privilege escalation attempt performed by that same beacon. 

The ETW Watcher module will be integrated in THOR TechPreview version 10.6.8 and only is available on Windows. It will not be available in THOR Lite and THOR 10.5. 

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. 

WordPress Cookie Plugin by Real Cookie Banner