The Zero2Hero malware course concludes with Vitali Kremez explaining how to hunt malware families such as DoppelPaymer, BitPaymer & Dridex loader using YARA rules.

Whenever we discuss how to proactively hunt for malware of interest, whether it be crimeware or APT for threat intelligence purposes, YARA is the true swiss-army knife that makes the work of malware researchers and threat intelligence analysts that much easier. 

Malware developers work just like legitimate software developers, aiming to automate their work and reduce the time wasted on repetitive tasks wherever possible. That means they create and reuse code across their malware. This has a pay-off for malware hunters: we can learn how to create search rules to detect this kind of code reuse, reducing our workload, too! In this post, we will we learn how to write YARA rules for the following three crimeware variants belonging to the Dridex family:

• 1 – BitPaymer ransomware (known as “wp_encrypt”) part of the Everis extortion case
• 2 – DoppelPaymer ransomware leveraged in the PEMEX lockdown
• 3 – Dridex Loader (known as “ldr”) botnet ID “23005” 

In a nutshell, our goal is to hunt for malware software developer code leveraging YARA code reuse rules rather than relying on rules covering easily changeable strings.

One of the primary original purposes of YARA was to classify and identify malware samples. It is a rather simple Ruby-based language syntax used to describe various patterns.

The latest YARA version is 3.11.0. YARA is a signature-based tool with multiple command-line interfaces in various programming languages. In other words, it is similar to static anti-virus signatures used to detect malicious files.

The major functionality of YARA is to scan folders for files and buffers for patterns. Many tools rely on YARA such as yarashop, for example.

Some of the most common uses of YARA for our purposes is to scan, categorize and identify malware samples of interest based on code and string reuse.

The typical YARA syntax example is as follows:

import <module>

<rule type> rule <rule name> : <tags>
{
    meta:
        <name> = ""
        ...
    strings:
        $<string name> = <value> <modifiers>
        ...
    condition:
        <some condition>
}

Let’s practice writing YARA rules for Zero2Hero:

/*

We practice writing YARA rules for Zero2Hero

*/

import "pe"

rule zero2hero_course : best 
{
    meta:
        // Comment
        description = "This is an example rule to demonstrate typical syntax"
        reference = "https://www.sentinelone.com/lp/zero2hero"
        author = "@VK_Intel"
        tlp = "white"

    strings:
        $hero = "helloworld" xor wide
        $unique_function = { ?? ?? 8b fa 8b ?? 8b cf e8 ?? ?? ?? ?? 85 c0 75 ?? 81 ?? }

    condition:
        uint16(0) == 0x5A4D and pe.exports("CryptEncrypt") and  all of them
}

The additional modifiers can be as follows:

global: match before any subsequent rules 
private: build other rules 
none: match unless global is used

The tags are as follows:

strings: regular expression, text or hex
string modifiers: wide, ascii, xor, fullword, nocase

The conditions can be as follows:

Boolean expressions
Built-in, external, module variables, and functions

YARA String & Code Reuse Hunting 

There is a difference between writing YARA rules for malware hunting versus detection. In this part of the course, we aim to produce “looser” YARA rules for threat hunting purposes with the higher chance of capturing newer variants and false positives. In other contexts, you may want stricter YARA rules for a specific detection mechanism and malware strain.

By and large, efficient YARA rules are only as good as the data sources used to vet the YARA rules against. Anti-virus and malware researchers rely on large datasets of known good and known bad (and known random) samples to produce the most high-fidelity rules as it is often hard to predict YARA rule performance given the limited view of an individual researcher.

Some of the known bad and known good data sources for YARA rules performance include VirusTotal, Hybrid-Analysis, VirusBay, Malpedia, Microsoft, and VirusShare. Florian Roth’s tool yarGen includes some of the necessary string and opcode datasets for YARA performance checks as well. Another excellent tool for YARA rule management is the KLara tool developed by Kaspersky.

One of the major abilities of YARA rules that lead to successful and long-term hits is combining both string-based and code-based coverage. We believe that the key to efficient YARA rules depends on simple and clear rulesets utilizing both. I highly recommend watching Jay Rosenberg’s presentation from Confidence Conference 2019 entitled Utilizing YARA to Find Evolving Malware.

When creating code reuse YARA rules, we need to be aware of compilation flags, different compilers, and slightly altered code that can change the code and break the YARA rules. Consequently, we should wild card ?? certain instances such as used registers, which can change from one sample to another. 

For example, various instructions such as xor eax produce different opcodes depending on the xor’ed register. Skipping opcodes with “[1-2]” from one to two bytes is often necessary to survive compilers and make the YARA rules cover different environments.

The cyclical nature of the YARA rule development can be described in the following 7 steps:

1. Malware analysis 
2. Identification of malware string and code “uniqueness”
3. Prototype the YARA rule based on the findings
4. Test the YARA prototype rule across diverse malware family and clean and malware data sources
5. Deploy the rule to hunt for the samples
6. Review and monitor for possible false positives and/or false negatives outside of the testing phase and initial malware analysis
7. Repeat

Practical Crimeware Code Reuse: “Dridex” Malware Family

Dridex by far is one of the most complex and sophisticated pieces of malware on the crimeware landscape. 

The malware is also referred to as “Bugat” and “Cridex” by various researchers. The original Bugat malware dates back to 2010, which at some point rivaled the “Zeus” banking malware.

The development group behind it is responsible for the three malware variants, which are the subject of our YARA course:

• 1 – BitPaymer ransomware (known as “wp_encrypt”) part of the Everis extortion case
• 2 – DoppelPaymer ransomware leveraged in the PEMEX lockdown
• 3 – Dridex Loader (known as “ldr”) botnet ID “23005” 

The YARA rule for the overarching code reuse across the Dridex developer samples is based on the unique API hashing function used to resolve the Windows API calls. It is one of the most obvious unique features of this family.

The Dridex developer family can be described by this YARA rule as follows based on the API hashing function (as seen on the screenshot above):

rule dridex_family
{
    strings:
        $code = { 5? 5? 8b fa 8b ?? 8b cf e8 ?? ?? ?? ?? 85 c0 75 ?? 81 ?? ?? ?? ?? ?? 7? ?? }

    condition:
        $code
}

Always test the rules, for example, via command-line:

yara -s

Testing the YARA rule reveals multiple hits on the Dridex family across the folder.

Uniting Code Reuse & String Detection 

I. DoppelPaymer ransomware contains a peculiar string reused across samples we can add to the Dridex family code reuse. It copies the unicode string "setup runn" to eax via lstrcpyW API call.

The possible specific DoppelPaymer ransomware rule is as follows:

rule crime_win32_ransomware_doppelpaymer_1
{
    strings:
        $str1 = "Setup runn" wide
        $code = { 5? 5? 8b fa 8b ?? 8b cf e8 ?? ?? ?? ?? 85 c0 75 ?? 81 ?? ?? ?? ?? ?? 7? ??}

    condition:
        $code and $str1
}

II. BitPaymer ransomware contains the same referenced string across the samples aimed to act as anti-Windows Defender emulator checking the existence of the file "C:aaa_TouchMeNot_.txt", which is indicative of Windows Defender sandbox activity.

The possible specific BitPaymer ransomware rule is as follows:

rule crime_win32_ransomware_bitpaymer_1
{
    strings:
        $str1 = "C:aaa_TouchMeNot_.txt" wide
        $code = { 5? 5? 8b fa 8b ?? 8b cf e8 ?? ?? ?? ?? 85 c0 75 ?? 81 ?? ?? ?? ?? ?? 7? ??}

    condition:
        $code and $str1
}

III. Across the Dridex loader samples, this malware carries the same string "installed" called via OutputDebugStringW many times acting as anti-emulator. It is indicative of the Dridex loader.

The possible specific Dridex loader rule is as follows:

rule crime_win32_loader_dridex_1
{
    strings:
        $str1 = "installed" wide
        $code = { 5? 5? 8b fa 8b ?? 8b cf e8 ?? ?? ?? ?? 85 c0 75 ?? 81 ?? ?? ?? ?? ?? 7? ??}
    condition:
        $code and $str1
}

The final YARA rule, for example, covering both code and strings for the DoppelPaymer ransomware unpacked payload is as follows:

rule crime_win32_doppelpaymer_ransomware_1 
{
    meta:
        description = "Detects DoppelPaymer payload Nov 11 Signed"
        author = "@VK_Intel"
        reference = "https://twitter.com/VK_Intel/status/1193937831766429696"
        date = "2019-11-11"
        hash1 = "46254a390027a1708f6951f8af3da13d033dee9a71a4ee75f257087218676dd5"

    strings:
        $s1 = "Setup run" wide
        $hash_function = { 5? 5? 8b fa 8b ?? 8b cf e8 ?? ?? ?? ?? 85 c0 75 ?? 81 ?? ?? ?? ?? ?? 7? ??}

    condition:
        ( uint16(0) == 0x5a4d and
            filesize < 2500KB and
            ( all of them )
        )
}

Malware Samples

DoppelPaymer Ransomware (unpacked) SHA-256: 46254a390027a1708f6951f8af3da13d033dee9a71a4ee75f257087218676dd5

BitPaymer Ransomware (unpacked) SHA-256 78e180e5765aa7f4b89d6bcd9bcef1dd1e0d0261ad0f9c3ec6ab0635bf494eb3

Dridex Banker (unpacked) SHA-256 ce509469b80b97e857bcd80efffc448a8d6c63f33374a43e4f04f526278a2c41

Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

• Zero2Hero Previous: Here We GO: Crimeware Virus & APT Journey From “RobbinHood” to APT28
• Privilege Escalation | macOS Malware & The Path to Root Part 2
• The Quest for Visibility & Hunting Comes with an Unseen Opportunity Cost
• What is Mimikatz? (And Why Is It So Dangerous?)
• Meet the Client Workshop | What Can We Learn From A Security Executive?
• Ransomware Attacks: To Pay or Not To Pay? Let’s Discuss

Among security researchers and bug bounty hunters, obtaining unauthorized elevated privileges – privilege escalation – is widely held as the hackers holy grail; an achievement that can be paved with gold as bounty programs, private zero day hoarders and pwn2own-style competitions reward such exploits with handsome amounts of hard cash. As we saw in Part I, Apple’s regular product security updates are frequently littered with a variety of arbitrary code execution and privilege escalation vulnerabilities found by researchers both public and private. Despite this, the vulnerabilities and exploits discovered by researchers are not widely used in the wild by macOS threat actors, and that is largely because they have found other ways to the same end. In this post, we continue our look at the role of privilege escalation on macOS from the point of view of malware developers and how they take a different path.

Where’s the Harm in Asking?

Much of the commodity malware and adware seen on macOS doesn’t avail itself of the kind of exploits that lead to privilege escalation that we looked at last time. That’s not only because the exploits typically have a limited shelf life. It’s also not time well-spent. Most users, incredibly but not surprisingly, will happily give elevated privileges if you only ask! 

This direct route to elevation is party engendered by the fact that Mac users are conditioned by both frequency and repetition to seeing authorization requests when they install or move applications, move or copy files or programs from one location to another outside of their home folders, and now – more than ever – to grant applications access rights to many common system services such as Contacts, Calendars, Photos and such like, something we’ll discuss below in detail.

Examples of “ask and hope” are easy to find among macOS commodity adware and malware; in fact, they are the norm, precisely because users are easily socially engineered into installing some program or opening some file that they believe is going to be useful, informative or otherwise beneficial to what they are currently doing. 

Malware developers, PUPs/PUAs and adware make regular use of the built in Installer.app and .pkg file format, just like legitimate apps. They know that most users will click through the installer wizard and never stop to check the installer.log to see what is really going on, let alone use a tool like Suspicious Package to inspect what the package contains.

Below is just one example of a common malicious installer.

Genuine uses of the API that requests elevated permissions do not expose the password to the calling process, but malware authors typically just fake the dialog box and capture the password in plain text, which is easy to do.

It’s also fairly simple to use a bit of AppleScript to spoof a user into supplying a password with a pretty genuine-looking dialog box that even imports legitimate native icons for added authenticity:

And sometimes, even asking for root isn’t required. Famously, in the initial public release of macOS 10.13 High Sierra, an error allowed anyone to unlock a protected System Preferences pane simply with the username root and an empty password (the flaw was fixed in macOS 10.13.1)!

Abusing Dialog Alerts – Can Click, Will Click

Legitimate requests for privileges or access to protected resources have always been highly uninformative, conditioning users to either take on trust that the process is benign or risk losing some desired functionality. 

Aware of this, Apple have recently made changes to Security & Privacy preferences, adding the requirement that for notarized apps, developers must provide an informative description to be displayed in the request dialog if they intend to access these protected resources.

While the intention is good, it’s unlikely that this extra “hoop” for legitimate developers to jump through will make any difference to malware authors. First, there’s no check on what information the developer provides, only that they provide some kind of description string. Second, even Apple’s own description strings are hardly any less confusing. For example, what could it possibly mean to most users to say one application will be able to access documents and data in Terminal.app? The Terminal app isn’t typically thought of as a location for storing documents and data, so that description is at best confusing to users. Likely, we suspect it means one app will have access to documents and data within the sandbox container of the other app, but even if correct that is hardly helpful. What the implications are of that are left entirely for the user to find out the hard way: by clicking one of the buttons and finding out.

The result of that is the requirement to provide a description string isn’t really likely to be that helpful in judging whether it’s an action the user wants to take or not. Thirdly, and perhaps anecdotally, most people agree that such messages even when presented with useful text are rarely even read before the click or button press has been made. Double that effect when the messages come thick and fast and are perceived as a hindrance to productivity.

Who Needs Sudo When The User is Admin?

Another reason why attackers on macOS don’t worry unduly about elevating privileges to root is that by far and away the majority of macOS users are running as the default user that was setup when they first bought or were given their Mac. That default user is, of course, an admin user. The id command will quickly tell a process what access its user has.

A process generally has the privileges of the user who launches it, so clearly when the user is admin – as most are – that gives the process a lot of power to make changes, launch other processes and access resources.

Also see: How Two Firefox Zero Days Led To Two macOS Backdoors

For example, until Mojave, any user launched process could – without requesting any further interaction from the user – read the user’s email database, including encrypted emails, exfiltrate the browser’s entire browsing history and much more besides. These have supposedly been locked down, but various bypasses have already been revealed (see here and here, for example) and they are largely null and void in any case as soon as a user adds the Terminal to Full Disk Access, something that anyone who uses the Terminal is almost certainly going to do.

Any Hack Dropbox Can Do, Zoom Can Do Better

Which brings us to ways that malware authors can access protected resources even without asking. To tell this story, we need to pivot away from malicious developers to legitimate ones for a moment. 

Back in 2016, in my Revealing Dropbox’s dirty little security hack and a subsequent post, I exposed how Dropbox hacks System Preferences to forcibly insert itself into the Accessibility preferences pane giving itself permission to take control of the User Interface, regardless of what choices the user made in System Preferences.

This hack was itself seen in various adware, PUP/PUAs and malware exploit kits. Following a lot of exposure on hacker news and elsewhere, Apple took exception to this, and with the release of macOS Sierra a few months later locked down the TCC database that acts as the backing store for those rights. 

With Mojave and Catalina, Apple added further controls to user privacy, again backed by the TCC SQLite database, including restricting access to the system camera and microphone. 

Beginning in macOS Mojave, users have to consent before an app can access the camera or microphone. And then macOS Catalina further requires consent to record the contents of your screen or the keys that you type on your keyboard.

Importantly, while Apple have made it possible to pre-approve some of the privacy preferences either at the user level or by Mac Admins using MDM configuration profiles, they stressed in WWDC 2019 that access to the camera and microphone could only be pre-denied. Access to these resources could only be acquired at “time of use” through user approval: clicking an ‘Allow’ or ‘Deny’ button in a dialog that pops when the resource is requested by an application.

Also see: Malware Hunting on macOS | A Practical Guide

Enter Zoom into the story. You may remember Zoom were recently in the news regarding using a hidden web server, which it turned out, could easily be hijacked by malicious actors to enable a user’s camera without their permission. It seems the controversy has not made the company any less shy about abusing loophole’s in Apple’s security, albeit in a bid to provide a better experience for its users. Last week, Zoom hit the news again as a document they published themselves shows they had found and implemented another simple bypass to the Camera and Microphone permissions. 

Credits here go to Github user bp88 who developed an entire script for Jamf Pro users wanting to emulate the same effect, but let’s walk through it step by step to see how it works. Let’s use the Calculator.app, clearly something that does not require access to the Camera, for this demo. 

First we have to gather a little information about the app we want to sneak into Privacy preferences, including its bundle identifier and code signature requirements.

$ plutil -p /System/Applications/Calculator.app/Contents/Info.plist | grep -i bundleidentifier

This returns com.apple.Calculator.

We also need it’s code signing requirements in hex form. To get those, we use codesign to extract the requirements.

$ codesign -d -r- /Applications/Calculator.app

Which returns the following:

We only want the part after designated  =>. We echo that into the csreq util, which will give us a binary output that we’ll save to a temp file.

$ echo 'identifier "com.apple.calculator" and anchor apple' | csreq -r -b /tmp/req.bin

Using xxd and tr, we take the binary file and convert it into the hex “blob” that the TCC.db expects.

$ xxd -p /tmp/req.bin | tr -d 'n'

We’ll wrap that blob inside X' ' as required by the database syntax.

X'fade0c000000003000000001000000060000000200000014636f6d2e6170706c652e63616c63756c61746f7200000003'.

Finally we need a time stamp, which we can grab with 

$ date +"%s"

All we need to do now is construct our sqlite command based on the database’s schema and execute it.

$ sqlite3 ~/Library/Application Support/com.apple.TCC/TCC.db "INSERT INTO access (service,client,client_type,allowed,prompt_count,csreq,last_modified) VALUES('kTCCServiceCamera', 'com.apple.calculator', '0', '1', '1', X'fade0c000000003000000001000000060000000200000014636f6d2e6170706c652e63616c63756c61746f7200000003', 1573637690)"

While this is more of a horizontal privilege escalation – meaning, the level of rights remains the same, but the hack allows access to other resources that would normally require further user approval – it nevertheless demonstrates how macOS’s built-in security can easily be bypassed at the user level and without resorting to exploiting low-level vulnerabilities. Expect to see this hack used in the wild by RATs and other malware interested in hijacking the camera and microphone resources. 

Persistence Doesn’t Require Elevated Privileges

If you’ve ever logged in to a Mac only to unexpectedly find that some unwanted app launches itself and slows down the login process, you’ve just experienced the fact that apps don’t need permission or authentication to start up at user login time. With persistence being one of the major objectives of all malware, this is a feature that is widely abused.

There are several ways that apps can ensure they execute on login and before the user takes control of the Desktop, none of which require the application to obtain permission. 

First of all, an app can simply install itself into the Login Items list in System Preferences. Although use of this kind of persistence mechanism is formally deprecated, it’s still widely used and can even be done with a simple AppleScript.

tell application "System Events"
	name of every login item
	if (login item "Persistent App" exists) is false then
		tell application process "Persistent App" to set aPath to POSIX path of its application file as string
		make new login item at end of login items with properties {path:aPath, hidden:false, kind:"Application", name:"Persistent App"}
	end if
end tell

Second, the mechanism that is now officially recommended by Apple to replace deprecated Login Items actually makes it more difficult for users to review and manage. Login Items are now hidden within each application’s own bundle and are entirely managed within the application itself. Apple kindly point out to developers that the older API, unlike the new preferred mechanism, exposes their login item to user interference.

As we’ve mentioned before it is possible to enumerate which items are using Login Items, but this requires either writing custom code or running a script, which I’ve previously shared here.

Another root to persistence that does not require the malware authors to engage in privilege escalation techniques is to simply write a LaunchAgent to the user’s Library folder. The LaunchAgents folder does not require permissions to write to, and is by far and away the most prevalent persistence method used on the Mac by malware. That’s largely because most users have no idea that this folder exists – not helped by the fact that Apple chose to hide it by default from 10.7 onwards – and most wouldn’t know what was safe or dangerous to do with it even if they did.

Also see: How Malware Persists on macOS

Despite that, given the explosion in adware over the last couple of years, the role of LaunchAgents has started to attract a little more attention as adware infected users turn to community forums seeking help. That in turn has led to a small but rising use of the old cron technologies, which even fewer modern users are aware of. These still function reliably on all versions of macOS right up to and including macOS 10.15 Catalina.

Notice how in this example the malware explicitly calls sudo which throws a permission request to the user as they log in, without explanation other than “confup wants to make changes”. Given the recent rash of infections we’re seeing of this particular item, it’s clearly successful.

Conclusion

Despite the active and perhaps competitive race among researchers to find the latest path to root, it is rare to see the kind of privilege escalation exploits they develop being actively used in the wild by attackers. What accounts for this disjunction between research and practice is the fact that there are multiple ways for malware authors to achieve their objectives with simpler and more durable techniques. Sometimes, as we’ve seen, privilege escalation isn’t even required and where it is, social engineering or just a plain ask will often do the trick. While unpatched zero days will always be in the armoury of advanced attackers, for the majority of crimeware, they are rarely needed.

Like this article? Follow us on LinkedIn, Twitter, YouTube or Facebook to see the content we post.

Read more about Cyber Security

• Privilege Escalation | macOS Malware & The Path to Root Part 1
• The Quest for Visibility & Hunting Comes with an Unseen Opportunity Cost
• Zero2Hero (Free) Malware Course Pt 11: Here We GO: Crimeware & APT Journey
• Meet the Client Workshop | What Can We Learn From A Security Executive?
• What is Mimikatz? (And Why Is It So Dangerous?)
• Ransomware Attacks: To Pay or Not To Pay? Let’s Discuss