RobbinHood ransomware and the Merry Men
By: James Jackson
Tags: Windows, Malware Analysis, Ransomware, Reverse Engineering, Threat Research

Robbin’ the insecure for profit

Analysing the threat group’s use of malware

Through a combination of open source research, incident response engagements, and enquiries with other researchers, I discovered 19 unique RobbinHood ransomware binaries. Of these, I was able to link 6 to confirmed attacks.

I started my analysis by reviewing these samples for core functionality, using a methodology that broadly involved:

Sampling the key characteristics of the executable (such as identifying what programming language it was written in) and researching the earliest known evidence of that malware appearing in the wild.

(such as identifying what programming language it was written in) and researching the earliest known evidence of that malware appearing in the wild. Pulling embedded text from inside the malware and organising this into something that I could ‘read’. Embedded text often contains useful insights into what malware is designed to do; for example, you might identify text that contains a command to delete files.

and organising this into something that I could ‘read’. Embedded text often contains useful insights into what malware is designed to do; for example, you might identify text that contains a command to delete files. Executing the malware in a sandbox to determine any checks it makes to identify sandbox-execution. A sandbox is a secure and often temporary environment used to investigate the behaviour of malware without causing undesirable damage. Because sandboxes are only ever used to investigate malicious activity, it’s common for malware to try and detect when it might be inside one and alter its functionality in an attempt to mislead the investigator.

A sandbox is a secure and often temporary environment used to investigate the behaviour of malware without causing undesirable damage. Because sandboxes are only ever used to investigate malicious activity, it’s common for malware to try and detect when it might be inside one and alter its functionality in an attempt to mislead the investigator. Compensating for any sandbox detection functionality and executing the malware to observe what it does . Specifically, I would look for commands it ran, changes it made to any files, or any programs it created.

. Specifically, I would look for commands it ran, changes it made to any files, or any programs it created. Documenting the names of internal functions called by the malware, and comparing these against other versions. In programming, functions are snippets of code designed to manipulate inputs and deliver outputs. How these functions are named is often a good indicator into what they are designed to achieve, for example, we might infer that a function named multiply_two_numbers is designed to take two numbers as inputs, multiply them, and deliver one output value.

Employing this methodology across all samples, I was able to identify four clearly distinct versions of the malware, with each demonstrating a tangible progression in functionality and maturity.

RobbinHood Version Timeline

First seen: 8 April 2019

Version 0.1: This was the variant used to attack the cities of Baltimore and Greenville, and it is simplistic, inelegant, and unsophisticated. This is based on a consideration of the following points:

Its only functions are to stop computer services (such as anti-malware systems) that might prevent the malware from running, encrypt local files, and drop a ransom note demanding payment in exchange for return of the encrypted files.

The way it completes these functions is obviously malicious and noticeable (we call this being ‘noisy’, meaning it’s not very difficult to detect that something bad is happening).

The measures in place to prevent researchers from examining the malware (such as in a sandbox) are crude. As an example, the computer services it tries to stop are hardcoded into the malware, meaning we can identify a significant portion of its functionality by looking at the embedded text.

First seen: 13 June 2019

Version 0.2: This is most obviously distinguished by making it more difficult to extract embedded text from inside the malware. All function names have been scrambled (in the cyber world, we call this ‘obfuscation’), and the text detailing the list of services to stop are now encoded, meaning there is an additional step required for a researcher to read them.

It also tries to kill running processes before encryption, and contains a function to clear Windows Event Logs (main_ixnAe), which never seems to execute. Windows Event Logs (or just ‘event logs’) store a record of activities completed on a computer, and are generally an incident responder’s go-to source of information after a ransomware attack.

First seen: 27 January 2020

Version 0.3: This version has a reference to a folder named “Robinhood2” and drops the obfuscation (although embedded text is still encoded). It will now erase event logs and uses pattern matching to discover and stop services, rather than relying on hardcoded values. This makes it more effective at finding and disabling defensive software, such as anti-malware.

First seen: 24 April 2020

Version 0.4: Obviously a lot happened since v0.3, as this version references a folder named “Robbinhood6.1” — a big change from what the threat group had previously named “Robinhood2”, and this time they even spelt their name right!

A considerable number of additional functions have appeared and the overall architectural design of the program is improved. It goes back to using a hardcoded list of services and processes; however, this list is now mainly designed to stop services that constantly write data to a computer (such as databases, or something like your Outlook client). This increases the overall reliability of the encryption and minimises data loss, because programs that write a lot of data can sometimes interfere with the encryption process. In the case of a ransomware infection, this may mean that data is lost forever, which is bad for both the victim and the threat actor (who make their money returning files, not destroying them).

Refer to Tracking RobbinHood through Sherwood Forest for a more detailed review of this version.

There is no question that this version evidences a marked improvement in sophistication since v0.1 — in fact, a comparison of the internal functions indicate that only 23% of the same code is shared with v0.1.

It has certainly matured over that time (dropping some immature references — CoolMaker still makes an appearance though — and clearly focusing more on software engineering); however, it’s arguably still not doing anything we haven’t seen before. But that’s okay, because this is ransomware, and ransomware doesn’t always have to be sophisticated — its effectiveness nearly always comes down to the execution of the attack, and, as I’m about to explain, the threat group have also made a number of changes in that area as well…

“Living off another land”

On 6 February 2020, Sophos detailed their analysis of the binaries involved in recent RobbinHood attacks, making this the first known reference to what we previously assumed was just a single piece of ransomware. But no — evidently, there were accomplices:

robnr.exe handled installation of a malicious driver (a type of program the acts as the bridge between hardware and software) that the threat actors could use to elevate their permissions; and,

handled installation of a malicious driver (a type of program the acts as the bridge between hardware and software) that the threat actors could use to elevate their permissions; and, steel.exe was responsible for using these new permissions to permanently kill processes and stop services.

When we consider the timing of this article, we can see that it falls directly between the first known sightings of v0.3 and v0.4. This is significant because v0.3 improves support for identifying and stopping defensive software, whereas v0.4 goes back to an old approach and seems more concerned with services that could compromise the encryption process.

This change is more than merely interesting because, somewhere between these two versions, the threat group had developed and weaponised an exploit (the malicious driver) to handle this all for them. This approach would likely yield advantages for the group, including:

Greater confidence that defensive software was disabled prior to execution of the ransomware — perhaps they were having issues with this previously?

Facilitating compartmentalisation of the attack process. In theory, a team that understood enterprise IT infrastructure could be tasked with disabling defensive software, whilst a less technically sophisticated team could be assigned responsibility for executing the ransomware.

Having the ability to curate a custom list of processes (rather than relying on hardcoded values or runtime queries) for each environment increases the likelihood of attack success because it encourages understanding the victim’s IT landscape in more detail than was necessary previously.

RobbinHood’s merry men

When Sophos originally wrote that article, they commented that the necessary components for this exploit were “embedded in STEEL.EXE”, which the threat actor may have done to make deploying and executing this attack quicker and easier.

However, based on information received from RobbinHood attacks occurring in April 2020, it’s evident that a) the methodology for this attack has changed since February, and b) there is now a whole group of independent tools working together to ensure that the victim’s environment is purged of defensive software — RobbinHood’s gang of Merry Men, featuring:

BlackHole.exe

BlackHoleCleaner.exe

Steel.exe

Runtime_Service.exe

Robnr.exe

NewBoss2.exe

Employing the same methodology I used to categorise and investigate the ransomware, I was able to reconstruct the attack, detailed in the diagram below.

One thing to bear in mind, however, is that this is an attack with a dependency on the threat group gaining a high level of permissions across the victim’s IT environment, which is often achieved by compromising a Domain Administrator account (a type of super user often used by IT staff), navigating insecure permissions, or exploiting internal vulnerabilities. Refer to Notes from the Sheriff of Nottingham — Who do the threat group target? for more information about who the threat group are likely to target.

This attack therefore provides higher confidence that defensive programs have been deleted by using an exploit to elevate their permissions (discussed by Sophos), clearing the way for their ransomware.

All in all, I find that this is a really interesting attack that isn’t particularly noisy and means that the ransomware can focus on what it does best — encrypting stuff.

Tracking RobbinHood through Sherwood Forest

Speaking of the ransomware, I completed a more advanced review of v0.4 to understand its functionality in greater detail, given that it represents the latest available iteration. My methodology was expanded to also include:

Intercepting requests made by the malware to the operating system and inspecting their values. This is as opposed to my previous methodology, which revolved around observing the impact of any requests (such as to run commands or delete files) rather than reviewing the content of the requests themselves.

This is as opposed to my previous methodology, which revolved around observing the impact of any requests (such as to run commands or delete files) rather than reviewing the content of the requests themselves. Executing the malware with a debugger to analyse specific functions in real-time. A debugger is a tool designed to track the operations of a program, and they contain functionalities that are useful for a malware investigator, such as setting ‘breakpoints’ to halt the program at specific points, or to progress through the execution of the program line by line. Because programs often take milliseconds to execute commands, the ability to slow this down and step through each line of the program can give you much greater visibility into what’s going on behind the scenes.

A debugger is a tool designed to track the operations of a program, and they contain functionalities that are useful for a malware investigator, such as setting ‘breakpoints’ to halt the program at specific points, or to progress through the execution of the program line by line. Because programs often take milliseconds to execute commands, the ability to slow this down and step through each line of the program can give you much greater visibility into what’s going on behind the scenes. Using a debugger, track the order that the malware executes its functions (called ‘function tracing’) to understand its internal progression.

By applying this methodology, I gained a fairly good understanding of how the ransomware works, represented visually below.