Introduction THOR TechPreview

Aug 31, 2020 | Newsletter, THOR

Since its early days, THOR has always been focused on stability and detection rate. With the early module and feature set, we never had to make a compromise. 

However, during the last 1-2 years, we had to make some decisions on the integration of new features and their default state in favor of stability. These decisions include e.g. the process dump feature, the PE-Sieve integration and Sigma scanning. 

Detection and stability have become two competing goals. We do not want to make these hard decisions anymore and leave them to you. You decide, based on your use case, if you want to use the version with newest features and detection capabilities or the one with a maximum of stability. 

With THOR version 10.6 we introduce a version named THOR TechPreview, which includes the newest features, refactored modules and new modes of operation. 

THOR TechPreview is a special THOR version that contains the newest modules and great detection features, which have not yet been tested on thousands of systems.

Florian Roth

Head of Research

The first release of THOR TechPreview will be version 10.6.
The standard version of THOR remains version 10.5 until the refactored and new features of the TechPreview have been proved to be stable. The expected release cycles of new version of THOR Tech Preview will be once a month, while new minor versions of THOR will be released only twice a year. Both versions receive bugfix updates and use the same signature set. 

ASGARD and THOR TechPreview

The current ASGARD Management Centers continue to use the standard THOR versions. The next minor release ASGARD 2.6, which is planned for October 2020, includes the option to use the TechPreview variant.  

Recommended Use Cases

The TechPreview version is recommended for all use cases in which detection capabilities have higher priority than stability. We would e.g. always recommend the TechPreview for image scans in a forensics labs.

Internal Testing

THOR TechPreview is not an untested version. It still goes through our internal testing on almost a hundred different test systems in 4 different test configurations.

Getting Started

Customers can download the new THOR TechPreview version from the download section in the customer portal once it gets released. Thor-Util version 1.11+ also supports the TechPreview download. We’ve planned the release for September 8.

Sigma Scanning with THOR

Jul 29, 2020 | Newsletter, Nextron, Sigma, THOR

Our compromise assessment scanner THOR is able to apply Sigma rules during the local Eventlog analysis. This can help any customer that has no central SIEM system or performs a live forensic analysis on a system group that does not report to central monitoring. 

By running THOR on these systems with activated Sigma feature, THOR becomes a kind of a distributed and portable SIEM.

Since the Sigma scan module isn’t active by default, we thought it a good idea to explain how to activate an use it in the best possible way. 

Open Source Rule Set

By default THOR uses the open-source Sigma rule set with more than 500+ rules provided by the Sigma project on their Github page. 

Since our head of research is also one of the project maintainers, it was reasonable to combine the detection capabilities of Sigma with THOR’s scanning functionality on the endpoint. 

We comply with Sigma’s DRL (Detection Rule License) by including the rule authors in the event data produced by these rules.  

Custom Sigma Rules

You can easily add you own Sigma rules by placing them in the “./custom-signatures/sigma” sub folder.

THOR’s Sigma Config

The THOR default configuration for Sigma can be found in the Sigma repository. 

This configuration shows you, which Windows Eventlogs and Linux/Unix log files get analyzed by the Sigma module in THOR.

 

Sigma Scanning

To activate the Sigma module simply use the “–sigma” flag (or “sigma: True” in a YML config file).

You can start a THOR scan that analyzes the local Eventlog and activates the Sigma feature with:

thor64.exe -a Eventlog --sigma

To run a Sigma scan on a single Eventlog e.g. Sysmon’s log, use the “-n” flag.

thor64.exe -a Eventlog --sigma -n "Microsoft-Windows-Sysmon/Operational"

To include the Sigma feature in a standard THOR scan and check only the last 3 days of the Windows Eventlogs to reduce the scan duration, use:

thor64.exe --sigma -lookback 3

Sigma Matches

Once a Sigma rule matches on a log entry, you’ll see it listed in one of the REASON’s that lead to the classification of an event. 

The following example shows the detection of a China Chopper (Caidao) ASP web shell. That web shell has been detected by multiple Sigma rules. 

  1. Webshell Detection With Command Line Keywords 
  2. Shells Spawned by Web Servers
  3. Whoami Execution

Getting Started

Since this feature isn’t available in THOR Lite, please contact us via the “Get Started” button in the upper right corner and get a free trial voucher. Most customers that use THOR with Sigma choose one of our THOR license packs, especially the SOC Toolkit Pack, which was geared to the needs of today’s SOC teams. 

New VALHALLA Web Features

Jul 25, 2020 | Newsletter, VALHALLA

The newest update of our popular YARA rule feed named VALHALLA adds new features to its web interface.

The most awaited new feature is a keyword search that allows you to query the database for certain keywords, rule names, reports, MITRE ATT&CK ids or tags.

The result page shows you if VALHALLA already has related rules in its database. 

 

Keyword Search

The search results show all rules in our database related to the search keyword.

You can see the rule name, description, the rule date, a reference URL and a set of links.

The new search function helps you to determine if VALHALLA and THOR already contain rules for a given report or threat. 

New Links

We have integrated new links that lead you to:

  1. the reference listed in the rule (report, source)
  2. a Virustotal lookup for that rule / sample
  3. a detailed info page for that specific rule

Rule Info Pages

The rule info page contains all the details to a certain rule. These include all metadata values liks score, tags, reference links, required YARA version and modules, the rule date and the average AV detection ratio.

Two additional tables include all antivirus verdicts for samples on which that rule has matched and a list of all observed samples with links to Virustotal. 

 

Community Rule Info

We’ve also added notes on the 2400+ rules that are available as open source in the signature-base repository on github, e.g. try SUSP_LNK_Big_Link_File.

Category Counts

A new table on the start page informs users about the rules per subscribable category. 

Also note that queries of any type to Valhalla are rate limited. Too many requests in a relatively short time frame will lead to complete blocks as well as a high amount of requests over a longe time period and other suspicious activity. Customers can get their source IP addresses whitelisted on request. 

The new version will be deployed in the coming days.

End-of-Life ASGARD v1 and Master ASGARD v1

May 22, 2020 | ASGARD Management Center, Newsletter

Nextron announces the end-of-sale and end-of-life dates for the ASGARD version 1 and Master ASGARD version 1. The last day to order the affected product(s) is May 31, 2020. Customers with active service contracts will continue to receive support as shown until June 30, 2021.

End of Life Announcement Date The date the document that announces the end-of-sale and end-of-life of a product is distributed to the general public. 22.05.2020
End of Sale Date The product is no longer for sale after this date. 31.05.2020
End of Software Maintenance The last date that Nextron may release any final software maintenance releases or bug fixes. After this date, Nextron will no longer develop, repair, maintain, or test the product software. 31.05.2021
Last Date of Support The last date to receive applicable service and support for the product as entitled by active service contracts or by warranty terms and conditions. After this date, all support services for the product are unavailable, and the product becomes obsolete. 31.06.2021

New VALHALLA Features That You Might Have Missed

May 15, 2020 | Newsletter, VALHALLA

Rule Info Pages

The new rule info pages allow you to get more information on a certain rule. You can find all the meta data, as well as past rule matches and previous antivirus verdicts.

A second tab contains statistics. 

You can also report false positives that you’ve encountered with that rule using the button in the tab bar. 

Note that the rule info lookups in the web GUI are rate limited. If you query rule infos too often, you get blocked.

The rule info pages can be access using this URL scheme: 

https://valhalla.nextron-systems.com/info/rule/RULE_NAME

For example:

https://valhalla.nextron-systems.com/info/rule/HKTL_Empire_ShellCodeRDI_Dec19_1

 

Rule Info & Hash Info

The rule info and hash info API endpoints are available for customers with valid API key only.

The API is not rate limited.

Customers can find information on how to use these end points here.

 

Automated Tagging

The automated tagging has been extended to included MITRE ATT&CK threat actor group IDs. 

Status Includes Version

The status endpoint now includes a version number.

The version number is an integer value generated from the last update timestamp using a format string “%Y%m%d%H”. This way it is not just a version number that you can compare with you local last change (e.g. “>=”) but also an implicit timestamp.

You can access that endpoint via POST request (/api/v1/status) or Python API’s “get_status()” function.

 

You can find more information on Valhalla on our web page.

THOR 8 and SPARK End-of-Support

Apr 30, 2020 | Newsletter, SPARK, THOR

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.

Upcoming ASGARD Version 2

Mar 2, 2020 | ASGARD Management Center, Newsletter

The last five months we’ve been working on a shiny new version of our ASGARD platform that overcomes previous limitations and includes exciting new features.

ASGARD 2 is a completely rewritten management platform, featuring a new interface, load balancing options, a new lightweight agent, custom response playbooks and greatly improved IOC management.

 

Fundamental Changes

  • Easy to use GUI and API for response functions (replaces GRR as underlying framework)
  • Rewritten agents consume much less memory
  • New dynamic agent load control allows to connect up to 25,000 endpoints
  • Predefined and custom playbooks
  • IOC management support for MISP
  • Remote consoles

IOC Management

The new IOC management allows to interface with a MISP instance and create rule sets based on filters.

For example, you can search for and select all MISP events containing the keyword “Emotet”, create a new rule set from them and then select this rule set to be used in a new THOR scan. 

Playbooks

The so-called playbooks allow you to define a set of steps that the agent executes on an end system. 

Each playbook can have up to 16 independant steps of the types “Run Command Line”, “Download File” or “Upload File”.

It is easy to set up new playbooks that e.g. download a certain tool to the endpoints, run it and collect the generated output. 

Each or all results of playbook executions can be collected via GUI or API. Playbooks can be triggered via API to allow the integration into security orchestration, automation and response (SOAR) solutions. 

ASGARD v2 ships with a set of predefined playbooks including: 

  • Collect system memory
  • Collect file or folders
  • Quarantine endpoint
  • Collect triage package
  • Collect process tree 

Remote Console

The remote console allows you to open up a web based command line window on any attached end system. This greatly facilitates the analysis of suspicious events. Analysts can browse the remote system, review or change settings and issue commands.

During the session, you can select files for collection or define certain playbooks to be executed after disconnecting the command line session.

Every session gets recorded for complete traceability.

Time Schedule

Beta customers will test drive ASGARD v2 in March and April. We expect a first release in June.

An upgrade guide for ASGARD v1 customers will be provided. 

Automated Citrix Netscaler Forensic Analysis with THOR

Jan 14, 2020 | Newsletter, THOR

In this blog post I’d like to outline an idea on how to perform an automated compromise assessment on Citrix Netscaler / Citrix ADC appliances.

 

I you haven’t heard about that vulnerability yet, you should read my tweets over the past weekend or try to get a full picture with the help of this Reddit. 

This blog post is about a subsequent forensic analysis, not detection, not protection and contains no marketing blah-blah.

The described solution should work with the free / open scanners as well. They just don’t have that huge signature set as it is included in THOR.  

 

The reason for this is that although you’ve implemented the workaround on Monday 13th of January, you can’t trust your gateway anymore.

The vulnerability is known since December 17th and the public exploit code available since Friday the 10th of January. Nation state actors have most likely used Christmas holiday season to analyze Netscaler systems in their lab and produce an exploit, just like many offensive researchers did. Since Friday the 10th, even script kiddies can exploit this vulnerbility.

Strictly speaking, you can’t trust these gateways anymore. 

But how can we regain trust? 

A. Wait for a patched version and reinstall the gateways from the scratch

B. Perform a manual forensic analysis 

C. Perform an automated forensic analysis 

Automated Analysis with THOR

We don’t have and plan a THOR (SPARK Core or LOKI) version for FreeBSD 8.4, but we could try to mount the remote filesystem of the Netscaler gateway with SSHFS. 

DigitalOcean has a good tutorial on how to enable it on your workstation.  

mkdir ~/netscaler-mount
sudo sshfs -o allow_other,defer_permissions nsroot@citrix-gateway.nextron:/netscaler ~/netscaler-mount/

We can then use one of our scanners on that mounted volume using the `–fsonly` parameter (which activates forensic lab mode and scans directories regardless of their type). 

./thor64 --fsonly -p ~/netscaler-mount

With this method, we can detect dropped malicious templates. 

You can use the public YARA rule, that I’Ve published in LOKI’s and SPARK Core’s signature base. (note that a SPARK Core version that includes that rule hasn’t been released yet) 

Important note: this only works for templates that have been dropped since the last reboot. Users reported that dropped malicious templates get removed during a reboot. As the workaround described by Citrix requires a reboot, scanning with this single YARA rule alone won’t be a reliable method.

I recommend scanning with the full signatures set in all scanners, as they also include rules for web shells and other suspicious content in files. I’ll also extend the YARA rules on github and add further indicators. 

Additional Indicators

We can use the following YARA rule to check for suspicious strings in log files. But we don’t want to use that rule on any Linux/FreeBSD system. Therefore I won’t integrate that YARA rule in the public signature base. You can just copy it from this blog post and place it in the ‘custom-signatures/yara’ sub folder (‘/signatures’ for LOKI). 

This rule for the forensic artefacts is based on remarks made in this article by TrustedSec and shared as gist. 

First, we mount the ‘/var/log’ directory from our remote Netscaler system. 

mkdir ~/netscaler-logs
sudo sshfs -o allow_other,defer_permissions nsroot@citrix-gateway.nextron:/var/log ~/netscaler-logs/
We then start a scan on the mounted log directory.

As you can see, the scanner noticed a an issued ‘whoami’ command in the ‘bash.log’ and ‘notice.log’ files, which is a good starting point for further investigations. 

Final Thoughts

I think we’ll develop more rules for post-exploitation payloads over the coming days. Stay tuned and follow my twitter account for updates.