Upcoming Master ASGARD v2

In the first week of June, we plan to release Master ASGARD v2.

Master ASGARD is an ASGARD version that is able to connect to and control an unlimited number of ASGARD servers.

While each ASGARD supports 25,000 connected endpoints, a Master ASGARD server can control an theoretically unlimited amount of ASGARD servers and thus an unlimited amount of end systems. We plan to support installations with up to 500,000 end systems until we get confirming performance and system load statistics from our customers’ setups.

With Master ASGARD v2 we will also change the way in which you install Master ASGARD.

From now on the ASGARD platform can be upgraded to a Master ASGARD by the installation of special license. You simply upgrade an already installed ASGARD to a Master ASGARD.

Master ASGARD 2 features

  • MISP integration and IOCs triage scans on all connected endpoints
  • Remote Console on all connected endpoints
  • Playbook runs on all connected endpoints
  • Evidence collection from all connected endpoints
  • License management for all connected ASGARDs
  • Key material backup of all connected ASGARDs
  • THOR version management of all connected ASGARDs

Master ASGARD 2 does not support

  • direct upgrade from Master ASGARD version 1
  • the control of ASGARDs running on version 1

Please contact sales@nextron-systems.com for more information on Master ASGARD v2.

 

Upcoming Changes in THOR v10.5

PE Sieve Integration

With the integration of @hasharezade‘s PE Sieve project THOR is able to detect and report a variety of process implants like replaced or injected portable executables (process hollowing), injected shellcodes, hooks and in-memory patches.

Naturally, since @hasharezade’s project is an open source project, this feature will also be available in THOR Lite, the free version of THOR. 

Process Dumps

THOR v10.5 creates a process dump of any process that is considered suspicious or malicious. 

This process dump can then be analyzed with standard tools later to examine the findings.

To prevent excessive disk space usage, new dumps overwrite old dumps of the same process. Also, THOR stores the dumps in a compressed form and will not generate dumps if less than 5 GB disk space is available. 

Global Module Lookback

The current “–lookback” option allows you to restrict the Eventlog and log file scan to a given amount of days. E.g. by using “–lookback 3” you instruct THOR to check only the log entries that have been created in the last 3 days.

We’ve extended this feature to include all applicable modules, including “FileScan”, “Registry”, “Services”, “Registry Hives” and “EVTX Scan”. By setting the flags “–global-lookback –lookback 2” you instruct THOR to scan only elements that have been created or modified during the last 2 days. This reduces the scan duration significantly.

On our test systems, we were able to reduce the scan duration of a full filesystem scan and a lookback of three days to less than 4 minutes.

LNK File Parser

The link file parser module processes .lnk files, extracts relevant data and gathers more information on the linked contents. It also applies the anomaly detection methods to its contents to allow the detection of unknown threats. 

 

More Changes

  • Default output files include a timestamp and not just the date
  • Outputs include non-ASCII characters in a hex encoded form (use –ascii to revert to ASCII only output)
  • THOR DBs “–resume” feature is deactivated by default and has to be manually activated using “–resume” due to significant performance implications caused by updating resume states in THOR DB 
  • New –portal* flags allow the licenses generation at runtime using our Netxron portal API
  • New –yara-max-strings-per-rule flag limits the output of matching strings
  • New –nofserrors flag suppresses all error messages regarding access permissions
  • New –scanid-prefix allows users to set a custom prefix to allow the identification of group of scans
  • New –print-signatures flag lists names and meta data of all included YARA and Sigma rules

End-of-Life ASGARD v1 and Master ASGARD v1

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

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

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.

THOR Lite – Free YARA and IOC Scanner

THOR Lite – Free YARA and IOC Scanner

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: 

  1. Reduced feature set
  2. Open source signature base

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.

Upgrading from SPARK Core

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. 

Issues

Please report problems in the issues section of THOR Lite’s helper scripts github page

Upcoming ASGARD Version 2

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

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.

THOR Integration into Microsoft Defender ATP

Why Integrate THOR into Microsoft Defender ATP

While Microsoft Defender ATP fully plays off its strength in detecting live attacks, suspicious process starts and network connections, THOR shines as a live forensic scanner that scans the local filesystem, registry, logs and other elements for traces of hacking activity.

While Microsoft Defender ATP features a forensic package collection that retrieves elements from a remote system, THOR scans these elements on the remote system, applying more than 10,000 hand-written YARA rules and thousands of filename, C2, hash, mutex and named pipe IOCs to them. This live forensic scan reduces the work of your forensic analysts to a minimum and generates results as fast as possible for you to react in a timely manner. 

THOR extends Microsoft Defender ATP’s real-time monitoring by intense local scans to allow a full on-demand compromise assessment.

Deployment Options

Due to the fact that both Microsoft Defender ATP and THOR are very flexible and open products, the integration is no one-lane road with a single possible solution. Depending on the network size, segmentation and available 3rd party solutions like a SIEM the integration allows and requires different setups.

This blog post starts with an example use case and then outlines many of these setup options.

Live Response Scripts

The Microsoft Defender Security Center allows us to upload PowerShell scripts into a so called “live response library”, which is available on the endpoint during “live response” sessions.

These scripts allow us to facilitate the download and execution of THOR on the endpoint.

There are two ways to implement different scan modes and parameters. THOR has numerous command line options, which can be passed either as parameters of the PowerShell scripts or predefined in YAML config files.

Example: Turla Malware

We’ll use a simple demo script that contains a path to a file share providing the THOR package. 

It uses a config file named “rootkit-check.yml”, which is located in the program folder on the file share. It activates 3 rootkit related modules, sets the path for all output files as rebase-dir and deactivates some features. 

We upload that script into a live response session to investigate suspicious behaviour of a workstation that showed several alerts regarding a malware and the use of a “living-off-the-land” binary to run malicious code. 

The details reveal that the use of certutil.exe triggered the alert.

We can see other commands like tasklist, net and netstat, which are often used in reconnaissance scripts, executed in the context of a user named “admin”. 

We start a “Live Response Session” for further live forensic investigations with the help of THOR. 

Since this is our first investigation with that specific script, we have to upload it to the live response library. 

We can then verify the upload using the “library” command and run the script from the command line. 

It takes about a minute to complete the Rootkit check.

THOR recognized a malicious mutex used by Turla malware and gives further information on the related process and process binary, which can be used for additional verification of the threat. 

The HTML report and text log file have been saved back to the file share.

Other Setup Options

Scanner Provisioning

In this chapter we describe different methods to provide a THOR package to an end system during live response investigations.

Option A: File Share

The complete THOR package including binaries and signatures can be provided on a network share. This network share should be read-only to avoid that attackers notice the activity and manipulate the program or signatures on the file share.

Advantages:

  • Quick setup
  • Only a file server is needed

Disadvantages:

  • Requires SMB/CIFS connection from end system to file share
  • Scanner / signature updates must be scripted (thor-util.exe)
  • Manual license generation (in Nextron’s customer portal) or expensive IR license (not host-based)

Option B: ASGARD Management Center

The central management platform ASGARD Management Center is hardened Debian-based soft appliance that serves as software repository and licensing server in our use case.

The PowerShell scripts in the script library can retrieve THOR packages via HTTPS from the ASGARD Management Center.

Advantages:

  • HTTPS download of THOR packages
  • Integrated licensing
  • Automatic scanner and signature updates

Disadvantages:

  • Additional server system (VM; maintenance)

Option C: THOR via Script Library as SFX

The complete THOR program folder can be packaged into a self-extracting & executing archive (SFX), which could then be uploaded into the “live response library”. It could then be executed right from the script library (run) or uploaded to the end system (put).

Advantages:

  • No servers needed
  • Microsoft Defender ATP native solution

Disadvantages:

  • Scanner / signature updates and SFX creation must be scripted on an analyst system (thor-util.exe)
  • Manual license generation (in Nextron’s customer portal) or expensive IR license (not host-based)

Output Options

The results of the scans can be stored and transmitted to different locations.

Option A: Log and Report on File Share

THOR writes a log file in real-time during the scan and renders an HTML report at the end of the scan. Users can set an output directory other than the working directory for all output files with the “–rebase-dir” parameter.

This output folder can be a file share, e.g. “\\server\share”.

Analysts can check the log file during the scan, which takes between minutes and hours to complete.

Advantages:

  • Only a file server required

Disadvantages:

  • Requires access to file share from the end system (SMB/CIFS)
  • File share must be writable (possible manipulation by the attackers)

Option B: SYSLOG, JSON or CEF to SIEM

THOR can send the logs via SYSLOG (UDP, TCP, TCP+SSL, CEF) or in JSON (UDP, TCP, TCP+SSL) to a remote SIEM or log management system.

Advantages:

  • Integrates into existing solution and processes

Disadvantages:

  • Requires SIEM system and some base-lining
  • Requires connection to port 514 from end system to SIEM system

Option C: SYSLOG, JSON or CEF to ASGARD Analysis Cockpit

ASGARD Analysis Cockpit is the optimized log analysis platform (soft appliance) to process, baseline and forward THOR logs.

It most relevant features in this use case are:

  • Base-lining and central false positive filtering
  • Event forwarding of filtered events

ASGARD Analysis Cockpit already has several options to create alerts for incoming logs.

Similar to the current “Webhook” output, Analysis Cockpit could add a feature to connect with Microsoft Defender Security Center and create Alerts as described in the official API documentation.

Advantages:

  • Optimal THOR log base-lining and forwarding of relevant events only

Disadvantages:

  • Additional server system (VM; maintenance)
  • Requires connection to port 514 from end system to Analysis Cockpit

Option D: Local Eventlog

THOR can be instructed to log to the local Windows Eventlog with the “—eventlog” command line parameter. Customers that already forward their Windows Application Eventlog to a central SIEM could then use the existing integration and analyze the THOR events in their SIEM.

Advantages:

  • Integrates into existing security monitoring
  • No additional open port needed

Disadvantages:

  • Requires SIEM system and some base-lining

Option E: Live Response – “getfile”

Local log files that were written to the working directory can be retrieved with the “getfile” command.

Advantages:

  • Integrates into analyst workflow
  • No additional open port needed

Disadvantages:

  • Files could be left on the end system
    (causing false positives in other products; in plain sight for attackers)

Future Integrations

This chapter contains an outlook on expected future integrations based on upcoming features and APIs. 

Sample Collection

The Microsoft Defender ATP API allows to fetch a certain file from a remote system. Similar to the alerting mechanisms via Webhooks in ASGARD Analysis Cockpit, users will be able to fetch any suspicious or malicious file reported by THOR with a given minimum threat score using the Microsoft Defender ATP API. 

THOR Cloud

The upcoming cloud based version of our licensing and download server, which is currently integrated into our customer portal, will be able to serve THOR packages that contain an integrated license for the host which is supposed to be scanned

This way, you will we be able to run a PowerShell script from the live response library that downloads an up-to-date THOR package with a valid license file right from the new online service and don’t need a local ASGARD server that provides the THOR packages and licenses.