THOR-Util with HTML Report Generation

The new version of “thor-util” (used with THOR/SPARK) / “spark-core-util” (used with SPARK Core) support a feature that allows a user to convert any scanner log file into a convenient report. 

  • Convert THOR / SPARK / SPARK Core scan logs into HTML reports
  • Convert a single text log file into an HTML report
  • Convert multiple log files (50 max.) in a directory into a single HTML report 
  • Provide a file with filters to suppress false positives in the reports
  • Even LOKI logs can be converted (no support)
  • Hash values linked to Virustotal searches
  • IP values linked to VirusTotal searches
  • Header sections linked to elements via ankers

You can access this feature in the upcoming enterprise products (THOR 8.47.2 and SPARK 1.13) and the free product SPARK Core (SPARK Core 1.13). 

The following screenshot shows a typical text log file. It can be processed in log analysis solutions but it is difficult to read for an analyst. Most analysts search these log files for “(Alert|Warning):” or use grep to get the most relevant messages.

Our tools “thor-util” and “spark-core-util” will help you with this task. 

Generate an HTML report for a single log file

thor-util report --logfile PROMETHEUS_thor.log

Generate an HTML report for multiple log files

thor-util report --logdir ./logs

You can also provide a file with regular expressions that are applied during log parsing as filters to suppress false positives in the reports. 

The new tools will be in all productive packages at the end of this week. 

SPARK Core – Free IOC and YARA Scanning

It is done! Our new free scanner SPARK Core has been released.

After weeks of planning, development and testing, we’re proud to provide the community with a new and powerful multi-platform scanner.

SPARK Core is a reduced version of our successful scanner SPARK.

The main differences are the Open Source signature base and the reduced set of modules. It uses LOKI’s open source “signature-base” instead of the big signature set that is used in THOR and SPARK. It also lacks some of the modules, like the SHIM cache, Registry, Eventlog and DeepDive modules.

This overview explains how SPARK Core fits in our current scanner portfolio:

Some key points:

  • Free scanner for Windows, Linux and macOS
  • Precompiled and encrypted open source signature set
  • Update utility (spark-core-util) to download tested versions with signature updates
  • Documentation
  • Custom IOCs and signatures (just add them to the ./custom-signatures/ folder)
  • Different output formats: text log, SYSLOG (udp/tcp/tcp+tls), JSON to file, JSON via Syslog
  • Scan throttling to limit the CPU usage

All we ask for is a SPARK Core Newsletter subscription, which is a requirement for the automatic license renewal. Each subscriber receives a personal licenses file that is valid for 1 year and allows to run SPARK Core on as many systems as he wishes.

Support is not guaranteed but we provide the possibility to submit issues via our github page.

More information and download can be found on the product page.

We hope that you can use SPARK Core to catch some bad guys.

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.

The Right Package for Every Mission

We offer license packs for the following scenarios:

  • Incident Response Cases
  • Compromise Assessments (enterprise wide / single system)
  • Digital Forensics Engagements

The license packs are the perfect solution for:

  • Incident Response Teams
  • Security Service Providers
  • CERTs / CSIRTs
  • Digital Forensics Specialists
  • SOC Teams

Customer Portal

After purchasing one or more license packs, we create an account in our customer portal in which you can issue a license right when you need it. It also has a “Downloads” section in which you find the scanner software, guides and signature information.

Customer Portal

Example

For example, when you purchase 3 “Incident Response” license packs, you’ll get 3 full and unrestricted enterprise licenses of THOR and SPARK, each of them with a validity of 30 days from the issue date.

You also receive 15 host-based licenses with a validity of 5 days each which you can issue and use for all types of testing and lab scanning.

You can use THOR for Windows and SPARK for Linux and OSX system scans. Both scanners contain our huge signature database and allow you to integrate your own IOCs and YARA signatures in an unencrypted or encrypted form.

Contact

If you can’t find your use case covered by one of our license packs, please don’t hesitate to contact us. Boost your detection capabilities and ask for a quote or request a trial today.

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.