McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Crescendo

Episode 4: Crescendo

This is the final installment of the McAfee Advanced Threat Research (ATR) analysis of Sodinokibi and its connections to GandGrab, the most prolific Ransomware-as-a-Service (RaaS) Campaign of 2018 and mid 2019.

In this final episode of our series we will zoom in on the operations, techniques and tools used by different affiliate groups spreading Sodinokibi ransomware.

Since May we have observed several different modus operandi by different affiliates, for example:

  • Distributing the ransomware using spear-phishing and weaponized documents
  • Bat-files downloading payloads from Pastebin and inject them into a process on the operating system
  • Compromising RDP and usage of script files and password cracking tools to distribute over the victim’s network
  • Compromise of Managed Service Providers and usage of their distribution software to spread the ransomware

To understand more about how this enemy operates, we in McAfee Advanced Threat Research (ATR) decided to operate a global network of honeypots. We were aware of the lively underground trade market of RDP credentials and were curious about what someone would do with a compromised machine. Would they distribute the Sodinokibi ransomware? Would they execute the DejaBlue or BlueKeep exploits? Our specially designed and built RDP honeypots would give us those insights.

Like Moths to a Flame

From June until September 2019, we observed several groups compromise our honey pots and conduct activities related to Sodinokibi; we were able to fully monitor attackers and their actions without their knowledge.

It is important to note the golden rule we operated under: the moment criminal actions were prepared or about to be executed, the actor would be disconnected and the machine would be restored to its original settings with a new IP address.

We noticed some of our honeypot RDP servers were attacked by Persian-speaking actors that were actively harvesting credentials. Our analysis of these attacks led us to various Persian underground channels offering the same tools we observed appearing in Sodinokibi intrusions. Some of these tools are closed source and custom made, originating from within the channels in our analysis.

In this blog we will highlight a few of the intrusions we observed.

Group 1 – Unknown Affiliate ID

McAfee ATR observed initial activity against our South American honey pot begin in late May 2019. We had full visibility as the actor loaded a number of tools, including Sodinokibi, during the initial intrusion period.

The following ransom note (uax291-readme.txt) was dropped onto the system on June 10th, 2019. The actor utilized Masscan and NLBrute to scan and target other assets over RDP which fits with the behavior we have seen in all other Sodinokibi intrusions tracked by McAfee ATR. The actor then created a user account ‘backup’ and proceeded to consistently connect from an IP address range in Belgrade, Serbia.

Group 2 – Affiliate ID 34

Campaign 295 (based on sub-ID in the malware configuration)

The following Sodinokibi variant appeared in our South American honey pot with the original file name of H.a.n.n.a.exe.

  • 58C390FE5845E2BB88D1D22610B0CA61 (June 8th, 2019)

Extracting the configuration from the ransomware sample as we conducted during our affiliate research, the affiliate-id is nr 34.

Upon initial intrusion, the actor created several user accounts on the target system between June 10th and June 11th.  The malware Sodinokibi and credential-harvesting tool Mimikatz were executed under the user account “ibm” that the actor created as part of the entry into the system

Further information revealed that the actor was connecting from two IP addresses in Poland and Finland via the ‘ibm’ account. These logins originated from these countries in a 24hr period between July 10th and 11th with the following two unique machine names WIN-S5N2M6EGS5J and TS11. Machine name WIN-S5N2M6EGS5J was observed to be used by another actor that created the account “asp” and originated from the same Polish IP address.

The actor deployed a variant of the Mimikatz credential harvester during the intrusion, with the following custom BAT file:

We have seen a consistent usage of various custom files used to interact with hacking tools that are shared among the underground communities.

Another tool, known as Everything.exe, was also executed during the same period. This tool was used to index the entire file system and what was on the target system. This tool is not considered malicious and was developed by a legitimate company but can be used for profiling purposes. The usage of reconnaissance tools to profile the machine is interesting as it indicates potential manual lateral movement attempts by the actor on the target system.

July 20th to 30th Intrusion

Activity observed during this period utilized tools similar to those used in other intrusions we have observed in multiple regions, including those by Affiliate ID 34.

In this activity McAfee ATR identified NLBrute being executed again to target victims over RDP; a pattern we have seen over and over again in intrusions involving Sodinokibi.  A series of logins from Iran were observed between July 25th and July 30th, 2019.

We have also seen crypto currency mining apps deployed in most of the intrusions involving Sodinokibi, which may suggest some interesting side activity for these groups. In this incident we discovered a miner gate configuration file with a Gmail address.

Using Open-Source Intelligence (OSINT) investigation techniques, we identified an individual that is most likely tied to the discovered Gmail address. Based on our analysis, this individual is likely part of some Persian-speaking credential cracking crew harvesting RDP credentials and other types of data. The individual is sharing information related to Masscan and Kport scan results for specific countries that can be used for brute force operations.

ACTOR PROFILE

Further, we observed this actor on a Telegram channel discussing operations which align to the behavior we observed during intrusions on our honey pot. The data shared appears to be results from tools such as Masscan or Kport-scan that would be used to compromise further assets.

DISCUSSION OF SCANNING IN FARSI, ON PRIVATE CHANNEL

Other tools were found to have been executed the same day as the activity documented include:

  • Mimikatz

Was executed manually from the command line with the following parameters:

mimikatz.exe “privilege::debug” “sekurlsa::logonPasswords full” “exit”

  • Slayer Leecher
  • MinerGate

Group 3 – Affiliate ID 19

We observed the following Sodinokibi ransom variants attributed to this affiliate appearing in the honey pot in the Middle East. The attacker downloaded a file, ابزار کرک.zip, which can be mostly found in Farsi language private channels. The tool is basically a VPS Checker (really an RDP cracker) as discussed on the channels in the underground.

Campaign 36

Activity from June 3rd to 26th indicates that the attacker present on the system was conducting operations involving the Sodinokibi ransomware. When linking back activity, we observed one notable tool the actor had used during the operation.

‘Hidden-User.bat’ was designed to create hidden users on the target system. This tool links back to some underground distribution on Farsi-speaking private channels.

The file being shared is identical to the one we found to be used actively in the Sodinokibi case in different instances in June 2019, in different cities in the Middle East. We found the following Farsi-speaking users sharing and discussing this tool specifically (Cryptor007 and MR Amir), and others active in these groups. McAfee ATR observed this tool being used on June 13th, 2019 and June 26th, 2019 by the same actors in different regions.

HIDDEN-USER.bat

POSTED IMAGE OF THE TOOL IN USE

These Sodinokibi variants are strictly appearing in Israel from our observations:

  • 009666D97065E97FFDE7B1584DB802EB (June 3rd, 2019)
  • 3746F1823A47B4AA4B520264D1CF4606 (June 11th, 2019)

We observed the actor dropping one of the above-mentioned variants of Sodinokibi. In this case, the login came from an IP address originating in Iran and with a machine with a female Persian name.

The attackers connecting are most likely Farsi-speaking, as is evident by the browsing history uncovered by McAfee ATR, which indicates where a number of the tools utilized originate from, including Farsi language file sharing sites, such as Picofile.com and Soft98.ir, that contain malicious tools such as NLBrute, etc.

FARSI LANGUAGE SITE FOUND IN BROWSING HISTORY

We observed the actor attempting to run an RDP brute force attack using NLBrute downloaded from the Iranian site Picofile.com. The target was several network blocks in Oman and the United Arab Emirates in the Middle East.

In our analysis we discovered an offer to install ransomware on servers posted in Farsi speaking on August 19th,. This posting date corresponds with the timing of attacks observed in the Middle East. The services mentioned are specifically targeting servers that have been obtained via RDP credential theft campaigns. It is possible that these actors are coming in after the fact and installing ransomware on behalf of the main organizer, according to actor chatter. One specific Farsi language message indicates these services for a list of countries where they could install ransomware for the potential client.

FARSI LANGUAGE MESSAGE FROM PERSIAN LANGUAGE CHANNEL

Tools and Methods of Group 1

The operators responsible for intrusions involving Sodinokibi variants with an unknown affiliate ID utilize a variety of methods:

  • Initial intrusions made over RDP protocol
  • Using Masscan to identify potential victims
  • Executing NLBrute with custom password lists

Tools and Methods of Group 2

The operators responsible for intrusions involving Sodinokibi variants with PID 34 utilize a variety of methods:

  • Intrusion via RDP protocol
  • Manual execution of subsequent stages of the operation
  • Deployment of Sodinokibi
  • Deployment of Mimikatz
  • Utilization of CryptoCurrency mining
  • Deployment of other brute force and checker tools
  • Running mass port scans and other reconnaissance activities to identify potential targets
  • Executing NLBrute with custom password lists
  • Some of the operators appear write in Farsi and are originating from Iranian IP address space when connecting to observed targets

Tools and Methods of Group 3

The operators responsible for intrusions involving Sodinokibi variants with PID 19 utilize a variety of methods:

  • Intrusion via RDP protocol
  • Manual execution of subsequent stages of the operation
  • Likely a cracking crew working on behalf of an affiliate
  • Deployment of Sodinokibi
  • Custom scripts to erase logs and create hidden users
  • Usage of Neshta to scan internal network shares within an organization in an effort to spread Sodinokibi
  • Running mass port scans and other reconnaissance activities to identify potential targets
  • Limited use of local exploits to gain administrative access
  • Executing NLBrute with custom password lists
  • Some of the operators appear to write in Farsi and are originating from Iranian IP address space when connecting to observed targets

Conclusion

In our blog series about Sodinokibi we began by analyzing the code. One of our observations was that like GandCrab, the Romanian and Persian languages are blacklisted. If these two languages, amongst others, are installed on a victim’s machine, the ransomware would not execute. We asked ourselves the question, “Why Persian?” With the information retrieved from our honeypot investigations, it might give us a hypothesis that the Persian language is present due to the involvement of Persian-speaking affiliates. Would that also count for the Romanian language? Time and evidence will tell.

We observed many affiliates using different sets of tools and skills to gain profit and, across the series, we highlighted different aspects of this massive ongoing operation.

To protect your organization against Sodinokibi, make sure your defense is layered. As demonstrated, the actors we are facing either buy, brute-force or spear-phish themselves into your company or use a trusted-third party that has access to your network. Some guidelines for organizations to protect themselves include employing sandboxing, backing up data, educating their users, and restricting access.

As long as we support the ransomware model, ransomware will exist as it has for the last four years. We cannot fight alone against ransomware and have to unite as public and private parties. McAfee is one of the founding partners of NoMoreRansom.org and are supporting Law Enforcement agencies around the globe in fighting ransomware.

 

We hope you enjoyed reading this series of blogs about Sodinokibi.

The post McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Crescendo appeared first on McAfee Blogs.

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – The All-Stars

Episode 2: The All-Stars

Analyzing Affiliate Structures in Ransomware-as-a-Service Campaigns

This is the second installment of the McAfee Advanced Threat Research (ATR) analysis of Sodinokibi and its connections to GandGrab, the most prolific Ransomware-as-a-Service (RaaS) Campaign of 2018 and mid-2019.

GandCrab announced its retirement at the end of May. Since then, a new RaaS family called Sodinokibi, aka REvil, took its place as one of the most prolific ransomware campaigns.

In episode one of our analysis on the Sodinokibi RaaS campaign we shared our extensive malware and post-infection analysis, which included code comparisons to GandCrab, and insight on exactly how massive the new Sodinokibi campaign is.

The Sodinokibi campaigns are still ongoing and differ in execution due to the different affiliates spreading the ransomware. Which begs more questions to be answered, such as how do the affiliates operate? Is the affiliate model working? What can we learn about the campaign and possible connections to GandCrab by investigating the affiliates?

It turns out, through large scale sample analysis and hardcoded value aggregation, we were able to determine which affiliates played a crucial role in the success of GandCrab’ criminal enterprise and found a lot of similarity between the RaaS enterprise of GandCrab and that of Sodinokibi.

Before we begin with the Sodinokibi analysis and comparison we will briefly explain the methodology that we used for GandCrab.

GandCrab RaaS System

GandCrab was a prime example of a Ransomware-as-a-Service. RaaS follows a structure where the developers are offering their product to affiliates, partners or advertisers who are responsible for spreading the ransomware and generating infections. The developers take a percentage of the earned income and provide the other portion to the affiliates.

FIGURE 1. HIGH LEVEL OVERVIEW OF THE GANDCRAB RAAS MODEL

Operating a RaaS model can be lucrative for both parties involved:

  • Developer’s perspective: The malware author/s request a percentage per payment for use of the ransomware product. This way the developers have less risk than the affiliates spreading the malware. The developers can set certain targets for their affiliates regarding the amount of infections they need to produce. In a way, this is very similar to a modern sales organization in the corporate world.

Subsequently, a RaaS model offers malware authors a safe haven when they operate from a country that does not regard developing malware as a crime. If their own nation’s citizens are not victimized, the developers are not going to be prosecuted.

  • Affiliate perspective: As an affiliate you do not have to write the ransomware code yourself; less technical skill is involved. RaaS makes ransomware more accessible to a greater number of users. An affiliate just needs to be accepted in the criminal network and reach the targets set by the developers. As a service model it also offers a level of decentralization where each party sticks to their own area of expertise.

Getting a Piece of the Pie

Affiliates want to get paid proportionate to the infections they made; they expose themselves to a large amount of risk by spreading ransomware and they want to reap the benefits. Mutual trust between the developer and the affiliate plays a huge role in joining a RaaS system. It is very much like the expression: “Trust, hard to build, and easy to lose” and this largely explains the general skepticism that cybercriminal forum members display when a new RaaS system is announced.

For the RaaS service to grow and maintain their trust, proper administration of infections/earnings per affiliate plays an important part. Through this, the developers can ensure that everyone gets an honest piece of the proverbial “pie”. So how can this administration be achieved? One way is having hardcoded values in the ransomware.

Linking the Ransomware to Affiliates

Through our technical malware analysis, we established that, starting from version 4, GandCrab included certain hardcoded values in the ransomware source code:

  • id – The affiliate id number.
  • sub_id – The Sub ID of the affiliate ID; A tracking number for the affiliate for sub-renting infections or it tracks their own campaign, identifiable via the sub_id number.
  • version – The internal version number of the malware.

Version 4 had significant changes overall and we believe that these changes were partly done by the authors to improve administration and make GandCrab more scalable to cope with its increased popularity.

Based on the hardcoded values it was possible for us, to a certain extent, to extract the administration information and create our own overview. We hunted for as many different GandCrab samples as we could find, using Yara rules, industry contacts and customer submissions. The sample list we gathered is quite extensive but not exhaustive. From the collected samples we extracted the hardcoded values and compile times automatically, using a custom build tool. We aggregated all these values together in one giant timeline from GandCrab version 4, all the way up to version 5.2.

FIGURE 2. SMALL PORTION OF THE TIMELINE OF COLLECTED SAMPLES (NOTE THE FIRST FOUR POSSIBLY TIME STOMPED)

ID and SUB_ID Characteristics Observed

Parent-Child Relationship
The extracted ID’s and Sub_IDs showed a parent-child relationship, meaning every ID could have more than one SUB_ID (child) but every SUB_ID only had one ID (parent).

FIGURE 3. THE ACTIVITY OF ID NUMBER 41 (PARENT) AND ITS CORRESPONDING SUB_IDs (CHILDREN)

ID Increments
Overall, we observed a gradual increment in the ID number over time. The earlier versions generally had lower ID numbers and higher ID numbers appeared with the later versions.

However, there were relatively lower ID numbers that appeared in many versions, as shown in figure 3.

This observation aligned with our theory that the ID number corresponds with a particular affiliate. Certain affiliates remained partners for a long period of time, spreading different versions of GandCrab; this explains the ID number appearing over a longer period and in different versions. This theory has also been acknowledged by several (anonymous) sources.

Determining Top ID’s/Affiliates
When we applied the theory that the ID corresponded with an affiliate, we observed different activity amongst the affiliates. There are some affiliates/ID’s that were only linked to a single sample that we found. A reason for affiliates to only appear for a short moment can be explained by the failure to perform. The GandCrab developers had a strict policy of expelling affiliates that underperformed. Expelling an affiliate would open a new slot that would receive a new incremented ID number.

On the other hand, we observed several very active affiliates, “The All-Stars”, of which ID number 99 was by far the most active. We first observed ID 99 in six different samples of version 4.1.1, growing to 35 different samples in version 5.04. Based on our dataset we observed 71 unique unpacked samples linked to ID 99.

Being involved with several versions (consistency over time), in combination with the number of unique samples (volume) and the number of infections (based on industry malware detections) can effectively show which affiliate was the most aggressive and possibly the most important to the RaaS network.

Affiliate vs. Salesperson & Disruption

An active affiliate can be compared to a top salesperson in any normal commercial organization. Given that the income of the RaaS network is largely dependent on the performance of its top affiliates, identifying and disrupting a top affiliate’s activity can have a crippling effect on the income of the RaaS network, internal morale and overall RaaS performance. This can be achieved through arrests of an affiliate and/or co-conspirers.

Another way is disrupting the business model and lowering the ransomware’s profits through offering free decryption tools or building vaccines that prevent encryption. The disruption will increase the operational costs for the criminals, making the RaaS of less interest.

Lastly, for any future proceedings (suspect apprehension and legal) it is important to maintain a chain of custody linking victims, samples and affiliates together. Security providers as gatherers and owners of this data play a huge role in safeguarding this for the future.

Overview Versions and ID Numbers

Using an online tool from RAWGraphs we created a graphic display of the entire dataset showing the relationship between the versions and the ID numbers. Below is an overview, a more detailed overview can be found on the McAfee ATR Github.

FIGURE 4. OVERVIEW OF GANDCRAB VERSIONS AND IDs

Top performing affiliates immediately stood out from the rest as the lines were thicker and more spread out. According to our data, the most active ID numbers were 15,41,99 and 170. Determining the key players in a RaaS family can help Law Enforcement prioritize its valuable resources.

Where are the All-Stars? Top Affiliates Missing in 5.2

At the time we were not realizing it fully but, looking back at the overview, it stands out that none of the top affiliates/ID numbers where present in the final version 5.2 of GandCrab which was released in February. We believe that this was an early indicator that the end of GandCrab was imminent.

This discovery might indicate that some kind of event had taken place that resulted in the most active affiliates not being present. The cause could have been internal or external.

But what puzzles us is why would a high performing affiliate leave? Maybe we will never hear the exact reason. Perhaps it is quite similar to why people leave regular jobs… feeling unhappy, a dispute or leaving for a better offer.

With the absence of the top affiliates the question remains; Where did these affiliates go to?

FIGURE 5. ID AND SUB_ID NUMBER LINKED TO VERSION 5.2

Please note that active ID numbers 15,41,99 and170 from the complete overview are not present in any GandCrab version 5.2 infections. The most active affiliate in version 5.2. was nr 287.

Goodbye GandCrab, Hello Sodinokibi/REvil

In our opening episode we described the technical similarities we have seen between GandCrab and REvil. We are not the only ones that noticed these similarities – security reporter Brian Krebs published an article where he highlights the similarities between GandCrab and a new ransomware named Sodinokibi or REvil, and certain postings that were made on several underground forums.

Affiliates Switching RaaS Families….

On two popular underground Forums a user named UNKN, aka unknown, placed an advertisement on the 4th of July 2019, for a private ransomware as a service (RaaS) he had been running for some time. Below is a screenshot of the posting. Interesting is the response from a user with the nickname Lalartu. In a reply to the advertisement, Lalartu mentions that he is working with UNKN and his team, as well as that they had been a former GandCrab affiliate, something that was noticed by Bleepingcomputer too. Lalartu’s post supports our earlier observations that some top GandCrab affiliates suddenly disappeared and might have moved to a different RaaS family. This is something that was suspected but never confirmed with technical evidence.

We suspect that Lalartu is not the only GandCrab affiliate that has moved to Sodinokibi. If top affiliates have a solid and very profitable infection method available, then it does not make sense to retire with the developers.

Around February 2019, there was a noticeable change in some of GandCrab’s infections behavior. Managed Service Providers (MSP) were now targeted through vulnerable systems and their customers got infected with GandCrab on a large scale, something we had not seen performed before by any of the affiliates. Interestingly, shortly after the retirement of GandCrab, the MSP modus operandi was quickly adopted by Sodinokibi, another indication that a former GandCrab affiliate had moved to Sodinokibi.

This makes us suspect that Sodinokibi is actively recruiting the top performing affiliates from other successful RaaS families, creating a sort of all-star team.

At the same time, the RaaS market is such where less proficient affiliates can hone their skills, improve their spreading capabilities and pivot to the more successful RaaS families. Combined with a climate where relatively few ransomware arrests are taking place, it allows for an alarming cybercriminal career path with dire consequences.

Gathering “administration” from Sodinokibi/Revil Samples

Another similarity Sodinokibi shares with GandCrab is the administration of infections, one of the indicators of a RaaS’s growth potential. In our earlier blog we discussed that Sodinokibi generates a JSON config file for each sample containing certain values such as a PID number and a value labeled sub. So, we decided to use our GandCrab affiliate methodology on the Sodinokibi config files we were able to collect.

With GandCrab we had to write our own tool to pull the hardcoded indicators but, with Sodinokibi, we were lucky enough that Carbon Black had developed a tool that did much of the heavy lifting for us. In the end there were still some samples from which we had to pull the configs manually. The JSON file contains different values and fields; for a comparison to GandCrab we focused on the PID and SUB field of each sample as these values appeared to have a similar characteristic as the ID and SUB_ID field in the GandCrab samples.

FIGURE 6. REVIL JSON CONFIG VALUES

Interpreting the Data Structures

With the data we gathered, we used the same analysis methodology on Sodinokibi  as we did on GandCrab. We discovered that Sodinokibi has a RaaS structure very similar to GandCrab and with the Parent-Child relationship structure being nearly identical. Below we compared activity of GandCrab affiliate number 99 with the activity of the Sodinokibi affiliate number 19.

FIGURE 7. THE ACTIVITY OF GANDCRAB ID NO 99 (PARENT) AND ITS CORRESPONDING SUB (CHILDREN)

FIGURE 8. THE ACTIVITY OF SODINOKIBI PID NO 19 (PARENT) AND ITS CORRESPONDING SUB (CHILDREN)

It needs to be said that the timespan for the GandCrab overview was generated over a long period of time with a larger total of samples than the Sodinokibi overview.

Nevertheless, the similarity is quit striking.

The activity of both ID numbers displays a tree-shaped structure with the parent ID number at the root and branching out to the respective SUB numbers linked to multiple samples.

We believe that the activity above might be linked to a tiered affiliate group that is specialized in RDP brute forcing and infecting systems with Sodinokibi after each successful compromise.

Both RaaS family structures are too large to effectively publish within the space of this blog. Our Complete overview for the Sodinokibi RaaS structure can be found on our McAfee GitHub.

Conclusion

When we started our journey with GandCrab we did not expect it would take us so far down the rabbit hole. Mass sample analysis and searching for administration indicators provided a way to get more insight in a multi-million-dollar criminal enterprise, determine key players and foresee future events through changes in the business structure. We believe that the retirement of GandCrab was not an overnight decision and, based on the data on the affiliates, it was clear that something was going to happen.

With the emergence of Sodinokibi and the few forum postings by a high profile former GandCrab affiliate, everything fell into place. We have strong indications that some of the top affiliates have found a new home with Sodinokibi to further their criminal business.

Given that the income of the RaaS network is largely dependent on the performance of its top affiliates, and it is run like a normal business, we (the security industry) should not only research the products the criminals develop, but also identify possible ways to successfully disrupt the criminal business.

In our next episode we dive deeper into the financial streams involved in the affiliate program and provide an estimate of how much money these actors are earning with the ransomware-as-a-service business model.

The post McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – The All-Stars appeared first on McAfee Blogs.

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – What The Code Tells Us

Episode 1: What the Code Tells Us

McAfee’s Advanced Threat Research team (ATR) observed a new ransomware family in the wild, dubbed Sodinokibi (or REvil), at the end of April 2019. Around this same time, the GandCrab ransomware crew announced they would shut down their operations. Coincidence? Or is there more to the story?

In this series of blogs, we share fresh analysis of Sodinokibi and its connections to GandCrab, with new insights gleaned exclusively from McAfee ATR’s in-depth and extensive research.

  • Episode 1: What the Code Tells Us
  • Episode 2: The All-Stars
  • Episode 3: Follow the Money
  • Episode 4: Crescendo

In this first instalment we share our extensive malware and post-infection analysis and visualize exactly how big the Sodinokibi campaign is.

Background

Since its arrival in April 2019, it has become very clear that the new kid in town, “Sodinokibi” or “REvil” is a serious threat. The name Sodinokibi was discovered in the hash ccfde149220e87e97198c23fb8115d5a where ‘Sodinokibi.exe’ was mentioned as the internal file name; it is also known by the name of REvil.

At first, Sodinokibi ransomware was observed propagating itself by exploiting a vulnerability in Oracle’s WebLogic server. However, similar to some other ransomware families, Sodinokibi is what we call a Ransomware-as-a-Service (RaaS), where a group of people maintain the code and another group, known as affiliates, spread the ransomware.

This model allows affiliates to distribute the ransomware any way they like. Some affiliates prefer mass-spread attacks using phishing-campaigns and exploit-kits, where other affiliates adopt a more targeted approach by brute-forcing RDP access and uploading tools and scripts to gain more rights and execute the ransomware in the internal network of a victim. We have investigated several campaigns spreading Sodinokibi, most of which had different modus operandi but we did notice many started with a breach of an RDP server.

Who and Where is Sodinokibi Hitting?

Based on visibility from MVISION Insights we were able to generate the below picture of infections observed from May through August 23rd, 2019:

Who is the target? Mostly organizations, though it really depends on the skills and expertise from the different affiliate groups on who, and in which geo, they operate.

Reversing the Code

In this first episode, we will dig into the code and explain the inner workings of the ransomware once it has executed on the victim’s machine.

Overall the code is very well written and designed to execute quickly to encrypt the defined files in the configuration of the ransomware. The embedded configuration file has some interesting options which we will highlight further in this article.

Based on the code comparison analysis we conducted between GandCrab and Sodinokibi we consider it a likely hypothesis that the people behind the Sodinokibi ransomware may have some type of relationship with the GandCrab crew.

FIGURE 1.1. OVERVIEW OF SODINOKIBI’S EXECUTION FLAW

Inside the Code

Sodinokibi Overview

For this article we researched the sample with the following hash (packed):

The main goal of this malware, as other ransomware families, is to encrypt your files and then request a payment in return for a decryption tool from the authors or affiliates to decrypt them.

The malware sample we researched is a 32-bit binary, with an icon in the packed file and without one in the unpacked file. The packer is programmed in Visual C++ and the malware itself is written in pure assembly.

Technical Details

The goal of the packer is to decrypt the true malware part and use a RunPE technique to run it from memory. To obtain the malware from memory, after the decryption is finished and is loaded into the memory, we dumped it to obtain an unpacked version.

The first action of the malware is to get all functions needed in runtime and make a dynamic IAT to try obfuscating the Windows call in a static analysis.

FIGURE 2. THE MALWARE GETS ALL FUNCTIONS NEEDED IN RUNTIME

The next action of the malware is trying to create a mutex with a hardcoded name. It is important to know that the malware has 95% of the strings encrypted inside. Consider that each sample of the malware has different strings in a lot of places; values as keys or seeds change all the time to avoid what we, as an industry do, namely making vaccines or creating one decryptor without taking the values from the specific malware sample to decrypt the strings.

FIGURE 3. CREATION OF A MUTEX AND CHECK TO SEE IF IT ALREADY EXISTS

If the mutex exists, the malware finishes with a call to “ExitProcess.” This is done to avoid re-launching of the ransomware.

After this mutex operation the malware calculates a CRC32 hash of a part of its data using a special seed that changes per sample too. This CRC32 operation is based on a CRC32 polynomial operation instead of tables to make it faster and the code-size smaller.

The next step is decrypting this block of data if the CRC32 check passes with success. If the check is a failure, the malware will ignore this flow of code and try to use an exploit as will be explained later in the report.

FIGURE 4. CALCULATION OF THE CRC32 HASH OF THE CRYPTED CONFIG AND DECRYPTION IF IT PASSES THE CHECK

In the case that the malware passes the CRC32 check and decrypts correctly with a key that changes per sample, the block of data will get a JSON file in memory that will be parsed. This config file has fields to prepare the keys later to encrypt the victim key and more information that will alter the behavior of the malware.

The CRC32 check avoids the possibility that somebody can change the crypted data with another config and does not update the CRC32 value in the malware.

After decryption of the JSON file, the malware will parse it with a code of a full JSON parser and extract all fields and save the values of these fields in the memory.

FIGURE 5. PARTIAL EXAMPLE OF THE CONFIG DECRYPTED AND CLEANED

Let us explain all the fields in the config and their meanings:

  • pk -> This value encoded in base64 is important later for the crypto process; it is the public key of the attacker.
  • pid -> The affiliate number that belongs to the sample.
  • sub -> The subaccount or campaign id for this sample that the affiliate uses to keep track of its payments.
  • dbg -> Debug option. In the final version this is used to check if some things have been done or not; it is a development option that can be true or false. In the samples in the wild it is in the false state. If it is set, the keyboard check later will not happen. It is useful for the malware developers to prove the malware works correctly in the critical part without detecting his/her own machines based on the language.
  • fast -> If this option is enabled, and by default a lot of samples have it enabled, the malware will crypt the first 1 megabyte of each target file, or all files if it is smaller than this size. In the case that this field is false, it will crypt all files.
  • wipe -> If this option is ‘true’, the malware will destroy the target files in the folders that are described in the json field “wfld”. This destruction happens in all folders that have the name or names that appear in this field of the config in logic units and network shares. The overwriting of the files can be with trash data or null data, depending of the sample.
  • wht -> This field has some subfields: fld -> Folders that should not be crypted; they are whitelisted to avoid destroying critical files in the system and programs. fls -> List of whitelists of files per name; these files will never be crypted and this is useful to avoid destroying critical files in the system. ext -> List of the target extensions to avoid encrypting based on extension.
  • wfld -> A list of folders where the files will be destroyed if the wipe option is enabled.
  • prc -> List of processes to kill for unlocking files that are locked by this/these program/s, for example, “mysql.exe”.
  • dmn -> List of domains that will be used for the malware if the net option is enabled; this list can change per sample, to send information of the victim.
  • net -> This value can be false or true. By default, it is usually true, meaning that the malware will send information about the victim if they have Internet access to the domain list in the field “dmn” in the config.
  • nbody -> A big string encoded in base64 that is the template for the ransom note that will appear in each folder where the malware can create it.
  • nname -> The string of the name of the malware for the ransom note file. It is a template that will have a part that will be random in the execution.
  • exp -> This field is very important in the config. By default it will usually be ‘false’, but if it is ‘true’, or if the check of the hash of the config fails, it will use the exploit CVE-2018-8453. The malware has this value as false by default because this exploit does not always work and can cause a Blue Screen of Death that avoids the malware’s goal to encrypt the files and request the ransom. If the exploit works, it will elevate the process to SYSTEM user.
  • img -> A string encoded in base64. It is the template for the image that the malware will create in runtime to change the wallpaper of the desktop with this text.

After decrypting the malware config, it parses it and the malware will check the “exp” field and if the value is ‘true’, it will detect the type of the operative system using the PEB fields that reports the major and minor version of the OS.

FIGURE 6. CHECK OF THE VERSION OF THE OPERATIVE SYSTEM

Usually only one OS can be found but that is enough for the malware. The malware will check the file-time to verify if the date was before or after a patch was installed to fix the exploit. If the file time is before the file time of the patch, it will check if the OS is 64-bit or 32-bit using the function “GetSystemNativeInfoW”. When the OS system is 32-bit, it will use a shellcode embedded in the malware that is the exploit and, in the case of a 64-bit OS, it will use another shellcode that can use a “Heaven´s Gate” to execute code of 64 bits in a process of 32 bits.

FIGURE 7. CHECK IF OS IS 32- OR 64-BIT

In the case that the field was false, or the exploit is patched, the malware will check the OS version again using the PEB. If the OS is Windows Vista, at least it will get from the own process token the level of execution privilege. When the discovered privilege level is less than 0x3000 (that means that the process is running as a real administrator in the system or SYSTEM), it will relaunch the process using the ‘runas’ command to elevate to 0x3000 process from 0x2000 or 0x1000 level of execution. After relaunching itself with the ‘runas’ command the malware instance will finish.

FIGURE 8. CHECK IF OS IS WINDOWS VISTA MINIMAL AND CHECK OF EXECUTION LEVEL

The malware’s next action is to check if the execute privilege is SYSTEM. When the execute privilege is SYSTEM, the malware will get the process “Explorer.exe”, get the token of the user that launched the process and impersonate it. It is a downgrade from SYSTEM to another user with less privileges to avoid affecting the desktop of the SYSTEM user later.

After this it will parse again the config and get information of the victim’s machine This information is the user of the machine, the name of the machine, etc. The malware prepares a victim id to know who is affected based in two 32-bit values concat in one string in hexadecimal.

The first part of these two values is the serial number of the hard disk of the Windows main logic unit, and the second one is the CRC32 hash value that comes from the CRC32 hash of the serial number of the Windows logic main unit with a seed hardcoded that change per sample.

FIGURE 9. GET DISK SERIAL NUMBER TO MAKE CRC32 HASH

After this, the result is used as a seed to make the CRC32 hash of the name of the processor of the machine. But this name of the processor is not extracted using the Windows API as GandCrab does; in this case the malware authors use the opcode CPUID to try to make it more obfuscated.

FIGURE 10. GET THE PROCESSOR NAME USING CPUID OPCODE

Finally, it converts these values in a string in a hexadecimal representation and saves it.

Later, during the execution, the malware will write in the Windows registry the next entries in the subkey “SOFTWARE\recfg” (this subkey can change in some samples but usually does not).

The key entries are:

  • 0_key -> Type binary; this is the master key (includes the victim’s generated random key to crypt later together with the key of the malware authors).
  • sk_key -> As 0_key entry, it is the victim’s private key crypted but with the affiliate public key hardcoded in the sample. It is the key used in the decryptor by the affiliate, but it means that the malware authors can always decrypt any file crypted with any sample as a secondary resource to decrypt the files.
  • pk_key -> Victim public key derivate from the private key.
  • subkey -> Affiliate public key to use.
  • stat -> The information gathered from the victim machine and used to put in the ransom note crypted and in the POST send to domains.
  • rnd_ext -> The random extension for the encrypted files (can be from 5 to 10 alphanumeric characters).

The malware tries to write the subkey and the entries in the HKEY_LOCAL_MACHINE hive at first glance and, if it fails, it will write them in the HKEY_CURRENT_USER hive.

FIGURE 11. EXAMPLE OF REGISTRY ENTRIES AND SUBKEY IN THE HKLM HIVE

The information that the malware gets from the victim machine can be the user name, the machine name, the domain where the machine belongs or, if not, the workgroup, the product name (operating system name), etc.

After this step is completed, the malware will check the “dbg” option gathered from the config and, if that value is ‘true’, it will avoid checking the language of the machine but if the value is ‘false’ ( by default), it will check the machine language and compare it with a list of hardcoded values.

FIGURE 12. GET THE KEYBOARD LANGUAGE OF THE SYSTEM

The malware checks against the next list of blacklisted languages (they can change per sample in some cases):

  • 0x818 – Romanian (Moldova)
  • 0x419 – Russian
  • 0x819 – Russian (Moldova)
  • 0x422 – Ukrainian
  • 0x423 – Belarusian
  • 0x425 – Estonian
  • 0x426 – Latvian
  • 0x427 – Lithuanian
  • 0x428 – Tajik
  • 0x429 – Persian
  • 0x42B – Armenian
  • 0x42C – Azeri
  • 0x437 – Georgian
  • 0x43F – Kazakh
  • 0x440 – Kyrgyz
  • 0x442 –Turkmen
  • 0x443 – Uzbek
  • 0x444 – Tatar
  • 0x45A – Syrian
  • 0x2801 – Arabic (Syria)

We observed that Sodinokibi, like GandCrab and Anatova, are blacklisting the regular Syrian language and the Syrian language in Arabic too. If the system contains one of these languages, it will exit without performing any action. If a different language is detected, it will continue in the normal flow.

This is interesting and may hint to an affiliate being involved who has mastery of either one of the languages. This insight became especially interesting later in our investigation.

If the malware continues, it will search all processes in the list in the field “prc” in the config and terminate them in a loop to unlock the files locked for this/these process/es.

FIGURE 13. SEARCH FOR TARGET PROCESSES AND TERMINATE THEM

After this it will destroy all shadow volumes of the victim machine and disable the protection of the recovery boot with this command:

  • exe /c vssadmin.exe Delete Shadows /All /Quiet & bcdedit /set {default} recoveryenabled No & bcdedit /set {default} bootstatuspolicy ignoreallfailures

It is executed with the Windows function “ShellExecuteW”.

FIGURE 14. LAUNCH COMMAND TO DESTROY SHADOW VOLUMES AND DESTROY SECURITY IN THE BOOT

Next it will check the field of the config “wipe” and if it is true will destroy and delete all files with random trash or with NULL values. If the malware destroys the files , it will start enumerating all logic units and finally the network shares in the folders with the name that appear in the config field “wfld”.

FIGURE 15. WIPE FILES IN THE TARGET FOLDERS

In the case where an affiliate creates a sample that has defined a lot of folders in this field, the ransomware can be a solid wiper of the full machine.

The next action of the malware is its main function, encrypting the files in all logic units and network shares, avoiding the white listed folders and names of files and extensions, and dropping the ransom note prepared from the template in each folder.

FIGURE 16. CRYPT FILES IN THE LOGIC UNITS AND NETWORK SHARES

After finishing this step, it will create the image of the desktop in runtime with the text that comes in the config file prepared with the random extension that affect the machine.

The next step is checking the field “net” from the config, and, if true, will start sending a POST message to the list of domains in the config file in the field “dmn”.

FIGURE 17. PREPARE THE FINAL URL RANDOMLY PER DOMAIN TO MAKE THE POST COMMAND

This part of the code has similarities to the code of GandCrab, which we will highlight later in this article.

After this step the malware cleans its own memory in vars and strings but does not remove the malware code, but it does remove the critical contents to avoid dumps or forensics tools that can gather some information from the RAM.

FIGURE 18. CLEAN MEMORY OF VARS

If the malware was running as SYSTEM after the exploit, it will revert its rights and finally finish its execution.

FIGURE 19. REVERT THE SYSTEM PRIVILEGE EXECUTION LEVEL

Code Comparison with GandCrab

Using the unpacked Sodinokibi sample and a v5.03 version of GandCrab, we started to use IDA and BinDiff to observe any similarities. Based on the Call-Graph it seems that there is an overall 40 percent code overlap between the two:

FIGURE 20. CALL-GRAPH COMPARISON

The most overlap seems to be in the functions of both families. Although values change, going through the code reveals similar patterns and flows:

Although here and there are some differences, the structure is similar:

 

We already mentioned that the code part responsible for the random URL generation has similarities with regards to how it is generated in the GandCrab malware. Sodinokibi is using one function to execute this part where GandCrab is using three functions to generate the random URL. Where we do see some similar structure is in the parts for the to-be-generated URL in both malware codes. We created a visual to explain the comparison better:

FIGURE 21. URL GENERATION COMPARISON

We observe how even though the way both ransomware families generate the URL might differ, the URL directories and file extensions used have a similarity that seems to be more than coincidence. This observation was also discovered by Tesorion in one of its blogs.

Overall, looking at the structure and coincidences, either the developers of the GandCrab code used it as a base for creating a new family or, another hypothesis, is that people got hold of the leaked GandCrab source code and started the new RaaS Sodinokibi.

Conclusion

Sodinokibi is a serious new ransomware threat that is hitting many victims all over the world.

We executed an in-depth analysis comparing GandCrab and Sodinokibi and discovered a lot of similarities, indicating the developer of Sodinokibi had access to GandCrab source-code and improvements. The Sodinokibi campaigns are ongoing and differ in skills and tools due to the different affiliates operating these campaigns, which begs more questions to be answered. How do they operate? And is the affiliate model working? McAfee ATR has the answers in episode 2, “The All Stars.”

Coverage

McAfee is detecting this family by the following signatures:

  • “Ransom-Sodinokibi”
  • “Ransom-REvil!”.

MITRE ATT&CK Techniques

The malware sample uses the following MITRE ATT&CK™ techniques:

  • File and Directory Discovery
  • File Deletion
  • Modify Registry
  • Query Registry
  • Registry modification
  • Query information of the user
  • Crypt Files
  • Destroy Files
  • Make C2 connections to send information of the victim
  • Modify system configuration
  • Elevate privileges

YARA Rule

rule Sodinokobi

{

/*

This rule detects Sodinokobi Ransomware in memory in old samples and perhaps future.

*/

meta:

author      = “McAfee ATR team”

version     = “1.0”

description = “This rule detect Sodinokobi Ransomware in memory in old samples and perhaps future.”

strings:

$a = { 40 0F B6 C8 89 4D FC 8A 94 0D FC FE FF FF 0F B6 C2 03 C6 0F B6 F0 8A 84 35 FC FE FF FF 88 84 0D FC FE FF FF 88 94 35 FC FE FF FF 0F B6 8C 0D FC FE FF FF }

$b = { 0F B6 C2 03 C8 8B 45 14 0F B6 C9 8A 8C 0D FC FE FF FF 32 0C 07 88 08 40 89 45 14 8B 45 FC 83 EB 01 75 AA }

condition:

all of them

}

 

The post McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – What The Code Tells Us appeared first on McAfee Blogs.

Ryuk, Exploring the Human Connection

In collaboration with Bill Siegel and Alex Holdtman from Coveware.

 

At the beginning of 2019, McAfee ATR published an article describing how the hasty attribution of Ryuk ransomware to North Korea was missing the point. Since then, collective industry peers discovered additional technical details on Ryuk’s inner workings, the overlap between Ryuk and Hermes2.1, and a detailed description of how the ransomware is piggybacking the infamous and ever evolving Trickbot as a primary attack vector. In this blog post we have teamed up with Coveware to take a closer look at the adversary and victim dynamics of Ryuk Ransomware. We structured our research using the Diamond threat model and challenged our existing hypotheses with fresh insights.

Introduction to The Diamond Model

Within Cyber Threat intelligence research, a popular approach is to model the characteristics of an attack using The Diamond Model of Intrusion Analysis. This model relates four basic elements of an intrusion: adversary, capabilities, infrastructure and victim.

For the Ryuk case described above the model can be applied as follows: “An Adversary, cyber-criminal(s), have a capability (Ryuk Ransomware) that is being spread via a TrickBot infection Infrastructure targeting specific victims.

Diamond model of Intrusion Analysis

The Diamond Model offers a holistic view of an intrusion that is a helpful guideline to shape the direction of intelligence research. By searching for relationships between two elements one can gather new evidence. For instance, by analyzing and reverse engineering a piece of malware one might uncover that a certain server is being used for command and control infrastructure, thus linking capability with infrastructure (as shown below).

Linking Infrastructure and Capability

Alternatively, one might search underground forums to find information on adversaries who sell certain pieces of malware, thus linking an adversary with a capability. For instance, finding the underground forum advertisement of Hermes2.1.

Linking Adversary and Capability

Analysis of Competing Hypotheses

In our earlier publication we explained The Analysis of Competing Hypotheses (ACH), the process of challenging formed hypotheses with research findings.
By following this method, we concluded that the strongest hypothesis is not the one with the most verifying evidence, but the one with the least falsifying evidence.

In order to construct a hypothesis with the least falsifying evidence we welcome research published by our industry peers to dissimilate insights that challenge our hypotheses. When we combined all the evidence with links on the diamond model, we discovered that one essential link wasn’t made, the link between adversary and victim.

Seeking New Insights Between Adversary and Victim

Despite published research, the direct link between adversary and victim remained relatively unexplored. Unlike most cybercrime, ransomware and digital extortion frequently creates a strong social connection between adversary and victim. The adversary has certain needs and views the victim as the means to fulfill those needs. The connection between an adversary and victim often generates valuable insights, especially in cases where (extensive) negotiation take place.

Luckily, one of our NoMoreRansom partners, Coveware, is specialized in ransomware negotiations and has gained valuable insights help us link adversary and victim.

The social connection between Adversary and Victim

Ransom Amounts and Negotiations

By aggregating ransomware negotiation and payment data, Coveware is able to identify strain-specific ransomware trends. With regards to Ryuk, it should be noted that ransom amounts average more than 10x the average, making it the costliest type of ransomware. Coveware also observed that some Ryuk ransoms were highly negotiable, while others were not. The bar-belled negotiation results generated an average ransom payment of $71k, a 60% discount from an average opening ask of $145k.

The bar-belled negotiation outcomes meant that some victims were stonewalled. These victims either lost their data or took on staggering financial risk to pay the ransom. The outcomes also imply that in certain cases the adversary would rather receive infrequent large windfalls (often in excess of 100BTC), while in other cases the adversary was keen to monetize every attack and accept lower amounts to ensure payment. This difference in modus operandi suggests that more than one cyber-criminal group is operating Ryuk ransomware.

Ransom Note and Negotiation Similarities and Differences

Similarities between Bitpaymer and Ryuk ransom notes have been observed before. While it is not uncommon for ransom notes to share similar language, sequences of phrases tend to remain within the same ransomware family. Slight copy+paste modifications are made to the ransom text as a variant is passed along to different groups, but large alterations are rarely made. Below is a comparison of a Bitpaymer initial email (left) and a standard Ryuk initial email (right).

A comparison of a Bitpaymer initial email (left) and a standard Ryuk initial email (right)

The shared language implies that text once unique to a Bitpaymer campaign was borrowed for a Ryuk campaign, possibly by an operator running simultaneous ransom campaigns of both Bitpaymer and Ryuk or the imitation can be considered as the sincerest form of flattery.

Different Initial Email Response May Be Different Adversaries?

A more dramatic scripted communication difference has been observed in the initial email response from Ryuk adversaries. The initial email response is typically identical within ransomware families belonging to the same campaign. When significant differences in length, language, and initial ransom amount appear in the initial email response we are comfortable assuming they belong to unique groups with unique modus operandi. This would mean that Ryuk in being spread by more than one actor group.

Below are two such Ryuk examples:

 

Post Payment Bitcoin Activity

A final indicator that multiple groups are running simultaneous Ryuk campaigns can be observed in the activity of bitcoin after it hits a ransom address. Surprisingly, despite the differences between negotiation outcome and initial communications, Coveware observed little difference between the BTC wallets (blacked out to protect victims) associated with the above cases. Initial comparison showed no meaningful discrepancy in difference between the time of a ransom payment and the time of a corresponding withdraw. Additionally, the distribution of funds upon withdrawal was consistently split between two addresses. Coveware will continue to monitor the funds associated with campaigns for meaningful indicators.

Ryuk Negotiating Profiles

With few exceptions, the rest of the email replies during a Ryuk extortion negotiation are extremely short and blunt. Typical replies and retorts are generally less than 10 written words and often just a single number if the ransom amount is the point of discussion. This correspondence is unique to Ryuk.

One reply did contain quite a remarkable expression; “à la guerre comme à la guerre,” to contextualize the methods and reasons for the cyber criminals’ attacks on western companies. The French expression originates from the seventeenth century and literally translates to “in war as in war” and loosely translates to: “In Harsh times one has to do with what’s available”. The striking thing about this expression is that is prominently featured in volume 30 of the collected works of the Soviet Revolutionary leader Vladimir Lenin. Lenin uses the expression to describe the struggle of his people during the war against western capitalism.

This concept of “The capitalistic West versus the Poor east” is actually something McAfee ATR sees quite often expressed by cyber criminals from some of the Post-Soviet republics. This expression may be a clear indicator of the origin and cultural view of the criminals behind Ryuk.

Ryuk poses existential risk to certain industries

Even though the average ransom discounts of Ryuk are large (~60%), the absolute level of the ransom is extreme. Accordingly, we have seen evidence that links ransom demands to the size of the network footprint of the victim company. However, this doesn’t mean that the ransom demand correlates to the victims actual operational and financial size.

Companies in the IT Hosting and the Freight and Logistics industries have been particularly susceptible to this discrepancy. Coveware has assisted at least 3 companies that have had to unwind their business when an affordable ransom amount, could not be reached. Typically, downtime costs are 10x the ransom amount, but in these industries downtime costs can be particularly extreme.

IT Hosting companies are of note as the size and number of their servers can make them appear like a large organization. Unfortunately, the business of hosting involves high fixed costs, low operating margins, and zero tolerance of downtime by end clients.  Hosting companies that get attacked typically have a few hours to restore service before their clients drop them for alternatives. Moreover, these companies suffer irreparable harm to their reputations, and may trigger SLA breaches that leave them exposed to liability.  The inability to pay a six-figure ransom has caused multiple hosting companies to shut down.

Freight and Logistics firms are also acutely exposed. These firms also present like larger firms given the volume of data they move and their network footprint. Additionally, attacks against Freight and Logistics firms can cause immediate supply chain issues for the victims’ end clients, who are subsequently forced to route through other service providers. Similar to IT Hosting, Freight and Logistics firms have low operating margins and end clients with little tolerance for service interruptions. The inability to pay or negotiate a large ransom has materially impacted several firms in this industry.

Ryuk Decryptor findings and issues

When victims do pay the exorbitant ransom amount, the criminals will provide a decryptor to unlock a their files. This decryptor is actually framework that needs to be loaded with a victim’s private RSA key, provided by the criminals, in order to decrypt. Ensuring that the provided decryptor will only work for this specific victim. This setup allows the criminals to quickly load a victim’s key in the framework and offer a custom decryptor with minimal code change while the underlaying framework remains the same.

From Coveware’s experience we have learned that the decryption process is quite cumbersome and full of possible fatal errors. Luckily Coveware was able to share the Ryuk decryptor with McAfee ATR in order to take a closer look at the issues and level of sophistication of the decryptor.

Once launched the first thing the decryptor does is to search the HKEY_CURRENT_USER Hive for a value pair named “svchos” in the path “SOFTWARE\Microsoft\Windows\CurrentVersion\Run” and delete the specific entry. This removes the persistence of the malware. Afterwards it will reboot the system and remove any remaining Ryuk malware still receding on the system.

Deleting the “svchos” value from the registry.

Once rebooted the user needs to run the tool again and the decryptor will provide two options to decrypt.

  • Decryption per file
  • Automatic decryption

The main interface of the Ryuk decryptor with the different menu options.

HERMES File maker

During the decryption process we have found that the decryptor searches for the known file marker string HERMES which is located in the encrypted file.

The HERMES marker clearly visible within the file

The fact that Ryuk ransomware adds HERMES filemarker string was already known, but discovering this specific check routine in the decryptor strengthens the hypotheses that Ryuk is a slightly modified version of Hermes2.1 ransomware kit that is sold online even more.

Decryptor Issues

While examining the decryptor we were astonished by the lack of sophistication and the amount of errors that resided within the code. Some of the most prominent issues were:

  • If there is a space in the Windows file path the decryptor will fail the decryption process.
  • If there is a quotation mark (“) in the file path the decryptor will report an error that it cannot find the specific file.
  • The decryptor uses the “GetVersionExW” function to determine the windows version, from Windows 8.1. the value returned by this API has changed and the decryptor isn’t designed to handle this value.
  • The decryptor doesn’t remove the .RYUK extension and replace it with the original extension. So, there is no way the name of the file can give an indication towards the type of the file, something that can be extremely labor intensive for enterprise victims.
  • When choosing the manual option in the decryptor, the user has to supply a path of the specific file or choose “0” to finish. However, choosing a “0” will put the decryptor into an infinite loop.

Looking at the decryptor, it is very worrisome to see that the criminals behind Ryuk can get away with such bad programming. It shows a clear lack of empathy towards their victims and the absence of solid coding skills. Victims who do pay the exorbitant ransom demand are far from in the clear. The decryptor offered by the criminals has a very high risk of malfunctioning, resulting in permanent damage to their precious files. Victims should always make an exact copy of the encrypted hard disk before trying to use the decryptor.

Call to action in piecing the different parts together

By combining all the fresh insights with the information that was already discovered by ourselves and industry peers we can start defining our leading hypotheses around Ryuk. Based on this hypothesis, we will actively look for falsifying evidence. We encourage the security community to participate in this process. We realize that only by collaboration can we piece the different parts of the Ryuk puzzle together.

By now it should be without question that involvement of the DPRK is the least likely hypothesis. Our leading Hypothesis on Ryuk until proven otherwise is;

Ryuk is a direct descendant from Hermes2.1 with slight modifications, based on the code overlap in the ransomware as well as the decryptor. Ryuk is not designed to be used in a largescale corporate environment, based on all the scalability issues in the decryptor. At this moment there are several actors or actor-groups spreading Ryuk, based on the extortion modus operandi and different communications with the victims. The actors or actor-groups behind Ryuk have a relationship with one of the Post-Soviet republics, based on the Russian found in one of the encrypted files and the cultural references observed in the negotiations. The actors behind Ryuk most likely have an affiliation or relationship with the actors behind Trickbot and, based on their TTP, are better skilled at exploitation and lateral movement than pure Ransomware development.

Conclusion

In the last seven months Ryuk has proven to be a highly profitable form of ransomware, despite the poor programming behind it and its decryptor. The criminals have proven to be ruthless and several of their victims were forced to wind down their businesses after they were unable to afford the exorbitant ransom.

When a company does give in to the high demands it is extra painful to see a situation occur where they are permanently unable to recover their files due to the faulty decryptor.

A solid data loss prevention strategy still remains the best advice against all forms of ransomware, for general prevention advice please visit NoMoreRansom. Always seek professional assistance when you are faced with a targeted ransomware attack such as Ryuk.

The post Ryuk, Exploring the Human Connection appeared first on McAfee Blogs.