RobbinHood and the Merry Men

Tracking the evolution of the RobbinHood threat group

17 min readJun 3, 2020

How to use this article

Throughout the commentary below I provide an analysis of the RobbinHood threat group and the malware they use. Here’s a quick reference to help you get where you need to go:

If you want to know how the RobbinHood ransomware has changed over time, go to RobbinHood Version Timeline.
Been affected by RobbinHood and just want to know how the ransomware works? See: Tracking RobbinHood through Sherwood Forest.
Or, maybe you’ve been affected but don’t know how the malware spread through your network? Let me introduce you to RobbinHood’s merry men.
Interested in what we know about the threat group and how they operate? Take a read of the Notes from the Sheriff of Nottingham.

What is RobbinHood?

RobbinHood is a type of ransomware that made its name infecting the governments of Baltimore and Greenville during a spate of activity across April and May 2019. It was quickly condemned by the experts who examined it as “amateur”, “unsophisticated”, and “something I could have looked at 15 years ago”.

Despite the damage it caused, even a rudimentary analysis of the malware by others at the time revealed a level of juvenile naivety that was difficult to ignore. It was littered with childish references to a “CoolMaker” function, an “EnableShadowFucks” variable, and a debugging message: Done, Enjoy buddy :)

And, as researchers quickly pointed out, the malware authors had compiled the application from a user account named “valery”, the speculation being that perhaps this was the name of one of the authors. If this was a mistake, then it was clearly a very simple one that you seldom see with serious malware developers. But if it was intentional — maybe a red-herring or a joke — then it further hints at an attitude of arrogant precociousness, a profile that we very often see with young or immature cybercriminals.

All in all, the cyber security industry seemed poised to dismiss this threat as simply another one in the long list of ransomware actors that weren’t doing anything particularly interesting or unique.

But that was a year ago now, and the team behind RobbinHood have evidently not been sitting quietly.

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

Overall, there are a few points to note about the functionality of v0.4:

It is highly multi-threaded, and therefore many of these functions detailed in the diagram above were executed concurrently, as opposed to one at a time.
As you’ll find in prior reporting on RobbinHood, key.pub (fun fact, in v0.1 this was named pub.key) contains the public key used by the ransomware to encrypt a randomly generated AES key. Refer to the Notes from the Sheriff of Nottingham for information on decryption.
As mentioned in RobbinHood Version Timeline, the malware contains a hardcoded list of processes to identify and kill. Through my review of the embedded text, I was able to identify 838 of these hardcoded values. Broadly, the processes they reference fall into four categories: 1) processes with high-write operations such as databases or corporate services like email and web servers, 2) user-orientated processes like web browsers and PDF readers, 3) backup software and common system utilities used by IT staff, and 4) defensive software such as anti-malware programs made by Sophos, Avast, and Symantec.

Backup deletion

A nasty feature of this version worth singling out is that it identifies and deletes files prior to encryption, using logic apparently aimed at removing backups, but which may very easily capture ‘legitimate’ data that you might want decrypted.

Based on a review of internal strings and dynamic testing, this version of the ransomware searches for and deletes files with names (including extensions) that match the following patterns:

*backup*
*.back
*.bak
*.bak1
*.bak2
*.bak3
*bakup*
*.bakx
*bckup*
*.edb
*bkup*

Because the file names are obfuscated as part of the attack, it can be very difficult to identify if the data you are after has been encrypted or deleted; however, any deleted data may still be recoverable through file carving. If this is something you want to try, make sure to keep the machine turned off or mount any drives as read-only to prevent any further changes to the file system.

Notes from the Sheriff of Nottingham

What we know about the group and how they operate

Based on my experience with the threat group’s tools, the knowledge gained through inspecting them, and having been involved with the group directly through incident response work, there are some insights I can offer into the threat group and their methods. These insights are designed to help those who may have been infected with RobbinHood and are looking for answers; hopefully, this section will provide them.

Appeal for new information
The insights below were only possible because of community support and information exchange, which is especially important when threat groups such as this are constantly changing their methods and behaviours. Please consider reaching out if you have been affected by RobbinHood or have information about the group, so that people like me can continue to provide information to help those in trouble. See the section below for how to get in touch.

Who are the threat group behind RobbinHood ransomware?

There is insufficient evidence to construct a reliable profile of the threat group and its key personalities; however, some important characteristics have been noted, including:

v0.1 of the ransomware included immature references (refer to introduction)
The threat group demonstrates a concern with leaving behind forensic evidence of their attack.
The exploit implemented by Robnr.exe was likely developed by a competent Golang programmer (Golang is a programming language originally developed by Google) with prior experience writing exploit code.

Despite this, however, it is likely that this group consists of more than one person, some of whom may or may not be aware of each other. This assessment is based on a consideration of the below:

steel.exe was developed in the C or C++ programming languages despite the fact that the exploit dropper steel.exe references (Robnr.exe) was developed in Golang, indicating these tools were not developed by the same person.
steel.exe contains an internal reference to a user ‘mikhail’ and v0.1 of the ransomware referenced ‘valery’, which, at the very least, indicates two different development environments.
The method of obfuscation used in v0.2 of the ransomware suggests that multiple personalities may have been collaborating on the ransomware development. This is explained below.

Source code obfuscation

v0.2 of the ransomware was designed with internal obfuscation that was subsequently dropped in v0.3. The method of obfuscation they used was likely entirely manual, meaning that new function and variable names were hardcoded by the threat group during development. I suspect this because across the unique v0.2 samples, most functions have a persistent name, indicating that they were not using any automated method of obfuscation. Instead, it suggests that they were manually obfuscating function and variable names as they were updated or added to the code, otherwise they were left unchanged.

If the threat group was using an automated method of obfuscation (refer here, for example), we would expect to see entirely new function and variable names for every compilation.

Furthermore, the internal compilation path referenced by v0.2 contains the name “ObfuRobbinhood”, suggesting that it had an entirely separate codebase to the ‘vanilla’ v0.1 RobbinHood. This increases the likelihood that the group was not using compilation-time obfuscation, which could have been run against the existing codebase.

The fact that this approach was dropped in samples found in the wild a few months later may be because it would have been extremely cumbersome to update a codebase that was intentionally designed to be unreadable, especially if someone was collaborating with other developers. This could be one of the reasons why the obfuscation was dropped, as it would have hindered the rapid progression of the ransomware that we’ve observed.

Is this a Ransomware as a Service?

The evidence most often quoted to support the view that the group is hosting a Ransomware as a Service (RaaS) platform is that they use a messaging portal on the dark web to facilitate communications with their victims. Researchers have suggested that a portal can be designed for multi-tenancy, meaning that the threat group could streamline the process of ransom negotiation for their would-be users as part of the service.

This may be true, but there are several facts that undermine that assessment, including that:

A messaging portal may actually represent (at least in the mind of the threat group) a superior alternative to email platforms, which come with a heavy digital footprint and be frequently taken down by responsible providers.
Even if the portal is designed to streamline the negotiation process, there are benefits to this approach regardless if the portal is designed for multiple tenants or not, especially if the threat actor expects wide infection.
If the portal is designed for multi-tenancy, it would be extremely inconvenient to relocate the platform to a new dark web address, which could prevent existing users from negotiating with their victims or ruin their planned attacks. Over the last year, we can demonstrate that the portal used by the threat actor has changed address three times, which is unusual for dark web sites because they can ‘carry’ their address across different hosting environments.

In addition, there appears to be nothing requiring a would-be user to commit to the portal. For example, once a user had bought a copy of the binary, there is nothing stopping them from generating their own private keys. RaaS models usually operate on a commission basis, so the threat group should theoretically have a strong incentive to somehow require the user to make use of their service to facilitate encryption/decryption. One alternative to this model could be that the threat actors are selling their malware, and then adding a subscription on top for use of the portal.

Overall, there is insufficient evidence to conclude either way at this point. However, despite this, based on some circumstantial evidence and my interactions with the threat actor, my personal viewpoint is that if this is RaaS, it is more likely designed for ‘friends and family’ than for something ready for the mass-market.

Who do the threat group target?

The knowledge available from confirmed attacks indicate that the threat group have no specific type of target or focus. It is likely that they simply operate as the vast majority does — find internet-facing services and look for known vulnerabilities or weak passwords.

This means that your typical cyber-intrusion controls are still your best defence, and will provide coverage across a range of threats wider than just ransomware . If you’re not sure if you have these controls in place, you may want to consider the below:

Are cyber security risks represented at an executive level? Does the CEO or Board understand the potential impact of a cyber attack?
Do you have an assurance system in place to provide confidence that the security defences you think you have in place to reduce your risk are actually effective at reducing that risk?
If an attack did happen, how would you work out what happened quickly so that you could take prompt corrective action? Do you have a database of logs from other systems that could provide a critical backup if threat actors were to delete logs from individual systems?

Will the threat group honour a ransom payment?

All 6 identified Bitcoin addresses (5 of which belong to v0.1) have never contained any funds, perhaps indicating that the earlier versions of RobbinHood did not enjoy a high success rate.

Despite this, evidence derived from enquiries with other researchers confirms that those who have paid a RobbinHood ransom have received a decryptor, alongside the associated private keys.

Are the threat group capable of decrypting data?

In three confirmed cases occurring in April 2020, the threat group demonstrated the ability to decrypt up to three sample files submitted by the victims. This proves that in those cases they possessed the technical capability to decrypt data.

Despite this, their method of encryption can be unreliable and there is an elevated likelihood that decryption may not be possible even with the threat group’s assistance. This is because their encryption process involves using public keys to encrypt a randomly generated AES key and append that information to the target file. If the slightest error or failure occurred, it could mean that the AES key is not recoverable and the data is lost.

Lastly, v0.3 and v0.4 of the ransomware attempts to change all the user account passwords on the system. If you are using BitLocker and you are not backing up your keys centrally and you inadvertently logout or shutdown the computer, then you may be in trouble as the threat actor may not be recording what password they used for the accounts. The good news though is that this is easily recoverable if you have a copy of the ransomware used in the attack.

Where are the IOCs?

Throughout the course of this research I documented many IOCs. These will be released and linked here as soon as I have a chance to compile them within a single document.

How can I help?

Research like this depends on the victims of ransomware crime sharing information about the attack. Please consider reaching out if you have been affected by RobbinHood.

Samples or other information can be emailed to me directly at: robbinhood@sankgreall.com.

Disclaimer

All opinions are my own.

Acknowledgements

Authorised and edited by King Richard the Lionheart, a.k.a., Daniel Caplin. Many thanks for his contributions and royal assent.

Brazen plug

If you’re an incident response consultant and fed up with the slow process of pulling and interpreting event logs, you might be in need of a fully multi-core elastic ingestion tool. Check out my solution: https://github.com/S-RM/HELi