THOR Util Replaces THOR-Upgrade

We are currently upgrading our update infrastructure in many different ways.

We have added 2 new dedicated update servers – update1 (Karlsruhe, Germany) and update2 (Lenexa, USA). The old update locations will still be supported for a few months but have to be regarded as obsolete.

As a customer, please make sure to allow the following update servers in your proxy / firewall:

  • update1.nextron-systems.com (443/tcp)
  • update2.nextron-systems.com (443/tcp)

In this regard, our old utility called “thor-upgrade.exe” will be out-of-support by the end of July 2018.Please make sure to use the “THOR util” for all update tasks.

Advantages:

  • Supports all download types (THOR, SPARK for Windows, Linux, macOS)
  • Verifies Download via RSA signature
  • Runs on all platforms (Windows, Linux, macOS)
  • Allows updates and the download of a full program packages with config files

Disadvantage:

  • No support for proxy NTLM authentication

It is already part of all download packs.

Since THOR v8.46.9 and SPARK v1.11 all binaries are signed with a 2048 bit RSA key. The signatures are integrated in the download packs as separate “*.sig” files.

The new version 1.1.6 of THOR util checks the signatures during the upgrade / download and interrupts the process if an invalid signature is found.

You can verify the signatures yourself, by using the the new “verify” function.

These changes make our updates more reliable and secure.

If you have any question, don’t hesitate to contact us via support@nextron-systems.com

ASGARD Management Center version 1.4

Release notification of the ASGARD Management Center version 1.4

We have release version 1.4 for ASGARD.

This version has major improvements in usability, flexibility, stability and performance.

  • Plan and run THOR and SPARK scans on up to 10.000 endpoints – with a single 1RU appliance
  • Plan and run THOR and SPARK scans on up to 5.000 endpoints – with a virtual appliance
  • Improved the user interface with more information from a single pane
  • Schedule start date/time for single and group scans
  • Define frequency rhythm of scheduled scans (hourly, daily, weekly, etc.)
  • We added our own MySQL database to better track asset data
  • Improved ASGARD logging
  • Improved the ASGARD extension for GRR (added log status and scan duration to ASGARD)
  • You can now download the Scan Log from Scan Control
  • Import / export function to and from your CMDB system
  • Added full macOS support (Darwin) for SPARK scans

If you would like to see the core functions in action, check out our demo video:

Plan and run THOR and SPARK scans

Set the frequency of your planned scans

Monitor your progress

Asset information

New Antivirus Event Analysis Cheat Sheet Version 1.2

Today we release a new version of our “Antivirus Event Analysis” Cheat Sheet that helps you with the analysis of Antivirus events by providing a clear decision matrix.

We’ve updated many of the sections, added new VirusTotal online analysis checks and brought it in a new format.

You can download the PDF version here.

Upcoming ASGARD Version 1.4

The new ASGARD version 1.4 will be released in the next days. It comes with some interesting new features and underlying changes that improve its flexibility, stability and performance.

  • Controls THOR and SPARK scans for up to 10.000 endpoints – all from a single 1U appliance
  • Scheduled start of single and group scans (cron jobs)
  • Added MySQL database for ASGARD, that stores GRR assets, flows, hunts and users
    (no more issues caused by GRR’s internal data storage)
  • Improved ASGARD logging
  • Improved ASGARD extension for GRR (log status and scan duration to ASGARD)
  • Scan Log Download in Scan Control
  • Full macOS support (darwin)

Customers can use the “Upgrade” functions in ASGARD’s management interface to get the newest ASGARD version.

Scheduler: Create New Scheduled Scan

ASGARD Logging: Full Audit Trail

Scan Log Download

Improved ASGARD Extension for GRR

macOS / OSX Support

THOR 8.44 features TLS Syslog Transmission & ZIP YARA Scanning

The new THOR version 8.44 comes with some interesting new features.

TLS/SSL Syslog Transmission

THOR version 8.44.0 supports the Syslog log transmission in an SSL/TLS encrypted form. Just set the value “TCPTLS” as protocol in the 4th position of the target definition.

thor.exe -s mysyslogserver:6514:SYSLOG:TCPTLS

The documentation has been updated accordingly.

TLS Syslog Log Transmission

ZIP YARA Scanning

Until today the ZIP file checks were limited to file name IOC or anomaly checks. The new version 8.44.2 supports the scanning of ZIP file contents with the YARA rule base. However, for the time being the ZIP YARA scanning has some limitations:

  1. The feature is limited to files which decompressed size does not exceed the defined maximum file size (default 4.5 Megabytes)
  2. The feature is limited to certain scan modes: –intense, –fsonly, –dropzone

If the feature proves to be stable, we will activate it in the default scan mode in a future minor release.

ZIP YARA Scanning

New THOR / SPARK License Packs

We have just recently released new, flexible and practice-oriented license packs for our scanners THOR and SPARK. These license packs will help you to get started as quickly as possible in case of an incident response, digital forensics engagement or compromise assessment.

Most packs include a short-term but unrestricted enterprise license that allows you to run THOR or SPARK on any end system within an organisation. (the default licensing includes only host-based licenses; unrestricted enterprise licenses are more expensive)

Each license pack is offered at an attractively low price.

(more…)

How to Write Sigma Rules

Sigma is an open standard for rules that allow you to describe searches on log data in generic form. These rules can be converted and applied to many log management or SIEM systems and can even be used with grep on the command line.

In this article I’d like to give you a brief practical introduction into the rule creation process. I’ll recommend some tools and draft a guide that helps you to write Sigma rules as quick and sound as possible.

1. Get the Repository

First download or clone our Sigma repository from Github.

It contains the rule base in the folder “./rules” and the Sigma rule compiler “./tools/sigmac”. We will use the existing rules as examples and create a new rule based on a similar existing one. We will then test that rule by using “sigmac”.

Sigma Github Repository

2. Copy and Edit YAML Files

My personal favorite editor for YAML is VSCode. It is free and runs on all major platforms. (alternatively you can use Atom with ‘language-yaml’ and ‘linter-js-yaml’ packages)

Visual Studio Code

I used the following extensions but I don’t know if they are still necessary. VSCode has improved a lot over the last 12 months and it is possible that it supports YAML highlighting and syntax checks by default now.

YAML Extensions for VSCode

We open the Sigma repository folder with “Open …” and see all existing rules.

Sigma Rules

3. Create a Sigma Rule

I selected an example in which we will create a Sigma rule from one of @JPCERT‘s findings in their awesome “Tool Analysis Result Sheet“.

We open the results for “Quarks PWDump“, a password dumper often used by Chinese threat groups. It creates temporary files that we want to detect in our SysInternals Sysmon log data. To collect the needed events we use Sysmon with @SwiftOnSecurity‘s Sysmon config file, Windows Event Forwarding or NXlog.

Quarks PWDump Analysis Results

So, what we do is to find a Sigma rule in the repository that we can use as a template for our new rule. We use the ‘search’ function to find a rule that looks for “File Creation” events (EventID 11) in Sysmon log data.

Sigma Example Rule

We find a rule that has a special format. It is a so-called “rule-collection“, which allows us to define a global section in the YAML file marked with “action: global” that will be applied to all other sections in that file during the search query generation process. This way you can define and create multiple search queries from a single YAML file.

In the case of our QuarksPwDump example we don’t need a rule collection, so we reduce the rule to a standard rule that contains a detection expression looking Sysmon Events with Event ID 11 and save it as “sysmon_quarkspw_filedump.yml” to a new file in the folder “./rules/windows/sysmon/”.

Simple Sysmon Sigma Rule

After that, we modify several fields of that rule:

  • We give the rule a correct “title” and “description”
  • We leave the status “experimental” to inform everyone that this is a new and untested rule
  • We add the correct reference to the source from which we derived that rule
  • We change the author of the rule
  • We set the level of that rule to one of “low”, “medium”, “high” or “critical”
  • We adjust the date (of last modification) and use the format %Y/%m%d (strftime)
  • We check if the log source is correct, which is important for the field mappings used by “sigmac”

New Sigma Rule Header

Before we create the new “detection” section, we review the analysis report in detail.

Details: QuarksPwDump Temporary Files

We add a string with wildcards that matches on the ‘TargetFileName’ field in the Sysmon events of type 11. That’s what the new rule looks like:

QuarksPwDump Sigma Rule

4. Test the Rules

We test our newly created rule with “sigmac”, which requires python3. It is located in the “./tools” folder. It features several targets for which we can create searches/configurations from our rules.

Currently supported targets (10.02.2018):

  • es-qs (Elastic Search Query Language)
  • kibana
  • xpack-watcher
  • logpoint
  • splunk
  • grep
  • fieldlist (only used to show all fields that require mapping in a config file)

Running “python3 sigmac -h” shows a help:

$ python3 sigmac -h
usage: sigmac [-h] [--recurse] [--filter FILTER]
              [--target {es-qs,kibana,xpack-watcher,logpoint,splunk,grep,fieldlist}]
              [--target-list] [--config CONFIG] [--output OUTPUT]
              [--backend-option BACKEND_OPTION] [--defer-abort]
              [--ignore-not-implemented] [--verbose] [--debug]
              [inputs [inputs ...]]

Convert Sigma rules into SIEM signatures.

positional arguments:
  inputs                Sigma input files

optional arguments:
  -h, --help            show this help message and exit
  --recurse, -r         Recurse into subdirectories (not yet implemented)
  --filter FILTER, -f FILTER
                        Define comma-separated filters that must match (AND-
                        linked) to rule to be processed. Valid filters:
                        level<=x, level>=x, level=x, status=y, logsource=z. x
                        is one of: low, medium, high, critical. y is one of:
                        experimental, testing, stable. z is a word appearing
                        in an arbitrary log source attribute. Multiple log
                        source specifications are AND linked.
  --target {es-qs,kibana,xpack-watcher,logpoint,splunk,grep,fieldlist}, -t {es-qs,kibana,xpack-watcher,logpoint,splunk,grep,fieldlist}
                        Output target format
  --target-list, -l     List available output target formats
  --config CONFIG, -c CONFIG
                        Configuration with field name and index mapping for
                        target environment (not yet implemented)
  --output OUTPUT, -o OUTPUT
                        Output file or filename prefix if multiple files are
                        generated (not yet implemented)
  --backend-option BACKEND_OPTION, -O BACKEND_OPTION
                        Options and switches that are passed to the backend
  --defer-abort, -d     Don't abort on parse or conversion errors, proceed
                        with next rule. The exit code from the last error is
                        returned
  --ignore-not-implemented, -I
                        Only return error codes for parse errors and ignore
                        errors for rules with not implemented features
  --verbose, -v         Be verbose
  --debug, -D           Debugging output

We test our new rule with “sigmac” and the target “splunk”.

$ python3 sigmac -t splunk ../rules/windows/sysmon/sysmon_quarkspw_filedump.yml
(EventID="11" TargetFileName="*\AppData\Local\Temp\SAM-*.dmp*")

Now the rule is ready for a pull request. Follow me or contact me on Twitter: @cyb3rops

Write YARA Rules to Detect Embedded EXE Files in OLE Objects

This is the first blog post published on our new website. If you followed my blog on www.bsk-consulting.de you should consider subscribing to the RSS feed of this blog or the “Nextron Systems Newsletter”.

This is one of the YARA related blog posts showcasing a special use case. Last year I noticed that I wrote many rules for hex encoded strings found in OLE objects embedded in MS Office documents and RTF files.

I did most of the encoding and decoding work on the command line or with the help of CyberChef, an online tool provided by GCHQ. I also thought about a new YARA keyword that would allow us to write rules without encoding the strings.

Today, rules contain strings in a hex encoded form. I usually add the decoded string as a comment.

$s1 = "68007400740070003a002f002f00" /* http:// */

Rules with the new keyword would look like this:

$s1 = "http://" wide hex

Neat, isn’t it? I already forwarded that feature request to Wesley Shields (@wxs) but it seems to be no low hanging fruit. I’ll keep you informed about this feature via Twitter.

A tweet by Kevin Beaumont reminded me of the work that I’ve done and while looking at the tool by Rich Warren. I thought that I should create a illustrative example of a more generic YARA rule that explains why the “hex” keyword would be very useful.

The tool creates weaponized RTF files with hex encoded payloads.

I derived some strings for a new rule from the decoded object.

/* Hex encoded strings */
/* This program cannot be run in DOS mode */
$a1 = "546869732070726f6772616d2063616e6e6f742062652072756e20696e20444f53206d6f6465" ascii
/* C:fakepath */
$a2 = "433a5c66616b65706174685c" ascii

To further improve the rule I went to my goodware directory and ran the following command to generate a list of the most frequent PE file headers in a hex encoded form.

neo$ find ./ -type f -name "*.exe" -exec xxd -ps -l 14 {} ; | sort | uniq -c | sort -k 1 | tail -10
4 4d5a87000300000020000000ffff
4 4d5aae010300000020000000ffff
4 4d5abf000300000020000000ffff
4 4d5add000300000020000000ffff
4 4d5aeb000300000020000000ffff
6 213c73796d6c696e6b3e2f757372
8 4d5a72010200000020001700ffff
88 4d5a40000100000006000000ffff
116 4d5a50000200000004000f00ffff
5852 4d5a90000300000004000000ffff

Then I used these hex encoded strings in a YARA rule that looks for these strings in the OLE objects of an RTF file.

rule MAL_RTF_Embedded_OLE_PE {
   meta:
      description = "Detects a suspicious string often used in PE files in a hex encoded object stream"
      author = "Florian Roth"
      reference = "https://github.com/rxwx/CVE-2018-0802/blob/master/packager_exec_CVE-2018-0802.py"
      date = "2018-01-22"
   strings:
      /* Hex encoded strings */
      /* This program cannot be run in DOS mode */
      $a1 = "546869732070726f6772616d2063616e6e6f742062652072756e20696e20444f53206d6f6465" ascii
      /* KERNEL32.dll */
      $a2 = "4b45524e454c33322e646c6c" ascii
      /* C:fakepath */
      $a3 = "433a5c66616b65706174685c" ascii
      /* DOS Magic Header */
      $m3 = "4d5a40000100000006000000ffff"
      $m2 = "4d5a50000200000004000f00ffff"
      $m1 = "4d5a90000300000004000000ffff"
   condition:
      uint32be(0) == 0x7B5C7274 /* RTF */
      and 1 of them
}

The first analysis of the coverage looks pretty good. I see only clear matches in munin‘s output.

The few questionable matches look fishy enough to release my rule.

If you have further ideas to improve the rule, ping me via Twitter.

Welcome to Our New Website

We welcome you to our new website and encourage you to review our ‘products’ and ‘services’ sections.

From now on we will publish news about our products, articles about incident response, YARA rules, detection methods, IOCs and other interesting topics on this blog page.