New Analysis Cockpit 3.5

New Baselining Views

Over the course of the last 18 months we reviewed most of our detections regarding their success in real world scenarios. In this context “success” means, that the detection uncovered malicious activity in the wild and at the same time had a low anomaly and false positive rate. Additionally we also consider a detection to be successful that caused little or no false positives or anomalies.

All this lead to two new views within the Cockpit’s Baselining section: “Compromise Assessment Mode” and “Deep Inspection Mode”.

“Compromise Assessment Mode” includes only matches of the highly successful rules. The second mode is the “Deep Inspection Mode”. This view is basically how it used to be (the old default view). It shows all Alerts and Warnings unless they are already part of an existing case.

This new “Compromise Assessment Mode” dramatically reduces our customer’s baselining effort.

In our tests we noticed a decrease of events in the Baselining section of more than 90%. We believe that especially entities that follow our “Continuous Compromise Assessment” approach should switch into this new mode. We’ve also challenged the new mode with the post exploitation tools and techniques found in the context of HAFNIUM / Exchange exploitations in March 2021 and covered almost every aspect of the attacks in the new view.

Asset Labels

Another exciting new feature that comes with Analysis Cockpit version 3.5 is an event filter based on asset labels. This was requested by many of our customers and partners, but until now we never found a way to deliver this feature without negatively affecting the Cockpit’s performance. We solved this now by allowing two limitations to this feature. It doesn’t work for events that existed prior to the update. Secondly an event always remains linked to the asset label it had at the time the event occurred. Changing an assets label will only affect events from scans that take place after the label change.

Other Changes

  • Hidden static filters in certain views
  • Minor bugfixes and stability improvements

Release

The new Analysis Cockpit will be released in the 2nd half of August. Interested customers can get a guide to use the “preprod” version of Analysis Cockpit 3.5. 

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.

 

End-of-Life ASGARD Analysis Cockpit Version 2

Nextron announces the end-of-sale and end-of-life dates for the ASGARD Analysis Cockpit version 2. Customers with active service contracts will continue to receive support until June 30, 2022, as shown in the table below.

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. 06.05.2021
End of Sale Date The product is no longer for sale after this date. 30.04.2021
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.2022
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. 30.06.2022

ASGARD Analysis Cockpit Version 3

ASGARD Analysis Cockpit is our on-premise soft-appliance that helps you analyze large amounts of THOR log data. The new version 3, which has just been released, adds many new usability features and views. This blog post lists some of the changes. 

Analysis Cockpit 3 has a new look with many features that improve usability.

Filtering the log data to select a group of events to include into a case has never been easier. The search bar has been modified to support the most common use cases with feedback from numerous analysts. 

The idea is to allow a user reach a certain intended view with as few clicks and interactions as possible. 

New case creation forms, which are much more compact and add a new event selection type named “condition”. 

It adds many views focussed on assets like scans of each asset or findings per asset.

Extensive reporting section and for HTML and PDF reports

It allows to create reports

  • by business unit
  • comparison between time frames and group scans
  • highlights on lateral movement
  • highlights on remediated systems

Two-Factor-Authentication (2FA, OTP) and improved LDAP support

A new “Notifications” sections allows you to review all triggered notifications that have been sent via SYSLOG, E-mail oder Webhook to a remote system.

These notifications are configured by the user and may include e.g.

  • New event added to incident case
  • Case type changed from “open” to “request evidence”

Other improvements:

  • Massive performance improvements
  • Improved API for SOAR, Sandbox, SIEM integration
  • Views for real-time events generated by ASGARD’s 2.10 new Eventlog watcher with Sigma rules
  • Provides additional endpoint related information like installed software and list of local users (Windows only)
  • Improved flexibility in case management section 
  • Sidebar with context information
  • CSV exports from almost any view
  • Direct Virustotal & Valhalla lookups from the event details

ASGARD Analysis Cockpit version 3 has been released this month. An upgrade from Analysis Cockpit version 2 is possible and includes an export of the case data and re-import of all previously indexed log data with the help of a guide that is part of the new online manual. New customers find the installer ISO in the “Downloads” section of the customer portal.

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.

ASGARD Analysis Cockpit v2.8 with Sandbox Integration

ASGARD Analysis Cockpit’s new version 2.8.2 features an open API to interface with all major sandbox vendors.

It ships with presets for Cuckoo Sandbox and even allows to connect multiple different sandboxes at the same time.  

Today users can configure THOR scans in the ASGARD Management Center that collect suspicious files with a given minimum score.

(side note: a clever mechanism in Bifrost protocol v2 collects only files that have not been collected before)

The new version of Analysis Cockpit will automatically receive these samples once it gets connected to an ASGARD Management Center.

 

With a connected Sandbox, you can decide to send <all> incoming samples to Sandbox or drop only selected samples manually.  

Analysis Cockpit’s “Sandbox” section shows all collected samples, the affected hosts, hashes, filenames and other data in the “Files” tab. 

 

The “Reports” tab contains results from each sandbox run. 

Each event in “Baselining” section shows an available sandbox report if a hash in the event matches with one of a sample that has been analyzed by the sandbox. 

The Analysis Cockpit API allows the retrieval of collected sample files and the upload of any type of report. 

ASGARD Analysis Cockpit 2.2 Feature Overview

Later this month the new version 2.2 of ASGARD Analysis Cockpit will be released. These are the most important new features.

The Optimize Button

The new “Optimize” button allows you to add all unassigned log lines to existing cases with matching filters. It is possible that you miss some events when creating a new case, either by the wrong selection or due to the fact that new log lines can arrive at any time via SYSLOG or log file import in the background.

Now it is possible to add all unassigned log lines to previously created cases by using the “Optimize” button.   

It will not remove previously assigned log lines from existing cases. It just helps you to clear up the base lining section by removing events that are related to existing cases but haven’t been assigned to these cases yet.

You can later review all automatic assignments in the “Automatic Event Assignment” protocol.

Notification Settings

The new “notification” settings allow you to create notification rules for the following type of events:

  1. Log lines that are automatically assigned to an existing case
  2. Status changes of cases

The current supported actions are:

  1. Syslog Forwarding
  2. Email Notification

This allows you to define flexible rules for many different events. You may e.g. create a rule that sends an email notification whenever a new “Incident” case is opened. 

You could also forward all incoming log lines that are automatically assigned to a case of type “Incident” to your remote SIEM system. (each syslog message will be extended by two new fields: case_type and case_id)

An email for a opened “Incident” case will then look like this:

The attachments of these emails contain the included log lines (text) and a JSON with all case information in machine readable form.

File Importer

The File Importer status view has been improved so that it shows the number of total files in queue and the number of processed files.

Improved Reporting

The new improved reporting allows you to generate reports not only for a given period of time (e.g. last month) but custom queries on the ElasticSearch database. E.g. you can generate report for the scans on your SuSE linux systems only. 

The reports contain more panels and information on the data set. 

The data from all reports can be downloaded as JSON file. 

Upgrade to 2.2

The upgrade will be visible in the “Updates” section of your Analysis Cockpit once it is released. See the change.log notes for a full list of changes. 

 

GDPR Cookie Consent with Real Cookie Banner