THOR Manual

THOR MANUAL
VERSION 10.5
1 What is THOR? ............................................................................................................ 7
2 Requirements ............................................................................................................. 8
3 Package ..................................................................................................................... 9
4 Preparations ............................................................................................................. 10
4.1 Add License File .................................................................................................... 10
4.2 Add Tools (optional) ............................................................................................... 10
4.3 Verify Signatures (optional) ..................................................................................... 10
5 Single Scan .............................................................................................................. 11
5.1 Quick Way ............................................................................................................. 11
5.2 Controlled Way ...................................................................................................... 11
6 Deployment .............................................................................................................. 12
6.1 Network Share (Windows)........................................................................................ 12
6.1.1 Place THOR on a Network Share ................................................................................. 12
6.1.2 Create a Scheduled Task via GPO ............................................................................... 13
6.1.3 Create a Scheduled Task via PsExec ........................................................................... 13
6.1.4 Start THOR on the Remote System via WMIC ............................................................... 13
6.2 ASGARD Management Center (Windows, Linux, macOS) ............................................... 14
6.3 Ansible (Linux) ...................................................................................................... 15
6.3.1 Distribute Run with Ansible ......................................................................................... 15
6.3.2 Ansible ...................................................................................................................... 15
6.3.3 Execute Thor using Ansible ........................................................................................ 15
6.3.4 Inventory File ............................................................................................................. 16
6.3.5 Ansible Playbook Template ........................................................................................ 16
6.3.6 Usage of Thor´s Ansible playbook............................................................................... 17
6.3.7 Adjust Thor’s Command Line Parameters .................................................................... 17
6.4 THOR Remote (New) ............................................................................................... 17
6.4.1 Usage ........................................................................................................................ 17
6.4.2 Licensing ................................................................................................................... 18
6.4.3 Output ....................................................................................................................... 18
6.4.4 Issues ....................................................................................................................... 19
6.5 Distribute to Offline Networks / Field Offices .............................................................. 19
6.6 System Load Considerations .................................................................................... 19
7 Scan ........................................................................................................................ 20
7.1 Most Relevant Parameters ....................................................................................... 20
7.2 Recommended Scan Options .................................................................................... 21
7.2.1 Logging to a Network Share ........................................................................................ 21
THOR Manual Page 2 of 76

7.2.2 Logging to Syslog Server ............................................................................................ 21
7.2.3 Logging to a Local Log File and Import........................................................................ 21
7.3 Often Used Parameters ........................................................................................... 21
7.3.1 Scan Run on a Single Directory ................................................................................... 21
7.3.2 Deactivate all file output - Syslog only ......................................................................... 21
7.3.3 Save the result files to a different directory ................................................................. 21
7.3.4 Only scan the last 7 days of the Windows Eventlog and log files on disk ....................... 21
7.3.5 Scan System with Defaults and Make a Surface Scan .................................................. 22
7.3.6 Intense Scan and DeepDive on a Mounted Image as Drive Z ......................................... 22
7.3.7 Throttled THOR Run (static throttling value) ................................................................ 22
7.3.8 Scan Multiple Paths ................................................................................................... 22
7.3.9 Scan All Hard Drives (Windows Only) .......................................................................... 22
7.4 Scan Output .......................................................................................................... 22
7.4.1 Log File Output (.txt) .................................................................................................. 22
7.4.2 JSON Output (.json) ................................................................................................... 22
7.4.3 Key Value Output ....................................................................................................... 23
7.4.4 SYSLOG Output .......................................................................................................... 23
7.4.5 Timestamps .............................................................................................................. 23
7.4.6 SCAN ID .................................................................................................................... 24
7.5 Run a Scan with Specific Modules ............................................................................. 24
7.5.1 Examples................................................................................................................... 25
7.6 Debugging ............................................................................................................ 25
7.6.1 Find Bottlenecks ........................................................................................................ 25
7.6.2 Most Frequent Causes of Missing Alerts ..................................................................... 26
8 Analysis ................................................................................................................... 27
8.1 ASGARD Analysis Cockpit ....................................................................................... 27
8.2 Splunk .................................................................................................................. 28
8.3 THOR Util Report Feature ........................................................................................ 29
8.4 Log Analysis Manual............................................................................................... 29
9 Special Scan Modes ................................................................................................... 30
9.1 Lab Scanning (--fsonly) ........................................................................................... 30
9.2 Lookback Mode (--lookback --all-module-lookback) .................................................... 30
9.3 Drop Zone Mode (--dropzone) .................................................................................. 30
9.4 Image File Scan Mode (-m) ...................................................................................... 31
9.5 DeepDive (--deepdive) ............................................................................................ 31
9.6 Eventlog Analysis (-n) ............................................................................................. 32

9.7 MFT Analysis (--mft) .............................................................................................. 33
10 Configuration Files .................................................................................................... 34
10.1 Scan Templates ..................................................................................................... 34
10.1.1 Default Template ....................................................................................................... 34
10.1.2 Apply Custom Scan Templates ................................................................................... 34
10.1.3 Example Templates.................................................................................................... 34
11 License Files............................................................................................................. 36
12 Scan Modes .............................................................................................................. 37
12.1 Scan Modes Overview ............................................................................................. 38
12.1.1 Modules .................................................................................................................... 38
12.1.2 Features .................................................................................................................... 39
13 Evidence Collection ................................................................................................... 40
13.1 File Collection (Bifrost) ........................................................................................... 40
13.1.1 Bifrost v1 with Script-Based Server ............................................................................. 40
13.1.2 Bifrost v2 with ASGARD .............................................................................................. 40
13.2 Process Dumps ...................................................................................................... 41
14 Scoring System ......................................................................................................... 43
14.1 Scoring per Signature Type Match ............................................................................ 43
14.2 Accumulated Score by Module ................................................................................. 43
14.3 Default Scores ....................................................................................................... 44
14.4 Exception: High total score with low sub scores .......................................................... 44
14.5 Exception: Filename IOC Checks ............................................................................... 44
14.5.1 Filename IOC Matching in String Check Example ......................................................... 44
15 Update ..................................................................................................................... 46
15.1 Upgrade Locations ................................................................................................. 46
15.2 Update Server Information ....................................................................................... 46
16 Syslog ..................................................................................................................... 47
16.1 Target Definition .................................................................................................... 47
16.2 Common Event Format (CEF) .................................................................................... 47
17 THOR DB .................................................................................................................. 48
17.1 Scan Resume......................................................................................................... 49
17.2 Delta Comparison ................................................................................................... 50
18 Resource Control ....................................................................................................... 51
18.1 Automatic Soft Mode .............................................................................................. 51
19 Exclude Elements ...................................................................................................... 52
19.1 Files and Directories ............................................................................................... 52

19.2 Eventlogs.............................................................................................................. 52
19.3 Registry ................................................................................................................ 52
19.4 False Positives ...................................................................................................... 53
19.5 Filter Verification ................................................................................................... 53
19.6 Personal Information .............................................................................................. 53
20 Threat Intel Receivers ................................................................................................ 54
21 Custom Signatures .................................................................................................... 56
21.1 Simple IOCs .......................................................................................................... 56
21.1.1 Hashes ...................................................................................................................... 56
21.1.2 Trusted Hashes ......................................................................................................... 56
21.1.3 File Name Characteristics .......................................................................................... 56
21.1.4 Keyword IOCs ............................................................................................................ 58
21.1.5 Mutex, Named Pipes or Event Values .......................................................................... 58
21.1.6 Initialization Based on Strings in File Names ............................................................... 59
21.2 Sigma .................................................................................................................. 59
21.2.1 Sigma Examples ........................................................................................................ 60
21.3 STIX..................................................................................................................... 60
21.3.1 STIX v1 ...................................................................................................................... 61
21.3.2 Encrypted STIX IOC Files ............................................................................................ 61
21.4 YARA ................................................................................................................... 62
21.4.1 Generic YARA Rules ................................................................................................... 62
21.4.2 Specific YARA Rules ................................................................................................... 62
21.4.3 YARA Rule Application ............................................................................................... 63
21.4.4 Create YARA Rules ..................................................................................................... 63
21.4.5 Typical Pitfalls ........................................................................................................... 64
21.4.6 YARA Rule Performance ............................................................................................. 65
21.5 Enhance YARA Rules with THOR Specific Attributes .................................................... 65
21.5.1 Score ........................................................................................................................ 66
21.5.2 Additional Attributes .................................................................................................. 67
21.5.3 THOR YARA Rules for Registry Detection ..................................................................... 68
21.5.4 Restrict Yara Rule Matches in Generic Rules ................................................................ 70
21.5.5 Restrict Yara Rule Matches in Specific Rules ............................................................... 71
21.5.6 False Positive Yara Rules ........................................................................................... 71
21.6 Encrypt Custom Signatures ...................................................................................... 72
22 Analysis and Info ....................................................................................................... 73
22.1 Log Analysis Manual............................................................................................... 73

22.2 VALHALLA Rule Lookup .......................................................................................... 73
22.3 Rule List Output ..................................................................................................... 74
23 Encrypted Output Files ............................................................................................... 75
24 Links and References ................................................................................................. 76

1 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 a
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 agentless "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/KV/CEF), HTML, TXT, JSON, CSV
§ Throttling of the scan process to reduce the system load to a minimum

2 Requirements
THOR runs in any Windows, Linux and macOS environment without any further requirements.
Everything needed is already included in the program package.
For best results, it is necessary to run THOR with administrative privileges or
LOCAL_SYSTEM on Windows and “root” on Linux/macOS systems.
Supported
§ Windows 7 x86
§ Windows 7 x64
§ Windows Server 2008 x86
§ Windows Server 2008 R2 x64
§ Windows 8.1
§ Windows Server 2012
§ Windows Server 2012 R2
§ Windows 10
§ Windows Server 2016
§ RHEL/CentOS 6
§ RHEL/CentOS 7
§ SuSE SLES 11
§ SuSE SLES 12
§ SuSE SLES 15
§ Ubuntu 14 LTS
§ Ubuntu 16 LTS
§ Ubuntu 18 LTS
§ Debian 8
§ Debian 9
§ macOS 10
Unsupported
§ Windows XP SP2 x86 (unsupported)
§ Windows XP SP2 x64 (unsupported)
§ Windows Server 2003 x86 (unsupported)
§ Windows Server 2003 x64 (unsupported)
If you need to run scans on old Windows XP and 2003 machines, contact us for old scanner
versions that run on these outdated platforms.

3 Package
The THOR Package includes the following files and directories:
§ THOR Binaries - thor.exe for 32-bit and thor64.exe for 64-bit systems
§ THOR Utility (thor-util.exe) (Helper tool for update, encryption, report generation,
signature verification and other tasks – see the separate manual)
§ Configuration Files in "./config" subfolder
(directory-excludes.cfg, sigma.yml, false_positive_filters.cfg)
§ Main Signature Database of THOR (./signatures/)
§ Custom Signatures and Threat Intel IOCs (./custom-signatures/)
§ THOR change log (changes.log)
§ Additional tools like EXE packers and the Bifrost server script (./tools/)
§ Threat Intel Receivers for the IOC retrieval from MISP and OTX (./threatintel)
§ THOR manuals (./docs/)

4 Preparations
4.1 Add License File
Files that you have to place in the program folder:
§ THOR License File (*.lic)
THOR check the program folder and all sub folder for valid license files. You can specify
a certain path with --licensepath path. See chapter 11 "License Files" for details.
4.2 Add Tools (optional)

The EULA of the SysInternals tool “Handle” doesn’t allow us to ship the tool with scanner
package. You can download this tool, accept their EULA and place it into the ./tools sub
folder to improve the scan results.
This tool is still required due to limitations in the Golang standard lib. We’ll remove this
dependency in future versions.
Handle: https://docs.microsoft.com/en-us/sysinternals/downloads/handle
4.3 Verify Signatures (optional)

You can verify the executable files in the THOR package via:
§ their digital signature - issued by "BSK Consulting GmbH"
§ thor-util’s “verify” feature
§ this hash list https://www.nextron-systems.com/download/hashsums.txt

5 Single Scan
5.1 Quick Way
1. Open the folder with the THOR executables (thor.exe, thor64.exe)
2. Right click on THOR and select "Run as Administrator"
3. A command line window appears and closes itself at the end of the scan
4. Check the HTML report in the THOR program directory named:
COMPUTERNAME_thor_YEAR-MONTH-DAY.html
5.2 Controlled Way

1. Start a Terminal with Administrator rights (Right Click > Run as Administrator)
2. Change directory to the program directory of THOR
3. Check most relevant parameters in chapter 7.6 "Often Used Parameters" or all
available parameters with "thor.exe --help"
4. Start "thor.exe" with the necessary parameters
i.e. "thor.exe -s 10.1.52.1 --fsonly -p C:\ -p D:\webapp"

6 Deployment
This chapter lists different ways to deploy THOR in an environment. Most of these methods
are OS specific.
6.1 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).
Figure 1 – Deployment via Network Share
6.1.1 Place THOR on a Network Share

A good way to run THOR on multiple systems is by defining a "Scheduled Task" using your
Windows domain's group policy functionality.
The preferred way to run THOR on a remote system is by providing a network share on which
the extracted THOR package resides. You can use this directory as the output directory but it

is recommended to create another share with write permissions especially for the HTML and
TXT result files. The share that holds the THOR program folder should be read-only. The
various output files must be disabled or defined in different locations in order to avoid write-
access errors.
The necessary steps are:
1. Create a network share and extract the THOR package into the root of the share, i.e.
\\fileserver\thor\
2. Find the "thor_remote.bat" batch file, which can be found in the “tools” sub folder,
place it directly in the root of the program folder and adjust it to your needs.
§ set the network share UNC path
§ set the parameters for the THOR run (see chapter 7 "Scan")
You should then test the setting like this:
1. Connect to a remote system (Remote Desktop), which you would like to scan
2. Start a command line "as Administrator"
(right click > Run as Administrator)
3. Run the following command, which is going to mount a network drive, run THOR and
disconnect the previously mounted drive:
\\fileserver\thor\thor_remote.bat
After a successful test run, you decide on how to invoke the script on the network drive. The
following chapters list different options.
6.1.2 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
6.1.3 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:
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
6.1.4 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.
wmic /node:10.0.2.10 /user:MYDOM\scanadmin process call create "cmd.exe /c
\\server\thor10\thor.exe"

6.2 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 analyse 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
Screenshot 1 - ASGARD Management Center

Screenshot 2 - ASGARD IOC Management
6.3 Ansible (Linux)

6.3.1 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.
6.3.2 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.
6.3.3 Execute Thor using Ansible

The following section will show how to use a 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 mountpoint

§ Copy Thor to this RAM drive
§ Execute Thor
§ Unmount the RAM drive
§ Delete the temporary folder
6.3.4 Inventory File

First it is needed to define a list of hosts to execute Thor on. This is done by setting up yml
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 reference the
official documentation:
https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html
6.3.5 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=/https/www.scribd.com/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/
Listing 1 - Ansible Playbook

6.3.6 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:
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.
6.3.7 Adjust Thor’s Command Line Parameters

Per default this playbook will start Thor with only the parameter, to define 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.
6.4 THOR Remote (New)

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 für SCM (Service Management)
445/tcp für 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)
6.4.1 Usage
A list of parameters used with the remote scanning function can be found in the help screen.

Screenshot 3 - THOR Remote Usage
As you can see, a list of target hosts can be provided with the help of the new YAML config
files. See chapter 10 “Configuration Files” for more details.
A YAML file with a list of hosts looks like this:
remote:
- winatl001.dom.int
- winatl002.dom.int
- winnyk001.dom2.int
Listing 2 - THOR remote host definition in targets.yml file
We recommend using a text editor that supports multi-line editing like Atom or Sublime.
https://atom.io/
https://stackoverflow.com/questions/39391688/multi-line-editing-on-atom
You can then use that file with:
thor64.exe -t targets.yml
6.4.2 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).
6.4.3 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.

Screenshot 4 - THOR Remote Interface
6.4.4 Issues
6.4.4.1 System Error 5 occurred – Access Denied

See: https://helgeklein.com/blog/2011/08/access-denied-trying-to-connect-to-administrative-shares-
on-windows-7/
6.4.4.2 Running THOR from a Network Share

THOR must reside on the local filesystem of the source system. Don’t run it from a mounted
network share. This could lead to the following error:
CreateFile .: The system cannot find the path specified.
6.5 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
6.6 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.

7 Scan
THOR operates pretty well when you run it with the default settings. This is mainly because
THOR automatically adapts the scan speed to the performance capabilities of the system.
7.1 Most Relevant Parameters

The following table lists the parameters that are often used and relevant for the standard
deployment. The recommended options are shaded in green.
Parameter Values Function
-t template-string Location of scan template file (.yml) with defined scan
parameters
-s server Set a SYSLOG target server
-l log-file Location of the text log file.
Use environment variables like %COMPUTERNAME% to
generate a log file with the system name in the file
name.
--nolog Disables text log output
-htmlfile htmlreport-file Location of the HTML report file.
name.
--nohtml Disables HTML report output
-o md5list-file Location of the MD5 list file.
name.
--nocsv Disables MD5 list output
-e location Rebase Directory. Set a different path as output location
for all output files. Instead of setting a new location for
all output files separately, you can just define a new
location by "-e E:\", which is much shorter and less
complex. The naming scheme will still be
"HOSTNAME_thor_DATE.ext". Output directories that do
not exist, will be created.
--lookback 1.. Number of days to look back in the Windows Eventlog. If
you schedule a frequent scan, use this option to limit
the Eventlog analysis to the yet unchecked dates.
-d Get debug information if errors occur.
--help Get a full help with all options.
Table 1 - Most Relevant Scan Options

7.2 Recommended Scan Options
The following scan options are recommended if you plan to deploy THOR as described in the
previous chapters. We distinguish between the log collection on a network share, a central
syslog server and the use of local log files.
The command line options described in the following sections have to be configured in the
"thor_remote.bat" or a "run_thor.bat" in case of a local scan without network connection to the
central log collection/syslog server.
7.2.1 Logging to a Network Share

The following command creates a plaintext log file on a share called "rep" on system "sys" if
the user running the command has the respective access rights on the share.
thor.exe --nohtml --nocsv -l \\sys\rep\%COMPUTERNAME%_thor.txt
If preferably used in the "thor_remote.bat" use the variable %RESDRIVE% instead of the UNC
path:
thor.exe --nohtml --nocsv -l %RESDRIVE%\%COMPUTERNAME%.txt
7.2.2 Logging to Syslog Server

The following command instructs THOR to log to a remote syslog server only.
thor.exe --nohtml --nocsv --nolog -s syslog.server.net
7.2.3 Logging to a Local Log File and Import

The following options should be used in a "run_thor.bat" file in the THOR folder of the USB
drive. It will generate a TXT log that is written at runtime and a HTML report that is generated
at the end of the scan.
thor.exe --nocsv
7.3 Often Used Parameters

7.3.1 Scan Run on a Single Directory
thor.exe --fsonly -p C:\ProgramData
thor.exe --fsonly -p I:\mounted_image\disk1
7.3.2 Deactivate all file output - Syslog only

thor.exe -s 10.1.5.14 --nohtml --nolog --nocsv
7.3.3 Save the result files to a different directory

thor.exe -s 10.1.5.14 -e Z:\
7.3.4 Only scan the last 7 days of the Windows Eventlog and log files on disk
thor.exe --lookback 7

7.3.5 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.
thor.exe --deepdivecustom -e \\server\thor_output_share
7.3.6 Intense Scan and DeepDive on a Mounted Image as Drive Z

thor.exe --fsonly --deepdive -p Z:\
7.3.7 Throttled THOR Run (static throttling value)

Will restrict THOR’s CPU usage in the long running modules “FileScan”, “Eventlog”, “LogScan”
and “Registry” to 80%. Note that THOR automatically applies certain restrictions in automatic
soft mode.
thor.exe -c 80
7.3.8 Scan Multiple Paths

thor.exe --fsonly -p C:\ D:\webapps E:\inetpub
(non-existent directories will be automatically skipped)
7.3.9 Scan All Hard Drives (Windows Only)

thor.exe --allhds
7.4 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.
7.4.1 Log File Output (.txt)

The standard log file is written by default.
§ --nolog
Don’t create a log file
§ -l / --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.
7.4.2 JSON Output (.json)

The JSON output file can be configured with these options:

§ --json
Create a JSON output file
§ --jsonfile filename
Set a filename for the JSON log file
§ --cmdjson
Print JSON format into the command line (e.g. used with Splunk scripted input)
§ -s [syslogtarget]:[port]: SYSLOGJSON
Send syslog messages with JSON formatting
7.4.3 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)
§ -s [syslogtarget]:[port]:SYSLOGKV
Send syslog messages with propper 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"
7.4.4 SYSLOG Output

One or more SYSLOG targets can be set with the -s parameter.
For details on the syslog output see chapter “16 Syslog”.
7.4.5 Timestamps
Timestamp in all modules use the ANSIC standard, which looks like:
Mon Jan 2 15:04:05 2006
Mon Mar 19 09:04:05 2018
https://flaviocopes.com/go-date-time-format

7.4.5.1 UTC
The --utc parameter allows to use UTC in all timestamps.
7.4.5.2 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
7.4.6 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 end system?
§ Which scan on a certain end system 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_-
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.
Examples:
S-Rooa61RfuuM
S-0vRKu-1_p7A
In a log line, it looks like:

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
7.4.6.1 Custom Scan ID Prefix

Since 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.
7.5 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.
Valid modules are:
Autoruns, DeepDive, Dropzone, EnvCheck, Filescan, Firewall, Hosts, LoggedIn,
OpenFiles, ProcessCheck, UserDir, ServiceCheck, Users, AtJobs, DNSCache,
Eventlog, HotfixCheck, LSASessions, MFT, Mutex, NetworkSessions, NetworkShares,
RegistryChecks, Rootkit, SHIMCache, ScheduledTasks, WMIStartup

7.5.1 Examples
Run a Rootkit check only:
thor64.exe -a Rootkit
Run the Eventlog and file system scan:

thor64.exe –a Eventlog -a Filescan
7.6 PE-Sieve Integration

THOR integrates PE-Sieve, an open-source tool by @hasherezade to check for malware
masquerading as benevolent processes.
PE-Sieve will run on Windows as part of the ProcessCheck module and is capable of
detecting advanced techniques such as Process Doppelganging. When investigating likely
infections, you can also raise the sensitivity of the integrated PE-Sieve's sensitivity beyond
the default (at the cost of likely false positives).
Activate a higher sensitivity with “--full-proc-integrity”.
7.7 Debugging
Most unexpected behavior can be debugged by using the parameters ‘--debug’ and the even
more verbose ‘--trace’.
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
Then try scanning that specific element with the ‘--debug’ and ‘--trace’ parameters set.
7.7.1 Find Bottlenecks

You may get the error message “MODULE: RuntimeWatcher MESSAGE: Maximum runtime
has exceeded, killing THOR” or encounter very slow or never ending scans.
You can check the statistics table in “thor.db” on that end system 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\thor.db

7.7.2 Most Frequent Causes of Missing Alerts
7.7.2.1 THOR didn’t scan file due to file size restrictions.

Solution: Use --max_file_size parameter or set permanently in config file
“./config/thor.yml”. Also note that in lab scanning mode the default value is much
bigger (--max_file_size_intense)
7.7.2.2 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 lab scanning mode (--fsonly) or add the magic header to file-type-
signatures.cfg (Warning: this file gets overwritten with an update)

8 Analysis
This chapter explains the possibilities for collecting and analyzing THOR logs.
8.1 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 are executed manually or are controlled by third party solutions. It is
available as a virtual appliance on VMWare and also as 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.
Screenshot 5 - Analysis Cockpit View

8.2 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.
Screenshot 6 - THOR Splunk App (free)
Screenshot 7 - Splunk THOR App Universal View
THOR APT Scanner App

THOR Add-On

8.3 THOR Util Report Feature
THOR Util provides a feature called “report” that creates HTML reports from text logs of one
or more scanned systems.
Screenshot 8 - THOR Util's Report Output
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/
8.4 Log Analysis Manual

The Customer Portal contains a log analysis manual in the “Downloads” section.
Screenshot 9 - Log Analysis Manual Download Link
https://portal.nextron-systems.com/webshop/downloads

9 Special Scan Modes
9.1 Lab Scanning (--fsonly)
Lab scanning mode that is activated with --fsonly. It is used in cases in which a mounted
filesystem or single directory on a forensic workstation should be checked in an intense
scan. All resource control functions are disabled and intense mode is activated by default.
The "--fsonly" 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)
A full command line of a THOR scan started in a lab environment would look like this:
thor64.exe --fsonly -p S:\ -e C:\reports –j hostname-of-src-image
You typically mount a disk or partition image to a given drive letter ("S:") and want to write
the output files to a dedicated directory ("C:\thor-reports"). The parameter -j can be used to
reset the hostname used in the log files to a given identifier instead of using the current
workstation's name in all output files.
9.2 Lookback Mode (--lookback --all-module-lookback)

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.
9.3 Drop Zone Mode (--dropzone)

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:
thor.exe --dropzone –p C:\dropzone

9.4 Image File Scan Mode (-m)
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 (--fsonly) 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 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.
thor.exe –m systemX123.mem –j systemX123 –e C:\reports
9.5 DeepDive (--deepdive)

The DeepDive module allows a surface scan of a given drive.
This check processes every byte of the whole hard drive including the free space. This
enables THOR to detect deleted files that have not been wiped by the attackers.
DeepDive is not recommended for triage sweeps in a whole network as it generates more
false positives that a normal file system scan. This is mainly caused by the fact that chunks
of data read from the disk 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 "- a deepdive" option. To restore all detected files to a
restore directory additionally use the "-r directory" option.

Option Description
-a deepdive Activate DeepDive for the File System Scan.

Only applicable if scan target is a whole drive – default or with
selected drive root, i.e. "-p D:\"
-r directory Recovery directory for files found by DeepDive
Table 2 - DeepDive Options
While the DeepDive detects suspicious files regardless of their master file table reference
the default file system scan that is executed afterwards may detect the same file twice.
The following example for the use of the DeepDive shows how to scan a mounted file system
image as drive "X:".
thor --fsonly --deepdive -rd D:\restore -p X:\
Listing 2: DeepDive Example
9.6 Eventlog Analysis (-n)

The Eventlog scan mode allows scanning certain Windows Eventlogs.
The parameter -n works like the -p parameter in the Filesystem module takes the target
Eventlog as parameter, which is the Windows Eventlog’s full name.
thor.exe -a Eventlog –n "Microsoft-Windows-Sysmon/Operational"
You can get the full name of a Windows Eventlog by right clicking the Eventlog in Windows
Event Viewer and selecting "Properties".
Windows Eventlog 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.
thor.exe -a Security -a System

9.7 MFT Analysis (--mft)
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 more 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)
Table 3 - MFT Options

10 Configuration Files
10.1 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.
10.1.1 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.
10.1.2 Apply Custom Scan Templates

The following command line provides a custom scan template named mythor.yml.
thor.exe -t mythor.yml
10.1.3 Example Templates

The default config thor.yml in the ./config folder has the following content
# 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
Listing 3 - Content of THOR's Default Config 'thor.yml'
resume: true
cpulimit: 40
intense: true
max_file_size: 7500000
syslog:
- foo.nextron
- bar.nextron:514:TCP
Listing 4 - Content of Config File ‘mythor.yml'

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.
Screenshot 10 - Lookup command line parameter long forms using –help
10.2 Maximum File Size

The default maximum file size for deeper investigations (hash calculation, YARA scanning) is
12 MB and preset in the config file “./config/thor.yml”. The maximum file size for the
“intense” scan mode is 30 MB.
You can adjust the values in the “thor.yml”. This file does not get overwritten by an update.
Special scan features like the EVTX or Memory Dump scan ignore these limits.
10.2.1 Chunk Size in DeepDive

The chunk size in DeepDive module is set to the maximum file size value. Remember that
DeepDive uses overlapping chunks of that 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

11 License Files
THOR processes the program folder and all sub folders in search for a valid license file with
a "*.lic" extension picks the first valid license he 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 system for which
you have generated licenses and just run the "thor.exe" executable.

12 Scan Modes
You can select between 6 different scan modes in THOR:
§ Default
We recommend using the default scan mode for all sweeping activity. Scans take
from 1 to 6 hours depending on the partition size and number of interesting files.
In default mode, THOR automatically choses "Soft" mode if the system has only
limited CPU and RAM resources.
There's a special "Lab Scanning" (--fsonly) method described in chapter 0 that
disables many limitations and allows to scan mounted images in a Lab scenario,
even with multiple THOR instances on a single Workstation.
§ Quick (--quick)
This mode is the fastest one and oriented on the "Pareto Principe", covering 80% of
the modules and check in 20% of the normal scan time. In "quick" mode, THOR skips
the "Eventlog" scan and reduces the "Filescan" to relevant directories. The scan
target selection is based on all our APT cases, public APT reports and typical
malware directories (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 19.1 Automatic Soft Mode):
§ Systems with only a single CPU core
§ Systems with less than 1024 MB of RAM
§ Lab Scan (--fsonly)
This mode scan only the filesystem and disable all other modules.
Also often used with flag -p
Example: ./thor64 --fsonly -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.
§ 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 short-cuts 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”1.
1
https://attack.mitre.org/techniques/T1099/

12.1 Scan Modes Overview
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.
12.1.1 Modules
Module Default Quick Soft Intense Domain Linux /
Controller macOS
File System Scan Enabled Reduced Enabled Enabled - Enabled
Registry Scan (Full Walk) Enabled Enabled Enabled Enabled - Disabled
Run Key Analysis Enabled Enabled Enabled Enabled - Disabled
SHIM Cache Scan Enabled Enabled Enabled Enabled - Disabled
Mutex Check Enabled Enabled Disabled Enabled - Disabled
Named Pipes Check Enabled Enabled Disabled Enabled - Disabled
DNS Cache Check Enabled Enabled Enabled Enabled - Enabled
Hotfix Check Enabled Disabled Enabled Enabled - Disabled
Hosts File Check Enabled Enabled Enabled Enabled - Enabled
Firewall Config Check Enabled Disabled Disabled Enabled - Disabled
Network Share Check Enabled Disabled Disabled Enabled - Disabled
Logged In Check Enabled Disabled Disabled Enabled Disabled Disabled
Process Check Enabled Enabled Enabled Enabled - Enabled
Service Check Enabled Enabled Enabled Enabled - Disabled
Autoruns Check Enabled Enabled Enabled Enabled - Enabled
Rootkit Check Enabled Enabled Enabled Enabled - Disabled
LSA Sessions Analysis Enabled Enabled Disabled Enabled - Disabled
User Account Check Enabled Enabled Enabled Enabled Disabled Disabled
User Profile Check Enabled Disabled Enabled Enabled Disabled Disabled
Network Sessions Check Enabled Enabled Disabled Enabled Disabled Disabled
Network Open Files Check Enabled Enabled Disabled Enabled Disabled Disabled
Scheduled Tasks Analysis Enabled Enabled Enabled Enabled - Disabled
WMI Startup Check Enabled Enabled Enabled Enabled - Disabled
At Entries Check Enabled Enabled Enabled Enabled - Disabled
MFT Analysis Disabled Disabled Disabled Enabled - Disabled
Eventlog Analysis Enabled Disabled Enabled Enabled - Disabled
Table 4 - THOR Scan Modules

12.1.2 Features
The following table gives an overview of several module features and their use in the
different scan modes.
Feature Parent Default Quick Soft Intense DC Linux /
macOS
Sigma Scan Eventlog Analysis / Disabled Disabled Disabled Enabled - Enabled
Log File Scanning
EXE Decompression File System Scan Enabled Enabled Disabled Enabled - Disabled
Archive Scan File System Scan Enabled Enabled Enabled Enabled - Enabled
Double Pulsar Check Rootkit Check Enabled Enabled Disabled Enabled - Disabled
Groups XML Analysis File System Scan Enabled Enabled Enabled Enabled - Enabled
Vulnerability Check File System Scan Enabled Enabled Enabled Enabled - Disabled
Web Server Dir Scan Process Check Enabled Disabled Enabled Enabled - Disabled
WMI Persistence File System Scan Enabled Enabled Disabled Enabled - Disabled
Registry Hive Scan File System Scan Enabled Enabled Disabled Enabled Dis- Enabled
abled
AmCache Analysis File System Scan Enabled Enabled Enabled Enabled - Enabled
Process Handle Process Check Enabled Enabled Enabled Enabled - Disabled
Check
Process Memory Process Check Enabled Enabled Disabled Enabled - Enabled
Check
Process Connections Process Check Enabled Enabled Enabled Enabled - Enabled
Check
Basic File Location File System Scan Enabled Enabled Enabled Enabled - Enabled
Checks
Windows Error Report File System Scan Enabled Enabled Enabled Enabled - Enabled
(WER)
Windows At Job File File System Scan Enabled Enabled Enabled Enabled - Enabled
Analysis
Evil Users Check User Account Enabled Enabled Enabled Enabled - Disabled
Check
EVTX File Scanning File System Scan Enabled Disabled Enabled Enabled - Enabled
Prefetch Library File System Scan Enabled Enabled Enabled Enabled - Enabled
Scanning
Memory Dump File System Scan Disabled Disabled Disabled Enabled - Enabled
DeepDive
Log File Scanning File System Scan Enabled Enabled Enabled Enabled - Enabled
(.log)
Event ID statistics Eventlog Analysis Enabled Disabled Disabled Enabled - Disabled
Suspicious Shellbag Registry Hive Scan Enabled Enabled Enabled Enabled - Enabled
Entries
Table 5 - THOR Scan Features

13 Evidence Collection
13.1 File Collection (Bifrost)
13.1.1 Bifrost v1 with Script-Based Server
The ./tools folder in the program directory contains a simple Python based file collection
server named Bifrost. The script is named bifrost-server.py.
You can run that script on any internal system with a Python script interpreter installed. By
default, it uses port 1400/tcp for incoming connections but you can use any port you like.
Usage is:
usage: bifrost-server.py [-h] [-d out-dir] [-i ip] [-p port]
Bifrost
optional arguments:
-h, --help show this help message and exit
-d out-dir Quarantine directory
-i ip IP address to bind to
-p port Port to bind to (tcp, default 1400)
You can run the server script with:

python ./bifrost-server.py
In order to send suspicious file to that server, you have to set some command line flags
when running THOR, e.g.
thor64.exe --bifrostServer myserver
A more complex statement setting a minimum score and custom port would look like this:
thor64.exe --bifrostServer myserver --bifrost-port 8080 --bifrostLevel 80
THOR will then try to submit all samples with score equal or higher than 80 to a Bifrost
service running on myserver port 8080/tcp.
13.1.2 Bifrost v2 with ASGARD

Bifrost v2 cannot be used standalone yet. The required API Key is set by ASGARD v2 during
initialization and is unknown to a THOR user.
You can activate the quarantine function via Bifrost v2 when creating a single or group scan
via the ASGARD management interface.
Figure 2 - Configure Quarantine via Bifrost in New Scan Dialogue

Figure 3 - Collected File Evidence in ASGARD v2
13.2 Process Dumps (--dump-procs)

Since THOR version 10.5 it supports process dumping to backup volatile malware
information.
THOR on Windows creates a process dump of any process that is considered malicious.
Maliciousness is determined as anything that triggers a warning or an alert.
Activate process memory dumping with “--dump-procs”.
This process dump can then be analyzed with standard tools later on to examine the found
malware.
Figure 4 - Process dumping
Figure 5 - Process dumps on disk

To prevent flooding the disk fully in case many dumps are created, old dumps of a process
are overwritten if a new dump is generated. Also, THOR will not generate dumps by default if
less than 5 GB disk space is available. This can be overwritten to always or never dump
malicious processes.
Also note that THOR will never dump lsass.exe to prevent these dumps from potentially
being used to extract passwords by any attackers.

14 Scoring System
The scoring system is one of THOR's most prominent features. Both YARA signatures and
filename IOCs contain a score field. The score is an integer value that can be negative to
reduce the score on elements that are prone to false positives.
Only YARA rules and Filename IOCs support a user defined score. But since you are able to
write YARA rules for almost every module, the scoring system is very flexible. (see chapter
22.4.3 for details)
The total score of an element determines the level/severity of the resulting log message.
Score Level Condition
40 Notice
60 Warning
100 Alert At least 1 sub score of 75 or higher
Table 6 - Element total scores and the resulting message level (in default)
14.1 Scoring per Signature Type Match

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 2nd field of the CSV (e.g. "\\evil.exe;80")
Keyword IOC2 match "warning" level messages, see 14.3 "Default Scores"
C2 IOC match "warning" and "alert" level massages, see 14.3 "Default Scores"
Table 7 - Score definition by signature type
14.2 Accumulated Score by Module

Module Cumulated Scoring
Score
FileScan Yes Score is a sum of the scores of all "REASON"s (YARA
Archive Scan matches, filename IOCs, other anomalies)
DeepDive Note 1 Only positive scores are shown by default
Prefetch Note 2 Only the top 2 reasons are shown by default
WER (use –allreasons to show all positive
scores)
All Other Modules No Individual score of each signature match (YARA, filename
IOC, keywords, C2)
Note 1 This means that multiple matches for a
single element are possible
Table 8 - Accumulation of scores by module
2
Applies to old keyword IOC defined in text file divided by new line (new method allows to define "keyword"
signatures as YARA rule and set your score in the meta data of the YARA rule)

14.3 Default Scores
If no score is set in an "alert" or "warning" message, THOR automatically appends a score
that corresponds to the message level: Warning = 70, Alert = 100.
14.4 Exception: High total score with low sub scores

"Alerts" on file system elements are only generated if one of the sub scores is at least 75.
Before that change, multiple low scoring reasons had led to a score higher 100 and caused
an "Alert" level message although not a single hard match was included in the "Reasons". A
wrong extension, e.g. ".txt" for an executable, which is often used by employees to hand
executables through tight mail filters, and a suspicious location, e.g.
"C:\Temp\funprog.txt" caused an "Alert" level message.
Since version 8.27.2, one of the sub scores that pushes the total score over 100 has to be 75
or higher. (internally calculated as "alert_level - 25" because the user can adjust the alert
level via the "--alert" parameter)
14.5 Exception: Filename IOC Checks

The "Filename IOC Check" is a sub check of the "String Check", which is applied to many
elements, like Eventlog messages or Registry keys.
The function "checkString()" receives a string as input and returns possible matches.
The string is checked in multiple sub-checks against different signature lists. The most
important sub-checks are "checkKeyword()" and "checkFilename()".
While the "checkKeyword()" sub-check returns each individual match, the "checkFilename()"
sub check accumulates the score of all matches and returns a single total score. It is
possible that many different filename signatures have matched on that string but only one
match with a total score is reported. This is an exception to the behavior set out in chapter
14.2 that states that only the "FileScan" module accumulates scores.
14.5.1 Filename IOC Matching in String Check Example

Imagine the following filename IOC signatures:
\\nmap.exe;70
\\bin\\nmap.exe;-30
and the following Keyword signature:

nmap.exe
The "checkString()" function receives the following string from the Eventlog scan module
(here: a Sysmon Eventlog entry):
Process Create:
UtcTime: 2018-01-10 10:22:25.277
ProcessGuid: {c1b49677-e961-5a55-0000-0010bbc80702}
ProcessId: 3912
Image: C:\Program Files\Nmap\bin\nmap.exe
CommandLine: nmap.exe
CurrentDirectory: C:\Windows\system32\
User: PROMETHEUS\user1

LogonGuid: {c1b49677-1d72-5a53-0000-0020d4232500}
LogonId: 0x2523d4
TerminalSessionId: 1
IntegrityLevel: High
Hashes:
SHA1=F5DC12D658402900A2B01AF2F018D113619B96B8,MD5=9FEA051A9585F2A303D55745B4BF63A
A
ParentProcessGuid: {c1b49677-1d74-5a53-0000-001057452500}
ParentProcessId: 1036
ParentImage: C:\Windows\explorer.exe
ParentCommandLine: C:\Windows\Explorer.EXE
The "checkString()" function would create two messages: 1 "warning" for the keyword
signature and 1 "notice" of the filename IOC signatures.
The keyword IOC matches in the "checkKeyword()" sub-check and "checkString()" returns a
match, that generates a "Warning" level message that automatically receives a score of 75
(see chapter 14.3).
The filename IOCs would both match on the string in the "checkFilename()" sub-check and
both score would be summed up to a total score of 40 (70 + (-30) = 40), which would
generate a "Notice".

15 Update
You can download updates for THOR with “thor-util”. Running “thor-util.exe --help”
shows two options that look very similar: “upgrade” (program and signature update) and
“update” (signature update only).
For more information on “thor-util” see the separate “THOR_Util_Manual.pdf”.
15.1 Upgrade Locations

The following servers are used as update mirrors and should be accessible via HTTPS:
update1.nextron-systems.com
update2.nextron-systems.com
15.2 Update Server Information

You can get information on the available update packages on this site:
https://update1.nextron-systems.com/info.php

16 Syslog
16.1 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.
thor.exe -s syslog1.server.net -s arsight.server.net:514:CEF
The definition consists of 4 elements:

System : Port : Type : Protocol
Listing 1: THOR Syslog Target Definition Format
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:

§ 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:
-s 10.0.0.4:2514
Sending Syslog to a receiving server using an SSL/TLS encrypted TCP connection:

-s 10.0.0.4:6514:DEFAULT:TCPTLS
When changing the protocol from UDP to TCP, all preceding fields have to be set:
-s 10.0.0.4:514:DEFAULT:TCP
You can define as many targets as you like.
16.2 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.:
thor.exe -s syslog1.server.local:514:CEF
All details on the definition of syslog target can be found in chapter 0.

17 Action on Match
The action command allows you define a command that runs whenever THOR encounters a
file during “Filescan” that has a certain total score or higher. The default score that triggers
the action command (if set) is 40.
The most popular use case for the action command is sample collection.
17.1 Action Flags

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)
Table 9 – Action Flags
17.2 Command Line Use

A typical use would be e.g. to copy a sample to a network share:
copy %filepath% \\server\share1
To instruct THOR to run this command, you need

thor64.exe --action_command copy --action_args %filepath% --action_args
\\server\share1
17.3 Use in a Config File

The ./config folder contains a template for a config file that uses the action commands.
# Action to perform if file has been detected with a score more than the defined
'action_level'
# You may use all environment variables that are available on the system, i.e.
%COMPUTERNAME%.
# Further available meta vars are:
# %score% = Score
# %file% = Filename without extension
# %filename% = Basename
# %filepath% = Full path
# %ext% = Extension without dot
# %md5% = MD5 value
# %date% = Detection time stamp
action_level: 35
action_command: "copy"
action_args:
- "%filepath%"
- "\\\\VBOXSVR\\Downloads\\restore_files\\%COMPUTERNAME%_%md5%_%file%_%ext%_%date%"
Listing 5 - Content of 'tmpl-action.yml'

18 THOR DB
This simple SQLite database is created by default in the "%ProgramData%\thor" directory as
"thor.db". You can deactivate THOR DB and all its features by using the "--nothordb" option.
It stores persistent information over several scan runs:
§ Scan State Information
This information is used to resume scan runs where they were stopped
§ Delta Comparison
This detection feature allows to compare the result of a former module check with
the current results and indicate suspicious changes between scan runs
The THOR DB related command line options are:
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 ‘thor.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.
Table 10 - THOR DB scan options
18.1 Scan Resume

THOR tries resume a scan when you set the --resume parameter. Since THOR version 10.5
the resume state doesn’t get tracked by default due to its significant performance
implications. If you want to be able to resume a scan, you have to start scans with the --
resume flag. If you start a scan and a previous resume state is present, than THOR is going
to resume the interrupted scan.
It will only resume the previous scan if
1. you have started the scan with --resume
2. the argument list is exactly the same as in the first scan attempt
3. you haven’t used the flag --nothordb
4. scan state information is still available
(could have been cleared by running THOR a second time without the --resume
parameter)
You can always clear the resume state and discard an old state by running thor.exe once
without using the --resume parameter.

18.2 Delta Comparison
The delta comparison feature allows comparing former scan results on a system with the
current results indicating changes in system configurations and system components.
Currently, the following scan modules feature the delta comparison check:
§ Autoruns
THOR compares the output of the Autoruns module with the output of the last scan
run. The Autoruns does not only check "Autorun" locations but also elements like
browser plugins, drivers, LSA providers, WMI objects and scheduled tasks.
§ Services
The comparison detects new service entries and reports them.
§ Hosts
New or changed entries in the "hosts" file could indicate system manipulations by
attackers to block certain security function or intercept connections.

19 Resource Control
THOR’s internal resource control feature puts the system’s stability and the responsiveness
of running services first.
Resource control is active by default. You can deactivate it using --norescontrol.
Be advised that due to Resource Control, the THOR scan may terminate its completion. The
scan gets terminated under the following conditions:
1. If the available physical memory drops below 60MB
2. If more than 60 MB of log data have been written (disk / syslog)
In this case, THOR switches in the "reduced-logging" mode in which it only transmits
"Notices, Warnings and Alerts" and after another 4 MB of log data THOR terminates
itself in order to prevent log flooding due to a high number of false positives
If the scan constantly terminates you should check what causes the performance issues or
choose times with less workload (e.g. weekends, night). To debug such states, you can
check the last warning that THOR generates before exiting the scan. It includes the top
memory consumers that could have caused the memory exhaustion.
Screenshot 11 - Resource Control Scan Termination
Warning: Deactivating Resource Control on systems with exhausted resources can put the
system’s stability at risk.
19.1 Automatic Soft Mode

Soft mode is automatically activated on systems with low hardware resources.
One of the following conditions activates soft mode:
§ Less than 2 CPU cores
§ Less than 1024 MB of RAM
In Soft mode several checks and features that could risk system’s stability or could provoke
an Antivirus or HIDS to intervene with the scanner are disabled. See chapter “12 Scan
Modes” for a complete overview.

20 Exclude Elements
20.1 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 but it will still perform some basic
checks on file names in 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 exclusions 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.
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 \\HPSM\\log\\
the partition
Every file with the extension .nsf \.nsf$
THOR custom signatures \\THOR\\custom\-signatures\\
20.2 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“)
Windows PowerShell Windows PowerShell
Microsoft-Windows-Windows Windows Defender
Defender/Operational
20.3 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.
HKEY_LOCAL_MACHINE\Software\ ⏎ Symantec Endpoint ⏎

Wow6432Node\Symantec\Symantec ⏎ Protection\AV\Exclusions
Endpoint Protection\AV\Exclusions
20.4 False Positives

The false positive filters work like the directory/file excludes. A regular expression is applied
to the full content of the "MESSAGE:" value.
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)".
20.5 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:
thor.exe --fsonly -p C:\TestDir
20.6 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.

21 Threat Intel Receivers
THOR provides several threat intel receiver scripts.
Those receivers can be used to query private and public feeds and store the retrieved IOCs in
a simple CSV format that THOR understands. Those files are stored in the "./custom-
signatures/iocs" folder and get initialized during startup. The receiver scripts are stored
in a subfolder called "./threatintel".
The Threat Intel Receivers write different IOC types in dedicated files. C2 server addresses
and host names are stored in files named "source-c2-iocs.txt". C2 server definitions
received from a MISP instance would be stored into "misp-c2-iocs.txt". THOR uses the
"c2" string in the file name to identify which type of indicators the file contains. The keyword
"hash" is used for hash indicators, the keyword "filename" for file name indicators.
Receive Threat Intel IOCs from MISP
This means that you can also store your own threat intel IOCs into files in that folder with the
correct tag in the file name and they will get initialized by THOR during startup.
THOR currently contains with two threat intel receivers:
§ get-misp-iocs.py
MISP Receiver - retrieves Hash, C2, File Name IOCs and Yara signatures from an
arbitrary MISP instance (local or CIRCL.lu community)
§ get-otx-iocs.py
OTX Receiver - retrieves Hash, C2 and File Name IOCs from AlienVault’s Open Threat
Exchange platform
THOR initializing the threat intel IOC files from MISP and OTX
Current requirements to use the Threat Intel Receivers:

§ Python interpreter
§ PyMISP module
https://github.com/CIRCL/PyMISP
§ OTX Python SDK module
https://github.com/AlienVault-Labs/OTX-Python-SDK
§ Direct Internet access (no proxy support)
The free IOC scanner LOKI repository contains compiled Windows executables of these
threat intel scripts but those scripts store the files in the folder "../signature-
base/iocs/" instead of "../custom-signatures". We do not include two compiled threat
intel downloaders due to their big file size of more than 5MB.
Each script is provided as is in an Open Source form. Feel free to extend or change adjust
them to your needs. The support for these scripts is limited.

22 Custom Signatures
There are several ways to integrate your own IOCs and rule sets in THOR.
22.1 Simple IOCs

With version 7.8.0 we’ve introduced the support for custom simple IOCs, which are basically
CSV files with comment lines. Currently there are two template files that can be filled with
your own IOC data. The simple IOC config files can be found in the folder "./custom-
signatures/iocs".
22.1.1 Hashes
The file "custom-evil-hashes.txt" allows you to define hashes of malware or hack tools
that THOR should report at least as a "Warning". In order to ensure that, every matching
object will receive a score of 75.
You can add MD5, SHA1 or SHA256 hashes and add a comment, which is separated by a
semicolon.
22.1.2 Trusted Hashes

The custom trusted hashes files follow the same format as the hash IOC files. The only
difference is that they require the keyword “trusted-hash” or “trusted-hashes” in the file
name, so that THOR know how to initialize the respective content of that file.
See chapter 22.1.5 for more information.
22.1.3 File Name Characteristics

In the "filename-characteristics.txt" you are able to define IOCs based on file name and path
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.

File "filename-characteristics.txt"
For example, if you know that administrators in your organization use "PsExec.exe" in a
folder "Sysinternals" and any other location should be reported as suspicious you could
define the following statements:
\\PsExec\.exe;60
\\SysInternals\\PsExec\.exe;-60
This following example represents the 3rd 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|wins
xs|WinSxS|SysWOW64|SysWow64|syswow64|SYSNATIVE|Sysnative|dllcache|WINXP|WINDOWS|i386|%sys
tem32%)\\
You could also score down directories with many false positives reported as "Notices" or
"Warnings" like this:

\\directory_with_many_false_positives\\;-30
22.1.4 Keyword IOCs

The keyword based IOC files contain plain strings that are matched against the output lines
of almost every module (e.g. Eventlog entries, log lines, Autoruns elements, local user
names, at jobs etc.)
Every line is treated as case-sensitive string. The comment above each block is used as
reference in the THOR log entries.
Keyword IOC Example
22.1.5 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 “startswith”, “endswith” and “equals”.
You can decide if you want to set a scope by using a prefix “Global\” or e.g.
“BaseNamedObjects\”. If you decide to use none, your expression will be applied to any
scope.
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
Figure 6 - Example: my-malicious-handles.txt
22.1.6 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.
Optionally, a score can be added as 2nd field. If none is present, it defaults to 100.
MyMaliciousNamedPipe;Malicious pipe used by known RAT

MyInteresting[a-z]+Pipe;50;Interesting pipe we have seen in new malware
Figure 7 - Example: my-malicious-pipes.txt
22.1.7 Initialization Based on Strings in File Names

THOR checks the contents of the "./custom-signatures" folder and processes every file in
this folder based on string tags in the file names.
For example, every file that contains the string "c2" will be initialized as Simple IOC
indicators file with C2 server information. Internally we use the regex ‘[_\W]c2[_\W]’ to
detect the tag, so "mysource-c2-iocs.txt", "mysource_c2_iocs.txt" and
"dec15_batch1_c2_indicators.txt" would be detected correctly, whereas on the
contrary "c2-iocs.txt" or "myc2iocs.txt" would not.
The following tags are currently supported:
§ "c2" or "domains" for C2 server IOCs like IPs and host names
§ "filename" or "filenames" for file name IOCs
§ "hash" or "hashes" for MD5, SHA1, SHA256 hash IOCs
§ "keyword" or "keywords" for string based keywords
§ "trusted-hash" or "trusted-hashes" or "falsepositive-hash" or
"falsepositive-hashes" for hashes that you trust (also expects CSV format in the
form “hash;comment” like the hash IOCs)
§ "handles" for malicious Mutex, Event or Named Pipe values
See chapter 0 for more information on files that can be used in the "./custom-
signatures" folder. IOC files must have the extensions ".txt". Only ".dat" extensions are
treated differently as THOR expects ".dat" files to be encrypted (with “thor-util” – see
separate manual)
Keyword in File Example
Name
c2 misp_c2__domains_iocs.txt
filename Case_UX22_filename_iocs.txt
filenames Malicious_filenames_unitX.txt
hash op_aura_hash_iocs.cfg
hashes int_misp_hashes.txt
keyword keywords-incident-3389.txt
keywords Incident-22-keyword.cfg
trusted-hash my-trusted-hashes.dat (encrypted)
handles Operation-fallout-handles.txt
Table 11 - Keywords in Simple IOC file names and corresponding initialization
22.2 Sigma
Sigma is a generic rule format for detections on log data. Sigma is for log data, as 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 on Github.
To activate Sigma scanning, you have to use the --sigma command line option or perform a
--intense scan. Sigma scanning is not activated by default. This behavior may change in
the future.
Custom Sigma rules have to be placed in the ./custom-signatures/sigma folder and can
be encrypted using “THOR Util”. You can find details on the encryption in the separate
“THOR_Util_Manual.pdf”.
Screenshot 12 - Example Sigma match on Windows Eventlog
22.2.1 Sigma Examples

Perform a scan with the Sigma rules on the different local Windows Eventlogs (-a Eventlog)
thor64.exe -a Eventlog --sigma
Perform a scan with the Sigma rules on logs of Linux systems (-a LogScan) only
thor64 -a Filesystem -p /var/log –sigma
22.3 STIX
THOR can read and apply IOCs provided in STIXv2 JSON files by placing them with the
“.json” file extension in the “./custom-signatures/stix” folder.
Screenshot 13 – STIXv2 Initialization during startup
The following observables are supported.

§ file:name with = != LIKE and MATCHES
§ file:parent_directory_ref.path with = != LIKE and MATCHES
§ file:hashes.sha-256 / file:hashes.sha256 with = and !=
§ file:hashes.sha-1 / file:hashes.sha1 with = and !=
§ file:hashes.md-5 / file:hashes.md5 with = and !=

§ file:size with < <= > >= = !=
§ file:created with < <= > >= = !=
§ file:modified with < <= > >= = !=
§ file:accessed with < <= > >= = !=
§ win-registry-key:key with = != LIKE and MATCHES
§ win-registry-key:values.name with = != LIKE and MATCHES
§ win-registry-key:values.data with = != LIKE and MATCHES
§ win-registry-key:values.modified_time with < <= > >= = !=
22.3.1 STIX v1
STIX version 1 is not supported.
22.3.2 Encrypted STIX IOC Files

THOR Util supports the encryption of the “.json” STIX files to encrypted files with the
“.jsos” file extension. See the “THOR_Util_Manual.pdf” for more information on the
“encrypt” feature.

22.4 YARA
THOR offers an interface to include own rules based on the YARA format. Just place valid
rule files with the Extension ".yar" in the custom signature folder ("/custom-
signatures/yara").
Yara rules are widely used in THOR.
There are basically two custom YARA rule types that you can define in THOR:
1. Generic Rules
2. Specific Rules
22.4.1 Generic YARA Rules

The "Generic" rules are standard YARA rules that are applied to payloads of files and
memory. Just place any file with "*.yar" extension in the "./custom-signatures/yara"
folder.
Generic 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. It extends the standard conditions by THOR specific extensions (see
below).
§ Process Memory
THOR also uses the process memory scan function of the Yara python module. It
carefully selects only processes with a working set memory size of a certain limit
that can be altered by the "--maxpmemsize" 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.
(Warning Level)
22.4.2 Specific YARA Rules

The specific YARA rules contain certain keywords in their filename in order to select them for
application in certain modules only.
§ Registry Keys
Keyword: ‘registry’
Rules are applied to a whole key and all of its values. This means that you can
combine several key values in a single YARA rule. (see chapter 22.5.3 for details)
§ Log Files
Keyword: ‘log’
Rules are applied to each log line (or a bigger set of log lines if the aggregator
features is active).
§ Process Memory
Keyword: 'process' or ‘memory’
Rules are applied to process memory only

§ All String Checks
Keyword: 'keyword'
Rules are applied to all string checks in many different modules
22.4.3 YARA Rule Application

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
Table 12 - Generic YARA Rule Application
The following table shows in which modules the Specific YARA rules are applied to content.
Keyword in File Name Applied in Module Examples
registry Registry incident-feb17-registry.yar
log Eventlog, Logscan general-log-strings.yar
process ProcessCheck (only on process memory) case-a23-process-rules.yar
keyword Mutex, Named Pipes, Eventlog, MFT, misp-3345-keyword-extract.yar
ProcessCheck (on all process handles),
ProcessHandles, ServiceCheck, AtJobs,
LogScan, AmCache, SHIMCache, Registry
Table 13 - Specific YARA Rule Application
You can restrict the Specific YARA rules to certain modules to avoid false positives. Please
check chapter 22.5.5 for details.
Also see the link section in chapter 23 for a YARA rule exporter script that extracts YARA
Keyword rules automatically from a MISP threat feed.
22.4.4 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 developer's website (https://code.google.com/p/yara-
project/).

The options for the Yara tool are listed below. The most useful options are "-r" to recursively
scan a path and "-s" to show all matching strings.
The best practice steps to generate a custom rule are:
1. Extract information from the malware sample
(Strings, Byte Code, MD5 …)
2. Create a new Yara rule file. It is important to:
a. Define a unique rule name – duplicates lead to severe errors
b. Give a description that you want to see when the signature matches
c. Define an appropriate score (optional but useful in THOR, default is 50)
3. Check your rule by scanning the malware with the "Yara Binary" from the project’s
website to verify a positive match
4. 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
5. 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.bsk-consulting.de/2015/02/16/write-simple-sound-yara-rules/
https://www.bsk-consulting.de/2015/10/17/how-to-write-simple-but-sound-yara-rules-part-2/
22.4.5 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.
rule APT1_WEBC2_TABLE {
meta:
author = "AlienVault Labs"
strings:
$msg1 = "Fail To Execute The Command" wide ascii
$msg2 = "Execute The Command Successfully" wide ascii
$gif1 = /\w+\.gif/
$gif2 = "GIF89" wide ascii
condition:
3 of them
}
Listing 3: AlientVault APT1 Rule

Copying your rule to the signatures directory may cause THOR to fail during rule initialization
as shown in the following screenshot. In the current state of development, the error trace
back is not as verbose as desired but gives the reason why the rule compiler failed. 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.
22.4.6 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
22.5 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".
rule simple_demo_rule_1 {
meta:
description = "Demo Rule"
strings:
$a1 = "EICAR-STANDARD-ANTIVIRUS-TEST-FILE"
condition:
$a1
}
Listing 6 - Simple Yara Rule
The following listing shows a more complex rule that includes a lot of keywords used in
typical rules included in the rule set.

rule complex_demo_rule_1 {
meta:
strings:
$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
}
Listing 7 - Complex Yara Rule
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.
22.5.1 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.
rule demo_rule_score {
meta:
score = 80
strings:
$a2 = "honkers" fullword
condition:
1 of them
}
Listing 8 – Yara Rule with THOR specific attribute "score"

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
chapter 22.5.2.
22.5.2 Additional Attributes

THOR allows using certain external variables in you rules. They are passed to the "match"
function and evaluated during matching.
The external variables are:
§ ‘filename’ - single file name like "cmd.exe"
§ ‘filepath’ - file path without file name like "C:\temp"
§ ‘extension’ - file extension with a leading ".", lower case like ".exe"
§ ‘filetype’ - type of the file based on the magic header signatures (for a list of valid file
types see: "./signatures/file-type-signatures.cfg") like "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)
The "filesize" value is a build-in variable and therefore not mentioned as THOR specific
external variables.
rule demo_rule_enhanced_attribute_1 {
meta:
description = "Demo Rule - Eicar"
strings:
condition:
$a1 and filename matches /eicar.com/
}
Listing 9 – Yara Rule with THOR External Variable
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.

rule demo_rule_enhanced_attribute_2 {
meta:
author = "F.Roth"
strings:
condition:
$a1 and filename matches /eicar\.(com|dll|exe)/ and filesize < 100
}
Listing 10 – Yara Rule with more complex THOR Enhanced Attributes
The following YARA rule show 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.
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/
}
Listing 11 – Real Life Yara Rule
22.5.3 THOR YARA Rules for Registry Detection

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

Figure 8 - Composed strings from registry key/value pairs
The composed format is:

KEYPATH;KEY;VALUE\n
KEYPATH;KEY;VALUE\n
KEYPATH;KEY;VALUE\n
This means that you can write a Yara rule that looks like this (remember to escape all back
slashes):
rule Registry_DarkComet {
meta:
description = "DarkComet Registry Keys"
strings:
$a1 = "LEGACY_MY_DRIVERLINKNAME_TEST;NextInstance"
$a2 = "CurrentVersion\\Run;MicroUpdate"
condition:
1 of them
}
Listing 12 – Registry Yara Rule Example
Since version 7.25.5 THOR is even able to apply these rules to non-DWORD registry values.
This means that e.g. a REG_BINARY value contains an executable as in the following
example, you can write a YARA rule to detect this binary value in Registry as shown below.
REG_BINARY = 4d 5a 00 00 00 01 .. ..
Corresponding YARA rule:
rule registry_binary_exe {
meta:
description = "Detects executables in Registry values"
strings:
$a1 = "Path;Value;4D5A00000001"
condition:
1 of them
}
Listing 13 - YARA rule to detect executables in Registry values
The letters in the expression have to be all uppercase. Remember that you have to use the
keyword ‘registry’ in the file name that is placed in the "./custom-signatures/yara"
folder in order to initialize the YARA rule file as registry rule set. (e.g.
"registry_exe_in_value.yar")
22.5.3.1 Important:
Please notice that strings like HKEY_LOCAL_MACHINE, HKLM, HKCU,
HKEY_CURRENT_CONFIG are not used in the strings 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. The strings for the YARA matching look like:

\SOFTWARE\Microsoft\GPUPipeline;InstallLocation;Test
22.5.4 Restrict Yara Rule Matches in Generic Rules

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.
rule Malware_in_memory {
meta:
author = "Florian Roth"
description = " Think Tank Campaign"
type = "memory"
strings:
$s1 = "evilstring-inmemory-only"
condition:
1 of them
}
Listing 14 – Apply rule in-memory only
rule Malware_in_fileobject {
meta:
description = "Think Tank Campaign"
type = "file"
strings:
$s1 = "evilstring-infile-only"
condition:
1 of them
}
Listing 15 – Apply rule on file objects only
You can also decide if a rule should not match in "DeepDive" module by setting the
"nodeepdive" attribute to "1".
rule Malware_avoid_DeepDive {
meta:
description = "Think Tank Campaign"
nodeepdive = 1
strings:
$s1 = "evilstring-not-deepdive"
condition:
1 of them
}
Listing 16 – Avoid DeepDive application

22.5.5 Restrict Yara Rule Matches in Specific Rules
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.
rule Malicious_Mutex_Evtx {
meta:
description = "Detects malicious mutex EVTX"
limit = "Mutex"
strings:
$s1 = "_evtx_"
condition:
1 of them
}
Listing 17 – Limits detection to the "Mutex" module
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)
22.5.6 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.
rule FalsePositive_AVSig1 {
meta:
description = "Match on McAfee Signature Files"
falsepositive = 1
score = 50
strings:
$s1 = "%%%McAfee-Signature%%%"
condition:
1 of them
}
Listing 18 – False Positive Rule

22.6 Encrypt Custom Signatures
You can encrypt the YARA signatures and IOC files with the help of THOR-util’s “encrypt”
feature.
See the separate “THOR_util_Manual.pdf” for more details.

23 Analysis and Info
23.1 Log Analysis Manual
The ./docs folder of the THOR program directory contains a manual named
THOR_LogAnalysis.pdf on how to process the events generated by THOR.
23.2 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
Figure 9 - Rule Info Page

23.3 Rule List Output
By using the --print-signatures flag, you can get a list of all initialized YARA and Sigma
rules.
Figure 10 - Rule List Output

24 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 to use. The public key must be
an RSA key of 1024, 2048 or 4096 bit size in PEM format.
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.
thor-util decrypt file.txt

25 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
Sigma Project
https://github.com/Neo23x0/sigma

THOR Manual

Uploaded by

Copyright:

Available Formats

THOR Manual

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

THOR Manual

Uploaded by

Copyright:

Available Formats

THOR MANUAL

THOR Manual Page 2 of 76

THOR Manual Page 3 of 76

THOR Manual Page 4 of 76

THOR Manual Page 5 of 76

THOR Manual Page 6 of 76

THOR Coverage and Comparison to Antivirus and Intrusion Detection

The key features are:

THOR Manual Page 7 of 76

THOR Manual Page 8 of 76

THOR Manual Page 9 of 76

4.2 Add Tools (optional)

4.3 Verify Signatures (optional)

THOR Manual Page 10 of 76

5.2 Controlled Way

THOR Manual Page 11 of 76

6.1 Network Share (Windows)

Figure 1 – Deployment via Network Share

6.1.1 Place THOR on a Network Share

THOR Manual Page 12 of 76

6.1.2 Create a Scheduled Task via GPO

6.1.3 Create a Scheduled Task via PsExec

6.1.4 Start THOR on the Remote System via WMIC

THOR Manual Page 13 of 76

Screenshot 1 - ASGARD Management Center

THOR Manual Page 14 of 76

6.3 Ansible (Linux)

6.3.3 Execute Thor using Ansible

THOR Manual Page 15 of 76

6.3.4 Inventory File

6.3.5 Ansible Playbook Template

Listing 1 - Ansible Playbook

THOR Manual Page 16 of 76

6.3.7 Adjust Thor’s Command Line Parameters

6.4 THOR Remote (New)

THOR Manual Page 17 of 76

Listing 2 - THOR remote host definition in targets.yml file

THOR Manual Page 18 of 76

6.4.4.1 System Error 5 occurred – Access Denied

6.4.4.2 Running THOR from a Network Share

6.5 Distribute to Offline Networks / Field Offices

6.6 System Load Considerations

THOR Manual Page 19 of 76

7.1 Most Relevant Parameters

THOR Manual Page 20 of 76

7.2.1 Logging to a Network Share

7.2.2 Logging to Syslog Server

7.2.3 Logging to a Local Log File and Import

7.3 Often Used Parameters

thor.exe --fsonly -p I:\mounted_image\disk1

7.3.2 Deactivate all file output - Syslog only

7.3.3 Save the result files to a different directory

THOR Manual Page 21 of 76

7.3.6 Intense Scan and DeepDive on a Mounted Image as Drive Z

7.3.7 Throttled THOR Run (static throttling value)

7.3.8 Scan Multiple Paths

(non-existent directories will be automatically skipped)

7.3.9 Scan All Hard Drives (Windows Only)

7.4 Scan Output

7.4.1 Log File Output (.txt)