With the upcoming version 8.53 of THOR, we’re testing a new feature called “Difference” or “Diff” mode (–diff).
The idea behind “Diff” mode is that a scan could be much faster, if it would only consider elements that have been created or changed since the last scan on that system. We can apply this principle to various modules and increase scan speed massively.
Diff mode is currently supported in the long running modules
Filesystem – files with MAC timestamps older than the last scan (start) will be skipped
Registry – registry keys with last modification dates older than the last scan (start) will be skipped
Eventlog – runs until it reaches eventlog entries with timestamps older than the last scan (start)
Diff mode requires the use of THOR DB, which is the default but could have been disabled with “–nothordb”. This is necessary to determine information from the last scan, e.g. “when did it start” but also “which modules were used in the last scan”.
The main advantage is an incredible fast scan. Our tests showed that scans in “Diff” mode complete within 5 and 15 minutes. In “Diff” mode, the longest running module is “ProcessCheck” with run times between 3 and 6 minutes.
The main disadvantage of “Diff” mode is the inability to detect Timestomping attacks, in which attackers or malware changes the timestamps of files and other elements.
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:
Log lines that are automatically assigned to an existing case
Status changes of cases
The current supported actions are:
Syslog Forwarding
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.
ASGARD features a new section since the last upgrade that you may have missed. It’s called “Downloads” and contains a section in which you can configure a download link for scanner packages.
In previous versions, the scanners have been accessible right from the login screen without any authentication, just like the GRR agents, which are still accessible in that way.
We’ve removed these unauthenticated scanner downloads and created that new “Downloads” section, which can be used by authenticated users in different ways.
While selecting different options in the form, the download link changes.
After you have selected the correct scanner, operating system and target hostname (not FQDN), you can copy the download link and use it to retrieve a full scanner package with included license file for that host. These download links can be send to administrators or team members that don’t have access to ASGARD management center. Remember that the recipients of that link still need to be able to reach ASGARD’s web server port 443/tcp.
If you don’t set a hostname in the “Target Hostname” field, the scanner package will not contain a license file. If you have an unlimited “Enterprise” license, you’ll have to provide it separately.
Use Case 1 – Provide Download Links
You can generate download links for the different scanner packages without included license for yourself or the administration team. A valid license (e.g. “Enterprise” or “Incident Response”) has to be provided and placed in the program folder. You can also use “thor-util” to retrieve licenses for specific hostnames from an ASGARD server (see the “THOR_Util_Manual.pdf” in each scanners “./docs” folder for details)
Use Case 2 – Administrator Asked to Run a Scan
You can copy the final download link and send it to an administrator, which can use this link on one of the servers to retrieve a full scanner package with license and run a scan.
Use Case 3 – Use the URL in Script
You can use the URL in Bash or PowerShell scripts to automate scan runs on systems without installed ASGARD agent. Replace the hostname value with the value of the current host on which the script runs to get a URL for scanner download package with a host-specific license.
SPARK Version 1.17.0 adds extensive STIXv2 support.
This allows you to easily extend SPARK’s signature bases with IOCs from any sandbox, analysis or threat intel platforms that support STIXv2 export by placing the exported *.json files in the ./custom-signatures folder.
For now, the supported observable object types are:
file:name with =!=LIKE and MATCHES
file:parent_directory_ref.path with =!=LIKE and MATCHES
file:hashes.sha-256 / file:hashes.sha256 with = and !=
file:hashes.sha-1 / file:hashes.sha1 with = and !=
file:hashes.md-5 / file:hashes.md5 with = and !=
file:size with <<=>>==!=
file:created with <<=>>==!=
file:modified with <<=>>==!=
file:accessed with <<=>>==!=
win-registry-key:key with =!=LIKE and MATCHES
win-registry-key:values.name with =!=LIKE and MATCHES
win-registry-key:values.data with =!=LIKE and MATCHES
win-registry-key:values.modified_time with <<=>>==!=
These types are applied in different modules:
FileScan: file:*
Registry: win-registry-key:* and file:name (applied to data field)
You can find a list of products that support the STIX data exchange format here.
As we have announced in May, the old “thor-upgrade.exe” is already out-of-support and the old update servers accessed by “thor-upgrade.exe” will be decommissioned at the end of October.
The new all-round utility “thor-util.exe” now supports all of the features provided by the old “thor-upgrade.exe” including NTLM Authentication with corporate proxy servers.
You can use “thor-util.exe upgrade –help” to see all options of the “upgrade” feature.
Also note that “thor-util” has an “encrypt” feature that allows you to encrypt custom signature files and the “report” feature that creates HTML reports from plain text log files.
The only valid update servers that should be accessible to get updates from November onward are:
update1.nextron-systems.com
update2.nextron-systems.com
The “thor-util” utility is part of the THOR and SPARK packages and can also be downloaded from the Customer Portal in the “Downloads” section.
If you are a customer and don’t have access to the Customer Portal yet, please contact us or the respective partner.
The new THOR-util version 1.2.4 supports the encryption of your custom signatures so that you can deploy your own IOC files and YARA rules in an encrypted form.
We use a public key in the utilities to encrypt the files for our scanners so that admins, Antivirus engines and attackers won’t be able to read the contents of the files.
The feature is also available in SPARK Core, our free scanner.
After encryption, place the encrypted IOC files in the “./custom-signatures” directory and the encrypted YARA rules in the “./custom-signatures/yara” directory.
The use of the function is simple. Just point it to a file, a list of files or use wildcards to select a set of files for encryption. The extension of the output file depends on the extension of the input file.
The upcoming ASGARD version 1.5 comes with a IOC management section in which you can manage your own set of IOCs in text files, YARA and Sigma rules.
You can then select each of the folders when creating a new scan run with THOR or SPARK. Selecting one of these folders will not include the sub folders.
You can schedule and run scans with different IOC, Sigma and YARA rule sets. You can review the included custom signatures in the scan details.
The following features are not yet implemented in v1.5 but on the roadmap for ASGARD v1.6:
Signature verification
Exclude the standard rule set (shipped with THOR and SPARK)
There are a few relevant changes in the upcoming THOR version 8.49.0 that we would like to announce.
Interpreter and Module Upgrades
The integrated Python interpreter will be upgraded to Version 2.7.15. We have also upgraded several modules. All our tests showed no signs of problems even with the oldest Windows version like Windows 2003 Server. (officially unsupported)
If you encounter any issues, please let us know.
4th Generation License Format Support
THOR 8.49.0 supports the newest license format which allows us to:
set a start date for the period of validity
enable or disable certain modules and features in THOR and SPARK
(e.g. we could license a SPARK version that only scans endpoint logs with Sigma rules)
THOR-util Report Generation
The new included THOR-util version 1.2 allows to generate HTML reports from scan log files. It can also generate reports for a directory that contains THOR or SPARK scan logs (up to 50 per HTML report). We’ve discussed this feature in detail in a previous blog post.
Noresume Becomes the New Default
The Scan Resume feature has caused many problems during incident response engagements in the past. The feature activates a journal in THOR DB that tracks the state of the scan and resumes the scan automatically if it was interrupted by a user or terminated due to a system shutdown. This feature seemed to be helpful but actually caused some problems.
THOR logs are created in “write” (w) mode, not in “append” (a) mode. When an administrator started THOR on a system, terminated the scan and then restarted it shortly after, the first part of the local log file was overwritten by the second scan. Sometimes a scan was interrupted on a system due to different reasons. When an administrator received the order to start a new scan on that system, the scan resumed the last scan and the log file and report contained only info of the resumed part of the scan.
We therefore decided to not resume scans by default. If you still want to maintain the old behaviour, please use the new “–resume” parameter. The old “–noresume” parameter is still valid but has no effect and is marked “obsolete” in the help.
Analysis Cockpit Web Session
We’ve just recently published a web session that gives an overview on our whole product portfolio and describes the features of our Analysis Cockpit in detail. (18 minutes, English language)
The main features of the Analysis Cockpit are:
THOR / SPARK Log Baselining
Automatic case creation based on similarities of the events
Sigma is a rule format for threat detection in log files. It is for log data what “Snort rules” are for network traffic or “YARA signatures” are for file data. It is easy to write and read. Writing a Sigma rule is a matter of minutes.
On the right you can see a simple Sigma rule that checks the “System” eventlog for traces of password dumper activity. The detection section contains 1+ identifiers (selection, keywords, quarkspwdump) that can be defined freely by the rule author. These selectors are used in the condition to build the rule.
It also contains a description, references, possible false positives and a level.
Analysts use Sigma to generate search queries for their SIEM or log management solution. The Sigma repo contains a converter that allows to convert the generic rules to ElasticSearch, Splunk, QRadar, Logpoint, Windows Defender ATP (WDATP) and ArcSight.
Wouldn’t it be great if you could apply Sigma rules on the endpoint?
Well, the upcoming version 1.14 of SPARK, which will be released at the end of July, does that. It applies Sigma rules to the local Eventlog. This way you’re able to apply searches that you have once defined for your SIEM to the local Eventlogs.
This way you are able “query” the standalone systems that are not connected to your SIEM and uncover otherwise common blind spots in your environment.
We ship the current rule set, which is part of the public Sigma repository and contains more than 200 rules with our SPARK program package in an encrypted form. (*.yms)
You can add your own Sigma rules to the “./custom-signatures/sigma/” folder in the SPARK program directory.
To activate Sigma scanning, use the new “–sigma” parameter.
Currently only SPARK supports this feature and there are no plans to implement this in THOR as well.
The feature is currently free for all customers but may become a premium feature that has to be licensed separately by the end of the year depending on the customer’s plan.
See the comparison table for a complete overview on all features.
The new version of “thor-util” (used with THOR/SPARK) / “spark-core-util” (used with SPARK Core) support a feature that allows a user to convert any scanner log file into a convenient report.
Convert THOR / SPARK / SPARK Core scan logs into HTML reports
Convert a single text log file into an HTML report
Convert multiple log files (50 max.) in a directory into a single HTML report
Provide a file with filters to suppress false positives in the reports
Even LOKI logs can be converted (no support)
Hash values linked to Virustotal searches
IP values linked to VirusTotal searches
Header sections linked to elements via ankers
You can access this feature in the upcoming enterprise products (THOR 8.47.2 and SPARK 1.13) and the free product SPARK Core (SPARK Core 1.13).
The following screenshot shows a typical text log file. It can be processed in log analysis solutions but it is difficult to read for an analyst. Most analysts search these log files for “(Alert|Warning):” or use grep to get the most relevant messages.
Our tools “thor-util” and “spark-core-util” will help you with this task.
