With more and more companies choosing to allow for flexible (hybrid/remote) work environments post-pandemic, we investigated the unique cyberthreats employees working from home face.
Our analysis focused primarily on trends in our firewall traffic and phishing pages detected by our URL Filtering service from September 2019 to April 2021. We found that in early 2020, when employees were making the shift to working from home, there was a significant drop in traffic coming through our URL Filtering service, coinciding with a significant increase in the number of new phishing pages per week. This suggests that at the peak of remote work, right when the smallest percentage of end-user traffic was being protected by corporate firewalls, threat actors were putting out more phishing attacks than ever.
By comparing the rate of phishing traffic coming from our on-prem firewalls versus our cloud-delivered security platform, Prisma Access, we discovered that remote employees might be especially vulnerable to a wide variety of phishing attacks. Specifically, we saw that the percentage of traffic coming from phishing pages was more than 2.4 times greater in Prisma Access traffic than in on-prem firewall traffic. This emphasizes the need to have the proper defenses in place for employees who are either fully remote or working from home.
With phishing attacks continuing to rise globally, it’s more important now than ever that all employees are able to safely and securely browse the web, regardless of whether they are working in the office or from home. Tools like Prisma Access and GlobalProtect can help shield remote and/or hybrid employees from these cyberthreats by ensuring that they have access to the same security services afforded by Palo Alto Networks Next-Generation Firewalls.
Firewall Traffic Trends
We began our analysis by investigating trends in our URL Filtering traffic from before the pandemic, starting in September 2019. We observed a sudden and significant drop in traffic from March-April 2020, just as COVID was beginning its initial spread throughout the U.S., forcing organizations to shift to remote work.
Figure 1. Total observed URL Filtering traffic per week from September 2019-April 2021.
We then investigated how changes in customer traffic differed between our on-prem Next-Generation Firewalls and our cloud-delivered security platform, Prisma Access. We saw that weekly traffic from our on-prem firewalls (blue in Figure 2 below) dropped quite significantly – by about 45% – from March-April 2020. In contrast, weekly traffic from Prisma Access (orange in Figure 2) increased by more than 200% as employees suddenly shifted to working remotely. (The dips in December 2020 and December 2021 correspond to holiday breaks.)
This suggests that organizations relying solely on on-prem firewalls, without adjusting to increased remote work by deploying cloud-delivered security services, were far more vulnerable to a variety of cyberattacks since their now-remote employees were able to browse the web unprotected.
Figure 2. On-prem firewall traffic versus Prisma Access (cloud) traffic from September 2019-April 2021. Normalized such that the maximum weekly traffic is represented with a value of 1.00.
To further investigate this point, we looked into which industries experienced the greatest drops in total URL Filtering traffic from March-April 2020. We noticed that the education and high tech industries experienced especially large decreases in traffic during this period: education (~46% decrease), presumably due to school closures, and high tech (~35% decrease), presumably due to employers’ willingness to let employees work remotely given the industry’s inherently digital nature. All in all, nearly every industry we studied experienced a significant drop in URL Filtering traffic of roughly 30% or more during this time.
Figure 3. Total weekly traffic by industry from September 2019-April 2021.
These significant drops in observed URL Filtering traffic stress the importance of having access to security services regardless of where your employees or end users are physically located. Although our observed URL Filtering traffic dropped at the start of the pandemic, internet usage as a whole went up by ~25% in mid-March, according to the Wall Street Journal. (Total internet usage then dipped slightly in May, but still stayed higher than pre-pandemic levels). This suggests that despite the drop in traffic, people were not necessarily using the internet any less than before. Rather, people were on average using the internet evenmore than before, with a larger proportion of that internet traffic being unprotected by enterprise-grade firewalls, leaving end users more vulnerable than ever to a wide variety of cyberthreats.
Since the hybrid work model is likely here to stay post-pandemic (according to The Work Trend Index, a report published by Microsoft, over 70 percent of employees across a variety of industries want flexible remote work options to continue), organizations must rethink how to protect their workforces moving forward, which starts by making digital security an integral part of their hybrid and/or remote work plans.
Phishing-Related Trends
To study how attackers may have responded to this increase in remote work, we investigated the number of phishing URLs detected by our ML-powered URL Filtering service from September 2019-April 2021.
We observed an initial upward trend in new phishing URLs starting around February 2020, peaking around June 2020. Looking at Figure 4, we can see that the largest number of new phishing pages (orange) was observed just as URL Filtering traffic (blue) was at its lowest point (May-June 2020). This suggests that the high prevalence of remote work at this time coincided with a high rate of attempted phishing attacks.
Figure 4. Total URL traffic versus number of new phishing URLs from September 2019-April 2021
Next, we used keyword matching to determine which URLs were business-related (targeting various business communication and/or collaboration tools) and which phishing URLs were consumer-related (targeting well-known social media brands, consumer banking sites, etc.). We found that business-related and consumer-related phishing attacks increased by roughly 100% from February 2020 to June 2020. This suggests that the types of phishing attacks responsible for the spike during this time period did not necessarily change – but rather, the total volume of attempted phishing attacks increased across the board.
In addition, we can see from the upward trend toward the right side of Figures 4 and 5 that the rate of new phishing attacks shows no signs of slowing down anytime soon.
Figure 5. Business-related versus consumer-related phishing URLs per week from September 2019-April 2021.
Figure 6. office365invoicea[.]xyz/ce: A typical example of a business phishing webpage targeting Office365. This page requires that the user first interacts with the page to see the phishing form, possibly in an attempt to evade automated phishing detection engines.Figure 7. ww3ecure-authlogin4[.]ns02[.]info/Chase%20New/: A typical example of a consumer phishing webpage targeting Chase bank.Finally, we investigated which industries are the most affected by these phishing attacks. We did this by calculating the percentage of total traffic for organizations in each industry that came from phishing webpages from September 2019-May 2021.
Figure 8. Percentage of phishing traffic relative to the total traffic by industry from September 2019-May 2021.
We found that the telecommunications industry was by far the most heavily impacted by phishing attacks, with about 0.1% of total traffic coming from phishing webpages. Of note, the high tech and education industries (both of which experienced significant drops in firewall traffic during the pandemic) also happen to be among the top-five most heavily affected industries.
Figure 9. Percentage of phishing traffic relative to total traffic for on-prem firewalls versus Prisma Access from March 2020-April 2021.
Furthermore, we saw that the percentage of traffic coming from phishing pages was more than 2.4 times greater in Prisma Access traffic than in on-prem firewall traffic. While we can’t be certain of the underlying reasons behind this, one plausible explanation is that employees may be less on-guard against phishing links when working outside the office. If this is indeed the case, then that would make it doubly important that employees who are working remotely have access to adequate internet security like URL Filtering to protect them from online threats such as phishing attacks and other malicious webpages.
Securing Your Remote/Hybrid Workforce
With today’s work environment shifting more and more to the virtual sphere, and with more and more work happening outside the physical boundaries of an office or corporate campus, it’s often no longer enough to rely entirely on on-prem firewalls to keep end users protected while browsing the web.
We can see that attackers tried to make the most of this sudden spike in remote work by ramping up their rate of phishing attacks, going after end users’ corporate credentials, as well as their personal credentials. We are now observing more new phishing attacks per week now than ever before, and our findings suggest that remote employees may be especially vulnerable to these phishing attacks, emphasizing the importance of having the proper defenses in place.
For end users who have access to Palo AltoNetworks URL Filtering services (e.g. via Prisma Access or GlobalProtect), it is likely that many of these phishing URLs would have been blocked before even being rendered in the user’s web browser. For end users working from home without access to a Next-Generation Firewall or cloud-delivered security service, it is likely that more of these attacks would have been successful, and that many end users have been fooled into giving attackers either their business login credentials or sensitive personal information.
With more companies looking to adopt remote and/or hybrid work models in the future, it is more important than ever to ensure that all employees have secure access to the internet, no matter where they happen to be physically located.
Conclusion
We have seen that threat actors ramped up their rate of phishing attacks at the same time as the number of employees who were working from home increased. If employers want to maintain a secure workforce in this new hybrid/remote environment, it is crucial that employees who are working from home have the same access to adequate coverage from cyberthreats that employees who are working in the office do.
Palo Alto Networks remote-work offerings, including cloud-delivered security services such as URL Filtering and Threat Prevention, can protect employees from the latest phishing and malware attacks regardless of whether they are working from the office or remotely.
In addition to these security services, best practices to protect yourself and your organization from phishing attacks include:
For individuals:
Exercising caution when clicking on any links or attachments contained in suspicious emails, especially those relating to one’s account settings or personal information, or otherwise trying to convey a sense of urgency.
Verifying the sender’s address for any suspicious emails in your inbox.
Double-checking the URL and security certificate of each website before inputting your login credentials.
Reporting suspected phishing attempts to your organization’s IT or InfoSec department
For organizations:
Implementing security awareness training to improve employees’ ability to identify fraudulent emails.
Regularly backing up your organization’s data as a defense against ransomware attacks initiated via phishing emails.
Enforcing multi-factor authentication on all business-related logins as an added layer of security.
Phishing emails can be the start of ransomware attacks. If you think you may have been impacted by ransomware, please email unit42-investigations@paloaltonetworks.com or call (866) 486-4842 – (866) 4-UNIT42 – for U.S. toll free, (31-20) 299-3130 in EMEA or (65) 6983-8730 in JAPAC. The Unit 42 Incident Response team is available 24/7/365. You can also take preventative steps by requesting a Ransomware Readiness Assessment.
The author would like to thank Wei Wang, Huagang Xie, Mayuresh Ektare, Vaishnavi Grudanti and Mike Jacobsen for helping to set the direction for this research; Claud Xiao, Russell Holloway and Eric Chen for helping to gather the data used in the analyses; and Laura Novak, Jen Miller Osborn, Jim Finkle and Lakshmi Kandadai for their help in publishing the blog.
As part of Unit 42’s commitment to stop ransomware attacks, we conduct ransomware hunting operations to ensure our customers are protected against new and evolving ransomware variants. We monitor the activity of existing groups, search for dark web leak sites and fresh onion sites, identify up-and-coming players and study tactics, techniques and procedures. During our operations, we have observed four emerging ransomware groups that are currently affecting organizations and show signs of having the potential to become more prevalent in the future:
AvosLocker is ransomware as a service (RaaS) that started operations in late June, using a blue beetle logo to identify itself in communications with victims and “press releases” aimed at recruiting new affiliates. AvosLocker was observed promoting its RaaS program and looking for affiliates on dark web discussion forums and other forums. Like many of its competitors, AvosLocker offers technical support to help victims recover after they’ve been attacked with encryption software that the group claims is “fail-proof,” has low detection rates and is capable of handling large files. This ransomware also has an extortion site, which claims to have impacted six organizations in the following countries: the U.S., the U.K., the U.A.E., Belgium, Spain and Lebanon. We have observed initial ransom demands ranging from $50,000 to $75,000.
Hive Ransomware is double-extortion ransomware that started operations in June. Since then, Hive has impacted 28 organizations that are now listed on the group’s extortion site, including a European airline company and three U.S.-based organizations. Hive uses all tools available in the extortion toolset to create pressure on the victim, including the date of initial compromise, countdown, the date the leak was actually disclosed on their site, and even the option to share the disclosed leak on social media.
HelloKitty is not a new ransomware group; it can be tracked as early as 2020, mainly targeting Windows systems. However, in July, we observed a Linux variant of HelloKitty targeting VMware’s ESXi hypervisor, which is widely used in cloud and on-premises data centers. We also observed two clusters of activity. Across the observed samples, some threat actors preferred email communications, while others used TOR chats for communication with the victims. The observed variants impacted five organizations in Italy, Australia, Germany, the Netherlands and the U.S. The highest ransom demand observed from this group was $10 million, but at the time of writing, the threat actors have only received three transactions that sum up to about $1.48 million.
LockBit 2.0 (previously known as ABCD ransomware) is a three-year-old RaaS operator that has been linked to some high-profile attacks lately following the June launch of a slick marketing campaign to recruit new affiliates. It claims to offer the fastest encryption on the ransomware market. LockBit 2.0 has impacted multiple industries – 52 victims are listed on the group’s leak site. Its victims include organizations in the U.S., Mexico, Belgium, Argentina, Malaysia, Australia, Brazil, Switzerland, Germany, Italy, Austria, Romania and the U.K.
Here, we share information we've gathered from our observations of the behavior of these ransomware groups to help organizations defend against them.
AvosLocker is new ransomware that was first observed on July 4, 2021, and follows the RaaS model. The ransomware operator of the same name, avos, advertised their affiliate program on Dread (Figure 1). Dread is a Reddit-like dark web discussion forum featuring news and sub-dreads around darknet markets. The announcement of the program includes information about features of the ransomware and lets affiliates know that AvosLocker operators will take care of negotiation and extortion practices. The user Avos has also been observed trying to recruit individuals on the Russian forum XSS.
Figure 1. AvosLocker announcement in Dread.AvosLocker, when executed, first opens a Windows shell showing the progress of the encryption process. After encryption is complete, it then appends the .avos extension to the encrypted files and drops the ransom note GET_YOUR_FILES_BACK.TXT in every encrypted directory (Figure 2). We observed another AvosLocker sample that behaves exactly the same way as the initial observed sample, but also included a string called “Message from the agent” letting the victim know their files were exfiltrated.
The ransom note includes information and an ID used to identify victims, and instructs the victim to visit the AvosLocker TOR site (Figure 3).
Figure 3. AvosLocker landing page.
After submitting the ID, the victim will encounter a support chat and the request for ransom. From the available instances observed, we have seen payment requests as low as $50,000 and as high as $75,000 in Monero (XMR). As seen with other ransomware groups, AvosLocker increases the ransom price if the victim doesn’t pay in the designated time period, as shown in Figure 4.
Figure 4. AvosLocker support page.
While exploring their site, we discovered that this group has already affected seven organizations: two law firms, one in the U.K. and one in the U.S.; a logistics company in Spain; a real estate agency in Belgium; a holdings company in Turkey; a Syrian transportation organization and a city in the U.S. Some of the leaked data displayed on their site include private organization documents and personal identifiable information.
AvosLocker's first site post, on Jan. 1, 2021, was an announcement that the site was officially online (Figure 5). The user avos also announced they started leaking data on multiple sub-dreads as well. We believe this was done to attract more affiliates and traffic to their site.
Figure 5. AvosLocker leak site and multiple advertisements on Dread.
Hive Ransomware
Hive ransomware began operations in June 2021 and has already shown notable disregard for its victims’ welfare, attacking organizations including healthcare providers and mid-size organizations ill-equipped for managing a ransomware attack. Hive published their first victim on their leak site, Hive Leaks, in late June (Figure 6). Since then, 28 victims have been published on the Hive Leaks site, including a European airline company and three U.S.-based organizations, one each in hardware retail, manufacturing and law. The posts include the date and time the victim was affected.
Figure 6. Hive Leaks.
When this ransomware is executed, it drops two batch scripts. The first script, hive.bat, tries to delete itself, and the second script is in charge of deleting the shadow copies of the system (shadow.bat). Hive ransomware adds the [randomized characters].hive extension to the encrypted files and drops a ransom note titled HOW_TO_DECRYPT.txt containing instructions and guidelines to prevent data loss (Figure 7). The ransom note includes a generated login credential for the victim to chat with what the threat actors claim is their “sales” department. The TOR link directs the “customer” to a login page, and after the credentials are submitted, it opens up a chat room for communication between the operators and the victim (Figure 8).
Figure 7. Hive ransom note.
We noticed that the login credentials provided by the ransom note were for a specific victim. With this in mind, we then hunted for additional samples and found two more victims that were affected but not yet listed on the leak site at the time of writing. After logging in, the victim will see a chat where they can talk to the operators and get their decryptors (Figure 8).
Figure 8. Hive chat (left) and login page (right).
We don’t yet have information on how Hive ransomware is being delivered, but ransomware operators are known for buying access to certain networks, brute-forcing credentials or spear-phishing for initial access.
HelloKitty: Linux Edition
HelloKitty is a ransomware family that first surfaced at the end of 2020, primarily targeting Windows systems. The malware family got its name due to its use of a Mutex with the same name: HelloKittyMutex. The ransomware samples seem to evolve quickly and frequently, with different versions making use of the .crypted or .kitty file extensions for encrypted files. Some newer samples make use of a Golang packer that ensures the final ransomware code is only loaded in memory, most likely to evade detection by security solutions.
In July 2021, we came across a Linux (ELF) sample with the name funny_linux.elf containing a ransom note with verbiage that directly matched ransom notes seen in later samples of HelloKitty for Windows. This led to the discovery of other samples of this Linux strain of the HelloKitty ransomware, dating as far back as October 2020. However, starting in March, the samples began targeting ESXi, a target of choice for recent Linux ransomware variants.
Oddly enough, the preferred mode of communication shared by attackers in the ransom notes across the different samples is a mix between TOR URLs and victim-specific Protonmail email addresses. This could indicate different campaigns or even entirely different threat actors making use of the same malware codebase. Since the samples we found contained victim-specific ransom notes, we were able to get an idea of the ransomware’s targets. We observed six organizations impacted by Hello Kitty, including Italian and Dutch pharmaceutical organizations, a Germany-based manufacturer, an Australian industrial automation solutions organization, and a medical office and a stock broker in the U.S. One sample, oddly enough, didn’t contain any contact information in its ransom note.
We also observed that the ransom demanded by the operator varies depending on the impacted organization; we saw demands as high as $10 million and as low as $950,000 in Monero (Figure 9). The operators behind HelloKitty are also open to using bitcoin (BTC), but they charge higher for bitcoin transactions due to its associated fees. We were able to look up the BTC wallet address they provided for victims (bc1ql5f3m75qx3ueu2pz5eeveyqsw6pdjs3ufk8r20) and confirm that three transactions were made to that address, summing up to $1,477,872.41.
Figure 9 HelloKitty chats.
The samples found primarily made use of different combinations of the arguments described in Table 1.
Argument
Description
Value(s)
v
Verbose mode
0 or 1
d
Run the process as a daemon
0 or 1
e
When the flag is set, the ransomware only encrypts files with the extensions .vmdk, .vmx, .vmsd and .vmsn
It is not set by default, which means that all files under the start path that don’t match certain ransomware-specific file extensions will be encrypted
0 or 1
k
When this flag is set, the ransomware tries to kill VMs running on the host using the esxcli tool.
It is not set by default
0 or 1
m
Mode
5 (default) or 10 or 20 or 25 or 33 or 50
c
(Unsure of purpose)
Table 1. Arguments accepted by the Linux HelloKitty ransomware.
The following esxcli commands are executed to kill running VMs, when the k flag is set:
esxcli vm process list esxcli vm process kill -t=soft -w=%d %(PID) esxcli vm process kill -t=force -w=%d %(PID)
The malware samples log their output to a work.log file in their execution path.
Finally, the ransomware makes use of the Elliptic Curve Digital Signature Algorithm (ECDSA) for encrypting files using functions from the shared library libcrypto.so for encryption. The encrypted file is saved with the extension .crypt. Each encrypted file has a corresponding file with the extension .README_TO_RESTORE containing the ransom note. Additional details can be found in the appendix of this report.
LockBit 2.0
LockBit is another ransomware group that follows the RaaS model. According to their website, this ransomware affiliate program has been active since September 2019. While LockBit has been known for some time, we included this group in this blog because of their recent evolution to LockBit 2.0. In June 2021, the operators behind this ransomware revamped their site and rebranded as LockBit 2.0.
Since June 2021, they have compromised 52 organizations in accounting ,automotive, consulting, engineering, finance, high tech, hospitality, insurance, law enforcement,l egal services, manufacturing, non-profit energy, retail, transportation and logistics industries, utilities in the following countries: Argentina, Australia, Austria, Belgium, Brazil, Germany, Italy, Malaysia, Mexico, Romania, Switzerland, the U.K. and the U.S. All the posts by the threat actors on their leak site include a countdown until confidential information is released to the public, which creates additional pressure on the victim (Figure 10).
Figure 10. Affiliation program description (left) and leak site (right).
The threat actors behind this ransomware claim that their current variant is the fastest encryption software in operation. To attract more affiliates, they include a table comparing different ransomware families, including their previous variant (Figure 11).
Figure 11. Encryption speeds comparison released by LockBit.
When LockBit is executed, it starts encrypting files and appends the .lockbit extension. Additionally, the ransomware changes the icon of the encrypted file to the LockBit 2.0 logo (Figure 12.b). After encryption is complete, LockBit then drops the ransom note titled, Restore-My-Files.txt (Figure 12.a).
Similar to REvil, LockBit 2.0 ransomware modifies the victim’s desktop wallpaper if the encryption process is successful, making the victim aware of their compromise. The wallpaper also includes an advertisement aimed at encouraging insider threats that all organizations could fall prey to. (Figure 13).
Figure 13. Modified LockBit 2.0 wallpaper.
The advertisement states that the threat actors are interested in methods of access, such as RDP, VPN and corporate email credentials. In exchange, they offer a cut of paid ransom.
If the victim wants to communicate with Lockbit operators to get their data back, the operators include a “Decryption ID” and a TOR link (and their clearnet mirror: decoding[.]at) on the ransom note. This information allows the user to log in and start the negotiation process (Figure 14).
Figure 14. Support site login (left) and LockBit Support chat (right).
Conclusion
With major ransomware groups such as REvil and Darkside lying low or rebranding to evade law enforcement heat and media attention, new groups will emerge to replace the ones that are no longer actively targeting victims. Here, we shared information on some of the observed malicious activity of the ransomware groups trying to become the next key players. While LockBit and HelloKitty have been previously active, their recent evolution makes them a good example of how old groups can re-emerge and remain persistent threats. Unit 42 will continue to monitor these ransomware families – and new ones that may emerge in the future.
Palo Alto Networks customers are protected against these ransomware families with Cortex XDR or the Next-Generation Firewall with Threat Prevention and WildFire security subscriptions. Customers can use AutoFocus for tracking related entities using the AvosLocker, Hive, LockBit and HelloKitty tags, respectively. Full visualization of the techniques observed can be seen in the Unit 42 ATOM viewer.
Palo Alto Networks has shared these findings, including file samples and indicators of compromise, 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.
If you think you may have been impacted by any of these ransomware families, please email unit42-investigations@paloaltonetworks.com or call (866) 486-4842 – (866) 4-UNIT42 – for U.S. toll-free; (31-20) 299-3130 in EMEA; or (65) 6983-8730 in JAPAC. The Unit 42 Incident Response team is available 24/7/365. You can also take preventative steps by requesting a Ransomware Readiness Assessment.
Organizations are facing an increase in obfuscation behavior from on-site and remote employees attempting to bypass proxy servers to hide their online activities or exfiltrate data without detection. For example, an employee might use the “incognito” mode, download a personal virtual private network (VPN) or the Tor browser, or bypass the corporate VPN. In those cases, the information security team (InfoSec) needs complete network visibility to determine if that employee is solely guarding their own privacy, masking behavior that breaks organization policies or attempting to cover an attack.
Personal VPN services promise to enable secure, encrypted tunnels for user traffic. They provide services that prevent others from seeing through these tunnels by encrypting the internet connection and keeping users' application usage and browsing history private. VPNs may be used to bypass internet censorship and traffic policy enforcement. However, in practice, they obscure organizations’ visibility into networks.
Network visibility is important for a variety of reasons, including improved security by policy enforcement, a decrease in shadow IT, and speedy detection of malicious or suspicious activities. It can enhance application profiling for organizations and aid in well-informed decision-making.
Organizations often use tools such as Palo Alto Networks Next-Generation Firewalls to gain immense visibility into network traffic. Enterprises may attempt to obtain visibility down to the packet, application and user level.
Here, we assess personal VPN applications and their risk and threats to network visibility within organizations. We will touch on how these applications and services evade firewalls to bypass security and policy enforcement mechanisms.
Palo Alto Networks customers can maintain complete network visibility through the use of the Next-Generation FirewallApp-ID, which assists in the identification and sanitization of personal VPNs in networks.
Using Personal VPN on Corporate Networks: Key Risks
VPNs enable users to access network resources that may remain inaccessible otherwise. VPNs were developed to allow companies in different locations to connect their internal networks via encrypted channels through the internet. They are commonly used in workplaces to provide access to assets and devices for users who are not physically connected to a corporate network, such as remote workers. However, VPNs are now readily available to everyone – in some cases, free of charge. Nonetheless, average users often don't consider the risks of using personal VPNs on company devices.
Concerning data security and privacy with VPNs, in most cases, users have to simply trust their VPN providers, since providers operate the network tunnel. Moreover, providers can see which websites the user visits, including non-encrypted data, and the frequency of their visits. This data can be stored; some of it is valuable to advertising and marketing firms that use surfing behaviour to deliver ads to the right target audience. VPN providers could double-dip users and businesses by taking subscription money from users and selling users' web consumption data to the advertising industry. In more extreme cases, they might even supply user data to government authorities.
Using personal VPNs can introduce risks to networks. These risks involve threats that InfoSec teams mitigate in corporate environments via a defense-in-depth strategy to protect endpoints and prevent users from performing specific unauthorized tasks, either deliberately or accidentally.
Attackers constantly scan for vulnerable networks to compromise. If attackers succeed at compromising even one computer from an organization, the entire network could be at risk. Organizations use their domain name systems (DNS), enterprise data loss prevention (DLP), and proxy servers as countermeasures, each of which plays an important role in protecting users, data and communications. Circumventing any of those decreases network visibility and endangers the organization.
One of the primary uses of proxy servers is to prevent employees' access to browsing inappropriate and unsafe sites and monitor traffic. In addition, proxy servers protect corporate endpoints from communication with malicious command and control (C2) servers. However, through VPNs, users can bypass this protection. For example, if an employee's computer gets infected while using a VPN, the data sent to the C2 server will not be visible to the InfoSec team.
Insider threats pose almost as significant a risk to enterprise security as external intruders. Private or personal VPNs allow employees to bypass security measures and permissions that the InfoSec team put in place. VPNs can leave online activities vulnerable to hackers. In addition, the IT team loses its complete visibility into users' activities – for example, they hide when users browse unsafe or forbidden sites.
Known VPN Vulnerabilities
Not only does the underlying functionality of VPN products bring risks to the organization, but also, these products are often targeted by advanced persistent threats (APTs) due to their vulnerabilities. Unfortunately, cybercriminals all too often find ways to exploit known and patched vulnerabilities, banking on not all users having kept their patches up to date.
We took a list of the best VPN products of 2021 according to PC Magazine and checked the number of known vulnerabilities they have had in the past few years, as seen in Table 1.
Name
Number of Vulnerabilities
Vuln ID
Highest CVSS Severity
Private Internet Access VPN
12
CVE-2020-15590
CVE-2019-12579
CVE-2019-12578
CVE-2019-12577
CVE-2019-12576
CVE-2019-12575
CVE-2019-12574
CVE-2019-12573
CVE-2019-12571
CVE-2019-12572
CVE-2018-10190
CVE-2017-15882
V3.0: 7.8 HIGH
V2.0: 9.3 HIGH
NordVPN
3
CVE-2018-3952
CVE-2018-10170
CVE-2018-9105
V3.0: 9.8 CRITICAL
V2.0: 10.0 HIGH
IVPN
3
CVE-2020-7043
CVE-2020-7042
CVE-2020-7041
V3.1: 9.1 CRITICAL
V2.0: 6.4 MEDIUM
ExpressVPN
2
CVE-2020-29238
CVE-2018-15490
V3.1: 7.5 HIGH
V2.0: 5.0 MEDIUM
ProtonVPN
2
CVE-2018-4010
CVE-2018-10169
V3.0: 9.8 CRITICAL
V2.0: 10.0 HIGH
Hotspot Shield VPN
2
CVE-2020-17365
CVE-2018-6460
V3.1: 7.8 HIGH
V2.0: 7.2 HIGH
CyberGhost VPN
1
CVE-2018-10646
V3.0: 7.8 HIGH
V2.0: 7.2 HIGH
TunnelBear VPN
1
CVE-2018-10381
V3.0: 9.8 CRITICAL
V2.0: 10.0 HIGH
Table 1. Best VPN products of 2021 according to PC magazine, the number of known vulnerabilities in those services, and information on CVEs and severity.
How Do VPN Applications Try to Evade Firewalls?
Given that they can introduce vulnerabilities into an organization's network, it's concerning that the function of VPN applications includes trying to evade firewalls. VPNs cannot make online connections completely anonymous; however, VPNs typically tunnel into other protocols and use encryption techniques. VPN service providers can use secure VPN protocols such as Internet Protocol Security (IPsec), Transport Layer Security (SSL/TLS), Datagram Transport Layer Security (DTLS), Microsoft Point-to-Point Encryption (MPPE), Microsoft Secure Socket Tunneling Protocol (SSTP), Secure Shell VPN (SSH/OpenSSH), OpenVPN and WireGuard. However, these are all secure and well-defined protocols for legitimate use of VPNs, which comes with a disadvantage for personal VPN service providers. Because these are all known protocols, they can easily be blocked by organizations or governments. This poses a contradiction with the VPN provider's promise to their customer, which is 100% secure connectivity and availability.
VPN providers do their best to remain undetectable in the network, leveraging methods such as switching ports or servers or hopping from protocols. For example, VPN services that are based on OpenVPN give their users the option to change the transport protocol to Transmission Control Protocol (TCP) or User Datagram Protocol (UDP). However, the demand for remaining undetected while maintaining full availability to serve customers goes further than that. Some VPN companies design their proprietary protocols precisely for circumventing organization or government blocks.
In this section, we review the evasion techniques that are used by some VPN products.
Self-Signed Certificate
Figure 1 illustrates how Hotspot Shield uses a bogus self-signed certificate to evade firewalls with its traffic. However, It can be identified with methods such as examining TLS Cipher Suite information, port number and observation of a pattern that is different from the genuine certificate.
Figure 1. Hotspot Shield uses a bogus self-signed certificate to evade firewalls.
“Tunnel Into HTTP Traffic”
Some VPN applications try to traverse firewalls by sending traffic that appears to be simple HTTP traffic. However, with close inspection, their characteristics can be identified, such as authentication header or encoding, HTTP request method or port number, along with other distinct information in the request headers. These can be used to identify such applications.
Figure 2 shows that SetupVPN, which has over two million users, uses the HTTP proxy-authorization header to authenticate users to its server. Deciphering the header presents helpful information about the SetupVPN application.
Figure 2. SetupVPN uses an HTTP Proxy-authorization header to authenticate users to its server.
Mimicking Common Protocols
VPN applications send traffic using well-known ports for their communication to evade firewalls and cause misidentification of the firewall implementation to pass through firewalls. For instance, with over 10 million users, Thunder VPN uses UDP port 53, known for its use for DNS, and TCP port 443, known for its use for the HTTP protocol over TLS/SSL.
Figure 3. Thunder VPN mimics SSL traffic by utilizing the port and the handshake type.
The above figure shows that the traffic on port 443 sent by Thunder VPN was misidentified as SSL in Wireshark. Thunder VPN mimics SSL traffic by utilizing the same port and handshake type.
Thunder VPN also uses port 53 to evade traffic using default DNS ports that are generally allowed in all networks. In addition, the DNS reserved flag Z is set to 1, which must be zero in all DNS queries and responses in the traffic originated by this application. The UDP traffic on port 53 sent by Thunder VPN is as shown in Figure 4.
Figure 4. Thunder VPN UDP traffic on port 53 with DNS reserved flag Z is set to 1.
Conclusion
With the rise of remote work as adopted by most corporations these days, network security teams should recognize the potential threats presented by personal VPN usage and adjust security policies accordingly.
The Palo Alto Networks App-ID technology provides customers with the ability to control applications and protocols in their networks. It allows information and network security teams to securely enable applications through policies that allow or deny applications contextually. This helps keep the attack surface as small as possible.
App-ID, which is now running on the Palo Alto Networks Next-Generation Firewall, can grant visibility into VPN apps and their underlying protocols in your network, including all the protocols mentioned in this article. App-ID can help security teams see who uses VPN applications in your entire network – as well as when and where – and enforce policies chosen by your organization. Currently, App-ID covers more than 70 of the most popular VPN services.
The App-ID team constantly reviews and releases updates for the latest versions of VPN applications to its customers. Due to the nature of these applications, their traffic changes frequently to evade firewalls.
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).
![office365invoicea[.]xyz/ce: A typical example of a business phishing attack targeting Office365. This page requires that the user first interacts with the page to see the phishing form, possibly in an attempt to evade automated phishing detection engines.](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/08/word-image-53.png)
![ww3ecure-authlogin4[.]ns02[.]info/Chase%20New/: A typical example of a consumer phishing attack targeting Chase bank.](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/08/word-image-54.png)
![The screenshot shows a message posted in Dread, a dark web discussion forum. It announces an affiliate program for AvosLocker, one of the four emerging ransomware groups we identified. The message is titled, "AvosLocker - Ransomware [ACCEPTING AFFILIATES]"](https://unit42.paloaltonetworks.com/wp-content/uploads/2021/08/word-image-19.png)
When this ransomware is executed, it drops two batch scripts. The first script, 
Get updates from Unit 42 