Short Tutorial: How to Create a YARA Rule for a Compromised Certificate

Working in incident response or malware analysis, you may have come across compromised and sometimes revoked certificates used to sign malware of different types. Often threat groups use stolen certificates to sign their malware.

I’d like to show you an easy way to create a YARA rule for such a certificate. We will look at a sample that has been marked as malware by many Antivirus engines on Virustotal and the “Details” tab shows a revoked certificate. That’s a good indicator for a compromised certificate that has been and sometimes is still used by threat groups to sign their binaries.

Sample: ee5340b2391fa7f8d6e22b32dcd48f8bfc1951c35491a1e2b4bb4ab2fcbd5cd4

Let’s look at the details. I recommend creating a YARA that uses the “pe” module of YARA and integrate the Serial Number and the Issuer of the certificate to create an unambiguous rule.

rule MAL_Compromised_Cert_Nov18_1 {
   meta:
      description = "Detects a compromised certificate of CORP 8 LIMITED - identified in November 2018"
      date = "2018-11-01"
      hash = "ee5340b2391fa7f8d6e22b32dcd48f8bfc1951c35491a1e2b4bb4ab2fcbd5cd4"
   condition:
      uint16(0) == 0x5a4d and
      for any i in (0 .. pe.number_of_signatures) : (
         pe.signatures[i].issuer contains "COMODO RSA Code Signing CA" and
         pe.signatures[i].serial == "4c:75:75:69:2c:2d:06:51:03:1a:77:ab:49:22:4c:cc"
      )
}

As you can see, you need to copy two strings from Virustotals web page:

Copy the CA name and use it for the “.issue” condition as well as the serial number, which you use for the “.serial” condition. Make sure that you changed the casing to lower-case as YARA does not expect and understand uppercase characters in the serial field.

Virustotal Intelligence users can use the following hunting rule to detect new uploaded malicious samples with revoked certificates:

rule Compromised_Certificate {
  condition:
    // New files, detected by more than 30 engines and revoked certificate
   new_file and positives > 30 and tags contains "revoked-cert"
}

Important Update Process Changes

As we have announced in May, the old “thor-upgrade.exe” is already out-of-support and the old update servers accessed by “thor-upgrade.exe” will be decommissioned at the end of October.

The new all-round utility “thor-util.exe” now supports all of the features provided by the old “thor-upgrade.exe” including NTLM Authentication with corporate proxy servers.

You can use “thor-util.exe upgrade –help” to see all options of the “upgrade” feature.

Also note that “thor-util” has an “encrypt” feature that allows you to encrypt custom signature files and the “report” feature that creates HTML reports from plain text log files. 

The only valid update servers that should be accessible to get updates from November onward are:

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

The “thor-util” utility is part of the THOR and SPARK packages and can also be downloaded from the Customer Portal in the “Downloads” section.

If you are a customer and don’t have access to the Customer Portal yet, please contact us or the respective partner.

Feature: SPARK Sample Quarantine via Bifrost

The new SPARK v1.14.16 supports the sample quarantine protocol named Bifrost.

With Bifrost you’re able to send suspicious samples that THOR or SPARK  detect on endpoints directly to a central server for analysis.

A Bifrost server is shipped in form of a Python script with THOR and SPARK. (./tools sub folder)
You can also activate the Bifrost server on our ASGARD platform.

All samples that have a score higher than the given limit are dropped into a given directory and are available for further post-processing – e.g. drop them into a sandbox or static analysis.

New Feature: THOR-util and SPARK-Core-util Signature Encryption

The new THOR-util version 1.2.4 supports the encryption of your custom signatures so that you can deploy your own IOC files and YARA rules in an encrypted form.

We use a public key in the utilities to encrypt the files for our scanners so that admins, Antivirus engines and attackers won’t be able to read the contents of the files.

 

The feature is also available in SPARK Core, our free scanner.

After encryption, place the encrypted IOC files in the “./custom-signatures” directory and the encrypted YARA rules in the “./custom-signatures/yara” directory.

The use of the function is simple. Just point it to a file, a list of files or use wildcards to select a set of files for encryption. The extension of the output file depends on the extension of the input file.

  • IOC Files: .txt > .dat
  • YARA Rules: .yar > .yas
  • Sigma Rules: .yml > .yms

Examples:

thor-util.exe encrypt case44.yar
thor-util.exe encrypt case44-hashes.txt
thor-util.exe encrypt case44-hashes.txt case44.yar
thor-util.exe encrypt case44.*

You can use the “upgrade” feature in both tools to get the newest version of the utility.

thor-util upgrade

ASGARD IOC Management

The upcoming ASGARD version 1.5 comes with a IOC management section in which you can manage your own set of IOCs in text files, YARA and Sigma rules.

You can then select each of the folders when creating a new scan run with THOR or SPARK. Selecting one of these folders will not include the sub folders.

You can schedule and run scans with different IOC, Sigma and YARA rule sets. You can review the included custom signatures in the scan details. 

The following features are not yet implemented in v1.5 but on the roadmap for ASGARD v1.6:

  • Signature verification
  • Exclude the standard rule set (shipped with THOR and SPARK)

THOR Version 8.49.0 Changes

There are a few relevant changes in the upcoming THOR version 8.49.0 that we would like to announce.

Interpreter and Module Upgrades

The integrated Python interpreter will be upgraded to Version 2.7.15. We have also upgraded several modules. All our tests showed no signs of problems even with the oldest Windows version like Windows 2003 Server. (officially unsupported)

If you encounter any issues, please let us know.

4th Generation License Format Support

THOR 8.49.0 supports the newest license format which allows us to:

  • set a start date for the period of validity
  • enable or disable certain modules and features in THOR and SPARK
    (e.g. we could license a SPARK version that only scans endpoint logs with Sigma rules)

THOR-util Report Generation

The new included THOR-util version 1.2 allows to generate HTML reports from scan log files. It can also generate reports for a directory that contains THOR or SPARK scan logs (up to 50 per HTML report). We’ve discussed this feature in detail in a previous blog post.

Noresume Becomes the New Default

The Scan Resume feature has caused many problems during incident response engagements in the past. The feature activates a journal in THOR DB that tracks the state of the scan and resumes the scan automatically if it was interrupted by a user or terminated due to a system shutdown. This feature seemed to be helpful but actually caused some problems.

THOR logs are created in “write” (w) mode, not in “append” (a) mode. When an administrator started THOR on a system, terminated the scan and then restarted it shortly after, the first part of the local log file was overwritten by the second scan. Sometimes a scan was interrupted on a system due to different reasons. When an administrator received the order to start a new scan on that system, the scan resumed the last scan and the log file and report contained only info of the resumed part of the scan.

We therefore decided to not resume scans by default. If you still want to maintain the old behaviour, please use the new “–resume” parameter. The old “–noresume” parameter is still valid but has no effect and is marked “obsolete” in the help.

Analysis Cockpit Web Session

We’ve just recently published a web session that gives an overview on our whole product portfolio and describes the features of our Analysis Cockpit in detail. (18 minutes, English language)

The main features of the Analysis Cockpit are:

  • THOR / SPARK Log Baselining
  • Automatic case creation based on similarities of the events
  • Filtered Forwarding of Logs to a SIEM system

SPARK uses Sigma Rules in Eventlog Scan

Sigma is a rule format for threat detection in log files. It is for log data what “Snort rules” are for network traffic or “YARA signatures” are for file data. It is easy to write and read. Writing a Sigma rule is a matter of minutes.

On the right you can see a simple Sigma rule that checks the “System” eventlog for traces of password dumper activity. The detection section contains 1+ identifiers (selection, keywords, quarkspwdump) that can be defined freely by the rule author. These selectors are used in the condition to build the rule.

It also contains a description, references, possible false positives and a level.

Analysts use Sigma to generate search queries for their SIEM or log management solution. The Sigma repo contains a converter that allows to convert the generic rules to ElasticSearch, Splunk, QRadar, Logpoint, Windows Defender ATP (WDATP) and ArcSight.

Wouldn’t it be great if you could apply Sigma rules on the endpoint?

Well, the upcoming version 1.14 of SPARK, which will be released at the end of July,  does that. It applies Sigma rules to the local Eventlog. This way you’re able to apply searches that you have once defined for your SIEM to the local Eventlogs.

This way you are able “query” the standalone systems that are not connected to your SIEM and uncover otherwise common blind spots in your environment.

 

We ship the current rule set, which is part of the public Sigma repository and contains more than 200 rules with our SPARK program package in an encrypted form. (*.yms)

You can add your own Sigma rules to the “./custom-signatures/sigma/” folder in the SPARK program directory.

To activate Sigma scanning, use the new “–sigma” parameter.

Currently only SPARK supports this feature and there are no plans to implement this in THOR as well.

The feature is currently free for all customers but may become a premium feature that has to be licensed separately by the end of the year depending on the customer’s plan. 

See the comparison table for a complete overview on all features.

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. 

YARA Rule Creation Crackme

I’ve collected some interesting samples for an internal YARA rule creation training session with our interns. With this blog post, I’ll also share 3 new premium feed YARA rules by pushing them to the Open Source signature-base repo.

What are the the preliminary conditions for the rule creation?

  • We don’t want to to spend more than 20 minutes for a single rule.
  • We use string extraction, hex editors and yarGen
  • We also use public resources like Google (yes), malware.one

Requirements:

  • You need a Virusbay account to download the samples

So, get ready. We process the following 3 cases.

Turla Agent-BTZ

  • Great for yarGen string extraction
  • Especially check for variations of strings (in PE header) that are highly specific
  • Use google to check strings

Sample

PLEAD Downloader

  • yarGen will not produce good results in this case
  • Try to compare the samples in order to find specific strings that appear in all of them

Sample 1

Sample 2

Sample 3

Sample 4

TYPEFRAME (Hidden Cobra)

  • Authors missed some specific strings

Sample

Solution

Don’t check the solution before you’ve created your own rules.

Agent.BTZ YARA rule

PLEAD YARA rule

TYPEFRAME YARA rule

Remember, there is no single correct solution to this task. Your rules may be better than mine. If that’s the case, please share them with me 😄.