McAfee Labs


Spanish MSSP Targeted by BitPaymer Ransomware

Spanish MSSP Targeted by BitPaymer Ransomware

Initial Discovery

This week the news hit that several companies in Spain were hit by a ransomware attack. Ransomware attacks themselves are not new but, by interacting with one of the cases in Spain, we want to highlight in this blog how well prepared and targeted an attack can be and how it appears to be customized specifically against its victims.

In general, ransomware attacks are mass-spread attacks where adversaries try to infect many victims at the same time and cash out quickly. However, this has significantly changed over the past two years where more and more ransomware attacks are targeting high-value targets in all kinds of sectors.

Victims are infected with a different type of malware before the actual ransomware attack takes place. It looks like adversaries are using the infection base to select or purchase the most promising victims for further exploitation and ransomware, in a similar way to how the sale of Remote Desktop Access on underground forums or private Telegram channels is being used for victim selection for ransomware attacks.

In the following paragraphs, we will take you step by step through the modus operandi of the attack stages and most important techniques used and mapped against the MITRE ATT&CK Framework.

The overall techniques observed in the campaign and flow visualization:

Spanish MSSP Targeted by BitPaymer Ransomware

Technical Analysis

The overall campaign is well known in the industry and the crew behind it came back to the scene reusing some of the TTPs observed one year ago and adding new ones like: privilege escalation, lateral movement and internal reconnaissance.

Spanish MSSP Targeted by BitPaymer Ransomware

Patient 0 – T1189 Drive-by Compromise

The entry point for these types of campaigns starts with a URL that points the user to a fake website (in case the website is compromised) or a legitimate page (in case they decided to use a pay-per-install service) using social engineering techniques; the user gets tricked to download the desired application that will use frameworks like Empire or similar software to download and install next stage malware which, in this case, is Dridex.

First infection – T1090 Connection Proxy

These types of attacks are not limited to one type of malware; we have observed it being used by:

  • Azorult
  • Chthonic
  • Dridex

It is currently unclear why one would select one malware family above the other, but these tools allow for remote access into a victim’s network. This access can then be used by the actor as a launchpad to further exploit the victim’s network with additional malware, post-exploitation frameworks or the access can be sold online.

For quite some time now, Dridex’s behavior has changed from its original form. Less Dridex installs are linked to stealing banking info and more Dridex infections are becoming a precursor to a targeted ransomware attack.

This change or adaptation is something we have observed with other malware families as well.

For this campaign, the Dridex botnet used was 199:

Spanish MSSP Targeted by BitPaymer Ransomware

Information Harvesting – T1003 Credential Dumping

From the infection, one or multiple machines are infected, and the next step is to collect as many credentials as they can to perform lateral movement. We observed the use of Mimikatz to collect (high privileged) credentials and re-use them internally to execute additional software in the Active Directory servers or other machines inside the network.

The use of Mimikatz is quite popular, having been observed in the modus operandi of more than 20 different threat actors.

Lateral Movement – T1086 PowerShell

The use of PowerShell helps attackers to automate certain things once they are in a network. In this case, we observed how Empire was used for different sock proxy PowerShell scripts to pivot inside the network:

Spanish MSSP Targeted by BitPaymer Ransomware

Extracting information about the IP found in the investigation, we observed that the infrastructure for the Dridex C2 panels and this proxy sock was shared.

Spanish MSSP Targeted by BitPaymer Ransomware

PowerShell was also used to find specific folders inside the infected systems:

Spanish MSSP Targeted by BitPaymer Ransomware

A reason for an attacker to use a PowerShell based framework like Empire, is the use of different modules, like invoke-psexec or invoke-mimikatz, that can execute remote processes on other systems, or get credentials from any of the systems where it can run Mimikatz. When deployed right, these modules can significantly increase the speed of exploitation.

Once the attackers collected enough high privileged accounts and got complete control over the Active Directory, they would then distribute and execute ransomware on the complete network as the next step of their attack, in this case BitPaymer.

Ransomware Detonation – T1486 Data Encrypted for Impact

BitPaymer seemed to be the final objective of this attack. The actors behind BitPaymer invest time to know their victims and build a custom binary for each which includes the leet-speek name of the victim as the file extension for the encrypted files, i.e. “financials.<name_of_victim>”.

In the ransomware note, we observed the use of the company name too:

Spanish MSSP Targeted by BitPaymer Ransomware


  • One of the remote proxy servers used in the operation shares the same infrastructure as one of the C2 panels used by Dridex.
  • We observed how a Dridex infection served as a launch point for an extensive compromise and BitPaymer ransomware infection.
  • Each binary of Bitpaymer is specially prepared for every single target, including the extension name and using the company name in the ransomware note.
  • Certain Dridex botnet IDs are seen in combination with targeted BitPaymer infections.
  • Companies must not ignore indicators of activity from malware like Dridex, Azorult or NetSupport; they could be a first indicator of other malicious activity to follow.
  • It is still unclear how the fake update link arrived at the users but in similar operations, SPAM campaigns were most likely used to deliver the first stage.

McAfee Coverage

Based on the indicators of compromise found, we successfully detect them with the following signatures:

  • RDN/Generic.hbg
  • Trojan-FRGC!7618CB3013C3
  • RDN/Generic.dx

The C2 IPs are tagged as a malicious in our GTI.

McAfee ATD Sandbox Detonation

Advanced Threat Detection (ATD) is a specialized appliance that identifies sophisticated and difficult to detect threats by executing suspicious malware in an isolated space, analyzing its behavior and assessing the impact it can have on an endpoint and on a network.

For this specific case, the ATD sandbox showcases the activity of Bitpaymer in a system:

Spanish MSSP Targeted by BitPaymer Ransomware

We observe the use of icacls and takeown to change permissions inside the system and the living off the land techniques are commonly used by different type of malware.

ATD Sandbox extracted behavior signatures observing Bitpaymer detonation in the isolated environment:

Spanish MSSP Targeted by BitPaymer Ransomware

Having the opportunity to detonate malware in this environment could give indicators about the threat types and their capabilities.

McAfee Real Protect

Analysis into the samples garnered from this campaign would have been detected by Real Protect. Real Protect is designed to detect zero-day malware in near real time by classifying it based on behavior and static analysis. Real Protect uses machine learning to automate classification and is a signature-less, small client footprint while supporting both offline mode and online mode of classification. Real Protect improves detection by up to 30% on top of .DAT and McAfee Global Threat Intelligence detections, while producing actionable threat intelligence.

Spanish MSSP Targeted by BitPaymer Ransomware


We have a YARA rule available on our ATR GitHub repository to detect some of the versions of BitPaymer ransomware.


Spanish MSSP Targeted by BitPaymer Ransomware

The post Spanish MSSP Targeted by BitPaymer Ransomware appeared first on McAfee Blogs.


Buran Ransomware; the Evolution of VegaLocker

Buran Ransomware; the Evolution of VegaLocker

McAfee’s Advanced Threat Research Team observed how a new ransomware family named ‘Buran’ appeared in May 2019. Buran works as a RaaS model like other ransomware families such as REVil, GandCrab (now defunct), Phobos, etc. The author(s) take 25% of the income earned by affiliates, instead of the 30% – 40%, numbers from notorious malware families like GandCrab, and they are willing to negotiate that rate with anyone who can guarantee an impressive level of infection with Buran. They announced in their ads that all the affiliates will have a personal arrangement with them.

For this analysis we present, we will focus on one of the Buran hashes:

Buran Ransomware; the Evolution of VegaLocker

We will highlight the most important observations when researching the malware and will share protection rules for the endpoint, IOCs and a YARA rule to detect this malware.

Buran Ransomware Advertisement

This ransomware was announced in a well-known Russian forum with the following message:


Buran is a stable offline cryptoclocker, with flexible functionality and support 24/7.


Reliable cryptographic algorithm using global and session keys + random file keys;
Scan all local drives and all available network paths;
High speed: a separate stream works for each disk and network path;
Skipping Windows system directories and browser directories;
Decryptor generation based on an encrypted file;
Correct work on all OSs from Windows XP, Server 2003 to the latest;
The locker has no dependencies, does not use third-party libraries, only mathematics and vinapi;

The completion of some processes to free open files (optional, negotiated);
The ability to encrypt files without changing extensions (optional);
Removing recovery points + cleaning logs on a dedicated server (optional);
Standard options: tapping, startup, self-deletion (optional);
Installed protection against launch in the CIS segment.


They are negotiated individually for each advert depending on volumes and material.

Start earning with us!


The announcement says that Buran is compatible with all versions of the Windows OS’s (but during our analysis we found how, in old systems like Windows XP, the analyzed version did not work) and Windows Server and, also, that they will not infect any region inside the CIS segment. Note: The CIS segment belongs to ten former Soviet Republics: Armenia, Belarus, Kazakhstan, Kyrgyzstan, Moldova, Russia, Tajikistan, Turkmenistan, Ukraine, and Uzbekistan.

Rig Exploit Kit as an Entry Vector

Based upon the investigation we performed, as well as research by “nao_sec” highlighted in June 2019, we discovered how Buran ransomware was delivered through the Rig Exploit Kit. It is important to note how the Rig Exploit Kit is the preferred EK used to deliver the latest ransomware campaigns.

Buran Ransomware; the Evolution of VegaLocker


The Rig Exploit Kit was using CVE-2018-8174 (Microsoft Internet Explorer VBScript Engine, Arbitrary Code Execution) to exploit in the client-side. After successful exploitation this vulnerability will deliver Buran ransomware in the system.

Static Analysis

The main packer and the malware were written in Delphi to make analysis of the sample more complicated. The malware sample is a 32-bit binary.

Buran Ransomware; the Evolution of VegaLocker


In our analysis we detected two different versions of Buran, the second with improvements compared to the first one released.

Buran Ransomware; the Evolution of VegaLocker


The goal of the packer is to decrypt the malware making a RunPE technique to run it from memory. To obtain a cleaner version of the sample we proceed to dump the malware from the memory, obtaining an unpacked version.

Country Protection

Checking locales has become quite popular in RaaS ransomware as authors want to ensure they do not encrypt data in certain countries. Normally we would expect to see more former CIS countries but, in this case, only three are verified.

Buran Ransomware; the Evolution of VegaLocker


This function gets the system country and compares it with 3 possible results:

  • 0x177 -> BELARUS
  • 0x17C -> UKRAINE

It is important to note here that the advertising of the malware in the forums said it does not affect CIS countries but, with there being 10 nations in the region, that is obviously not entirely accurate.

If the system is determined to be in the Russian Federation, Belarus or Ukraine the malware will finish with an “ExitProcess”.

The next action is to calculate a hash based on its own path and name in the machine. With the hash value of 32-bits it will make a concat with the extension “.buran”. Immediately after, it will create this file in the temp folder of the victim machine. Importantly, if the malware cannot create or write the file in the TEMP folder it will finish the execution; the check will be done extracting the date of the file.

Buran Ransomware; the Evolution of VegaLocker


If the file exists after the check performed by the malware, the temporary file will be erased through the API “DeleteFileW”.

Buran Ransomware; the Evolution of VegaLocker


This function can be used as a kill switch to avoid infection by Buran.

Buran ransomware could accept special arguments in execution. If it is executed without any special argument, it will create a copy of Buran with the name “ctfmon.exe” in the Microsoft APPDATA folder and will launch it using ShellExecute, with the verb as “runas”. This verb is not in the official Microsoft SDK but, if we follow the MSDN documentation to learn how it works, we can deduce that the program will ignore its own manifest and prompt the UAC to the user if the protection is enabled.

This behavior could change depending on the compilation options chosen by the authors and delivered to the affiliates.

According to the documentation, the function “CreateProcess” checks the manifest, however in Buran, this is avoided due to that function:

Buran Ransomware; the Evolution of VegaLocker


Buran in execution will create a registry key in the Run subkey section pointing to the new instance of the ransomware with a suffix of ‘*’. The meaning of this value is that Buran will run in safe mode too:

Buran Ransomware; the Evolution of VegaLocker


The writing operation in the registry is done using the “reg” utility, using a one-liner and concatenating different options with the “&” symbol. This method through “reg.exe” avoids a breakpoint in the main binary.

Buran Ransomware; the Evolution of VegaLocker


Buran implements this technique with the objective of making analysis of the sample complicated for malware analysts looking at reverse engineering profiles. After these operations, the old instance of the ransomware will die using “Exit Process”.

Analysis of the Delphi code show that the 2nd version of Buran will identify the victim using random values.

Buran Ransomware; the Evolution of VegaLocker


After that it will decrypt a registry subkey called “SoftwareBuranKnock” in the HKEY_CURRENT_USER hive. For the mentioned key it will check the actual data of it and, if the key does not exist, it will add the value 0x29A (666) to it. Interestingly, we discovered that GandCrab used the same value to generate the ransom id of the victim. If the value and subkey exists the malware will continue in the normal flow; if not, it will decrypt a URL ,“”, and make a connection to this domain using a special user agent:

Buran Ransomware; the Evolution of VegaLocker


Buran Ransomware; the Evolution of VegaLocker

As mentioned, the referrer will be the victim identifier infected with Buran.

The result of this operation is the writing of the subkey previously checked with the value 0x29A, to avoid repeating the same operation.

After this action the malware will enumerate all network shares with the functions :

  • WNetOpenEnumA,
  • WNetEnumResourceA
  • WNetCloseEnum

This call is made in a recursive way, to get and save all discovered shared networks in a list. This process is necessary if Buran wants to encrypt all the network shares as an addition to the logical drives. Buran will avoid enumerating optical drives and other non-mounted volumes. The result of those operations will be saved for Buran to use later in the encryption process.

The ransom note is crypted inside the binary and will be dumped in execution to the victim’s machine. Inside this ransom note, the user will find their victim identifier extracted with the random Delphi function mentioned earlier. This identification is necessary to track their infected users to affiliates to deliver the decryptor after the payment is made.

In the analysis of Buran, we found how this ransomware blacklists certain files and folders. This is usually a mechanism to ensure that the ransomware does not break its functionality or performance.

Blacklisted folders in Buran:

Buran Ransomware; the Evolution of VegaLocker

Blacklisted files in Buran:

Buran Ransomware; the Evolution of VegaLocker

The encryption process will start with special folders in the system like the Desktop folder. Buran can use threads to encrypt files and during the process will encrypt the drive letters and folders grabbed before in the recognition process.

The ransom note will be written to disk with the name “!!! YOUR FILES ARE ENCRYPTED !!!” with the following content:

Buran Ransomware; the Evolution of VegaLocker


Each file crypted is renamed to the same name as before but with the new extension of the random values too.

For example: “rsa.bin.4C516831-800A-6ED2-260F-2EAEDC4A8C45”.

All the files encrypted by Buran will contain a specific filemarker:

Buran Ransomware; the Evolution of VegaLocker


In terms of encryption performance, we found Buran slower compared to other RaaS families. According to the authors’ advertisement in the underground forums, they are continually improving their piece of ransomware.

Buran Version 1 vs Buran Version 2

In our research we identified two different versions of Buran. The main differences between them are:

Shadow copies delete process:

In the 2nd version of Buran one of the main things added is the deletion of the shadow copies using WMI.

Buran Ransomware; the Evolution of VegaLockerBackup catalog deletion:

Another feature added in the new version is the backup catalog deletion. It is possible to use the Catalog Recovery Wizard to recover a local backup catalog.

Buran Ransomware; the Evolution of VegaLocker

System state backup deletion:

In the same line of system destruction, we observed how Buran deletes in execution the system state backup in the system:

Buran Ransomware; the Evolution of VegaLocker

Ping used as a sleep method:

As a poor anti-evasion technique, Buran will use ping through a ‘for loop’ in order to ensure the file deletion system.

Buran Ransomware; the Evolution of VegaLocker

The ransom note changed between versions:

Buran Ransomware; the Evolution of VegaLocker

VegaLocker, Jumper and Now Buran Ransomware

Despite the file marker used, based on the behavior, TTPs and artifacts in the system we could identify that Buran is an evolution of the Jumper ransomware. VegaLocker is the origin for this malware family.

Malware authors evolve their malware code to improve it and make it more professional. Trying to be stealthy to confuse security researchers and AV companies could be one reason for changing its name between revisions.

This is the timeline of this malware family:

Buran Ransomware; the Evolution of VegaLocker

Similarities in Behavior:

Files stored in the temp folder:


Buran Ransomware; the Evolution of VegaLocker


Buran Ransomware; the Evolution of VegaLocker


Buran Ransomware; the Evolution of VegaLocker

Registry changes:


Buran Ransomware; the Evolution of VegaLocker


Buran Ransomware; the Evolution of VegaLocker

Extension overlapping:

In one of the variants (Jumper) it is possible to spot some samples using both extensions:

  • .vega
  • .jamper

Shadow copies, backup catalog and systembackup:

In the analyzed samples we saw how VegaLocker used the same methods to delete the shadow copies, backup catalog and the systembackup.


  • RDN/Ransom
  • Ransomware-GOS!E60E767E33AC
  • Ransom
  • RDN/Ransom
  • RDN/
  • Ransom-Buran!

Expert Rule:

Buran Ransomware; the Evolution of VegaLocker

Indicators of Compromise

Buran Ransomware; the Evolution of VegaLocker


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

  • Disabling Security Tools
  • Email Collection
  • File and Directory Discovery
  • File Deletion
  • Hooking
  • Kernel Modules and Extensions
  • Masquerading
  • Modify Registry
  • Network Service Scanning
  • Peripheral Device Discovery
  • Process Injection
  • Query Registry
  • Registry Run Keys / Start Folder
  • Remote Desktop Protocol
  • Remote System Discovery
  • Service Execution
  • System Time Discovery
  • Windows Management Instrumentation


We created a YARA rule to detect Buran ransomware samples and the rule is available in our GitHub repository


Buran represents an evolution of a well-known player in the ransomware landscape. VegaLocker had a history of infections in companies and end-users and the malware developers behind it are still working on new features, as well as new brands, as they continue to generate profits from those actions. We observed new versions of Buran with just a few months between them in terms of development, so we expect more variants from the authors in the future and, perhaps, more brand name changes if the security industry puts too much focus on them. We are observing an increase in ransomware families in 2019, as well as old players in the market releasing new versions based on their own creations.

For the binaries, all of them appeared with a custom packer and already came with interesting features to avoid detection or to ensure the user must pay due to the difficulty of retrieving the files. It mimics some features from the big players and we expect the inclusion of more features in future developments.

Buran is slower than other ransomware families we observed, and samples are coded in Delphi which makes reverse engineering difficult.

The post Buran Ransomware; the Evolution of VegaLocker appeared first on McAfee Blogs.


Office 365 Users Targeted by Voicemail Scam Pages

Office 365 Users Targeted by Voicemail Scam Pages

Over the past few weeks McAfee Labs has been observing a new phishing campaign using a fake voicemail message to lure victims into entering their Office 365 email credentials. At first, we believed that only one phishing kit was being used to harvest the user’s credentials. However, during our investigation, we found three different malicious kits and evidence of several high-profile companies being targeted. McAfee Customers using VSE, ENS, Livesafe, WebAdvisor and MGW are protected against this phishing campaign.

The attack begins when the victim receives an email informing them that they have missed a phone call, along with a request to login to their account to access their voicemail.

An example of the malicious email is shown below:

Office 365 Users Targeted by Voicemail Scam Pages

The phishing email contains a HTML file as an attachment which, when loaded, will redirect the user to the phishing website. There are slight variations in the attachment, but the most recent ones contain an audio recording of someone talking which will lead the victim to believe they are listening to the beginning of a legitimate voicemail.

Office 365 Users Targeted by Voicemail Scam Pages

The HTML code which plays the recording is shown below:

Office 365 Users Targeted by Voicemail Scam Pages

Once redirected, the victim is shown the phishing page which asks them to log into their account. The email address is prepopulated when the website is loaded; this is another trick to reinforce the victim’s belief that the site is legitimate.

Office 365 Users Targeted by Voicemail Scam Pages

When the password is entered, the user is presented with the following successful login page and redirected to the login page.

Office 365 Users Targeted by Voicemail Scam Pages

We observed the following filenames being used for the attachments:

  • 10-August-2019.wav.html [Format: DD-Month-YYYY.wav.html]
  • 14-August-2019.html [Format: DD-Month-YYYY.html]
  • Voice-17-July2019wav.htm [Format: Voice- DD-MonthYYYYwav.htm]
  • Audio_Telephone_Message15-August-2019.wav.html [Format: Audio_Telephone_MessageDD-Month-YYYY.wav.html]

Phishing Sites

As explained in the introduction, we were surprised to observe three different phishing kits being used to generate the malicious websites. All three look almost identical but we were able to differentiate them by looking at the generated HTML code and the parameters which were accepted by the PHP script.

Voicemail Scmpage 2019 (Not a typo)

The first kit is being sold on an ICQ channel and the creator advertises it on social media. The kit goes by the name of ‘Voicemail Scmpage 2019’ and operates on a license key basis, where the license key is checked prior to the phishing site being loaded.

A snippet of the generated HTML code is shown below:

Office 365 Users Targeted by Voicemail Scam Pages

A file, data.txt, is created on the compromised website and it contains a list of visitors, including their IP address, web browsers and the date.

Office 365 Users Targeted by Voicemail Scam Pages

The following data is harvested from the victims and emailed to the owner of the phishing site:

  • Email
  • Password
  • IP Address
  • Region (Location)

Office 365 Information Hollar

The second phishing kit we discovered is called ‘Office 365 Information Hollar’. This kit is very similar to ‘Voicemail Scmpage 2019’ and gathers the same data, as shown in the image below:

Office 365 Users Targeted by Voicemail Scam Pages

Third “Unnamed” Kit

The final phishing kit is unbranded, and we could not find any attribution to it. This kit makes use of code from a previous malicious kit targeting Adobe users back in 2017. It is possible that the original author from 2017 has modified this kit, or perhaps more likely the old code has been re-used by a new group.

Office 365 Users Targeted by Voicemail Scam Pages

This kit also harvests the same data as the previous two. The ‘Unnamed Kit’ is the most prevalent malicious page we have observed while tracking these voicemail phishing campaigns.

Targeted Industries

During our investigation we observed the following industries being targeted with these types of phishing emails:

Office 365 Users Targeted by Voicemail Scam Pages

[Services includes tourism, entertainment, real estate and others which are too small to group]

A wide range of employees were targeted, from middle management to executive level staff. We believe that this is a ‘Phishing’ and ‘Whaling’ campaign.


The goal of malicious actors is to harvest as many credentials as possible, to gain access to potentially sensitive information and open the possibility of impersonation of staff, which could be very damaging to the company. The entered credentials could also be used to access other services if the victim uses the same password, and this could leave them open to a wider of range targeted attacks.

What sets this phishing campaign apart from others is the fact that it incorporates audio to create a sense of urgency which, in turn, prompts victims to access the malicious link. This gives the attacker the upper hand in the social engineering side of this campaign.

We urge all our readers to be vigilant when opening emails and to never open attachments from unknown senders. We also strongly advise against using the same password for different services and, if a user believes that his/her password is compromised, it is recommended to change it as soon as possible

It is highly recommended to use Two-Factor Authentication (2FA) since it provides a higher level of assurance than authentication methods based on Single-Factor Authentication (SFA), like the one that many users utilise for their Office 365 accounts.

When possible for enterprise customers, we recommend blocking .html and .htm attachments at the email gateway level so this kind of attack will not reach the final user.

Also, be sure to read our companion blog which details how you can stay safe from such phishing campaigns.

Indicators of Compromise

Email Attachment with the following filename:

10-August-2019.wav.html [Format: DD-Month-YYYY.wav.html]

14-August-2019.html [Format: DD-Month-YYYY.html]

Voice-17-July2019wav.htm [Format: Voice- DD-MonthYYYYwav.htm]

Audio_Telephone_Message15-August-2019.wav.html [Format: Audio_Telephone_MessageDD-Month-YYYY.wav.html]

McAfee Detections

HTML/Phishing.g V2 DAT = 9349, V3 DAT = 3800

HTML/Phishing.av V2 DAT = 9371, V3 DAT = 3821

HTML/ V2 DAT = 9371, V3 DAT = 3821

The hashes of the attachments will not be provided as this will provide information on the potential targets


(Domains (all blocked by McAfee WebAdvisor)






More Information on Phishing Attacks:

The post Office 365 Users Targeted by Voicemail Scam Pages appeared first on McAfee Blogs.


Did You Check Your Quarantine?!

Did You Check Your Quarantine?!

A cost-effective way to detect targeted attacks in your enterprise

While it is easy to get caught up in the many waves of new and exciting protection strategies, we have recently discovered an interesting approach to detect a targeted attack and the related actor(s). Quite surprisingly, a big part of the solution already exists in most enterprises: the tried, tested endpoint security platform. In this case, we used our own McAfee Endpoint Security (ENS). Along with ENS, we used GetQuarantine, a freeware tool from McAfee, and a third-party threat analytics service.

The Problem

We will begin with a working definition of a targeted attack:

A targeted attack is a threat in which a threat actor actively pursues and compromises a specific target. To achieve the goal, the adversary may adapt and improve their attack(s) to counter the victim’s defenses and persist at it for a long period of time.

What does this say? First, the adversary’s objective is to compromise a specific target, not just an arbitrary target. Second, the adversary is skilled enough to know how defenses work and is resourceful enough to actively adapt and improve their attack to beat defenses. Third, the adversary is determined enough to pursue the objective for perhaps an indefinite period of time.

Taken together, the above characteristics challenge most defense technologies. Why so? Because these characteristics run counter to the assumptions on which these technologies are based.

At the heart of it, most defense technologies are signature-based, where the signatures are created either by a human analyst, by a machine, or by using instances of known malicious behavior. The cost of constructing signatures is high and is amortized by using the same signature to defend against the same attack elsewhere.

Twenty years ago, when there were just a few thousand examples of malicious software around, it was relatively easy to find the origin, perpetrators, and the reason for the creation and release of a malicious file or application. Security researchers would manually analyze each sample, carefully identify similarities with previously known samples through sheer memory and label each sample with a unique name. This method worked well because the attacks then were opportunistic and aimed at spreading as wide as possible. This meant that anti-virus companies could discover an attack in one place, extract relevant detection signatures, and send the signature updates to its install base.

Now, security threat intelligence companies receive hundreds of thousands of new malware samples every day. There is simply not enough time or resources to analyze each malware to answer who, what, when, and why? The best any anti-virus software can do is to classify a file into just two bins: good or bad. It is impossible for researchers to manually look at every sample and process them to the same detail as before. To make matters worse, attacks today are targeted. Attackers create one-off variants aimed at a specific enterprise. This makes it virtually impossible to connect attacks across enterprises to understand the attacker.

And therein lies an important problem. Just as the numbers and sophistication of attacks have increased exponentially, the objective of tracking who is behind an attack, and identifying linkages between different malware samples and their authors, and the intent behind an attack, have been lost.

Why should it matter? In the absence of information about who is attempting to breach an organization, defenders are left operating in the dark. They make security decisions based on breaches that happen elsewhere using threat intelligence that is most often irrelevant, and when relevant, is most likely outdated.

The Solution

Analysis of targeted campaigns shows that programs that are part of an attack usually show a couple of similar characteristics. First, the malware or attack mechanism is focused on one enterprise or, at most, one sector and second, the malware program demonstrates evolutionary characteristics where the actor repeatedly unleashes different variants of it. Our proposed solution focuses on these characteristics and tries to uncover targeted campaigns by finding binary semantics between malware found in customer environments and known targeted campaigns.

Our solution strategy is:

Endpoint-security detects a malware sample. It is compared with a sample from a known targeted attack. If the similarity is high, it is a strong indication that the ENS detected sample is a part of that targeted attack and the threat actor is the same.

The strategy is implemented in three building blocks: sample collector, sample storage and targeted attack analysis using third-party threat analytics application.

Sample Collector (GetQuarantine)

Sample collection is performed using McAfee proprietary licensed freeware, GetQuarantine. GetQuarantine is a McAfee e-Policy Orchestrator (ePO) deployable tool that can run on all endpoints protected by McAfee ENS. GetQuarantine runs as an ePO scheduled product deployment task. ENS cleans or deletes items that are detected as threats and saves copies in a non-executable format to the Quarantine folder. The GetQuarantine tool on a scheduled run, checks the quarantine folder and uploads items to the McAfee backend if items are not already uploaded during previous tool runs.

Sample Storage (McAfee Workflow & AWS)

The McAfee workflow backend receives sample submissions from GetQuarantine and stores them in an S3 bucket. Samples are segregated per enterprise and made available for further analysis. Third-party analytics applications like MAGIC can be run on samples to extract targeted attack insights. Analytics services are available to McAfee customers participating in a third-party analytics program. For customers that do not participate in a third-party analytics program, sample processing ends at the McAfee backend layer and the sample eventually gets deleted without further analysis.

Targeted Attack Analysis

For our pilot implementation we used Cythereal MAGIC services. The McAfee backend submits samples to MAGIC for binary similarity analysis. Customers can check analysis reports using Cythereal website. Cythereal is McAfee’s Security Innovation Alliance (SIA) partner.

Cythereal MAGIC™ (malware genomic correlation) is a web-service touted as “BinDiff on Steroids”. The system carries out semantic similarity analysis of programs using advanced program analysis techniques at the assembly instruction-level code. The semantics of the program gives more meaningful insights than structural or behavioral characteristics. MAGIC can find similarity between samples submitted using GetQuarantine and also find variants of those samples from MAGIC’s database. It has the facility to provide alerts for campaign detections and can generate YARA rules that can be used for searching other services, like VirusTotal.

We first tried human-driven in-house analysis using open source tools like SSDEEP, SDHASH, TLSH, etc. to prove the concept of identifying targeted attacks using the binary similarity of samples found in quarantine. Though we were successful in proving this concept with these open source tools, they were not very effective, especially with polymorphic variants, so we explored third-party options and identified Cythereal MAGIC™.


Figure 1 shows the overall architecture of our system:

Did You Check Your Quarantine?!

[Figure 1: McAfee ENS detects a suspicious sample by studying its behavior or other means and then moves the sample file to the quarantine folder. The scheduled execution of the GetQuarantine Tool configured in ePO as a scheduled task submits the sample to the McAfee backend. The third-party analytics app, periodically receives samples from McAfee backend for further analysis.]

Case Study

For a case study, we used samples from a McAfee discovered campaign, Oceansalt. We tested the solution’s ability to group samples using semantic similarity and also tested the solution’s ability to identify new variants of Oceansalt samples.

Illustration of the Solution’s Ability to Group Malware From Quarantine

McAfee Endpoint Security (ENS) detected two samples of Oceansalt (as listed in Table 1). GetQuarantine submitted these samples to the McAfee backend. Targeted attack analysis of these files showed a semantic similarity of 95.1%. The comparison of their control-flow graphs in Figure 2 justifies the high semantic similarity score.

Did You Check Your Quarantine?!

[Table 1: Oceansalt samples reported by McAfee™ security operation center in June-July 2018.]

Did You Check Your Quarantine?!

[Figure 2: Control-flow graph of Oceansalt samples from Table 1]

Illustration of the Solution’s Ability to Link New Variants From the Wild to a Known Targeted Attack

Finally, we come to the use case that motivated this study. Malware belonging to a targeted attack is identified by its file-hashes. However, attackers use polymorphism and other obfuscations to create new variants. Though McAfee ENS may block such variants, it may not link it to the original attack. Targeted attack analytics can help fill this void.

To test the solution’s ability to locate such targeted attacks, we uploaded an Oceansalt sample (MD5: 531DEE019792A089A4589C2CCE3DAC95 [VT]) to MAGIC and identified it as an APT. We then uploaded a large number (thousands) of malware samples via GetQuarantine. As we had thought, targeted attack analytics sent an alert that it had detected variants of Oceansalt (Figure 3).

Did You Check Your Quarantine?!

[Figure 3: Alert about detecting an Oceansalt variant in the quarantine]

MAGIC’s alert was triggered because it found two Oceansalt variants from the wild which were not previously reported by the McAfee SOC or any other global threat intelligence.

Did You Check Your Quarantine?!

[Table 2: Two new variants of Oceansalt samples found using semantic similarity]

Try Your Quarantine

We tested the GetQuarantine-based solution in our lab and found encouraging results. If you would like to try out this solution use the following steps, along with McAfee Endpoint Security (ENS):

  • Download the beta version of GetQuarantine, a proprietary licensed freeware.
  • Deploy it using the ePO ecosystem.
  • On successful sample submission to the McAfee backend, receive an acknowledgment email.

To obtain analysis results from the third-party analytics app, follow these steps:

  • Visit Cythereal MAGIC™.
  • The MAGIC dashboard contains plots with details about various ongoing campaigns.
  • Upon selecting a campaign in the plot, a table with all the associated malware is displayed where the customer can download samples and YARA rules.
  • Whenever MAGIC detects a targeted attack, it sends an alert email to the registered email address of the customer, along with additional threat intelligence, such as information on the threat group, third-party research on the group, and associated IoCs. Customers can also see the list of alerts on the MAGIC website.


As you can see from this exercise, traditional AV still has lot to offer and can play an important role in overall security strategy againt targeted attacks. We can amplify signals coming out of AV detections using tools like GetQuarantine and by running analytics on quarantine artifacts to uncover targeted attacks. We can take an incremental approach in solving targeted attack challenges.

The post Did You Check Your Quarantine?! appeared first on McAfee Blogs.


Using Expert Rules in ENS 10.5.3 to Prevent Malicious Exploits

Using Expert Rules in ENS 10.5.3 to Prevent Malicious Exploits

Expert Rules are text-based custom rules that can be created in the Exploit Prevention policy in ENS Threat Prevention 10.5.3+. Expert Rules provide additional parameters and allow much more flexibility than the custom rules that can be created in the Access Protection policy. It also allows system administration to control / monitor an endpoint system at a very granular level. Expert rules do not rely on User-Mode hooking; hence they have very minimal impact on a system’s performance. This blog is created as a basic guide to show our customers how to create them and which threats they can help block. Further detailed information can be found in the conclusion.

How Expert Rules work

The following sections show how to add Expert rules via EPO and ENS.

Adding an Expert Rule from EPO

1. Select System Tree | Subgroup (e.g.: ens_10.6.0) | Assigned Policies | Product (Endpoint Security Threat Prevention) | Exploit Prevention (My Default)

Using Expert Rules in ENS 10.5.3 to Prevent Malicious Exploits

2. Navigate to Signatures and click on Add Expert Rule.

Using Expert Rules in ENS 10.5.3 to Prevent Malicious Exploits

3. In the Rules section, complete the fields.

a. Select the severity and action for the rule. The severity provides information only; it has no select on the rule action.

b. Select the type of rule to create. The Rule content field is populated with the template for the selected type.

c. Change the template code to specify the behavior of the rule.

Using Expert Rules in ENS 10.5.3 to Prevent Malicious Exploits

When you select a new class type, the code in the Rule content field is replaced with the corresponding template code. Endpoint Security assigns the ID number automatically, starting with 20000. Endpoint Security does not limit the number of Expert Rules you can create.

4. Save the rule, then save the settings.

5. Enforce the policy to a client system.

6. Validate the new Expert Rule on the client system.

Adding an Expert Rule directly at the Endpoint:

If we need to add an expert rule from EPO it will be pushed to all endpoints of an entire EPO “WORKGROUP”. There could be situations where expert rules are required to be applied in one/two systems or ENS systems which are not managed by EPO (non-corporate environment where ENS is installed from a standalone setup); in those cases, the expert rule must be added directly at the endpoint. Expert rules can be written and applied directly at the Endpoint system using McAfee Endpoint Security UI. Steps are below:

1. Open McAfee Endpoint Security. Go to Settings.

Using Expert Rules in ENS 10.5.3 to Prevent Malicious Exploits

2. Go to Threat Prevention | Show Advanced.

Using Expert Rules in ENS 10.5.3 to Prevent Malicious Exploits

3. Scroll Down to Expert Rule Section and then click on Add Expert Rule.

Using Expert Rules in ENS 10.5.3 to Prevent Malicious Exploits

4. The expert rule compiler should pop up where an end user can directly write and compile expert rules and, upon compilation, enforce the rules to the system.

Using Expert Rules in ENS 10.5.3 to Prevent Malicious Exploits

If there is no syntax error in the expert rule it can be applied in the system by clicking on the Enforce button. In case there is a syntax error, the details can be found in log file  %ProgramData%McAfeeEndpoint SecurityLogsExploitPrevention_Debug.log

Testing the Rules

When new rules are created, they should first be tested in ‘Report’ mode so that the detections can be observed. When enough confidence in the rule has been gained, it can be turned to ‘Block’ mode.

Expert Rule Examples:


Basic Rule:

The following rule will detect an instance of cmd.exe creating any file at c:temp. Please note that cmd.exe might be run by any user and from any part of the system.

Rule {

Process {

Include OBJECT_NAME { -v “cmd.exe” }


Target {

Match FILE {

Include OBJECT_NAME { -v “c:temp**” }

Include -access “CREATE”





Rules which target specific malicious behavior:

The following rules can be created to help block specific malicious activity which is performed by various malware families and attack techniques.


Expert Rule to Block Remote Process Injection [MITRE Technique Process Injection T1055]:

Rule {

Process {

Include OBJECT_NAME { -v “**” }

Exclude OBJECT_NAME { -v “SYSTEM” }

Exclude OBJECT_NAME { -v “%windir%System32WBEMWMIPRVSE.EXE” }

Exclude OBJECT_NAME { -v “%windir%System32CSRSS.EXE” }

Exclude OBJECT_NAME { -v “%windir%System32WERFAULT.EXE” }

Exclude OBJECT_NAME { -v “%windir%System32SERVICES.EXE” }



Target {

Match THREAD {

Include OBJECT_NAME { -v “**” }


Exclude OBJECT_NAME { -v “%windir%System32WERFAULT.EXE” }

Include -access “WRITE”





Expert Rule which prevents powershell.exe and powershell_ise.exe process from dumping credentials by accessing lsass.exe memory [ MITRE Technique Credential Dumping T1003 ]:

Rule {

Process {

Include OBJECT_NAME {  -v “powershell.exe”  }

Include OBJECT_NAME {  -v “powershell_ise.exe”  }

Exclude VTP_PRIVILEGES -type BITMASK { -v 0x8 }


Target {


Include OBJECT_NAME {   -v  “lsass.exe”  }

Include -nt_access “!0x10”

Exclude -nt_access “!0x400”





Expert Rule which prevents creation of a suspicious task (PowerShell script or batch file) using “SchTasks.exe” utility [MITRE Technique Scheduled Task T1053]:

Rule {

Process {

Include OBJECT_NAME { -v  “SchTasks.exe” }

Include PROCESS_CMD_LINE { -v “*/Create*” }


Target {


Include PROCESS_CMD_LINE { -v “**.bat**” }



Include PROCESS_CMD_LINE { -v “**.ps1**” }





Expert Rule to prevent Start Up Entry Creation [ MITRE Technique Persistence T1060]:

Adversaries can use several techniques to maintain persistence through system reboots. One of the most popular techniques is creating entries in the Start Up folder. The following expert rule will prevent any process from creating files in the Start Up folder. Recently, the internet has witnessed a full-fledged exploit of a decade old WinRAR vulnerability (CVE-2018-20251) which can be exploited by dropping files in the Start Up directory. The following expert rule will also block such an attempt.

Rule {

Process {

Include OBJECT_NAME { -v ** }


Target {

Match FILE {

Include OBJECT_NAME { -v “**AppDataRoamingMicrosoftWindowsStart MenuProgramsStartup**” }

Include -access “CREATE WRITE”





Expert Rule which blocks JavaScript Execution within Adobe Reader:

Exploiting a client-side software vulnerability to gain an initial foothold in a network is not new [MITRE Technique T1203]. Adobe Reader is a very popular target because, like any other browser, it supports JavaScript which makes exploitation much easier. The following expert rule can be deployed in any network to prevent Adobe Reader from executing any kind of JavaScript.

Rule {

Process {

Include OBJECT_NAME { -v “AcroRd32.exe”}


Target {


Include OBJECT_NAME { -v “EScript.api” }




The table below shows how the above four Expert Rules line up in the Mitre Att&ck matrix.

Using Expert Rules in ENS 10.5.3 to Prevent Malicious Exploits


There are many more rules which can be created within Exploit Prevention (part of McAfee’s ENS Threat Prevention) and they can be customized depending on the customer’s environment and requirements. For example, the Expert Rule which blocks JavaScript Execution within Adobe Reader will be of no use if an organization does not use “Adobe Reader” software. To fully utilize this feature, we recommend our customers read the following guides:


Disclaimer: The expert rules used here as examples can cause a significant number of False Positives in some environments, hence we recommend those rules to be explicitly applied only in an environment where better visibility of above (or similar) events at granular level is required.


The author would like to thank following colleagues for their help and inputs authoring this blog.

  • Oliver Devane
  • Abhishek Karnik
  • Cedric Cochin

The post Using Expert Rules in ENS 10.5.3 to Prevent Malicious Exploits appeared first on McAfee Blogs.


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

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:

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

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.

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


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.

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


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.

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


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


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 and, that contain malicious tools such as NLBrute, etc.

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


We observed the actor attempting to run an RDP brute force attack using NLBrute downloaded from the Iranian site 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.

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


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


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 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 – Follow The Money

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money

Episode 3: Follow the Money

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

The Talking Heads once sang “We’re on a road to nowhere.” This expresses how challenging it can be when one investigates the financial trails behind a RaaS scheme with many affiliates, etc.

However, we persisted, and we prevailed. By linking underground forum posts with bitcoin transfer traces, we were able to uncover new information on the size of the campaign and associated revenue; even getting detailed insights into what the affiliates do with their earnings following a successful attack.

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money

With the Sodinokibi ransomware a unique BTC wallet is generated for each victim. As long as no payment is made, no trace of the BTC wallet will be available on the blockchain. The blockchain operates as a public ledger of all bitcoin transactions that have happened. When no currencies are exchanged, no transactions are recorded. Although many victims hit the news, we understand that if they paid, sharing that with the research community is maybe a bridge too far. On one of the underground forums we discovered the following post:

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money

In this post the actors are expanding their successful activity and offering a 60 percent cut as a start and, after three successful payments by the affiliate (read successful ransomware infections and payments received from the victims), the cut increases to 70 percent of the payments received. This is very common as we saw in the past with RaaS schemes like GandCrab and Cryptowall.

Responding to this post is an actor with the moniker of ‘Lalartu’ and his comments are quite interesting, hinting he was involved with GandCrab. As a site-note: “Lalartu’ means ‘ghost/phantom’. Its origins are from the Sumerian civilization where Lalartu was seen as a vampiric demon.

Researching the moniker of ‘Lalartu’ through our data, we went back in time a month or so and discovered a posting from the actor on June 4th of 2019, again referencing GandCrab.

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money

We observe here a couple of transaction IDs (TXID) on the bitcoin ledger, however they are incomplete. More than a week later, on June 17th, 2019, “Lalartu” posted another one with an attachment to it:

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money


McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money

In this posting we see a screenshot with partial TXIDs and the amounts. With the help of the Chainalysis software and team, we were able to retrieve the full TXIDs. With that list we were able to investigate the transactions and start mapping them out with their software:

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money

From the various samples we have researched, the amounts asked for payment are between 0.44 and 0.45 BTC, an average of 4,000 USD.

In the above screenshot we see the transactions where some of these amounts are transferred from a wallet, or bitcoins are bought at an exchange and transferred to the wallets associated with the affiliate(s).

Based on the list shared by Lalartu in his post, and the average value of bitcoin around the dates, within 72 hours a value of 287,499.00 USD of ransom had been transferred.

Taking the list of transactions as a starting point in our graph-analysis, we colored the lines red and started from there to investigate the wallets involved and interesting transactions:

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money

Although it might look like spaghetti, once you dive in, very interesting patterns can be discovered. We see victims paying to their assigned wallets; from there it takes an average of two to three transactions before it goes to an ‘affiliate’ or ‘distribution’ wallet. From that wallet we see the split happening as the moniker ‘UNKN’ mentioned in his forum post we started this article with. The 60 or 70 percent stays with the affiliate and the remaining 40/30 percent is forwarded in multiple transactions towards the actors behind Sodinokibi.

Once we identified a couple of these transactions, we started to dig in both directions. What is the affiliate doing with the money and where is the money going for the Sodinokibi actors?

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money

We picked one promising affiliate wallet and started to dig deeper down and followed the transactions. As described above, the affiliate is getting money transferred mostly through an exchange (since this is being advised by the actors in the ransom note). This is what we see in the example below. Incoming ransomware payments via are received. The affiliate seems to pay some fee to a service but also sends BTC into a popular underground bitcoin mixer that is obfuscating the next transactions to make it difficult to link the transactions back to the ‘final’ wallet or cash-out in a (crypto) currency.

We also observed examples where the affiliates were paying for services, they bought on Hydra Market. Hydra Market is a Russian underground marketplace where many services and illegal products are offered with payment in BTC.

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money

Tracing down the route of splits, we started to search for the 30 or 40 percent cuts of the ransom payments of 0.27359811 BTC or, if the price was doubled, 0.54719622 BTC.

Using the list of amounts and querying the transactions and transfers discovered, we observed a wallet that was receiving a lot of these smaller payments. Due to ongoing research we will not publish the wallet but here is a graph representation of a subset of transactions:

McAfee ATR Analyzes Sodinokibi aka REvil Ransomware-as-a-Service – Follow The Money

It seems like a spider, but many incoming ‘split’ transfers, and only a few outgoing ones with larger amounts of bitcoins, were observed.

If we take the average of $2,500 – $5,000 USD as a ransom ask, and the mentioned split of 30/40 percent for the actor maintaining the Sodinokibi ransomware and affiliate infrastructure, they make $700 – $1,500 USD per paid infection.

We already saw in the beginning of this article that the affiliate Lalartu claimed to have made 287k USD in 72 hours, which is an 86k USD profit for the actor from one affiliate only.

In episode 2, The All-Stars, we explained how the structure is setup and how each affiliate has its own id.

As far as we tracked the samples and extracted the amount of id-numbers, we counted over 41 affiliates being active. The data showed a in a relatively short amount of time the velocity and number of infections was high. Taken this velocity combined with a few payments per day, we can imagine that the actors behind Sodinokibi are making a fortune.

Following the traces of one particular affiliate, we ended up seeing large amounts of bitcoins being transferred into a wallet which had a total value of 443 BTC, around 4,5 million USD with the average bitcoin price.

We do understand that there are situations in which executives decide to pay the ransom but, by doing that, we keep this business model alive and also fund other criminal markets.


In this blog we focused on insights into the financial streams behind ransomware. By linking underground forum posts with bitcoin transfer traces, we were able to uncover new information on the size of the campaign and associated revenue. In some cases, we were able even to get detailed insights into what the affiliates do with their earnings following a “successful” attack. It shows that paying ransomware is not only keeping the ‘ransom-model’ alive but is also supporting other forms of crime.

In the next and final episode, “Crescendo” McAfee ATR reveals insights gleaned from a global network of honey pots.

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


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

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.

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


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.

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


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

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


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.

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


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?

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


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.

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

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.

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


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.

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


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


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.

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

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.


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

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.


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:

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

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.

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


Inside the Code

Sodinokibi Overview

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

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

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.

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


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.

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


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.

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


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.

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


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.

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


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.

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


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.

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


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.

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


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.

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


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 “SOFTWARErecfg” (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.

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


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.

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


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.

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


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

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


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

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


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.

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


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

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


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.

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


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

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


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:

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


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

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

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

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


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:

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


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.


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


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


rule Sodinokobi



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



author      = “McAfee ATR team”

version     = “1.0”

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


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


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.


How Visiting a Trusted Site Could Infect Your Employees

How Visiting a Trusted Site Could Infect Your Employees

The Artful and Dangerous Dynamics of Watering Hole Attacks

A group of researchers recently published findings of an exploitation of multiple iPhone vulnerabilities using websites to infect final targets. The key concept behind this type of attack is the use of trusted websites as an intermediate platform to attack others, and it’s defined as a watering hole attack.

How Does it Work?

Your organization is an impenetrable fortress that has implemented every single cybersecurity measure. Bad actors are having a hard time trying to compromise your systems. But what if the weakest link is not your organization, but a third-party? That is where an “island hopping” attack can take apart your fortress.

 “Island hopping” was a military strategy aimed to concentrate efforts on strategically positioned (and weaker) islands to gain access to a final main land target.

One relevant instance of “island hopping” is a watering hole attack. A watering hole attack is motivated by an attackers’ frustration. If they cannot get to a target, maybe they can compromise a weaker secondary one to gain access to the intended one? Employees in an organization interact with third-party websites and services all the time. It could be with a provider, an entity in the supply chain, or even with a publicly available website. Even though your organization may have cutting edge security perimeter protection, the third parties you interact with may not.

In this type of attack, bad actors start profiling employees to find out what websites/services they usually consume. What is the most frequented news blog? Which flight company do they prefer? Which service provider do they use to check pay stubs? What type of industry is the target organization in and what are the professional interests of its employees, etc.?

Based on this profiling, they analyze which one of the many websites visited by employees is weak and vulnerable. When they find one, the next step is compromising this third-party website by injecting malicious code, hosting malware, infecting existing/trusted downloads, or redirecting the employee to a phishing site to steal credentials. Once the site has been compromised, they will wait for an employee of the target organization to visit the site and get infected, sometimes pushed by an incentive such as a phishing email sent to the employees. Sometimes this requires some sort of interaction, such as the employee using a file upload form, downloading a previously trusted PDF report or attempting to login on a phishing site after a redirection from the legitimate one. Finally, bad actors will move laterally from the infected employee device to the desired final target(s).

How Visiting a Trusted Site Could Infect Your Employees

Figure 1: Watering Hole Attack Dynamics

Victims of a watering hole attack are not only the final targets but also strategic organizations that are involved during the attack chain. As an example, a watering hole attack was discovered in March 2019, targeting member states of the United Nations by compromising the International Civil Aviation Organization (ICAO) as intermediate target[1]. Because the ICAO was a website frequented by the intended targets, it got compromised by exploiting vulnerable servers. Another example from last year is a group of more than 20 news and media websites that got compromised as intermediate targets to get to specific targets in Vietnam and Cambodia[2].

Risk analysis

Because this kind of attack relies on vulnerable but trusted third-party sites, it usually goes unnoticed and is not easily linked to further data breaches. To make sure this potential threat is being considered in your risk analysis, here are some of the questions you need to ask:

  • How secure are the websites and services of the entities I interact with?
  • Are the security interests of third parties aligned with mine? (Hint: probably not! You may be rushing to patch your web server but that does not mean a third-party site is doing the same).
  • What would be the impact of a watering hole attack for my organization?

As with every threat, it is important to analyze both the probability of this threat as well as how difficult it would be for attackers to implement it. This will vary from organization to organization, but one generic approach is to analyze the most popular websites. When checking the top one million websites around the world, it is interesting to note that around 60%[3] of these are using Content Management Systems (CMSs) such as WordPress, Joomla or Drupal.

This creates an extra challenge as these popular CMSs are statistically more likely to be present in an organization’s network traffic and, therefore, are more likely to be targeted for a watering hole attack. It is not surprising then that dozens of vulnerabilities on CMSs are discovered and exploited every month (around 1000 vulnerabilities were discovered in the last two years for just the top 4 CMSs[4]). What is more concerning is that CMSs are designed to be integrated with other services and extended using plugins (more than 55,000 plugins are available as of today). This further expands the attack surface as it creates the opportunity of compromising small libraries/plugins being used by these frameworks.

Consequently, CMSs are frequently targeted by watering hole attacks by exploiting vulnerabilities that enable bad actors to gain control of the server/site, modifying its content to serve a malicious purpose. In some advanced scenarios, they will also add fingerprinting scripts to check the IP address, time zone and other useful details about the victim. Based on this data, bad actors can automatically decide to let go when the victim is not an employee of the desired company or move further in the attack chain when they have hit the jackpot.

Defending against watering hole attacks

As organizations harden their security posture, bad actors are being pushed to new boundaries. Therefore, watering hole attacks are gaining traction as these allows bad actors to compromise intermediate (more vulnerable) targets to later get access to the intended final target. To help keep your organization secure against watering hole attacks, make sure you are including web protection. McAfee Web Gateway can help provide additional defense against certain class of attacks even when the user is visiting a site that’s been compromised by a watering hole attack, with behavior emulation that aims to prevents zero-day malware in milliseconds as traffic is processed. You may also want to:

  • Build a Zero Trust model, especially around employees visiting publicly available websites, to make sure that even if a watering hole attack is targeting your organization, you can stop it from moving forward.
  • Regularly check your organization’s network traffic to identify vulnerable third-party websites that your employees might be exposed to.
  • Check the websites and services exposed by your organization’s providers. Are these secure enough and properly patched? If not, consider the possibility that these may become intermediate targets and apply policies to limit the exposure to these sites (e.g. do not allow downloads if that is an option).
  • When possible, alert providers about unpatched web servers, CMS frameworks or libraries, so they can promptly mitigate the risk.

Dealing with watering hole attacks requires us to be more attentive and to carefully review the websites we visit, even if these are cataloged as trusted sites. By doing so, we will not only mitigate the risk of watering hole attacks, but also steer away from one possible pathway to data breaches.



[3] “Usage of content management systems”,

[4] “The state of web application vulnerabilities in 2018”,

The post How Visiting a Trusted Site Could Infect Your Employees appeared first on McAfee Blogs.


End-2-End Encrypted. Secure. Ad-Free.
Lightweight and Faster than the Competition.

Vox Messenger is a secure alternative to other popular chat messenger apps.

Available for Free. Whitelabel Corporate Edition Coming Soon.

All Rights Reserved - Copyright @ 2018 - Vox Messenger (a Division of Kryotech Ltd.)