ASGARD v2.13 Release

Over the last 4 months, we’ve worked on many new UX improvements and the integration of our endpoint agent Aurora. Today, we are glad to announce the release of ASGARD version 2.13. 

UX Improvements

We’ve reworked many sections and dialogues with user experience (UX) in mind. 

Overall, we’ve made more than 260 changes, reworked complete sections and dialogues and added completely new functions like the new “diagnostics”. 

Some of highlights:

  • Each THOR scan now shows a progress bar that doesn’t only show the state of completion but also the current module and element, the module progress and the amount of time spent on this module. This can help you to identify bottlenecks, issues or elements that should better be excluded from the scan.
  • All tables now have an option for an auto-refresh, which can be set per user and table (persistent setting by user)
  • The new diagnostics section helps you to quickly identify connectivity or configuration issues
  • Export and Import of Scan Templates
  • Reworked THOR download section, which allows to generate links for the “latest available version” and shows an information on the API endpoint usage
  • Improved agent installer repackaging options (e.g. repack all outdated installers)
  • Many dialogues with additional error handling of common user errors

Some of the planned UX improvements are still on the roadmap and will be part of the next update. These include: 

  • More flexible group scan target selection (combine labels with AND instead of OR, filter selection for labels to exclude)
  • Maintenance section in which users can define clean-up rules for old data (remove old assets, automatically remove old log data etc.)

 

 

Scan Progress Bar (Single Scan)

Scan Progress Bar (Group Scan; Collapsed Info)

Auto Refresh Options

System Diagnostics

Background Load Indicators (green line)

Export & Import of Scan Templates

Reworked THOR Download Section (generate link for the latest version, information about the use of the tokens)

Improved Agent Installer Repackaging Options

Aurora Agent Support

This version allows the deployment and management of our Sigma-based endpoint agent.

You can find information about Aurora here.

ASGARD Management Center allows you to:

  • Manage rules that you want to use
  • Add false positive filters to rules
  • Define response actions for certain rules
  • Manage updates on these rules
  • Group rules into rule sets
  • Use rule sets in an Aurora configurations
  • Assign configurations to groups of end systems
  • Put all response actions in a configuration into simulation mode
  • Put single response actions in simulation mode
  • Manage rules that have been in simulation mode for a certain time
  • Apply so-called response sets (groups of response actions provided by Nextron) to your rule set
  • Apply your IOCs or IOCs retrieved from a MISP instance with Aurora

Aurora Agents (Deployed)

Sigma Rule Set Management

Aurora Agent Configurations

More changes in this release

  • AIX support (beta users only)
  • Collect THOR log as JSON (optional)
  • New section “Playbook Files” to manage all files and tools used in playbooks
  • License expiration warning messages
  • many more – see the changelog for all details

Upgrade

ASGARD Management Center customers upgrade their instances in “Updates > Management Center”. 
Important: Make sure to upgrade Master ASGARD instances before upgrading the connected ASGARDs. 

ASGARD v2.12 Released

The new ASGARD Management Center version 2.12 adds new features and fixes several issues that were introduced with the version 2.11 in December last year.

Better Sigma Rule Management

We’ve added new features and improved the usability of the sigma rule management section, which is relevant for the released LogWatcher agent and beta customers testing our new Aurora agent.

 The most important new features are the false positive and response editor, which allows Aurora customers to configure response actions for a triggering rule. 

The false positive filter enables users to add filters that, instead of changing the  original rule, extend it during deployment. This makes it easy to use updated rules with the same custom filter values that are only relevant in the user’s environment. 

Revised Updates Section

The update section for the scanners and signatures has been revised. Each action has been reworked. Users can now trigger and update manually and check the log of the update process in a separate tab. 

Full change log:

– Feature: Support Aurora Agent (Beta Only)
– Feature: Manage Sigma Responses and False Positives (Aurora Only)
– Feature: Enable / Disable Sigma Rules
– Feature: Manually check for THOR and Signature Updates
– Feature: Show log of previous update process
– Feature: Auto Config for Sigma Rulesets (Automatically add new Sigma Rules based on level)
– Feature: The UI now has a lot more indicators for e.g. ‘Asset Requests’, ‘Uncompiled Rulesets’ and more
– Feature: Added more graphs to overview page, e.g. incoming Aurora and Log Watcher events
– Feature: Added bulk update for available Sigma rule updates
– Feature: Added default Sigma Rulesets (if no ruleset has been created yet)
– Feature: Added background routine that removes older and unused THOR / Signature versions
– Feature: Edit Scan Templates
– Feature: Search THOR Flags / Aurora Options
– Feature: Download THOR Zip with target hostname as filename
– Change: Improved Server Status indicators
– Change: Improved licensing
– Change: LDAP users require at least one LDAP role, otherwise they are not authenticated anymore
– Change: Updated Sigma rules
– Change: Cosmetics and UX improvements
– Change: Updated default THOR and Signature auto-update config
– Change: Added more links and password reset help to login page
– Change: Improved usability and feedback in IOC Management section
– Change: Require current password for password change
– Bugfix: Re-added and improved “no labels” filter in assets table
– Bugfix: Re-added resize buttons for Remote Console
– Bugfix: Fixed an issue that causes some API keys to be corrupt
– Bugfix: Fixed non-working ‘Install Service Controller’ playbook on Master ASGARD
– Bugfix: Updated interrogate job to detect ‘Windows 11’ correctly
– Bugfix: Fixed corrupt ‘Is Domain Controller: No’ filter
– Bugfix: Fixed missing default value when editing Sigma or YARA rules in IOC Management
– Bugfix: Fixed non-working “use newer Sigma rule” button
– Bugfix: Fixed CRLF issues in IOC Management for some IOC types
– Bugfix: Fixed some missing MISP iocs in THOR download package
– Bugfix: Fixed permissions on some files that caused backup process of ASGARD config files on Master ASGARD to not work properly
– Bugfix: Fixed encryption issues with custom signatures for THOR Lite
– Bugfix: Fixed missing import in ntp config that causes ntp to not work properly on some ASGARDs
– Bugfix: Fixed tasks that are pending forever due to unknown task module
– Bugfix: Fixed non-working rsyslog reload after monthly logrotation
– Bugfix: Fixed wrong file extension of stdout and stderr file in group task result package

To install the update, visit the “Updates > Management Center” section. 

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.

 

ASGARD: Check your Signature Versions

It came to our attention that under certain circumstances, after the upgrade to ASGARD 2.11, some ASGARD instances lost their scheduled task to automatically assign the newest signatures to scan jobs . We advice customers to review their update configuration if they are affected. Go to Updates > Scanners and Signatures. If you are affected the column ‘Automatically use newest version’ shows ‘not configured’.

In order to resolve this issue, you need to schedule a time for signature updates. Use the action button with the clock icon. We recommend an interval of 1 day (see the screenshot).

After you have entered the new schedule, you should see the configured date and interval in the “Automatically use newest revision” column.

The same mechanism is used to configure when new THOR versions should be used for scans. We recommend to use the default, which is also a daily update interval.

Log4j Evaluations with ASGARD

We’ve created two ASGARD playbooks that can help you find Log4j libraries affected by CVE-2021-44228 (log4shell) and CVE-2021-45046 in your environment. 

Both playbooks can be found in our public Github repository

We’ve created a playbook named “log4j-analysis” that helps you find instances that use versions of “log4j”. An additional evaluation script can be used to process the ASGARD playbook results and distinguish between affected and unaffected versions. 

Another playbook named “log4shell-detector” allows you to run a script provided by our head of research on all Linux systems to detect exploitation attempts in log files.

The results of the evaluation script that processes the results of the “log4j-analysis” playbook look like this. 

ASGARD 2.11 Release

We are glad to announce a new ASGARD Management Center (AMC) release with exciting new features and improvements.

Sigma LogWatcher

LogWatcher is a new service that applies Sigma rules to Windows Eventlog entries. It uses the big public Sigma rule base and has access to the upcoming private Sigma rule feed maintained by Nextron Systems. It’s the first additional service that can be managed and configured in the new “Service Control” section. (add the “Service Control” right to roles to enable the section for these roles)

Improved LDAP Support

The new LDAP configuration now supports all kinds of different selection options to authenticate against Microsoft Active Directory.

Improved IOC Management

The IOC Management moved into the Scan Control section and now allows you to import single or groups of IOCs in a special interface that abstracts from the underlying format required by THOR.

A ruleset contains IOC groups which contain IOCs. Integrated checks verify the provided expressions and give you direct feedback. 

Persistent Column Settings per User

Each user can now configure the table views in each section according to their needs, which persist across sessions.

Performance Improvements

The new version improves the performance of large installations (>10,000 endpoints) significantly. 

THOR and THOR TechPreview Support

It’s now possible to scan with all kinds of THOR version, the current stable version Tech Preview versions and even THOR Lite. 

 

Before you update:

  • the upgrade can take up to one hour in large installations, so please wait and do not reboot during the installation
  • the API has been completely revised so that old API endpoints that you currently use may not work anymore
  • to prevent an inconsistent state, you have to upgrade the Master ASGARD before upgrading the connected ASGARDs

More changes:

  • improved stability and error handling of THOR scans
  • extended CSV output and availability in many more sections
  • requirements for password complexity has been increased

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

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. 

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.

WordPress Cookie Plugin by Real Cookie Banner