Unit 42 researchers have been observing various malicious campaigns abusing either legitimate challenge and response services (such as Google’s reCAPTCHA) or deploying customized fake CAPTCHA-like validation. Recent security blogs on phishing campaigns and cybercriminals using reCAPTCHA and research papers like PhishTime and CrawlPhish show an increasing trend of CAPTCHA-protected phishing pages. Hiding phishing content behind CAPTCHAs prevents security crawlers from detecting malicious content and adds a legitimate look to phishing login pages.
In this blog, we show techniques to detect malicious content with security crawlers even in the presence of CAPTCHA evasion. In some cases, these techniques can even track and detect such campaigns. We see many malicious campaigns reuse CAPTCHA service keys, either to simplify their malware infrastructure or to avoid being blocked by the legitimate reCAPTCHA provider for creating too many CAPTCHA accounts and keys.
Our research paper “Betrayed by your Dashboard” (published in 2018 at TheWebConf) shows that web analytics IDs can be used to identify large-scale malicious campaigns, as attackers often use legitimate web analytics services. Here, we show how similar pipelines can be used to detect phishing pages through the association of CAPTCHA keys.
Looking at the top 10 most popular malicious CAPTCHA keys across broad phishing campaigns just over the last month, we blocked 7,572 unique URLs over 4,088 pay-level domains, protecting our customers from visiting them at least 202,872 times. At the same time, we see that such URLs are slower in appearing in third-party malicious feeds, presumably because of hidden phishing, scam and other malicious content.
At Palo Alto Networks, we focus on how we can detect and track malicious campaigns across various domains and URLs.
Phishing Example for Apple ID Credentials
Let’s look at the example (hxxp://utem[.]com/[.]YSou8XI) of a long-running phishing campaign that we have been monitoring since July 2020. It has been pushing phishing pages and targeting Microsoft Outlook, Apple and other login pages. Users see the following CAPTCHA challenge when they visit the page.
Figure 1. CAPTCHA challenge.
After solving a standard reCAPTCHA challenge, the browser will see a classic phishing page, shown in Figure 2 below. In this example, phishing content was generated dynamically on the same page, but more often a top-level redirection occurs.
Figure 2. Phishing page.
However, on the main page (before solving the CAPTCHA challenge), we observe the following sub-requests, which reveals the reCAPTCHA API key used in the URL parameters:
Figure 3. The sub-requests shown reveal the reCAPTCHA API key used in the URL parameters.
Such identifiers can be parsed out and searched for on other pages, which gives us the ability to find other phishing pages. For example, a webpage using the same ID was pushing Apple ID phishing too.
Figure 4. Phishing for Apple ID credentials.
Alternatively, CAPTCHA keys can be extracted from HTML. The example shown below was used in another recent Outlook phishing campaign:
Figure 5. HTML from a recent Outlook phishing campaign.
Such CAPTCHA keys are a strong signal for detecting malicious pages even without getting phishing content. Moreover, malicious CAPTCHA keys can be mined automatically using similar ground truth data and filtering pipelines, which were presented in the paper Betrayed by Your Dashboard: Discovering Malicious Campaigns via Web Analytics. However, we noticed that such sophisticated malicious pages are slow to appear in third-party malware and phishing feeds. As such, manually verified ground truth data gives more useful CAPTCHA keys or clustered CAPTCHA keys from an unlabeled feed of URLs.
Microsoft Phishing Example
Here we see op[.]g2yu-bere[.]xyz/?e=c2Nhc2VAY2l0Y28uY29t, where an attacker is attempting to phish for Microsoft account credentials. The CAPTCHA challenge makes it seem legitimate for both the users and security scanners. After the user solves the CAPTCHA, the attacker attempts to phish Office 365 credentials from the user.
Figure 6. Phishing page protected by CAPTCHA.
Is It Only About Phishing?
In addition to various phishing campaigns, beginning in October 2020 we started to observe more scam campaigns and malicious gateways using CAPTCHA evasion. Often, they show CAPTCHA challenges only if they suspect automation with other means (for example, based on IP and browser versions).
Grayware Campaigns
Another category of malicious pages protected by CAPTCHA is grayware. Survey and lottery scams are some of the most common grayware pages. In exchange for a fake payment or chance at winning the lottery, the user is lured into disclosing sensitive information, including address, date of birth, banking information, annual income, etc.
Figure 7. Survey scam examples.
Below is another example of a lottery scam page (win[.]click2win4life[.].com/api/offer) that uses CAPTCHA evasion with ID 6LfKnxEUAAAAAO1iXBX9FqL0w-68XqXGl3UPBF5p and attempts to collect user information.
Figure 8. Lottery scam examples.
Malware Delivery
We have seen recent examples of malware delivery pages abusing legitimate CAPTCHA services. For example, the URL hxxps://davidemoscato[.]com serves a malicious JAR file (PayeeAdvice_IN00231_Q1626801_32843.jar) that is hidden from security scanners by protecting the page with a CAPTCHA challenge.
Figure 9. Malware page protected by CAPTCHA.
Efficacy of CAPTCHA Signatures
We present the statistics of the 10 most popular malicious CAPTCHA IDs in a one-month period (April 18-May 18). The graph below shows the number of new detections per day for each ID. We see that on a daily average, 529 new URLs are found to use such malicious IDs. We received a total of 7,572 unique URLs from these top 10 IDs in a 30-day period.
Figure 10. Daily detections of top 10 IDs in 30 days (April 18 - May 18).
We ranked their popularity using the number of unique detections per day. Because we see that attackers use these IDs for a long time – more than 250 days in some cases – they are robust indicators of malicious activity.
ID Live Days:
CAPTCHA ID
Unique 30 day detections
Avg detections / day
ID live (days)
6LcEthAUAAAAANLeILVZiZpPDbVwyoQuQ7c3qlsy
3,290
228
264
6LcJK64UAAAAAKwjDYyWpakQ_5aFAb34tK-EkiDA
2,094
87
287
6Le-dsYUAAAAABJa32oIuo9LEPsur7OcBz-a9kyL
1,132
42
294
6LfKnxEUAAAAAO1iXBX9FqL0w-68XqXGl3UPBF5p
1,021
39
238
6Lc8-cQUAAAAAF60sMK0PjhPOA6ciyzy6cfnGcl0
784
38
294
6LeihuEUAAAAAEgMRhYQKQCxnJvsqIZnRghJAPcH
222
42
182
6LezpHMUAAAAALunasQAvKdhRwFC1oqRE0OZW8f4
216
23
295
6LdkVo0aAAAAAN5yxjGbJPH39rF--s6ZVsl_LxzE
201
10
43
6LdVFrgUAAAAAEMNq1ljl8HZSQ2sA8Hu6a8umPQr
191
7
287
6LfrPbMUAAAAAF2DLXNWH8-s0Ln08lXtaX9k1tRC
152
13
294
Table 1. Top 10 CAPTCHA IDs ranked by 30-day unique detections count.
It is also interesting to note that the three top-ranked CAPTCHA IDs alone account for 70% of the detections.
Figure 11. Cumulative detections ordered by popularity of CAPTCHA ID.
Impact of Detections
Let’s look at the impact these detections have on our customers. For the same 30-day timeframe, we observe that our customers attempted to visit these pages at least 202,872 times. The graph below shows the number of visits to the 10 most popular malicious URLs. Six of them belong to grayware, and four belong to malware categories. The grayware page that collects user information for a chance at the lottery (win[.]omgsweeps[.]info) accounts for 51% of the customer visits to these malicious pages.
Figure 12. Top 10 most visited malicious URLs by customers.
Other Detection Methods
We observe that CAPTCHA IDs are often not the only signal in the detected sites. In addition to the IDs, we can use some other methods to detect these malicious sites.
Static URL analysis: In some instances, we can identify malicious sites just by looking at the URL. Many campaigns reuse similar URL patterns, related domains, IPs or other signals. Based on previous examples seen with the same pattern as the URL, runswift-besthighlyfile[.]best/ZW2RR5af4KcKjjWeJS2qTOgg92QyTjh7NL0_4Yv8R98, we can mark it malicious.
Traffic analysis: In a few cases, we can look into the HTML traffic for malicious activity. For example, the malicious page, https:/syans2008[.]3dn[.]ru/news/barbi_princessa_rapuncel_skachat_igru/2013-10-23-1705, can be detected with the CAPTCHA ID, 6LcpAwsUAAAAAPif4MyLJQVv7r5Nr1Wv31NB86C6, or with the YARA rule below.
When simulating client-side behavior, we observe the HTML traffic with (SHA256: 781e16b89604cdcd37928009920654628cc95f6e1b34916fd47b880ff3c7cc92) that the page havnsardf[.]ga loads. The YARA rule above can uncover many cases of malicious JavaScript injections or downloads. This execution behavior is usually seen in situations in which attackers have taken over a web server and intend to inject malicious JavaScript from their servers into the victim web server.
Using content analysis: In some cases, malicious phishing content is already present in the HTML, but just not shown, or a custom/fake CAPTCHA is used. Such pages are usually JavaScript-rich, and detectable with malicious JavaScript analysis used at Palo Alto Networks. For example, the malicious site, yourstorecentre[.]com, protected by CAPTCHA ID, 6LcA2tEZAAAAAJj7FTYTF9cZ4NL3ShgBCBfkWov0, contains the malicious JS with SHA256: 68687db7ae5029f534809e3a41f288ec4e2718c0bbdefdf45ad6575b69fed823, which is shown to be malicious when analyzed.
Finally, the simplicity of making detections with CAPTCHA signatures has the benefit of being early in newer detections. For example, if we look up the site, lowautocasion[.]es, on third-party vendor feeds, it remained undetected by many standard methods until July 7, but was detected as malware by Palo Alto Networks Advanced URL Filtering using CAPTCHA signatures as early as May 18.
Conclusion
Mass phishing and grayware campaigns have become more sophisticated, using evasion techniques to escape detection by automated security crawlers. Fortunately, when malicious actors use infrastructure, services or tools across their ecosystem of malicious websites, we have a chance to leverage these indicators against them. CAPTCHA identifiers are one great example of such detection by association.
Palo Alto Networks continually monitors CAPTCHA IDs as one example of a malicious indicator, and we use it to detect phishing, malware and grayware pages. Palo Alto Networks Next-Generation Firewall customers with Advanced URL Filtering andWildFire security subscriptions are protected against such sophisticated phishing campaigns.
Signatures
Below is the list of top 10 popular Captcha ID signatures for the period April 18-May 18. 6LcEthAUAAAAANLeILVZiZpPDbVwyoQuQ7c3qlsy 6LcJK64UAAAAAKwjDYyWpakQ_5aFAb34tK-EkiDA 6Le-dsYUAAAAABJa32oIuo9LEPsur7OcBz-a9kyL 6LfKnxEUAAAAAO1iXBX9FqL0w-68XqXGl3UPBF5p 6Lc8-cQUAAAAAF60sMK0PjhPOA6ciyzy6cfnGcl0 6LeihuEUAAAAAEgMRhYQKQCxnJvsqIZnRghJAPcH 6LezpHMUAAAAALunasQAvKdhRwFC1oqRE0OZW8f4 6LdkVo0aAAAAAN5yxjGbJPH39rF--s6ZVsl_LxzE 6LdVFrgUAAAAAEMNq1ljl8HZSQ2sA8Hu6a8umPQr 6LfrPbMUAAAAAF2DLXNWH8-s0Ln08lXtaX9k1tRC
We’d like to thank Unit 42 for helping us with this blog. Special thanks to Bahman Rostamyazdi, David Fuertes, Taojie Wang, Tao Yan and Hector Debuc for helping us with the data.
Unit 42 researchers have discovered a new variant of eCh0raix ransomware targeting Synology network-attached storage (NAS) and Quality Network Appliance Provider (QNAP) NAS devices. To achieve this, attackers are also leveraging CVE-2021-28799 to deliver the new eCh0raix ransomware variant to QNAP devices. While eCh0raix is known ransomware that has historically targeted QNAP and Synology NAS devices in separate campaigns, this new variant is the first time we’ve seen it combining functionality to target both QNAP and Synology NAS devices, demonstrating that some ransomware developers are continuing to invest in optimizing the tools used to target devices common in the small office and home office (SOHO).
We’re regularly seeing attacks with the eCh0raix ransomware variant, which has been active in the wild for nearly a year. As recently as June, victims have reported paying a modest ransom.
We’re releasing our findings about this new variant of eCh0raix to raise awareness of the ongoing threats to the SOHO and small business sectors. Coverage of the ransomware crisis tends to focus on threats to large enterprises and government agencies, which are facing increasingly aggressive and disruptive ransomware attacks. However, the SOHO and small business sectors can contain a large attack surface for threat actors – for example, some 250,000 QNAP and Synology NAS devices are exposed to the public internet, according to data from the Cortex Xpanse platform.
SOHO users are attractive to ransomware operators looking to attack bigger targets because attackers can potentially use SOHO NAS devices as a stepping stone in supply chain attacks on large enterprises that can generate huge ransoms.
Additionally, SOHO users typically do not employ dedicated IT or security professionals, which makes them less prepared to block ransomware attacks than larger organizations.
We recommend the following best practices for protecting home offices from ransomware attacks:
Update device firmware to keep attacks of this nature at bay. Details about updating QNAP NAS devices against CVE-2021-28799 can be found on the QNAP website.
Create complex login passwords to make brute-forcing more difficult for attackers.
Limit connections to SOHO connected devices from only a hard-coded list of recognized IPs to prevent network attacks that are used to deliver ransomware to devices.
On April 22, QNAP released a security advisory to disclose a vulnerability within their Hybrid Backup Sync (HBS 3) software. This software provides backup, restoration and synchronization functions between local, remote and cloud storage spaces. The vulnerability has been confirmed as an improper authorization vulnerability. Once exploited, it allows remote attackers to log in to the devices. CVE-2021-28799 is assigned to this vulnerability.
On June 21, we caught an attack targeting QNAP HBS3 with an exploit of CVE-2021-28799. While this vulnerability has been exploited to deliver QLocker in the past, this is the first instance we know of in which it is being exploited to deliver eCh0raix (also known as QNAPCrypt) ransomware. The payload of the malicious request is shown in Figure 1. The attack tried to utilize a hard-coded session ID "jisoosocoolhbsmgnt" to bypass authentication and execute a command on the device, aiming to fetch malware from the remote server 64[.]42[.]152[.]46 and run it on the victim device. The payload is still live at the time of this writing.
Figure 1. CVE-2021-28799 exploit.
While eCh0raix has historically targeted QNAP devices, further analysis of the payload led to the discovery that this is a new variant of the ransomware that also targets Synology devices, thereby increasing its attack surface.
Timeline of the New eCh0raix Ransomware Variant
To the best of our knowledge, details on the eCh0raix ransomware samples targeting these Synology devices were unknown until now. Instances of Synology devices infected by eCh0raix have been reported from as far back as 2019, but the only previous research connecting the Synology attacks to eCh0raix actors is based on decryptors that were found.
The first sample we saw of this new ransomware variant combining functionality to target both QNAP and Synology devices is from September 2020. It’s possible that is when the combined variant was authored. Before then, the attackers likely had separate codebases for campaigns targeting devices from each of the vendors. This is also confirmed by the use of rct_cryptor_universal as the project name in the new variant, going by the compilation paths present in GoLang binaries (/home/dev/GoglandProjects/src/rct_cryptor_universal). Prior samples of eCh0raix use the project name qnap_crypt_worker.
We observed other eCh0raix samples between June and September 2020 using the rct_cryptor_universal project name, but the first full-blown sample with two separate code flows, based on a syno flag (explained below), is from September 2020.
Going by posts from victims in forums, it appears the eCh0raix ransomware is quite active. The attackers have found success extorting ransom out of victims, an example of which can be seen on BleepingComputer.com, where the ransom was paid as recently as June 16, 2021.
Querying Cortex Xpanse for NAS devices gives us a rough estimate of the number of devices from each vendor connected to the internet (i.e. the attack surface for this ransomware). Xpanse tells us there are approximately 240,000 internet-connected QNAP NAS devices. In contrast, Xpanse found approximately 3,500 Synology NAS devices – a much smaller number. This tells us the additional target doesn’t significantly increase the ransomware’s attack surface.
Technical Analysis
The new variant accepts an additional syno flag as an input parameter. The two accepted flags are explained below in Table 1.
Flag Name
Description
Significance
s
start path
A string value that determines the path on the targeted device where the ransomware encrypts files. The default value is “/”. The exploit we observed in the wild specified this value as “/share/” (see Figure 1). This value is also ignored if the syno flag is set, in which case the start path value is a hardcoded list of paths.
syno
is syno?
This is a Boolean value accepted by this new variant. By default, it is not set, but if explicitly set using the syno input parameter, a hardcoded path is used for encrypting files. The hardcoded path used is /volume[X] (where X takes on values from 0 to 9). This essentially means that the ransomware tries to encrypt the first 10 numbered volumes on the device. This aligns with the name of the flag syno since Synology NAS devices specifically store their data under volumes.
Table 1. Input arguments supported by the new variant.
CheckIsRunning: After launch, the ransomware first checks whether another instance of the process is already running. This is done by checking for a [SampleName].pid file in the temporary directory on the system. The temporary directory location is determined either by the value of the TMPDIR environment variable, or /tmp is used if the environment variable is not set. If found, the ransomware tries to read an integer value from this file and kill the corresponding process ID on the system. If it fails to kill the existing process, it prints a message: “Program is running. Exiting…” and exits. If no existing running process is found, or the ransomware succeeds at killing a previously running process, it initializes the .pid file in the temporary directory with the value of its own process ID.
checkReadmeExists: Next, the binary checks for the presence of a ransom note file. In the original variant, this file was named README_FOR_DECRYPT.txt. However, this new variant uses the filename README_FOR_DECRYPT.txtt (with the extra trailing ‘t’). Perhaps the typo is an easy way for the attackers to distinguish between campaigns. This thread in the QNAP user forum starting March 21, 2021, shows this new variant has been active and contains victims’ accounts from instances of successful infection.
If this file already exists on the device, the binary exits.
getInfo: If a preexisting ransom note file is not found and program execution continues, the ransomware attempts to connect to a Tor URL via a hard-coded SOCKS proxy – see Indicators of Compromise (IoCs) below. This URL serves as the command and control (C2) server and returns a JSON object containing:
The AES key used to encrypt files on the system.
The ransom note.
A Bitcoin address that is included in the ransom note.
We managed to find one of the C2 URLs still live, which returned a response with the JSON object described above, as seen in Figure 2.
Figure 2. C2 response.
An interesting thing to note is that the new variant uses a different URL format for communicating with the C2 using an API key, instead of using Campaign ID numbers as the previous variant did (see Table 3 for variant comparison).
If the sample fails to connect to the C2 or receive a meaningful response, it exits with the rather amusing log message, “AES public key not set!” (AES is a symmetric encryption algorithm, thus the concept of public or private keys is moot in this case.)
main: Following all these steps, the ransomware iterates through the list of files at a path determined by the flag values (syno and s) explained in Table 1. Any files in this path containing the following strings are ignored:
/proc
/boot/
/sys/
/run/
/dev/
/etc/
/home/httpd
/mnt/ext/opt
.system/thumbnail
.system/opt
.config
.qpkg
/usr/syno
/tmp
/volume1/@appstore/PhotoStation
.@analytic
qnapSystem.php
README_FOR_DECRYPT.txtt
.@backup_config
.antivirus
.ldapdb
.@backup_qbox
.appDB
.locks
.@backup_qfiling
.idmap
.log
.@qmariadb
.php_session_sys
.qbox
Table 2. Files excluded from encryption.
The encryption algorithm used is the same as that used by the original variant (AES CFB), and the same extension (.encrypt)is appended to encrypted files, with the eCh0raix string used as a marker in the files to verify successful decryption by decryptors. However, this new variant doesn’t generate the AES key locally, but rather receives it directly from the C2.
The new variant also implements encryption in two stages based on file extensions. The ransomware first iterates through files with the following 42 extensions and encrypts them:
We hypothesize that this is a higher-priority subset of extensions focusing on data that would be of value to the average user. Thus, it is more likely for the ransom to be paid to recover this data. These extensions are likely encrypted first to prioritize valuable data in case the ransomware fails to complete its encryption process.
After the encryption of files with the first set of extensions, files matching a longer list of 530 unique file extensions are encrypted. These are included in the appendix. We noticed the .docx extension is included on both lists, so those files would get encrypted twice.
The original variant targeted a total of 563 unique extensions, all encrypted as part of the same routine (also included in the appendix).
Encryption is carried out in two steps, focusing on a short list of higher priority extensions first.
AES Encryption Key received from C2
42+530 unique file extensions targeted.
Encryption carried out in one go.
AES Encryption Key generated locally
563 unique file extensions targeted.
Saves ransomware PID in a temporary directory?
Yes
No
Kills certain running processes?
No
Yes
Table 3. Variant comparison.
Conclusion
The discussion of this new variant of eCh0raix ransomware provides an example of the ongoing threats to the SOHO and small business sectors. These sectors represent a large attack surface for threat actors – for example, some 250,000 QNAP and Synology NAS devices are exposed to the public internet, according to data from the Cortex Xpanse platform.
SOHO users are attractive to ransomware operators looking to attack bigger targets because attackers can potentially use SOHO NAS devices as a stepping stone in supply chain attacks on large enterprises that can generate huge ransoms.
Additionally, SOHO users typically do not employ dedicated IT or security professionals, which makes them less prepared to block ransomware attacks than larger organizations.
We recommend the following best practices for protecting home offices from ransomware attacks:
Update device firmware to keep attacks of this nature at bay. Details about updating QNAP NAS devices against CVE-2021-28799 can be found on the QNAP website.
Create complex login passwords to make brute-forcing more difficult for attackers.
Limit connections to SOHO connected devices from only a hard-coded list of recognized IPs to prevent network attacks that are used to deliver ransomware to devices.
Palo Alto Networks customers are protected from eCh0raix ransomware and CVE-2021-28799 by the following products and services:
Next-Generation Firewalls with a Threat Prevention security subscription can block the attacks with best practice via Threat Prevention signature 91323.
WildFire accurately detects and blocks these attacks.
Cortex Xpanse provides attack surface management for your connected assets.
Cloud environments are more susceptible to attacks today than they were at the end of last year, according to new research from Unit 42. We identified significant increases in the number of organizations that did not enable multi-factor authentication (MFA), failed to rotate access keys or used overly permissive service accounts in their instances with cloud service providers (CSPs). That puts those organizations at increased risk of experiencing a high-profile security incident caused by compromised identity and access management (IAM) accounts for CSP environments.
These findings supplement our Unit 42 Cloud Threat Report, 2H 2020. In that October 2020 report, we analyzed the security risks IAM misconfigurations can pose to cloud environments. We decided to follow up that research to see how trends have changed over the past eight months, particularly in light of the highly significant MFA ramifications of the SolarStorm attack and the Microsoft Exchange Server attacks.
It is important to note that our findings result from an organization’s misconfiguration of their respective CSP’s settings and are not the result of the services provided by the CSP.
Between January and June 2021, Unit 42 researchers found that cloud environments are more susceptible to attacks today than in October 2020. Most notably, researchers made additional discoveries, including:
A 60% increase in the number of organizations that configure Google Cloud storage buckets so they are accessible to all users, putting their data at higher risk.
A 42% increase in the number of organizations that did not enable MFA settings for root accounts on the Amazon Web Services (AWS) platform.
A 22% increase in the number of organizations using AWS, where access keys are not rotated for more than 90 days.
These findings (MFA disablement, no routine key rotation operations and the provisioning of over-privileged accounts) indicate the need for organizations to tighten their DevOps security operating procedures.
It is highly recommended that all organizations invest in cloud-native security platforms, such as Palo Alto Networks Prisma Cloud, to routinely monitor cloud environments for IAM misconfigurations both within production and development environments.
MFA Misconfigurations
The findings regarding those who do not enable MFA in cloud environments only pertain to a CSP’s native IAM capabilities and not those provided by a third-party identity provider (IdP). CSP root accounts present a critical security bottleneck in terms of an organization’s cloud IAM security. The CSP root account is the first account created within a cloud environment. It is an all-powerful account holding “the keys to the kingdom,” including allowing and managing any IdP configuration. This is important to point out, as a compromised CSP root account could circumvent any security measure put in place by an IdP.
It is a security best practice to configure the organization’s CSP root account with MFA to safeguard it, which includes the organization’s cloud environment itself. While there are instances where MFA can be bypassed (e.g. phishing attacks, insecure protocols and vulnerabilities), these types of attacks are incredibly costly for attackers. Microsoft found that the “[u]se of anything beyond the password significantly increases the costs for attackers, which is why the rate of compromise for accounts using any type of MFA is less than 0.1% of the general population.” According to IDC, 90% of enterprises will rely upon a cloud infrastructure to meet production requirements by 2022. To help secure that cloud infrastructure, following MFA best practices will help ensure organizations do not suffer avoidable identity security exposures.
MFA, also referred to as two-factor authentication (2FA), is the process of providing two or more forms of authentication before being granted access to an application. The three forms of authentication are:
Something you know.
Password.
Passphrase.
Something you have.
Hardware security key.
Software token application.
SMS token.
Something you are.
Biometric scan or iris scan.
Voice authentication.
When MFA is enabled and a user requests access to an application, the user will be required to successfully provide two or more authentication checks before being given access. This typically involves supplying a password (something you know) and entering a token value (something you have).
In the previously mentioned CTR, 2H 2020, Unit 42 researchers examined MFA misconfigurations where organizations had not properly enabled or configured MFA resources for their root and standard user accounts. Unfortunately, these statistics have worsened since October 2020, as shown in Table 1. An explanation for the downward trend in these numbers could be that it is due to organizations failing to properly configure user accounts, which may lie outside of their IdP platform. This means, for organizations that are using an IdP (e.g. Okta, Auth0, SailPoint or OneLogin), they may not have disabled those IAM accounts created within the cloud platform itself. This would include the IAM account that was used to establish the IdP integration.
Critical Misconfiguration
Oct. 2020
June 2021
Percentage Increase
Orgs using Oracle Cloud where MFA is disabled for IAM users
N/A
92%
N/A
Orgs using Alibaba Cloud where MFA is disabled for RAM* user
62%
85%
+27%
Orgs using AWS where MFA was not enabled for IAM users
47%
69%
+32%
Orgs using AWS where MFA was not enabled for root accounts
24%
42%
+42%
Table 1. Organizations not enabling MFA for IAM accounts. *RAM - Resource Access Management is the identity and access control service within the Alibaba cloud that enables users’ central management and their permissions.
Whereas Amazon Web Services (AWS), Oracle Cloud and Alibaba Cloud have incorporated the IAM authentication functionality within the cloud platform itself, Google Cloud and Microsoft Azure use their proprietary IdP services with their cloud platforms to perform IAM authentication. Google Cloud uses the proprietary Google Accounts service, and Azure uses Microsoft’s Azure Active Directory (AD) service. If organization administrators wish to enable MFA for their Google Cloud accounts, please refer to this Google Workspace guide. If organization administrators want to enable MFA for their Azure cloud accounts, please refer to this Azure AD Multi-Factor Authentication guide
Additional Misconfigurations
Diving into the IAM access key rotation findings, Unit 42 researchers found a roughly 20% global increase in cloud organizations failing to perform access key rotation operations between October 2020 and June 2021. This was found within organizations using Google Cloud and AWS platforms.
Much like passwords, new CSP access keys should be rotated every 90 days to ensure that they will not remain active for long periods if the keys are leaked or stolen. Access keys become compromised if they are accidentally uploaded to code repository sites such as GitLab or GitHub or placed on a cloud instance that later becomes compromised. As can be seen within Table 2, organizations using AWS, Google Cloud and Oracle Cloud platforms exhibited notable occurrences of long-lived access keys. (Each of the cloud providers offer access to configuration settings to protect the cloud infrastructure from this issue, though not all users enable them.)
Due to the increase in cloud demand and complexity paired with the overall low severity rating of long-lived credentials, it is likely that organizations are choosing to address other cloud development operations, such as on-prem to cloud migrations or application development, rather than addressing long-lived credential misconfigurations. However, access key rotation is one of the few use cases that presents an ever-increasing risk severity. The longer credentials remain unchanged and the more cloud infrastructures being built that use those credentials, the more damaging their exposure could be to the organization should those credentials become leaked.
Critical Misconfiguration
Oct. 2020
June 2021
Percentage Increase
Orgs using AWS where access keys are not rotated for 90+ days
68%
83%
+22%
Orgs using Google Cloud where account keys have not rotated for 90+ days
62%
73%
+18%
Orgs using Oracle Cloud where API keys have not rotated for 90+ days
N/A
85%
N/A
Orgs using Oracle Cloud where Auth Tokens have not rotated for 90+ days
N/A
19%
N/A
Table 2. Organizations not rotating access keys.
Each of the primary CSPs offers methodologies for automating the process of access key rotation. Please see the following links for more details: Alibaba Cloud, AWS, Azure, Google Cloud and Oracle Cloud.
Excessive Permissions
Finally, Unit 42 researchers revisited the likelihood of organizations with excessive permissions, which allowed for IAM accounts and roles. The most notable IAM excessive privilege issue centers around the misuse of the AWS AssumeRole functionality. (While AWS provides configurations to protect against AssumeRole misuse, not all users enable them.) This service has received a great deal of attention from both Unit 42 researchers and CSO Online industry best practice articles, and even SolarWinds has a tie into misconfigured AssumeRole services. Due to this level of attention, researchers are beginning to see a decrease in the number of organizations that are overly privileging AssumeRole configurations, which has decreased by 67% in just six months (see Table 3).
Critical Misconfiguration
Oct. 2020
June 2021
Percentage Increase/Decrease
Orgs using AWS where an IAM policy allows AssumeRole permission across all services
30%
18%
-67%
Orgs using Google Cloud where an IAM user has service account privileges
61%
62%
+2%
Orgs using Google Cloud where an account has overly permissive service account privileges
20%
24%
+17%
Orgs using Google Cloud where storage buckets are publicly accessible to all users
11%
27%
+60%
Table 3. Organizations allowing overly permissive IAM privileges.
While the reduction in over-privileged AWS AssumeRole services is good news, we believe it is time to switch our collective attention to correcting other IAM security concerns within other CSP environments. For example, this includes overly permissive IAM service accounts within Google Cloud environments, which have increased in frequency by 17%, as well as locking down publicly accessible Google Cloud storage resources, which have increased in frequency by a massive 60% over the last six months.
Conclusion
CSP root accounts pose a critical security risk to cloud environments. Providing proper security protection for these accounts should be an urgent priority for any organization operating in the cloud. Organizations improperly configuring and maintaining their cloud environments could experience grave consequences. Unit 42 researchers strongly recommend that organizations limit operational functionality from CSP root accounts to only configuring an IdP platform. The CSP root account should have MFA enabled, preferably via an MFA hard token, and that root account should never be used, except for emergencies. Any and all administrative functions must be performed through a newly designated IdP-based administrative account.
Unit 42 researchers also found an increase in the number of organizations not rotating their IAM access keys and the number of organizations deploying overly privileged IAM accounts and roles. Similar to rotating user passwords, access keys must be rotated at least every 90 days to maintain minimal risk. Finally, the principle of least-privilege should be applied when creating and maintaining all IAM entities, be they users, roles or group privileges. The critical IAM misconfigurations discussed can be detected and alerted on, out of the box, within Prisma Cloud. The platform allows organizations to maintain awareness of their cloud environment configurations, especially for those organizations using a multi-cloud setup.
Recommendations
Ensure that the CSP root account has MFA enabled, preferably with a hardware token.
Use the CSP’s root account to set up the IdP configuration and never use that root account for any other function.
Create an IAM administrative account configured through the IdP to perform all administrative functions.
Microsoft recently added additional security checks that address the Windows container escape that we discovered last year. This is the same escape that enabled Siloscape, the first known vulnerability targeting Windows containers, which we discovered earlier this year.
To address the issue, Microsoft focused on the key function that enabled the container escape, which prevents exploitation. Now, there will also be a check for whether the function is being called from inside a container. If so, it will be blocked. These new changes Microsoft introduced directly prevent Siloscape’s attack technique.
However, these security checks do not completely get rid of the risk of running Windows Server containers for certain purposes. As discussed in a previous blog, we do not recommend using Windows containers as a security feature, which is consistent with guidance from Microsoft.
Palo Alto Networks Prisma Cloud protects customers from Siloscape attacks. In addition, Prisma Cloud Compute will alert customers who have old versions of their hosts that are vulnerable to known CVEs.
Technical Overview of the Issue and the Patch
Recap of Windows Container Escape Technique
As covered in detail in previous posts, an attacker who wants to abuse this issue to create a symbolic link to the host’s drive, and escape the container, needs to call the undocumented function NtSetInformationSymbolicLink with the correct parameters. Such a call will make the attacker’s chosen symbolic link global, thus pointing to the host’s objects instead of the container’s objects. A global symbolic link from inside the container can point to the host's filesystem, registry or basically any named object under the Root Directory Object.
Figure 1. Execution flow of the container escape.
To successfully use NtSetInformationSymbolicLink the caller has to have SeTcbPrivilege privileges. The regular container’s user is indeed Administrator but doesn’t have the necessary privileges.
In order to obtain SeTcbPrivilege privileges an attacker can use the main container’s process, CExecSvc.exe, which has the relevant privileges. An attacker can use CExecSvc.exe’s context to gain its privileges in numerous ways, such as Thread Impersonation or good old DLL injection.
The Fix
Figure 2. NtSetInformationSymbolicLink before (left) and after (right) the patch.
The patch is easy to understand and straightforward. Any call to NtSetInformationSymbolicLink from a thread inside a container (server silo) will be blocked with the STATUS_PRIVILEGE_NOT_HELD error code. This is done using the PsIsCurrentThreadInServerSilo function, which, as its name suggests, checks whether the current thread is associated with a process inside a server silo.
Is My Kubernetes Cluster Protected?
Figure 3. A failed attempt to globalize a symbolic link on an updated Windows Server 2019 machine, using NtObjectManager.
Windows Server 2019 is the only Windows operating system supported by Kubernetes and was also included in the patch. All versions of Windows Server 2019, including the very first one, 1809, received the fix and are protected from this issue.
If you are using a cloud provider to host your Kubernetes cluster, make sure there are no pending updates for your nodes. On the other hand, if you are hosting your cluster on your own, make sure your nodes have the latest updates installed.
Conclusion
Although this fix provides great relief since it closes the known exploits in the wild, it does not completely get rid of the risk of running Windows Server containers for certain purposes. As discussed in my previous blog, users should follow Microsoft’s guidance recommending not to use Windows containers as a security feature. Microsoft recommends using strictly Hyper-V containers for anything that relies on containerization as a security boundary. Any process running in Windows Server containers should be assumed to have the same privileges as admin on the host, which in this case is the Kubernetes node. If you are running applications in Windows Server containers that need to be secured, we recommend moving these applications to Hyper-V containers.
Nevertheless, and even though containers will always be less secure than a real Virtual Machine with a separate kernel, this fix is a move in the right direction, helping to make Windows containers as secure as their Linux counterparts.
Palo Alto Networks Prisma Cloud protects customers from Siloscape attacks. In addition, Prisma Cloud Compute will alert customers who have old versions of their hosts that are vulnerable to known CVEs.
Figure 4. Choosing action for unexpected processes on Prisma Cloud.
Prisma Cloud’s Runtime Protection feature learns the machine’s behavior and creates a set of rules for processes. Once the learning is complete, the user can choose the action for new, unexpected processes attempting to execute. The user can choose to alert, prevent or completely block the execution.
Unit 42 recently shared information about a new attack surface targeting Microsoft Internet Information Services (IIS) and SQL Server at Black Hat Asia 2021. In our presentation, we introduced a previously undisclosed technique to execute SQL queries on the remote database in IIS and SQL Server under SQL injection or ad hoc scenarios. We also discussed three typical cases picked from around 100 Jet vulnerabilities that we discovered in a three-month period. Here, we cover the details of the technique, which allows threat actors to remotely attack IIS and SQL Server to gain SYSTEM privilege by using Microsoft Jet Database Engine vulnerabilities.
In response to this research, Microsoft released a complex patch to mitigate this attack surface. However, the patch is turned off by default and most Jet vulnerabilities are still not patched. We highly recommend that our customers proactively turn on mitigation to disable remote tables access in the registry and stay cautious of these kinds of attacks. Besides that, the mitigation for the attack surface in Access Connectivity Engine (ACE) still remains imperfect, and we are working with Microsoft to release a complete patch for both MS Jet and ACE.
The new attack surface is caused by the remote database access supported in Microsoft Jet Database Engine, including MS Jet Red (Jet Red Database Engine) and ACE (Access Connectivity Engine). It is a practical feature, but can also bring potential security issues. When misused, the feature allows attackers to execute SQL queries on the fully controlled database file on the remote attacker’s controlled server. Once the remote legitimate database file is replaced with a malformed database file, executing SQL queries on it could break the code precondition and assumptions in Microsoft Jet/ACE, leading to vulnerabilities in many Jet components.
The overall impact and break in security boundaries from these Jet vulnerabilities depend on where the SQL query is executed. The typical attack scenarios are SQL injection and ad hoc. In these two scenarios, attackers can execute any SQL queries on the malformed databases in the IIS and SQL Server. The resulting Jet vulnerabilities will impact the IIS and SQL Server. In detail, users can assign a remote database when executing SQL queries on tables by adding a database path ahead of the table in MS Jet and using OPENDATASOURCE,OPENROWSET or addlinkedserver in ACE, as shown in Figure 1.
Figure 1. Remote database access SQL in Access and SQL Server.
Inside MS Jet and ACE, CreateFile is called to open the remote database file in IIS and SQL Server. Given that the input path of the remote database is a UNC path, both Server Message Block (SMB) and Web-based Distributed Authoring and Versioning (WebDAV) will be used to open the remote database, as shown in Figure 2.
Figure 2. The hidden feature for CreateFile(UNC) in IIS and SQL Server.
SQL injection and ad hoc are just two of the possible attack scenarios. Similarly, IIS and SQL Server are only two of the potential victims. Any components supporting MS Jet and ACE on Windows could be vulnerable, as long as the component allows users to execute any query on the controllable database with MS Jet and ACE.
Vulnerabilities in IIS and SQL Server
The remote database access gives attackers the capability of replacing a legitimate database with a malformed database. According to our research, replacing the database is one of the keys to finding vulnerabilities in MS Jet and ACE. Assuming that code development and testing in MS Jet and ACE might not consider the situation of the database being malformed, we had the idea of mutating both SQL queries and database files. With that fuzzing strategy, we have discovered around 100 vulnerabilities in MS Jet and ACE, as shown in Figure 3. Most of them can be used to attack IIS and SQL Server under SQL injection and ad hoc scenarios.
Figure 3. ~100 MS Jet vulnerabilities.
In our presentation, we proved that just one byte change in the database file can lead to an MS Jet vulnerability, as shown in Figure 4.
Figure 4. The power of one byte mutation of the database.
Microsoft Patch
With the Patch Tuesday update for Windows released in May 2021, Microsoft assigned CVE-2021-28455 to our discovery and patched the new attack surface we reported. The patch introduces an option for users to disable remote database access in the MS Jet component and ACE component. Instead of patching every single JET vulnerability, it mitigated the whole attack surface disclosed in our presentation in multiple applications that use MS Jet, such as IIS and Access.
As we can see in Figure 5, there is a new field at offset 904h in the rgtib structure (represented by ebx register) for remote database access. It is set to 1 by default in the _ltibAllocate function, which means it is enabled by default.
Figure 5. Default value set for new field AllowQueryRemoteTables in the rgtib structure.
Then the UtilRegQueryValue2 function is called in the ErrReadRegistry function to get the value of the registry key – AllowQueryRemoteTables – under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\engines registry entry. After that, it stores the value to the AllowQueryRemoteTables field of the rgtib structure shown in Figure 6.
Figure 6. Get AllowQueryRemoteTables field from the registry in the UtilRegQueryValue2 function.
After that, two functions ( _ErrGetOutputDatabaseId and _ErrQEMCompileQuery) check the AllowQueryRemoteTables field in the rgtib structure (represented by ecx register), as figure 7 depicts.
Figure 7. Check the AllowQueryRemoteTables field in the rgtib structure.
As we can see in figure 8, if the AllowQueryRemoteTables field is set to 0, then the _ErrGetOutputDatabaseId function will return an error and the ErrTryOpenDatabase function will not be invoked to open the database file, regardless of whether the database file is remote or local. This effectively mitigates the remote database access attack surface.
Figure 8. AllowQueryRemoteTables field check in the _ErrGetOutputDatabaseId function.
However, this feature is not turned on by default. To disable remote database access, users need to add a registry, named AllowQueryRemoteTables, in corresponding registries as described in this Microsoft document and set the dword value to 0.
Next-Generation Firewall Mitigations for CVE-2021-28455
Palo Alto Networks Next-Generation Firewall customers can configure their Security Policy Rule settings to protect themselves from attacks related to CVE-2021-28455 by blocking WebDAV traffic from traversing from the trusted to untrusted zones.
How to configure App-ID to drop WebDAV packets:
Step 1: Create a Security Policy Rule.
1. Select Policies > Security and Add a new rule.
2. Enter a Name for the rule and add an optional Description.
Figure 9. Configuring Security Policy Rule.
3. On the Source tab, add “trust” to the Source Zone.
Figure 10. Configuring Source Zone.
4. On the Destination tab, add “untrust” to the Destination Zone.
Figure 11. Configuring Destination Zone.
5. On the Application tab, add WebDAV to the Applications.
Figure 12. Configuring applications.
6. On the Actions tab, use Drop action in Action Setting.
Figure 13. Configuring actions.
7. Click OK.
Step 2: Commit your changes.
Conclusion
IIS and SQL Server are examples of fundamental components in the Microsoft ecosystem that have been widely deployed in many production systems and services. Microsoft Jet Database Engine, including MS Jet and ACE, are over 20 years old, and a vast majority of the Jet modules have been found to be easily exploitable due to limited exploit mitigations. The remote database access feature connects the Jet vulnerabilities with IIS and SQL Server components, thereby downgrading their security to the same level as the Jet Database Engine. Attackers could potentially leverage this feature to attack IIS and SQL Server and get SYSTEM privilege remotely from a single SQL injection.
Palo Alto Networks recommends all of our customers follow the Microsoft guidance and disable remote database access to mitigate this severe attack surface. This can help prevent attackers from using Jet vulnerabilities to compromise IIS and SQL Server. Palo Alto Networks Next-Generation Firewalls can help mitigate such attacks by using App-ID and the Threat Prevention security subscription.
Ransomware is one of the top threats in cybersecurity and a focus area for Palo Alto Networks. In the current threat landscape, ransom payments are rising and organizations are seeking to protect themselves from threat actors. In the 2021 Unit 42 Ransomware Threat Report, we detailed the observations and the trend of top ransomware families from January 2020-January 2021. This post supplements that information based on observations from the first three months of 2021, and will discuss the propagation of different ransomware families we observed in the wild and the different types of extortion used. We hope the information will help readers get a clear picture of current directions in ransomware trends.
Ransomware Trends in Early 2021
In the first quarter (Q1) of 2021, Unit 42 detected 113 different ransomware families in the wild. Based on the statistical data, the top 15 ransomware families only cover 52.3% of total ransomware cases. This demonstrates the diversity of ransomware and emphasizes how difficult it is to expand ransomware detection coverage with static profiling. Figure 1 shows the proportion of ransomware sample numbers for different families that Unit 42 detected in the wild. Among all, 6.7% of the ransomware samples are Virlock, which has been active since 2014. Virlock has the largest number of variants due to its file-infector-like behavior.
Figure 1. Ransomware variant numbers, showing the proportion of ransomware sample numbers for different families that Unit 42 detected in the wild.
Higher malware variant numbers don't necessarily imply a higher prevalence. Some ransomware families don’t deliver different variants every time, but the infection ratio per sample is high, meaning attackers delivered the same malware to huge numbers of victims. Figure 2 shows a completely different result from Figure 1 and stems from only counting ransomware samples from cases in which more than five hosts were infected with the same malware. From this lens, the top three families observed are Ryuk (31.7%), Sodinokibi (20%) and Maze (15%).
Figure 2. Top ransomware families based on prevalence.
Emails are still the most efficient method to deliver and propagate ransomware. Figure 3 shows ransomware arrives via different application protocols. The majority of ransomware is delivered by email. Web browsing is the second most common entry vector for ransomware infections. The process of delivering malware by a URL can include various techniques. For example, the URL links can be posted on forums or chat group software, sent by IM applications, offered via fake freeware for download or attached in emails. Web hosting ransomware can also be downloaded and successfully installed through a multi-layered infection chain among different file types. For example, AlumniLocker is first delivered as a phishing PDF. It leads to downloading a ZIP archive that contains an LNK downloader. This downloads and executes an obfuscated PowerShell script to finally install the ransomware.
Figure 3. Arrival protocols used to deliver ransomware and their prevalence.Figure 4. File Type Breakdown.
Figure 4 breaks down which file types we saw in the course of ransomware detection and their prevalence. 32-bit EXE is the most common ransomware file type we observed. Other file types are often used as the first stage of infection or downloaders, such as archives, documents and scripts. Most ransomware is delivered via email with an attached archive; the ransomware is compressed in the archived files with or without password protection. “Resume” or “portfolio document” are examples of archive file names, and the archive contains one or more pieces of malware with fake document file icons. One example here is Makop, contained in a 7z archive along with an infostealer malware (SHA256: DE6DFA018773E07C218EF1DF62CE0D99A708841BF1DDFB4C6AD7E323D5D666A4). A script file is also used to download or install ransomware. For example, GandCrab uses JScript as a downloader, leveraging Windows Background Intelligent Transfer Service (BITS) to download the payload in the background (Figure 5). We also observed that Mailto (AKA NetWalker) tends to deliver ransomware in a highly obfuscated PowerShell script. Exploit documents are seldom seen for delivering ransomware. One example is an exploit RTF that led to downloading and installing Makop ransomware remotely.
Figure 5. GandCrab uses an HTTP BITS file transfer service to download a payload in the background.
Besides encrypting files on infected hosts, the main feature of ransomware is, of course, the demand for ransom. Since ransomware threat actors have had years to evolve their techniques, there are now several different ways for attackers to receive payments and provide the "service" they claim to offer. Usually, after the ransomware successfully installs, it pops up a message box or leaves text files to explain how to pay the ransom – the ransom note. Some ransomware locks the victim's screen and only displays the ransom note.
Unit 42 has reviewed ransom notes from different ransomware families. Most ransom notes request payment in cryptocurrency or mention reaching out via the darknet, though some other contact methods also appear.
Payment in Cryptocurrency
In these cases, the ransom note asks victims to pay a specific amount in cryptocurrency – Bitcoin (BTC), Monero (XMR), etc. — to a specific wallet address. Two ransomware families that utilize these types of ransom notes are Virlock and WanaCrypt0r.
Payment Through the Darknet
Some ransomware families, including Babuk, Sodinokibi, Cerber, Mailto, Ryuk and others, seldom show the ransom amount or cryptocurrency wallet address. Instead, they instruct victims to install TOR and reach out to them on the darknet. Usually, they host a website for victims to input the identification key found in the ransom note, upload encrypted files for decryption – and pay the ransom.
Other Methods of Ransom Payment
Ransom notes from Makop, Dharma, Ryuk, DearCry and others, sometimes ask victims to reach out to them via email. The email addresses given are usually from untraceable email accounts. At other times, a threat actor lets the victim chat with them directly on group chat software. The victims can find the threat actor’s user name through specific group chat software or follow a chat group link in the ransom note.
Ransom Payment Operations
Ransom payment operations are complicated and highly automated processes. Attackers can create a lot of cryptocurrency wallets automatically; they can even make a unique wallet address for each victim. Once a ransom is received, the ransom will be involved in the multiple transactions that are managed to distribute and aggregate the ransom across thousands of virtual wallets. For example, the Xorist ransomware (SHA256: 4979A10B81C41ECC0FC3A0F376ADE766CE616D2301639F74E0277047CC40E3D6) demanded £1,000 for a ransom; the bitcoin wallet address was 1BFqrLCDwwrxueY7FFDn8DqeoasPJignxt. However, this wallet had not really received any ransom payments when the malware was delivered. The wallet got involved in the operation of mixing and tumbling among several other virtual wallets. This is a pretty common operation when attackers want to withdraw or disperse currency from ransom payments into other wallets. During the operation, 25.1 BTC from 538 wallets was sent to 1NDyJtNTjmwk5xPNhjgAMu4HDHigtobu1s (SHA256: CE11703DEF517306326C48A67A7C859A3DE0F18E2451DF226CE171389A5B7953), which is a wallet owned by Binance cryptocurrency exchange. (ref: Binance on Twitter ). The 25.1 BTC amount was worth $1.18 million at that time, and now is about $876,000.
Ransomware Families: Low and High Profile
Since Virlock only requests a $250 ransom, it does not draw too much public attention. Other ransomware families, however, target enterprises and ask for multimillion dollar ransoms, which garners much more media attention. Based on the way Virlock spreads the ransom amount it demands, it is likely designed to target consumers or home users.
After infection, Virlock hides the file extension through modification of the registry (HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\HideFileExt= 1, HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\Hidden= 2). The encrypted file icon will look the same as usual, but after opening the infected file, the ransom note will pop up. Virlock uses, but isn’t limited to, PDF, DOC, PPT, JPG, BMP,GIF, RAR, 7Zip, Zip and EXE files. Figure 6 is a screenshot of a recently captured Virlock ransom note. The attacker asked for $250 and required payment as 0.004 BTC (suggesting that at the time the ransom note was written, 1 BTC equaled approximately $62,500). At the time of infection experiments, 1 BTC equaled approximately $54,649, suggesting that the exchange rate in the ransom note is not updated on the fly. Some Virlock variants ask for more ransom, such as 0.771 BTC, 1.008 BTC or more.
Figure 6. Virlock ransom note.
The top three samples we observed spreading in early 2021 were Ryuk, Maze, and Sodinokibi. These three contribute 7.2% out of the total infected numbers we collected.
Ryuk will change the infected file extension to .RYK, and leave a ransom note called RyukReadMe.html. One of the reasons Ryuk causes so much damage is because it will scan the local network and try to infect other machines through Server Message Block (SMB) protocols. Ryuk will even send out Wake-on-LAN packets to wake up systems that have been configured with this feature.
Figure 7: Ryuk sample sent Wake-on-LAN
Conclusion
In this research, we discussed ransomware family trends we observed in the first three months of 2021. First, we reviewed the trends from prevalent ransomware families, then we discussed the most common file types used as attack vectors leveraged by ransomware. Lastly, we gave an example of ransom operations and updates about top ransomware families.
Ransomware threats are a serious challenge. Employing effective backup strategies and disaster recovery procedures is important. Palo Alto Networks customers are further protected from ransomware. Cortex XSOAR can automatically and instantly coordinate with network security, malware analysis and threat management solutions to ensure customers remain protected. Cortex XDR endpoint protection stops malware, exploits and ransomware before they can compromise endpoints. With AI-powered Inline analysis, the Next-Generation Firewall stops exploits that lead to infection, and WildFire’s always up-to-date machine learning models monitor behavior to preemptively detect unknown ransomware.
If you think you may have been impacted by ransomware, please email unit42-investigations@paloaltonetworks.com or call (866) 4-UNIT42 to get in touch with the Unit 42 Incident Response team.
While monitoring the Microsoft Exchange Server attacks in March 2021, Unit 42 researchers identified a PlugX variant delivered as a post-exploitation remote access tool (RAT) to one of the compromised servers. The variant observed by Unit 42 is unique in that it contains a change to its core source code: the replacement of its trademark word “PLUG” to “THOR.” The earliest THOR sample uncovered was from August 2019, and it is the earliest known instance of the rebranded code. New features were observed in this variant, including enhanced payload-delivery mechanisms and abuse of trusted binaries.
First discovered in 2008, PlugX is a second-stage implant that’s been used by Chinese cyberespionage group PKPLUG (aka Mustang Panda) and other groups. In addition to being used in multiple high-profile attacks over the years, including the significant U.S. Government Office of Personnel Management (OPM) breach in 2015, PlugX is also known for its modularity and plug-in-style approach to malware development.
Additional hunting and analysis led to the identification of several more samples along with an associated PlugX command and control (C2) infrastructure. This blog provides a technical overview of the PlugX variant discovered, indicators of compromise (IOCs) to identify it in networks and a tool developed by Unit 42 to handle payload decryption.
On March 19, 2021, attackers were observed exploiting an Exchange Server via a chain of zero-days (CVE-2021-26855 and CVE-2021-27065), known as ProxyLogon, originating from IP 101.36.120[.]227. Upon successful exploitation, a webshell was uploaded to a publicly accessible web directory, allowing code execution at the highest privilege level.
The attackers then used a technique known as “living off the land,” which uses trusted binaries to bypass antivirus detection. In this case, the Microsoft Windows binary bitsadmin.exe was used to download an innocuous file named Aro.dat (SHA256: 59BA902871E98934C054649CA582E2A01707998ACC78B2570FEF43DBD10F7B6F) from an actor-controlled GitHub repo to the target. (See Figure 1 for the download command executed.)
Figure 1. Bitsadmin command example.
Aro.Dat: Overview
The first one thousand bytes of Aro.dat (see Figure 2) indicate the file might be encrypted or possibly compressed. As it turns out, this data is nothing but random padding data likely added as a file header to evade AV signatures to thwart detection. The end of the filler data is null-terminated, which provides an identifier to the actual data entry point. Immediately following the NULL byte (0x00) is a set of x86 assembly instructions to unpack the file. In this sample, the x86 assembly starts at file offset 0x4EC with opcode 0x77. This translates to assembly mnemonic of JA (jump if above unsigned).
Figure 2 illustrates the Aro.dat file header up until the NULL byte. The data was truncated for brevity, as the bytes up until the NULL are meaningless. Red denotes the NULL byte, and green is where code execution begins.
Aro.dat is designed to remain undetected and cannot run without the aid of a specific loader. As with previous PlugX variants, code execution is achieved via a technique known as DLL side loading. Static analysis reveals that once loaded into memory, Aro.dat begins to unpack itself and initiates communication with a C2 server.
Aro.dat is, in fact, an encrypted and compressed PlugX payload. The decryption routine within Aro.dat closely resembles that of older PlugX variants (see Figure 3 below) in that it involves multiple decryption keys and bit shift operations. Once decrypted, it gets decompressed via the Windows API RtlDecompressBuffer into a Windows module (DLL). The compression algorithm is LZ compression (COMPRESSION_FORMAT_LZNT1).
Figure 3. Comparison of PlugX decryption routines
The highlighted entries shown in Figure 3 are the static decryption keys used by Aro.dat and an older 2012 PlugX sample (SHA256: A68CA9D35D26505A83C92202B0220F7BB8F615BC1E8D4E2266AADDB0DFE7BD15). The decryption routine differs slightly with each PlugX build by using different static keys and varying the use of addition and subtraction.
The decrypted, decompressed Aro.dat is an x86 Windows DLL or PE file.
Aro.Dat: Code Execution
The Aro.dat file contains the following string names: aross.dll, aro.exe and aro.dat. The association of these three files together provides insight into how code execution is likely achieved. VirusTotal has the following files:
Open-source research suggests Aro.exe is part of the “ARO 2012 advanced repair and optimization tool.” It is a freely available tool that claims to fix Windows registry errors. It is digitally signed, has known associations with a PlugX loader and dynamically loads Aross.dll. Aross.dll is the actor’s DLL file that is responsible for loading the encrypted payload file, Aro.dat. With this information, we can infer that these two files are necessary and responsible for loading the encrypted THOR payload, Aro.dat.
See Figure 4 for an illustration of how code execution is achieved.
Figure 4. DLL sideloading overview for Aro.dat
Aro.Dat: Runtime Operation
Once the decrypted payload runs in memory, it exhibits the same behaviors as previous PlugX implant variants. It starts by decrypting the embedded PlugX hardcoded configuration settings. The decryption algorithm and XOR keys are fairly consistent across multiple PlugX implants. Code behavior closely resembles that of the RedDelta PlugX that’s been reported by Insikt Group. One noticeable difference with this sample compared to all the other known PlugX malware families is the magic number check performed during the initialization of the PlugX plugins. Historically, that number has always been 0x504C5547, which corresponds to the PLUG value in ASCII encoding. In this sample, the magic number is 0x54484F52, corresponding to the THOR value in ASCII encoding.
Figure 5 below illustrates the differences.
Figure 5. DLL PlugX magic number comparison
The hardcoded PlugX configuration settings within the sample decoded to the following values (truncated):
As illustrated in Figure 6, this particular PlugX implant is configured for the following:
Four C2 domains of rainydaysweb[.]com
Communication with ports: 80, 443, 53 and 8000. Data is transmitted on both TCP and UDP protocols. Outputs data transmitted to debug (outputdebugstringW) to debugger (if attached). Example:
Figure 7. Debug output example
Uses the HTTP protocol. The initial handshake with the C2 is not HTTP, and it consists of random bytes of variable lengths. The implant expects 16 bytes of data for the return and, depending on the return value (command), will initiate HTTP communication. The PlugX SxWorkProc thread is responsible for handling HTTP communications. An example HTTP header:
Figure 8. HTTP POST example
Breakdown of Figure 8:
POST data is made of random bytes.
User-agent is a hardcoded value: Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 10.0; .NET4.0C; .NET4.0E; Tablet PC 2.0).
utmcn, utmcs, utmsr, and utmsc are hardcoded user-agent values.
To create a Windows system service using the name and description: HP Digital Image
Figure 9. PlugX sample running as HP Digital Image
Possible campaign ID of 1234
When running, system events such as process creation, date and time and username are logged to a hidden file named NTUSER.DAT, located in the C:\ProgramData\MSDN\6.0 directory. This file is encrypted with a two-byte key of 0x4F6F.
There are two other identifiable attributes for PlugX:
1. The hidden Windows class name, Static, shown in Figure 10. This window is used for inner-process communications.
Figure 10. PlugX Windows class name
2. The MZ and PE headers of the RWX in-memory module are removed and replaced with ASCII ROHT (THOR backwards), shown in Figure 11.
Figure 11. In-memory module artifact
This sample has the following PlugX plugins, which have an individual hardcoded date stamp, as illustrated in Table 1 below. Much has been said about these plugins in the past. In summary, they provide attackers various capabilities to monitor, update and interact with the compromised system to fulfil their objectives.
Plugin Name
Date Time Stamp Value
Disk
0x20120325
Keylog
0x20120324
NetHood
0x20120213
NetStat
0x20120215
Option
0x20120128
PortMap
0x20120325
Process
0x20120204
RegEdit
0x20120315
Screen
0x20120220
Service
0x20120117
Shell
0x20120305
SQL
0x20120323
Telnet
0x20120225
Table 1. PlugX plugins
This sample also appears to contain a key or a hard-coded date of 20180209, which is used within a structure and passed whenever a function object is called.
Links to PKPLUG
PlugX modules, such as Aro.dat, include hardcoded configuration information allowing for multiple C2 addresses. This provides fallback options for the backdoor in case some remote services are unavailable at the time of compromise. In this particular PlugX implant (SHA256: 59BA902871E98934C054649CA582E2A01707998ACC78B2570FEF43DBD10F7B6F), and as shown in Figure 6 above, all four C2 configuration options reference the domain name rainydaysweb[.]com.
Overlaps between the recently discovered PlugX samples with the THOR magic bytes (the infrastructure) and other entities associated with known PKPLUG activity are highlighted in Figure 12 below, stemming from the orange rectangle and the red square, respectively.
As previously mentioned, Aro.dat (SHA256: 59BA902871E98934C054649CA582E2A01707998ACC78B2570FEF43DBD10F7B6F) was downloaded from an actor-controlled GitHub repository to the target Microsoft Exchange Server using bitsadmin. As such, the specific component responsible for loading and decrypting the module is unknown. However, the connection from it to rainydaysweb[.]com is shown in the blue oval shape in Figure 12.
Several overlaps of related infrastructure and common malicious behaviors were found and are described below using reference number notation [x] that references parts of Figure 12.
PlugX sample (SHA256: 93D33626886E97ABF4087F5445B2A02738EA21D8624B3F015625CD646E9D986E)[1], first seen March 19, 2021, uses the traditional PLUG (not THOR) identifier and communicates with the same C2, rainydaysweb[.]com. This sample also shares some behavioral characteristics with other PlugX samples, namely registry activity specific to the creation of the key, HKLM\Software\CLASSES\ms-pu\PROXY[2]. Some of those samples make use of the C2 infrastructure linked to PKPLUG activity in the past, such as PlugX sample (SHA256: A15FED60E69EC07BFD01A23BEEC2C8E9B14AD457EA052BA29BD7A7B806AB63B4)[3] from late 2020 using C2 manager2013[.]com.
Other samples from the set using the common registry key, through the use of shared infrastructure, reveal further samples containing C2 communication information relating to the third-level domain, upload.ukbbcnews[.]com[4]. This domain is not and has never been a legitimate BBC domain and was registered to appear as such to victims. This domain resolved to IPv4 address 45.248.87[.]217 up until April 12, 2021, providing the C2 channel for PlugX sample (SHA256: 690C488A9902978F2EF05AA23D21F4FA30A52DD9D11191F9B49667CD08618D87)[5] with its THOR module mpsvc.ui (SHA256: 64E2FE0E9D52812D2DA956B1D92B51E7C215E579241649316CF996F9721E466E) from early August 2020.
Other "ukbbcnews" third-level domains (i.e. bbc., news. and www.)existed and resolved to the same 45.248.87[.]217 IPv4 address from as far back as May 2019 through March 2021. In 2018, the same third-level domains resolved to some IPv4 addresses in the 134835 ASN range, including 185.239.226[.]65, 185.239.226[.]76 and 185.239.226[.]14, which have been used as C2 channels for various PlugX samples, seemingly throughout 2018, 2019 and 2020. PlugX sample (SHA256: 3CDD33DEA12F21A4F222EB060E1E8CA8A20D5F6CA0FD849715F125B973F3A257)[6] from June 2018 shares behavioral traits, namely setting the value of registry key HKLM\SOFTWARE\Classes\KET.FAST\CLSID[7] to -1, with two other PlugX samples over the last three years.
Out of the set of three such PlugX samples known to Unit 42 that changed the value of that registry key, one sample (SHA256: A9511CDAA96ED59DE73A7A7C7DC375DE204BEE7A9511C5EE71BF013010324A91)[8] existed around the same timeframe (June 2018) using the domain tibetsl[.]com and many third-level domains from it for C2 communication. The third PlugX sample, (SHA256: 80DEED939A520696968335D1BB2A9FCCE7053C0156F679BA261824D0A2D44967)[9], from the set also used the THOR identifier. From November 2019, this sample and its configuration module aross.dat (SHA256: C5DCD3073904FAD5D9A8FE1026141A832E05C9CA03A88FEE96587921F42773D4) used 108.61.182[.]34 for its C2 communication, which resolved to the indonesiaport[.]info[10] domain between September 2019 and February 2020. The same domain has been used for C2 communications by several other PlugX samples (using the PLUG identifier) that Unit 42 tracks as related to PKPLUG, dating as far back as August 2017.
Another configuration module using the THOR identifier, acrobat.chm (SHA256: B5C0DB62184325FFBE2B8EF7E6F13F5D5926DEAC331EF6D542C5FA50144E0280)[11] loaded by PlugX sample Acrobat.dll (SHA256: 3C5E2A4AFE58634F45C48F4E800DC56BAE3907DDE308FF97740E9CD5684D1C53) was first seen at the end of October 2020. The C2 channel from the configuration is tools.scbbgroup[.]com, which at the time resolved to 167.88.180[.]131, and since early February 2021, it continues to resolve to 103.85.24[.]158 under the ASNs 6134 and 134835, respectively[12]. Other known PKPLUG infrastructure using additional IP addresses from the range under both ASNs are tracked by Unit 42 and other vendors.
Examples include www.ixiaoyver[.]com and www.systeminfor[.]com that resolved in April and May 2020 respectively to 103.85.24[.]190, which acted as C2 channels for several PlugX samples (using the PLUG identifier).
Shortly after the brief, two-day period when www.systeminfor[.]com resolved to 103.85.24[.]190, the resolution briefly changed to 167.88.180[.]32 (ASN 6134), which other PKPLUG-related domains resolved to throughout the course of 2020. One such domain was www.cabsecnow[.]com, which was used as a C2 channel for another PlugX sample (SHA256: A9CBCE007A7467BA1394EED32B9C1774AD09A9A9FB74EB2CCC584749273FAC01)[13] and configuration module Smadav.dat (SHA256: E2D21B5E34189FA1ACA39A13A405C792B19B6EDF020907FB9840AF1AAFBAA2F4) using the THOR magic bytes in August 2020.
The final PlugX sample using the THOR identifier [14] is SmadHook32.dll (SHA256: 125FDF108DC1AD6F572CBDDE74B0C7FA938A9ADCE0CC80CB5CE00F1C030B0C93) and its configuration module Smadav.dat (SHA256: CC1AFB373F8286C08869CD786FEE75B8002DF595586E00255F52892016FD7A4F) is the most recent THOR sample Unit 42 has discovered. First seen in March 2021, this sample's C2 references news.cqpeizi[.]com, which since late 2019 resolves to the loopback address 127.0.0[.]1.
PlugX: The Hunt for Others
With an understanding of how the encrypted payload files are constructed, Unit 42 researchers created a signature based on the x86 assembly instructions. These instructions are used to unpack the payload. (See Table 2 for a list of files discovered.)
During our research, we discovered other PlugX-encrypted payloads that have a different encoding scheme and file header. These samples are XOR encoded with the decryption key consisting of the bytes starting at file offset zero, up until the NULL byte. Typically, the key is 10 bytes in length. Once decrypted, the sample is that of a PE file (DLL). (Reference Table 3 for a list of files uncovered that follow this format.)
We’ve identified two other PlugX-encrypted payload files with different encoding schemes. These files were manually decrypted and confirmed to be PlugX variants. (See Table 4.)
Unit 42 PlugX Payload Decrypter
Unit 42 created a Python script that can decrypt and unpack encrypted PlugX payloads without having the associated PlugX loaders. It attempts to detect the type of PlugX-encrypted samples and then outputs the following:
Decrypted and decompressed PlugX module (DLL). Adds an MZ header to the file as the MZ header is not present in the in-memory module. It only applies to encrypted payloads that have the random byte header (THOR payloads).
Hardcoded PlugX configuration file (C2 information), if supported.
Thirteen years after its initial discovery, the PlugX malware family remains a threat. After 10+ years of consistent source code components, the developers made an unexpected change to its signature magic value from “PLUG” to “THOR.” New features were observed in this variant, including enhanced payload delivery mechanisms and abuse of trusted binaries. With the THOR identifier signature, Unit 42 will continue to search for additional samples and variants that may be associated with this new PlugX variant.
Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and systematically disrupt malicious cyber actors. Visit the Cyber Threat Alliance for more information
Unit 42 has discovered a specific single bit (Trap Flag) in the Intel CPU register that can be abused by malware to evade sandbox detection in general purposes. Malware can detect whether it is executing in a physical or virtual machine (VM) by monitoring the response of the CPU after setting this single bit.
Sandboxing is a popular technique used to detect whether a sample is malicious. A sandbox analyzes the behaviors of the binary as it executes inside a controlled environment. To overcome the challenge of analyzing a large number of binaries with limited computing resources, virtual machines are used to build sandboxes. To evade detection, malware will try to determine whether it is executing in a physical or virtual machine. When the malware finds out it is executing in a virtual machine, it will terminate its execution or provide fake outputs to hide its real intentions.
Some of the most common evasion techniques involve malware conducting various system checks against the environment it is executing in. For example, malware will often look for abnormal screen resolution, hard disk and physical memory size. Sandboxes can build countermeasures, such as returning fake information to the malware during these checks.
This blog documents how malware can detect the differences in CPU behaviors in a virtual or physical machine with only a single bit in the CPU register.
Single-Step Mode With a Single Bit — the Trap Flag (TF)
To detect the use of a VM in a sandbox, malware could check the behavior of the CPU after the trap flag is enabled.
The trap flag (TF) is the 8th single bit in the EFLAGs register of the Intel x86 CPU architecture. If the TF is enabled before a single instruction is executed, the CPU will raise an exception (single-step mode) after the instruction is completed. This exception stops the CPU execution to allow the contents of the registers and memory location to be examined by the exception handler. Before allowing code execution to continue, the CPU also has to clear the TF.
To determine whether a VM is used, malware can check whether the single-step exception was delivered to the correct CPU instruction, after executing specific instructions (e.g. CPUID, RDTSC, IN) that cause the VM to exit with the TF enabled. During VM exits, the hypervisor – also known as Virtual Machine Monitor (VMM) – will emulate the effects of the physical CPU it encounters.
The following sequence of instructions explains the CPU’s behavior after enabling the TF in a physical machine.
Figure 1. CPU instructions to enable TF.
The first three instructions enable the TF bit in the EFLAGs register of the CPU. RDTSC is executed with the TF enabled. In a physical machine, the exception would be delivered to the first no operation (NOP) instruction (0x00401073). Take note that the exception occurred on the instruction immediately after the execution of the instruction with TF enabled.
Figure 2. Execution in a physical machine.
Executing the same sequence of instructions in a VM would have a different effect. In a VM, executing RDTSC would result in a VM exit. The hypervisor will carry out its usual tasks of emulating the behaviors of the RDTSC instruction. However, an implementation of the hypervisor with incorrect emulation of the TF would result in the TF being ignored and the code execution will continue to the first NOP instruction. During the execution of the first NOP instruction, the TF is still enabled as the TF was not handled by the hypervisor. This results in an exception occurring on the second NOP instruction (0x00401073). The correct implementation will require the hypervisor to inject a debug exception after emulating the instruction that caused the VM exit and clearing the TF.
Figure 3. Execution in a virtual machine.
As a sandbox evasion technique, malware will use an exception handler in addition to the above instruction sequence to examine which instruction the exception occurred on. The next section describes a real-world example of a malware family that made use of this technique to evade sandboxes.
Real-World Example
Lampion is a malware family that was targeting users in Portugal. Lampion employed multiple system checks to evade sandbox detection. One of the techniques is making use of the single-step mode with TF, as discussed in the previous section.
Lampion implemented all its system checks with x86 assembly instructions and minimal Windows API calls. This allowed the Lampion samples to conceal their behavior from the sandboxes. The Lampion samples would terminate if the malware determined it was executing inside a VM. The system checks are also intertwined with multiple anti-reverse engineering techniques to hide from human analysts.
The following screenshot shows a snippet of instructions hidden in the Lampion sample that conducts the system check.
Figure 4. Instructions in Lampion used to evade sandboxes.
The following is pseudocode to demonstrate how Lampion carries out one of its sandbox system checks by enabling TF on an instruction that causes the VM to exit.
Figure 5. Pseudocode of Lampion carrying out anti sandbox check using TF.
The instruction right after the instruction RDTSC is NOP. The byte code for the NOP instruction is 0x90. The exception handler would traverse the ContextRecord structure to locate the address of the instruction in the Extended Instruction Pointer register (EIP) when the exception occurred. The instruction is then compared against the 0x90 byte and the malware will exit if the check fails.
The following screenshot shows the EIP=0x7F0E4E when the exception happened.
Figure 6. Address of the instruction where the exception occurred.
Malware vs Sandbox Authors
For many years, there has been an ongoing cat and mouse game between malware authors crafting evasion techniques to prevent effective analysis, and sandbox authors who research novel ways to defeat those evasions.
This is one of the main drivers that led us at Palo Alto Networks to build our own custom hypervisor for malware analysis. Since we have full control over the software stack, including the virtualization layer, we can react to new and emerging threats. In this particular case, once we had identified the issue with the incorrect emulation of the trap flag, our hypervisor team was able to test and deploy a fix. This evasion issue has since been resolved for any malware sample using this technique.
Palo Alto Networks customers are further protected from malware families using similar sandbox evasion techniques with Cortex XDR or the Next-Generation Firewall with WildFire and Threat Prevention security subscriptions. AutoFocus customers can track the malware discussed here using the Lampion tag. Other similar sandbox evasion techniques that rely on abusing Intel CPU instructions or registers will not work against WildFire.
As cyber extortion flourishes, ransomware gangs are constantly changing tactics and business models to increase the chances that victims will pay increasingly large ransoms. As these criminal organizations become more sophisticated, they are increasingly taking on the appearance of professional enterprises. One good example is Mespinoza ransomware, which is run by a prolific group with a penchant for using whimsical terms to name its hacking tools.
Our Unit 42 cybersecurity consultants have observed the gang attacking U.S. publishing, real estate, industrial manufacturing and education organizations with ransom demands as high as $1.6 million and payments as high as $470,000. The FBI recently published an alert about the group, also known as PYSA, following a hacking spree on K-12 schools, colleges, universities and even seminaries in the United States, as well as the United Kingdom.
To learn more about this group, we monitored its infrastructure — including a command and control (C2) server it uses to manage attacks and a leak site where it posts data of victims who refused to pay large ransoms. Here are some our our key findings on the Mespinoza gang:
Extremely Disciplined: After accessing a new network, the group studies compromised systems in what we believe is triage to determine whether there’s enough valuable data to justify launching a full-scale attack. They look for keywords including clandestine, fraud, ssn, driver*license, passport and I-9. That suggests they are hunting for sensitive files that would have the most impact if leaked.
Targets Many Industries: Victim organizations are referred to as “partners.” Use of that term suggests that they try to run the group as a professional enterprise and see victims as business partners who fund their profits. The gang’s leak site provided data it claims belong to 187 victim organizations in industries including education, manufacturing, retail, medical, government, high tech, transportation and logistics, engineering and social services, among others.
Has Global Reach: 55 percent of victims identified on the leak site are in the United States. The rest are scattered across the globe in more than 20 countries including Canada, Brazil, United Kingdom, Italy, Spain, France, Germany, South Africa and Australia.
Is Cocky When Approaching Victims: A ransom note offers this advice: “What to tell my boss?” “Protect Your System, Amigo.”
Uses Attack Tools with Creative Names: A tool that creates network tunnels to siphon off data is called “MagicSocks.” A component stored on their staging server and likely used to wrap up an attack is named “HappyEnd.bat.”
We’ve responded to incidents where the ransomware operators use Remote Desktop Protocol (RDP) to access the impacted organization’s network and make use of various open-source and built-in system tools to aid lateral movement and credential gathering. The operators leverage double-extortion tactics — exfiltrating data prior to deploying the ransomware so they can later threaten to leak it — and install a new backdoor, we call Gasket, (based on the malware’s code) to maintain access to the network. Gasket also references a capability called “MagicSocks,” which uses the open-source Chisel project to create tunnels for continued remote access to the network.
We’ve observed the Mespinoza ransomware gang exfiltrating files to a remote server whose filenames match a list of keywords prior to installing the ransomware via a PowerShell script. The keywords include the sub-strings “secret,” “fraud” and “SWIFT.”, which suggests the actors sought to gather and exfiltrate sensitive files that would have the most impact on the organization if the actors released the files to the public. At the time of this writing, the gang’s leak site named and provided information on 187 organizations in various industries globally.
Figure 1. Mespinoza victimology by country.Figure 2. Mespinoza victimology by industry.
In many of the descriptions, the actor refers to the impacted organization as their “partner.” We suspect that Mespinoza uses the term because they view their operations as a professional enterprise and their “partners” as business partners funding their business.
The Gasket and MagicSocks tools, as well as the exfiltrated data on the leaked site, date back to April 2020, which suggests the Mespinoza ransomware gang has been active for more than a year. While there are reports suggesting that the Mespinoza ransomware gang has adopted a Ransomware-as-a-Service (RaaS) model, we have not observed this behavior from the group based on the ransomware cases we’ve investigated.
Gasket
During our analysis of a Mespinoza ransomware incident, we observed the threat actors installing a backdoor written in the Go language on the system prior to the distribution of the ransomware. According to a report published by France’s National Agency for the Security of Information Systems (ANSSI), ANSSI also observed threat actors delivering the Mespinoza ransomware using a payload written in Go. We analyzed the Go sample mentioned in the ANSSI report and found that it was an earlier and an unobfuscated version of the same tool we observed in our case.
The developers of Gasket wrote this backdoor in Golang and used the open-source Gobfuscate tool to obfuscate the payload. We call this tool Gasket, as the variant of this tool mentioned in the ANSSI report (SHA256: 9986b6881fc1df8f119a6ed693a7858c606aed291b0b2f2b3d9ed866337bdbde) designated as version “001,” which had the following two functions that it called to carry out its command and control (c2) communications:
main.checkGasket
main.connectGasket
We believe that the actors use this backdoor as a backup to RDP to maintain access to the network.
Gasket parses the command line arguments passed to it to determine whether it should run as a standalone process (no daemon mode), install itself as a service (daemon mode, no command line arguments) or to control a previously installed Gasket service. Gasket supports the following command line arguments:
no-persist
service Restart|Install|Start|Run
When attempting to install itself as a daemon, Gasket will create a service and run its functional code. The following service names have been extracted from the known Gasket samples:
AzureAgentController
CorpNativeHostDebugger
DefenderSecurityAgent
GetServiceController
JavaJDBC
MicrosoftSecurityManager
MicrosoftTeamConnect
MicrosoftTeamConnectDebugger
MicrosoftTeamManager
MsStudioAgentUpdateService
WindowsHealthSubSystem
WindowsManagementSystem
WindowsProtectionSystem
WindowsSoftwareManager
WindowsSoftwareManagerDebugger
Command and Control
A majority of versions of Gasket come equipped with a primary C2 communication channel, as well as a second fallback channel. Early versions of Gasket relied only on HTTP-based C2 communications using IP addresses for its servers, while later versions use the same HTTP-based C2 channel as a fallback and rely mainly on a DNS tunneling C2 channel. The DNS tunneling protocol uses DNS TXT queries and is based on an open source project called Chashell. For instance, the following DNS TXT query was issued by Gasket:
To understand the outbound DNS queries issued by Gasket, we analyzed Chashell’s server to determine how it processes the inbound DNS queries and to understand how the server constructs its responses. The Chashell C2 server will take the subdomain up to the fully qualified domain name for the C2 (transnet[.]wiki from above) and join the subdomain labels together without the periods removed. The server then decrypts the resulting data using XSalsa20 and Poly1305, of which the cleartext is treated as a serialized protobuf message. All Gasket samples that use the DNS tunneling C2 channel-based on Chashell use a unique key of 37c3cb07b37d43721b3a8171959d2dff11ff904b048a334012239be9c7b87f63 to decrypt the data transferred.
According to Chashell's GitHub, the chacomm.proto file describes the protobuf message structure that the server will use to parse the decrypted data received by Gasket and how it will structure its response. The structure of the message includes a clientguid field that is a GUID unique to the compromised host and either a ChunkStart, ChunkData, PollQuery or InfoPacket packet type. The structure of each packet type varies, but the following table describes each packet type's purpose:
Packet Type
Description
InfoPacket
Initial beacon that provides the compromised system's hostname to the C2.
ChunkStart
Provides a chunk identifier and tells the C2 how many DNS queries will be required to send the data.
ChunkData
Includes the chunk identifier, the current chunk and the data, so the C2 can reconstruct the uploaded data.
PollQuery
Acts as a heartbeat to keep the session alive, but is also used as the query type to get data from the C2.
Table 1. Description of Chashell's different packet types.
The C2 will respond to these queries with hexadecimal formatted data within the TXT answer, which is a serialized protobuf that uses the same message structure from Chashell’s chacomm.proto file. The following example shows the DNS requests and responses and the contents of the messages necessary to send data from the Chashell server to the Gasket payload via the DNS tunneling C2 channel:
Figure 3. Example DNS request and response flow of Chashell.
Unfortunately, Gasket would not run the hostname data provided via the Chashell server above as a command, as there’s a sub-protocol and a command handler used by Gasket to determine how to handle the server’s response, which we will discuss in the next section. Gasket also uses a sub-protocol in addition to Chashell's DNS tunneling protocol for its DNS requests, which prepends a message type followed by encrypted data to notify the C2 of the type of message. This suggests that the actors had modified the Chashell server code to support this modified communication channel. The following message types are available:
Message Type
Description
1
Initial check-in structured as <version number>///<encoded computer and user name>///<computer name>///<user name>
2
Heart-beat <version number>///<encoded computer and user name>
9
Data sent including output and debug messages
Table 2. Description of Chashell's different packet types.
As previously mentioned, many Gasket versions also have an HTTP-based backup C2 channel that it will use if the domains used in the DNS tunneling channel are inaccessible. The payload will issue HTTP requests directly to IP addresses, which does not require any DNS requests to operate. To support this backup channel, the payload includes a list of IP addresses that it has hardcoded into a four two-byte binary format that the payload decodes by subtracting 10 from each two-byte and uses the result to create the dot notation IP address. For instance, the bytes 37 00 9D 00 EF 00 27 00 in the binary would result in a list of 0x37, 0x9d, 0xef and 0x27, each of which have 10 subtracted from them to produce 0x2d, 0x93, 0xe5 and 0x1d, which results in 45, 147, 229 and 29. These values are then joined with a "." character to make the dot notation IP of 45.147.229[.]29. A full list of known HTTP-based Gasket C2 servers is available in Table 5, as well as the Indicators of Compromise (IOCs) section of this blog.
The initial beacon sent via the HTTP C2 channel involves a POST request to the URL /cert/trust. The POST request uses the default Go-http-client/1.1 user-agent and includes encrypted data that will look like the following:
Figure 4. Example Gasket initial beacon communication.
The data in the HTTP POST requests are encrypted with a rolling XOR algorithm, using the string dick as a key. The data within the initial beacon to /cert/trust contains a hardcoded version number 021, a unique identifier for the system (MD5 hash or base64 encoded string), the computer name and user name delimited by /// as seen in the following:
After the initial beacon, Gasket sends supplemental requests to a URL of /time/sync to obtain commands from the threat actor, which will look like the following:
Figure 5. Example Gasket supplemental requests.
These follow up requests to /time/sync use the same XOR algorithm and key and the resulting data includes just the first two fields, specifically:
021///15c50b724a801417ef4143bb58b7178b
For versions that have remote logging capabilities, Gasket sends HTTP POST requests to a URL of /cert/dist that looks like the following:
Figure 6. Example Gasket remote logging requests.
The remote logging request seen above uses the same XOR algorithm and key as in other HTTP requests. The structure of the data differs slightly with the sent information, including the version number, the unique identifier for the system and finally the message sent to the server as seen in the following example remote error log:
002///<base64 username+computername>///[Control]: Failed to Stop Windows Protection System: Unknown action Stop
Capabilities
The response from the C2 server will provide /// delimited data that contains an integer that the payload will treat as a command, along with additional parameters for the commands. Table 3 below provides a list of available commands within a majority of and the most recent (021) Gasket versions.
Command
Description
1
Runs a command/application/powershell with os.exec.Command.Run, returns stdout.
2
Starts a SOCKS5 server using the rsocks project (https://github.com/brimstone/rsocks) to connect to a specified remote system.
3
Same as command 2.
4
Switches the C2 communications from DNS to HTTP or HTTP to DNS, depending on which channel was currently active.
7
Uses the Chisel project to create what it calls a "MagicSocks" client to port forward and tunnel traffic to a provided server using a provided username and 'networkZSA$789ty5' as a password for SSH.
9
Uninstalls the Trojan by deleting the service running the payload, creating %temp%\del.bat to delete itself and calling os.Exit
Table 3. Commands available in Gasket version 021.
Based on the commands in Table 3, it appears that Gasket serves the threat actors not only as a backdoor, but also provides tunneling abilities to allow the actor to use Gasket as a means to tunnel traffic through to an externally controlled server. Gasket references "magicSocks" within its debug logs when creating its tunnel, which appears to be a tunneling method using the 'chisel' project. We have evidence that this threat actor has a standalone version of this tunneling tool, which we call MagicSocks and will discuss in the next section.
Evolution of Gasket
We alluded to several versions of Gasket in previous sections of this blog, but we only referenced 001 and 021 specifically. These two version numbers mark the oldest and newest known version of Gasket, of which we saw first back in April 2020 all the way through March 2021. Table 4 provides a list of Gasket samples, their respective version number and the first timestamp we have associated with the sample.
Table 4. Known Gasket samples and their respective versions.
We extracted the C2 locations used by Gasket samples for both the HTTP-based and DNS-based channels for analysis. The hardcoded domains and IP addresses, seen in Table 5, are not unique to the version of Gasket, as several domains and IPs were used in Gasket samples that had different version numbers.
Table 5. C2 domains and IP addresses and their associated Gasket version.
As previously mentioned, we analyzed many Gasket backdoors and MagicSocks versions used by the threat actors and gathered a significant amount of related infrastructure for blocking and tracking purposes. The Maltego chart in Figure 7 below helps to visualize the Gasket samples listed in Table 5 above, their versions and related infrastructure used for C2 communications. Figure 7 below broadly shows two main clusters. On the left, showing more recent versions (012 to 021) and on the right showing pre-012 versions.
The vast majority of links between entities shown in Figure 7 are related to infrastructure, namely domain names and IP addresses that respective samples connected to during our WildFire sandbox analysis, or could connect to, based on extracted C2 configuration information.
Figure 7. Maltego diagram showing Gasket and MicroSocks infrastructure and links.
The links between some of the distinct clusters (highlighted by squares drawn over Figure 7) are limited and typically involve C2 reuse. However, some additional links were possible using sample meta-data, such as common Windows Service names, as previously listed.
Using the heatmap -- Figure 8 below -- we were able to further visualize the amount of reuse and overlap present for the primary C2 address in all Gasket samples. Generally speaking, the table shows that earlier versions of Gasket reused C2 addresses the most both for multiple variants of the same version and also for different variants using newer Gasket versions. The heatmap shows later versions -- from about 008 onwards -- have a reduction in reuse of primary C2 addresses within and across versions, and in the latest versions, it seems primary C2 addresses are not being reused.
Figure 8. Heatmap showing Gasket sample counts and versions against primary C2s.
The outliers to this pattern are rows 9, 11 and 12 in Figure 8 above. Rows 9 and 11 relate to the top right cluster in Figure 7 while row 12 relates to the bottom right cluster. They are outliers because the Gasket versions are relatively old yet their C2 reuse is nonexistent. Furthermore, the links in Figure 7 from the cluster including C2s listed on rows 9 and 11 to the rest of the Gasket mapping lies only with the fact that they are known Gasket samples, and they share the same Windows Service name as other samples from other clusters. We believe these outliers could be due to specific campaigns involving Gasket malware with bespoke attack infrastructure.
We see the most repetitive use of infrastructure in earlier versions of Gasket together with several changes to the name of the Windows Service created during infection. However, the latest Gasket versions, which appear to adopt more single-use and short-lived infrastructure, (at least for their primary C2s) use a consistent name for the Windows Service, namely JavaJDBC.
Figure 7 also highlights an area of overlap between Gasket and the MagicSocks tool via the common IP address 89.44.9[.]229, which hosted both Gasket (SHA256: aa2faf0f41cc1710caf736f9c966bf82528a97631e94c7a5d23eadcbe0a2b586), the MagicSocks sample (SHA256: d49a69be32744e0af32ad622aa22ba480d68253287c99f5a888feb9f2409e46f) and some PowerShell components related to MagicSocks. The PowerShell script hashes and additional C2 addresses extracted from other MagicSocks samples are listed in the IOCs section later.
MagicSocks
The Gasket tool referenced a proxying and tunneling capability known as MagicSocks, which is based on the open-source Chisel project. The actors also created a standalone version of MagicSocks that they would use in addition to Gasket. The standalone MagicSocks tool comes as a dynamic link library (DLL), which the actor also wrote in Golang. The developer of MagicSocks uses code from the Chisel project to tunnel traffic from the local system to an external actor-controlled Chisel server. The tool will build the string R:0.0.0.0:50000:socks that it supplies to the Chisel client code that will generate the following JSON that the client uses as a configuration:
The tool also builds a string that represents the external actor-controlled Chisel server, which is hosted at:
http://creatordampfe[.]xyz:443
When running the MagicSocks tool, MagicSocks uses the Chisel client to connect to the Chisel server hosted at creatordampfe[.]xyz. This starts with an HTTP request and response that will look like the following:
Figure 9. Example MagicSocks initial request and response.
Figure 9. Example MagicSocks initial request and response.
The purpose of using Chisel is to tunnel traffic out from the local system to creatordampfe[.]xyz, which acts as a proxy to the true location of the outbound traffic. Unfortunately, we do not have access to the Chisel server at creatordampfe[.]xyz to determine the ultimate destination of the traffic, which highlights the hiding functionality that MagicSocks offers the actors.
We discovered five additional MagicSocks standalone samples, all compiled between February 2021 and April 2021. We extracted the location of the remote Chisel server from each of the five samples and found the following three unique C2 locations:
104.168.164[.]195
172.96.189[.]86
142.79.237[.]163
These samples were also obfuscated with Gobfuscate, but earlier compiled samples were compiled in the following location, which suggests they were created on a Linux system by a user, named solar:
/home/solar/c/go/magic-dll/src/sokos/
One of the MagicSocks standalone samples we discovered was delivered with and executed by another tool with a filename of run64.exe (SHA256: f2dcad28330f500354eb37f33783af2bcc22d205e9c3805fed5e919c6853649c). This tool does nothing more than run the MagicSocks DLL (timex.dll), specifically calling the Debug exported function by running the following rundll32 command:
We believe the same individual created this sample as the MagicSocks samples, as the Go project's source was in the following folder that has the same solar username:
/home/solar/c/go/exec-dll/src/
We found another MagicSocks sample (SHA256: d49a69be32744e0af32ad622aa22ba480d68253287c99f5a888feb9f2409e46f) from September 2020, which was not obfuscated with Gobfuscate. This sample was hosted at 89.44.9[.]229/info.txt, which is the same IP that hosted the Gasket sample (SHA256: aa2faf0f41cc1710caf736f9c966bf82528a97631e94c7a5d23eadcbe0a2b586). This version of MagicSocks uses a socks5 library to create a proxy to a remote server, specifically 23.227.206[.]158:443. The 89.44.9[.]229 IP hosted other files of interest that we will discuss further in the related tools section of this blog.
Mespinoza Ransomware
The Gasket and MagicSocks tools were used in an attack that delivered the Mespinoza ransomware (also known as PYSA). Additionally, based on analysis during incident response cases worked by Unit 42 consultants, other tools were discovered as used by the operators to facilitate latter parts of their attacks, as described below.
For general reconnaissance of the network after the RDP breach, "ADRecon" was used to enumerate Active Directory for domains, users, groups, computers and more. Furthermore, built-in Windows utilities such as quser, ping and net were used, together with downloaded tools Advanced IP Scanner and Advanced Port Scanner, to gather more information about logged-on users and network topologies. PowerShell scripts were used to wake up systems turning them on over the network providing the operators with additional targets.
To gather credentials and facilitate lateral movement, ransomware deployment, the operators used PowerShell to recursively search the file system for logon credentials stored in text files and spreadsheets. The PowerShell tool "SessionGopher", capable of extracting session information from remote access tools, such as WinSCP, PuTTY, FileZilla and more, was also used enabling RDP and the Microsoft Sysinternals utility PsExec to allow lateral movement.
The operators also used PowerShell scripts to kill security services and backups, and disable features of Windows Defender by editing local group policies.
The ransomware is fairly straightforward, as it enumerates the file system and encrypts files with an asymmetric cipher, renames the files with a specific extension and displays a ransom message. The ransom message contains three email addresses that victims would contact to discuss payment options for the actors to decrypt the encrypted files. In addition to providing email addresses, the ransom message also includes the group’s leak site that the actors say they will post sensitive files that the actors stole from the network prior to encrypting the files. It appears that the group uses these potentially sensitive files to gain leverage in negotiating payment.
Exfiltration
Prior to deploying Mespinoza, the actors run a PowerShell script that would exfiltrate potentially sensitive files from the compromised network as either a double-extortion attempt or to increase leverage in ransom payment negotiations. According to the ransomware’s ransom message displayed later in this blog, the actors threaten to upload these files to their website or will sell them on the ‘darknet’ if the organization does not pay the ransom. This message suggests that the actors are using the exfiltrated files as leverage to increase the likelihood of the organization paying the ransom.
We visited the group’s leak site and found that the actors leaked archives of files supposedly exfiltrated from the victim networks. Each leak entry on the website includes the name of the organization, a date associated with the leak and a link to either a page hosting the leaked information or a Zip archive of files. At the time of this writing, 187 organizations were named and the dates of these leaks range from April 3, 2020 through April 29, 2021. The website also includes a description of the leaked files for 25 of the organizations, which were apparently written by the actor. In many of the descriptions, the actor refers to the impacted organization as their “partner,” as seen in the following example description:
Our partners provide you with their transaction history, invoices and bank documents for viewing.
During our analysis, the actors collected potentially sensitive files by running a PowerShell script that would enumerate files on the system, ignoring files with specific file extensions and files in specific folders and sending files whose filename contained one of 71 sub-strings. When a file of interest was found, the PowerShell script uses the System.Net.WebClient.UploadFile method to upload the file to a URL with the following structure:
193.34.166[.]92/upload-wekkmferokmsdderiuheoirhuiewiwnijnfrer?token=<base64 token value>&id=<unique number for organization>&fullPath=<path on disk of file exfiltrated>
The PowerShell script identifies files of interest by comparing the filename to the 71 sub-strings seen in Table 6. The sub-strings would suggest the actors are interested in gathering a variety of different types of information, including documents related to finances, account credentials, government, employees and other personal identifiable information (PII). Several of the sub-strings, such as illegal, fraud and criminal, suggest that the actors are also interested in illegal activities known to the organization as well.
secret
checking
illegal
bureau
billing
sec
private
saving
compromate
government
payment
soc
confident
routing
privacy
securit
budget
vendor
important
finance
login
unclassified
criminal
tax
federal
agreement
credent
seed
bank
emplo
government
SWIFT
private
personal
cash
hir
security
compilation
contract
partner
payroll
ssn
fraud
report
concealed
confident
password
tax
secret
confident
clandestine
mail
driver*license
i-9
balance
hidden
investigation
letter
license*driver
w-9
statement
clandestine
federal
passport
scans
w-4
pay
Staf
SSA
Emplo
Confid
Table 6 Substrings used to identify files of interest to exfiltrate
When generating a list of files to exfiltrate, the PowerShell script will disregard files based on their file extension if they match the list in Table 7. One could speculate which file types the threat actors were most interested in, as the list of excluded file extensions does not include common extensions associated with productivity software, such as “.docx,” “.doc” and “.pdf.” We believe the threat actors are most interested in document files as they are more likely to contain the sensitive information the actors seek when compared to file types in the exclusion list. There are also errors in the extension exclusion list, specifically the “. rpt” entry that contains the space character that is not allowed in a file extension.
.png
.evtx
.gif
.man
.pls
.trn
.ascx
.suo
.jss
.jpg
.rb
.log
.template
.checksum
.ipa
.application
.vsix
.jsm
.txt
.htm*
.url
.xsd
.cdf-ms
.procedure
.cls
.wsdl
.ico
.py
.jar
.lnk
.aspx
.cmd
.vb
.deploy
.tt
.function
.pyc
.dat
.cs
.h
. rpt
.cshtml
.DIC
.cch
.hlp
.dll
.ini
.json
.cab
.php
.config
.rll
.chw
.ldf
.exe
.xrm-ms
.bak
.Pid
.svc
.chm
.so
.epub
.map
.js
.xml
.md
.frm
.java
.msp
.table
.form
.mof
.css
.swf
.manifest
.msi
.class
.msm
.tmp
.function
.mp3
.msg
.nupkg
Table 7. File extensions ignored in identifying files of interest.
Lastly, the PowerShell script ignores files stored in the folders and sub-folders that match the sub-strings listed in Table 8. These folders are omitted from consideration as they are related to the Windows operating system, application files, browsers and antivirus products, which would unlikely contain any sensitive files of interest to the actors.
Windows
Package Cache
PerfLogs
Symantec
VMware
Recovery
Chrome
Microsoft
Boot
Mozilla
Sophos
Program Files
ESET
System Volume Information
ProgramData
Table 8. Folders ignored in identifying files of interest.
Deployment
To deploy Mespinoza, the actor used three batch scripts that would use PsExec to copy files to, and to run commands on, other systems on the network. The actors use one system as a distribution point and run the three batch scripts from this system to spread to other systems on the network. The three scripts carry out the following tasks:
Use PsExec to run a PowerShell script located on a shared folder on the distribution server.
Use PsExec to run the copy command to copy the Mespinoza ransomware from the shared folder on the distribution server to C:\Windows\Temp\svchost.exe to other systems on the network.
Use PsExec to run the copied ransomware sample by running cmd /c c:\windows\temp\svchost.exe
The initial PowerShell script is meant to precede the ransomware deployment, specifically to disable antivirus, enable remote desktop and to modify the system to maximize the impact of the ransomware. First, the pre-deployment PowerShell script attempts to specifically disable or remove both MalwareBytes and Windows Defender antivirus software from the system. The script then attempts to stop services that have specific sub-strings in their display name, as seen in Table 9. These service names suggest the actors wish to run their ransomware after database, email and backup services are disabled with the hope that the ransomware would encrypt the files used by these services.
SQL
Exchange
Sharepoint
Oracle
Veeam
Quest
Citrix
Malwarebytes
Backup
Table 9. Processes killed by Mespinoza pre-deployment script.
The script also uses Windows Management Instrumentation command (wmic) to find and kill processes whose process name has sub-strings seen in Table 10. The process names that the script attempts to kill include popular browsers, endpoint protection, productivity, database and server processes.
Agent
Backup
apache
office
manage
Malware
QuickBooks
web
anydesk
acronis
Endpoint
QBDB
vnc
protect
endpoint
Citrix
QBData
teamviewer
secure
autodesk
sql
QBCF
OCS Inventory
segurda
database
SQL
server
monitor
center
adobe
Veeam
citrix
security
agent
java
Core.Service
sage
def
silverlight
logmein
Mongo
http
dev
exchange
microsoft
solarwinds
engine
AlwaysOn
Framework
sprout
firefox
chrome
barracuda
veeam
arcserve
Table 10. Processes killed by Mespinoza pre-deployment script.
The PowerShell script also attempts to delete the system's restore point and volume shadow copies via the following commands:
The script also attempts to further impact the ability to use systems by changing the password of the local user accounts on the system. To carry this out, the PowerShell script obtains a list of local user accounts on the current system by running the following command:
It then iterates through all of the local user accounts and appends the string pysa to the username, generates the MD5 hash of the resulting string and sets the user’s password to the first 13 characters of the MD5 hash by running the following command:
To determine if the pre-deployment script successfully ran on the end system, the actor added a command that will create a file in a shared folder on the distribution system with the name of the system the pre-deployment script ran on. The command would write “I'll be back.” to this file, which suggests that the actor expects to revisit the system to deploy the ransomware. The PowerShell command that performs this functionality appears as follows, of which “[redacted]” replaces the IP address of the distribution system:
Mespinoza ransomware starts by creating a mutex Pysa, of which Pysa is another alias for this ransomware family. It then enumerates the file system and writes the following ransom message to a file named Readme.README in each folder:
Figure 10. Mespinoza ransomware note.
Figure 10. Mespinoza ransomware note.
The ransomware will omit writing the ransom message and will not encrypt files in folders that have the following within their path:
:\Windows\
\Boot\
\BOOTSECT
\pagefile
\System Volume Information\
bootmgr
\Recovery
\Microsoft
The ransomware also writes values to the registry to display the ransom message at system startup. The ransomware edits two registry keys in SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, specifically setting the legalnoticecaption value to PYSA and legalnoticetext to the same ransom message above.
The ransomware will encrypt files using a RSA public key and the AES-CBC cipher, after which it will rename the encrypted file to change its file extension to .pysa. Before encrypting each file, the ransomware checks the file's extension against the following exclusion list:
.README
.docx
.myd
.backupdb
.vfd
.vbm
.pysa
.xlsx
.ndf
.bck
.avhdx
.vrb
.exe
.pdf
.sdf
.bkf
.vmcx
.win
.dll
.db
.trc
.bkup
.vmrs
.pst
.sys
.db3
.wrk
.bup
.pbf
.mdb
.search-ms
.frm
.001
.fbk
.qic
.7z
.sql
.ib
.acr
.mig
.sqb
.zip
.doc
.mdf
.bac
.spf
.tis
.rar
.xls
.mwb
.bak
.vhdx
.vbk
.cad
.dsd
.dwg
.pla
.pln
Table 11. Encryption exclusion list using file extensions.
The ransomware finishes by creating a batch script at %TEMP%\update.bat with the following contents, that it will run to delete the ransomware and batch script from the system:
:Repeat
del "<ransomware filename>.exe"
if exist "<ransomware filename>.exe" goto Repeat
rmdir "<folder containing ransomware>"
del %TEMP%\update.bat
Related Tools
It appears that actors have been using a combination of the pre-deployment PowerShell script prior to deploying Mespinoza ransomware since at least March 2021. We found another pre-deployment script ‘p.ps1’ (SHA256: 7193d6f3c621596e845694c1348e90ea5a9d99d756c9e9fe5063860cd1ee3838) used prior to a Mespinoza/Pysa ransomware (SHA256: 90cf35560032c380ddaaa05d9ed6baacbc7526a94a992a07fd02f92f371a8e92) that used the following email addresses within the ransom message:
luebegg8024@onionmail[.]org
mayakinggw3732@onionmail[.]org
lauriabornhat7722@protonmail[.]com
We found that the IP address 89.44.9[.]229 hosted a Gasket and MagicSocks sample the first week of September 2020. At the same time, this server also hosted two PowerShell scripts that gave us additional insight into the threat actors using these tools. The actors would likely use both of the scripts during their post-exploitation activities, specifically related to credential harvesting and to support lateral movement.
One of the scripts had a filename of keke.ps1, which is a modified version of Invoke-Kerberoast with the comments and all of the lines that print messages to the screen removed (Write-Verbose). The actor renamed the Invoke-Kerberoast function to mommm, which is run and will output its results to a file at the path C:\Users\Public\logs. The actors removed the ability for the script to output the gathered hashes as “John the Ripper” format, which suggests the threat actors removed this code in favor of using the hashcat output format. Therefore, we believe this threat group would exfiltrate the C:\Users\Public\logs file and would use the hashcat tool to try to extract credentials.
The second PowerShell script had a filename of try.ps1, which attempts to split a file at the hardcoded path of C:\Users\Public\lsass.zip into 5MB blocks. The script would write each of these blocks files with .[number].part appended to the filename. This script suggests that this group may dump the Local Security Authority Subsystem Service (LSASS) process’ memory and wishes to exfiltrate smaller files for credential harvesting on a remote system.
Conclusion
In a recent incident, threat actors deployed the Mespinoza (also known as Pysa) ransomware by accessing a system via remote desktop and running a series of batch scripts that use the PsExec tool to copy and execute the ransomware on other systems on the network. Before deploying the ransomware to other systems, the actor runs PowerShell scripts on the other systems on the network to exfiltrate files of interest and to maximize the impact of the ransomware.
Mespinoza attacks, such as those documented in this report, highlight multiple trends currently occurring amongst multiple ransomware threat actors and families that clearly enable their attacks, and make them easy and simple to use in their attacks. As with other ransomware attacks, Mespinoza originates through the proverbial front door -- internet-facing RDP servers -- mitigating the need to craft phishing emails, perform social engineering, leverage software vulnerabilities or other more time-consuming and costly activities. Further costs are saved through the use of numerous open-source tools available online for free, or through the use of built-in tools enabling actors to live off the land, all of which benefits bottom line expenses and profits.
Finding RDP servers on the internet can be easily automated. The 2021 Cortex Xpanse Attack Surface Threat Report found RDP was the most common security issue found among global enterprises, representing 32% of overall security issues.
Palo Alto Networks Next-Generation Firewall customers are protected from Mespinoza, Gasket and MagicSocks via the following protections:
All known Gasket HTTP C2 traffic are detected in Threat Prevention.
All known Mespinoza, Gasket and MagicSocks samples receive malicious verdicts in WildFire.
All known Gasket and MagicSocks C2 domains have malicious verdicts in Advanced URL Filtering and are classified as Command & Control in PAN-DB.
All known domains for Gasket and MagicSocks C2 are detected in DNS Security.
Cortex XDR customers are protected through WildFire verdicts for all known Mespinoza, Gasket and MagicSocks samples and by Local Analysis for Gasket samples.
AutoFocus customers can track the ransomware and associated tools used in this attack via the Mespinoza and Gasket tags.
Cortex Xpanse customers can assess and manage their network security attack surface and generate an inventory of their systems.
On July 1, 2021, Microsoft released a security advisory for a new remote code execution (RCE) vulnerability in Windows, CVE-2021-34527, referred to publicly as "PrintNightmare.” Security researchers initially believed this vulnerability to be tied to CVE-2021-1675 (Windows Print Spooler Remote Code Execution Vulnerability), which was first disclosed in the Microsoft Patch Tuesday release on June 8, 2021. Microsoft has since updated the FAQ section of the advisory that shows CVE-2021-34527 is similar but distinct from CVE-2021-1675, which addresses a different but related vulnerability in RpcAddPrinterDriverEx().
Systems Vulnerable to CVE-2021-34527
All Windows versions are affected by this vulnerability. Domain controllers, clients and member servers running the Print Spooler service on any Windows version are affected by this vulnerability. Microsoft has released an out-of-band update with the fixes for versions other than Windows 10 version 1607, Windows Server 2016 or Windows Server 2012. For these, the security update is expected to be released soon.
Mitigation Actions
Microsoft released an out-of-band security update to address this vulnerability on July 6, 2021. Please see the Security Updates table for the applicable update for your system. Administrators are strongly advised to install these updates. If you are unable to install these updates, see the FAQ and Workarounds sections in the CVE for information on how to help protect your system from this vulnerability. See also KB5005010: Restricting installation of new printer drivers after applying the July 6, 2021 updates.
Note that the security updates released on and after July 6, 2021, contain protections for CVE-2021-1675 and the additional RCE exploit in the Windows Print Spooler service known as “PrintNightmare,” documented in CVE-2021-34527.
Conclusion
Palo Alto Networks provides protection against the exploitation of this vulnerability:
Next-Generation Firewalls with a Threat Prevention security subscription (running Applications and Threat content update version 8427+) can automatically block sessions related to this vulnerability (as well as CVE-2021-1675) using Threat IDs 91333, 91346 and 91349.
Cortex XDR agent 7.4.1 with content version 189-64538 and above is capable of preventing all currently known implementations of the exploits on vulnerable hosts, including patched hosts with the “Point and Print” feature enabled.
Palo Alto Networks will update this Threat Brief with new information and recommendations as they become available.
On July 2, attackers reportedly launched attacks against users of the Kaseya VSA remote monitoring and management software as well as customers of multiple managed service providers (MSPs) that use the software. They used access to the VSA software to deploy ransomware associated with the REvil/Sodinokibi ransomware-as-a-service group, according to reports. Kaseya has stated that the attack was conducted by exploiting a vulnerability in its software, and said they are working on a patch. The company has not released further information on the vulnerability. Kaseya recommends that any organization using VSA shut the system down immediately. CISA has also issued a bulletin asking organizations using the software to follow Kaseya guidance.
The full extent of the attack is currently unknown. Kaseya states that fewer than 40 of its customers are impacted. If those customers include MSPs, many more organizations could have been attacked with the ransomware. Kaseya VSA’s functionality allows administrators to remotely manage systems. If an MSP’s VSA system was compromised, that could allow an attacker to deploy malware into multiple networks managed by that MSP.
There has been much speculation about the nature of this attack on social media and other forums. We have not been able to independently determine how these attacks were conducted.
Multiple sources have stated that the following three files were used to install and execute the ransomware attack on Windows systems:
POST /dl.asp curl/7.69.1 GET /done.asp curl/7.69.1 POST /cgi-bin/KUpload.dll curl/7.69.1 GET /done.asp curl/7.69.1 POST /cgi-bin/KUpload.dll curl/7.69.1 POST /userFilterTableRpt.asp curl/7.69.1
Unit 42 researchers observed network attack trends, February-April 2021. In the following sections, we present our analysis of the most recently published vulnerabilities, including the severity and category. Additionally, we provide insight into how the vulnerabilities are actively exploited in the wild based on real-world data collected from Palo Alto Networks Next-Generation Firewalls. We then draw conclusions about the most commonly exploited vulnerabilities the attackers are using, as well as the severity, category and origin of each attack.
Network Attack Trends February-April 2021: Analysis of the Latest Published Vulnerabilities
From February-April 2021, a total of 4,969 new Common Vulnerabilities and Exposures (CVE) numbers were registered. To better understand the potential impact they could have on network security, we collected as many details as possible for each CVE. In the following sections, we provide our observations based on the severity, affected products and vulnerability categories.
How Severe Are the Latest Vulnerabilities?
To estimate the potential impact of vulnerabilities, we consider their severity and examine any reliable proofs-of-concept (POCs) that are available. Some of the public sources we use to find POCs include Exploit-DB, GitHub, and Metasploit. Distribution for the 3,849 CVEs that have an assigned severity score of medium or higher can be seen in the following table:
Severity
Count
Ratio
POC Availability
Critical
598
15.5%
9.4%
High
1659
43.1%
8.1%
Medium
1592
41.4%
7.0%
Table 1. Severity distribution for CVEs registered in February-April 2021.
Figure 1. Severity distribution for CVEs registered in February-April 2021.
Vulnerabilities classified as critical are the least common, but they are also more likely to have POCs available. The data suggests that there is a correlation between the availability of a POC and the severity of a vulnerability. This could be influenced by the amount of attention a vulnerability receives when it is more severe, as it is more interesting to both security researchers and attackers. Palo Alto Networks continues to leverage the aforementioned threat intelligence information to provide protections for our customers.
Vulnerability Category Distribution
The type of vulnerability is also crucial to understanding its consequences. Out of the 4,327 newly published CVEs that were analyzed, only 27.3% are classified as local vulnerabilities, requiring prior access to a compromised system, while the remaining 72.7% are remote vulnerabilities, which can be exploited over a network. The most common types are shown below:
Ranking
Vulnerability Type
1
Cross-Site Scripting
2
Denial-of-Service
3
Information Disclosure
4
Buffer Overflow
5
Privilege Escalation
6
Code Execution
7
Command Injection
8
SQL Injection
9
Out-of-Bounds Read
10
Memory Corruption
Table 2. Vulnerability category ranking for CVEs registered in February-April 2021.
Figure 2. Vulnerability category distribution for CVEs registered in February-April 2021.
As web applications are one of the most popular types of software, it's understandable that cross-site scripting is the top-ranking type of vulnerability. Denial-of-service vulnerabilities are also abundant, possibly due to how difficult it can be to prevent them. However, they are usually less severe and not as valuable to attackers.
Network Attack Trends February-April 2021: Analysis of the Latest Exploits in the Wild
Data Collection
By leveraging Palo Alto Networks Next-Generation Firewalls as sensors on the perimeter, Unit 42 researchers have been able to isolate malicious activities from benign traffic from February-April 2021. We have analyzed more than 10 million sessions in total for this quarter. The malicious traffic is then further processed based on metrics such as IP addresses, port numbers and timestamps. This ensures the uniqueness of each attack session and thus eliminates potential data skews. The researchers then correlate the refined data with other attributes to infer attack trends over time and get a picture of the threat landscape.
How Severe Were the Attacks Exploited in the Wild?
Out of 10.6 million verified attack sessions observed, network traffic triggers and signatures categorized as informational and low severity are used to detect scanning and brute-forcing attempts. Therefore, we consider exploitable vulnerabilities with a severity ranking of medium and above (based on the CVSS v3 Score) as a verified attack.
Figure 3. Attack severity distribution in February-April 2021.
Table 3 shows the session count and ratio of attacks grouped by the severity of each vulnerability.
Severity
Session Count
Ratio
Critical
2,602,996
21.1%
High
6,611,114
62.3%
Medium
1,772,091
16.7%
Table 3. Attack severity distribution ratio in February-April 2021.
Exploitation of vulnerabilities with high severity significantly increased to 62.3% of observed sessions compared to last quarter, when this category made up only 10.7%. This may indicate that attackers were less successful in acquiring or weaponizing critical vulnerabilities during this time frame, causing them to settle for less severe vulnerabilities.
When Did the Network Attacks Occur?
Figure 4. Attack severity distribution measured bi-weekly from February-April 2021.
For this installment of our network attack trends analysis, we collected data from February to April 2021, and we discovered that the majority of attacks were ranked with high severity. Attackers also made frequent use of newer vulnerabilities disclosed within the past year, as well as vulnerabilities exploited in the wild from 2017-19. This highlights the importance of updating security products and applying software patches as soon as they become available to provide protection against the most recently discovered vulnerabilities.
Figure 5. Observed attacks, broken down by the year in which the exploited CVE was disclosed, measured bi-weekly from February-April 2021.
Latest Attacks: Exploits in the Wild
Out of all the attacks observed during this time period, the following exploits stood out due to their ease of exploitation, POC availability and severity. We have provided snippets that show how attackers used open source tools to compromise the different targets. We provide snippets of these exploits captured in our monitoring system below.
There is an improper sanitization in multiple Nagios XI PHP files, such as windowswmi.inc.php, switch.inc.php, and cloud-vm.inc.php. An attacker can submit a crafted request that the software does not properly sanitize. We have published a blog that demonstrates how this specific attack can be used for cryptojacking. Figure 6 reveals the exploit.
Figure 6. Nagios XI remote command injection vulnerability.
A server-side request forgery (SSRF) vulnerability is present in VMware vRealize Operations Manager's API. An attacker can potentially steal administrative credentials or can send crafted requests to be processed with admin privileges. Figure 7 describes this particular attack.
Npm’s package system information is vulnerable to a command injection vulnerability. In this vulnerability, an attacker can send a malicious payload that will exploit the name parameter. After successful exploitation, attackers can execute remote commands. A sample exploit is shown in Figure 8.
The vulnerable parameters X-F5-Auth-Token and loginReference link of BIG-IP's iControl REST do not properly sanitize the user-supplied data, which an attacker can exploit to gain remote code execution (RCE). Figure 9 is an example of this exploit.
The Traffic Management Microkernel of BIG-IP ASM Risk Engine has a buffer overflow vulnerability, in which it does not properly handle incoming requests, leading to a bypassing of URL-based access controls. Figure 10 shows an unsuccessful exploitation attempt in the wild.
An RCE vulnerability in Microsoft Exchange Server’s X-BEResource HTTP is present in ProxyRequestHandler class. An attacker can exploit this vulnerability by sending a crafted request to a vulnerable Exchange Server. Figure 11 reveals the exploit.
Figure 11. Microsoft Exchange Server remote code execution vulnerability.
In this information disclosure vulnerability, the administrator password can be disclosed by an unauthenticated user by visiting a unique URL. This vulnerability was first published in September 2020, and we started seeing triggers in our system in May 2021. A sample captured in our system is shown in Figure 12.
Figure 12. DCS-2530L unauthenticated information disclosure vulnerability.
Inspur ClusterEngine 4.0 has an RCE vulnerability that allows an attacker to send a malicious login packet to the control server. We started seeing hits for this vulnerability in our system in April 2021. The vulnerability was originally published in February 2021. A live attack capture is displayed in Figure 13.
A cross-site request forgery (CSRF) vulnerability in MAGMI was discovered in September 2020. Due to the lack of proper checks on CSRF tokens, an attacker can perform a CSRF attack. We have observed it in our system in June 2021. Figure 14 shows an example.
In December 2020, an RCE vulnerability was discovered in D-Link DSL-2888A devices, allowing an authenticated user to execute operating system (OS) commands by exploiting one of the CGI. Our system captured the attacks in April 2021. Figure 15 has more relevant details.
In late January 2021, a buffer overflow vulnerability was disclosed in D-Link DIR-825 R1 devices. This vulnerability can be leveraged to achieve pre-authentication RCE. It started appearing in our systems in mid-March 2021. A sample exploit is shown in Figure 16 for reference.
The Micro Focus Operation Bridge Reporter (OBR) product has an RCE vulnerability, which an attacker can exploit by sending a crafted request to the OBR server. This was first disclosed in February 2021, but we have seen triggers in our system lately. Figure 17 shows the exploit in the wild.
There exists an RCE vulnerability in NETGEAR’s JGS516PE devices, which an attacker can easily exploit by sending a malicious request. This was first disclosed in October 2020, and we have seen attacks daily since March 2021. Due to the ease of exploitation and abundant availability of NETGEAR devices on the internet, this vulnerability seems to be favored by attackers. More details in Figure 18 below.
Another RCE vulnerability was captured by our systems starting in March 2021. This one is related to 74CMS, in which an attacker can achieve the RCE by exploiting the assign_resume_tpl method. This vulnerability was disclosed in December 2020. Figure 19 shows a live attack captured in our system.
Genexis Platinum 4410 has an RCE vulnerability that allows an attacker to pass shell metacharacters and achieve arbitrary command execution. The CVE was first made public in April 2021, and we observed it in our system around the same time. Figure 20 describes this particular attack.
Oracle WebLogic Server reported an RCE vulnerability in October 2020 that allows an attacker to easily exploit a vulnerable method called getHandle and take over the server. A new POC has been released recently. We started seeing this new method of attack in our system in May 2021. Figure 21 contains the exploit in the wild.
Figure 21. Oracle WebLogic server remote code execution vulnerability.
Figure 22 shows the session-based attack category distribution. To learn more details about impact and prevalence, we classified each network traffic trigger by attack category. Code execution accounts for 45.6% of attacks, which is unsurprising, considering that attackers typically want to gain as much control as possible over the systems they target. When fully compromising a target isn't an option, attackers demonstrated interest in obtaining sensitive data through directory traversal and information disclosure attacks. While SQL injection and cross-site scripting are two of the most common types of web application vulnerabilities, they were the least commonly abused among our observations.
Where Did the Attacks Originate?
After identifying the region from which each network attack originated, we discovered that the largest number of them seem to originate from the United States, followed by Russia and China. However, we recognize that the attackers might leverage proxy servers and VPNs located in those countries to hide their true physical locations.
Figure 23. Locations ranked in terms of how frequently they were the origin of observed attacks from February-April 2021.Figure 24. Attack geolocation distribution from February-April 2021.
Conclusion
Our data show that attackers prioritize exploits that are both severe and reliable, showing a preference for high-impact, low-effort attacks. The vulnerabilities published in February-April 2021 indicate that web applications remain popular and that critical vulnerabilities are more likely to have POCs publicly available. This emphasizes the need for organizations to promptly patch their systems and implement security best practices – attackers will make a concerted effort to expand their arsenal of exploits whenever possible.
While cybercriminals will never cease their malicious activities, Palo Alto Networks customers are fully protected from the attacks discussed here by Next-Generation Firewalls. Additional mitigations include:
Run a Best Practice Assessment to identify where your configuration could be altered to improve your security posture.
Continuously update your Next-Generation Firewalls with the latest Palo Alto Networks Threat Prevention content (e.g versions 8416 and above).
Conti ransomware stands out as one of the most ruthless of the dozens of ransomware gangs that we follow. The group has spent more than a year attacking organizations where IT outages can have life-threatening consequences: hospitals, 911 dispatch carriers, emergency medical services and law enforcement agencies. Ireland has yet to recover from an attack in mid-May that prompted the shutdown of the entire information technology network of the nation's healthcare system – prompting cancellation of appointments, the shutdown of X-ray systems and delays in COVID testing.
Conti also stands out as unreliable. We've seen the group stiff victims who pay ransoms, expecting to be able to recover their data.
The FBI has connected Conti to more than 400 cyberattacks against organizations worldwide, three-quarters of which are based in the U.S., with demands as high as $25 million. This makes Conti one of the greediest groups out there.
If you think you may have been impacted, please email unit42-investigations@paloaltonetworks.com or call (866) 4-UNIT42 to get in touch with the Unit 42 Incident Response team.
Conti Ransomware Overview
We’ve followed Conti for more than a year through our work helping organizations respond to ransomware attacks. It appears to be one of many private cybercrime groups that have set up their operations by leveraging the booming ransomware-as-a-service (RaaS) ecosystem. Such gangs obtain their foothold in the networks of their victims by purchasing access from other threat actors, who sell it as a commodity. They can also procure infrastructure, malware, communications tools and money laundering from other RaaS providers. Most of these actors use the same methods of access found in many ransomware attacks, such as phishing emails and exploiting unprotected internet-facing applications, the lack of multi-factor authentication (MFA), as well as the typical avenues used to preserve and enhance access once it’s achieved, such as through the use of Cobalt Strike or PowerShell.
These approaches are not particularly clever or sophisticated, but often they are effective. Conti’s methodology often follows the “double extortion” approach that many leading ransomware groups are presently using. When using double extortion, attackers will not only lock up a victim’s files and demand ransom, but they will also steal files and threaten to publish them on a website or otherwise leak them if their initial ransom demand is not met.
But Conti’s methods do have atypical elements.
Usually, the more successful ransomware operators put a lot of effort into establishing and maintaining some semblance of “integrity” as a way of facilitating ransom payments from victims. They want to establish stellar reputations for “customer service” and for delivering on what they promise – that if you pay a ransom, your files will be decrypted (and they will not appear on a leak website). Yet in our experience helping clients remediate attacks, Conti has not demonstrated any signs that it cares about its reputation with would-be victims.
In one recent case, Conti did not return a client’s files who had paid the ransom. This client got only a small fraction of the file restorations that were promised before the Conti ransomware representatives disappeared back into the dark web. In another case, our client needed an inventory of all files accessed, so that they could notify parties whose data was affected. Conti agreed to share that information if a payment was made, then changed their minds, saying, “We do not own that data anymore. It was deleted and there is no chance to restore it.” Like many ransomware gangs, Conti is constantly adapting to changes, including recent heightened scrutiny by law enforcement and policy makers following high-profile disruptive attacks on the Colonial pipeline and healthcare organizations. When Ireland's healthcare system refused to pay any ransom, Conti provided the agency with what it said was a free decryption key. But there was a twist: The group maintained that it would still make good on its "double extortion" threat to publish stolen data on its leak site.
Conclusion
Unfortunately, keeping Conti out of your network often isn’t simple. A primary means of infection appears to be through phishing scams, and attackers are constantly upping their game in this area. While phishing emails used to be pretty easy for almost anyone to spot, particularly after some awareness training, we are seeing increasingly sophisticated attacks in which the threat actors have done plenty of homework on their intended victims. Sometimes they’ll send a blitz of scam emails to employees throughout an organization, and it takes only one to open the attachment and release the malware into the network.
Ransomware attacks are getting easier to unleash, and the rewards to the attackers are still growing by leaps and bounds. Accordingly, it continues to be a growth industry that will attract multitudes of new practitioners, and it is likely that high-profile targets will continue to fall.
Palo Alto Networks detects and prevents Conti ransomware in the following ways:
WildFire: All known samples are identified as malware.
AutoFocus: Tracking related activity using the Conti tag.
Unit 42 Security Consulting: The Ransomware Readiness Assessment detects any hidden threats, tests for preparedness and provides remediation recommendations.
Additionally, Indicators of Compromise (IoCs) associated with Conti are available on GitHub, and have been published to the Unit 42 TAXII feed.
Courses of Action
Product / Service
Course of Action
Initial Access
The below courses of action mitigate the following techniques:
Ensure a secure Vulnerability Protection Profile is applied to all security rules allowing traffic
Ensure a Vulnerability Protection Profile is set to block attacks against critical and high vulnerabilities, and set to default on medium, low and informational vulnerabilities
Ensure that antivirus profiles are set to block on all decoders except 'imap' and 'pop3'
Ensure a secure antivirus profile is applied to all relevant security policies
Wildfire†
Ensure forwarding is enabled for all applications and file types in WildFire file blocking profiles
Ensure that WildFire file size upload limits are maximized
Ensure a WildFire Analysis profile is enabled for all security policies
Ensure forwarding of decrypted content to WildFire is enabled
Ensure all WildFire session information settings are enabled
Ensure alerts are enabled for malicious files detected by WildFire
Ensure 'WildFire Update Schedule' is set to download and install updates every minute
Unit 42 researchers often spend time investigating what we call non-traditional sources. Non-traditional sources often include underground marketplaces and sites, spanning from forums on the Tor network to Telegram channels and other marketplaces. One such case that we investigated involves a threat actor called BelialDemon, who is a member of several underground forums and marketplaces.
In February 2021, BelialDemon advertised a new malware-as-a-service (MaaS) called Matanbuchus Loader and charged an initial rental price of $2,500. Malware loaders are malicious software that typically drop or pull down second-stage malware from command and control (C2) infrastructures. Matanbuchus has the following capabilities:
The ability to launch a .exe or .dll file in memory.
The ability to leverage schtasks.exe to add or modify task schedules.
The ability to launch custom PowerShell commands.
The ability to leverage a standalone executable to load the DLL if the attacker otherwise has no way of doing so.
We discovered several organizations impacted by Matanbuchus including a large university and high school in the United States, as well as a high-tech organization in Belgium.
After observing the user BelialDemon operating in well-established underground forums, we’ve noticed they stick to a particular biblical theme: their name, Belial, along with the name of their new loader, Matanbuchus, stem from the Ascension of Isaiah 2:4: "And Manasseh turned aside his heart to serve Belial; for the angel of lawlessness, who is the ruler of this world, is Belial, whose name is Matanbuchus.” A fitting theme for their operations.
This blog sheds light on Matanbuchus, BelialDemon and the malware’s infrastructure.
BelialDemon Overview
If we look historically, BelialDemon has been involved in the development of malware loaders. BelialDemon is considered the primary developer of TriumphLoader, a loader previously posted about on several forums, and has experience with selling this type of malware.
Figure 1. Forum posting of BelialDemon showcasing a loader.
Looking over posts such as these in Figure 1, we’ll attempt to locate the files through a litany of means to better understand the functionality of the malware and analyze its activity in the wild – allowing for better protections and enriched intelligence. BelialDemon was specifically looking to recruit three people as part of their MaaS offering, charging an initial rental price of $2,500.
Figure 2. Forum posting for Matanbuchus sale.
Since we have a name for the malware direct from the source, we subsequently went hunting for samples of Matanbuchus used in the wild. Hunting for a sample of Matanbuchus unearthed a file in the wild called ddg.dll, which is actively being dropped via hxxp://idea-secure-login[.]com. Looking at some of the included strings showed we were on the right track.
Figure 3. Strings showing MatanbuchusDroper.dll.
As stated by the malware author, the loader has the following features:
The ability to launch a .exe or .dll file in memory.
The ability to leverage schtasks.exe to add or modify task schedules.
The ability to launch custom PowerShell commands.
The ability to leverage a standalone executable to load the DLL if the attacker otherwise has no way of doing so.
The question then becomes what does it actually look like in the wild?
The Excel Dropper
After identifying the Microsoft Excel document (SHA256: 41727fc99b9d99abd7183f6eec9052f86de076c04056e224ac366762c361afda) as an initial vector of an attack that drops the Matanbuchus Loader DLL, we begin our analysis on this file. When opening the Excel document, you're met with the notification that you need to enable macros to view the actual content of the document.
Figure 4. Picture of fake Excel warning.
This file is using a technique more recently favored in attacks leveraging Microsoft Office documents. Specifically, there has been a shift from Microsoft Word to Microsoft Excel when trying to launch malicious payloads on victims’ systems. This shift is because, using Excel's built-in functions, it is possible to store code distributed throughout the spreadsheet cells, offering a native obfuscation that hampers analysis and detection. This is colloquially referred to as Excel 4.0 Macros.
Figure 5. Hidden worksheet functions.
The cells with data will spread across a sea of blank ones which, when executed, will piece together the information. In the example above, note how some of the visible cells in the B column refer to columns and rows across the sheet.
Figure 6. Example of an Excel function.
This GOTO function tells Excel to select a specific cell hundreds of columns over and 1,595 rows down. These types of actions are chained together, and in this document, perform a simple download and execution of said file.
By removing the blank cells in the document and reviewing the resulting strings, there are many interesting standouts that align with the observed behavior of this file in our WildFire malware analysis engine.
Figure 7. Excel V4 extracted macro strings.
Taking these at face value, we can see a breakdown in functionality for downloading a file to a certain location and the execution of it. In this case, ddg.dll will be downloaded from idea-secure-login[.]com and saved locally as hcRlCTg.dll. Then the export within the DLL called RunDLL32_Install_COM32 is executed.
As previously stated, this lines up with expected behavior that was observed in WildFire.
Figure 8. WildFire logged activity.
The DLL, in this case, is the Matanbuchus Loader DLL file.
Matanbuchus Overview
In this next section, we'll briefly cover the Matanbuchus malware before we take a look at the infrastructure used.
Overall, Matanbuchus uses two DLLs during the malware’s run cycle. Both DLLs are packed, but it should be noted that the first DLL has an internal name of MatanbuchusDroper.dll while the second DLL is named Matanbuchus.dll. It’s not the stealthiest approach, but helpful to us nonetheless. Additionally, both DLLs are based at 0x10000000 and use hard coded addresses throughout execution.
Once Excel downloads the initial DLL, MatanbuchusDroper.dll (SHA256: 7fbaf7420943d4aa327bb82a357cd31ca92c7c83277f73a195d45bd18365cfce), from the idea-secure-login[.]com site, the Excel macro will launch and call the export within the DLL labeled RunDLL32_Install_COM32.
The primary function of this first DLL is, as its name suggests, to drop the main Matanbuchus DLL. However, before that, it will make a number of API calls typically observed in anti-virtualization and anti-debugging checks, such as GetCursorPos, IsProcessorFeaturePresent, cpuid, GetSystemTimeAsFileTime, and QueryPerformanceCounter. These can profile a system to provide indicators to the malware that allow it to determine if it is running in a controlled environment (i.e. a sandbox).
Figure 9. API Call for IsProcessorFeaturePresent.Figure 10. API Call for cpuid.
Eventually, the DLL will move to the next phase and unpack the URL to download the primary Matanbuchus DLL, disguised as an XML file called AveBelial.xml. This downloaded file is then saved to Users\ADMINI~1\AppData\Local\Temp\Run_32DLL_COM32\shell96.dll. The use of shell96 is an attempt to blend in with the native system files, suggesting shell32 -> shell64 -> shell96 as a logical progression in naming if it were real.
Figure 11. Matanbuchus DLL download.Figure 11. Writing shell96.dll to disk.
Persistence is established by creating a scheduled task to run the new DLL, along with the specific export to call.
Figure 12. Scheduled task for persistence.
Note the attempt to blend the export name of the DLL with words typically found in popular DLLs: RunDLL32_Install_COM32 and Run_32DLL_COM32. This continues the trend noted above regarding shell96.
The sample, Matanbuchus.dll (SHA256: af356a39a298f6a48f8091afc2f2fc0639338b11813f4f4bd05aba4e65d2bbe3), is similar to the first DLL and uses multiple types of obfuscation and encoding to hide strings and executable code from static analysis. Unlike the first one, additional steps were taken after unpacking the code to further hide the DLLs it leverages functions from. In Figure 14, you can see that the sample is building a string, Shell32.dll.
Figure 13. Building “Shell32.dll” string.
If you look at the DLLs it decodes strings for, there are no big surprises: IPHLPAPI.DLL, ws2_32.dll, wininet.dll and shlwapi.dll. These are common sights when doing malware analysis as they are frequently a precursor to actions such as writing files or network-based communication.
Finally, this DLL collects various pieces of information about the system, such as hostnames, OS details, network adapters and so on, before transitioning into a more familiar routine exhibited by remote access trojans (RAT). The malware begins to communicate with the same host the DLL was downloaded from – eonsabode[.]at. It then sends an HTTP POST to kntwtopnbt/8r5kudwrc8/gate[.]php with no referrer, and a user-agent field containing data instead of an actual user-agent, making it quite visible and easily detectable.
Figure 14. Network Traffic HTTP POST.
The requests are Base64 encoded JSON arrays of more encoded data, most likely containing the profiling information of the host.
Figure 15. Base64 decoded C2 traffic.
Infrastructure Overview
Shifting focus to the domain where the final Matanbuchus DLL came from (eonsabode[.]at), we can see that it resolves to an IP address in a Google network and has had a number of IP addresses it resolved to since early February 2021. This aligns with the time we observed BelialDemon advertising their new malware. Additionally, the initial domain (idea-secure-login[.]com) that the Excel v4 macro reaches out to for the first Matanbuchus DLL is also hosted on these same IP addresses.
Figure 17. DNS resolutions for eonsabode[.]at.When looking at each of the individual IP addresses and their previous resolutions, a number of patterns begin to emerge in the domains that exist on each one, further grouping the malicious activity together.
For example, consider the following three most recent IP addresses and a subset of their resolutions:
34.94.151[.]129
34.106.243[.]174
34.105.89[.]82
The immediately observable patterns here include the usage of domains registered with the Austria ccTLD "at," the usage of "24" within the domain names, and the use of the words "login,” "online," "sso" and "secure.” These are in line with BelialDemon's previous attempts to hide in plain sight by using “good” words.
Given this, we pulled all of the passive DNS resolutions for each IP the original malicious domains resolved to since February 2021. Focusing specifically on domains with multiple connections, we're left with a graph that neatly clusters potentially related domains.
Figure 18. Connection map of IP and Domains.
Within this subset of domains, there are numerous clusters based on various aspects of the domain names, and we've individually clustered them below.
Pattern: Theme of biznesplanet
Pattern: Usage of "24"
Pattern: Usage of Austria ccTLD
Pattern: Fake Adobe Flash updates
Pattern: Usage of “Idea”
Pattern: Theme of “Wallet,” possibly crypto-related
The domains and themes primarily appear focused on phishing, and while not all of these domains are related to the Matanbuchus malware, it appears they are all malicious and likely operated by the same entities. For example, the "Fake Flash Updates" were associated with malicious APK files, as noted by the Malware Hunter Team on Twitter, adding further weight to this theory. Some of these domains may be staged for future campaigns and may not have been utilized yet.
Conclusion
This blog highlights how threat intelligence can be generated from hunting for threats observed in the wild and how small pieces of seemingly disparate data can chain together to strengthen analysis, extract indicators and improve defenses for your organization before being impacted.
Palo Alto Networks customers are protected from this threat by:
WildFire: All known samples are identified as malware.
Cortex XDR with:
Indicators for Matanbuchus.
Next-Generation Firewalls: DNS Signatures detect the known command and control (C2) domains, which are also categorized as malware in Advanced URL Filtering.
AutoFocus: Tracking related activity using the Matanbuchus tag.
Unit 42 has spent the past four months following the activities of Prometheus, a new player in the ransomware world that uses similar malware and tactics to ransomware veteran Thanos.
Prometheus leverages double-extortion tactics and hosts a leak site, where it names new victims and posts stolen data available for purchase. It claims to have breached 30 organizations in government, financial services, manufacturing, logistics, consulting, agriculture, healthcare services, insurance agencies, energy and law firms in the United States, United Kingdom and a dozen more countries in Asia, Europe, the Middle East and South America.
Like many ransomware gangs, Prometheus runs like a professional enterprise. It refers to its victims as “customers,” communicates with them using a customer service ticketing system that warns them when payment deadlines are approaching and even uses a clock to count down the hours, minutes and seconds to a payment deadline.
“We are closing the ticket and have started an auction on your data,” the group threatens when victims fail to pay up. But there’s an out: Victims can click to open a new “ticket” if they’re willing to pay up to stop the auction and recover their data.
Only four victims have paid to date, according to the group’s leak site. It claims that a Peruvian agricultural company, a Brazilian healthcare services provider and transportation and logistics organizations in Austria and Singapore paid ransoms. However, we’re unable to confirm the ransom amounts.
One interesting note is that Prometheus claims to be part of the notorious ransomware gang REvil. Unit 42 has seen no indication that these two ransomware gangs are related in any way. The claim may be an attempt to exploit REvil’s name to persuade victims to pay up, or it could be a false flag to take attention away from Thanos.
We’ve compiled this report to shed light into the threat posed by the emergence of new ransomware gangs like Prometheus, which are able to quickly scale up new operations by embracing the ransomware-as-a-service (RaaS) model, in which they procure ransomware code, infrastructure and access to compromised networks from outside providers. The RaaS model has lowered the barrier to entry for ransomware gangs.
Full visualization of the Prometheus techniques observed and the courses of action relevant for response can be viewed in the Unit 42 ATOM Viewer.
If you think you may have been impacted, please email unit42-investigations@paloaltonetworks.com or call (855) 875-4631 to get in touch with the Unit 42 Incident Response team.
Prometheus Ransomware Overview
Prometheus ransomware was first observed in February 2021 and is a new variant of a known strain called Thanos. Thanos ransomware has been advertised for sale on underground forums since at least the first half of 2020, where it has a builder that allows actors to customize a sample with a wide variety of available settings. This suggests that different threat actors may have leveraged this builder to create their own variants and brands.
In this case, we turn our attention to one of those threat actors, Prometheus. While this ransomware gang claims to be part of REvil, we haven’t seen any other solid connection between the two groups. REvil operates on an affiliate-driven RaaS program, but we believe the Prometheus ransomware gang may be acting on their own and attempting to leverage the infamous REvil name and reputation to improve the chance that victims will pay the demanded ransom. This would not be the first time adversaries have used the names of well-known threat groups to strengthen their credibility.
At the time of writing, we don’t have information on how Prometheus ransomware is being delivered, but threat actors are known for buying access to certain networks, brute-forcing credentials or spear phishing for initial access.
When Prometheus ransomware is executed, it tries to kill several backups and security software-related processes, such as Raccine, a ransomware prevention tool that tries to stop ransomware from deleting shadow copies in Windows. Here is a sample of its approach:
Prometheus ransomware appends an extension using the following format .[XXX-XXX-XXXX] (Figure 1). We found that the extensions are hardcoded into the sample. We believe that the Prometheus ransomware operators generate a unique payload per victim, which is used for their negotiation site to recover files. We obfuscated the extensions because they could be used to identify the victims on the leak site. Prometheus also adds an hexadecimal string of GotAllDone at the end of all encrypted files.
Figure 1. Encrypted files after execution.
After the backup and security processes are terminated and encryption is complete, Prometheus ransomware drops two ransom notes: a RESTORE_FILES_INFO.TXT file and a RESTORE_FILES_INFO.TXT.hta file (Figure 2), both containing the same information.
Figure 2. RESTORE_FILES_INFO.hta.
The ransom note also includes instructions for contacting Prometheus ransomware operators to recover files, as well as informing the victim that, if the demands are not met, the threat actors will release the data to the public or sell it to a third party.
Since the extensions are used as a victim identifier, by following the instructions on the ransom note, we were able to take a look at the negotiation part of their site using the extensions ID to gain access. Interestingly, this group uses a ticketing system for tracking victims. The tickets include a tracking ID, created date, resolution status and priority. A victim can even open a ticket with the threat actors to request data recovery – though this will cost you extra, according to the site (Figure 3).
Figure 3. Prometheus reply to a victim ticket.
The Prometheus ransomware gang tailors their ransom demand depending on the victim organization. From the available instances observed, we have seen payments requested as low as $6,000 and as high as $100,000 in Monero (XMR). This price is doubled if the victims don’t contact the threat actors within the established timeframe, which on average is a week. At the time of writing, four victims paid the ransom including a Peru-based agricultural company, a healthcare services provider in Brazil, and two transportation and logistics organizations – one located in Austria and the other in Singapore.
Figure 4. Prometheus victim ticket.
Like many current ransomware gangs, this group also created a leak site (a different section of the same website that hosts the “ticketing system”) where they name and shame their victims (Figure 5).
Figure 5. Prometheus leak site.
The Prometheus ransomware operators include a status per victim. We found that some of the information posted on the leak site has already been sold to an unknown third party. There are also posts showing that victims within impacted industries paid the ransom and their data was removed from the site (Figure 6).
Figure 6. Leak site victim status for Prometheus ransomware out of 30 victims.
Prometheus Victimology
At the time of this writing, the Prometheus leak site hosts 30 victims, impacting multiple industries globally. By taking a look at their victims listed, we generated this graph, showing the locations of organizations impacted by this ransomware.
Figure 7. Countries impacted by Prometheus ransomware out of 30 victims.
Manufacturing was the most impacted industry among the victim organizations we observed, closely followed by the transportation and logistics industry.
Figure 8. Industries impacted by Prometheus ransomware out of 30 victims.
Older Prometheus Variants
The first encountered Prometheus sample, first observed in February 2021 (SHA256: 9bf0633f41d2962ba5e2895ece2ef9fa7b546ada311ca30f330f0d261a7fb184), behaves similarly to the more recent variant we are currently tracking. However, it appends the following extension to the encrypted files: .PROM[prometheushelp@mail[.]ch].
Some of the observed samples, when executed, opened a Windows Command Shell showing the encryption progress (Figure 9). The most recent Prometheus samples do not display this information.
Figure 9. Encryption progress window.
Another variant (SHA256: 11aebdff8c064c160c2b21f3a844bacaecd581d9dc2e4224d31903d2a56e2dd3) appended the .XXXXXXXXXX[prometheusdec@yahoo[.]com] extension format to encrypted files where the X is the victim ID. Like the current variant, it generates two ransom note files. The ransom note includes two ways to contact the group that are different from those offered by the current variant (Figure 10). Based on the content and instructions provided by this variant, we believe Prometheus didn’t have a leak site established at the time they distributed it.
Figure 10. RESTORE_FILES_INFO.hta (as sent by an older Prometheus variant).
Instead of directing the victim to the leak site as the current variant does, the older variant of Prometheus instructs the victim to go to a Tor site called Sonar, a web-based messaging service, and create an account. After the account is created, the ransom note instructs the victim to send a message to the username Prometheus, containing the file extension identifier and a link to three encrypted files to provide proof of decryption. The second method of contact is through email and includes three email addresses for contact, requesting the same information as the first method.
This helps us understand how the Prometheus ransomware group originally operated and shows the evolution of their approach to securing payment before deciding to start their own leak site.
Conclusion
Prometheus is a new and emerging ransomware gang that uses a personalized variant of Thanos ransomware. The operators behind this ransomware are actively targeting multiple industries globally. Like many other ransomware groups, Prometheus hosts a leak site to create additional pressure and shame victims into paying the ransom. While Prometheus claims to be part of the REvil ransomware gang, during our research, we didn’t find a solid connection between the two ransomware groups at the time of writing this report.
Indicators associated with this Threat Assessment are available on GitHub, have been published to the Unit 42 TAXII feed and are viewable via the ATOM Viewer.
Palo Alto Networks customers are protected from this threat by:
WildFire: All known samples are identified as malware.
This section documents relevant tactics, techniques and procedures (TTPs) used with Prometheus and maps them directly to Palo Alto Networks product(s) and service(s). It also further instructs customers on how to ensure their devices are configured correctly.
Product / Service
Course of Action
Persistence, Privilege Escalation
The below courses of action mitigate the following techniques:
Look for the following BIOCs alerts to detect activity*:
Cortex XDR Agent - Behavioral Threat Detected
Table 1. Courses of Action for Prometheus ransomware. * These analytic detectors will trigger automatically for Cortex XDR Pro customers.
Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.
Get updates from Unit 42
Peace of mind comes from staying ahead of threats. Subscribe today.
Get the latest news, invites to events, and threat alerts
![Figure 17. DNS resolutions for eonsabode[.]at.](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/06/word-image-63.png)
![Resolutions associated with 34.94.151[.]129](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/06/word-image-64.png)
![Resolutions associated with 34.106.243[.]174](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/06/word-image-65.png)
![Resolutions associated with 34.105.89[.]82](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/06/word-image-66.png)
Like many current ransomware gangs, this group also created a leak site (a different section of the same website that hosts the “ticketing system”) where they name and shame their victims (Figure 5).
The Prometheus ransomware operators include a status per victim. We found that some of the information posted on the leak site has already been sold to an unknown third party. There are also posts showing that victims within impacted industries paid the ransom and their data was removed from the site (Figure 6).
Get updates from Unit 42 