Using THOR Lite to scan for indicators of Lazarus activity related to the 3CX compromise

Using THOR Lite to scan for indicators of Lazarus activity related to the 3CX compromise

Mar 31, 2023 | Alert, APT, Nextron, THOR, THOR Lite, Tutorial, YARA

On March 29, 2023 CrowdStrike detected malicious activity, originating from a legitimate, signed binary called 3CXDesktopApp. The binary is part of a softphone system developed by 3CX.
The observed malicious activity consisted of beaconing to infrastructure controlled by the actors, leading to the deployment of second-stage payloads and in a few cases direct on-keyboard activity from the attackers.

You can find more information on the threat in the following articles by CrowdStrike, Volexity and Huntress Labs:

CrowdStrike Report

The first report on the activity linking it to LABYRINTH CHOLLIMA aka Lazarus group.

Volexity Article

This article by Volexity lists a lot of indicators and reports on the final stage in form of the stealer ICONIC

Huntress Labs Article

Huntress Labs report on the activity including process patterns, rules and IOCs

After the compromise became first known, we began our own investigation and in the following few hours released a number of detection rules to our public repositories.

While having the detection in place is a great start, often times it’s not an easy task to assess the situation and make sure that no system in the network is affected by the threat.

One way to leverage these rules and quickly scan your own environment for free, is using THOR Lite scanner.

Enter THOR Lite

THOR Lite is the reduced version of our compromise assessment scanner THOR. It uses YARA rules and Indicators of Compromise (IOC) like hash values and file names to detect malicious activity. 

In this technical blog article, we’ll explore how to levreage THOR Lite to scan end systems for signs of malicious activity related to the 3CX compromise.

We’ll also discuss the various types of indicators that THOR Lite can detect, walk through the process of setting up and configuring the tool, and provide tips for interpreting the scan results.

By the end of this article, you should have a solid understanding of how to use THOR Lite to run a compromise assessments within your network.

Download THOR Lite

Visit the product page, subscribe to the newsletter to get the program package and the license file.

(note: we offer a special license file to 3CX customers that enables an additional module from the full version to extend the detection coverage even more)

You can download this special license here: (expires 30.04.2023) 

Download 3cx.lic

Email content:

Getting Started

After you’ve downloaded the program package as a ZIP archive, extract it and place the license file (.lic) in the program folder.

Double click on the “thor64-lite.exe” to run it without any flags or open a Windows command line as an administrator and navigate to the folder where you’ve extracted the program package.

You should then see the scan window that closes automatically when the scan is complete. Usually scans take between 1-4 hours, but there are some ways to speed up the scan.

 

Flags to Consider

--nosoft --nolowprio

If you’re scanning virtual machines or systems that are under a constant high load by other processes, it could be helpful to use the “–nosoft” and “–nolowprio” flags to let THOR run with the same process priority as any other regular process.

--lookback 150 --global-lookback

If you’re interested in scanning recently created files and log entries. These flags instruct THOR to only scan elements created or changed within the last 150 days (why 150?). It would ignore any file or eventlog entry older than that and thus scan a much smaller set of elements.

--cpulimit 30

To minimize the impact for the end user working on a system while it is getting scanned, you can reduce the CPU usage of the scanner to e.g. 30% to avoid them taking notice of the scan by reducing the overall load and fan noise.

Recommended CommandLine Flags For The 3CX Use Case

If a normal scan takes too long, we recommend the following command line flags in order to reduce the scan duration by restricting the scan to the changes of the last 150 days:

thor64-lite.exe --nolowprio --lookback 150 --global-lookback

In order to reduce the CPU usage and make it as imperceptible as possible to the end user working on the scanned systems use the following command:

thor64-lite.exe --lookback 150 --global-lookback --cpulimit 35

Update the Signatures

We’re constantly working on enhancing and updating the signatures related to the 3CX compromise. Updates are to be expected over the weekend and next week. To make sure THOR always works with the newest set of signatures use the following command:

thor-lite-util.exe upgrade

Interpreting the Scan Results

During the scan you’ll see several messages in green and blue colours. Warning and alert messages use a yellow or red color. But don’t worry when you notice a message of that color. Remember that THOR is a scanner that highlights malicious and suspicious elements for review by an administrator or forensic analyst. Not everything shown as a “warning” message has to be a real threat.

After the scan finishes, users can find an HTML report in the program folder that lists all findings. 

We recommend searching the HTML report for the “3CX” keyword and only review matches with the specific IOCs and YARA rules related to this activity.

THOR Lite is able to detect various forensic artefacts:

  • The installer files
  • The malicious binaries
  • The loaded malware in-memory
  • Process connections to known C2 addresses
  • Traces of activity in local log files

We’re also offering a special license (3cx.lic) to 3CX and their customers that will activate a special feature called “Sigma Scanning” in THOR Lite instances. This allows them to apply the Sigma rules mentioned below (and 1600+ more) on the event logs of a scanned end system.

A match with one of these Sigma rules would look like this: 

You can download this special license here: (expires 30.04.2023) 

Download 3cx.lic

Continuous Compromise Assessment: Enhancing Detection Capabilities to Mitigate High-Profile Cyber Attacks

One more time, we are all taken aback by yet another sudden high-profile compromise. Just like the Sunburst or HAFNIUM Attack, the 3CX compromise arose out of nowhere, putting companies of all kinds across the globe at risk. We may later discover that some organizations were exploited for months before the 3CX compromise was ultimately made public.

But does it truly have to come as such a surprise to everyone? Looking back at the Hafnium attack, Nextron discovered that many organizations had been breached by various attack groups, all of whom appeared to have used the proxy shell/proxy logon weakness. All attackers who expanded their breach brought their own toolset for persistence and post-exploitation. Nothing new so far.

However, what if we could automatically detect an attacker’s toolkit after it has been deployed? In this case, we could efficiently detect these breaches long before day zero simply by identifying secondary tools that appear magically on a system. Let’s assume we scan our systems weekly, searching for all kinds of Indicators of Compromise, known attacker tools, or traces of their methods. Then, even without knowing that the 3CX compromise exists, we would most likely be able to detect attacks that make use of it within a week. This would give us a heads up before bad things even begin to happen, shocking everyone.

This is precisely Nextron’s “Continuous Compromise Assessment” approach. With our orchestration platform ASGARD, we can conduct recurrent and automated compromise assessments using our full-featured Scanner THOR. Our first and initial scan represents what we call the baseline. We would analyze all events from the first scan and, starting with the next week, focus on any deviations from this baseline. In such a scenario, we would detect breaches based on secondary toolsets from one week to another. While we still would not detect the 0-day itself, the secondary toolset would show up very prominently as a deviation from the baseline.

There is not much effort required to gain a considerable amount of additional detection capabilities.

Signatures 

The following listings show all the signatures we’ve made public and used in THOR Lite to detect malicious activity

YARA (public)

SIGMA (public)

Potential Compromised 3CXDesktopApp Beaconing Activity – Proxy
UUID: 3c4b3bbf-36b4-470c-b6cf-f07e8b1c7e26

Potential Compromised 3CXDesktopApp ICO C2 File Download
UUID: 76bc1601-9546-4b75-9419-06e0e8d10651

Potential Compromised 3CXDesktopApp Beaconing Activity – DNS
UUID: bd03a0dc-5d93-49eb-b2e8-2dfd268600f8

Potential Compromised 3CXDesktopApp Beaconing Activity – Netcon
UUID: 51eecf75-d069-43c7-9ea2-63f75499edd4

Potential Suspicious Child Process Of 3CXDesktopApp
UUID: 63f3605b-979f-48c2-b7cc-7f90523fed88

Malicious DLL Load By Compromised 3CXDesktopApp
UUID: d0b65ad3-e945-435e-a7a9-438e62dd48e9

Potential Compromised 3CXDesktopApp Execution
UUID: 93bbde78-dc86-4e73-9ffc-ff8a384ca89c

Potential Compromised 3CXDesktopApp Update Activity
UUID: e7581747-1e44-4d4b-85a6-0db0b4a00f2a

IOCs

C2 IOCs
c2-iocs.txt @ signature-base

Filename IOCs
filename-iocs.txt @ signature-base

Hash IOCs
hash-iocs.txt @ signature-base

Full THOR Version

Keep in mind that THOR Lite is only a demo version of our full scanner with more than 27 detection modules and more than 20,000 YARA rues compared to the 5 modules and 2,500 rules used in THOR Lite.

You can find a full feature comparison here and a blog post that explains the differences in more detail here. 

 

THOR 10 Legacy for Windows XP and Windows 2003

Dec 17, 2020 | Newsletter, THOR, YARA

We’ve been working on a legacy version of our scanner THOR 10 for a while and started our closed BETA, which is available to all current customers on special request.

The THOR legacy version does not include the following modules/features:

  • Module: Eventlog scanning
  • Feature: Deeper process analysis for injection, Doppelgaenging, hollowing etc. using PE-Sieve

THOR Legacy runs on:

  • Windows XP x86
  • Windows Server 2003 x86 / x64
  • Windows Vista x86 / x64
  • Windows Server 2008 x64

We offer only limited support for this version and don’t plan to release it for old Linux or macOS versions.

THOR 10 Legacy on Windows Server 2003

THOR 10 Legacy on Windows XP

Please contact us if you are interested in participating in the closed BETA. 

There’s a Thunderstorm Coming

Oct 1, 2020 | Newsletter, THOR, Thunderstorm, YARA

We are proud to announce a groundbreaking new scan mode named “Thunderstorm” that we’ve integrated into preview builds of the upcoming THOR version 10.6.

This mode of operation turns THOR into a RESTful web service that is able to process thousands of samples per minute sent from any device within the network.

Think of it as your ultra-fast on-premise scan service, wich is bundled with more than 13,000 hand-crafted YARA rules focusing on persistent threats and forensic artefacts.

Collect files and submit them for analysis from any operating system and any hardware platform. The possibilities are limitless.

With this blog post, we’d like to highlight some of these new possibilities.

Thunder rolls, lightning strikes & the hammer flies across the sky.
God of the weather,
chariot of the storm,
master of rain & torrents.
Son of the strength
of Mother Earth,
I ask you to grant me that strength for myself.

Norse Poem

What is THOR Thunderstorm?

A RESTful web service that receives samples and returns a scan result. It is feature-rich and very fast.

Use Cases

Use Case 1 – Remote File Collection

During forensic investigations, automated file collection (ESI) from one or multiple remote systems can be combined with THOR Thunderstorm to improve the forensic anylsis.

Alerts and warnings produced by THOR Thunderstorm highlight interesting elements in file data, registry hives, eventlog files and more.

Use Case 2 – ICS Networks

ICS networks are mission critical, requiring immediate and high-availability. The installation of an endpoint agent or running a portable scanner is often out of question.

With THOR Thunderstorm, you just have to collect and submit the files.

Use Case 3 – Out of Reach Devices

Since file collection is a lot easier than endpoint scanning, all you need is way to export the remote system’s files or directly send them to THOR Thunderstorm.

Imagine that you can collect and submit files from network devices, telephone systems or embedded devices.

Use Case 4 – Out of Reach Operating Systems

File collection scripts for many old or usually unsupported operating systems allow you to upload samples for analysis.

Select files based on size, age or type and schedule frequent upload tasks to analyze only new or modified files. 

Use Case 5 – S3 Bucket Scanning

We’ve been working with our partner Adolus to showcase a tuned version of AirBnb’s BinaryAlert in which the standard YARA analyzer has been replaced by THOR Thunderstorm.

By using it in a container that scales with the demand, you can process millions of files in a few minutes.

Flexibility

Most operating system provide tools to walk the file system and submit files via HTTP. The following examples are intentionally short and compact to inspire you with their simplicity. Think of all devices that you could analyze this way. No agent, no portable scanner, just simple file submission via HTTP.

Windows 10 Batch

This example shows a simple batch file that walks recursively over a given folder an submits all files. You could extend it to the whole disk and reduce the submission to certain file extensions (e.g. exe, bat, ps1, js).

Linux Web Server

This examples shows how easy it is to get all files in a web server root checked by THOR Thunderstorm just by using bash, find and curl.

 

Thunderstorm Components

The following slide lists the different components that can be used with THOR Thunderstorm. We provide a server installer script, collectors, a Python API client and update scripts. 

In addition to the Thunderstorm server we provide a set of simple sample collection tools called Thunderstorm Collectors, a Python-based API library with command line client and a set of helper scripts. 

Thunderstorm Collectors

The Thunderstorm Collector repository contains a Go based collector, precompiled for many different operating systems and architectures as well as collectors scripts (Batch, Bash, PowerShell).

We have pre-build collectors for Windows, Linux, macOS, AIX, Solaris on x86, x64, Arm, PowerPC, MIPS, RISC-V, Plan9, S390x (IBM Z) architectures.

These collectors allow you select files based on age, size and type for submission to a Thunderstorm server.

It is easy to set up a task like: 

“Select all files that have been created or modified within the last 24 hours and submit them to Thunderstorm for analysis. Run this task daily.”

Low CPU and RAM Usage

A collection task requires 0.75-2% of the CPU and 20MB memory. 

Any OS, Any Arch

Our collectors run on any operating system and processor architecture

High Speed

It allows ultra fast collection runs. (Our tests: Win 10, collect last 3 days, any type, full disk = 3 minutes run)

Thunderstorm API Client

We provide a Python module and Python based API client that supports multi-threaded submission to the THOR Thunderstorm service.

Modes of Operation

Service Mode

The service can be started in two scan modes:

  • Pure YARA
  • Full-Featured

Pure YARA

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

Full-Featured

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

More Features

Completely On Premise

THOR Thunderstorm can be installed on any internal system and runs as a service within your network

Sample Storage

Store suspicious or all transmitted samples with a reference to the source system to facilitate the deeper analysis

Forensic Modules

THOR Thunderstorm supports the analysis of different file types that get collected for forensic analysis purposes (e.g. EVTX files, Registry Hives)

Custom Signatures and IOCs

Add you own YARA signatures, Sigma rules, hash and filename IOCs and apply them to incoming samples

SIEM Integration

THOR Thunderstorm offers many ways to output information (Text, JSON, Syslog), which makes it easy to integrate the findings into your favorite SIEM system

Web GUI and API Documentation

The API documentation is embedded into the web service itself. You can even send requests right from the browser to test it live.

The Web GUI contains important information about the service like the signature set version, uptime, number of processed and queued samples and much more. 

It contains some graphs that help you to assess the actual server load and processing speed. 

It also contains links to the API documentation, the Python API library and the Thunderstorm Collectors for your convenience. 

 

On The Roadmap

The following tasks are on our roadmap for THOR Thunderstorm

  • Collector service that uses file system notifications to submit new files in real-time
  • Cortex Analyzer
  • ICAP Support (allows interfacing with Web Proxies)
  • File format support: PCAP, MFT
  • Recursive extraction of nested archives
  • Docker setup guide

Getting Started

Please use the “GET STARTED” button in the upper right corner or this link to request more information.

The release slide deck contains more detailed information on some of the mentioned aspects.

 

Spotlight: Threat Hunting YARA Rule Example

Apr 29, 2019 | VALHALLA, YARA

With this post, we would like to demonstration the YARA rule creation process for the so-called “threat hunting” rule category that we use in VALHALLA.

We noticed that many interested parties thought that “threat hunting” YARA rules are just rules with lower scores indicating a lower certainty. But in fact, they’re our most successful rules. The reason behind this is that they focus on anomalies as they appear in obfuscated samples and we’re not just talking about different forms of encoding.

Looking at the current table named “Successful YARA Rules in Set” on the VALHALLA start page, you’ll see many rule names that start with “SUSP_” for “suspicious”. 

These rules don’t match on a specific threat / malware but detect

  • certain methods (evasion, exploitation, side-loading, LOLBASs, LOLBINs)
  • casing anomalies (like cMd.ExE)
  • many forms of suspicious encodings
  • reversed strings
  • suspicious parameter combinations (e.g. certutil -decode)
  • suspicious packer / PE information combinations (like AutoIt executables from Microsoft)
  • and much more

So, these rules cannot be used for classification but they’re certainly priceless to detect new unknown threats.

Genesis of a New Threat Hunting YARA Rule

Processing different samples from various threat groups we often notice patterns in malicious code that looks as if it could be used for a generic “threat hunting” rule. 

The MuddyWater sample (8f0c6a09d1fca3d0002d3047733b50fe5153a33436d576c5020f0a21761242f1) contains the following base64 encoded block. 

While looking at this code block you can see repeating patterns even before decoding it just by scrolling over it. 

A good analysts asks himself “could this pattern serve as a signature?”.

To answer the question he decodes the base64 encoded chunk and gets a script with the following content:

He’ll notice a block of hex encoded values in a list. It seems that the obfuscation of the lower level (hex) can be detected in the upper layer (base64). So, by using a combination of these two forms of obfuscation, the attackers provide us a pretty specific pattern to detect a malicious – or rather – a highly suspicious code.

Next we try to figure out the exact usable patterns and put them to the test with different offsets. We use simple regular expressions in CyberChef to highlight matches. 

For our YARA rules, we don’t want to use regular expressions but byte patterns with place holders. Even for this task we can make use of CyberChef. 

The output can be used in a YARA rule that looks like this:

[code lang=”javascript”]
rule SUSP_Base64_Encoded_Hex_Encoded_Code {
meta:
author = “Florian Roth”
description = “Detects hex encoded code that has been base64 encoded”
date = “2019-04-29”
score = 65
reference = “Internal Research”
strings:
$x1 = { 78 34 4e ?? ?? 63 65 44 ?? ?? 58 48 67 }
$x2 = { 63 45 44 ?? ?? 58 48 67 ?? ?? ?? 78 34 4e }
condition:
1 of them
}
[/code]

To us it is not surprising that a test with the rule returned a lot of samples with low or no AV detection at all. We tested the hash list of the samples retrieved from a Virustotal Retrohunt with Munin and got the following results: 

As you can see, it’s not possible to verify the results based on the AV detection ratio. However, it’s a good sign that other threat hunting rules or even rules for known webshells from our ruleset match on these samples as well. We typically evaluate the false positive rate of this type of rules with the help of the file names (e.g. c99.php, virus.txt, *_codexgigas, Virusshare_*) and some spot checks.

You’ll also note that the rule matches many different content types – emails (.eml), executables, web shells, scripts. That’s one of the reasons why we love these rules so much.

The second screenshot contains some reassuring matches of the customized older version of the LaZagne credential dumper used by MuddyWater and apparently also encoded in the described form. (b8e97c96aa18916c15eea5c78d5a20b966aa45f332a5ea4d9ac2c87ebe5adff6)

You can find a full munin result file of the retrohunt matches here.

The YARA rule will be pushed to the signature-base that we provide for the community and will also be available in a streamlined form in the VALHALLA demo feed very soon. 

I hope you liked it.

For more information like this, please subscribe to the newsletter or follow us on twitter: @thor_scanner 

50 Shades of YARA

Jan 2, 2019 | YARA

A long time ago I’ve noticed that there is no single best YARA rule for a given sample, but different best solutions depending on the user’s requirements and use case. I noticed that I often create 2 to 3 YARA rules for a single sample that I process, while each of them serves a different purpose.

In this blog post, I’d like to describe the three most common rule types.

In the following example I’ll use the malware sample with hash 7415ac9d4dac5cb5051bc0e0abff69fbca4967c7 (VirusBay, Hybrid-Analysis)

While looking at the strings extracted by yarGen, you’ll notice that it contains a lot of interesting strings. In my past tutorials (1, 2, 3) I’ve always distinguished between “Highly Specific” and “Suspicious” strings (see Part 3 of the blog post series). Today I’d like to show you a more purpose oriented approach. 

The following screenshots shows what types of strings I see while looking at these strings:

The strings that are marked with yellow look very specific. I’d use them as “Highly Specific” strings ($x*) of which only a single one is required to trigger the rule: 1 of ($x*)

The strings marked green will be used in combination with other green strings. A reasonable set of these strings is required to trigger the rule: $u1 and 1 of ($f*)

The strings marked with red color could serve in a rule that tracks the C2 addresses used by this sample and the strings marked blue could be used for a generic detection of malicious samples that can be completely unrelated.

The different rule categories are:

  • Regular Rules: Detect a certain malware or malware family 
  • Threat Intel Tracking Rules: Detect specific indicators that relate to a certain actor
  • Method Detection Rules: Detect methods or anomalies 

The following table describes these three different types of rules and gives some string examples. 

Regular Rules

In the case of the “Regular Rules” I distinguish between two different flavors: 

  • Threat Detection Rules
  • Threat Hunting Rules

The difference between these flavors is based on a different level of strictness in the conditions and not on the different selection of strings. While a “threat detection” rule may require “6 of them”, a “threat hunting” rule may be satisfied with “3 of them”, accepting some false positives. 

The reason why someone distinguishes between “threat detection” and “threat hunting” rules is that the response to matches can be very different. Antivirus solutions that respond to matches with “delete” or “disinfect” reactions do not accept false positives and avoid false positives by any means.

In “threat hunting” use cases which include direct destructive reactions to signatures matches are rare. Typically analysts investigate such an event, classify and react to it manually. In “threat hunting” scenarios analysts try to avoid “false negatives” by all means. 

(Source: Chris Gerritz @gerritzc) 

Threat Intel Tracking

In threat intel, we can use YARA rules to track the activity of certain actors in cases in which there are certain characteristics or keywords that persist over longer periods and campaigns. 

A very convenient form of tracking without having access to the telemetry data of OS and AV vendors is offered in the form of YARA match notification services as provided by VirusTotal or ReversingLabs. 

Method Detection Rules

During the past year I focussed on the last rule type “Method Detection” whenever I had the opportunity as it allows me to provide very generic rules that produce amazing results with a minimum of false positives.

However, those rule matches lack a reference like a malware name or an adversary group that used the detected method in their samples. Here is an example with one of the few public YARA rules published in the “signature-base” repository:

Sample: fc18bc1c2891b18bfe644e93c60a2822ad367a697bebc8c527bc9f14dad61db5 

The comment tab shows a match with generic rule “SUSP_LNK_SuspiciousCommands” . No reference is given. The Antivirus detection ratio is low. 

You can find more matches with this rule on Virustotal using the search function – URL: https://www.virustotal.com/#/search/lnk 

Conclusion

These are the reasons why the analysis of a single sample often results in 2-3 different YARA rules.

Using this method the coverage is exceptionally good as the set of rules covers specific samples of the same family and the different malware families the use the same methods.

YARA Rule Sets and Rule Feed

Dec 21, 2018 | Newsletter, YARA

As previously announced our YARA rule packs and feeds will be available in March/April 2019. We’ve put a lot of effort into a internal system named “Mjolnir” that parses, normalizes, filters, tags and automatically modifies our rule base, which contains more than 9000 YARA rules. 

This system will now fill a database of tagged YARA rules – the basis of our new YARA services. 

The services will be divided into two categories:

  • YARA Rule Set
  • YARA Rule Feed

YARA Rule Set

The YARA rule set consist of more than 7000 YARA rules of different categories that are used in our scanners.

Some of our rules use extensions (external variables) that are only usable in our scanner products. These rules, experimental, third party and other classified rules will not be part of the purchasable rule set. 

YARA Rule Feed 

The YARA rule feed is a subscription on our rules. The feed always contains the rules of the last 90 days, which is between 250-400 YARA rules. 

Rule Samples

The quality of the rules in the rule set are comparable to the rules in our public “signature-base” repository. 

Some good examples for the different rule categories are:

Quality and Focus

The rules are tested against a data set of more than 350 TB of goodware. The goodware file repository consists of Windows OS files, several full Linux distributions and a big collection of commercial and free software. 

However, false positives are always possible. We do not recommend any destructive action on a signature match, like delete or blocking.

The main focus of our rules are:

  • Threat Hunting
  • Classification
  • Anomaly Detection
  • Compromise Assessment 

Subscribe to our Early Access Mailing List

Subscribe here

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

Nov 1, 2018 | YARA

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"
}

YARA Rule Creation Crackme

Jun 16, 2018 | YARA

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

Write YARA Rules to Detect Embedded EXE Files in OLE Objects

Jan 22, 2018 | LOKI, SPARK, THOR, YARA

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.

How to Write Simple but Sound Yara Rules – Part 3

Apr 15, 2016 | Tool, Tutorial, YARA

It has been a while since I wrote “How to Write Simple but Sound Yara Rules – Part 2“. Since then I changed my rule creation method to generate more versatile rules that can also be used for in-memory detection. Furthermore new features were added to yarGen and yarAnalyzer.

Binarly

The most important feature of the upcoming yarGen YARA Rule Generator release is the Binarly API integration.
Binarly is a “binary search engine” that can search arbitrary byte patterns through the contents of tens of millions of samples, instantly. It allows you to quickly get answers to questions like:

  • “What other files contain this code/string?”
  • “Can this code/string be found in clean applications or malware samples?”

Binary Search Engine - Binar.ly

Binary Search Engine – Binar.ly


This means that you can use Binarly to quickly verify the quality of your YARA strings.
Furthermore, Binarly has a YARA file search functionality, which you can use to scan their entire collection (currently at 7.5+ Million PE files, 3.5M clean – over 6TB) with your rule in a less than a minute.
For yarGen I integrated their API from https://github.com/binarlyhq/binarly-sdk.
In order to be able to use it you just need an API key that you can get for free if you contact them at contact@binar.ly. They are looking for researchers interested in testing the service. They limit the requests per day to 10,000 for free accounts – which is plenty. yarGen uses between 50 and 500 requests per sample during rule generation.
The following screenshot shows Binarly lookups in yarGen’s debugging mode. You can see that some of the strings produce a pretty high score. This score is added to the total score, which decides if a string gets included in the final YARA rule. The score generation process from the Binarly results is more complex than it might seem. For example, I had to score samples down that had 3000+ malware but also 1000 goodware matches. The goodware matches have higher weight than the malware matches. A string could have 15.000+ malware matches – if it also appears in 1000 goodware matches it does not serve as a good YARA rule string. I also handled cases in which small result sets lead to high Binarly scores.
Binarly Service Lookup in yarGen 0.16

Binarly Service Lookup in yarGen 0.16


Therefore the evaluation method that generates the score of each string has been further improved in the new version 0.16.0 of yarGen. Both the Binarly service and the new yarGen version are still ‘testing’. Do not upgrade your local yarGen installation to v0.16b in cases in which you rely on the rule generation process. Follow me and Daniel Radu (Binarly) on twitter to stay up-to-date.

Improved Rule Generation

But let’s talk about the improved rule generation process.
As described in my previous articles, I try to divide the list of strings generated by yarGen into two different groups:

  • Highly Specific Strings
    These strings include C2 server addresses, mutextes, PDB file names, tool/malware names (nbtscan.exe, iexp1orer.exe), tool outputs (e.g. keylog text output format), typos in common strings (e.g. “Micosoft Corporation”)
  • Suspicious Strings
    These strings look suspicious and uncommon but may appear in some exotic goodware, dictionary libraries or unknown software (e.g. ‘/logos.gif’, ‘&PassWord=’, ‘User-Agent: Mozilla’ > I’ve seen pigs fly – legitimate software contains the rarest strings)

In previous examples I always tended to combine these strings with magic header and file size. yarGen 0.15 and older versions generated those rules by default. The problem with these rules is that they do not detect the malware or tools to process memory.
Therefore I changed my rule generation process and adjusted yarGen to follow that example. As I said before, yarGen is not designed to generate perfect rules. Its main purpose is to generate raw rules that require the least effort to complete and could also work without further modification.
The following image shows how new rules are composed. They contain two main conditions, one for the file detection and one for the in-memory detection. I tried to copy the manual rule generation process as far as possible.

YARA Rule Creation

YARA rule composition (manual composition and yarGen v0.16)


The statement to detect files on disk combines the magic header, file size and only one of the highly specific strings OR a set of the suspicious strings.
For the in-memory detection I omit the magic header and file size. Highly specific strings and suspicious strings are combined with a logical AND.
The different statements (manual rule creation) look like this:

/* Detects File on Disk */
( uint16(0) == 0x5a4d and filesize < 100KB and ( 1 of ($x*) or 4 of ($s*) ) )
or
/* Detects Malware/Tool in Memory */
( 1 of ($x*) and 4 of ($s*) )

Here is an example of a rule produced by yarGen v0.16 (sample Unit 78020 - WininetMM.exe). I shows a 'raw' rule without further editing and the 'scores' included as comments:

rule WininetMM {
	meta:
		description = "Auto-generated rule - file WininetMM.exe"
		author = "YarGen Rule Generator"
		reference = "not set"
		date = "2016-04-15"
		hash1 = "bfec01b50d32f31b33dccef83e93c43532a884ec148f4229d40cbd9fdc88b1ab"
	strings:
		$x1 = ".?AVCWinnetSocket@@" fullword ascii /* PEStudio Blacklist: strings */ /* score: '40.00' (binarly: 30.0) */
		$x2 = "DATA_BEGIN:" fullword ascii /* PEStudio Blacklist: strings */ /* score: '36.89' (binarly: 27.89) */
		$x3 = "dMozilla/4.0 (compatible; MSIE 6.0;Windows NT 5.0; .NET CLR 1.1.4322)" fullword wide /* PEStudio Blacklist: strings */ /* score: '32.53' (binarly: 5.53) */
		$s4 = "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)" fullword wide /* PEStudio Blacklist: strings */ /* score: '20.00' (binarly: -7.0) */
		$s5 = "Accept-Encoding:gzip,deflate/r/n" fullword wide /* PEStudio Blacklist: strings */ /* score: '10.35' (binarly: -1.65) */
		$s6 = "/%d%s%d" fullword ascii /* score: '10.27' (binarly: 0.27) */
		$s7 = "%USERPROFILE%\\Application Data\\Mozilla\\Firefox\\Profiles" fullword wide /* PEStudio Blacklist: strings */ /* score: '9.36' (binarly: -13.64) */
		$s8 = "Content-Type:application/x-www-form-urlencoded/r/n" fullword wide /* PEStudio Blacklist: strings */ /* score: '5.61' (binarly: -9.39) */
		$s9 = ".?AVCMyTlntTrans@@" fullword ascii /* score: '5.00' */
	condition:
		( uint16(0) == 0x5a4d and filesize < 300KB and ( 1 of ($x*) and all of ($s*) ) ) or ( all of them )
}

You may ask "Why do the 'DATA_BEGINS:' and '.?AVCWinnetSocket@@' do have such high scores"? Well, that's the reason why analysts needs the support of big data:
Screen Shot 2016-04-15 at 12.51.40
Screen Shot 2016-04-15 at 12.52.01
I have to add that Binarly offers two query modes (fast/exact) of which yarGen uses the 'fast' mode. An analyst that doubts the produced results would use 'exact' query mode to verify the results manually. Please ask Daniel about the details.

yarAnalyzer - Inventory Generation

The new version of yarAnalyzer allows to generate an inventory of your YARA rule sets. This features comes in very handy in cases in which you have to handle a big set of rules. The '--inventory' option generates a CSV file that can be prettied up in MS Excel or Openoffice Calc.

YARA Rule Analyzer

yarAnalyzer Inventory

GDPR Cookie Consent with Real Cookie Banner