THOR Scanner User Manual

What is THOR?

THOR is a portable scanner for attacker tools and activity on suspicious or compromised server systems.

It covers a big set of basic checks and in deep analysis of the local event log, registry and file system. THOR aims to be a sensitive auditor noticing files and behavior traces a common Antivirus may have missed. An integrated "Scoring System" enables THOR to rate elements based on numerous characteristics to give hints on unknown malware.

THOR can be easily expanded to handle individual, client-specific attack patterns (e.g. the detection of specific malware files or certain log entries on the basis of a forensic analysis).

It is a portable and agent-less "APT Scanner".

THOR Coverage and Comparison to Antivirus and Intrusion Detection

The key features are:

Scans for hack tools and attacker activity (with multiple detection mechanisms)
Portable – no installation required
Runs on Windows, Linux and macOS platforms without any prerequisites
Adaptable to the specific tools and activity of new APT cases
Scoring System – providing a way to detect previously unknown software
Several Export Formats – Syslog (JSON/Key-Value/CEF), HTML, TXT, JSON, CSV
Throttling of the scan process to reduce the system load to a minimum

Package

The THOR Package includes the following files and directories:

	Files/Directories
THOR Binaries	thor.exe and thor64.exe, for 32-bit and 64-bit systems respectively
THOR Utility	thor-util.exe, Helper tool for updates, encryption, report generation, signature verification and other tasks – see THOR Util Manual
Configuration Files	In subfolder `./config` - (directory-excludes.cfg, sigma.yml, false_positive_filters.cfg)
Main Signature Database	In subfolder `./signatures`
Custom Signatures and Threat Intel IOCs	In subfolder `./custom-signatures`
THOR Changelog	changes.log
Additional Tools	In subfolder `./tools` - EXE packers and the Bifrost server script
THOR Manuals	In subfolder `./docs`

Requirements

THOR runs in any Windows, Linux and macOS environment without any further requirements. Everything needed is already included in the program package.

To use the full potential of THOR, you should execute it with administrative privileges - LOCAL_SYSTEM on Windows and root on Linux/macOS systems.

Operating Systems

The following operating systems and their versions are the minimum requirements to run THOR. Any newer version will also work with THOR.

Linux	Windows	macOS
RHEL/CentOS 6	Windows 7 x86/x64	macOS 10.14 (Mojave)
SuSE SLES 11	Windows Server 2008 R2	macOS 11 (Intel)
Ubuntu 16 LTS		macOS 11 (ARM, Apple M1)
Debian 9

Legacy Systems

These versions are scannable with THOR Legacy. The legacy version of THOR is usually running on those systems, but if you encounter any problems, we will not be able to fix them. Contact us for details on how to download and use THOR Legacy.

OS	Architecture	Support
Windows Server 2008	x86 and x64	yes
Windows Server 2003 SP2	x86 and x64	limited
Windows Server 2003 SP1	x86 and x64	limited
Windows Server 2003	x86 and x64	limited
Windows XP SP3	x86 and x64	limited
Windows XP SP2	x86 and x64	limited

THOR for AIX

We offer a special version for AIX. Currently only a small number of versions are supported. We are extensively testing THOR on AIX 7.2 with Power7/Power8. THOR for AIX will not run on older versions of AIX. If you are running a newer version and are interested in THOR for AIX, we can always provide a test license to verify if everything is working as expected.

Unsupported

VMWare ESX - https://kb.vmware.com/s/article/1036544
many others

If you need to perform an analysis on unsupported operating systems or architectures, contact us for a solution using THOR Thunderstorm and Thunderstorm collectors.

We have productive setups with our customers involving the file collection from:

SPARC Solaris
RHEL Linux 4
Citrix Netscaler
ICS environments with Windows XP embedded systems (planned)
VMWare ESX (see this blog post)

Update Servers

To download the newest updates for THOR and our signatures, you need an active internet connection. The endpoint performing the update needs to reach our update servers to do this.

For a detailed and up to date list of our update and licensing servers, please visit https://www.nextron-systems.com/hosts/.

Hint

You do not need an active internet connection to scan an endpoint. This is only needed if you want to update to the latest THOR and signature versions. There are special licenses for special circumstances, for example when the licensed system does not have internet access.

Before You Begin

Before you begin to use THOR for the first time, you should read through this section to get a better understanding of what is needed to use THOR.

In the following chapters you should learn how THOR works.

Add License File

Place a valid license file into the THOR program folder. THOR checks the program folder and all sub folder for valid license files (*.lic). Alternatively, you can specify a specific path with --licensepath <path>.

Tip

THOR is also able to fetch licenses from our licensing portal or a local ASGARD Management Center. Please see chapter License Retrieval for more information about license retrieval.

Generate a License

You can generate a valid license in our customer portal.

Navigate to Contracts & Licenses > My Contracts and choose the correct Contract Type to generate a new license. You can use THOR Workstation or THOR Server & Workstation as the License Type.

Here is an Overview of which type of license you need to use:

THOR Workstation
- Host-based THOR scanner license for Windows workstations and macOS only. Not usable on Windows servers or Linux systems, regardless of their actual usage (e.g. Linux Desktop systems). Usage on legacy systems, such as Windows XP, requires the legacy option.
THOR Server & Workstation
- Host-based THOR scanner license for scans on all end systems, workstations, servers, Windows, Linux, and macOS. Usage on legacy systems, like Windows 2003 or Windows 2008 before R2, requires the legacy option.

Click on the green Plus icon of your contract and fill all the mandatory fields. After clicking on Check Hostnames, you can issue the license if all the hostnames are unique and valid.

For the license generation it is necessary to use the hostname of the system which will run THOR. On Windows system you should use the computername as hostname during license creation:

C:\Users\nextron>echo %COMPUTERNAME%
WIN11-TESTING

On Linux use the hostname command:

nextron@unix:~$ hostname
unix

On macOS use the following command:

MacBook:~ nextron$ sysctl kern.hostname
MacBook

Some more remarks regarding the hostname values:

Use only the hostname of a FQDN (master1 of master1.internal.net)
The casing of the letters doesn't matter (case-insensitive)
We do not store the hostnames anywhere in our portal

After you issued your license, your browser will forward you to the Licenses section of the portal. You will be able to see all the issued licenses for the contract you just used earlier. You can either download a single License, a License Bundle, which contains all the selected licenses in one zip file, or a Software + License Bundle, which contains the correct THOR version plus your license(s). If you want to see all your issued licenses for all of your contracts, you can remove the filter on the top which says Contract: xyz.

About License Files

THOR processes its program folder and all sub folders in search for a valid license file with a .lic extension, and picks the first valid license it can find.

This change has been made to facilitate the rollout using the new host based license model.

You can now generate licenses for a big set of systems, store all the licenses as thor-system1.lic, this-system2.lic" and so on in a sub folder ./licenses and transfer the THOR program folder with the "licenses" sub folder to all the different systems, for which you have generated licenses and just run the thor.exe executable.

Upgrade THOR and Update The Signatures

Run the following command to update THOR and its signatures:

Windows:

C:\nextron\thor>thor-util.exe upgrade
Jan 10 09:24:20 win11-testing THOR_UTIL: Info: Read configuration from C:\nextron\thor\config\thor-util.yml

    ________ ______  ___    __  ______________
   /_  __/ // / __ \/ _ \  / / / /_  __/  _/ /
    / / / _  / /_/ / , _/ / /_/ / / / _/ // /__
   /_/ /_//_/\____/_/|_|  \____/ /_/ /___/____/

   Copyright by Nextron Systems GmbH, 2021
   v1.10.6+thor10.6.19

Jan 10 09:24:20 win11-testing THOR_UTIL: Info: Starting Upgrade Process
Jan 10 09:24:20 win11-testing THOR_UTIL: Info: License file found OWNER: Rick Roll TYPE: client STARTS: 2022/08/09 EXPIRES: 2023/08/09
Jan 10 09:24:20 win11-testing THOR_UTIL: Info: Downloading 'thor-win'
Jan 10 09:24:20 win11-testing THOR_UTIL: Info: Downloading from: https://update1.nextron-systems.com/getupdate.php?full=1&lic=00000000000000000000000000000000&product=thor10-win&thorupgrader=1.10.6%2Bthor10.6.19&thorversion=10.6.19&upgrade_only=1
Jan 10 09:24:20 win11-testing THOR_UTIL: Info: already up-to-date
Jan 10 09:24:20 win11-testing THOR_UTIL: Info: THOR 10 detected, also updating signatures ...
Jan 10 09:24:20 win11-testing THOR_UTIL: Info: Starting Upgrade Process
Jan 10 09:24:20 win11-testing THOR_UTIL: Info: License file found OWNER: Rick Roll TYPE: client STARTS: 2022/08/09 EXPIRES: 2023/08/09
Jan 10 09:24:21 win11-testing THOR_UTIL: Info: Downloading 'signatures'
Jan 10 09:24:21 win11-testing THOR_UTIL: Info: Downloading from: https://update1.nextron-systems.com/getupdate.php?full=1&lic=00000000000000000000000000000000&product=signatures&thorupgrader=1.10.6%2Bthor10.6.19&thorversion=23.1.5-122954&upgrade_only=1
Jan 10 09:24:21 win11-testing THOR_UTIL: Info: downloaded package as zip
Jan 10 09:24:28 win11-testing THOR_UTIL: Info: Successfully upgraded from Signatures 23.1.5-122954 to Signatures 23.1.9-153938

Linux:

nextron@unix:~/Documents/thor$ ./thor-util upgrade
Jan 10 09:33:10 unix THOR_UTIL: Info: Read configuration from /home/nextron/Documents/thor/config/thor-util.yml

    ________ ______  ___    __  ______________
   /_  __/ // / __ \/ _ \  / / / /_  __/  _/ /
    / / / _  / /_/ / , _/ / /_/ / / / _/ // /__
   /_/ /_//_/\____/_/|_|  \____/ /_/ /___/____/

   Copyright by Nextron Systems GmbH, 2021
   v1.10.6+thor10.6.19

Jan 10 09:33:10 unix THOR_UTIL: Info: Starting Upgrade Process
Jan 10 09:33:10 unix THOR_UTIL: Info: License file found OWNER: Rick Roll TYPE: client STARTS: 2023/01/10 EXPIRES: 2023/08/14
Jan 10 09:33:10 unix THOR_UTIL: Info: Downloading 'thor-linux'
Jan 10 09:33:10 unix THOR_UTIL: Info: Downloading from: https://update1.nextron-systems.com/getupdate.php?full=1&lic=00000000000000000000000000000000&product=thor10-linux&thorupgrader=1.10.6%2Bthor10.6.19&thorversion=10.6.19&upgrade_only=1
Jan 10 09:33:11 unix THOR_UTIL: Info: already up-to-date
Jan 10 09:33:11 unix THOR_UTIL: Info: THOR 10 detected, also updating signatures ...
Jan 10 09:33:11 unix THOR_UTIL: Info: Starting Upgrade Process
Jan 10 09:33:11 unix THOR_UTIL: Info: License file found OWNER: Rick Roll TYPE: client STARTS: 2023/01/10 EXPIRES: 2023/08/14
Jan 10 09:33:11 unix THOR_UTIL: Info: Downloading 'signatures'
Jan 10 09:33:11 unix THOR_UTIL: Info: Downloading from: https://update1.nextron-systems.com/getupdate.php?full=1&lic=00000000000000000000000000000000&product=signatures&thorupgrader=1.10.6%2Bthor10.6.19&thorversion=23.1.9-153938&upgrade_only=1
Jan 10 09:33:11 unix THOR_UTIL: Info: already up-to-date

It is important that you update THOR after you have downloaded it from the customer portal, since the packages do not contain the newest signature files. (caused by internal integrity checks)

Note

The upgrade requires a valid license for the host that performs the update. If you don't want to use a license for that host, ask us for a silent license, which can be used for all kinds of testing purposes and also allows to update THOR and its signatures.

Define an Antivirus / EDR Exclusion

Since THOR accesses different process memories and probes for malicious Mutex, Named Pipes and Event values, it is recommended to exclude THOR from Antivirus / EDR scanning.

The Antivirus exclusion could also lead to a significant runtime reduction, since access to processes memory and files will not get intercepted anymore.

Note

We see massive runtime changes with Windows Defender since April 2021 (+50-100%). It is highly recommended to exclude THOR from scanning when using Windows Defender.

The quickest way to add an exclusion on a single system is with the following command (change the path in -ExclusionProcess accordingly).

Windows command line:

C:\Users\nextron>powershell -ep bypass -Command "Add-MpPreference -ExclusionProcess 'c:\temp\thor\thor64.exe'"

PowerShell:

PS C:\Users\nextron> Add-MpPreference -ExclusionProcess 'c:\temp\thor\thor64.exe'

For more information visit https://docs.microsoft.com.

A Note on SentinelOne

The process memory of systems running SentinelOne is polluted with suspicious strings. The most prevalent false positive is related to the keyword "ReflectiveLoader", but any other rule can match as well.

It is unclear what SentinelOne does to the process memory of many system processes. We cannot exclude these signatures from the scan. Be aware that the results from the "ProcessCheck" module on a system running SentinelOne can contain many false positives.

A Note on McAfee

It is not an easy task to define exclusions for THOR in all the different services when running McAfee products. You have to exclude the process in different sections (AV, EDR, On-Access). We've compiled a list of exclusions for our ASGARD customers, which you can find here.

Choose The Right THOR Variant

We offer THOR in different variants.

THOR
THOR TechPreview
THOR Legacy (limited support and compatibility)

THOR

The default version of THOR is the most stable version, intensively tested and without any broadly tested performance and detection tweaks.

The default version should be used for:

Scan sweeps on hundreds or thousands of systems
Continuous compromise assessments on hundreds or thousands of systems
Systems with high requirements on stability

THOR TechPreview

The TechPreview version is focussed on detection and speed. This blog post contains more information on the differences.

The TechPreview version should be used for:

Digital forensic lab scanning
Dropzone mode scanning
Image scanning
THOR Thunderstorm setups
Single system live forensics on systems that don't have highest priority on stability

You can find the information on how to get the TechPreview version in the THOR Util manual.

THOR Legacy

THOR Legacy is a stripped down version that includes all modules that can be used on outdated operating systems. This blog post contains more information on the legacy version.

The legacy version lacks:

Diagnostic features of THOR Util
UPX unpacking
ADS scanning
Module: Process scanning
Module: Eventlog scanning
Module: THOR Thunderstorm
Module: ETW Watcher
Module: Task scheduler
HTML report generation

Note

We only offer limited support for this version, since we cannot guarantee a successful stable scan on platforms that have already been deprecated.

To use THOR Legacy, you need a special license. Contact sales to get more information regarding Legacy licenses.

To download THOR Legacy, you can either download it directly from our portal (recommended; continue at step 5), or follow these steps:

Download a normal THOR package (non-legacy)
Use thor-util to download THOR Legacy:

thor-util.exe download --legacy -t thor10-win
You will get a zip file with the following name:

thor-win-10.6.20_<date>-<time>.zip
The content of this zip file should be as follows:
You can now transfer this package to your Legacy system. Please do an upgrade before you start using this:

thor-legacy-util.exe upgrade

thor-legacy-util.exe update
Place your Legacy license inside this folder and start using THOR Legacy

Choose The Right Architecture

You will find a 32 and 64 bit version of the executable in the program folder. Never run the 32bit version of THOR named thor.exe on 64bit system. The 32bit version has some limitations that the 64bit version doesn't have (memory usage, sees different folders on disk and registry versions).

Make sure to run the correct binary for your target architecture.

Choose The Right Command Line Flags

The recommended way to run THOR has already been put into the default. So, the recommended way to start a THOR is without any command line flags.

However, special circumstances can lead to different requirements and thus a different set of command line flags. See chapter Scan for often used flags.

Add Command Line Completions (optional)

Since version 10.7.15, THOR offers shell completions for browsing the flags. These completions can be generated by using:

thor-linux-64 --completions <bash/zsh/fish/powershell>

This generates a snippet for the specified shell that can be loaded for the current terminal using the following command, depending on your shell:

bash:

source <(thor-linux-64 --completions bash)
zsh:

source <(thor-linux-64 --completions zsh)
fish:

thor-linux-64 --completions fish | source
PowerShell:

thor64.exe --completions powershell | Out-String | Invoke-Expression

Verify Public Key Signatures (optional)

You can verify the executable files in the THOR package with

their digital signature (PE signature) issued by "Nextron Systems GmbH"
thor-util's "verify" feature
openssl verifying the integrity of executables manually

Find more information on THOR Util in its dedicated online manual.

Hint

THOR Util automatically verifies the signatures of the contained binaries in an update package and exits if one or more signatures cannot be verified. You don't have to check them manually unless you distrust the THOR Util itself. In this case, you can use the public key published on our web page.

After downloading the public key the signatures can be manually verified with the following command:

C:\Users\nextron>openssl dgst -sha256 -verify <Path to public key .pem> -signature <Path to signature .sig> <Path to the executable>

Example Windows:

C:\Users\nextron>openssl dgst -sha256 -verify codesign.pem -signature thor64.exe.sig thor64.exe
Verified OK

Example Linux:

user@unix:~/thor$ openssl sha256 -verify codesign.pem -signature thor-linux.sig thor-linux
Verified OK

Deployment

This chapter lists different ways to deploy THOR in an environment. Most of these methods are OS specific.

Licensing

In almost any method of deployment, the provision of valid licenses for the scanners on the endpoints is a core issue. Every license is limited to a certain host name. The only exception are the rare and relatively expensive "Incident Response" licenses.

In all other cases, a valid license has to be generated before a scan run.

There are numerous options to retrieve a valid license for a host.

With ASGARD:

use an ASGARD Agent
download THOR package with license from ASGARD's Downloads section
generate licenses in ASGARD's web GUI under Licensing > Generate Licenses
use THOR's --asgard and --asgard-token parameters to retrieve a license
use ASGARD's API to retrieve a license manually

Without ASGARD:

generate a license in the web GUI of the customer portal
use THOR's --portal-key and --portal-contracts parameters to retrieve a license from the customer portal
use the Customer Portal's API to retrieve a license manually

Some of the options are described in more detail in the following two chapters.

Retrieve Valid License From ASGARD

Use THOR's `--asgard` and `--asgard-token` parameters

In ASGARD 2.5+ you're able to configure a download token to limit the download of THOR packages and licenses to clients with knowledge of this token. The token is a protection that no one without knowledge of that token can intentionally exceed your license quota limit or retrieve a THOR package without authorization.

The download token can be configured in the Downloads section of you ASGARD server.

Downloads > Download Token Configuration

You can retrieve an appropriate THOR license at the scan start using the built-in --asgard and --asgard-token parameters.

C:\temp\thor>thor64.exe --asgard my-asgard.internal

C:\temp\thor>thor64.exe --asgard my-asgard.internal --asgard-token OCU92GW1CyOJLzaHkGrim1v2O0_ZkHPu0A

If everything works as expected, you'll see an INFO level message in the output that looks like:

Info: Init License file found LICENSE: my-asgard.internal OWNER: Master ASGARD: ACME Inc TYPE: Workstation STARTS: 2021/06/18 EXPIRES: 2022/06/18 SCANNER: All Scanners VALID: true REASON:

Use ASGARD's API to retrieve a license manually

You can also script the license retrieval from a local ASGARD server by using the API. The help box in ASGARD's Licensing > Generate License section shows curl requests that can be used to retrieve licenses from your ASGARD server.

All you need is:

Hostname
System Type (server or workstation)

Hint

Linux is always using the server license type

If there is uncertainty it's recommended to generate server type licenses which are more expensive but run on both system types.

For example: To retrieve a valid license for the servers named SRV001 and SRV002 you can use the following command:

nextron@unix:~$ curl -XPOST "https://my-asgard.internal:8443/api/v0/licensing/issue?token=OJCBaTq4VGLjrCes2k4ACCQOzg0AxAoz01" -o licenses.zip -d "type=server" -d "hostnames=SRV001" -d "hostnames=SRV002" ... -d "hostnames=hostnameN"

If you can't use curl and want to retrieve a license as part of a bigger PowerShell script, you can use the following code snippet to help you with the retrieval.

# License retrieval script
# Florian Roth, June 2021

# ASGARD URL
$AsgardURL = "https://asgard.nextron-systems.com:8443/api/v0/licensing/issue"
$Token = ""
$LicenseFile = "licenses.zip"
$OutputPath = ".\"
$ExtractLicenses = $True

# Config
# Ignore Self-signed certificates
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
# Set current working directory for .NET as well
[Environment]::CurrentDirectory = (Get-Location -PSProvider FileSystem).ProviderPath

# Web Client
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
$WebClient = New-Object System.Net.WebClient 
if ( $Token ) {
    $AsgardURL = [string]::Format("{0}?token={1}", $AsgardURL, $Token)
}
Write-Host "Using URL: $AsgardURL"

# Hostname
$Hostname = $env:COMPUTERNAME

# License Type
$LicenseType = "server"
$OsInfo = Get-CimInstance -ClassName Win32_OperatingSystem
if ( $osInfo.ProductType -eq 1 ) { 
    $LicenseType = "workstation"
}

# Proxy Support
$WebClient.Proxy = [System.Net.WebRequest]::DefaultWebProxy
$WebClient.Proxy.Credentials = [System.Net.CredentialCache]::DefaultNetworkCredentials

# Prepare request
$postData=New-Object System.Collections.Specialized.NameValueCollection
$postData.Add('hostnames',$Hostname)
$postData.Add('type',$LicenseType)
Write-Host "Requesting license for HOST: $Hostname TYPE: $LicenseType"

# Request license
try {
    $Response = $WebClient.UploadValues($AsgardURL, $postData)
# HTTP Errors
} catch [System.Net.WebException] {
    Write-Host "The following error occurred: $_"
    $Response = $_.Exception.Response
    # 403
    if ( [int]$Response.StatusCode -eq 403 ) { 
        Write-Host "This can be caused by a missing download token."
    }
    break
}
[System.IO.File]::WriteAllBytes($LicenseFile, $Response);

# Extract licenses
if ( $ExtractLicenses ) {
    Add-Type -AssemblyName System.IO.Compression.FileSystem
    try {
        [System.IO.Compression.ZipFile]::ExtractToDirectory($LicenseFile, $OutputPath)
    } catch {
        Write-Host "The following error occurred: $_"
    }
    Remove-Item -Path $LicenseFile
}

Check the ASGARD helper scripts section in our Github repo for more scripts and snippets.

Retrieve Valid License From Customer Portal

Use THOR's `--portal-key` and `--portal-contracts` parameters to retrieve a license

To retrieve a licenses from the customer portal, you need a portal key. The portal key (API key) can be configured in the My Settings > API Key section of the customer portal.

Important

API functionality needs to be activated by Nextron. Please contact support/sales to activate the API functionality.

You can retrieve an appropriate THOR license at the scan start using the built-in --portal-key and --portal-contracts parameters. The --portal-contracts parameter is optional. It can be used to take licenses from a specific contract in case you have more than one and want to use a specific one. If none is set, THOR will automatically retrieve licenses from a contract of the right type. (e.g. retrieve workstation license from the first still valid contract that has workstation licenses available)

Contracts IDs in Customer Portal — Contract IDs in Customer Portal

You can then use the parameters as shown in the following examples:

C:\temp\thor>thor64.exe --portal-key IY5Y36thrt7h1775tt1ygfuYIadmGzZJmVk32lXcud4

C:\temp\thor>thor64.exe --portal-key IY5Y36thrt7h1775tt1ygfuYIadmGzZJmVk32lXcud4 --portal-contracts 3,5

If everything works as expected, you'll see an INFO level message in the output that looks like:

Info License file found LICENSE: portal.nextron-systems.com OWNER: ACME Inc TYPE: Workstation STARTS: 2021/06/23 EXPIRES: 2021/06/30 SCANNER: All Scanners VALID: true REASON:

You can specify a proxy by setting the HTTP_PROXY and HTTPS_PROXY environment variables, e.g. to my-proxy.internal:3000.

Username and password can be specified as part of the proxy URL as http://username:password@host:port/.

Use the Customer Portal's API to retrieve a license manually

This is a bit more complicated as we've decided long ago that our customer portal will never contain personal or otherwise relatable information and this includes any kind of hostnames - not even in memory. Therefore it's necessary to generate a HMAC SHA1 hash of the lowercased hostname on the client side and include only the hash in the request to our customer portal.

This command generates a HMAC SHA1 of the current host you're working on. If you'd like to generate a license for a different host, simply replace the first part of the command with echo -n "mycustomname".

nextron@unix:~$ echo -n "$(hostname -s)" | tr '[:upper:]' '[:lower:]' | openssl dgst -binary -sha1 -mac hmac -macopt hexkey:b190dd4a98456999b6d9c7e4e1ac1f231b978c3e7652898d7db2fcdede34613dbc7909c9fc8b3177bb904871b8b7fc7a30cb1582ce9b0089397836dcc209e2d6 | base64 | tr '/+' '_-' | tr -d '='

The values needed for a successful request are:

$CONTRACT = contract id (set to 0 for automatic selection)
$TYPE = [server/client]
$HASH = the hash generated from the hostname in the previous step
$APIKEY = the API from the User Settings section in the customer portal

nextron@unix:~$ curl -XPOST https://portal.nextron-systems.com/api/public/contracts/issue/$CONTRACT/$TYPE/$HASH?download=1 -H "Authorization: $APIKEY" -o license.lic

A valid license is an encrypted blob of at least 800 bytes. You can check the content of the license for possible error message that came back from the server using xxd.

nextron@unix:~$ xxd license.lic

If you find a Error: HTTP-401 in the file, than you've most likely used an invalid API key.

Network Share (Windows)

THOR is a lightweight tool that can be deployed in many different ways. It does not require installation and leaves only a few temporary files on the target system.

A lightweight deployment option provides the THOR program folder on a read-only network share and makes it accessible from all systems within the network. Systems in DMZ networks can be scanned manually by transferring a THOR program package to the system and run it from the command line. The locally written log files have the same format as the Syslog messages sent to remote SIEM systems and can be mixed without any problem.

We often recommend triggering the scan via "Scheduled Task" distributed to the systems via GPO or PsExec. The servers access the file share at a given time, pull THOR into memory and start the scan process. You can either mount the network share and run THOR from there or access it directly via its UNC path (e.g. \\server\share\thor.exe or \\server\share\thor64.exe).

Create a Scheduled Task via GPO

In a Windows Domain environment, you can create a Scheduled Task and distribute this Scheduled Task via GPO. This Scheduled Task would invoke the batch file on the network share and runs THOR. Make sure that the respective user account has the rights to mount the configured network share.

You can find more information here:

https://technet.microsoft.com/en-us/library/cc725745.aspx

Create a Scheduled Task via PsExec

This method uses Sysinternals PsExec and a list of target systems to connect and create a Scheduled Task via the command line. This could look like the following example:

C:\temp\thor>psexec \\server1 -u domain/admin -p pass schtasks /create /tn "THOR Run" /tr "\\server\share\thor_remote.bat" /sc ONCE /st 08:00:00 /ru DOMAIN/FUadmin /rp password

Start THOR on the Remote System via WMIC

THOR can be started on a remote system via "wmic" using a file share that serves the THOR package and is readable by the user that executes the scan.

C:\temp\thor> wmic /node:10.0.2.10 /user:MYDOM\scanadmin process call create "cmd.exe /c \\server\thor10\thor.exe"

ASGARD Management Center (Windows, Linux, macOS)

ASGARD is the central management platform for THOR scans. It manages distributed THOR scans on thousands of systems, collects, forwards and analyses logs. Furthermore, ASGARD can control and execute complex response tasks if needed.

ASGARD comes in two variations: While ASGARD Management Center features scan control and response functions, ASGARD Analysis Cockpit can be used to analyze large amounts of scan logs through an integrated base-lining and case management.

The hardened, Linux-based ASGARD appliance is a powerful, solid and scalable response platform with agents for Windows, Linux and macOS. It provides essential response features like the collection of files, directories and main memory, remote file system browsing and other counteractive measures.

It features templates for scan runs and lets you plan and schedule distributed sweeps with the lowest impact on system resources. Other services are:

Quarantine Service - file quarantine via Bifrost protocol
Update Service - automatic updates for THOR scanners
License Service - central registration and sub license generation
Asset Management Service - central inventory and status dashboard
IOC Management – manage and scan with custom IOC and YARA rule sets
Evidence Collection – collect evidences (files and memory) from asset

ASGARD Response Control — ASGARD Response

Ansible (Linux)

Distribute Run with Ansible

In practice it is crucial to execute THOR on many servers in a network. A possible way to achieve this is described within this paper, taking into account that the footprint on the target should be minimal and that the procedure should not depend on the used Linux Distribution.

Ansible

The software Ansible (https://www.ansible.com) is a solution to perform tasks distributed over a network on different targets. An Open Source Version is available as well as a version with commercial support for enterprises. Ansible uses SSH to connect to the target hosts and performs a defined set of tasks on them called playbooks. Per default it uses keys for authentication, but this can be setup differently. Please refer to the official documentation for other methods of authentication. The tasks and the targets can be customized using host groups. The host groups may be used to separate different Linux distributions. The other steps may remain the same. Within the playbook any command line option may be customized for the given scenario.

Ansible does parallelization of the tasks by itself. The default amount of parallel executions is five and can be configured using the -f or --forks parameter when starting the playbooks.

Execute THOR using Ansible

The following section will show how to use an Ansible playbook to execute THOR on multiple Linux systems.

It will perform following steps on each system:

Create a temporary folder
Mount a RAM drive using the folder as mount point
Copy THOR to this RAM drive
Execute THOR
Unmount the RAM drive
Delete the temporary folder

Inventory File

First it is needed to define a list of hosts to execute THOR on. This is done by setting up a YAML file with the hostnames or IP addresses of the hosts. This file is later used with the -i parameter in the ansible-playbook command. A simple version of this could look like following:

---
host1.com
host2.com
132.123.213.111

To learn more about Ansible inventory files and how to use them, please refer to the official documentation:

https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html

Ansible Playbook Template

---
- hosts: all
#remote_user: root become: true tasks:
- name: Create folder for temporary RAM drive
command: mkdir /mnt/temp_ram creates=/mnt/temp_ram
- name: Create THOR RAM drive on target
command: mount -t ramfs -o size=60M ramfs /mnt/temp_ram/ ignore_warnings: true
-  name: Copy THOR to RAM drive
copy: src=../thor-linux-pack/ dest=/mnt/temp_ram/ ignore_warnings: true
-  name: Make THOR Executeable
file: path=/mnt/temp_ram/thor-x64 state=touch mode="0555"
- name: Execute THOR
command: /mnt/temp_ram/thor64 -l /mnt/temp_ram/thor.txt creates=/mnt/temp_ram/thor.html
- name: Fetch Log file
fetch: src=/mnt/temp_ram/thor.txt dest=../thoransible-output/{{inventory_hostname}}/thor.txt flat=true
-  name: Unmount temporary RAM drive
mount:
path: /mnt/temp_ram
state: unmounted
-  name: check Mount
command: mount
-  name: Delete folder for temporary RAM drive
command: rmdir /mnt/temp_ram/

Usage of THOR's Ansible playbook

Copy the playbook in the main directory of THOR. After this is done it can be started as follows:

nextron@unix:~$ ansible-playbook -f <number_of_parallel_executions> -i <inventory_file> thorplaybook.yml

After the playbook finished running the scans, the output of each system can be found in the thoransible-output directory located at the parent directory of THOR. Therefor it is important that the user starting ansible-playbook has the required rights to write in this directory.

Adjust THOR's Command Line Parameters

Per default this playbook will only start THOR with the parameter that defines the output log file. This can be changed in the playbook in the "Execute THOR"-Task. However, it should be kept in mind, that changing the output log file is not recommended, since the later tasks of the playbook depend on this.

THOR Thunderstorm Service

The command line flag --thunderstorm starts THOR as a RESTful web service on a given network interface and port. This service receives samples and returns a scan result.

The service can be started in two scan modes:

Pure YARA
Full-Featured

In the pure YARA mode (--pure-yara) THOR Thunderstorm only applies the 13,000 internal and all custom YARA rules to the submitted samples. It's lightweight and fast.

The full-featured mode is the default. In this mode Thunderstorm also parses and analyses Windows Eventlogs (EVTX), registry hives, memory dumps, Windows error reports (WER) and more. It's not just a YARA scan, but a full forensic processing.

Under normal circumstances, we recommend using the full-featured mode, since most files are not of a type that triggers an intense parsing function, the processing speed should be similar to the “pure-yara” mode.

It is recommended to use "pure-yara" mode in cases in which:

huge forensic artefacts (EVTX or memory dump files) appear on the source systems and overload the Thunderstorm service
deeper forensic parsing, IOC matching or other internal THOR checks aren't needed or wanted

The following table contains all THOR Thunderstorm related command line flags:

Parameter	Values	Function
--thunderstorm		Watch and scan all files sent to a specific port (see `--server-port`). Disables resource checks and quick mode, activate intense mode, disable ThorDB and apply IOCs platform independently
--server-host	ip-address	IP address that THOR's server should bind to (default `127.0.0.1`)
--server-port	port number	TCP port that THOR's server should bind to (default `8080`)
--server-cert	.crt location	TLS certificate that THOR's server should use. If left empty, TLS is not used
--server-key	.key location	Private key for the TLS certificate that THOR's server should use. Required if `--server-cert` is specified
--pure-yara		Apply only YARA signatures (no IOCs or other programmatical checks)
--server-upload-dir	upload-directory	Path to a temporary directory where THOR drops uploaded files. Only relevant for Windows and MacOS. On Linux, THOR stores files in in-memory files. (default `/tmp/thor-uploads`)
--server-result-cache-size	number of results	Size of the cache that is used to store results of asynchronous requests temporarily. If set to 0, the cache is disabled and asynchronous results are not stored. (default `10000`)
--server-store-samples	all/malicious/none	Sets whether samples should be stored permanently in the folder specified with `--server-upload-dir`. Specify `all` to store all samples, or `malicious` to store only samples that generated a warning or an alert. (default `none`)
--sync-only-threads	number of threads	Number of threads reserved for synchronous requests (only needed in environments in which users use both synchronous and asynchronous mode of transmission)
--threads	number of threads	Number of threads that the Thunderstorm service should use (default: number of detected CPU cores)

Service License Type

To run THOR in Thunderstorm service mode, you need a special license type named "Service License" that allows this mode of operation.

After the launch of THOR Thunderstorm, we may allow other license types to run THOR in service mode for a limited period of time, so that customers can test the service and its integration into other solutions.

Thunderstorm Collectors

Thunderstorm API Client

We provide a free and open source command line client written in Python to communicate with the Thunderstorm service.

https://github.com/NextronSystems/thunderstormAPI

It can be installed with:

nextron@unix:~$ pip install thunderstormAPI

Thunderstorm API Documentation

An API documentation is integrated into the web service.

Simply visit the service URL, e.g.: http://my-server:8080/

Server Installer Script for Linux

A script that facilitates the installation on Linux systems can be found in our github repository.

https://github.com/NextronSystems/nextron-helper-scripts/blob/master/thunderstorm/thunderstorm-installer.sh

The installation of a full THOR Thunderstorm server requires only two steps.

Download and place a THOR Service license file in the current working directory
Run the following command

nextron@unix:~$ wget -O - https://raw.githubusercontent.com/NextronSystems/nextron-helper-scripts/master/thunderstorm/thunderstorm-installer.sh | bash

Warning

Please inspect scripts from the internet before executing them!

Everything else will automatically be handled by the installer script. It even supports an “uninstall” flag to remove all files and folders from the system to get the system clean again after a successful proof-of-concept.

After the installation, the configuration file is located in /etc/thunderstorm.

The log file of the service can be found in /var/log/thunderstorm.

Thunderstorm Update

The Thunderstorm service gets updated just as THOR does. Use "thor-util update" to update signatures or "thor-util upgrade" to update binaries and signatures. The service has to be stopped during the updates.

Update signatures:

nextron@unix:~$ thor-util update

Upgrade signatures:

nextron@unix:~$ thor-util upgrade

See the THOR Util Manual manual for details on how to use these functions.

Thunderstorm Update Script

The Thunderstorm installer script for Linux automatically places an updater script in the PATH of the server system.

https://github.com/NextronSystems/nextron-helper-scripts/tree/master/thunderstorm

Update binaries and signatures:

nextron@unix:~$ thunderstorm-update

Stop service, update binaries and signatures, restart service:

nextron@unix:~$ thunderstorm-update full

Source Identification

The log file generated by THOR Thunderstorm doesn't contain the current host as hostname in each line. By default, it contains the sending source's FQDN or IP address if a name cannot be resolved using the locally configured DNS server.

However, every source can set a “source” value in the request and overwrite the automatically evaluated hostname. This way users can use custom values that are evaluated or set on the sending on the end system.

nextron@unix:~$ curl -X POST "http://myserver:8080/api/check?source=test" -F "file=@sample.exe"

Synchronous and Asynchronous Mode

It is also important to mention that THOR Thunderstorm supports two ways to submit samples, a synchronous and an asynchronous mode.

The default is synchronous submission. In this mode, the sender waits for the scan result, which can be empty in case of no detection or contains match elements in cases in which a threat could be identified.

In asynchronous mode, the submitter doesn't wait for the scan result but always gets a send receipt with an id, which can just be discarded or used to query the service at a later point in time. This mode is best for use cases in which the submitter doesn't need to know the scan results and batch submission should be as fast as possible.

	Synchronous	Asynchronous
Server API Endpoint	/api/check	/api/checkAsync
ThunderstormAPI Client Parameter		--asyn
Advantage	Returns Scan Result	Faster submission
Disadvantage	Client waits for result of each sample	No immediate scan result on the client side

In asynchronous mode, the Thunderstorm service keeps the samples in a queue on disk and processes them one by one as soon as a thread has time to scan them. The number of files in this queue can be queried at the status endpoint /api/status and checked on the landing page of the web GUI.

In environments in which the Thunderstorm service is used to handle synchronous and asynchronous requests at the same time, it is possible that all threads are busy processing cached asynchronous samples and not more synchronous requests are possible.

In this case use the --sync-only-threads flag to reserve a number of threads for synchronous requests. (e.g. --threads 40 --sync-only-threads 10)

Performance Tests

Performance tests showed the differences between the two submission modes.

In Synchronous mode, sample transmission and server processing take exactly the same time since the client always waits for the scan result. In asynchronous mode, the sample transmission takes much less time, but the processing on the server takes a bit longer, since the sever caches the samples on disk.

	Synchronous	Asynchronous
Client Transmission	40 minutes	18 minutes
Server Processing		46 minutes
Total time	40 minutes	46 minutes

SSL/TLS

We do not recommend the use of SSL/TLS since it impacts the submission performance. In cases in which you transfer files through networks with IDS/IPS appliances, the submission in an SSL/TLS protected tunnel prevents IDS alerts and connection resets by the IPS.

Depending on the average size of the samples, the submission frequency and the number of different sources that submit samples, the transmission could take up to twice as much time.

Note: The thunderstormAPI client doesn't verify the server's certificate by default as in this special case, secrecy isn't important. The main goal of the SSL/TLS encryption is an obscured method to transport potentially malicious samples over network segments that could be monitored by IDS/IPS systems. You can activate certificate checks with the --verify command line flag or verify parameter in API library's method respectively.

THOR Remote

THOR Remote is a quick method to distribute THOR in a Windows environment. It has been developed during an incident response and can be considered as a clever hack that makes use of PsExec to push and execute THOR with certain parameters on remote systems.

Requirements:

Administrative Domain Windows user account with access rights on the target systems
Reachability of the target systems (Windows Ports):
- 135/tcp for SCM (Service Management)
- 445/tcp for SMB (Mounting)
A list of target systems

Advantages:

Agent-less
Comfortable scanning without scripting
Quick results (useful in incident response scenarios)

Disadvantages:

Requires reachability of Windows ports
User credentials remain on the target system if it is used with explicit credentials (NTLM Auth) and the users doesn't already use an account that has access rights on target systems (Kerberos Auth)

Usage

A list of parameters used with the remote scanning function can be found in the help screen.

As you can see, a list of target hosts can be provided with the help of the new YAML config files. See chapter Configuration for more details.

A YAML file with a list of hosts looks like this:

remote:
- winatl001.dom.int
- winatl002.dom.int
- winnyk001.dom2.int

You can then use that file with:

C:\nextron\thor>thor64.exe -t targets.yml

THOR Remote Licensing

Valid licenses for all target systems are required. Place them in the program folder or any sub folder within the program directory (e.g. ./licenses). In case of incident response licenses, just place that single license in the program folder.

You don't need a valid license for the system that runs THOR's remote scanning feature (the source system of the scans, e.g. admin workstation).

Hint

You can pair THOR Remote with the License Retrieval options available within THOR, to make deployment easier.

Output

The generated log files are collected and written to the folder ./remote-logs

The "THOR Remote" function has its own interface, which allows you to view the progress of the scans, view and scroll through the log files of the different remote systems.

THOR Remote Interface II — THOR Remote Interface

Issues

System Error 5 occurred – Access Denied

See: https://helgeklein.com/blog/2011/08/access-denied-trying-to-connect-to-administrative-shares-on-windows-7/

Distribute to Offline Networks / Field Offices

The quickest and most simple way to run THOR is by providing the ZIP archive to the colleagues in the remote location, letting them run the THOR executable and collect the report files afterwards.

The most usable format in this use case is the HTML report if only a few reports have to be analyzed. If the number of collected reports is high, we recommend using ASGARD Analysis Cockpit or Splunk with the free App and Add-on.

ASGARD Analysis Cockpit: https://portal.nextron-systems.com/webshop/downloads

THOR APT Scanner App: https://splunkbase.splunk.com/app/3717/

THOR Add-On: https://splunkbase.splunk.com/app/3718/

System Load Considerations

We recommend staging the THOR Run in order to avoid resource bottlenecks (network or on VMware host systems). Especially during the THOR start, program files and signatures get pulled over the network, which is about 30 MB per system. Additionally, the modules, which take only a few seconds or minutes to complete, run first so that the load is higher during the first 10 to 15 minutes of the scan.

It is therefore recommended to define sets of systems that will run at the same time and let other systems start at intervals of an hour.

It is typically no problem to start a big set of physical machines at the same time. But if you start a scan on numerous virtual guests or on remote locations connected through slow WAN lines, you should define smaller scan groups.

Scan

This chapter is a quick introduction on how to run a THOR scan and how to personalize scans to better fit your environment and expectations.

Please note, the command line arguments are used to fine tune your scans and yield potentially better results for your use cases.

There is no "one fits all" command line argument, but we designed THOR to cover the broadest area with minimal impact in the default operating mode. Default in this case means no additional command line arguments.

Quick Start

Follow these steps to complete your first THOR scan

Make sure you've read the Before You Begin guide
Open a command line as administrative user
1. Administrator on Windows
2. root on Linux and macOS
Navigate to the folder in which you've extracted the THOR package and placed the license file(s)
Start THOR on your command line
1. thor64.exe on 64-bit Windows systems
2. thor.exe on 32-bit Windows systems
3. thor-linux-64 on x86-64 Linux systems
4. thor-linux on i386 Linux systems
5. thor-macos on macOS
Wait until the scan has completed (this can take between 20 and 180 minutes)
When the scan is finsihed, check the text log and HTML report in the THOR program directory

Often Used Parameters

Parameter	Description
--soft	Reduce CPU usage, skip all checks that can consume a lot of memory (even if only for a few seconds)
--quick	Perform a quick scan (skips Eventlog and checks only the most relevant folders); see Scan Modes
-e target-folder	Write all output files to the given folder

Parameters possibly relevant for your Use Case

Parameter

Description

-c, --cpulimit integer

Instruct THOR to pause all scanning if the systems CPU load is higher than the value specified.

Please see CPU Limit (--cpulimit) for more information.

--allhds

By default THOR scans only the C: partition on Windows machines and other files/folders only

in cases in which some reference points to a different partition (e.g. configured web root of IIS is on D:\inetpub, registered service runs from D:\vendor\service)

--lookback days --globallookback

Only check the elements changed or created during the last X days in all available modules (reduces the scan duration significantly)

Risky Flags

This list contains flags that should better be avoided unless you know exactly what you're doing.

Parameter	Description
--intense	long runtime, stability issues due to disabled resource control
--c2-in-memory	many false positives on user workstations (especially browser memory)
--alldrives	long runtime, stability issues due to scan on network drives or other remote file systems
--mft	stability issues due to high memory usage
--dump-procs	stability issues, possibly high disk space usage (free disk space checks are implemented but may fail)
--full-registry	longer runtime, low positive impact

Lesser Known But Useful Flags

This list contains flags that are often used by analysts to tweak the scan in useful ways.

Parameter	Description
--allreasons	Show all reasons that led to a certain score
--printshim	Print all available SHIM cache entries into the log
--utc	Print all timestamps in UTC (helpful when creating timelines)
--string-context num-chars	Number of characters preceeding and following the string match to show in the output

Help and Debugging

You can use the following parameters help you to understand THOR and the output better.

Parameter	Description
--debug	Get debug information if errors occur
--help	Get a help with the most important scan options
--fullhelp	Get a help with all scan options

Examples

Logging to Syslog Server

The following command instructs THOR to log to a remote syslog server only.

thor64.exe --nohtml --nocsv --nolog -s syslog.server.net

Scan Run on a Single Directory

thor64.exe --lab -p C:\ProgramData
thor64.exe --lab -p I:\mounted\_image\disk1

Important

This feature requires a forensic lab license type which is meant to be used in forensic labs.

You can imitate a lab scan without a lab license with these command line flags:

thor64.exe -a Filescan --intense --norescontrol --nosoft --cross-platform -p C:\ProgramData

Save the result files to a different directory

thor64.exe -s 10.1.5.14 -e Z:\

Only scan the last 7 days of the Windows Eventlog and log files on disk

thor64.exe --lookback 7

Scan System with Defaults and Make a Surface Scan

By default, the surface scan (DeepDive) applies all YARA rules in "./custom-signatures" folder. In this example, all output files are written to a network share.

thor64.exe --deepdivecustom -e \\server\share\thor_output\

Intense Scan and DeepDive on a Mounted Image

The following are two examples on how to scan a mounted image on Windows and Linux.

Mounted as Drive Z

thor64.exe --lab --deepdive -p Z:\

Mounted as /mnt

thor64.exe --lab --deepdive -p /mnt

Important

Lab scanning mode requires a forensic lab license type, which is meant to be used in forensic labs.

Scan Multiple Paths

thor64.exe --lab -p C:\\ D:\\webapps E:\\inetpub

Hint

non-existent directories will be automatically skipped

Scan All Hard Drives (Windows Only)

thor64.exe --allhds

Don't Scan Recursively

To instruct THOR to scan a folder non-recursively use the :NOWALK suffix.

thor64.exe -a FileScan -p C:\Windows\System32:NOWALK

Run a Scan with Specific Modules

With the parameter -a you can run a single module or select a set of modules that you'd like to run. All available modules can be found in the section Scan Module Names.

Run a Rootkit check only:

thor64.exe -a Rootkit

Run the Eventlog and file system scan:

thor64.exe –a Eventlog -a Filescan

Select or filter Signatures during Initialization

THOR 10.7.8 introduces the Init Selector and Init Filter functionalities, allowing users to fine-tune and customize their scanning process for improved accuracy and efficiency.

You can use these flags to limit the signature set to a certain campaign, threat or threat actor.

The filter values are applied to:

Rule name
Tags
Description

Here are some examples:

thor64.exe --init-selector ProxyShell

You can pass multiple selector keywords separated by comma:

thor64.exe --init-selector RANSOM,Lockbit

Or filter a set of signatures that only cause false positives in your environment:

thor64.exe --init-filter AutoIt

It is important to note that while these features offer flexibility and customization, we recommend utilizing a limited signature set only for specific use cases. This approach is particularly suitable when scanning exclusively for indicators related to a specific campaign. By understanding the proper utilization of Init Selectors and Init Filters, users can optimize their scanning process and effectively identify targeted threats.

The main advantages of a reduced signature set are:

improved scan speed
lower memory usage

PE-Sieve Integration

THOR integrates PE-Sieve, an open-source tool by @hasherezade to check for malware masquerading as benevolent processes.

PE-Sieve can be activated by using the --processintegrity flag. It runs on Windows as part of the ProcessCheck module and is capable of detecting advanced techniques such as Process Doppelganging.

When investigating infections, you can also raise the sensitivity of the integrated PE-Sieve beyond the default with --full-proc-integrity (at the cost of possible false positives).

THOR reports PE-Sieve results as follows:

Findings	THOR's Reporting Level
Replaced PE File	Warning
Implanted PE File	Warning
Unreachable File	Notice
Patched	Notice
IAT Hooked	Notice
Others	No Output in THOR

See the PE-Sieve documentation for more details on these values.

Multi-Threading

Starting from version 10.6, THOR supports scanning a system with multiple threads in parallel, allowing for a significant increase in speed in exchange for a higher CPU usage.

To use this feature, use the --threads flag which allows you to specify THOR's number of parallel threads.

When using the --lab (Lab Scanning), --dropzone (sample drop zone) or --thunderstorm (Thunderstorm) command line flags, THOR will default to using as many threads as the system has CPU cores; otherwise, THOR will still default to running with a single thread.

Note

The above listed modes are only available with the "Lab", "Thunderstorm" and "Incident Response" license type.

Enabled Modules

Not all modules support multi-threading. It is currently supported for:

Filescan
RegistryChecks
Eventlog
Thunderstorm (Thunderstorm License needed)
Dropzone (Lab License needed)

Scan Modes

You can select between six different scan modes in THOR:

Default

We recommend using the default scan mode for all sweeping activities. Scans take from one to six hours, depending on the partition size and number of interesting files.

In default mode, THOR automatically chooses the "Soft" mode if the system has only limited CPU and RAM resources.

There's a special "Lab Scanning" (--lab) method described in section Lab Scanning, which disables many limitations and allows to scan mounted images in a Lab scenario, even with multiple THOR instances on a single Workstation.

Note

"Lab Scanning" requires a special forensic license.
Quick --quick

This mode is the fastest one and oriented on the "Pareto Principle", covering 80% of the modules and checks in 20% of the normal scan time. In "quick" mode, THOR skips elements that have not been created or modified within the last 2 days in the "Eventlog", "Registry" and "Filescan" modules. A set of 40+ predefined directories will still be checked completely (e.g. AppData, Recycler, System32). "Quick" mode is known to be the "preventive" scan mode – less intense and very fast.

Themed scan modes:

Soft --soft - force disable with --nosoft

This mode disables all modules and checks that could be risky for system stability. It is automatically activated on (more details in chapter Automatic Soft Mode):
- Systems with only a single CPU core
- Systems with less than 1024 MB of RAM

Lab Scan --lab

This mode scans only the file system and disables all other modules. (see Lab Scanning for more details and flags used in this scan mode)

Example:
```
user@unix:~/thor$ ./thor64 --lab -p /mnt/image_c/
```
Intense --intense

This mode is meant for system scanning in a non-productive or lab environment. It disables several speed optimizations and enables time-consuming extra checks for best detection results. Be careful with this mode on database servers, as this could corrupt your database due to the high load of the server. Snapshots/backups are advised before using this mode.
Difference --diff

The Diff Mode looks for a last scan and last finished modules in the local THOR DB and scans only elements on disk that have been changed or created since the last scan start. This mode applies shortcuts to the "Filesystem", "Eventlog" and "Registry" modules. Diff scans are typically the shortest scans but require a completed previous scan. This scan mode is also susceptible to the so-called "Timestomping".

These scan modes can also be combined, e.g. for --soft --diff, though not all combinations may make sense, e.g. --soft --intense.

The following tables give an overview on the active modules and features in the different scan modes. The Modules section lists all available modules, whereas the Features section lists only features that are handled differently in the different scan modes.

Modules

Modules are standalone jobs, which are being executed one after the other by THOR. Those modules are invoking one job, for example the File System Scan module will scan your file system, or the User Account Check will scan your system for user accounts. Modules can invoke one or multiple Features, which we will explain further down in this section.

OS Module Overview

Module	Windows	Linux	MacOS
File System Scan	Supported	Supported	Supported
Registry Scan	Supported	Not Supported	Not Supported
SHIM Cache Scan	Supported	Not Supported	Not Supported
Mutex Check	Supported	Not Supported	Not Supported
Named Pipes Check	Supported	Not Supported	Not Supported
DNS Cache Check	Supported	Supported	Supported
Hotfix Check	Supported	Not Supported	Not Supported
Hosts File Check	Supported	Supported	Supported
Firewall Config Check	Supported	Supported	Not Supported
Network Share Check	Supported	Not Supported	Not Supported
Logged In Check	Supported	Supported	Supported
Process Check	Supported	Supported [1]	Supported [1]
Service Check	Supported	Supported	Not Supported
Autoruns Check	Supported	Supported	Supported
Rootkit Check	Supported	Supported	Not Supported
LSA Sessions Analysis	Supported	Not Supported	Not Supported
User Account Check	Supported	Supported	Supported
User Profile Check	Supported	Supported	Supported
Network Sessions Check	Supported	Not Supported	Not Supported
Scheduled Tasks Analysis	Supported	Not Supported	Not Supported
WMI Startup Check	Supported	Not Supported	Not Supported
At Entries Check	Supported	Not Supported	Not Supported
MFT Analysis	Supported	Not Supported	Not Supported
Eventlog Analysis	Supported	Not Supported	Not Supported
KnowledgeDB Check	Not Supported	Not Supported	Supported
Environment Variables Check	Supported	Supported	Supported
Crontab Check	Not Supported	Supported	Not Supported
Integrity Check	Not Supported	Supported	Not Supported
Event Check	Supported	Not Supported	Not Supported
ETW Watcher	Supported	Not Supported	Not Supported

Hint

For a list of module names and how to turn them off, please see Scan Module Names

Scan Mode Overview

Module	Normal	Quick	Soft	Intense
File System Scan		Reduced
Registry Scan
SHIM Cache Scan
Mutex Check			Disabled
Named Pipes Check
DNS Cache Check
Hotfix Check		Disabled
Hosts File Check			Disabled
Firewall Config Check		Disabled	Disabled
Network Share Check			Disabled
Logged In Check	Enabled [2]		Disabled
Process Check			Reduced [3]
Service Check
Autoruns Check
Rootkit Check
LSA Sessions Analysis			Disabled
User Account Check	Enabled [2]
User Profile Check	Enabled [2]	Disabled
Network Sessions Check	Enabled [2]		Disabled
Scheduled Tasks Analysis
WMI Startup Check
At Entries Check
MFT Analysis	Disabled	Disabled	Disabled	Enabled
Eventlog Analysis		Disabled
KnowledgeDB Check
Environment Variables Check
Crontab Check
Integrity Check
Event Check
ETW Watcher

Scan Module Names

Scan Mode	Module Name	Disable Module
File System Scan	Filescan	--nofilesystem
Registry Scan	RegistryChecks	--noreg
SHIM Cache Scan	SHIMCache	--noshimcache
Mutex Check	Mutex	--nomutex
Named Pipes Check	Pipes	--nopipes
DNS Cache Check	DNSCache	--nodnscache
Hotfix Check	HotfixCheck	--nohotfixes
Hosts File Check	Hosts	--nohosts
Firewall Config Check	Firewall	--nofirewall
Network Share Check	NetworkShares	--nonetworkshares
Logged In Check	LoggedIn	--nologons
Process Check	ProcessCheck	--noprocs
Service Check	ServiceCheck	--noservices
Autoruns Check	Autoruns	--noautorons
Rootkit Check	Rootkit	--norootkits
LSA Sessions Analysis	LSASessions	--nolsasessions
User Account Check	Users	--nousers
User Profile Check	UserDir	--noprofiles
Network Sessions Check	NetworkSessions	--nonetworksessions
Scheduled Tasks Analysis	ScheduledTasks	--notasks
WMI Startup Check	WMIStartup	--nowmi
At Entries Check	AtJobs	--noatjobs
MFT Analysis	MFT	--nomft
Eventlog Analysis	Eventlog	--noeventlog
KnowledgeDB Check	KnowledgeDB	--noknowledgedb
Environment Variables Check	EnvCheck	--noenv
Crontab Check	Cron
Integrity Check	Integritycheck	--nointegritycheck
Event Check	Events	--noevents
ETW Watcher	EtwWatcher	--noetwwatcher

Scan Module Explanation

Module	Explanation
Filescan	Events reported by the FileScan module typically originate from the file system scan. But due to the "Message Enrichment" feature, other modules that include events with full "file path" strings may also produce events of this type (e.g. module `SHIMCache`, `Eventlog`).
SHIMcache	The SHIM Cache or AppCompatCache (Application Compatibility Cache) is a special Registry cache containing valuable information, because the cache tracks metadata for binary files that were executed.
Autoruns	The Autoruns module makes use of the command line version of SysInternals Autoruns. It parses the tools output and integrates the output in each log message.
LogScan	The LogScan module processes `.log` files found on disk line by line (It performs some checks to avoid scanning files that are not ASCII log files, but something else that uses the `.log` extension). Each log line is checked with all file name and keyword IOCs and scanned with the "keyword" and "log" type YARA rules.
GroupsXML	The GroupsXML module is a module that reports on critical security issues related to decryptable passwords in group policy files, that are readable for anyone within a Windows Domain.
Registry	Registry matches can be caused by different signature types: File name IOCs, keywords or YARA signatures matches.
WMIPersistence	It is difficult to detect malicious WMIPersistence objects. The detection methods are based on whitelists and a blacklist with keywords from APT reports. The whitelists are extended every time our analysts detect false positives in a customer's environment. The black lists are extended every time an APT report states a certain WMI persistence method with specific event filer or event file name.
VulnerabilityCheck	The VulnerabilityCheck module is limited to a few vulnerabilities that are known to be exploited by various threat groups. The vulnerability checks focus on vulnerabilities that are used for lateral movement or weaknesses which allow an attacker to easily achieve persistence without using any kind of software as backdoor. Note: There are vulnerabilities covered by YARA rules and reported in other modules. The YARA rules that detect vulnerabilities start with `VUL_`.
LoggedIn	The LoggedIn module analyses all currently logged in users and analyses their names.
ProcessCheck	Different checks are performed in the ProcessCheck module. Some of them check the process characteristics such as parent/child relations, process priorities and executable file locations for anomalies. Other checks evaluate the processes network connections and YARA checks match on the process memory.
HotfixCheck	The HotFixCheck module analyses the installed hotfixes on the end system.
RunKeyCheck	The RunKeyCheck module processes entries in the RUN Key.
AmCache	The AmCache module processes entries in the AmCache of the system. In contrast to the SHIMCache entries, AmCache entries contain a SHA1 hash value that can be used to determine the exact program that was executed on the end system.
Firewall	The Firewall module evaluates all local Windows firewall rules and tries to detect suspicious entries by using white- and blacklists.
ServiceCheck	The ServiceCheck module evaluates all registered local Windows services. It detects suspicious service entries by different anomaly checks, blacklisted keywords and reports file path anomalies.
DNSCache	The DNSCache module evaluates the entries of the local DNS cache. It compares the entries with known C2 servers and reports suspicious entries based on some regular expression checks.
Hosts	The Hosts module evaluates the entries in the local hosts file.
WMIStartup	The WMIStartup module uses different WMI queries to retrieve information on elements that could be used for persistence. It is very likely that findings by this module also appear in other modules (e.g. `Autoruns`) in a different form, because it just uses a different method to look at the same elements.
CommandCheck	The CommandCheck module is a meta module that analyses full command lines (path, executable, parameters) in different modules.
ProcessHandles	The ProcessHandles module is a sub module of the `ProcessCheck` module that analyses the handles of each process. The module makes use of the SysInternals `handle.exe` tool that can be placed in the `./tools` sub folder.
ProcessConnection	The ProcessConnections module checks the network connections of a process and generates alerts and warnings based on C2 signature matches and suspicious GEO IP lookups.
WER	The WER (Windows Error Reporting) module analyses program crash files and checks for special crashes caused by exploits and filename IOC signature matches in the application path. Software can break, so applications tend to crash, hack tools and exploits crash as well. Even if the attackers completely removed their tools from a system, a crashed exploit code, scanner, password dumper or backdoor will still be visible in the Windows Error Reports.
UserAccounts	The UserAccounts module analyses the local user database. It checks for suspicious user names, suspicious members in the `Administrators` group, activated guest accounts, user accounts created on Sundays and reports recently logged in users. It applies the `hot time frame` parameter (`-f`) if given and reports suspicious account activity on a given set of dates.
AtJobs	The AtJobs module analyses the local user jobs and just lists them in "Info" level messages and applies the global string check on the command line.
ScheduledTasks	The ScheduledTasks module analyses the local user at jobs and just lists them in "Info" level messages and applies the global string check on the command line.
Rescontrol	The Rescontrol (Resource Control) module generates "Warning" level messages in cases a resource limit has been reached. In most of the cases, this is caused by very low free main memory levels or false positives that generated many SYSLOG messages. Resource control is active by default and can be deactivated with (`--norescontrol`).
DeepDive	A DeepDive on memory images or disk space cannot be analyzed by THOR events alone. You typically need the memory dumps or restored chunks to evaluate the findings. This typically takes a lot more time, know-how and effort to complete.We recommend the analysis of DeepDive module events only in case other indicators give a sufficient initial suspicion.
Rootkit

Features

Features are being invoked by Modules and provide further Details about an item. For example, the File System Scan might find a .zip file during a scan and invoke the Archive Scan feature. The Archive Scan feature in return will extract the zip file and scan all the items in it.

Another example would be the Eventlog Analysis Module, which might invoke the Sigma Scan feature on certain eventlog entries.

Hint

Please see chapter Archive Scan for a list of supported archive formats.

Feature Scan Mode Overview

Feature	Normal	Quick	Soft	Intense
Sigma Scan	Disabled	Disabled	Disabled	Enabled
EXE Decompression [5]	Enabled	Enabled	Disabled	Enabled
Archive Scan	Enabled	Enabled	Enabled	Enabled
Double Pulsar Check [5]	Enabled	Enabled	Disabled	Enabled
Groups XML Analysis	Enabled	Enabled	Enabled	Enabled
Vulnerability Check	Enabled	Enabled	Enabled	Enabled
Web Server Dir Scan	Enabled	Disabled	Enabled	Enabled
WMI Persistence	Enabled	Enabled	Enabled	Enabled
Registry Hive Scan	Enabled [4]	Enabled	Enabled	Enabled
AmCache Analysis	Enabled	Enabled	Enabled	Enabled
Process Handle Check	Enabled	Enabled	Enabled	Enabled
Process Connections Check	Enabled	Enabled	Enabled	Enabled
Windows Error Report (WER)	Enabled	Enabled	Enabled	Enabled
Windows At Job File Analysis	Enabled	Enabled	Enabled	Enabled
EVTX File Scanning	Enabled	Disabled	Enabled	Enabled
Prefetch Library Scanning	Enabled	Enabled	Enabled	Enabled
Memory Dump DeepDive	Disabled	Disabled	Disabled	Enabled
Text Log File Scanning	Enabled	Disabled	Enabled	Enabled
Shellbag Entry Analysis	Enabled	Enabled	Enabled	Enabled
Authorized Key File Analysis	Enabled	Enabled	Enabled	Enabled
Bifrost File Upload	Enabled	Enabled	Enabled	Enabled
Malicious Domain Check	Enabled	Enabled	Enabled	Enabled
File Scan	Enabled	Enabled	Enabled	Enabled
Cobalt Strike Beacon Parsing	Enabled	Enabled	Enabled	Enabled
Process Integrity Check [5]	Disabled	Disabled	Disabled	Enabled
SHIM Cache Analysis	Enabled	Enabled	Enabled	Enabled
ETL File Scanning [5]	Enabled	Enabled	Enabled	Enabled

Feature caller list

The following table gives an overview of THOR's features and how they are called by the different modules and other features.

Feature	Callers
Sigma Scan	Eventlog, Log file scanning
EXE Decompression	File Scan
Archive Scan	File Scan
Double Pulsar Check	Rootkit Check
Groups XML Analysis	File Scan
Vulnerability Check	File Scan
Web Server Dir Scan	Process Check
WMI Persistence	File Scan
Registry Hive Scan	File Scan
AmCache Analysis	File Scan
Process Handle Check	Process Check
Process Memory Check	Process Check
Process Connections Check	Process Check
Windows Error Report (WER)	File Scan
Windows At Job File Analysis	File Scan
EVTX File Scanning	File Scan
Prefetch Library Scanning	File Scan
Memory Dump DeepDive	File Scan
Text Log File Scanning	File Scan
Shellbag Entry Analysis	Registry Hive Scan
Authorized Key File Analysis	File Scan
Bifrost File Upload	File Scan
Malicious Domain Check	File Scan
File Scan	Most modules and features
Cobalt Strike Beacon Parsing	File Scan, Process Check
Process Integrity Check	Process Check
SHIM Cache Analysis	SHIM Cache Scan, Registry Hive
ETL File Scanning	File Scan

Feature selectors

Since THOR 10.7, some features in THOR are triggered by YARA rules.

When a (meta or generic) YARA rule with a specific tag matches on a file, the corresponding feature is started and parses the file.

The standard signatures contain a number of rules with these tags, but if required, you can add additional rules with these tags as custom signatures.

Tag	Feature	Applied regardless of Filesize limit
AMCACHE	Amcache	no
ZIPARCHIVE	Archive	no
RARARCHIVE	Archive	no
TARARCHIVE	Archive	no
TARGZARCHIVE	Archive	no
TARBZ2ARCHIVE	Archive	no
CABARCHIVE	Archive	no
GZIPCOMPRESSEDFILE	Archive	no
SEVENZIPARCHIVE	Archive	no
ATJOBS	AtJobs	yes
AUDITLOG	Auditlog	yes
AUTHORIZEDKEYS	AuthorizedKeys	yes
EMAILFILE	EmailParser	no
ETL	ETL	yes
EVTX	EVTX	yes
UPX	ExeDecompress	no
WINRAR	ExeDecompress	no
LNK	LinkScan	yes
LOGSCAN	LogScan	yes
MFT	MftFile	yes
OLE	OleScan	no
PREFETCH	Prefetch	yes
REGISTRYHIVE	RegistryHive	yes
UNESCAPE	Unescaper	no
WER	WER	yes
WMIPERSISTENCE	WMIPersistence	yes

Feature names

Feature	Feature Name	Disable Feature
Use a persistent database for holding information across scans	ThorDB	--nothordb
Scan with Sigma signatures	Sigma	THOR 10.6 per default disabled, use `--sigma` to enable
		THOR 10.7 `--nosigma`
Scan log file (identified by .log extension or location) entries one by one	LogScan	--nologscan
Check files, processes or blobs with YARA	Yara
Check files with STIX	Stix	--nostix
Extract files contained in archives	Archive	--noarchive
Scan files contained in archives	ArchiveScan	--noarchive
Run checks for known C2 Domains	C2	--noc2
Analyze process handles	ProcessHandles	--noprochandles
Analyze process connections	ProcessConnections	--noprocconnections
Analyze entries in Amcache files	Amcache	--noamcache
Parse and analyze registry hives	RegistryHive	--noregistryhive
Decompress and scan UPX or SFX packed portable executables	ExeDecompress	--noexedecompress
Analyze web directories that were found in process handles	WebdirScan	--nowebdirscan
Search for configuration file vulnerabilities (e.g. weak Tomcat passwords)	VulnerabilityCheck	--novulnerabilitycheck
Parse Windows prefetch directories	Prefetch	--noprefetch
Parse groups.xml files (for AD permissions) and search for vulnerabilities	GroupsXML	--nogroupsxml
Parse WMI Persistence directories	WMIPersistence	--nowmipersistence
Parse and analyze LNK files	Lnk	--nolnk
Check Knowledge DB on Mac OS	KnowledgeDB	--noknowledgedb
Parse .wer crash dump files	WER	--nower
Parse EVTX eventlogs and scan the contained log entries	EVTX	--noevtx
Analyze authorized_keys SSH files	AuthorizedKeys	--noauthorizedkeys
Parse and analyze .eml Email files	Eml	--noeml
Parse Windows Event Trace Logging files and scan the contained logs	ETL	--noetl
Parse jobs files scheduled with the 'at' tool	AtJobs	--noatjobs
Upload suspicious files to a server running the Bifrost 2 quarantine service	Bifrost2	per default disabled, use `--bifrost2Server` to enable
Scan multiple entries as a single block	BulkScan	can't be disabled
Disable cpulimit check	CPULimit	--nocpulimit
Run filename IOC, keyword IOC, and YARA rules on a chunk of data	CheckString	can't be disabled
Parse crontab files and analyze their entries	CronParser	can't be disabled
Check for DoublePulsar Backdoor in the rootkit module	DoublePulsar	--nodoublepulsar
Gather additional information (like hashes, owner, timestamps, ...) about file paths	EnrichFileInfo	can't be disabled
Apply filename IOCs	FilenameIOCs	can't be disabled
Scan files and similar objects	Filescan	can't be disabled
Apply keyword IOCs	KeywordIOCs	can't be disabled
Log information during a THOR run	Logger	can't be disabled
Detect a file's type based on its first bytes	MagicHeader	can't be disabled
Parse OLE files (e.g. old MS office documents, or MS Office macros)	OLE	can't be disabled
Parse additional information from a detected CobaltStrike beacon	ParseCobaltStrike	can't be disabled
Keep and display information about THOR's current activity	ProgressTracker	can't be disabled
Parse additional information from files in a Windows recycle bin	RecycleBin	can't be disabled
Check whether the system is running out of RAM, and end THOR, if this is the case	Rescontrol	--norescontrol
Parse SHIM Caches from registry and analyze their entries	SHIMCache	--noshimcache
React to interrupts from outside THOR in a controlled manner	SignalHandler	can't be disabled
Look for unencrypted TeamViewer passwords in registry hives	TeamViewer	can't be disabled
Add additional information from Virustotal to detected files	VirusTotal	per default disabled, use `--vtkey` to enable
Run a user defined command for detected files	Action	per default disabled, use `--action_command` to enable
Write a detailed output file with information about all scanned elements	AuditTrail	per default disabled, use `--audit-trail` to enable
Scan memory dump files in chunks	DumpScan	per default disabled, use `--dumpscan` to enable
Scan processes with PE-Sieve to check for process integrity (Windows only)	ProcessIntegrity	per default disabled, use `--processintegrity` to enable

Special Scan Modes

This section describes special purpose scan modes that change THOR's mode of operation or activate particular features. Some of these modes need a special license which is highlighted in the note box. If you have any questions regarding pricing of those licenses, please contact our sales department at sales@nextron-systems.com

Lab Scanning

Lab scanning mode that is activated with --lab (formerly --fsonly). It is used to scan mounted forensic images or a single directory on a forensic workstation. All resource control functions are disabled and intense mode is activated by default.

The --lab parameter automatically activates the following other options:

intense (scan every file intensively regardless of its extension or magic header)
norescontrol (do not limit system resources or interrupt scan on low memory)
nosoft (do not automatically activate soft mode on systems with single core CPUs or low memory)
nodoublecheck (do not check for other THOR instances on the same system and do not interrupt scan if another instance has been found)
multi-threading (it automatically sets the number of threads to use to the number of CPU cores found on the workstation)

The chapter Use Cases contains some use cases in which this scan mode is used. You may find the guides useful.

Note

If you run multiple THOR scans with multi-threading on a single system, resource usage will rise quickly since it scales per thread.

Consider using --threads to reduce the number of threads that each THOR scan uses, e.g. --threads 4 if running 4 scans on a 16 core system.

Forensic Lab License

The scan of mounted disk or memory images is a use case that we call "lab scanning". It requires a forensic lab license which is meant to be used in corporate digital forensic labs.

All other license types are meant for other use cases. (usually live system scanning) You can get a similar but not an equally thorough scan using the following command line flags

C:\nextron\thor>thor64.exe -a Filescan --intense --norescontrol --cross-platform -p path-to-scan

Without a valid lab license, you cannot use multiple instances of THOR on a single system or switch into multi-threaded scanning. The features mentioned in the following sub chapters are also limited to a lab license.

This article explains that advantages of a lab licenses.

Virtual Drive Mapping

Since THOR enriches messages with more details, it could be problematic to scan a mounted drive “s:”, which has originally been a partition “c:” on the source system of the image.

E.g. The analyst has mounted a partition "C:" from a source system to drive "F:" on the forensic lab workstation. A SHIMCache entry points to C:\temp\mk.exe. THOR would look at location C:\temp\mk.exe for that file and couldn't find anything, since that file doesn't exist on the forensic lab workstation.

Virtual drive mapping allows you to virtually map that drive to its original name. The syntax is as follows:

--virtual-map current-location:original-location

Some examples:

A original partition "C:" from the source system has been mounted to drive "F:" on the forensic lab workstation:

--virtual-map F:C

A original mount point "/" has been mounted to "/mnt/image1" on a Linux forensic lab workstation:

--virtual-map /mnt/image1:/

A Windows image of drive "C:" mounted to "/mnt/image1" on a Linux forensic lab workstation:

--virtual-map /mnt/image1:C

Note

This feature requires a forensic lab license type, which is meant to be used in forensic labs.

Hostname Replacement in Logs

The parameter -j can be used to set the hostname used in the log files to a given identifier instead of using the current workstation's name in all output files. If you don't use this flag, all log files generated on that forensic lab workstation would contain the name of the forensic lab workstation as the source.

You should use the name of the host from which the image has been retrieved as the value for that parameter.

-j orig-hostname

Artefact Collector

THOR 10.7.8 introduces the Artefact Collector module. The purpose of this module is to be able to quickly collect and archive system artifacts into a single ZIP via THOR. It can be activated via --collector (running the collector module at the end of a THOR run) or --collector-only (only running the collector module) and uses :hostname:_collector.zip as output path for the ZIP archive per default. The default ZIP archive path can be changed with --collector-output <path>. The ZIP archive includes all found artifacts and a special file called collector.log containing logging information for the module execution (e.g. timestamps, hashes, filesize, ...)

The artifacts which are collected per default (GLOB patterns) can be seen with --collector-print-config. To change the default settings use --collector-config <file>.

Tip

Pipe the output of --collector-print-config to a file and use a modified version of it.

For testing the collector config you can use --collector-dry-run - this only prints the artifacts which would be collected to stdout - no output ZIP archive will be created. It is also possible to limit the artifact size via the --collector-max-filesize flag.

If run on Windows, the collector module will parse the MFT and collect files based on the extracted information. This allows the collection of all files including special files like $UsnJrnl. The downside of MFT parsing is that it takes a bit longer. If you do not care about special files and want to speed up the collection process, use --collector-no-mft.

All flags can be found in the THOR full help (--fullhelp).

Note

A special license called THOR Deep Forensics is needed to use the Artefact Collector feature.

Examples

THOR Lab Scanning Example

A full command line of a THOR scan started in a lab environment would look like this:

C:\nextron\thor>thor64.exe --lab -p S:\ --virtual-map S:C –j WKS001 -e C:\reports

It instructs THOR to scan the mounted partition S: in lab scanning mode, maps the current partition “S:” to a virtual drive “C:”, replaces the hostname with "WKS001" in the outputs and saves every output file (text log, HTML, CSV) to a reports folder named C:\reports.

Note

This feature requires a forensic lab license type which is meant to be used in forensic labs.

Artefact Collector Example

The command line of a THOR scan in collector-only mode would like this:

C:\nextron\thor>thor.exe --collector-only

If you want THOR to run in its "classic" way and afterwards collect artifacts, use:

C:\nextron\thor>thor.exe <normal-THOR-flags> --collector

Note

This feature requires a forensic lab license type which is meant to be used in forensic labs.

Lookback Mode

The --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.

In THOR v10.5 we've extended this feature to include all applicable modules, including "FileScan", "Registry", "Services", "Registry Hives" and "EVTX Scan".

By setting the flags --all-module-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.

This scan mode is perfect for quick scans to verify SIEM related events and is used by default in THOR Cloud's settings for executions via Microsoft Defender ATP.

Drop Zone Mode

The drop zone mode allows you to define a folder on your local hard drive that is monitored for changes. If a new file is created in that folder, THOR scans this file and writes a log message if suspicious indicators have been found. The optional parameter --dropdelete can be used to remove the dropped file once it has been scanned. Example:

C:\thor>thor64.exe --dropzone –p C:\dropzone

Warning

If another process writes a file to the drop zone, this is prone to a race condition: THOR might read the file when no or not all data has been written yet.

For consistent scan results, move files from another folder to the dropzone.

Note

This feature requires a forensic lab license or Thunderstorm license which are meant to be used in forensic labs.

Drop Zone Mode Output

We designed the drop zone mode to show only relevant output (Notice, Warning or Alert) after the initialization to reduce clutter on the screen. This might look like no files are being scanned, which is actually not the case. To see if files are being scanned, you can do one of the following two options.

You can drop the EICAR test file into the defined dropzone to test if findings are shown properly:

Example of a THOR Drop Zone Mode finding

Or you can print all output with --printall - this might clutter the output:

Image File Scan Mode

The image file scan mode has a misleading name. It isn't meant to be used for forensic image scanning but for the scan of un-mountable images or memory dumps only. If you have a forensic image of a remote system, it is always recommended to mount the image as a Windows drive and scan it using the Lab Scanning (--lab) mode.

The Image File Scan mode performs a deep dive on a given data file. Therefore, the file type, structure or size of that file is not relevant. The DeepDive module processes the file in overlapping 3 Megabyte chunks and checks these chunks using the given YARA rule base only (including custom YARA signatures).

The only suitable use case is the scan of a memory dump using your own YARA signatures placed in the "./custom-signatures/yara" sub folder.

C:\nextron\thor>thor.exe –m systemX123.mem –j systemX123 –e C:\reports

Note

This feature requires a forensic lab license type which is meant to be used in forensic labs.

DeepDive

The DeepDive module allows a surface scan of a given memory dump.

This check processes every byte of the memory dump.

DeepDive is not recommended for triage sweeps in a whole network as it generates more false positives than a normal file system scan. This is mainly caused by the fact that chunks of data read from the dump are processed regardless of their corresponding file's type, name or extension. It processes Antivirus signatures, pagefile contents and other data that may trigger an alert.

In the current stage of development, the DeepDive check parses out every executable file and applies all included Yara signatures. A positive match is reported according to the score as "Notice", "Warning" or "Alert".

There are some disadvantages linked with the DeepDive detection engine:

The file name cannot be extracted from the raw executable code
The file path of the reported sample is unknown

THOR uses other attributes to report these findings:

Offsets
- THOR reports the location on the disk, so that forensic investigators are able to check and extract the file from an image of the hard drive.
Restore
- THOR is able to restore the whole file to a given directory. It uses the system's NetBIOS name, rule name, the score and the offset to create a file name for the extracted file.

As a side effect of this dissection all the embedded executables in other file formats like RTF or PDF are detected regardless of their way of concealment.

To perform a surface scan, use the "--image_file" option. To restore all detected files to a restore directory additionally use the "-r directory" option.

Option	Description
--image_file	Activate DeepDive for a specific image file, i.e. `--image_file C:\\tmp\memory.hdmp`
-r directory	Recovery directory for files found by DeepDive

Eventlog Analysis

The Eventlog scan mode allows scanning certain Windows Eventlogs.

In intense mode, all Eventlogs are scanned. In normal or soft mode, the following Eventlogs are scanned:

System
Application
Security
Windows PowerShell
Microsoft-Windows-AppLocker/EXE and DLL
Microsoft-Windows-AppLocker/MSI and Script
Microsoft-Windows-CodeIntegrity/Operational
Microsoft-Windows-DeviceGuard/Operational
Microsoft-Windows-Folder Redirection/Operational
Microsoft-Windows-PowerShell/Operational
Microsoft-Windows-Sysmon/Operational
Microsoft-Windows-Security-Mitigations/KernelMode
Microsoft-Windows-Shell-Core/Operational
Microsoft-Windows-SmbClient/Security
Microsoft-Windows-SMBServer/Security
Microsoft-Windows-TaskScheduler/Operational
Microsoft-Windows-WMI-Activity/Operational
Microsoft-Windows-Windows Defender/Operational
Microsoft-Windows-Windows Firewall With Advanced Security/Firewall
Microsoft-Windows-WinINet-Config/ProxyConfigChanged
Microsoft-Windows-VHDMP-Operational
Microsoft-Windows-WLAN-AutoConfig/Operational
Microsoft-Windows-Winlogon/Operational
Microsoft-Windows-UniversalTelemetryClient/Operational

The parameter -n works like the -p parameter in the Filesystem module. It takes the target Eventlog as parameter, which is the Windows Eventlog's full name.

C:\nextron\thor>thor64.exe -a Eventlog –n "Microsoft-Windows-Sysmon/Operational"

From THOR 10.7.13 onwards, -n can also be used to scan all event logs by using -n *.

You can get the full name of a Windows Eventlog by right clicking the Eventlog in Windows Event Viewer and selecting "Properties".

The -n parameter can also be used to restrict the Eventlog scanning to certain Eventlogs. The following command will start a default THOR scan and instructs the Eventlog module to scan only the “Security” and “System” Eventlog.

C:\nextron\thor>thor64.exe -n Security -n System

MFT Analysis

The MFT analysis module reads the "Master File Table" (MFT) of a partition and parses its contents. The MFT analysis takes a significant amount of time and is only active in “intense” scan mode by default.

You can activate MFT analysis in any mode by using --mft.

The way THOR handles the MFT Analysis can be influenced by the following parameters:

Option	Description
--mft	Activate MFT analysis
--nomft	Do not perform any MFT analysis whatsoever (only useful in combination with `--intense`)
--maxmftsize MB	The maximum MFT size in Megabytes to process (default: 200 MB)

Analysis

This chapter explains the possibilities for collecting and analyzing THOR logs.

ASGARD Analysis Cockpit

The ANALYSIS COCKPIT is the central platform for analyzing THOR logs. It can be used in an environment where scans are controlled by ASGARD Management Center and can also be used where THOR is executed manually or controlled by third party solutions. It is available as a virtual appliance on VMWare and also as a dedicated hardware appliance.

THOR can also be seen or used as hunting solution, it is optimized to avoid false negatives – meaning optimized to not miss an indicator of compromise. On the other side this clearly leads to more anomalies and false positives being reported.

In a scenario where you scan your infrastructure frequently you would either be seeing the same anomalies again and again or you would need to create many rules to filter out these anomalies in order to save analysis time.

The ANALYSIS COCKPIT is designed to facilitate this process and help you generate these rules automatically, so that you can set your baseline-filters after the first scan. After setting the first baseline it is now easy to focus on relevant Alerts and Warnings as only differences between the first and second scans are shown.

The ANALYSIS COCKPIT comes with an integrated and highly configurable ticketing system that helps organizing your analysis workflow. Furthermore, the ANALYSIS COCKPIT comes with a rule based alert forwarding and SIEM integration that makes it easy for your organization to react quickly on new incidents.

Splunk

We offer a THOR Splunk App and Add-on via the official Splunk App Store. This App helps you to extract the event fields and provides dashboards to get a better overview on distributed runs on multiple systems.

THOR APT Scanner App: https://splunkbase.splunk.com/app/3717/

THOR Add-On:https://splunkbase.splunk.com/app/3718/

THOR Util Report Feature

THOR Util provides a feature called "report" that creates HTML reports from text logs of one or more scanned systems.

Find more information about this feature on our website or the separate THOR Util manual.

https://www.nextron-systems.com/2018/06/20/thor-util-with-html-report-generation/

Log Analysis Manual

We have written a detailed Log Analysis Manual which:

Explains how to analyze THOR logs
Contains example logs
Lists potential false positives you might encounter
And how different attributes are to be evaluated

https://log-analysis-manual.nextron-systems.com/

Configuration

Scan Templates

THOR 10 accepts config files (called "templates") in YAML format. They reflect all command options to make them flexible and their use as comfortable as possible.

This means that every parameter set via command line can be provided in the form of a config file. You can even combine several of these config files in a single scan run.

Default Template

By default, THOR only applies the file named thor.yml in the ./config sub folder. Other config files can be applied using the -t command line parameter.

Apply Custom Scan Templates

The following command line provides a custom scan template named mythor.yml.

C:\nextron\thor>thor.exe -t mythor.yml

Example Templates

The default config thor.yml in the ./config folder has the following content.

Content of THOR's Default Config thor.yml:

# This is the default config for THOR
# Terminate THOR if he runs longer than 72 hours
max_runtime: 72
# Minimum score to report is 40
min: 40
# Skip files bigger than 12000000 bytes
max_file_size: 12000000
# Skip files bigger than 30000000 bytes in intense mode (--fsonly, --intense)
max_file_size_intense: 30000000
# Limit THOR's CPU usage to 95%
cpulimit: 95
# The minimum amount of free physical memory to proceed (in MB)
minmem: 50
# Truncate THOR's field values after 2048 characters
truncate: 2048

Content of Config File mythor.yml:

resume: true
cpulimit: 40
intense: true
max_file_size: 7500000
syslog:
   - foo.nextron
   - bar.nextron:514:TCP

The default scan template is always applied first. Custom templates can then overwrite settings in the default template. In the example above, the cpulimit and max_file_size parameters are overwritten by the custom template.

As you can see in the example file, you have to use the long form of the command line parameter (e.g. syslog) and not the short form (e.g. -s) in the template files. The long forms can be looked up in the command line help using --help.

Lookup command line parameter long forms using -help — Lookup command line parameter long forms using `–help`

CPU Limit (--cpulimit)

Since the --cpulimit behavior can cause some confusion, we will explain the functionality of it a bit more in detail here.

This argument will take an integer (default 95; minimum 15), which represents the maximum CPU load at which THOR will be actively scanning. The value can be seen as percentage of the systems maximum CPU load.

This can be helpful to reduce the load on server systems with real-time services, or to reduce the noise produced by fans in laptops.

The specified value instructs THOR to pause (all scanning), if the load of the systems CPU is higher than the cpulimit. One example would be, if a user is doing something CPU intensive, and THOR is running at the same time, THOR will pause and wait until the CPU load drops below the cpulimit before continuing.

To illustrate this a bit, please see the table below:

--cpulimit 40
Total CPU load of system	THOR status
20 %	running
80 % (user is running CPU intensive tools)	paused/idle
30 %	running

Hint

A tool like top might show values greater than 100% for a running THOR process. Please see Irix Mode in the man page of top: https://man7.org/linux/man-pages/man1/top.1.html

Maximum File Size

The default maximum file size for deeper investigations (hash calculation and YARA scanning) is 30 MB. The maximum file size for the -intense scan mode is 100 MB.

You can adjust the values in ./config/thor.yml. This file does not get overwritten by an update or upgrade.

Special scan features like the EVTX or Memory Dump scan ignore these limits.

Features that obey the file size limit:

YARA Matching
Hash calculation
STIX IOC application
ArchiveScan

Features that ignore the file size limit:

LogScan
RegistryHive scanning
EVTX scanning
DeepDive on memory dumps (selected by .dmp and magic headers)
Filename IOCs
YARA meta rules (only check the first 100 bytes of a file and all meta data)

If the --intense flag is used, a different file size limit is applied.

The only exception is ArchiveScan (e.g. ZIP file analysis) that has no file size limit in intense scan.

Chunk Size in DeepDive

The chunk size in DeepDive module is set to the value defined as maximum file size. DeepDive uses overlapping chunks of this size for YARA rule scanning.

Example: If the maximum file size is set to a default of 12 MB, DeepDive use the following chunks in its scan to apply the YARA rule set:

Chunk 1: Offset 0 – 12
Chunk 2: Offset 6 – 18
Chunk 3: Offset 12 – 24
Chunk 4: Offset 18 – 30

Exclude Elements

Files and Directories

You may use the file directory-excludes.cfg to exclude directories and files(! The name of the config file is misleading) from the scan.

THOR will not scan the contents of these directories. This directory-excludes.cfg config is meant to avoid scanning sensitive files like databases or directories with a lot of content. If you want to suppress false positives that are generated in these directories, please see the following chapter and how to suppress them by using false_positive_filters.cfg.

The exclusion file contains regular expressions that are applied to each scanned element. Each element consists of the file path and file name (e.g. C:\IBM\temp_tools\custom.exe). If one of the defined expressions matches, the element is excluded. Exclusions can be defined for a full element name, at the beginning at the end or somewhere in the element name.

Note

If used in combination with flags like --virtual-map that change the original path on the filesystem, the exclusions are applied to the real path on the filesystem, not the original path.

For example, when using --virtual-map F:C and scanning a file located at F:\Windows\explorer.exe, THOR will check if F:\Windows\explorer.exe is excluded, not if C:\Windows\explorer.exe is excluded.

As the configured exclusions are treated as regular expressions, special characters must be masqueraded by backslash. This applies at least for: []\^$.\|?\*+()-

Element to exclude	Possible solution
C:\IBM\temp_tools\custom.exe	`C:\\IBM\\temp_tools\\`
Log folder of the tool "hpsm" regardless on the partition	`\\HPSM\\log\\`
Every file with the extension .nsf	`\.nsf$`
THOR custom signatures	`\\THOR\\custom\-signatures\\`
SQL database	`/var/lib/mysql/`

Eventlogs

Eventlog sources can be excluded as whole in "eventlog-excludes.cfg". The file holds one expression per line and applies them as regular expression on the name of the Eventlog. (e.g. Microsoft-Windows-Windows Defender/Operational)

Element to exclude	Possible solution
Windows PowerShell	Windows PowerShell
Microsoft-Windows-Windows Defender/Operational	Windows Defender

Registry

Registry paths/keys can be excluded in registry-excludes.cfg. The file holds one expression per line and applies them as regular expression on each registry key. (e.g. “Software\WOW6432Node“). Don't include the root of the key, e.g. HKLM.

Element to exclude	Exclude Definition
`HKEY_LOCAL_MACHINE\Software\Wow6432Node\Symantec\Symantec Endpoint Protection\AV\Exclusions`	Symantec Endpoint Protection\AV\Exclusions

False Positives

The false positive filters work like the directory/file excludes. A regular expression is applied to the full event, excluding the event header (e.g. Sep 14 12:07:07 some-hostname/192.168.0.20).

E.g. if you want to Exclude all messages that contain the string Trojan_Buzus_dev you just add this string to the false_positive_filters.cfg file. The file works with regular expressions so you could also define something like chinese_(charcode|keyboard).

Filter Verification

If you are unsure about the filters you just set, we recommend a test run on a certain directory that matches the criteria.

You can start a short test run on a certain directory with:

C:\nextron\thor>thor.exe -a FileScan --intense -p C:\\TestDir

Personal Information

THOR features an option named --brd that allows to filter the output messages and replace all known locations and fields that can contain user names or user ids with the value ANONYMIZED_BY_THOR.

What it does is:

Replace all "USER" and "OWNER" field values of all modules with the anonymized string value
Replaced the subfolder names of C:\Users and C:\Documents and Settings with the anonymized string value

There is no guarantee that all user IDs will be removed by the filter, as they may appear in the most unexpected locations, but in most cases this approach is sufficient to comply with data protection requirements.

Output Options

Scan Output

THOR creates several files during and at the end of the scan.

Real Time
- the text log file is written during the scan process. Also the SYSLOG output is sent in real-time to one or more remote systems.
End of Scan
- the full HTML report and CSV file with all file scan elements reported as suspicious are written at the end of the scan.

You can define different formatting options for each the FILE and the SYSLOG output.

Placeholders

Two placeholders can be used in command line parameters to facilitate the use of parameter on different operating systems.

:hostname:
:time:

These can be used in command line parameters and scan templates across all platforms.

C:\thor>thor64.exe -a FileScan -p S:\\ -o :hostname:\_:time:.csv

Log File Output (.txt)

The standard log file is written by default.

--nolog
- Don't create a log file
--logfile filename
- Set a filename for the log file

The log file's format aligns with the format of SYSLOG messages. This way it can easily be imported to most SIEM or log analysis systems.

CSV Output (.csv)

The CSV output is an optional legacy output file without much details. It contains only “Filescan” module findings and consist of 3 columns, file hash, file path and score.

CSV File Output:

c926bf384319e40506e3d6e409dc856e,C:\PowerZure.ps1,140
62160f1a71507e35ebf104a660d92794,C:\f.bat,180
c926bf384319e40506e3d6e409dc856e,C:\ntds.dit,50
c926bf384319e40506e3d6e409dc856e,C:\temp\ntds.zip|ntds.dit,140
36a93511fc0e2e967bc5ced6a5bc36a6,C:\temp\ntds.zip,50
44b34aac3135dcb03ababac5f7767a55,C:\temp\windows-hardening.bat,60

Be aware that archives with matches show up as “archive.zip|file-with-finding.js” (pipe separator) in the second column.

If you need more columns in that CSV, consider processing the JSON output instead. To do this, you can use thor-util to convert logs from one format to the other:

https://thor-util-manual.nextron-systems.com/en/latest/usage/log-conversion.html

CSV Stats

The CSV stats file is an optional output file that contains only the scan statistics. It contains a single line with:

Hostname, scan start, scan end, THOR version, used command line flags, number of alerts, number of warnings, number of notices and number of errors

CSV Stats Output:

HYPERION,2021-02-17 17:01:25,2021-02-17 17:01:28,10.6.2,--lab -p C:temp -o HYPERION:time:.csv --csvstats,5,2,3,0

JSON Output (.json)

The JSON output file can be configured with these options:

--json (deprecated since THOR 10.7, use --jsonv2)
- Create a JSON output file
--jsonv2 (THOR >= 10.7)
- Use the JSON v2 format, which is easier to parse than the old v1 format.
- This can be used with --jsonfile.
--jsonfile filename
- Log file for JSON output. If no value is specified, defaults to :hostname:_thor_:time:.json.
--cmdjson
- Print JSON format into the command line (e.g. used with Splunk scripted input)
--syslog [syslogtarget]:[port]:SYSLOGJSON
- Send syslog messages with JSON formatting

Key Value Output

THOR provides the option to create a "Key/Value" pair output that simplifies the SIEM integration.

By using the "--keyval" option you get the text and syslog output transformed as shown in the following example. The command line output stays untouched by this setting.

There are three different Key Value Pair Formatting flags:

--keyval
- Write key/value pairs to the log file
--cmdkeyval
- Print key/value pairs in the command line (e.g. used with Splunk scripted input)
--syslog [syslogtarget]:[port]:SYSLOGKV
- Send syslog messages with proper key/value formatting

Default - Without "--keyval" parameter
Jul 10 09:08:47 PROMETHEUS/10.0.2.15 THOR: Alert: MODULE: SHIMCache MESSAGE: Malware name found in Shim Cache Entry ENTRY: C:\Users\neo\Desktop\ncat.exe KEYWORD: \\ncat\.exe DATE: 07/29/13 05:16:04 TYPE: system HIVEFILE: None EXTRAS: N/A N/A True

Key/Value Pairs - With "--keyval" parameter
Jul 10 09:07:59 PROMETHEUS/10.0.2.15 THOR : Alert: MODULE="SHIMCache" MESSAGE="Malware name found in Shim Cache Entry" ENTRY="C:\Users\neo\Desktop\ncat.exe" KEYWORD="\\ncat\.exe" DATE="07/29/13 05:16:04" TYPE="system" HIVEFILE="None" EXTRAS="N/A N/A True"

Audit trail

Audit trail output is available starting from THOR 10.8.

It contains different output from the other output options. Usually, THOR only prints elements (e.g. files, or registry entries) that have been matched on by some signature. Audit trail mode, on the other hand, contains _all_ scanned elements, even those that THOR considers inconspicious, as well as their (known) connections to each other.

This information can be used to visualize these elements, and help with grouping suspicious elements or laterally finding more suspicious elements.

Warning

Audit trail output comes with an overhead since THOR usually does not calculate all the information contained in the audit trail.

Output format

Audit trail output is a gzipped JSON file. The file can be specified with --audit-trail my-target-file.json.gz.

The file contains newline delimited JSON. where each contained JSON object follows the following schema:

{
   "id": "string",
   "details": {
      "...": "...",
   },
   "timestamps": {
      "...": "...",
   },
   "reasons": [
      {
         "summary": "string",
         "score": "int",
         "...": "...",
      }
   ],
   "references": [
      {
         "target-id": "string"
      }
   ]
}

id contains a unique ID for the element that was matched on
details contains the element that was matched on
timestamps contains all timestamps found within this element
reasons contains a list of signatures that matched on this element
references contains a list of IDs of other elements that this element referred to in some way

Timestamps

Timestamp in all modules are using the ANSI C format:

Mon Jan  2 15:04:05 2006
Mon Mar 19 09:04:05 2018

https://go.dev/src/time/format.go

UTC

The --utc parameter allows to use UTC in all timestamps.

RFC3339 Time Stamps

The parameter --rfc3339 generates time stamps for UTC time in the format described in RFC 3339. In contrast to the default time stamps RFC 3339 timestamps include a year and look like this:

2017-02-31T23:59:60Z

SCAN ID

The former parameter -i, which has been used for so-called case IDs (CID) has been repurposed to allow users to set a certain scan ID (SCANID) that appears in every log line.

The scan ID helps SIEM and analysis systems to correlate the scan lines from multiple scans on a single host. Otherwise it would be very difficult to answer the following questions:

How many scans completed successfully on a certain endpoint?
Which scan on a certain endpoint terminated during the scan run?

If no parameter is set, THOR will automatically generate a random scan ID, which starts with an S- and contains the following characters: a-zA-Z0-9_-

Example ScanIDs
S-Rooa61RfuuM
S-0vRKu-1_p7A

Users can overwrite the scan ID with -i myscanid to assign the logs of multiple scan runs to a single logical scan, e.g. if multiple partitions of a system get scanned in the lab in different scan runs, but should be shown as a single scan in Analysis Cockpit or your SIEM of choice.

In a log line, it looks like (set newlines for readability):

Jul 10 09:08:47 PROMETHEUS/10.0.2.15 THOR: Alert:
  MODULE: SHIMCache
  SCANID: S-r4GhEhEiIRg
  MESSAGE: Malware name found in Shim Cache Entry
  ENTRY: C:\Users\neo\Desktop\ncat.exe
  KEYWORD: \\ncat\.exe
  DATE: 07/29/13 05:16:04
  TYPE: system
  HIVEFILE: None
  EXTRAS: N/A N/A True

Custom Scan ID Prefix

Since THOR version 10.5 you are able to set you custom prefix by using --scanid-prefix. The fixed character "S" can be replaced with any custom string. This allows users to set an identifier for a group of scans that can be grouped together in a SIEM or Analysis Cockpit.

Syslog or TCP/UDP Output

Target Definition

THOR version 10 comes with a very flexible Syslog target definition. You can define as many targets as you like and give them different ports, protocols and formats.

For example, if you want to send the THOR log entries to a Syslog server and an ArcSight SIEM at the same time, you just have to define two log targets with different formats.

C:\nextron\thor>thor.exe -s syslog1.server.net -s arsight.server.net:514:CEF

The definition consists of 4 elements:

System

:

Port

:

Type

:

Protocol

The available options for each element are:

(target ip):(target port):(DEFAULT/CEF/JSON/SYSLOGJSON/SYSLOGKV):(UDP/TCP/TCPTLS)

The available type field values require an explication:

Option	Format
DEFAULT	standard THOR log format
CEF	Common Event Format (ArcSight)
JSON	Raw JSON
SYSLOGJSON	encoded and escaped single line JSON
SYSLOGKV	syslog messages that contain strict key/value pairs

There are default values, which do not have to be defined explicitly:

(your target system ip):514:DEFAULT:UDP

Sending Syslog to a target on a port that differs from the default port 514/udp looks like this:

--syslog 10.0.0.4:2514

Sending Syslog to a receiving server using an SSL/TLS encrypted TCP connection:

--syslog 10.0.0.4:6514:DEFAULT:TCPTLS

You can define as many targets as you like.

An often used combination sends JSON formatted messages to a certain UDP port:

--syslog 10.0.0.4:5444:JSON:UDP

Common Event Format (CEF)

THOR supports the CEF format for easy integration into ArcSight SIEM systems. The CEF mapping is applied to a log line if the syslog target has the CEF format set, e.g.:

C:\nextron\thor>thor.exe -s syslog1.server.local:514:CEF

Local Syslog

If your Linux system is already configured to forward syslog messages, you might just want to write to your local syslog and use the existing system configuration to forward the events. This can be achieved by using the --local-syslog flag.

THOR logs to the local0 facility, which is not being written to a file by default on every Linux distribution. By default Debian derivatives log it to /var/log/syslog; Others such as Red Hat do not. To enable writing local0 messages to a file a syslog configuration for rsyslog (e.g. /etc/rsyslog.conf) could look like:

# THOR --local-syslog destination
local0.*        -/var/log/thor

Do not forget to restart the syslog daemon (e.g. systemctl restart rsyslog.service).

You then either add that file in your syslog forwarding configuration or write to a file that is already forwarded instead.

Encrypted Output Files

THOR allows to encrypt the output files of each scan using the --encrypt parameter. A second parameter --pubkey can be used to specify a public key to use. The public key must be an RSA key of 1024, 2048 or 4096 bit size in PEM format.

C:\nextron\thor>thor64.exe --encrypt --pubkey mykey.pub

If you don't specify a public key, THOR uses a default key. The private key for this default key is stored in "thor-util", which can be used to decrypt output files encrypted with the default key.

nextron@unix:~$ thor-util decrypt file.txt

For more information on "thor-util" see the separate THOR Util manual.

Update

You can download updates for THOR with "thor-util".

Running thor-util --help shows two options that look very similar:

upgrade : program and signature updates
update : signature updates only

For more information on "thor-util" see the separate THOR Util manual.

Update Locations

The following servers are used as update mirrors and should be accessible via HTTPS (443/tcp):

update1.nextron-systems.com
update2.nextron-systems.com

Update Server Information

You can get information on the available update packages on this site:

https://update1.nextron-systems.com/info.php

Custom Signatures

THOR checks the contents of the ./custom-signatures folder and processes every file in this folder. The file extension determines the type of signature (e.g. a simple IOC file, a YARA rule or a Sigma rule). For some signature types, string tags in the file names are used to further distinguish the signatures.

For example, a file named my-c2-iocs.txt will be initialized as a file containing simple IOC indicators with C2 server information.

Internally the regex \Wc2\W is used to detect the tag, so mysource-c2-iocs.txt and dec15-batch1-c2-indicators.txt would be detected correctly, whereas filenameiocs.txt or myc2iocs.txt would not be detected.

If you do not wish to place your custom IOCs on potentially compromised systems during an engagements, you can use thor-util to encrypting custom signatures. This is described in detail in the THOR Util manual

Simple IOCs

Simple IOC files are basically CSV files that include the IOC and comments. Simple IOC files must have the extension .txt. encrypted simple IOC files must have the extension .dat.

The following tags for simple IOCs are currently supported:

"c2" or "domains"
- for IP addresses and hostnames
"filename" or "filenames"
- for filenames
"hash" or "hashes"
- for MD5, SHA1 or SHA256 hashes or (since THOR 10.7.6) Imphashs
"keyword" or "keywords"
- for string-based keywords
"trusted-hash" or "trusted-hashes" or "falsepositive-hash" or "falsepositive-hashes"
- for hashes that you trust
"handles"
- for malicious Mutex / Events
"pipes" or "pipe"
- for Named Pipes

Tag/String in File Name	Example
c2	misp-c2-domains-iocs.txt
filename	Case-UX22-filename-iocs.txt
filenames	Malicious-filenames-unitX.txt
hash	op-aura-hash-iocs.txt
hashes	int-misp-hashes.txt
keyword	Incident-22-keyword.txt
keywords	keywords-incident-3389.txt
trusted-hash	my-trusted-hashes.dat (encrypted)
handles	Operation-fallout-handles.txt
pipes	incident-22-named-pipes.txt

Hint

You can find IOC examples in the directory custom-signatures/iocs/templates of THOR. This should help you to create your own simple IOC files.

For a list of Features/Modules which are used by the different Simple IOCs, please see the table below.

Name	Type	Filename	Keyword	Named Pipe	Handle	Hash	C2
Amcache	Feature	Yes	Yes	No	No	Yes	No
Archive	Feature	Yes	No	No	No	Yes	No
AtJobs	Feature	Yes	Yes	No	No	No	No
AtJobs	Module	Yes	Yes	No	No	No	No
AuthorizedKeys	Feature	Yes	Yes	No	No	No	No
Autoruns	Module	Yes	No	No	No	Yes	No
Cron	Module	Yes	Yes	No	No	No	No
DeepDive	Module	No	No	No	No	No	No
DNSCache	Module	No	No	No	No	No	Yes
DumpScan	Feature	No	No	No	No	No	No
Eml	Feature	Yes	No	No	No	Yes	No
Env	Module	Yes	Yes	No	No	No	No
ETL	Feature	Yes	Yes	No	No	No	No
Eventlog	Module	Yes	Yes	No	No	No	No
Events	Module	Yes	Yes	No	Yes	No	No
EVTX	Feature	Yes	Yes	No	No	No	No
FileScan	Feature	Yes	No	No	No	Yes	No
FileScan	Module	Yes	No	No	No	Yes	No
Firewall	Module	No	No	No	No	No	Yes
Hosts	Module	No	Yes	No	No	No	Yes
KnowledgeDB	Module	No	Yes	No	No	No	No
Lnk	Feature	Yes	Yes	No	No	No	No
LoggedIn	Module	No	No	No	No	No	No
LogScan	Feature	Yes	Yes	No	No	No	No
LSASessions	Module	No	Yes	No	No	No	No
MFT	Module	Yes	Yes	No	No	No	No
Mutex	Module	Yes	Yes	No	Yes	No	No
NetworkSessions	Module	No	Yes	No	No	No	No
NetworkShares	Module	No	Yes	No	No	No	No
OLE	Feature	Yes	No	No	No	No	No
Pipes	Module	No	Yes	Yes	No	No	No
Prefetch	Feature	Yes	No	No	No	No	No
ProcessCheck	Module	Yes	Yes	No	Yes	No	Yes
ProcessConnections	Feature	Yes	Yes	No	No	No	Yes
ProcessHandles	Feature	Yes	Yes	No	Yes	No	No
Profiles	Module	No	Yes	No	No	No	No
RegistryChecks	Module	Yes	Yes	No	No	No	No
RegistryHive	Feature	Yes	Yes	No	No	No	No
ServiceCheck	Module	Yes	Yes	No	No	No	No
SHIMCache	Feature	Yes	Yes	No	No	No	No
SHIMCache	Module	Yes	Yes	No	No	No	No
TaskScheduler	Module	Yes	Yes	No	No	No	No
Users	Module	Yes	Yes	No	No	No	No
WER	Feature	Yes	No	No	No	No	No
WMIPersistence	Feature	Yes	Yes	No	No	No	No
WMIStartup	Module	No	Yes	No	No	No	No

Hashes

Files with the string hash or hashes in their filename get initialized as hash IOC sets. Either you are assigning a custom score to your hashes, or you do not assign a score at all, in which case the match will default to a score of 100.

The first column contains your MD5, SHA1 or SHA256 hash or (since THOR 10.7.6) an Imphash. The second column contains your comment, if you do not use any scoring. If you choose to use your own scoring (example below on line 2), the score goes into the second column and the comment into the third. Columns are separated by a semicolon and hashes are applied case-insensitively. Scoring and comments are optional.

custom-hashes-iocs.txt

0c2674c3a97c53082187d930efb645c2;DEEP PANDA Sakula Malware - http://goo.gl/R3e6eG
f05b1ee9e2f6ab704b8919d5071becbce6f9d0f9d0ba32a460c41d5272134abe;50;Vulnerable Lenovo Diagnostics Driver - https://github.com/alfarom256/CVE-2022-3699/tree/main

File Name IOCs

Filename IOC files allow you to define IOCs based on filename and filepath using regular expressions. You can add or reduce the total score of a file element during the scan with a positive (e.g. "40") or negative score (e.g. "-30").

While this can also be used to define false positives, or reduce the score of well-known files and locations, it gives you all the flexibility to add scores according to your needs.

Filename IOCs are case insensitive if they don't use any special regex characters (such as *, ., [, ...). Otherwise, they are case sensitive by default, but can be set as case insensitive by using (?i) anywhere in the regex.

custom-filename-iocs.txt

# Ncat Example
\\bin\\nc\.exe;-20

If you know that administrators in your organization use PsExec.exe in a folder named Sysinternals, but any other location should be reported as suspicious you could define the following statements:

psexec-filename-ioc.txt

# PsExec
\\PsExec\.exe;60
\\SysInternals\\PsExec\.exe;-60

This following example represents the 3^rd generation filename IOC format introduced with THOR version 8.30 and SPARK version 1.5, which is now the recommended form to define such signatures.

It contains three fields:

Column 1: Regex
Column 2: Score
Column 3: False Positive Regex

The False Positive Regex statement is only evaluated if the Regex statement in column 1 matched.

\\PsExec\.exe;60;\\SysInternals\\

We use this new format internally to describe abnormal locations of system files like

([C-Zc-z]:\\|\\\\).{1,40}\\svchost\.exe;65;(?i)(HKCR\\Applications|System32|system32|SYSTEM32|winsxs|WinSxS|SysWOW64|SysWow64|syswow64|SYSNATIVE|Sysnative|dllcache|WINXP|WINDOWS|i386|%system32%)\\

You could also score down directories with many false positives reported as "Notices" or "Warnings" like this:

\\directory_with_many_false_positives\\;-30

Keyword IOCs

The keyword-based IOC files contain plaintext strings that are matched against the console output of THOR. Not all console output is being used for those IOCs, you can find the full list here: Simple IOCs Modules.

One use case would be to have different strings which you encountered in Scheduled Tasks within Windows. Usually THOR will output all the Scheduled Tasks as Info, so this can help to look for specific things throughout the whole THOR scan.

Every line is treated as case-sensitive string. A comment can be specified with a line starting with a # and applies to all following IOCs until another comment is encountered.

Keyword IOCs are case sensitive.

custom-keyword-iocs.txt

# Evil strings from our case
sekurlsa::logonpasswords
failed to create Service 'GAMEOVER'
kiwi.eo.oe

C2 IOCs

C2 IOC files specify remote servers which are known to be malicious. This can include:

Domain names

FQDNs

Single IPs

IP address ranges in CIDR notation

These IOCs are applied to the connections of examined processes and can optionally be used to search process memory.

Each IOC must be placed on a single line. A comment can be specified with a line starting with a # and applies to all following IOCs until another comment is encountered. A score for the IOC can optionally be specified after the IOC, separated by a ;, it defaults to 100 if none is specified.

custom-c2-domains.txt

# Case 44 C2 Server
mastermind.eu
googleaccountservices.com
89.22.123.12
someotherdomain.biz;80

Mutex or Event Values

Custom mutex or event values can be provided in a file that contains the “handles” keyword in its filename. The entries can be string or regular expression values. The entries are applied to the processes handles as ”equals” if no unescaped special regex characters are used, otherwise they are applied as "contains" (though a regex can, of course, specify its match position by using ^ and/or $).

You can decide if you want to set a scope by using Global\\ or BaseNamedObjects\\ as a prefix. If you decide to use none, your expression will be applied to any scope. Mutex and event IOCs are case sensitive.

custom-mutex-iocs.txt

Global\\mymaliciousmutex;Operation Fallout – RAT Mutex
Global\\WMI_CONNECTION_RECV;Flame Event https://bit.ly/2KjUTuP
Dwm-[a-f0-9]{4}-ApiPort-[a-f0-9]{4};Chinese campaign malware June 19

Named Pipes

Custom named pipe values can be provided in a file that contains the "pipes" keyword in its filename. The entries should be regular expressions that match the malicious named pipes. The \\\\.\\pipe\\ prefix should not be part of the entry. The IOCs are applied to the pipes as "equals" if no unescaped special regex characters are used, otherwise they are applied as "contains" (though a regex can, of course, specify its match position by using ^ and/or $).

Optionally, a score can be added as 2nd field. If none is present, it defaults to 100. Named Pipe IOCs are case insensitive.

custom-named-pipes-iocs.txt

# Incident Response Engagement
MyMaliciousNamedPipe;Malicious pipe used by known RAT
MyInteresting[a-z]+Pipe;50;Interesting pipe we have seen in new malware

Rules

There are different types of rules you can use to write your own custom rules. This chapter will explain all the methods you can use to achieve this.

For a list of Features/Modules which are used by Sigma Rules, Generic YARA Rules and Specific YARA Rules, please see the table below.

Name	Type	Keyword rules	Log rules	Registry rules	Generic rules	Sigma Rules
Amcache	Feature	Yes	No	No	No	No
Archive	Feature	No	No	No	Yes	No
AtJobs	Feature	Yes	No	No	No	No
AtJobs	Module	Yes	No	No	No	No
AuthorizedKeys	Feature	Yes	No	No	No	No
Autoruns	Module	No	No	No	No	No
Cron	Module	Yes	No	No	No	No
DeepDive	Module	No	No	No	Yes	No
DNSCache	Module	No	No	No	No	No
DumpScan	Feature	No	No	No	Yes	No
Eml	Feature	No	No	No	Yes	No
Env	Module	Yes	No	No	No	No
ETL	Feature	Yes	Yes	No	No	Yes
Eventlog	Module	Yes	Yes	No	No	Yes
Events	Module	Yes	No	No	No	No
EVTX	Feature	Yes	Yes	No	No	Yes
FileScan	Feature	No	No	No	Yes	No
FileScan	Module	No	No	No	Yes	No
Firewall	Module	No	No	No	No	No
Hosts	Module	No	No	No	No	No
KnowledgeDB	Module	No	No	No	No	No
Lnk	Feature	Yes	No	No	No	No
LoggedIn	Module	No	No	No	No	No
LogScan	Feature	Yes	Yes	No	No	Yes
LSASessions	Module	No	No	No	No	No
MFT	Module	Yes	No	No	No	No
Mutex	Module	Yes	No	No	No	No
NetworkSessions	Module	No	No	No	No	No
NetworkShares	Module	No	No	No	No	No
OLE	Feature	No	No	No	Yes	No
Pipes	Module	No	No	No	No	No
Prefetch	Feature	No	No	No	No	No
ProcessCheck	Module	Yes	No	No	No	Yes
ProcessConnections	Feature	Yes	No	No	No	No
ProcessHandles	Feature	Yes	No	No	No	No
Profiles	Module	No	No	No	No	No
RegistryChecks	Module	Yes	No	Yes	No	No
RegistryHive	Feature	Yes	No	Yes	No	No
ServiceCheck	Module	Yes	No	No	No	No
SHIMCache	Feature	Yes	No	No	No	No
SHIMCache	Module	Yes	No	No	No	No
TaskScheduler	Module	Yes	No	No	No	No
Users	Module	Yes	No	No	No	No
WER	Feature	No	No	No	No	No
WMIPersistence	Feature	Yes	No	No	No	No
WMIStartup	Module	No	No	No	No	No

Sigma Rules

Sigma is a generic rule format for detections on log data. Sigma is for log data, what Snort is for network packets and YARA is for files.

THOR applies Sigma rules to Windows Eventlogs and log files on disk (.log). By default, THOR ships with the public Sigma rule set, which is maintained by the community at https://github.com/SigmaHQ/sigma.

To activate Sigma scanning, you have to use the --sigma command line option or perform an --intense scan. Sigma scanning is not activated by default. This behavior may change in the future.

By default only the results of Sigma rules of level critical and high are shown. If called with the --intense flag, medium level rules are applied as well.

Custom Sigma rules must have the .yml extension for unencrypted sigma rules and the .yms extension for encrypted sigma rules.

Example Sigma match on Windows Eventlog

Sigma Examples

Perform a scan with the Sigma rules on the different local Windows Eventlogs (-a Eventlog)

C:\tools\thor>thor64.exe -a Eventlog --sigma

Perform a scan with the Sigma rules on logs of Linux systems (-a LogScan) only

C:\tools\thor>thor64 -a Filesystem -p /var/log –sigma

YARA Rules

THOR allows you include your own custom YARA rules. YARA rules must have the .yar extension for plain text YARA rules and the .yas extension for encrypted YARA rules. (the rules can be encrypted using THOR Util)

Custom YARA rules have to be saved to the .\custom-signatures\yara folder. In order to apply only custom YARA rules and IOCs, use the --customonly flag.

There are two custom YARA rule types that you can define in THOR:

Generic Rules
Specific Rules

Generic YARA Rules

All YARA rules which do not contain any specific tag (see Specific YARA Rules) are considered generic YARA rules.

The generic YARA rules are applied to the following elements:

Files

THOR applies the Yara rules to all files that are smaller than the size limit set in the thor.yml and matches specific rules. Additional Attributes are available.
Process Memory

THOR scans the process memory of all processes with a working set memory size up to a certain limit. This limit can be altered by the "--max_process_size" parameter.
Data Chunks

The rules are applied to the data chunks read during the DeepDive scan. DeepDive only reports and restores chunks if the score level of the rule is high enough to cause at least a warning.

The following table shows in which modules the Generic YARA rules are applied to content.

Applied in Module

Examples

Filescan, ProcessCheck, DeepDive

incident-feb17.yar

misp-3345-samples.yar

Specific YARA Rules

The specific YARA rules contain certain tags in their filename to differentiate them further:

Registry Keys

Tag: 'registry'

Rules are applied to a whole key with all of its values. See THOR YARA Rules for Registry Detection for more details.
Log Files

Tag: 'log'

Rules are applied to each log entry. See THOR YARA Rules for Log Detection for more details.
Process Memory

Tag: 'process' or 'memory'

Rules are applied to process memory only.
All String Checks

Tag: 'keyword'

Rules are applied to all string checks in many different modules.
Metadata Checks (since THOR 10.6)

Tag: 'meta'

Rules are applied to all files without exception, including directories, symlinks and the like, but can only access the THOR specific external variables (see Additional Attributes) and the first 2048 bytes of the file.

Since THOR 10.6.8: If a metadata rule has the special tag DEEPSCAN, THOR will perform a YARA scan on the full file with the default rule set (see Generic YARA Rules).

Since THOR 10.7: Symlinks now have their target as the content.

Since THOR 10.8: Directories now have their directory listing (as file names, separated by newlines) as the content.

The following table shows in which modules the specific YARA rules are applied to content.

Tag in File Name	Applied in Module	Examples
registry	RegistryChecks, RegistryHive	incident-feb17-registry.yar
log	Eventlog, Logscan, EVTX	general-log-strings.yar
process	ProcessCheck (only on process memory)	case-a23-process-rules.yar
keyword	Mutex, Named Pipes, Eventlog, MFT, ProcessCheck (on all process handles), ProcessHandles, ServiceCheck, AtJobs, LogScan, AmCache, SHIMCache, Registry	misp-3345-keyword-extract.yar
meta	Filescan	meta-rules.yar

THOR YARA Rules for Registry Detection

THOR allows checking a complete registry path key/value pairs with Yara rules. To accomplish this, THOR composes a string from the key/value pairs of a registry key path and formats them as shown in the following screenshot.

Composed strings from registry key/value pairs

The composed format is:

KEYPATH;KEY;VALUE\n
KEYPATH;KEY;VALUE\n
KEYPATH;KEY;VALUE\n

Registry Base Names

Please notice that strings like HKEY_LOCAL_MACHINE, HKLM, HKCU, HKEY_CURRENT_CONFIG are not part of the key path that your YARA rules are applied to. They depend on the analyzed hive and should not be in the strings that you define in your rules.

Values are formatted as follows:

REG_BINARY values are hex encoded with upper case.

REG_MULTI_SZ values are printed with \\0 separating the multiple strings.

Numeric values are printed normally (with base 10; e.g., use 32 for REG_DWORD 0x00000020).

String values are printed normally.

This means that you can write a Yara rule that looks like this (remember to escape all backslashes):

rule Registry_DarkComet {
        meta:
                description = "DarkComet Registry Keys"
        strings:
                $a1 = "LEGACY_MY_DRIVERLINKNAME_TEST;NextInstance"
                $a2 = "\\Microsoft\\Windows\\CurrentVersion\\Run;MicroUpdate"
                $a3 = "Path;Value;4D5A00000001" # REG_BINARY value
                $a4 = "Shell\\Open;Command;explorer.exe\\0comet.exe" # REG_MULTI_SZ value
                $a5 = ";Type;32" # REG_DWORD 0x00000020
        condition:
                1 of them
}

Remember that you have to use the keyword registry in the file name in order to initialize the YARA rule file as registry rule set (e.g. "registry_exe_in_value.yar").

Registry scanning uses bulk scanning. See Bulk Scanning for more details.

THOR YARA Rules for Log Detection

YARA Rules for logs are applied as follows:

For text logs, each line is passed to the YARA rules.
For Windows Event Logs, each event is serialized as follows for the YARA rules: Key1: Value1 Key2: Value2 ... where each key / value pair is an entry in EventData or UserData in the XML representation of the event.

Log (both text log and event log) scanning uses bulk scanning. See Bulk Scanning for more details.

Remember that you have to use the keyword log in the file name in order to initialize the YARA rule file as registry rule set (e.g. my_log_rule.yar).

How to Create YARA Rules

Using the UNIX "string" command on Linux systems or in a CYGWIN environment enables you to extract specific strings from your sample base and write your own rules within minutes. Use "string -el" to also extract the UNICODE strings from the executable.

A useful Yara Rule Generator called "yarGen" provided by our developers can be downloaded from Github. It takes a target directory as input and generates rules for all files in this directory and so called "super rules" if characteristics from different files can be used to generate a single rule to match them all. (https://github.com/Neo23x0/yarGen)

Another project to mention is the "Yara Generator", which creates a single Yara rule from one or multiple malware samples. Placing several malware files of the same family in the directory that gets analyzed by the generator will lead to a signature that matches all descendants of that family. (https://github.com/Xen0ph0n/YaraGenerator)

We recommend testing the Yara rule with the "yara" binary before including it into THOR because THOR does not provide a useful debugging mechanism for Yara rules. The Yara binary can be downloaded from the developers' website (https://github.com/VirusTotal/yara).

The best practice steps to generate a custom rule are:

Extract information from the malware sample

(Strings, Byte Code, MD5 …)
Create a new Yara rule file. It is important to:
1. Define a unique rule name – duplicates lead to errors
2. Give a description that you want to see when the signature matches
3. Define an appropriate score (optional but useful in THOR, default is 75)
Check your rule by scanning the malware with the Yara binary from the project's website to verify a positive match
Check your rule by scanning the "Windows" or "Program Files" directory with the Yara binary from the project's website to detect possible false positives
Copy the file to the "/custom-signatures/yara" folder of THOR and start THOR to check if the rule integrates well and no error is thrown

There are some THOR specific add-ons you may use to enhance your rules.

Also see these articles on how to write "simple but sound" YARA rules:

https://www.nextron-systems.com/2015/02/16/write-simple-sound-yara-rules/

https://www.nextron-systems.com/2015/10/17/how-to-write-simple-but-sound-yara-rules-part-2/

Typical Pitfalls

Some signatures - even the ones published by well-known vendors - cause problems on certain files. The most common source of trouble is the use of regular expressions with a variable length as shown in the following example. This APT1 rule published by the AlienVault team caused the Yara Binary as well as the THOR binary to run into a loop while checking certain malicious files. The reason why this happened is the string expression "$gif1" which causes Yara to check for a "word character" of undefined length. Try to avoid regular expressions of undefined length and everything works fine.

AlientVault APT1 Rule: yara

 rule APT1_WEBC2_TABLE {
     meta:
          author = "AlienVault Labs"
     strings:
          $msg1 = "Fail To Execute The Command" wide ascii
          $msg2 = "Execute The Command Successfully" wide
          $gif1 = /\w+\.gif/
          $gif2 = "GIF89" wide ascii
     condition:
          3 of them
 }

Copying your rule to the signatures directory may cause THOR to fail during rule initialization. If this happens you should check your rule again with the Yara binary. Usually this is caused by a duplicate rule name or syntactical errors.

YARA Rule Performance

We compiled a set of guidelines to improve the performance of YARA rules. By following these guidelines you avoid rules that cause many CPU cycles and hamper the scan process.

https://gist.github.com/Neo23x0/e3d4e316d7441d9143c7

STIX IOCs

THOR can read and apply IOCs provided in STIXv2 JSON files. They must have the .json extension for unencrypted STIXv2 files and the .jsos extension for encrypted STIXv2 files.

The following observables are supported.

file:name with
- =
- !=
- LIKE
- MATCHES
file:parent_directory_ref.path with
- =
- !=
- LIKE
- MATCHES
file:hashes.sha-256 / file:hashes.sha256 with
- =
- !=
file:hashes.sha-1 / file:hashes.sha1 with
- =
- !=
file:hashes.md-5 / file:hashes.md5 with
- =
- !=
file:size with
- <
- <=
- >
- >=
- =
- !=
file:created with
- <
- <=
- >
- >=
- =
- !=
file:modified with
- <
- <=
- >
- >=
- =
- !=
file:accessed with
- <
- <=
- >
- >=
- =
- !=
win-registry-key:key with
- =
- !=
- LIKE
- MATCHES
win-registry-key:values.name with
- =
- !=
- LIKE
- MATCHES
win-registry-key:values.data with with
- =
- !=
- LIKE
- MATCHES
win-registry-key:values.modified_time with
- <
- <=
- >
- >=
- =
- !=

STIX v1

STIX version 1 is not supported.

Enhance YARA Rules with THOR Specific Attributes

The following listing shows a typical YARA rule with the three main sections "meta", "strings" and "condition". The YARA Rule Manual which can be downloaded as PDF from the developer's website and is bundled with the THOR binary is a very useful guide and reference to get a function and keyword overview and build your own rules based on the YARA standard.

The "meta" section contains all types of meta information and can be extended freely to include own attributes. The "strings" section lists strings, regular expressions or hex string to identify the malware or hack tool. The condition section defines the condition on which the rule generates a "match". It can combine various strings and handles keywords like "not" or "all of them".

Simple Yara Rule:

rule simple_demo_rule_1 {
     meta:
          description = "Demo Rule"
     strings:
          $a1 = "EICAR-STANDARD-ANTIVIRUS-TEST-FILE"
     condition:
          $a1
}

The following listing shows a more complex rule that includes a lot of keywords used in typical rules included in the rule set.

Complex Yara Rule:

rule complex_demo_rule_1 {
    meta:
         description = "Demo Rule"
    strings:
         $a1 = "EICAR-STANDARD-ANTIVIRUS-TEST-FILE"
         $a2 = "li0n" fullword
         $a3 = /msupdate\.(exe|dll)/ nocase
         $a4 = { 00 45 9A ?? 00 00 00 AA }
         $fp = "MSWORD"
    condition:
         1 of ($a*) and not $fp
}

The example above shows the most common keywords used in our THOR rule set. These keywords are included in the YARA standard. The rule does not contain any THOR specific expressions.

Yara provides a lot of functionality but lacks some mayor attributes that are required to describe an indicator of compromise (IOC) defined in other standards as i.e. OpenIOC entirely. Yara's signature description aims to detect any kind of string or byte code within a file but is not able to match on meta data attributes like file names, file path, extensions and so on.

THOR adds functionality to overcome these limitations.

Score

THOR makes use of the possibility to extend the Meta information section by adding a new parameter called "score".

This parameter is the essential value of the scoring system, which enables THOR to increment a total score for an object and generate a message of the appropriate level according to the final score.

Every time a signature matches the value of the score attribute is added to the total score of an object.

Yara Rule with THOR specific attribute "score":

rule demo_rule_score {
    meta:
         description = "Demo Rule"
         score = 80
    strings:
         $a1 = "EICAR-STANDARD-ANTIVIRUS-TEST-FILE"
         $a2 = "honkers" fullword
    condition:
         1 of them
}

Feel free to set your own "score" values in rules you create. If you don't define a "score" the rule gets a default score of 75.

The scoring system allows you to include ambiguous, low scoring rules that can't be used with other scanners, as they would generate to many false positives. If you noticed a string that is used in malware as well as legitimate files, just assign a low score or combine it with other attributes, which are used by THOR to enhance the functionality and are described in Additional Attributes.

Additional Attributes

THOR allows using certain external variables in your generic and meta YARA rules. These external variables are:

filename
- single file name
- Example: cmd.exe
filepath
- file path without file name
- Example: C:\temp
extension
- file extension with a leading ., lower case
- Example: .exe
filetype
- type of the file based on the magic header signatures (for a list of valid file types see: ./signatures/misc/file-type-signatures.cfg)
- Example: EXE or ZIP
timezone
- the system's time zone (see https://golang.org/src/time/zoneinfo_abbrs_windows.go for valid values)
language
- the systems language settings (see https://docs.microsoft.com/en-us/windows/win32/intl/sort-order-identifiers)
owner
- The file owner
- Example: NT-AUTHORITY\SYSTEM on Windows
- Example: root on Linux
group (available since THOR 10.6.8)
- The file group
- Example: root on Linux
- This variable is empty on Windows
filemode (available since THOR 10.6)
- file mode for this file (see https://man7.org/linux/man-pages/man7/inode.7.html, "The file type and mode").
- On Windows, this variable will be an artificial approximation of a file mode since Windows is not POSIX compliant.
filesize
- The value contains the file size in bytes. It is provided directly by YARA and is not specific to THOR.

Yara Rule with THOR External Variable:

rule demo_rule_enhanced_attribute_1 {
     meta:
          description = "Demo Rule - Eicar"
     strings:
          $a1 = "EICAR-STANDARD-ANTIVIRUS-TEST-FILE"
     condition:
          $a1 and filename matches /eicar.com/
}

A more complex rule using several of the THOR external variables would look like the one in the following listing.

This rule matches to all files containing the EICAR string, having the name "eicar.com", "eicar.dll" or "eicar.exe" and a file size smaller 100byte.

Yara Rule with more complex THOR Enhanced Attributes.

rule demo_rule_enhanced_attribute_2 {
     meta:
          author = "F.Roth"
     strings:
          $a1 = "EICAR-STANDARD-ANTIVIRUS-TEST-FILE"
     condition:
          $a1 and filename matches /eicar\.(com|dll|exe)/ and filesize < 100
}

The following YARA rule shows a typical combination used in one of the client specific rule sets, which are integrated in THOR. The rule matches on .idx files that contain strings used in the Java Version of the VNC remote access tool. Without the enhancements made this wouldn't be possible as there would be no way to apply the rule only to a special type of extension.

Real Life Yara Rule:

rule HvS_Client_2_APT_Java_IDX_Content_hard {
     meta:
          description = "VNCViewer.jar Entry in Java IDX file"
     strings:
          $a1 = "vncviewer.jar"
          $a2 = "vncviewer/VNCViewer.class"
     condition:
          1 of ($a*) and extension matches /\.idx/
}

Bulk Scanning

THOR scans registry and log entries in bulks since each YARA invocation has a relatively high overhead. This means that during the scan, the following happens:

THOR gathers entries that need to be scanned.
When sufficiently many entries are gathered, all of them are combined (separated by line breaks) and passed to YARA.
If any YARA rule matches, each entry is scanned separately with YARA to determine whether any YARA rule matches for this specific entry.

One potential caveat of this is that false positive strings may prevent a rule from ever applying.

For example, consider this rule:

rule FakeMicrosoftStartupEntry {
     strings:
          $s1 = "Microsoft\\SomeRegistryKey;ShouldBeUsedOnlyByMicrosoft;"
          $fp = "Windows\\System32"
     condition:
          $s1 and not $fp
}

This rule is meant to match if the specified registry key contains some DLL that is not in C:\Windows\System32. However, the false positive string may inadvertently match on other entries in the bulk, like here:

Path\to\Microsoft\SomeRegistryKey;ShouldBeUsedOnlyByMicrosoft;C:\evil.exe
...
Path\to\SomeOtherRegistryKey;Entry;C:\Windows\System32\explorer.exe
...

Because the rule does not apply to the bulk, THOR never scans the single elements and does not report any match. Therefore, be very careful with false positive strings with log or registry YARA rules.

A possible workaround for this issue is to define the false positive strings in ways that they can't match anywhere else, e.g. like this:

rule FakeMicrosoftStartupEntry {
     strings:
          $s1 = "Microsoft\\SomeRegistryKey;ShouldBeUsedOnlyByMicrosoft;"
          $fp = /Microsoft\\SomeRegistryKey;ShouldBeUsedOnlyByMicrosoft;[^\n]{0,40}Windows\\System32/
     condition:
          $s1 and not $fp
}

Restrict Yara Rule Matches

On top of the keyword based initialization you can restrict Yara rules to match on certain objects only. It is sometimes necessary to restrict rules that e.g. cause many false positives on process memory to file object detection only. Use the meta attribute "type" to define if the rule should apply to file objects or process memory only.

Apply rule in-memory only:

rule Malware_in_memory {
     meta:
          author = "Florian Roth"
          description = "Think Tank Campaign"
          type = "memory"
     strings:
          $s1 = "evilstring-inmemory-only"
     condition:
          1 of them
}

Apply rule on file objects only:

rule Malware_in_fileobject {
     meta:
          description = "Think Tank Campaign"
          type = "file"
     strings:
          $s1 = "evilstring-infile-only"
     condition:
          1 of them
}

You can also decide if a rule should not match in "DeepDive" module by setting the "nodeepdive" attribute to "1".

Avoid DeepDive application:

rule Malware_avoid_DeepDive {
     meta:
          description = "Think Tank Campaign"
          nodeepdive = 1
     strings:
          $s1 = "evilstring-not-deepdive"
     condition:
          1 of them
}

If you have problems with false positives caused by the specific YARA rules, try using the "limit" modifier in the meta data section of your YARA rule. Using the "limit" attribute, you can limit the scope of your rules to a certain module. (Important: Use the module name as stated in the log messages of the module, e.g. "ServiceCheck" and not "services")

E.g. if you have defined a malicious 'Mutex' named '_evtx_' in a rule and saved it to a file named "mutex-keyword.yar", the string "_evtx_" will be reported in all other modules to which the keyword rules are applied – e.g. during the Eventlog scan.

You can limit the scope of your rule by setting 'limit = "Mutex"' in the meta data section of the YARA rule.

Limits detection to the "Mutex" module:

rule Malicious_Mutex_Evtx {
     meta:
          description = "Detects malicious mutex EVTX"
          limit = "Mutex"
     strings:
          $s1 = "_evtx_"
     condition:
          1 of them
}

Notes:

the internal check in THOR against the module name is case-insensitive
this "limit" parameter only applies to specific YARA rules (legacy reasons – will be normalized in a future THOR version)

False Positive Yara Rules

Yara rules that have the "falsepositive" flag set will cause a score reduction on the respective element by the value defined in the "score" attribute. Do not use a negative score value in YARA rules.

False Positive Rule:

rule FalsePositive_AVSig1 {
     meta:
          description = "Match on McAfee Signature Files"
          falsepositive = 1
          score = 50
     strings:
          $s1 = "%%%McAfee-Signature%%%"
     condition:
          1 of them
}

Command Line Options

This section lists all options that THOR TechPreview currently offers.

Scan Options

-t, --template string

Process default scan parameters from this YAML file

--generate-config

Print a YAML config from the given parameters and exit

-p, --path strings

Scan a specific file path. Define multiple paths by specifying this option multiple times. Append ':NOWALK' to the path for non-recursive scanning (default: only the system drive)

--allhds

(Windows Only) Scan all local hard drives (default: only the system drive)

--alldrives

Scan all local drives, including network drives (default: only the system drive). Requires a Forensic Lab license.

--max_file_size uint

Max. file size to check (larger files are ignored). Increasing this limit will also increase memory usage of THOR.

--max_log_lines int

Maximum amount of lines to check in a log file before skipping the remaining lines

--max_process_size uint

Max process size to check (larger processes won't be scanned)

--max_runtime int

Maximum runtime in hours. THOR will stop once this time has run out. 0 means no maximum runtime.

--nodoublecheck

Don't check whether another THOR instance is running (e.g. in Lab use cases when several mounted images are scanned simultaneously on a single system) (requires a Forensic Lab license)

-f, --epoch strings

Specify a range of days with attacker activity as start and end date pairs.

Files created/modified between these days (including the specified start, excluding the specified end) will receive an extra score.

Example: -f 2009-10-09 -f 2009-10-10 marks the 09.10.2009 as relevant.

--epochscore int

Score to add for files that were created/modified on days with attacker activity (see --epoch parameter)

--insecure

Skip TLS host verification (insecure)

--ca strings

Root CA for host certificate verification during TLS handshakes

--cross-platform

Apply IOCs with path separators platform independently.

--require-admin

Terminate immediately if THOR is executed without administrator rights.

--follow-symlinks

When encountering a symlink during the file scan that points to a directory, scan the directory.

--max-recursion-depth uint

Maximum depth of archives to scan

--max-nested-objects uint

Maximum number of files per archive to scan

Scan Modes

--quick

Activate a number of flags to speed up the scan at cost of some detection.

This is equivalent to: --noeventlog --nofirewall --noprofiles --nologscan --noevtx --nohotfixes --nomft --lookback 3 --lookback-modules filescan

--soft

Skip CPU and RAM intensive modules (Mutexes, Firewall, Logons, Network sessions and shares, LSA sessions, open files, hosts file), don't decompress executables and doesn't perform a DoublePulsar backdoor check, lower max CPU usage to 70% and set low priority for THOR.

This mode activates automatically on systems with 1 CPU core or less than 1024 MB RAM.

--intense

Paranoid scan mode that disables all safe guards. Only use this mode in lab scanning scenarios. We don't recommend using this mode to live scan productive systems. (enables: memory intensive extra modules)

--diff

Set lookback time (see --lookback) for each module to the last time the module ran successfully and activates --global-lookback.

Effectively, this means that only elements that changed since the last scan are examined. (only works if ThorDB has been active)

--lookback int

Specify how many past days shall be analyzed. Event log entries from before this point will be ignored. 0 means no limit

--global-lookback

Apply Lookback to all modules that support it (not only Eventlog). See also --lookback and --lookback-modules.

Warning: Timestomping or similar methods of antivirus evasion may result in elements not being examined.

--force-aptdir-lookback

Enforce lookback application on all files in the FileScan module. By default, especially endangered directories ignore the lookback value.

--lookback-modules strings

Apply Lookback to the given modules. See also --lookback and --modules.

Warning: Timestomping or similar methods of antivirus evasion may result in elements not being examined.

--lab

Lab scan mode - scan only the file system, disable resource checks and quick mode, activate intense mode, disable ThorDB, apply IOCs platform independently and use all CPU cores.

This option scans all drives by default, but is often used with -p to scan only a single path. Requires a Forensic Lab license.

--virtual-map strings

Rewrite found file paths to use a different prefix.

This can be useful for mounted images, where the current location of files does not match the original location and therefore references might be out of date.

Specify the original and current path as --virtual-map path/to/current/location:path/to/original/location.

On Windows, drive names are also supported, e.g. specify --virtual-map F:C if the drive on F: was originally used as C:.

Requires a Forensic Lab license.

Resource Options

-c, --cpulimit float

Limit CPU usage of THOR to this level (in percent). Minimum is 15%

--nocpulimit

Disable cpulimit check

--nosoft

Disable automatic activation of soft mode (see --soft)

--norescontrol

Do not check whether the system is running out of resources. Use this option to enforce scans that have been canceled due to resource scarcity. (use with care!)

--minmem uint

Cancel the running scan if the amount of free physical memory drops below this value (in MB)

--lowprio

Reduce the priority of the THOR process to a lower level

--verylowprio

Reduce the priority of the THOR process to a very low level

--lowioprio

Reduce the disk priority of the THOR process to a lower level

--nolowprio

Do not reduce the priority of the THOR process to a lower level due to soft mode (see --soft)

--nolockthread

Do not lock calls to C libraries to main thread (this may increase performance at the cost of memory usage)

--yara-stack-size int

Allocate this number of slots for the YARA stack. Default: 16384. Increasing this limit will allow you to use larger rules, albeit with more memory overhead.

--yara-timeout int

Cancel any YARA checks that take longer this amount of time (in seconds)

--threads uint16

Run this amount of THOR threads in parallel. Requires a Forensic Lab license.

--bulk-size uint

Check this amount of elements together, e.g. log lines or registry entries

Special Scan Modes

-m, --image_file string

Scan only the given single memory image / dump file (don't use for disk images, scan them mounted with --lab). Requires a Forensic Lab license.

--image-chunk-size uint

Scan image / dump files in chunks of this size

-r, --restore_directory string

Restore PE files with YARA rule matches during the DeepDive into the given folder

--restore_score int

Restore only chunks with a total match score higher than the given value

--dropzone

Watch and scan all files dropped to a certain directory (which must be passed with -p). Disable resource checks and quick mode, activate intense mode, disable ThorDB and apply IOCs platform independently. Requires a Forensic Lab license.

--dropdelete

Delete all files dropped to the drop zone after the scan.

Thor Thunderstorm Service

--thunderstorm

Watch and scan all files sent to a specific port (see --server-port). Disable resource checks and quick mode, activate intense mode, disable ThorDB and apply IOCs platform independently.

--server-upload-dir string

Path to a directory where THOR drops uploaded files.

If this path does not exist, THOR tries to create it.

--server-host string

IP address that THOR's server should bind to.

--server-port uint16

TCP port that THOR's server should bind to.

--server-cert string

TLS certificate that THOR's server should use. If left empty, TLS is not used.

--server-key string

Private key for the TLS certificate that THOR's server should use. Required if --server-cert is specified.

--server-store-samples string

Sets whether samples should be stored permanently in the folder specified with --server-upload-dir.

Specify "all" to store all samples, or "malicious" to store only samples that generated a warning or an alert.

--server-result-cache-size uint32

Size of the cache that is used to store results of asynchronous requests temporarily.

If set to 0, the cache is disabled and asynchronous results are not stored.

--pure-yara

Only scan files using YARA signatures (disables all programmatic checks, STIX, Sigma, IOCs, as well as most features and modules)

--sync-only-threads uint16

Reserve this amount of THOR threads for synchronous requests

--force-max-file-size

Enforce the maximum file size even on files like registry hives or log files which are usually scanned despite size.

License Retrieval

--asgard string

Hostname of the ASGARD server from which a license should be requested, e.g. asgard.my-company.internal

--asgard-token string

Use this token to authenticate with the License API of the asgard server. The token can be found in the 'Downloads' or 'Licensing' section in the ASGARD. This requires ASGARD 2.5+.

-q, --license-path string

Path containing the THOR license

--portal-key string

Get a license for this host from portal.nextron-systems.com using this API Key.

This feature is only supported for host-based server / workstation contracts.

--portal-contracts ints

Use these contracts for license generation. If no contract is specified, the portal selects a contract by itself. See --portal-key.

--portal-nonewlic

Only use an existing license from the portal. If none exists, exit. See --portal-key.

Active Modules

-a, --module strings

Activate the following modules only (Specify multiple modules with -a Module1 -a Module2 ... -a ModuleN).

--noprocs

Do not analyze Processes

--nofilesystem

Do not scan the file system

--noreg

Do not analyze the registry

--nousers

Do not analyze user accounts

--nologons

Do not show currently logged in users

--noautoruns

Do not analyse autorun elements

--noeventlog

Do not analyse the eventlog

--norootkits

Do not check for rootkits

--noevents

Do not check for malicious events

--nodnscache

Do not analyze the local DNS cache

--noenv

Do not analyze environment variables

--nohosts

Do not analyze the hosts file

--nomutex

Do not check for malicious mutexes

--notasks

Do not analyse scheduled tasks

--noservices

Do not analyze services

--noprofiles

Do not analyze profile directories

--noatjobs

Do not analyze jobs scheduled with the 'at' tool

--nonetworksessions

Do not analyze network sessions

--nonetworkshares

Do not analyze network shares

--noshimcache

Do not analyze SHIM Cache entries

--nohotfixes

Do not analyze Hotfixes

--nowmistartup

Do not analyze startup elements using WMI

--nofirewall

Do not analyze the local Firewall

--nowmi

Disable all checks with WMI functions

--nolsasessions

Do not analyze lsa sessions

--nomft

Do not analyze the drive's MFT (default, unless in intense mode)

--mft

Analyze the drive's MFT

--nopipes

Do not analyze named pipes

--noetwwatcher

Do not analyze ETW logs during THOR runtime

--nointegritycheck

Do not check with the package manager for package integrity on Linux

--notimestomp

Disable timestomping detection

Module Extras

--process ints

Process IDs to be scanned. Define multiple processes by specifying this option multiple times (default: all processes) (Module: ProcessCheck)

--dump-procs

Generate process dumps for suspicious or malicious processes (Module: ProcessCheck)

--max-procdumps uint

Create at most this many process dumps (Module: ProcessCheck)

--procdump-dir string

Store process dumps of suspicious processes in this directory (Module: ProcessCheck)

-n, --eventlog-target strings

Scan specific Eventlogs (e.g. 'Security' or 'Microsoft-Windows-Sysmon/Operational') (Module: Eventlog)

--nodoublepulsar

Do not check for DoublePulsar Backdoor (Module: Rootkit)

--full-registry

Do not skip registry hives keys with less relevance (Module: Registry)

--noregwalk

Do not scan the whole registry during the registry scan

--showdeleted

Show deleted files found in the MFT as 'info' messages.

--allfiles

Scan all files, even ones that are usually not interesting. Sets --max_file_size to 200MB unless specified otherwise.

--ads

Scan Alternate Data Streams for all files

Active Features

--nothordb

Do not use or create ThorDB database for holding scan information

--nosigma

Disable Sigma signatures

--dumpscan

Scan memory dumps

--nologscan

Do not scan log files (identified by .log extension or location)

--noyara

Disable checks with YARA

--nostix

Disable checks with STIX

--noarchive

Do not scan contents of archives

--noc2

Disable checks for known C2 Domains

--noprochandles

Do not analyze process handles

--noprocconnections

Do not analyze process connections

--noamcache

Do not analyze Amcache files

--noregistryhive

Do not analyze Registry Hive files

--noexedecompress

Do not decompress and scan portable executables

--nowebdirscan

Do not analyze web directories that were found in process handles

--novulnerabilitycheck

Do not analyze system for vulnerabilities

--noprefetch

Do not analyze prefetch directory

--nogroupsxml

Do not analyze groups.xml

--nowmipersistence

Do not check WMI Persistence

--nolnk

Do not analyze LNK files

--noknowledgedb

Do not check Knowledge DB on Mac OS

--nower

Do not analyze .wer files

--noevtx

Do not analyze EVTX files

--noauthorizedkeys

Do not analyze authorized_keys files

--noimphash

Do not calculate imphash for suspicious EXE files (Windows only)

--c2-in-memory

Apply C2 IOCs on process memory (not recommended unless you are willing to accept many false positives on browser and other process memories)

--custom-c2-in-memory

Apply custom C2 IOCs on process memory

--noeml

Disable Email parser

--noetl

Disable ETL parser

Feature Extras

--customonly

Use custom signatures only (disables all internal THOR signatures and detections)

--full-proc-integrity

Increase sensitivity of --processintegrity for process impersonation detection. Likely to cause false positives, but also better at detecting real threats.

--processintegrity

Run PE-Sieve to check for process integrity (Windows only)

Output Options

-l, --logfile string

Log file for text output

--htmlfile string

Log file for HTML output

--nolog

Do not generate text or HTML log files

--nohtml

Do not create an HTML report file

--appendlog

Append text log to existing log instead of overwriting

--keyval

Format text and HTML log files with key value pairs to simplify the field extraction in SIEM systems (key='value')

--jsonfile string

Log file for JSON output. If no value is specified, defaults to :hostname:_thor_:time:.json.

-o, --csvfile string

Generate a CSV containing MD5,Filepath,Score for all files with at least the minimum score

--nocsv

Do not write a CSV of all mentioned files with MD5 hash (see --csvfile)

--stats-file string

Generate a CSV file containing the scan summary in a single line. If no value is specified, defaults to :hostname:_stats.csv.

-e, --rebase-dir string

Specify the output directory where all output files will be written. Defaults to the current working directory.

--suppresspi

Suppress all personal information in log outputs to comply with local data protection policies

--eventlog

Log to windows application eventlog

-x, --min int

Only report files with at least this score

--allreasons

Show all reasons why a match is considered dangerous (default: only the top 2 reasons are displayed)

--printshim

Include all SHIM cache entries in the output as 'info' level messages

--printamcache

Include all AmCache entries in the output as 'info' level messages

-j, --overwrite-hostname string

Override the local hostname value with a static value (useful when scanning mounted images in the lab. Requires a Forensic Lab license.

-i, --scanid string

Specify a scan identifier (useful to filter on the scan ID, should be unique)

--scanid-prefix string

Specify a prefix for the scan ID that is concatenated with a random ID if neither --scanid nor --noscanid are specified

--noscanid

Do not automatically generate a scan identifier if none is specified

--silent

Do not print anything to command line

--cmdjson

Format command line output as JSON

--cmdkeyval

Use key-value pairs for command line output, see --keyval

--encrypt

Encrypt the generated log files and the MD5 csv file

--pubkey string

Use this RSA public key to encrypt the logfile and csvfile (see --encrypt). Both --pubkey="<key>" and --pubkey="<file>" are supported.

--nocolor

Do not use ANSI escape sequences for colorized command line output

--genid

Print a unique ID for each log message. Identical log messages will have the same ID.

--print-rescontrol

Print THOR's resource threshold and usage when it is checked

--truncate int

Max. length per THOR value (0 = no truncation)

--registry_depth_print int

Don't print info messages when traversing registry keys at a higher depth than this

--utc

Print timestamps in UTC instead of local time zone

--rfc3339

Print timestamps in RFC3339 (YYYY-MM-DD'T'HH:mm:ss'Z') format

--reduced

Reduced output mode - only warnings, alerts and errors will be printed

--printlicenses

Print all licenses to command line (default: only 10 licenses will be printed)

--local-syslog

Print THOR events to local syslog

--showall

Print rule matches even if that rule already matched more than 10 times.

--ascii

Don't print non-ASCII characters to command line and log files

--string-context uint

When printing strings from YARA matches, include this many bytes surrounding the match

--include-info-in-html

Include info messages in the HTML report

--audit-trail string

Output file for audit trail

--background string

Optimize font colors for given terminal background (options: default, light, dark)

ThorDB

--dbfile string

Location of the thor.db file

--resumeonly

Don't start a new scan, only finish an interrupted one. If no interrupted scan exists, nothing is done.

--resume

Store information while running that allows to resume an interrupted scan later. If a previous scan was interrupted, resume it instead of starting a new one.

Syslog

-s, --syslog strings

Write output to the specified syslog server, format: server[:port[:syslogtype[:sockettype]]].

Supported syslog types: DEFAULT/CEF/JSON/SYSLOGJSON/SYSLOGKV

Supported socket types: UDP/TCP/TCPTLS

Examples: -s syslog1.dom.net, -s arcsight.dom.net:514:CEF:UDP, -s syslog2:4514:DEFAULT:TCP, -s syslog3:514:JSON:TCPTLS

--rfc3164

Truncate long Syslog messages to 1024 bytes

--rfc5424

Truncate long Syslog messages to 2048 bytes

--rfc

Use strict syslog according to RFC 3164 (simple host name, shortened message)

--maxsysloglength int

Truncate Syslog messages to the given length (0 means no truncation)

--cef_level int

Define the minimum severity level to log to CEF syslogs (Debug=1, Info=3, Notice=4, Error=5, Warning=8, Alarm=10)

Reporting and Actions

--notice int

Minimum score on which a notice is generated

--warning int

Minimum score on which a warning is generated

--alert int

Minimum score on which an alert is generated

--action_command string

Run this command for each file that has a score greater than the score from --action_level.

--action_args strings

Arguments to pass to the command specified via --action_command.

The placeholders %filename%, %filepath%, %file%, %ext%, %md5%, %score% and %date% are replaced at execution time.

--action_level int

Only run the command from --action_command for files with at least this score.

--nofserrors

Silently ignore filesystem errors

THOR Remote

--remote strings

Target host (use multiple --remote <host> statements for a set of hosts)

--remote-user string

Username (if not specified, windows integrated authentication is used)

--remote-password string

Password to be used to authenticate against remote hosts

--remote-prompt

Prompt for password for remote hosts

--remote-debug

Debug Mode for THOR Remote

--remote-dir string

Upload THOR to this remote directory

--remote-workers int

Number of concurrent scans

--remote-rate int

Number of seconds to wait between scan starts

Automatic Collection of Suspicious Files (Bifrost)

--bifrost2Server string

Server running the Bifrost 2 quarantine service. THOR will upload all suspicious files to this server.

This flag is only usable when invoking THOR from ASGARD 2.

--bifrost2Score int

Send all files with at least this score to the Bifrost 2 quarantine service.

This flag is only usable when invoking THOR from ASGARD 2.

VirusTotal Integration

--vtkey string

Virustotal API key for hash / sample uploads

--vtmode string

VirusTotal lookup mode (limited = hash lookups only, full = hash and sample uploads)

--vtscore int

Minimum score for hash lookup / sample upload to VirusTotal

--vtaccepteula

By specifying this option, you accept VirusTotal's EULA: https://www.virustotal.com/en/about/terms-of-service/

--vtwaitforquota

Wait if the VirusTotal API key quota is exceeded

--vtverbose

Show more information from VirusTotal

Debugging and Info

--debug

Show Debugging Output

--trace

Show Tracing Output

--printall

Print all files that are checked (noisy)

--print-signatures

Show THOR Signatures and IOCs and exit

--version

Show THOR, signature and software versions and exit

-h, --help

Show help for most important options and exit

--fullhelp

Show help for all options and exit

Debugging

Most unexpected behavior can be debugged by using the parameter --debug.

If you ever encounter a situation in which:

THOR doesn't produce an alert on a known malicious element
THOR exits with an error
THOR takes a long time or unexpected short time on elements

Collecting a Diagnostcs Pack

THOR Util comes with the functionality to collect a diagnostics pack for THOR scans. This is helpful if a scan is taking more time as expected or if THOR exits unexpectedly. More details can be found in the diagnostics section of THOR Util.

Debugging Examples

If you found the culprit for your problematic scan, try scanning that specific element with the --debug parameter set.

To run a scan only with certain modules only use the --module (short hand -a) command line switch (see Scan Module Names for a full list of module names):

C:\nextron\thor>thor64.exe -a Mutex
C:\nextron\thor>thor64.exe -a FileScan
C:\nextron\thor>thor64.exe -a Eventlog

Hint

You can specify multiple modules:

C:\nextron\thor>thor64.exe -a Mutex -a EnvCheck -a Users

You can try to reduce the scope of a module even further by using lookbacks

C:\nextron\thor>thor64.exe -a Eventlog --lookback 3
C:\nextron\thor>thor64.exe -a FileScan -p C:\Windows\System32 --globallookback --lookback 1

To find out why a certain file couldn't be detected, use --debug with --printall and try to switch into --intense mode.

C:\nextron\thor>thor64.exe -a Filescan -p C:\testfolder --debug --printall
C:\nextron\thor>thor64.exe -a Filescan -p C:\testfolder --debug --printall --intense

If it has been detected in --intense mode but not in default mode, the file extension or the magic header is most likely the problem. You can adjust max_file_size in ./config/thor.yml or add a magic header in ./signatures/misc/file-type-signatures.cfg.

Finding Bottlenecks

You may get the error message MODULE: RuntimeWatcher MESSAGE: Maximum runtime has exceeded, killing THOR or encounter very slow/never-ending scans.

You can check the statistics table in thor10.db on the problematic endpoint after a scan to determine the last element or elements that took a long time to process.

We recommend using: https://sqlitebrowser.org/

The THOR DB is located at: C:\ProgramData\thor\thor10.db.

Most Frequent Causes of Missing Alerts

Below you can find the most frequent causes of missing alerts.

THOR didn't scan file due to file size restrictions

Solution: Use the --max_file_size parameter or set it permanently in the config file ./config/thor.yml.

C:\nextron\thor>thor64.exe --max_file_size 206233600 # setting max file size to 100 MB

Default thor.yaml

# This is the default config for THOR
# Skip files bigger than 31457280 bytes
max_file_size: 31457280
# Skip files bigger than 209715200 bytes in intense mode (--lab, --intense)
max_file_size_intense: 209715200
# Terminate THOR if he runs longer than 168 hours
max_runtime: 168
# Limit THOR's CPU usage to 95%
cpulimit: 95
# The minimum amount of free physical memory to proceed (in MB)
minmem: 50
# Minimum score to report is 40
min: 40
# Truncate THOR's field values after 2048 characters
truncate: 2048

THOR didn't scan the file due to a skipped deeper inspection

This can be caused by two reasons:

The magic header of that file is not in the list of interesting magic headers (see ./signatures/misc/file-type-signatures.cfg) AND file doesn't have a relevant file extension:

.asp, .vbs, .ps, .ps1, .rar, .tmp, .bas, .bat, .chm, .cmd, .com, .cpl, .crt, .dll,
.exe, .hta, .js, .lnk, .msc, .ocx, .pcd, .pif, .pot, .pdf, .reg, .scr, .sct, .sys,
.url, .vb, .vbe, .vbs, .wsc, .wsf, .wsh, .ct, .t, .input, .war, .jsp, .php, .asp,
.aspx, .doc, .docx, .pdf, .xls, .xlsx, .ppt, .pptx, .tmp, .log, .dump, .pwd, .w,
.txt, .conf, .cfg, .conf, .config, .psd1, .psm1, .ps1xml, .clixml, .psc1, .pssc,
.pl, .www, .rdp, .jar, .docm, .ace, .job, .temp, .plg, .asm

Solution: Use an intense scanning mode for that folder (--intense) or add the magic header to file-type-signatures.cfg

Warning

This file gets overwritten with an update; Intense scanning mode threatens the scan and system stability!

THOR fails to initialize custom rules with the correct type

It happens very often that users that prepare custom IOCs or YARA rules forget to include the correct keyword in the filename of the IOC or YARA rule file.

The correct use of keywords is described in the chapters Simple IOCs for IOCs and Specific YARA Rules for YARA rules.

A wrong or missing keyword leads to situations in which a file that contains YARA rules that are meant to be applied to log files, but doesn't contain a "log" keyword in it's filename.

You can review a correct initialization in the command line output or log file.

Info Adding rule set from my-log-rules.yar as 'log' type

Using the keyword c2 for C2 IOCs in a filename should result in a line like the following:

Info Reading iocs from /tmp/thor10/custom-signatures/iocs/my-c2-iocs.txt as 'domains' type

Most Frequent Causes of Frozen Scans

Whenever THOR stops or pauses without any traceback or panic message and no error messages.

Usually the following sources are responsible (descending order, by frequency):

An Antivirus or EDR suspends THOR (>98%)
A "paused" command line window due to Windows Quick Edit Mode (<1%)
A Constant High System Load that causes THOR to stay back and wait for an idling CPU (<1%)
The Perception of a Stalled Scan, which is actually running (<1%)

Antivirus or EDR suspends THOR

In more than 98% of the cases, an Antivirus or EDR is responsible for a stalled process. Especially McAfee AV/EDR is a well-known source of issues. This is caused by the different dialogues in which exceptions have to be defined and the fact certain kinds of blocks cannot be found in any logs.

If a THOR scans stalls in one of these modules, an Antivirus or EDR interaction is highly likely:

Mutex
Events
NamedPipes
ShimCache
ProcessCheck

Solution: Review all possible exclusions in your AV / EDR and add the THOR folder to the exclusion list

Windows Quick Edit Mode

Since Windows 10, the Windows command line window has the so-called "Quick Edit Mode" enabled by default. This mode causes a behavior that can lead to a paused THOR scan process. Whenever a user switches the active windows from the cmd.exe to a different application, e.g. Windows Explorer, and clicks back into the command line window, the running process automatically gets suspended. A user has to press "Enter" to resume the suspended process. As the progress indicator of THOR isn't always changing, this could lead to the impression that the scan paused by itself.

See this StackOverflow post for more details.

Solution: Press "Enter" in the command line window

Constant High System Load

Since THOR automatically sets a low process priority a scan can slow down to a level that appears to be paused or suspended on systems that are under a constant high load.

Solution: You can avoid this behaviour by using the --nolowprio flag. Be aware that scans on a system with a constant high CPU load take longer than on other systems and could slow down the processes that would otherwise take all the CPU capacity.

The Perception of a Stalled Scan

Under certain circumstances the scan may appear stalled but is still running. You can always interrupt a scan using CTRL+C that brings THOR into the interrupt menu in which you can see the currently scanned element. In case of the "FileScan" module, this is a file or folder. In case of the "EventLog" module, this is an event with an ID. If you resume the scan by pressing "C" and interrupt it again a few minutes later, you should see another element in the interrupt menu.

If THOR still processes the same element for several hours, we recommend checking that element (size, format, access rights, location).

Solution: Check progress using the interrupt menu (CTRL+C)

Most Frequent Causes of Failed Scans

The following examples are the most frequent causes of a failed scan.

External Processes Terminating THOR

Whenever THOR dies without any traceback or panic message and no error message in the log file, an external process terminated the THOR process.

Usually the four following sources are responsible (descending order, by frequency):

Antivirus or EDR killed the THOR process
A user killed the THOR process
A management solution that noticed a high CPU load caused by the THOR process killed it
Attackers killed the THOR process

Note

A process termination that always happens at the same element is a sign for an Antivirus or EDR detection.

Insufficient Free Memory

If the system you are trying to scan runs out of free memory, you will encounter the following message in your scan log:

fatal error: out of memory

Probable causes:

Other processes consume a lot of memory
THOR's scanning of certain elements requires a lot of memory
You've set ulimit values that are too restrictive
You are using the wrong THOR version for your architecture
You've activated a feature that consumes a lot of memory (e.g. --mft or --intense)

Whenever THOR recognizes a low amount of free memory, it checks the top three memory consumers on the system and includes them in the log message, before exiting the scan.

You could try running THOR in Soft Mode (--soft), which will deactivate modules and features that require a lot of memory.

Using the 32bit binary of THOR named thor.exe on a 64bit system can lead to interrupted scans with the above error message. The 32bit binary is not able to address as much memory as the 64bit version. Always make sure to use the correct THOR version for the respective architecture.

Several ulimits might cause THOR to terminate if they are too restrictive, including:

locked-in-memory size
address space
number of open file descriptors
maximum data size

If you are certain your machine has sufficient RAM, check your ulimits with ulimit -a and try to rerun the scan with increased limits, if necessary. The man page for the ulimits configuration size gives a full overview over the limits and how to persistently modify them.

Help Us With The Debugging

If you cannot find the source of a problem, please contact us using the support@nextron-systems.com email address.

You can help us find and debug the problem as quickly as possible by providing the following information.

Which THOR version do you use?

Tell us the exact THOR version you are using:

For which operating system (Windows, Linux, macOS, AIX)
For which architecture (32bit, 64bit)

Run thor --version and copy the resulting text into the email.

On Windows:

C:\thor>thor64.exe --version
THOR 10.6.6
Build bea8066 (2021-04-27 14:32:40)
YARA 4.0.5
PE-Sieve 0.2.8.5
OpenSSL 1.1.1j
Signature Database 2021/05/03-150936
Sigma Database 0.19.1-1749-g2f12c5c5

On Linux:

user@desktop:~$ ./thor-linux-64 --version
THOR 10.6.6
Build bea8066 (2021-04-27 14:32:40)
YARA 4.0.5
PE-Sieve 0.2.8.5
OpenSSL 1.1.1j
Signature Database 2021/05/03-150936
Sigma Database 0.19.1-1749-g2f12c5c5

On macOS:

user@macos:~$ ./thor-macosx --version
THOR 10.6.6
Build bea8066 (2021-04-27 14:32:40)
YARA 4.0.5
PE-Sieve 0.2.8.5
OpenSSL 1.1.1j
Signature Database 2021/05/03-150936
Sigma Database 0.19.1-1749-g2f12c5c5

What is the target platform that THOR fails on?

Please provide the output of the following commands.

On Windows:

C:\Users\user>systeminfo > systeminfo.txt

On Linux:

user@desktop:~$ uname -a

On macOS:

user@macos:~$ system_profiler -detailLevel mini > system_profile.txt

Which command line arguments do you use?

Please provide a complete list of command line arguments that you've used when the error occurred.

C:\thor>thor64.exe --quick -e D:\logs -p C:\Windows\System32

Provide the log of a scan with the `--debug` flag

The most important element is a scan log of a scan with the --debug flag used.

The easiest way is to run the scan exactly as you've run it when the problem occurred adding the --debug command line flag.

C:\thor>thor64.exe --quick -e D:\logs -p C:\Windows\System32 --debug

If you're able to pinpoint the error to a certain module, you could limit the scan to that module to get to the problematic element more quickly.

C:\thor>thor64.exe -a Rootkit --debug

After the scan you will find the normal text log (*.txt) in the program folder. It is okay to replace confidential information like the hostname or IP addresses.

Note: The debug log files can be pretty big, so please compress the file before submitting it to us. Normal log files have a size between 1 and 4 MB. Scans started with the --debug flag typically have sizes of 30-200 MB. The compression ratio is typically between 2-4%, so a compressed file shouldn't be larger than 10 MB.

Provide a Screenshot (Optional)

Sometimes errors lead to panics of the executables, which causes the situation in which relevant log lines don't appear in the log file. In these cases, please also create a screenshot of a panic shown in the command line window.

Provide the THOR database (Optional)

The THOR DB helps us debug situations in which the THOR scan timed out or didn't complete at all. It contains statistics on the run time of all used modules and the durations of all folders up to the second folder level from the root of a partition. (e.g. C:\Windows\SysWow64).

The default location of that file is:

Windows: C:\ProgramData\thor\thor10.db
Linux/macOS: /var/lib/thor/thor10.db

Please provide that file in situations in which:

THOR exceeded its maximum run time
THOR froze and didn't complete a scan for days
THOR scans take too long for the selected scan targets

Further Notes

If the files are too big to send, even after compression, please contact us and you'll receive a file upload link that you can use
If a certain file or element (eventlog, registry hive) caused the issue, please check if you can provide that file or element for our analysis, as those files can contain sensitive information.

Analysis and Info

Log Analysis Manual

You can find our Log Analysis Manual online:

https://log-analysis-manual.nextron-systems.com

This will help to process the events generated by THOR.

VALHALLA Rule Lookup

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 List Output

By using the --print-signatures flag, you can get a list of all initialized YARA and Sigma rules.

This information can also be printed machine readable as JSON by using the --print-signatures-json flag.

Use Cases

This chapter contains use cases that users often asked for.

Disk Image Analysis

Hint

A lot of functions in this chapter require a forensic lab or lab license. This license is geared towards forensic experts. Forensic Lab Licenses are a special license type with more functionality.

THOR, as a scanner, does not mount disk images to a certain drive on your forensic workstation. You have to use 3rd party tools for that task. Please see Arsenal Image Mounter (AIM) and FTKImager for Windows or Dissect for Linux to get an overview of potential tools to use. Other tools should also work.

First, you mount the image to a certain drive/path with your preferred tool. Afterwards you can use THOR in the lab scanning mode to analyze the mounted image.

The following example shows a recommended set of parameters, scanning a mounted image of a host named WKS0001 on drive S:\ of your forensic Windows workstation.

C:\thor>thor64.exe --lab --virtual-map S:C -j WKS0001 -p S:\

The following example shows the same parameters for a Linux forensic workstation. The drive is mounted to /mnt/image/fs/sysvol/.

nextron@unix:~/thor$ ./thor-linux-64 --lab --virtual-map /mnt/image/fs/sysvol/:C -j WKS0001 -p /mnt/image/fs/sysvol/

The --lab parameter will apply several internal flags (e.g. enables intense mode to scan every file, enables multi-threading, disables resource control, removes all limitations). The --virtual-map parameter maps every file found in elements of that image to the original drive letter and allows the message enrichment to work correctly. The -j HOSTNAME parameter can be used to write every log line with the hostname of the original system and not with that of the forensic workstation.

You find more information on the scan parameters in the chapter Lab Scanning.

Hint

This blog post mentions different ways to use commercial or built-in tools to mount and scan VMDK images.

Arsenal Image Mounter (AIM)

We recommend using Arsenal Image Mounter.

In case you plan to use an automated setup in which you use scripts to automatically process images, you could try to use the command-line of AIM, please see the aim_cli.exe within the program folder for more help.

FTKImager

Alternatively, you can use the tool FTKImager to mount your image.

Note

We recommend using Arsenal Image Mounter to mount your images, since we observed better performance during our internal tests.

Dissect

Dissect is an incident response framework build from various parsers and implementations of file formats. Tying this all together, Dissect allows you to work with tools named target-query and target-shell to quickly gain access to forensic artefacts, such as Runkeys, Prefetch files, and Windows Event Logs, just to name a few!

You can find the tool here: https://github.com/fox-it/dissect

For instructions on how to mount a disk image, you can find information here: https://docs.dissect.tools/en/latest/tools/target-mount.html

Memory Image Analysis with Volatility

In this use case, we show a way to run a THOR scan on a full memory image of a target system.

In volatility, we first evaluate the right profile for a memory image. You can use the imageinfo command or select one manually from the list that is show when you run vol.py --info.

user@linux:~$ vol.py -f win10-lab1.mem imageinfo

Volatility Foundation Volatility Framework 2.6.1
INFO     : volatility.debug    : Determining profile based on KDBG search...
          Suggested Profile(s) : Win10x64_19041
                     AS Layer1 : SkipDuplicatesAMD64PagedMemory (Kernel AS)
                     AS Layer2 : FileAddressSpace (/mnt/downloads/mem-dumps/win10-lab1.mem)
                      PAE type : No PAE
                           DTB : 0x1aa002L
                          KDBG : 0xf8005aa00b20L
          Number of Processors : 2
     Image Type (Service Pack) : 0
                KPCR for CPU 0 : 0xfffff80055ec0000L
                KPCR for CPU 1 : 0xffff8500313c0000L
             KUSER_SHARED_DATA : 0xfffff78000000000L
           Image date and time : 2021-06-15 08:25:08 UTC+0000
     Image local date and time : 2021-06-15 10:25:08 +0200

We then create a directory that will store all our process memory images.

user@linux:~$ mkdir procs

Now we can extract all process memory images and save them to the new directory.

user@linux:~$ vol.py -f win10-lab1.mem --profile=Win10x64_19041 memdump -D procs/

Volatility Foundation Volatility Framework 2.6.1
************************************************************************
Writing System [     4] to 4.dmp
************************************************************************
Writing Registry [    92] to 92.dmp
************************************************************************
Writing smss.exe [   348] to 348.dmp
************************************************************************
Writing csrss.exe [   440] to 440.dmp
************************************************************************
Writing wininit.exe [   512] to 512.dmp
************************************************************************
Writing csrss.exe [   520] to 520.dmp
************************************************************************
Writing winlogon.exe [   608] to 608.dmp
************************************************************************
Writing services.exe [   624] to 624.dmp
************************************************************************
Writing lsass.exe [   656] to 656.dmp
************************************************************************
Writing fontdrvhost.ex [   748] to 748.dmp

We recommend saving that output for mapping purposes, since THOR will only report the file names upon a YARA rule match, e.g. 748.dmp, and not the name of the executable fontdrvhost.exe.

Using THOR, we can now scan the extracted process memory images.

user@linux:~$ ./thor-linux-64 --lab -p /mnt/mem-dumps/procs/

Without a valid lab license, we can simulate that behaviour using the following command (see Lab Scanning for more details and flags used in lab scan mode):

user@linux:~$ ./thor-linux-64 -a Filescan --intense -p /mnt/mem-dumps/procs/

The output of such a scan will look like this

[?%] Worker 01: /mnt/mem-dumps/procs/3812.dmp          [_______________________________]Progress: 286 MB
[?%] Worker 01: /mnt/mem-dumps/procs/3812.dmp          [_______________________________]Progress: 343 MB
Alert YARA Score Rule Match
  TARGET: /mnt/mem-dumps/procs/3812.dmp
  TYPE: file
  NAME: SUSP_Encoded_UA_Mozilla
  SCORE: 50
  DESCRIPTION: Detects encoded keyword - User-Agent: Mozilla/
  SIGTYPE: internal
  CHUNK_OFFSET: 366000000
  TAGS: SUSP, T1027
  MATCHING_STRINGS: Str1: "VzZXItQWdlbnQ6IE1vemlsbGEv" in "dDBRMD0NClVzZXItQWdlbnQ6IE1vemlsbGEvNS4wIChjb2" at 0x1672eacc
  MODIFIED: Tue Jun 15 11:38:13 2021
  CHANGED: Tue Jun 15 11:38:13 2021
  TARGET_SIZE: 610324480
[?%] Worker 01: /mnt/mem-dumps/procs/3812.dmp          [_______________________________]Progress: 400 MB
[?%] Worker 01: /mnt/mem-dumps/procs/3812.dmp          [_______________________________]Progress: 457 MB

The match includes an offset, e.g. CHUNK_OFFSET: 366000000, and a matching string, e.g. Str1: "VzZXItQWdlbnQ6IE1vemlsbGEv" which help you to locate the correct section in the dump file using a hex editor for further analysis.

Scanning a Fileserver

The recommendation for scanning a fileserver is running THOR directly on the system. If that is not possible, because the operating system of the fileserver is not supported by THOR, we recommend a dedicated system to perform a filescan on the shares. The system should have at least 2 CPU cores and 2 GB of RAM.

The recommended flags to run THOR are:

C:\temp\thor>thor64.exe --module Filescan --alldrives --path X: --path Y: --path Z:

Note

The --alldrives flag is only available with a lab license

If needed or desired, the scan can be adapted using the following flags. In general, the following options are not recommended but can help in special scenarios.

--resume
- If a previous scan failed (e.g. because of a exceeded max. runtime) the scan can be resumed, if the same flags (and additional the resume flag) are used to start the scan.
--max-runtime 0
- Default is 7 days. Change this value if your scans need more time.
--path \\fileserver01\shareA
- If permissions allow anonymous access, the shares can be accessed using the UNC path and do not need to be mounted.
--nosoft
- If your scanning system has too little system resources, the softmode is automatically enabled. This flag prevents that.
--all-module--lookback --lookback 8
- Only scans files that were modified within the last 8 days. Faster scan time but vulnerable to timestomping attacks.
--diff
- Only scans new files or files that were modified since the last scan. Faster scan time but vulnerable to timestomping attacks. THOR DB is needed for diff, so cannot be used in combination with --nothordb.
--max_file_size ?????
- Maximum file size In bytes. The default is 20 MB. If you need to scan bigger files, you might need to increase the maximum file size.
--no<feature>
- Disable features like scanning eventlog files (--noevtx), if your share contains files that trigger special feature checks of THOR, that are not desired. Please see Scan Module Names and Feature names for a list of module/feature names and the respective command line argument to disable them.
--allfiles
- Scan all files, independent of file extensions or magic headers. Use --max_file_size_intense instead of --max_file_size. (Caution: This will increase the scan time drastically!)

If the share is not accessible anonymously, you need to mount the shares using valid user credentials. This has to be done before the scan and access granted to the user running the THOR scan. If you use ASGARD to launch THOR the user performing the scan is NT AUTHORITY\SYSTEM.

The usage of diff and lookback are generally not recommended, but can be used if your fileshare scan does not finish in the timeframe you desire. Another option is to use multiple dedicated systems to run scans on the fileserver shares in parallel.

Known Issues

THOR#003: No rules with DEEPSCAN tag found

Introduced Version	Fixed Version
N/A	N/A

This error is caused by a missing signature set. Usually the user just copied the THOR executable and forgot to copy the whole program folder including the ./signatures folder. The error message means that none of THOR's own signatures could be found. These signatures also include the so-called DEEPSCAN signatures. THOR reports that not a single one of these signatures could be found, which results in very limited scan capabilities.

You can see that this is the case by inspecting your scan results:

THOR: Warning: MODULE: Init MESSAGE: No rules with DEEPSCAN tag found.
    THOR won't scan any files with YARA rules. Please ensure that you use
    up-to-date signatures. SCANID: S-Qpw5dDmEBaw
THOR: Info: MODULE: Init MESSAGE: Successfully compiled 0 custom default
    YARA rules SCANID: S-Qpw5dDmEBaw TYPE: YARA

You can also see during the initialization process of THOR, that no YARA rules are compiled:

C:\nextron\thor>thor64.exe
[...]

> Reading YARA signatures and IOC files ...
Info Successfully compiled 0 default YARA rules TYPE: YARA
Info Successfully compiled 0 log YARA rules TYPE: YARA
Info Successfully compiled 0 registry YARA rules TYPE: YARA
Info Successfully compiled 0 keyword YARA rules TYPE: YARA
Info Successfully compiled 0 process YARA rules TYPE: YARA
Info Successfully compiled 0 meta YARA rules TYPE: YARA
Warning No rules with DEEPSCAN tag found. THOR won't scan any files with YARA rules.
    Please ensure that you use up-to-date signatures.
Info Successfully compiled 0 custom default YARA rules TYPE: YARA
Info Skip sigma initialization, use '--sigma' flag to scan with sigma
Info Successfully compiled 0 STIXv2 indicators (skipped 0 indicators) TYPE: STIX
Info Successfully compiled 0 keyword ioc strings TYPE: IOC
Info Successfully compiled 0 filename ioc strings and 0 filename ioc regexs TYPE: IOC
Info Successfully compiled 0 malware and 0 false positive hashes TYPE: IOC
Info Successfully compiled 0 file type signatures TYPE: IOC
Info Successfully compiled 0 malware domains TYPE: IOC
Info Successfully compiled 0 malicious handles and 0 regex malicious handles TYPE: IOC
Info Successfully compiled 0 named pipe ioc strings and 0 named pipe ioc regexs TYPE: IOC
Warning No file type signatures compiled, file type detection can't be done.
    Because of this, many files won't be scanned.

[...]

THOR#003: Solution

Make sure that you have the ./signatures folder in your THOR program folder and that it contains at least the following files:

./signatures/yara/thor-all.yas
./signatures/yara/thor-deepscan-selectors.yasx
./signatures/yara/thor-expensive.yase
./signatures/yara/thor-keywords.yas
./signatures/yara/thor-log-sigs.yas
./signatures/yara/thor-meta.yas
./signatures/yara/thor-process-memory-sigs.yas
./signatures/yara/thor-registry.yas

THOR#002: THOR in Lab-Mode does not scan network or external drives

Introduced Version	Fixed Version
N/A	>=10.6.16 >=10.7.3

If running a command like thor64.exe --lab -p Z:\myshare THOR will not currently scan the path. Normally the --alldrives flag should be implicitly activated in Lab-mode.

Note

The --alldrives flag is only available with a lab license

THOR#002: Workaround

You have to add the --alldrives flag on your own. E.g.

C:\thor>thor64.exe --lab -p Z:\myshare --alldrives

THOR#001: Could not parse sigma logsources

Introduced Version	Fixed Version
N/A	N/A

Error could not parse sigma log sources
FILE: config\sigma.yml ERROR: no logsources element found

The issue occurs only for very old THOR installations that at one time had the template file config\tmpl-sigma.yml named config\sigma.yml.

THOR#001: Workaround

The error can be ignored and the THOR scan will run as expected. To prevent the error message from showing, remove config\sigma.yml or use a newly downloaded THOR package.

Links and References

THOR Website: https://www.nextron-systems.com/thor/

Nextron Customer Portal: https://portal.nextron-systems.com

Nextron Software Update Status: https://update1.nextron-systems.com/info.php

YARA Documentation: https://yara.readthedocs.io/

yarGen - YARA Rule Generator: https://github.com/Neo23x0/yarGen/

THOR APT Scanner App and Add-on v2: https://splunkbase.splunk.com/app/3717/ and https://splunkbase.splunk.com/app/3718/

Sigma Project: https://github.com/Neo23x0/sigma

Open Source License Acknowledgements

List of third-party software components used by THOR 10 with open source licensing requirements.

golang.org

Copyright (c) 2009 The Go Authors
Licensed under BSD-3 License

OpenSSL

Copyright (c) OpenSSL

Licensed under OpenSSL license (https://www.openssl.org/source/license.html)

YARA

Licensed under BSD-3 License

github.com/Azure/go-ntlmssp

Licensed under MIT License

github.com/botherder/go-autoruns

modified as github.com/Codehardt/go-autoruns
Copyright (c) 2018 Claudio Guarnieri
Licensed under MIT License

github.com/omarghader/pefile-go

modified as github.com/Codehardt/go-pefile
Copyright (c) 2004-2015 Ero Carrera
Licensed under MIT License

github.com/Codehardt/go-cpulimit
github.com/Codehardt/go-handle
github.com/Codehardt/go-ntlm-proxy-auth
github.com/Codehardt/go-osversion
github.com/Codehardt/go-priority
github.com/Codehardt/go-taskscheduler
Licensed under MIT License

github.com/Codehardt/go-win64api
github.com/iamacarpet/go-win64api
Licensed under MIT License

github.com/Codehardt/mmap-go
github.com/ncw/mmap-go
Licensed under BSD-3 License

github.com/StackExchange/wmi

Licensed under MIT License

github.com/Velocidex/ordereddict
github.com/Velocidex/regparser
github.com/secDre4mer/regparser
www.velocidex.com/golang/go-ntfs
www.velocidex.com/golang/evtx
github.com/Velocidex/evtx
Licensed under Apache License 2.0

github.com/andrewkroh/sys

github.com/botherder/go-files

Licensed under MIT License

github.com/coreos/go-systemd/v22

(no copyright notes found)

Licensed under Apache License 2.0

github.com/dsnet/compress

Licensed under BSD-3 License

github.com/dustin/go-humanize

Licensed under MIT License

github.com/elastic/beats
github.com/elastic/go-ucfg
github.com/elastic/go-sysinfo
Licensed under Apache License 2.0

github.com/fatih/color

Licensed under MIT License

github.com/fsnotify/fsnotify

Copyright (c) 2012 The Go Authors
Copyright (c) 2012 fsnotify Authors
Licensed under BSD-3 License

github.com/gizak/termui/v3
github.com/gizak/termui/v3/widgets
github.com/gizak/termui/v3/drawille
Licensed under MIT License

github.com/go-ole/go-ole

Licensed under MIT License

github.com/godbus/dbus

Licensed under BSD-2 License

github.com/gofrs/uuid

Licensed under MIT License

github.com/google/pprof

(no copyright notes found)

Licensed under Apache License 2.0

github.com/golang/snappy

Licensed under BSD-3 License

github.com/gonutz/w32
github.com/shirou/w32
github.com/AllenDang/w32
Licensed under MIT License

Licensed under Mozilla Public License 2.0

github.com/hashicorp/go-multierror
github.com/hashicorp/golang-lru
github.com/hashicorp/errwrap
(no copyright notes found)

github.com/hillu/go-yara/v4

Licensed under BSD-2 License

github.com/inconshreveable/mousetrap

Licensed under Apache License 2.0

github.com/joeshaw/multierror

Licensed under MIT License

github.com/kardianos/service

Licensed under zlib License

github.com/marcsauter/single

Licensed under MIT License

Copyright (c) Yasuhiro MATSUMOTO <mattn.jp@gmail.com>

github.com/mattn/go-colorable
github.com/mattn/go-isatty
github.com/mattn/go-runewidth
github.com/mattn/go-shellwords
github.com/mattn/go-sqlite3
Licensed under MIT License

github.com/mitchellh/go-wordwrap

Licensed under MIT License

github.com/mholt/archiver

Licensed under MIT License

github.com/nsf/termbox-go

Licensed under MIT License

github.com/nwaples/rardecode

Licensed under BSD-2 License

github.com/pierrec/lz4

Licensed under BSD-3 License

Copyright (c) Dave Cheney <dave@cheney.net>

github.com/pkg/errors
github.com/pkg/profile
Licensed under BSD-2 License

github.com/pytimer/win-netstat

Licensed under MIT License

github.com/sebdah/goldie

Licensed under MIT License

github.com/shirou/gopsutil

Copyright (c) 2014 WAKAYAMA Shirou
Copyright (c) 2009 The Go Authors
Licensed under BSD License

github.com/smartystreets/goconvey
github.com/smartystreets/assertions
Licensed under MIT License

github.com/spf13/cobra

(no copyright notes found)

Licensed under Apache License 2.0

github.com/spf13/pflag

Copyright (c) 2012 Alex Ogier
Copyright (c) 2012 The Go Authors
Licensed under BSD-3 License

github.com/stretchr/testify

Licensed under MIT License

github.com/xi2/xz

(no license and copyright notes found)

go.uber.org/atomic
go.uber.org/multierr
Licensed under MIT License

go.uber.org/zap

Licensed under MIT License

golang.org/x/arch
golang.org/x/crypto
golang.org/x/sys
golang.org/x/exp
golang.org/x/net
golang.org/x/oauth2
golang.org/x/term
golang.org/x/time
golang.org/x/tools
golang.org/x/sync
Licensed under BSD-3 License

gopkg.in/ini.v1

Licensed under Apache License 2.0

gopkg.in/natefinch/npipe.v2

Licensed under MIT License

gopkg.in/yaml.v2
gopkg.in/yaml.v3
Licensed under Apache License 2.0

howett.net/plist

Copyright (c) 2013, Dustin L. Howett
Copyright (c) 2012 The Go Authors
Licensed under BSD-3 License

github.com/williballenthin/shellbags

(no copyright notes found)

Licensed under Apache License 2.0

go.opencensus.io

(no copyright notes found)

Licensed under Apache License 2.0

cloud.google.com/go

(no copyright notes found)

Licensed under Apache License 2.0

github.com/chzyer/logex
github.com/chzyer/readline
github.com/chzyer/test
Licensed under MIT License

github.com/ianlancetaylor/demangle

Licensed under BSD-3 License

github.com/jstemmer/go-junit-report

Licensed under MIT License

Google Go modules

google.golang.org/api
google.golang.org/appengine
google.golang.org/genproto
google.golang.org/grpc
(no copyright notes found)
Licensed under Apache License 2.0

google.golang.org/protobuf
github.com/golang/protobuf
Licensed under BSD-3 License

github.com/golang/groupcache

(no copyright notes found)

Licensed under Apache License 2.0

github.com/google/go-cmp

Licensed under BSD-3 License

github.com/frankban/quicktest

Licensed under MIT License

github.com/niemeyer/pretty

Licensed under MIT License

github.com/prometheus/procfs

(no copyright notes found)

Licensed under Apache License 2.0

Beats

https://github.com/secDre4mer/beats
https://github.com/elastic/beats
Licensed by Elasticsearch B.V.
Licensed under Apache License 2.0

https://github.com/ulikunitz/xz 

Licensed under BSD 2-Clause "Simplified" License

go.elastic.co/ecszap

Licensed under Apache License 2.0

gopkg.in/check.v1

Licensed under BSD 2-Clause "Simplified" License

github.com/gopherjs/gopherjs

Licensed under BSD 2-Clause "Simplified" License

github.com/kr/text

Licensed under MIT License

github.com/gobuffalo/envy
github.com/gobuffalo/packr
github.com/gobuffalo/packr/v2
Licensed under MIT License

github.com/karrick/godirwalk

Licensed under BSD 2-Clause License

github.com/rogpeppe/go-internal

Licensed under BSD 3-Clause "New" License

github.com/sirupsen/logrus

Licensed under MIT License

github.com/Workiva/go-datastructures

(no copyright notes found)

Licensed under Apache License 2.0

github.com/swagger-api/swagger-ui

Licensed under Apache License 2.0

github.com/cheggaaa/pb/v3

Licensed under BSD 3-Clause "New" License

github.com/magefile/mage

Licensed under Apache License 2.0

github.com/secDre4mer/go-parseflags

(no copyright notes found)

Licensed under BSD 3-Clause "New" License

github.com/secDre4mer/go-inject

Licensed under MIT License

Changelog

In this chapter you can find all the changes of THOR. Current version naming can be found in the index below.

THOR 10.7 (Techpreview)

THOR Version 10.7.14

Type	Description
Feature	New `--max-reasons` flag to limit the shown number of reasons per message. This flag replaces `--allreasons`, which will still work, but is now deprecated.
Bugfix	Fix an issue where the 32-bit version of THOR for Linux crashed when loading the signatures
Bugfix	Fix an issue where large /etc/hosts files could cause extremely long scan times
Bugfix	Fix an issue where entries in /etc/hosts that mapped multiple hostnames to the same IP address could cause hard-to-read log entries

THOR Version 10.7.13

Type	Description
Feature	New `--max-hits` flag to limit the number of hits per IOC or YARA rule
Feature	`--eventlog-target` now supports '*' as a target
Change	Memory dump files are now scanned with process memory YARA rules rather than the default YARA rules
Change	Update to Golang v1.20.13
Bugfix	`--lab --collector` now activates the artifact collector, as intended
Bugfix	Fix an issue where THOR could crash during initialization
Bugfix	Dataless files on MacOS are now ignored
Bugfix	Fix an issue where some network drives on Linux were scanned even if `--alldrives` was not activated
Bugfix	Fix an issue where THOR for Linux could crash in the 'Crontab' module
Bugfix	Fix an issue where some eventlogs could cause a crash in the 'Eventlog' module
Bugfix	Fix an issue where, if an error occurred when reading a file, incorrect file hashes were displayed

THOR Version 10.7.12

Type	Description
Bugfix	Fix an issue where a high number of mutexes could cause a crash in THOR

THOR Version 10.7.11

Type	Description
Bugfix	Fix an issue where THOR could hang when scanning specific processes on Linux

THOR Version 10.7.10

Type	Description
Feature	New `--nommap` flag to disable memory mapping in features
Change	Remove action feature due to potential abusability
Change	Update to Golang v1.20.10
Change	SFX RAR executables are now extracted using the Archive feature instead of the ExeDecompress feature, which allows access to the filenames within the archive
Bugfix	Fix an issue where too many open handles on a system could cause a crash
Bugfix	Fix an issue where a scan exit due to the Rescontrol could cause a deadlock
Bugfix	Ensure that data is truncated, even if match strings are unusually large
Bugfix	Fix an issue where the EtwWatcher could crash when finishing

THOR 10.7.9

Type	Description
Change	CPU limit now applies only to full system CPU usage, not only THOR (reverts a change made in 10.7.4)
Change	If THOR is cancelled by the Rescontrol feature, the information is now displayed as an Error instead of a Warning
Change	Standardized logging of matches on processes
Change	Update to Golang v1.20.6
Change	Update to YARA v4.3.2
Bugfix	Fixed an issue where simultaneous write access from another process to a file that THOR scanned could cause the THOR scan to fail
Bugfix	Fixed an issue where old Windows systems could incorrectly be displayed as unpatched
Bugfix	Fixed an issue where 'thor-util update' could remove the file type signatures

THOR 10.7.8

Type	Description
Feature	(via THOR Util) log conversion to CSV is now possible
Feature	New Artifact Collector module, which allows collection of forensic artifacts from the current system into a ZIP file
Feature	New `--print-signatures-json` flag for JSON output of current signatures
Feature	New `--init-selector` and `--init-filter` flags which allow the user to load only a subset of the normal signatures
Change	When using `--encrypt`, log files are now encrypted as they are written during the THOR scan. This prevents temporary log files, but also makes generation of HTML reports afterwards impossible. Use THOR Util instead to generate HTML reports after decrypting the logs.
Change	Display matches on reverse lookup IP addresses in a better way
Change	Update to Golang v1.20.5
Change	Update to OpenSSL 3.0.9
Bugfix	Display error messages correctly in JSON logs
Bugfix	On Linux, don't skip directories with children where lstat() fails

THOR 10.7.7

Type	Description
Change	THOR Lite licenses with Sigma now also have the Eventlog and EVTX modules enabled

THOR 10.7.6

Type	Description
Feature	Add `--minimum-sigma-level` to specify which Sigma rules should trigger a finding. This defaults to high and is reduced to medium in intense mode, which is the current behaviour.
Feature	Add `--audit-trail` for detailed log output of THOR scan trails. This feature is experimental so far, and the output and output format may yet change.
Feature	Add `--background` to adjust THOR log level colors to specific backgrounds. Currently, optimizeds for dark and light backgrounds are available.
Feature	Add `--jsonv2` which changes the JSON output to better reflect the structure of the log entry, with substructures now properly representing parts of the log entry. This also affects Thunderstorm responses when set.
Change	Increased default value for `--yara-stack-size` to 32768
Change	Standardized logging of filename IOC related reasons
Change	Update to Golang v1.20.2
Bugfix	Fix an issue where THOR scans failed due to a perceived symlink loop in the scan path

THOR 10.7.5

Type	Description
Feature	Add new ETL feature for parsing ETL files
Feature	Add `--vtkey`, `--vtmode`, and `--vtaccepteula` flag for integration of VirusTotal in THOR
Feature	Improve progress reports when scanning complex files
Feature	Support Sigma scans with THOR Lite for specific licenses
Change	Unify logging fields for many filename IOC, keyword IOC and YARA matches
Change	Unify logging fields for many messages in the NetworkShares module
Change	Update to Golang v1.19.5
Change	Upgrade PE-Sieve to v0.3.5
Change	`--print-signatures` now silences the normal initialization output
Change	Use mimalloc for YARA allocations on Linux and MacOS
Change	Scanning network paths now requires a Lab license
Bugfix	Reduce log level for corrupt /etc/passwd entries from Notice to Info
Bugfix	Identify packed samples correctly with --customonly set

THOR 10.7.4

Type	Description
Feature	New OLE feature for extraction of Office macros
Feature	ExeDecompress feature is now also supported on Linux
Feature	Added `--lowioprio` flag for lowered IO priority
Change	Update to Golang v1.19.2
Change	CPU limit now applies only to THOR's CPU usage, not the the complete system
Change	Windows Access Groups (e.g. in file permissions) are now always displayed in English
Change	Modified the scoring formula to further reduce the impact of multiple subscores on the full score. As compensation, the default threshold for alerts has been reduced.
Bugfix	.lnk file processing with `--virtual-map` no longer causes link targets to be scanned without applying the virtual mapping
Bugfix	Access faults while reading memory mapped files no longer cause THOR to crash
Bugfix	Panics on opening an archive are now handled properly

THOR 10.7.3

Type	Description
Feature	Meta rule matches with 'FORCE' tag will now cause THOR to ignore the maximum file size for that file
Feature	Improved matching behaviour of YARA rules on bulks. Scans on bulks (but not scans on single bulk elements) will now use a different YARA ruleset where common false positive constructs (e.g. filesize) are removed.
Feature	Improved performance in cases where a rule or IOC matched on a bulk
Feature	Improved memory usage and performance of HTML report generation
Feature	THOR now issues a Notice or Warning for Office connection cache entries
Feature	THOR now scans archives (e.g. ZIP files) recursively. This changes how matches in subfiles of archives are reported.
Feature	Added '.cab' support in the 'Archive' feature
Feature	Added '.gz' support in the 'Archive' feature
Feature	Added '.7z' support in the 'Archive' feature
Feature	Added new 'EML' feature for scanning .eml files
Change	Increase amount of bytes scanned by meta rules to 2048
Change	THOR now prefers reading files via memory maps over using the file read API
Bugfix	Improved performance of Sigma rule loading
Bugfix	Fixed a bug where THOR scanned some files multiple times, possibly resulting in a loop

THOR 10.7.2

Type	Description
Feature	Process memory checks are now enabled on Linux and MacOS
Feature	Added a check on Linux for deleted executables
Feature	UTF-16 Log files are now parsed correctly
Change	Upgrade YARA to v4.2.1

THOR 10.7.1

Type	Description
Feature	Sigma rules are now applied to running processes on the system
Feature	New command line option '-follow-symlinks' that causes the FileScan module to follow symlinks.
Feature	Checking e.g. log lines from a file with YARA will now set the THOR external variables like 'filepath' appropriately
Feature	THOR now shows modules names where string matches were found if a YARA rule matches on process memory
Feature	THOR now shows a warning if low rlimits are detected
Change	THOR will now scan processes even in soft mode, with a maximum process size of 250MB.
Change	`--max_file_size_intense` is now deprecated. Instead, `--max_file_size` should be used.
Change	`--virtual-map` now supports mounts in subpaths on Windows, e.g. as `--virtual-map G:\mount:C`
Change	Upgrade PE-Sieve to v0.3.3
Change	Filescan progress report for folders without subfolders was improved

THOR 10.7.0

Type	Description
Feature	Mark files with names close to common Windows executables as suspicious
Feature	Change how score is added to avoid cases where scores added up to absurd values
Feature	Support scanning alternate data streams with `--ads`
Feature	Check environment variables of processes
Change	THOR now terminates if a positional argument was specified since none are expected
Fix	Scan files written to the Dropzone only once the write is complete (or does not continue for at least 1 second)

THOR 10.6 (Stable)

THOR Version 10.6.24

Type	Description
Bugfix	Fix an issue where `--lowprio` and `--verylowprio` were not working correctly on Linux

THOR Version 10.6.23

Type	Description
Bugfix	Fix an issue where unicode characters in file names could cause panics
Bugfix	Fix an issue where corrupt archive files could cause panics
Bugfix	Fix an issue where the 32-bit version of THOR for Linux crashed when loading the signatures
Bugfix	Fix an issue where the NetworkShares module incorrectly reported an error

THOR 10.6.22

Type	Description
Change	SFX RAR executables are now extracted using the Archive feature instead of the ExeDecompress feature, which allows access to the filenames within the archive
Change	Remove action feature due to potential abusability.
Change	Update to Golang v1.20.8
Change	Update to OpenSSL v1.1.1w
Change	Update to YARA v4.3.2
Bugfix	Fix an issue where registry values with new lines could lead to messages missing information about the registry key

THOR 10.6.21

Type	Description
Feature	Add SIGTYPE fields to Sigma matches
Feature	Add TYPE fields to reasons
Change	Update to Golang v1.19.9
Change	Terminate early when an invalid flag is used in the THOR template file
Change	Report YARA matches in the DeepDive feature with reasons
Change	Increase default YARA stack size to 32768
Bugfix	Don't report filename matches on nonexisting files when resolving the file name from a reference using environment variables

THOR 10.6.20

Type	Description
Feature	Add a warning when running on MacOS without full disk access
Change	Update to Golang v1.19.5
Bugfix	Improve trace output for decompressing EXE files
Bugfix	Exclude MacOS directories used to for cloud storage unless '--alldrives' is specified
Bugfix	Set rule date in '--print-signatures' output to modified date, if available
Bugfix	Check if file is located remotely before trying to read file stats

THOR 10.6.19

Type	Description
Change	Update to Golang v1.19.2
Bugfix	Fixed an issue where scans were not properly resumed
Bugfix	Fixed an issue that caused ASGARD to download THOR even if it was cached locally

THOR 10.6.18

Type	Description
Change	Removed some exclusions where archives were not scanned

THOR 10.6.17

Type	Description
Change	Errors now appear as the first section in HTML reports
Change	Update to YARA v4.2.3
Change	Update to Golang v1.18.5

THOR 10.6.16

Type	Description
Feature	Show Office Connection Cache entries
Change	Show informational message when downloading a license from Portal or ASGARD
Change	Update to Golang v1.18.3
Change	Update to YARA v4.2.1
Change	Improved HTML report generation performance and HTML report UI
Change	Registry YARA rules are now loaded on other platforms than Windows as well (for image scans)
Bugfix	Added MATCHED_STRINGS field to filename IOC matches to improve visibility for complex IOCs
Bugfix	Fixed an issue where Sigma rules could use a large amount of memory during initialization
Bugfix	Fixed an issue where Linux services were incorrectly reported as group writable
Bugfix	Corrected the signature type (custom or internal) for C2 IOC matches on memory

THOR 10.6.15

Type	Description
Feature	Added a new 'diagnostics' command for THOR Util that collects information about a hanging or terminated THOR process
Feature	Custom process exclude regexps can now be specified in 'config/process-excludes.cfg'
Bugfix	Log messages about suspicious services are now correctly logged as belonging to the 'ServiceCheck' module
Bugfix	Process excludes are now handled more stringently, and accesses on excluded processes are less intrusive
Bugfix	Scan end time no longer sometimes misses from the HTML report
Change	Matches from deprecated sigma rules are no longer shown
Change	Upgrade of the sigma matching engine from v1 to v2
Change	Update to Golang v1.17.9
Change	Update to PE-Sieve v0.3.3
Change	Default maximum file size increased to 30 MB (200 MB for intense mode)

THOR 10.6.14

Type	Description
Bugfix	The Bifrost 2 server option is again available in ASGARD

THOR 10.6.13

Type	Description
Bugfix	Some YARA rules were not applied correctly on unpacked files
Bugfix	Catch panics that could occur when unpacking certain RAR files
Bugfix	THOR no longer attempts to access files that are not local (e.g. OneDrive files) when they are referenced from elsewhere unless '--alldrives' is used

THOR 10.6.12

Type	Description
Feature	Executing 32 bit THOR on a 64 bit Windows system now causes a warning
Feature	Hash IOCs may now have an optional score (default is 100, as before)
Change	Disable RarVM support
Change	Change colors for some log levels to improve readability in specific terminals
Change	THOR Util can no longer download licenses from ASGARD, use THOR instead
Change	THOR now terminates if the internal signatures can't be loaded
Change	Intrusive process actions that require process memory access are now skipped on excluded processes
Change	THOR Lite Util no longer supports '--force' for upgrades and updates
Change	Update to Golang v1.16.13
Bugfix	Process dumps are now created with secure access rights

THOR 10.6.11

Type	Description
Feature	Support Apple M1
Feature	Save resume state on system shutdown or logoff
Change	Upgrade PE-Sieve to v0.3.1
Change	Upgrade OpenSSL to v1.1.1l

THOR 10.6.10

Type	Description
Change	Update to Golang v1.16.7
Bugfix	Show process details for PPL processes correctly

THOR 10.6.9

Type	Description
Feature	Print rule authors for YARA rule matches
Feature	Check environment variables for other processes
Feature	Use Administrator rights on Windows, if available
Change	Upgrade PE-Sieve to v0.3.0
Fix	Handle UTF-16 output in string matches better
Fix	Improve progress estimation for Eventlog module
Fix	Skip non-local files on Windows (from e.g. OneDrive) unless '--alldrives' is set

THOR 10.6.8

Type	Description
Feature	Analyze ETW logs in the background for CobaltStrike beacon characteristics. This can be disabled with '--noetwwatcher'.
Feature	Check IP forwarding on Linux as part of the Firewall module.
Feature	Analyze authorized_keys files that are found. This feature can be disabled with '--noauthorizedkeys'.
Feature	Support metadata YARA rules which are applied to all files, but can only access the first 100 bytes of the file. These files must contain the "meta" word in their filename. If a Metadata YARA rule with the DEEPSCAN tag matches, a full YARA scan on the file will be triggered.
Feature	Add the "group" external variable to YARA rules for non-Windows scans.
Change	Upgrade YARA to v4.1.1
Change	Print more timestamps for deep dive targets
Change	Disable global YARA rules since they could impact THOR's internal rules
Fix	Handle a bug where THOR froze when calculating the hash of a file opened via the MFT

THOR 10.6.7

Type	Description
Bugfix	Apply cross platform IOCs correctly if '--lab' is set
Bugfix	Don't scan specific files twice if '--lab' is set

THOR 10.6.6

Type	Description
Upstream	Merge current changes from THOR 10.5.16
Feature	Scanning for symlinks and irregular files with Filename IOCs
Feature	YARA Meta rules (filename needs to contain the word meta) which are applied on all files, but which only can access the first 100 Bytes of the file
Feature	Improve Scheduled Task parsing and give a notice if a task's binary does not exist
Feature	Parse Cobalt Strike beacon configurations and return basic information about them
Feature	New command line option '--allfiles' that includes file types and locations that are usually not interesting. This is a subset of what '--intense' does.
Change	Upgrade PE-Sieve to v0.2.9.6
Change	Disable quick edit mode for a Windows console while THOR is running in it
Change	Update to Golang 1.15.11
Bugfix	Fix some issues with using THOR Util templates

THOR 10.6.5

Type	Description
Upstream	Merge changes from THOR 10.5.15
Change	Multithreading and virtual mapping have been restricted to Forensic Lab and Incident Response license types
Change	THOR TechPreview packages now contain a THOR Util configuration file to default to the TechPreview on upgrades.

THOR 10.5 (Legacy)

THOR 10.5.18

Type	Description
Change	Remove outdated content from the tools folder in THOR packages
Bugfix	Exclude THOR logs from being detected by THOR

THOR 10.5.17

Type	Description
Feature	Authors of YARA rules are now included in match outputs
Change	Update PE-Sieve to v0.2.9.6
Change	Global YARA rules now cause an error since they can inadvertently affect THOR's internal signatures
Change	Some modules were removed on specific platforms (especially on MacOS and AIX) that only held dummy
Change	Add EVTX 3.2 support
Bugfix	Print Eventlog timestamps in local timezone, unless '--utc' is used

THOR 10.5.16

Type	Description
Change	Upgrade PE-Sieve to v0.2.9.5
Change	Upgrade OpenSSL to 1.1.1j
Bugfix	Ensure THOR honors low CPU limits correctly
Bugfix	Correct loading for some named pipe IOC files
Bugfix	Incorrect formatting for JSON syslog output

THOR 10.5.15

Type	Description
Feature	Add support for a THOR Util configuration file. This file allows setting a default configuration (e.g. to always upgrade to the TechPreview).
Change	Notarize THOR for MacOS

THOR 10.5.14

Type	Description
Feature	Scan all event logs if '--intense' was specified
Feature	Allow fetching the signatures in development by using '--sigdev' with thor-util update
Change	Add info resource to THOR Windows files
Change	Refactor bulk scanning to have less memory allocated / released to reduce memory usage volatility
Change	Let THOR Util default to its own directory for THOR and license paths (same behaviour as THOR already has)
Change	Check YARA / IOC filename indicators (like log, registry, keyword) with word boundaries
Change	Add additional event logs to list scanned by default
Change	Don't allow a downgrade in THOR Util unless '--force' is specified
Change	Update to Golang 1.15.10
Change	Specific options (dropzone mode, deep dive mode, fsonly, nodoublecheck, hostname rewrite) have been restricted to Forensic Lab and Incident Response license types
Bugfix	Add checks for improved handling of corrupted registry hives
Bugfix	Clarify some messages of THOR Util
Bugfix	Apply excludes with OS path separators with '--cross-platform'

THOR 10.5.13

Type	Description
Change	Minor directory exclusion adjustments for Microsoft Exchange

THOR 10.5.12

Type	Description
Bugfix	Remove some directory excludes specific to Microsoft Exchange

THOR 10.5.11

Type	Description
Feature	Make bulk scan size manually configurable with '--bulk-size'
Change	Disable 60 MB log size limit if debugging (with '--debug' or '--trace') is active

THOR 10.5.10

Type	Description
Feature	Suppress rule matches on log files after the same rule matched 10 times or more, this can be deactivated with '--showall'
Feature	Add a context menu for filtering to the HTML reports
Feature	Add support for NFTables firewalls on Linux
Feature	Add a field 'SIGTYPE' to messages which displays whether an IOC or YARA rule is custom or built-in
Feature	Reuse previous Scan ID if a scan is resumed
Feature	Add additional information to files detected in a Windows recycle bin (original file name, deletion time)
Change	Limit file enrichment to 10 files per message
Change	Name automatically generated YARA rules for C2 domains after the domain rather than after a counter
Change	Reduce score of a C2 match with a YARA rule by 30
Change	Upgrade to YARA 4.0.5
Change	Make matching of C2 IOCs on process memory optional, it can be enabled with '--c2-in-memory'
Bugfix	Deduplicate listen ports per process
Bugfix	Improve permission vulnerability check for Linux services
Bugfix	Skip specific registry hives where THOR could behave unstable

THOR 10.5.9

Type	Description
Feature	Apply C2 checks to log scans
Change	Increase the default maximum runtime to 1 week
Change	Apply special scan features on files even if those files exceed the maximum file size set
Bugfix	Remove several false positives on process memory of Antivirus products
Bugfix	Fix an issue where THOR Remote could freeze if too many remote scans were started
Bugfix	Fix an issue where packed files weren't unpacked completely before being scanned

THOR 10.5.8

Type	Description
Bugfix	Print time of currently analyzed event in Eventlog module

THOR 10.5.7

Type	Description
Change	Upgrade to Golang 1.14.7
Change	Catch Panics in a Module to leave other modules unaffected
Change	Disable support for licenses using an obsolete encryption method
Bugfix	Extend output in a specific Events module message
Bugfix	New parameter '--max_process_size' that limits the size of processes that THOR scans with YARA rules. Default value is 500 MB. THOR memory usage increases as this value is increased.

THOR 10.5.6

Type	Description
Bugfix	Catch possible panic during Amcache parsing
Bugfix	Catch possible panic if the Application Eventlog could not be opened

THOR 10.5.5

Type	Description
Change	Exchange signing certificate for newer
Bugfix	Check Registry Hive entries in the same format as Live Registry entries
Bugfix	Check UserData elements in EVTX files

THOR 10.5.4

Type	Description
Feature	Support download of Tech Previews in Thor-Util
Feature	Support license download from ASGARD 2.5+ with '--asgard-token'
Bugfix	Terminate if started with '--resumeonly' and no previous scan with the same context existed
Bugfix	Calculate the context that '--resume' used to check for previous scans differently, excluding elements prone to change

THOR 10.5.3

Type	Description
Bugfix	Catch Panic when handling specific Registry Hives on disk.

THOR 10.5.2

Type	Description
Bugfix	Disable PE-Sieve by default to follow up on some rare issues. It can be enabled with '--process-integrity' or '--intense'.

THOR 10.5.1

Type	Description
Feature	Generate process dumps of suspicious processes (for now Windows only) when '--procdumps' is specified
Feature	New command line option '--procdump-dir' to control where process dumps are stored
Feature	Integrate parser for Windows LNK files
Feature	New command line option '--image-chunk-size' to set the size of chunks when scanning image files
Feature	New command line option '--generate-config' to create a configuration file for THOR based on command line options
Feature	Open busy registry hives using a raw disk image and the MFT
Feature	On interactive interrupts, show progress and a menu to continue or abort the scan
Feature	Support new IOC file for named pipes on Windows
Feature	Detect files with uncommon / unlikely timestamps (timestomping)
Change	Reduce log level for open port messages to Info
Change	Extend '--all-module-lookback' to Registry Hive files and EVTX log files, rename it to '--global-lookback'
Change	Update used YARA to 4.0.1
Change	Print last scanned element when maximum runtime is exceeded
Bugfix	Don't stop HTML log generation on encountering certain uncommon log lines

THOR 10.5.0

Type	Description
Feature	New PowerShell script to download and run Thor easily
Feature	Execute PE-Sieve at runtime to discover processes with malicious sections, sensitivity can be raised further with '--full-proc-integrity'
Feature	New command line option '--scanid-prefix' to set a custom Scan ID prefix
Feature	New command line option '--print-signatures' to print metadata to all YARA and Sigma signatures
Feature	New command line option '--all-module-lookback' that applies lookback to the Filesystem, Registry, and Services modules as well
Feature	Make score for Handle IOCs customizable
Feature	New command line option '--ascii' to exclude non-ASCII characters from the logs
Change	Check open files without using an external 'lsof' executable on Unix platforms
Change	Update descriptions for most command line options
Change	Print non-ASCII strings in matches as hex sequences
Change	Include time (in addition to the date) in default log file name

THOR 10.4

THOR 10.4.2

Type	Description
Feature	Store resume information only if '--resume' is set to improve performance
Feature	New command line option '--portal-key' to download a license at start time
Feature	New command line option '--yara-max-strings-per-rule' to increase the supported number of IOCs
Feature	New command line option '--nofserrors' to suppress filesystem errors
Feature	Print integrated revision of the sigma rules at startup
Feature	Include Scan ID in HTML report synopsis
Change	Apply suspicious locations platform independently
Bugfix	Don't stop HTML log generation on encountering certain uncommon log lines
Bugfix	Remove anonymization on non-personal accounts like Default
Bugfix	Apply Signatures for Windows Handles more precisely
Bugfix	Remove a False Positive that could occur in the DNS cache
Bugfix	Increase the supported number of IOCs massively beyond the default 10000.
Bugfix	Fix a panic related to incorrectly formatted /etc/passwd files on Linux.

THOR 10.4.1

Type	Description
Bugfix	Filescan panic on WER (Windows Error Report) files

THOR 10.4.0

Type	Description
Feature	Added Bifrost 2 gRPC support for upcoming ASGARD 2
Feature	EmoCheck in FileScan module
Feature	TeamViewer password detection and decryption

THOR 10.3

THOR 10.3.1

Type	Description
Bugfix	Files mentioned in Archivescan do not show up in CSV export

THOR 10.3.0

Type	Description
Feature	Iterate over process handles (files, events, mutants) natively without external tools
Feature	Automatically set a random Scan ID that will be added to each log line
Feature	Log to local syslog with '--local-syslog' (Linux and macOS only)
Feature	SHIMCache entries will be scanned in Registry Hive files, too
Feature	Do not skip registry paths with low relevance by using '--fullregistry' or '--intense'
Feature	New license type 'Silent' for rollout / deployment testing
Feature	Cross-platform filename IOCs in '--fsonly' mode (or with flag '--cross-platform')
Feature	New exclude configurations 'registry-excludes.cfg' and 'eventlog-excludes.cfg'
Feature	Enrich process information for event and mutant handles
Feature	Apply regexes on event and mutant handles
Feature	Added few more eventlog targets
Feature	New flag '--process <pid>' to scan a specific process
Change	Added comment to users' last logon date
Change	Enrich file information in process check output
Change	New flag '--max_file_size_intense' to set max file size for intense mode separately
Change	Removed flag '--buffer_size'. THOR's buffer will now be as big as '--max_file_size'
Change	Added YARA rules' date to match output
Change	Upgraded THOR Util to 1.9.8
Change	Wordings in flag descriptions
Change	Duplicates in IOCs will be filtered automatically
Bugfix	'-j <hostname>' will also rewrite names of THOR's logfiles
Bugfix	Fixed sporadically missing start- and endtime in html report
Bugfix	Fixed off-by-one error for '--maxloglines' flag
Bugfix	Skip directory junctions when scanning remotely mounted windows ntfs partitions
Bugfix	Fixed interaction of relevant file extensions and some file types

THOR 10.2

THOR 10.2.11

Type	Description
Feature	Sigma modifiers "startswith" and "endswith" are now supported

THOR 10.2.10

Type	Description
Bugfix	Empty values for "(Default)" keys names in Registry matching

THOR 10.2.9

Type	Description
Change	Removed legacy files (sfx, bat)
Change	Removed fix skip of "SOFTWAREClasses" Registry key
Bugfix	custom IOC initialization used different keywords than described in documentation ("c2" > "domain", "trusted" > "falsepositive")

THOR 10.2.8

Type	Description
Change	Increased default max. file size from 4.5 MB to 6.5 MB
Bugfix	Fixed a bug in sigma scoring system

THOR 10.2.7

Type	Description
Change	Dropped max filesize check for many types in intense scan mode (--intense / --fsonly) including memory dumps, registry hives, EVTX files
Change	Added PKZIP and MS Office PK header to headers eligible for archive scan
Change	Added file name, file path, hostname and channel to matches on events found in EVTX files

THOR 10.2.6

Type	Description
Change	Improvements to MESSAGE field (better descriptions)

THOR 10.2.5

Type	Description
Change	List available modules if selected module is unknown
Change	Increased log window size for thor events in thor remote
Change	Print reasons for invalid licenses
Change	Sigma rules will be muted if they matched too often
Change	Event IOCs will be applied on Mutex checks and vice versa

THOR 10.2.4

Type	Description
Bugfix	Fixed logic error in lsasessions' kerberos ticket life time checks

THOR 10.2.3

Type	Description
Change	Removed THOR Remote warning that a file could not be collected, which doesn't exist
Change	Low sigma rules will not be printed anymore, medium sigma rules will only be printed in '--intense' mode

THOR 10.2.2

Type	Description
Feature	New module 'Events' that checks for malicious Windows events

THOR 10.2.1

Type	Description
Feature	New ThorDB table 'stats', which contains scan duration of scan elements
Feature	New output mode '--reduced' to reduce output to warnings, alerts and errors
Change	Files can be scanned multiple times in Dropzone mode

THOR 10.2.0

Type	Description
Change	Upgraded YARA to 3.11.0
Change	Extended output of '--version' command
Change	Added ExecFlag to SHIMCache output
Change	Apply YARA on WMI Event Filters
Change	Passing new external YARA variables 'timezone' and 'language' to registry ruleset

THOR 10.1

THOR 10.1.9

Type	Description
Change	Made YARA more robust - YARA rules will now compile even if there is a duplicate identifier
Change	Made Sigma more robust - Sigma rules will now compile even if a rule is corrupt
Change	Removed challenge-response for trial licenses that are host-based
Change	Updated file types that will trigger a warning if cloaked

THOR 10.1.8

Type	Description
Change	Reverting case-insensitive filename IOC checking
Docs	New manual (fixed broken references)

THOR 10.1.7

Type	Description
Change	Crash reports are not truncated anymore
Bugfix	Improved stability of ScheduledTasks module

THOR 10.1.6

Type	Description
Change	Improved Sigma initialization
Change	Improved THOR Lite initialization

THOR 10.1.5

Type	Description
Feature	THOR Lite (replaces SPARK Core)

THOR 10.1.4

Type	Description
Change	Add `https://` protocol to '--bifrost2Server' if missing

THOR 10.1.3

Type	Description
Feature	New flag '--bifrost2Ignore <pattern>' to specify ignore patterns for Bifrost 2

THOR 10.1.2

Type	Description
Change	Wordings in '--help' section
Bugfix	Fixed THOR crash when scanning corrupt EVTX file

THOR 10.1.1

Type	Description
Feature	New flags '--ca <path>' and '--insecure' for tls host verification
Feature	HTTP proxy support for Bifrost 2 and license generation with ASGARD

THOR 10.1.0

Type	Description
Feature	THOR Remote for Windows
Feature	Bifrost 2
Feature	Sigma value modifiers (contains, base64, re, ...)
Bugfix	Fixed file descriptor leak in PE imphash calculation
Bugfix	Fixed "has admin rights" output when running with different EUID
Bugfix	Wrong eventtime in WER module output

THOR 10.0

THOR 10.0.14

Type	Description
Bugfix	Ignore filepaths of archives when scanning the contents with YARA

THOR 10.0.13

Type	Description
Bugfix	Fixes in exclusions and firewall indicator regex filters

THOR 10.0.12

Type	Description
Bugfix	Fixed obfuscated exclusion and apt presets

THOR 10.0.11

Type	Description
Change	ZEUS port detection regex adjusted

THOR 10.0.10

Type	Description
Change	More process excludes (OneDrive issue)

THOR 10.0.9

Type	Description
Change	Adjusted process excludes list (Windows Defender, OneDrive)

THOR 10.0.8

Type	Description
Change	Adjusted suspicious locations to avoid some SHIMCache false positives

THOR 10.0.7

Type	Description
Bugfix	Eventlog module deactivation disfunctional (--noeventlog, --quick)

THOR 10.0.6

Type	Description
Feature	Linux and MacOS support
Feature	Scan eventlog and logfiles with Sigma
Feature	STIX v2 in various checks and modules
Feature	Log to JSON file, send JSON via UDP/TCP
Feature	Scan templates '-t <template-file>' that holds preset command line arguments
Feature	Get license from ASGARD with '--asgard <host>'
Change	Update signatures with thor-util update
Change	Upgrade scanner with thor-util upgrade
Change	Changed programming language from Python to Golang
Change	Configure actions with command line arguments '--action-command <cmd>', '--action-args <argN>' and '--action-level <level>'
Change	Encrypt (RSA) scan results with '--encrypt', use custom key (or key file) with '--pubkey <key\|file>'
Change	Removed obsolete 'thor-upgrade.exe' tool
Change	THOR doesn't require SYSINTERNALS 'autorunsc.exe' in tools directory anymore
Change	Removed obsolete fast mode '--fast'
Change	Command line arguments with multiple values can not be appended anymore, they require a key in front of each value
	Example: '-p <path1> -p <path2> ... -p <pathN>' instead of '-p <path1> <path2> ... <pathN>'
Change	Short command line arguments with more than one character were removed. E.g. '-em <days>', use '--lookback <days>' instead
Change	Removed log caching in ThorDB

Indices and tables

Search Page

Type	Score
YARA match	Defined in the meta data of the YARA rule as integer value (e.g. "score = 50")
Filename IOC match	Defined in the 2^nd field of the CSV (e.g. `\\evil.exe;80`)
Keyword IOC match	"warning" level messages, see Default Scores
C2 IOC match	"warning" and "alert" level massages, see Default Scores

Parameter	Description
--action_command string	Run this command for each file that has a score greater than the score from `--action_level`
--action_args strings	Arguments to pass to the command specified via `--action_command`. The placeholders `%filename%`, `%filepath%`, `%file%`, `%ext%`, `%md5%`, `%score%` and `%date%` are replaced at execution time
--action_level int	Only run the command from `--action_command` for files with at least this score (default `40`)

Parameter	Description
--nothordb	Disables THOR DB completely. All related features will be disabled as well.
--dbfile [string]	Allows to define a location of the THOR database file. File names or path names are allowed. If a path is given, the database file `thor10.db` will be created in the directory. Environment variables are expanded.
--resume	Resumes a previous scan (if scan state information is still available and the exact same command line arguments are used)
--resumeonly	Only resume a scan if a scan state is available. Do not run a full scan if no scan state can be found.

THOR Scanner User Manual

What is THOR?

Package

Requirements

Operating Systems

Legacy Systems

THOR for AIX

Unsupported

Update Servers

Before You Begin

Add License File

Generate a License

About License Files

Upgrade THOR and Update The Signatures

Define an Antivirus / EDR Exclusion

A Note on SentinelOne

A Note on McAfee

Choose The Right THOR Variant

THOR

THOR TechPreview

THOR Legacy

Choose The Right Architecture

Choose The Right Command Line Flags

Add Command Line Completions (optional)

Verify Public Key Signatures (optional)

Deployment

Licensing

Retrieve Valid License From ASGARD

Use THOR's --asgard and --asgard-token parameters

Use ASGARD's API to retrieve a license manually

Retrieve Valid License From Customer Portal

Use THOR's --portal-key and --portal-contracts parameters to retrieve a license

Use the Customer Portal's API to retrieve a license manually

Network Share (Windows)

Place THOR on a Network Share

Create a Scheduled Task via GPO

Create a Scheduled Task via PsExec

Start THOR on the Remote System via WMIC

ASGARD Management Center (Windows, Linux, macOS)

Ansible (Linux)

Distribute Run with Ansible

Ansible

Execute THOR using Ansible

Inventory File

Ansible Playbook Template

Usage of THOR's Ansible playbook

Adjust THOR's Command Line Parameters

THOR Thunderstorm Service

Service License Type

Thunderstorm Collectors

Thunderstorm API Client

Thunderstorm API Documentation

Server Installer Script for Linux

Thunderstorm Update

Thunderstorm Update Script

Source Identification

Synchronous and Asynchronous Mode

Performance Tests

SSL/TLS

THOR Remote

Usage

THOR Remote Licensing

Output

Issues

System Error 5 occurred – Access Denied

Running THOR from a Network Share

Distribute to Offline Networks / Field Offices

System Load Considerations

Scan

Quick Start

Often Used Parameters

Parameters possibly relevant for your Use Case

Risky Flags

Lesser Known But Useful Flags

Help and Debugging

Examples

Logging to a Network Share

Logging to Syslog Server

Scan Run on a Single Directory

Save the result files to a different directory

Use THOR's `--asgard` and `--asgard-token` parameters

Use THOR's `--portal-key` and `--portal-contracts` parameters to retrieve a license