RedLine Stealer is information-stealing malware that harvests login credentials and other sensitive data from a victim's Windows host. This Wireshark quiz uses a packet capture (pcap) that “crosses a line” separating normal traffic from malicious activity. The malicious activity in this pcap is a RedLine Stealer infection from July 2023. Our pcap provides experience analyzing RedLine traffic, and we can determine what specific data was stolen from an infected Windows computer.
Anyone can participate in this quiz. To get the most benefit, participants should be familiar with Wireshark. This quiz also requires a basic understanding of IPv4 traffic. To help people gain this knowledge, we have a series of Wireshark tutorials available.
Traffic for this quiz occurred in an Active Directory (AD) environment during July 2023. Details of the local area network (LAN) environment for the pcap follow.
Local Area Network (LAN) Details
LAN segment range: 10.7.10[.]0/24 (10.7.10[.]1 through 10.7.10[.]255)
Domain: coolweathercoat[.]com
Domain controller IP address: 10.7.10[.]9
Domain controller hostname: WIN-S3WT6LGQFVX
LAN segment gateway: 10.7.10[.]1
LAN segment broadcast address: 10.7.10[.]255
Quiz Questions
What is the date and time in UTC the infection started?
What is the IP address of the infected Windows client?
What is the MAC address of the infected Windows client?
What is the hostname of the infected Windows client?
What is the user account name from the infected Windows host?
What type of information did this RedLine Stealer try to steal?
Requirements
Participants should use Wireshark to review the pcap. We encourage people to customize their Wireshark column display before reviewing the traffic. While you should personalize Wireshark according to your specific needs, we recommend starting with changes demonstrated in our Unit 42 series of tutorials and videos.
Participants should use the latest version of Wireshark if possible, due to its feature updates and bug fixes over previous versions. We do not recommend outdated Wireshark versions like 1.x and 2.x for these quizzes.
Infection traffic often contains malware or malicious code targeting Microsoft Windows. Because of this, we recommend using Wireshark in a non-Windows environment to review the pcap for this quiz. Operating systems like BSD, Linux or macOS provide an ideal environment for Wireshark when reviewing traffic from Windows-based malware like RedLine Stealer.
Accessing the Pcap
The pcap for this quiz is located in our GitHub repository as shown in Figure 1. Download the ZIP archive named 2023-07-Unit42-Wireshark-quiz.pcap.zip as shown in Figure 2. Use infected as the password to unlock the ZIP archive as shown in Figure 3.
Figure 1. Our GitHub repository for Unit 42 Wireshark quizzes.Figure 2. After selecting the pcap, download it from the GitHub repository.Figure 3. Extracting the pcap from the downloaded ZIP archive.
Conclusion
RedLine Stealer is one of many information stealers within our current threat landscape. This Wireshark quiz can help participants better understand network traffic associated with a RedLine Stealer infection.
The answers to the Unit 42 Wireshark quiz for RedLine Stealer are published in a separate post.
If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200
Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
While the SugarCRM CVE-2023-22952 zero-day authentication bypass and remote code execution vulnerability might seem like a typical exploit, there’s actually more for defenders to be aware of. Because it’s a web application, if it’s not configured or secured correctly, the infrastructure behind the scenes can allow attackers to increase their impact. When a threat actor understands the underlying technology used by cloud service providers, they can accomplish a great deal if they can gain access to credentials that have the right permissions.
During the past year, Unit 42 responded to multiple cases where the SugarCRM vulnerability CVE-2023-22952 was an initial attack vector that allowed threat actors to gain access to AWS accounts. This was not due to a vulnerability in AWS, and it could have happened with any cloud environment. Instead, the threat actors took advantage of misconfigurations to expand their access after initial compromise.
This article maps out various attacks against AWS environments following the MITRE ATT&CK Matrix framework, wrapping up with multiple prevention mechanisms an organization can put in place to protect themselves. Some of these protections include taking advantage of controls and services provided by AWS, cloud best practices, and ensuring sufficient data retention to catch the full attack.
The complexity of these attacks shows how it’s important to set your logging and monitoring to detect any unauthorized AWS API calls, even if they’re seemingly innocuous. If threat actors are allowed to gain a foothold, this can lead to much more daunting activity that is not always traceable. One size does not fit all in cloud security, but these attacks highlight key areas to focus on to make sure you're ready to defend against those attacks when they come.
Palo Alto Networks customers receive protections from the attacks described in this article in the following ways:
Organizations can engage the Unit 42 Incident Response team for specific assistance with this threat and others.
Prisma Cloud can provide alerting and mitigation solutions for the use-cases reported within this blog.
We’re framing the walk-through for these incidents with the MITRE ATT&CK Matrix, which is comprised of fourteen different tactics that describe the various components of a cybersecurity attack. With the various cases we responded to, nine of those fourteen tactics described the threat actor activity. Those nine were initial access, credential access, discovery, lateral movement, execution, exfiltration, privilege escalation, persistence and defense evasion.
Case Walk Through
Initial Access – CVE-2023-22952
The initial attack vector of these AWS account compromises was the zero-day SugarCRM vulnerability, CVE-2023-22952. SugarCRM is a customer relationship management platform that focuses on cross-team collaboration. The product has users in many different verticals due to their wide range of product features.
CVE-2023-22952 was published by NIST National Vulnerability Database on Jan. 11, 2023, with a base score of 8.8. This vulnerability allows threat actors to inject custom PHP code through the SugarCRM email templates module due to missing input validation.
To understand why the threat actors targeted SugarCRM for these attacks, it’s helpful to know that there is a wide range of sensitive data such as email addresses, contact information and account information in SugarCRM customer databases. If it was compromised, threat actors would either choose to sell this information directly or extort their victims to get more money.
By leveraging this vulnerability in SugarCRM, a threat actor can gain direct access to the underlying servers running this application due to the remote execution component of the vulnerability. In the cases we responded to, these servers were Amazon Elastic Cloud Compute (EC2) instances with long-term AWS access keys stored on the hosts, allowing the threat actors to expand their access. Since these organizations were hosting their infrastructure in the cloud, it opens different attack vectors for the threat actors than would be present with on-premises hosting.
Credential Access
Once the threat actors gained access to the EC2 instances, they successfully compromised long-term AWS access keys that existed on the host. Regardless of whether the computer exists on-premises or in the cloud, if a person uses the AWS command-line interface (CLI), they can choose to store temporary or permanent credentials used for the authentication within a credentials file stored on the host (as shown in Figure 1 below, which includes the file path).
In the cases we observed, these plain-text credentials existed on the compromised hosts, which allowed the threat actors to steal them and start using the access keys for discovery activity.
Figure 1. File paths for credentials file location.
Discovery
Before the threat actors performed any scanning activity, they first ran the command GetCallerIdentity. GetCallerIdentity is the AWS version of whoami. It returns various information about the entity that performed the call such as the user ID, account and Amazon Resource Name (ARN) of the principal associated with the credentials used to sign the request, as shown in Figure 2. The user ID is a unique identifier of the entity that performed the call, the account is the unique 12-digit identifier of the AWS account the credentials belong to, and the ARN includes the account ID and human-readable name of the principal performing the call.
Figure 2. Example GetCallerIdentity response.
Once the threat actor knew a little more about the credentials they compromised, they began their scanning activities. They utilized the tools Pacu and Scout Suite to gain a better understanding of what resources existed within the AWS account. Pacu is an open-source AWS exploitation framework, and it is designed to be the Metasploit equivalent in the cloud. Scout Suite is a security auditing tool used for security posture assessments of cloud environments.
In some of the cases we responded to, we saw Pacu already existed on hosts from previous penetration tests. Scout Suite was not something we saw downloaded onto the compromised EC2 instances, but we knew it was used based on the user agents associated with the threat actor activity. Both of these tools provide a lot of information for threat actors to get a lay of the land for the AWS account they’ve compromised.
In the cases, these tools scanned a variety of traditional services such as the following:
The threat actors also performed other discovery calls against services that would not necessarily be expected that provided helpful information to the attackers, such as the Organizations service and Cost and Usage service.
AWS Organizations provides companies with a centralized place to manage multiple AWS accounts and resources. When reviewing the threat actor activity in the CloudTrail logs, three Organizations API calls stood out. The first call was ListOrganizationalUnitsForParent, which lists out all the Organizational Units (OUs).
From there, the threat actors ran ListAccounts which returns all the account IDs associated with each of those OUs. The final call that provided the threat actor with the most useful information was the DescribeOrganization API call. This event returns the master account ID as well as the master account email address associated with that account. With that information, the threat actors have enough to attempt to log in as the Root user for that account.
The final discovery call of interest involved the Cost and Usage service. The threat actors performed various GetCostandUsage calls (shown in Figure 3) and the response returned information about the general costs within the compromised account (shown in Figure 4).
Defenders need to be aware that threat actors can determine how active an account is by understanding the cost within a cloud account. If the total cost in an account is large, it might be easier for them to spin up new resources undetected, because the cost might not stand out.
On the other hand, if there is very little spending in an account, a couple new resources could stand out a lot more. Account owners with less spending might also have tighter notifications around cost, which would potentially trigger alerts when the threat actors create new resources.
Figure 3. Example GetCostandUsage request parameters.Figure 4. Example GetCostandUsage response.
Both the Organizations and Cost and Usage API calls are great examples of how the attack surface is different in the cloud. By using these innocuous looking API calls, threat actors gained a ton of information about the account structure and usage without performing a lot of suspicious activity that might trigger an alert.
Lateral Movement/Execution/Exfiltration – RDS
In the incidents we observed, once threat actors finished scanning the environment, they had enough information to narrow their activity from discovery across the whole account to taking actions on various services starting with the Relational Database Service (RDS). The threat actors moved laterally from the compromised SugarCRM EC2 instances to the RDS service and started executing commands to create new RDS snapshots from the various SugarCRM RDS databases. The creation of these snapshots resulted in no downtime of the original RDS databases.
From there, the attackers modified pre-existing security group rules that already allowed SSH inbound, and they added port 3306 for MySQL traffic. The threat actors then moved to exfiltration, creating brand new databases from the snapshots, making them public and attaching the modified security groups. Finally, they modified the newly created RDS databases by changing the master user password, which would allow them to log in to the databases.
To understand whether any exfiltration of data occurred, in the cases that had virtual private cloud (VPC) flow logs enabled, we could use the logs to see how many bytes of data left the environment. With the cases that did not have VPC flow logs enabled, we were limited in our findings of data exfiltration.
Lateral Movement/Execution – EC2
After the RDS activity, the threat actors again moved laterally back to the EC2 service and made some changes. The first thing the threat actors did was create new Amazon Machine Images (AMIs) from the running SugarCRM EC2 instances, and from there they ran the ImportKeyPair command to import their public key pair that they created with a third-party tool. With these tasks complete, the threat actors proceeded to create new EC2 instances. The threat actors also attached existing security groups to the EC2 instances that allowed inbound port 22 access from any IP address, as shown in Figure 5.
Figure 5. Example security group allowing port 22 access.
The threat actors created EC2 instances in the same regions that the organizations used for the rest of their normal infrastructure. They also switched regions to a geographically new area, and created a new security group that allowed port 22 SSH traffic from any IP address. The threat actors then imported another key pair. Since the threat actors switched to a different region, the key pair had to be reimported even if it was the same key pair used in other regions.
After finishing the setup, they created a new EC2 instance, but this time they used a public AMI available on the AWS Marketplace. This EC2 instance activity shows the importance of enabling security services such as GuardDuty in all regions, to have visibility into all that is happening within an AWS account. As a proactive measure, organizations can disable unused regions as well.
Privilege Escalation – Root
For the privilege escalation portion of these attacks, the threat actors did not attempt to create new IAM users like we have seen in other cases. They instead opted for attempting to login as the Root user. Despite using information they obtained from the Organizations calls made during the discovery phase, the threat actors still failed to successfully log in as the Root user. Root login attempts are fairly noisy, so these failed Root logins stood out in the CloudTrail logs, as shown in Figure 6.
Figure 6. Example failed Root login from CloudTrail logs.
Persistence – Regions
Beyond attempting to log in with the Root account, the threat actors did not try much in the way of persistence. The clearest attempt at persistence was the creation of EC2 instances in different regions than the organizations normally used to host their infrastructure. Similar to the Root login attempts, these new EC2 instances stood out in the CloudTrail logs. However, it can be easy to miss stuff when reviewing resources in the console, as it's a fair amount of work to switch regions and track down all resources created, as cloud environments get larger.
Defense Evasion
Once a threat actor compromises an AWS account, they have a finite amount of time before the account owners detect that they have an issue. In order to stay under the radar, the threat actors deployed resources in non-standard regions. However, they also turned the EC2 instances on and off throughout their time in the environments.
There are a couple of reasons why a threat actor might choose to do this. The first reason is to decrease their visibility. On the EC2 instance page in the AWS console, it defaults to showing only running EC2 instances. Unless a user is actively trying to review non-running EC2 instances, at an initial glance, the new EC2 instances created by the threat actors would be missed once they are placed in a stopped state.
The second reason they might choose to do this is that stopping these resources also avoids incurring extra costs in the organization’s account. If the organizations have tight notifications around costs, threat actors stopping the resources they created minimizes costs and helps prevent triggering a cost alert, which is another way they could evade defenses.
Other than creating resources in different regions and stopping the resources they created, the threat actors did not attempt other defense evasion techniques such as stopping CloudTrail logging or disabling GuardDuty.
Remediation
Access Keys
There are four main remediation actions that organizations can take to protect themselves against these types of attacks in the future. The first one revolves around access keys. It’s vital for organizations to protect their access keys, as we often see them being the root cause of AWS compromises.
There is never a good reason to use long-term access keys on EC2 instances. Instead, use EC2 Roles and the temporary credentials that are present in the Instance Metadata Service (IMDS). Also, make sure to only use IMDSv2, which protects against server-side request forgery (SSRF) attacks.
We recommend creating a cleanup process for any long-term access keys stored in the credentials files on the hosts. This can be accomplished by asking users to clean up those files when they have completed their work, or by creating an organizational-level process that automatically cleans up these files.
We also recommend that the access keys are rotated and deleted on a schedule. The longer an access key lives, the more chance it has of being compromised. Consistently rotating them and deleting unused keys proactively protects the AWS account. This whole process can be automated and helps keep access key security in check.
Least-Privileged IAM Policies
The only reason that these threat actors were able to accomplish all that they did in these attacks was because of the expansive permissions that the organizations gave to the IAM User principal on the SugarCRM host. These IAM Users that were present on the hosts needed some AWS permissions, but those should have been narrowly scoped to only include exactly what the application using the permissions needed. And these organizations were not alone in this situation – according to our Cloud Threat Report, Volume 6, 99% of cloud users, roles, services, and resources were granted excessive permissions, which were left unused.
You can use AWS Access Analyzer to examine the historical usage of APIs by a particular IAM principal and automatically generate an access policy that restricts its access to only those APIs that it has used in the time period of your choice.
It might be easier to write overly permissive policies, but it is certainly worth the effort to write narrowly scoped permissions to better protect your AWS account.
Monitoring Root
Another remediation step we recommend to these organizations is to set up monitoring around the Root account. This account should only be used in an environment for a couple account management tasks that require Root, which maintains this as a high-fidelity alert to help secure the most valuable account. We also recommend always enabling multifactor authentication on Root and making sure it is protected with a long password.
Logging and Monitoring
The final remediation we recommend to these organizations is to make sure they have the correct logging configured. CloudTrail and GuardDuty should both be enabled in all regions and logs sent to a centralized location.
When it comes to GuardDuty, the alerts should be sent to a team that will respond based on the alert severity. In our cases where the organization had GuardDuty enabled, we saw that GuardDuty caught these access key compromises fairly early on in the attack. This is an easy way to help protect your accounts.
We also recommend for organizations to enable VPC flow logs to help catch any data exfiltration that might take place. These logs are extremely helpful when troubleshooting network connectivity issues. And with all of these different services, it’s important to make sure to have a good retention period for the data. Regardless of the environment, compromise can happen anywhere, and it’s vital to make sure logs are retained long enough to catch the full attack.
Conclusion
Even though the threat actors were able to accomplish a lot in these attacks, we saw that there’s some great remediation steps organizations can put in place to better protect themselves. Since access keys are the most common initial attack vector, try to avoid the use of long-term access keys when possible. In AWS, this means using EC2 Roles, IAM Roles Anywhere or Identity Center integration for developer workstations. Another layer to protect those keys is setting up monitoring around abnormal usage. With these attacks, the threat actors performed abnormal API calls, which is all detectable with long-tail log analysis.
It’s also imperative to do basic least-privilege analysis so that code running inside or outside the cloud has only the permissions it needs to do its job.
You always want to make sure that you’re monitoring your cloud accounts for abnormal activity in addition to monitoring access keys. In AWS this can look like monitoring various services such as CloudTrail, VPC flow logs and S3 server access logs. If services within your cloud account are being accessed by or reaching out to new and unusual IP addresses over abnormal ports, you want to make sure your monitoring is configured to alert on this activity. Also, if your organization has sensitive data in S3 buckets, monitoring S3 server access logging to note abnormal calls to the bucket helps proactively find attacks.
And finally, the threat actors were able to accomplish all that they did in these cases because of the lack of granular permissions. If these compromised access keys that belonged to IAM Users had fewer permissions, that would have stopped the threat actors in their tracks.
Product Protections
Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200
Prisma Cloud
Prisma Cloud can provide alerting and mitigation solutions for the use-cases reported within this blog in the following ways:
Prisma Cloud Anomaly Policies can be deployed to detect instances running in out of use AWS regions, as well as detecting suspicious IAM credential usage through AI/ML algorithmic functionality.
Prisma Cloud’s Attack Path Policies can also detect lateral movement and privilege escalation attacks against the EC2 instances described within this blog.
Prisma Cloud uses the MITRE ATT&CK framework as the guiding principle for developing detection and risk mitigation capabilities.
Next-Generation Firewalls and Prisma Access With Advanced Threat Prevention
Cortex XDR for cloud provides SOC teams with a full incident story across the entire digital domain by integrating activity from cloud hosts, cloud traffic and audit logs, together with endpoint and network data.
Unit 42 researchers have recently discovered a previously unreported phishing campaign that distributed an infostealer equipped to fully take over Facebook business accounts. Facebook business accounts were targeted with a phishing lure offering tools such as spreadsheet templates for business. This is part of a growing trend of threat actors targeting Facebook business accounts – for advertising fraud and other purposes – which emerged around July 2022 with the discovery of the Ducktail infostealer.
About eight months later, in March 2023, FakeGPT, a new variant of a fake ChatGPT Chrome extension that steals Facebook Ad accounts, was reported. Unit 42 also reported on ChatGPT-themed scam attacks in April 2023. In May 2023, a report from Meta of new information-stealing malware named NodeStealer surfaced, which described malware that was compiled in July 2022 and malicious activity involving NodeStealer that was identified in January 2023. NodeStealer allowed threat actors to steal browser cookies to hijack accounts on the platform, specifically aiming toward business accounts.
While investigating the growing trend, we came across a campaign that started around December 2022, and has not been previously reported.
The infostealer distributed in the campaign shares multiple similarities with the NodeStealer variant compiled in July 2022 that Meta analyzed, which was written in JavaScript. However, the new campaign involved two variants written in Python, improved with additional features to benefit the threat actors. The threat actor equipped these variants with cryptocurrency stealing capabilities, downloader capabilities and the ability to fully take over Facebook business accounts.
NodeStealer poses great risk for both individuals and organizations. Besides the direct impact on Facebook business accounts, which is mainly financial, the malware also steals credentials from browsers, which can be used for further attacks.
In this article, we will shed some light on the unreported phishing campaign targeting Facebook business accounts and will provide a deep dive analysis of the malware. In addition, we will show the execution of the malware through the lens of Cortex XDR (set to detect-only mode). We will provide recommendations for how Facebook business account owners can protect their accounts.
While this specific campaign is no longer active, we have indications that the threat actors behind it may continue to use and evolve NodeStealer or use similar techniques to continue targeting Facebook business accounts. It is also possible that there may be ongoing effects for previously compromised organizations.
Palo Alto Networks customers also receive protections against NodeStealer in the following ways:
Organizations can engage the Unit 42 Incident Response team for specific assistance with this threat and others.
Cortex XDR and XSIAM agents help protect against the threats discussed in this article, providing a multilayer defense that includes behavioral threat protection and exploit protection.
The Advanced WildFire cloud-delivered malware analysis service accurately identifies known samples related to these threats as malicious.
From the telemetry available to us, the main infection vector for the infostealer was a phishing campaign. The phishing campaign took place around December of 2022 and was used for delivering two variants of the stealer, which we will refer to as Variant #1 and Variant #2. The differences between them will be described in the next sections of this article.
The main theme of the campaign was advertising materials for businesses. The threat actor used multiple Facebook pages and users to post information luring victims to download a link from known cloud file storage providers. After clicking on it, a .zip file was downloaded to the machine, containing the malicious infostealer executable.
Figure 1. Facebook phishing post luring victims to download the infected .zip file.
Variant #1 Analysis
The first variant of the infostealer in the campaign was internally named word.exe. It was compiled with Nuitka, and the threat actor used a unique product name for the files: Peguis.
Figure 2. Metadata for word.exe.
Variant #1’s process tree is quite “noisy,” meaning it creates multiple processes and performs many actions that are considered as indications of abnormal activity, and not very clandestine, including pop-up windows presented to the user.
Main Features
As mentioned earlier, NodeStealer targets Facebook business accounts. Variant #1 has some additional features that enable it to do much more than that. Here are the main features of Variant #1:
Stealing Facebook business account information
Downloading additional malware
Disabling Windows Defender via GUI (graphical user interface)
MetaMask (cryptocurrency wallet) theft
Stealing Facebook Business Account Information
The first thing the malware does when executing is check if there is a Facebook business account logged in to the default browser on the infected machine. It does that by connecting to https://business.facebook.com/ads/ad_limits/ and checking the header.
Figure 3. Stealing information using Facebook’s Graph API.
If there is indeed a Facebook business account logged in, the malware connects to the Graph API – graph.facebook.com – with the user ID and the access token stolen from the header.
According to Meta, “The Graph API is the primary way to get data into and out of the Facebook platform. It's an HTTP-based API that apps can use to programmatically query data, post new stories, manage ads, upload photos, and perform a wide variety of other tasks.”
NodeStealer uses the Graph API to steal information about the target, including: followers count, user verification status, account credit balance, if the account is prepaid, and ads information.
The malware also gets the content of a Facebook JavaScript module AdsLWIDescribeCustomersContainer by sending a request to https://www.facebook.com/ajax/bootloader-endpoint/?modules=AdsLWIDescribeCustomersContainer.react.
This JavaScript module is a part of Facebook's advertising platform and is used for describing and managing custom audiences in Facebook Ads. Custom audiences allow advertisers to target specific groups of people based on their demographics, interests, behaviors or other criteria. The malware steals this information and sends it to its command and control server (C2).
In addition to stealing information about the Facebook business account, the malware also aims to steal those accounts credentials. In order to do so, it checks for Facebook users and passwords within the cookies and local databases of the following browsers: Chrome, Edge, Cốc Cốc, Brave and Firefox.
Figure 4. Stealing passwords from browsers’ databases.Figure 5. Alerts for the execution of NodeStealer, as shown in Cortex XDR.
The malware then exfiltrates the output files through Telegram and deletes the files to remove its tracks:
Figure 6. Exfiltration through Telegram.Figure 7. Tracks removal by NodeStealer.
Downloading Additional Malware
Variant #1 is configured to download two .zip files from the following URLs:
hxxps://tinyurl[.]com/batkyc, which redirects to hxxp://adgowin66[.]site/ratkyc/4/bat.zip
hxxps://tinyurl[.]com/ratkyc2, which redirects to hxxp://adgowin66[.]site/ratkyc/4/ratkyc.zip
Bat.zip contains the ToggleDefender batch script that disables Windows Defender, and Ratkyc.zip contains three pieces of malware:
In order to download the .zip files, the malware implements the FodHelper UAC bypass. Using this method, the attackers attempt to bypass User Account Control (UAC) and execute the PowerShell scripts used to download the above-mentioned zip files.
Figure 8. FodHelper UAC bypass encoded command in NodeStealer.
The base64 compressed command translates to the following:
Below is the execution flow of Variant #1, when Cortex XDR is set to detect-only mode:
Figure 9. Execution flow for Variant #1, as shown in Cortex XDR, set to detect-only mode.
After downloading and extracting the files, NodeStealer sets persistence for the three pieces of malware (BitRAT, the hVNC RAT, and XWorm), as well as for its own binary (word.exe), via the registry run keys.
Disabling Windows Defender via GUI
Besides the ToggleDefender batch script, Variant #1 uses another technique to disable Windows Defender, this time using the GUI. This is a very noisy approach, since the end user would be able to see the Windows Defender GUI pop up on the machine and the malware acting to disable it.
The commands used to open the GUI and disable Windows Defender are shown in Figure 10 below.
Figure 10. Commands used to disable Windows Defender.
MetaMask Theft
The malware also tries to maximize financial gain by stealing MetaMask credentials from Chrome, Cốc Cốc and Brave browsers.
MetaMask is an extension for accessing Ethereum Wallets through the browser. Stealing credentials for this application allows the attackers to steal cryptocurrency from the user’s wallets.
Just as it did in stealing Facebook cookies and credentials, the malware extracts the local databases used to store browsers’ information. It searches within them for the extension nkbihfbeogaeaoehlefnkodbefgpgknn, which is the extension of MetaMask when installed directly from the extension store.
Then, the malware copies the data into a file and exfiltrates it using Telegram, in the same fashion it did with the Facebook credentials.
Figure 11. Stealing MetaMask credentials from a Brave browser.
Variant #2 Analysis
The second variant of the infostealer in the campaign was internally named MicrosofOffice.exe and was compiled with Nuitka, same as the first variant. Unlike the first variant, it does not generate a lot of activity visible to the unsuspecting user. For this variant, the threat actor used the product name “Microsoft Coporation” (originally misspelled by the malware authors).
Figure 12. Metadata of Variant #2 masquerading as MicrosofOffice.exe.
Main Features
Like the first variant, Variant #2 targets Facebook business account information and MetaMask wallets, but it goes beyond by:
Attempting to take over the Facebook account
Implementing anti-analysis features
Stealing emails
Taking Over the Facebook Account
Variant #2 attempts to purchase an online email service provided by a legitimate Vietnamese website (hotmailbox[.]me). It attempts to do so using an embedded API key that holds a credit balance for that specific service: https://api.hotmailbox[.]me/mail/buy?apikey=<redacted>&mailcode=HOTMAIL&quantity=1.
Figure 13. Purchasing mailbox service from hotmailbox[.]me.Figure 14. Credit balance for the API key used by the malware.
If the purchase attempt is unsuccessful, the malware tries to purchase a mailbox service from another Vietnamese website (dongvanfb[.]net), again, using an API key that holds a dedicated credit balance — https://api.dongvanfb[.]net/user/buy?apikey=<redacted>&account_type=1&quality=1.
Figure 15. Purchasing mailbox service from dongvanfb[.]net.If the purchase attempt succeeds, the malware saves the email and password for the new mailbox, which will be used in the next phase of the campaign.
Next, the malware modifies the account email address for the Facebook business account of the victim, using a technique that doesn’t require verifying the password using the following URL: https://www.facebook[.]com/add_contactpoint/dialog/submit/.
If needed, the malware sends a request to get the Facebook authentication code via email by sending a request to: https://getcode.hotmailbox[.]me.
Figure 16. Code for requesting the Facebook authentication code from hotmailbox[.]me.The malware then checks the updated email to see if the modification was successful:
Figure 17. Checking the updated email for the Facebook account.
If successful, the attackers have now taken over the Facebook account by replacing the legitimate user’s email address with a mailbox under their control.
Reading Emails
In addition, the malware has a function that parses emails, so it can read the victim’s emails. It is possible that the threat actor added this functionality to potentially interfere with any Facebook alerts notifying the victim of the configuration changes, though we did not directly observe activity of this kind.
Figure 18. Function that is responsible for reading emails.
Anti Analysis and Anti VM
In several samples of Variant #2 that were analyzed, the threat actor added a simple function to check for the presence of several malware analysis tools and virtual machine processes. If one of them is running on the system, the malware terminates itself.
Figure 19. Anti-VM and anti-analysis function.
Differences Between the NodeStealer Variants
As mentioned above, there are similarities between the two variants of NodeStealer analyzed in this article, but there are many differences as well. To put things into order, below is a table that compare the main features of NodeStealer in the version reported by Meta, as well as those found in the different variants:
Table 1. Comparison of NodeStealer and the two variants.
Vietnamese Threat Actor
Interestingly, both Ducktail and NodeStealer were previously suspected by Meta to originate from threat actors based in Vietnam.
The suspected connection between the NodeStealer malware and a Vietnamese threat actor can be explained in different ways.
The first finding that may indicate this connection is that in the Python script of both variants analyzed in this blog, we came across many strings in Vietnamese. For example, see Figures 20 and 21.
Figure 20. Translation of the string “TongChiTieu” found in NodeStealer.Figure 21. Translation of the string “ThoiGianCheck” found in NodeStealer.
The second indication of the suspected connection to threat actors based in Vietnam is that the attackers targeted a browser named Cốc Cốc, which describes itself as “the web browser and search engine for Vietnamese people” on its About Us page.
Figure 22. Wikipedia description for Cốc Cốc software.
The third indication of a suspected Vietnamese connection to NodeStealer was found in Variant #2. This variant, as described earlier in the article, attempts to purchase an online mailbox service from two different Vietnamese websites: Hotmailbox[.]me and Dongvanfb[.]net.
Conclusion
In this article, we uncovered a campaign of the NodeStealer malware that targets Facebook business accounts. As part of the campaign, two variants of NodeStealer were discovered, Variant #1 and Variant #2. Analyzing the two variants revealed some interesting behavior of the malware that includes doing much more than its original intentions, all likely to increase the potential profit for the threat actor.
The threat actor, who is suspected to be of Vietnamese origin, provided the new variants with cryptocurrency stealing capabilities, downloader capabilities and the ability to fully take over Facebook business accounts. The potential damage for both individuals and organizations can be reflected not only in financial loss, but also in reputation damage for a target.
We encourage all organizations to review their protection policies and use the indicators of compromise (IoCs) provided in this report in order to address this threat. Facebook business account owners are encouraged to use strong passwords and enable multifactor authentication. Take the time to provide education for your organization on phishing tactics, especially modern, targeted approaches that play off current events, business needs and other appealing topics.
Protections and Mitigations
SmartScore, a unique ML-driven scoring engine that translates security investigation methods and their associated data into a hybrid scoring system, scored an incident involving NodeStealer an 86 out of 100, as shown in Figure 23. This type of scoring helps analysts determine which incidents are more urgent and provides context about the reason for the assessment, assisting with prioritization.
Figure 23. SmartScore information about an incident involving NodeStealer.
For Palo Alto Networks customers, our products and services provide the following coverage associated with this threat:
WildFire, our cloud-based threat analysis service, accurately identifies the samples as malicious.
Cortex XDR detects user- and credential-based threats by analyzing user activity from multiple data sources, including endpoints, network firewalls, Active Directory, identity and access management solutions, and cloud workloads. It builds behavioral profiles of user activity over time with machine learning. By comparing new activity to past activity, peer activity and the expected behavior of the entity, Cortex XDR detects anomalous activity indicative of credential-based attacks.
Figure 24. End user notification for blocking both NodeStealer variants.
It also offers the following protections related to the attacks discussed in this post:
Prevents the execution of known malicious malware, and prevents the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.
Protects against credential gathering tools and techniques using the new Credential Gathering Protection available from Cortex XDR 3.4.
Cortex XDR Pro detects post-exploit activity, including credential-based attacks, with Cortex Analytics and the ITDR module.
If you think you may have been impacted or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200
Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Update: As of August 23, over the last three weeks this incident has developed with three additional vulnerabilities discovered in Ivanti products. The first in MobileIron Core (CVE-2023-35082; the main topic of this threat brief post when first published in July), a second vulnerability discovered in the Ivanti Avalanche product (CVE-2023-32560), and the third in the Ivanti Sentry product (CVE-2023-38035).
On July 24, 2023, Ivanti Endpoint Manager Mobile (EPMM), previously known as MobileIron Core, publicly disclosed details about an unauthenticated API access zero-day vulnerability. CVE-2023-35078 affects versions 11.10, 11.9 and 11.8, but older versions are also at risk of possible exploitation.
At the time of writing, the only confirmed victims have been Norwegian government agencies. They confirmed their government ministries had been targeted in a cyberattack exploiting this vulnerability, but given the number of potentially vulnerable servers on the internet running this software, it's highly likely that other organizations will or already have fallen victim. Open source reporting indicates that these attacks most likely occurred prior to Ivanti knowing about the vulnerability.
As of July 24, data from our active attack surface management solution, Cortex Xpanse discovered over 5,500 Ivanti Endpoint Manager Mobile servers, spanning multiple versions, were publicly exposed on the internet. The highest number of these exposures were found in Germany, the United States and the United Kingdom.
The regional statistics from this scanning indicate over 80% of these servers reside in western countries and span multiple industry sectors including the following among many others:
Local and national government departments
Healthcare organizations
Law firms and other legal entities
Universities
Banks and financial institutions
Charities
Retail
Update: As of August 23, Unit 42 Xpanse data indicates a fairly consistent total number of Ivanti MobileIron servers on the internet compared to the same analysis three weeks ago. Also noted are hundreds of IP addresses previously showing older, vulnerable versions now with updated versions that should mitigate the known vulnerabilities. However, we also note many internet IP addresses today still serving Ivanti MobileIron and related services reporting potentially vulnerable, not to mention unsupported, versions.
This vulnerability allows unauthenticated users full API access through specific API endpoints. According to the CISA advisory, with this access malicious actors can extract personally identifiable information (PII) and perform administrative actions, like creating new accounts and making configuration changes, without needing any credentials.
Given the global reach of this incident, and the fact that the vulnerability has already been exploited in the wild, organizations should investigate exposures on their network, and remediate as quickly as possible, using the Ivanti-provided product upgrades.
Since the discovery of the Critical vulnerability CVE-2023-35078, another vulnerability with a High CVSS classification has also been reported within the Ivanti Endpoint Manager Mobile application. CVE-2023-35081 is a remote file write vulnerability that requires an authenticated administrator to write files to the compromised server, which could include additional payloads providing further access.
Update: As of August 23, in the past three weeks three additional vulnerabilities in Ivanti products have been announced, as follows:
CVE-2023-35082 allows an attacker remote, unauthenticated API access in MobileIron Core 11.2 and older. This is similar to the original vulnerability in the set – CVE-2023-35078 – but covers some of the older versions of the product.
CVE-2023-32560 allows an attacker to remotely exploit the Ivanti Avalanche software without authentication which could lead to execution of arbitrary code on the vulnerable system.
CVE-2023-38035 is currently being exploited in the wild allowing attackers, via an API authentication bypass vulnerability in the Ivanti Sentry product, to gain access to sensitive admin portal configuration APIs.
Unit 42 recommends that users of the affected software upgrade to the latest versions that include fixes for the vulnerability. It’s especially important to review your network topology to ensure that any public-facing Ivanti Endpoint Manager Mobile services are up-to-date with the latest patch.
For those who can’t upgrade to fixed versions of the software, we also recommend taking precautionary measures to control access to vulnerable servers, and considering restricting access to the public until they can be patched.
Cortex Xpanse customers can identify external facing instances of the application through the “Insecure Ivanti Endpoint Manager Mobile (MobileIron Core)” attack surface rule.
The timeline below provides an overview of the situation to-date.
Of the 5,500 Ivanti Endpoint Manager Mobile servers discovered through Palo Alto Networks Cortex Xpanse data, Figure 1 below shows a subset of those servers that we were able to obtain a product version for, and the count of said version. The Ivanti-supported version numbers are mentioned above. However, as you can see in the figure below, there are many other, older, unsupported versions still publicly exposed on the internet.
Just under a quarter of the servers we could obtain version information for were supported and, despite the partial information, that pattern is quite concerning. This is an important point to make: Software, especially when it’s internet-facing, should be protected and kept up to date.
Figure 1. Chart showing the number of hosts running Ivanti Endpoint Manager Mobile (MobileIron Core), by their versions (where the version was obtainable).
The vulnerability has received a CVSS v.3.0 base score of 10.0, the highest rating possible, and a severity of Critical.
Given the ease of exploitation to the internet-facing application's API, provided as default by each organization running the affected software, there is no so-called proof of concept code required to exploit the vulnerability. It is, unfortunately, as simple as interacting with the system's API using commands (many of which are documented and publically available) to perform various actions within the victim's environment. As described by CISA, such commands can extract PII and perform administrative actions, like creating new accounts and making configuration changes, without needing any credentials.
Details of the Vulnerability: CVE-2023-35081
On July 28, 2023, another vulnerability with a High CVSS classification was reported within the Ivanti Endpoint Manager Mobile application. CVE-2023-35081 is a remote file write vulnerability that requires an authenticated administrator to write files to the compromised server, which could include additional payloads providing further access.
According to Ivanti, there are reports of victims impacted by the new vulnerability used in conjunction with the original vulnerability. The original provides unauthenticated access while the second provides additional capabilities.
This news is somewhat reminiscent of the recent MOVEit vulnerability where, in the weeks following the discovery, both the vendor and security researchers had uncovered additional vulnerabilities perhaps due to the focus drawn by the initial findings.
Current Scope of the Attack: CVE-2023-35078
As Ivanti's public notification about CVE-2023-35078 in their forums states, "If exploited, this vulnerability enables an unauthorized, remote (internet-facing) actor to potentially access users’ personally identifiable information and make limited changes to the server." Furthermore, Ivanti stated they were aware of a very limited number of customers that have been impacted.
Our research shows that a total of 85 countries hosted the 5,500 Ivanti Endpoint Manager Mobile servers on the internet. A dozen or so countries had a single server present at the time of our scan, but many countries had dozens each, if not hundreds. Germany and the United States both had over 1,000 servers.
Figure 2 shows the breakdown of the top 10 countries hosting the highest number of servers.
Figure 2. Chart showing the top 10 countries hosting the highest number of MobileIron Core servers. (Percentages shown in chart cover only the countries shown.)
So far, the only publicly confirmed victims are Norwegian authorities and their government ministries. The attack against them was confirmed to be a zero day and later confirmed to be a vulnerability in Ivantis software. However, it's highly likely that other organizations will have fallen victim as well, given the number of potentially vulnerable servers on the internet running this software.
Interim Guidance
Ivanti recommends for users of their software to upgrade to the latest versions that include fixes for the vulnerability.
Unit 42 recommends reviewing your network topology to ensure that any public-facing Ivanti Endpoint Manager Mobile services are up-to-date with the latest patch. If not, consider restricting access to the public until they can be patched.
Conclusion
Based on the amount of publicly available information, the ease of use and the extreme effectiveness of the exploit for CVE-2023-35078, Palo Alto Networks highly recommends following Ivanti's guidance to protect your organization. Palo Alto Networks and Unit 42 will continue to monitor the situation for updated information and provide evidence of more widespread exploitation, if and when that occurs.
Network-based, and especially internet-facing, services are popular targets for threat actors to exploit and leverage to gain access into an environment. This has happened in the past with MobileIron, as documented by the UK NCSC describing nation-state actors using CVE-2020-15505 to compromise the networks of UK organizations.
The recent news of another vulnerability — CVE-2023-35081 — in the Ivanti Endpoint Manager Mobile application, providing a remote file write capability to an authenticated administrator came quickly after the original vulnerability disclosure. As was seen with the MOVEit vulnerability over the last couple of months, once a significant vulnerability is identified within a piece of software, attention is drawn for security researchers, threat actors and the software vendor in an attempt to uncover additional issues for different motivations.
We will update this threat brief as more relevant information becomes available.
Palo Alto Networks Product Protections for CVE-2023-35078
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200
Cortex Xpanse
Cortex Xpanse customers can identify external facing instances of the application through the “Insecure Ivanti Endpoint Manager Mobile (MobileIron Core)” attack surface rule. The rule is available to all customers with a default state of “On.”
Figure 3. A screenshot of the Cortex Xpanse interface, showing the Insecure Ivanti Endpoint Manager/MobileIron rule enabled.
Within Cortex Xpanse’s Threat Response Center, organizations can also find curated threat intel summaries, exploit consequences, previous exploit activity and links to other sources for additional information. This allows you to see how risk is distributed across your organization and build a remediation plan based on the guidance provided. Cortex Xpanse identifies service owners automatically, so organizations can easily assign a ticket to the right person.
Figure 4. A screenshot of the Cortex Xpanse interface, showing the Threat Summary, including Remediation and Mitigation Suggestions.
On July 18, 2023, Citrix published a security bulletin for vulnerabilities affecting their NetScaler ADC and NetScaler Gateway products. When these appliances are configured as a gateway or authentication server and managed by a customer (i.e., not Citrix-managed) they can be vulnerable to remote code execution initiated by an attacker. Vulnerabilities on Citrix-managed servers have already been mitigated.
Citrix states that they have observed attacks targeting CVE-2023-3519 against appliances that haven’t been patched. The Cybersecurity and Infrastructure Security Agency (CISA) has also released an advisory detailing an attack using this vulnerability.
Palo Alto Networks customers receive protections from and mitigations for CVE-2023-3519 in the following ways:
Cortex Xpanse customers can identify external-facing instances of the application through the “Insecure Citrix Application Delivery Controller” attack surface rule.
Palo Alto Networks also recommends patching against these vulnerabilities, including CVE-2023-3519, with the software update provided by Citrix.
CVE-2023-3519 is a remote code execution (RCE) vulnerability with a CVSS severity score of 9.8 that was disclosed on July 18, 2023. This vulnerability affects older installations of NetScaler ADC (an application delivery controller firmware for securing network traffic) as well as NetScaler Gateway, which is an access gateway that provides VPN and single sign-on (SSO) capabilities for remote end users of network assets.
Additional vulnerabilities covered in this security bulletin affecting NetScaler users include CVE-2023-3466 and CVE-2023-3467. According to Citrix, CVE-2023-3466 is a reflected Cross-Site Scripting (XSS) vulnerability that requires a victim to visit an attacker-controlled link via web browser while the virtual NetScaler appliance is on the same network with connectivity to the NetScaler IP (NSIP).
CVE 2023-3467 is a privilege escalation vulnerability that requires attackers to have unauthenticated access to the NSIP or subnet IP (SNIP) with management interface access, and allows for potential privilege elevation to root administrator access. CVE-2023-3466 and CVE-2023-3467 have severity scores of 8.3 and 8 respectively.
According to Citrix, these three vulnerabilities affect the following versions of Citrix NetScaler ADC and NetScaler Gateway:
NetScaler ADC and NetScaler Gateway 13.1 before 13.1-49.13
NetScaler ADC and NetScaler Gateway 13.0 before 13.0-91.13
NetScaler ADC and NetScaler Gateway version 12.1 (EOL)
NetScaler ADC 13.1-FIPS before 13.1-37.159
NetScaler ADC 12.1-FIPS before 12.1-55.297
NetScaler ADC 12.1-NDcPP before 12.1-55.297
CISA also reports that the appliance requires configuration as a gateway or authentication, authorization and auditing (AAA) server for exploitation. These updates from Citrix patch for all three of the aforementioned vulnerabilities.
Current Scope of the Attack
CISA has reported at least one attack in which a threat actor had exploited this vulnerability as a zero-day exploit, to gain access to a critical infrastructure organization’s NetScaler appliance. For this incident, the threat actor leveraged CVE-2023-3519 to drop a PHP webshell on the targeted appliance.
The threat actor then used the dropped web shell to enumerate and exfiltrate Active Directory data. The threat actor also attempted further discovery activities but failed because the exploited NetScaler appliance was in a segmented environment.
Interim Guidance
Citrix has released a patch for this vulnerability and recommends that all customer managed appliances update as soon as possible. Additionally, CISA released an advisory article with an accompanying document containing information on detection methods, incident response tips, mitigations, and validating security controls for securing your organization against this vulnerability and others like it.
The CISA detection methods include information such as the following:
Instructions for modifying specific parameters regarding your NetScaler appliance installation
Specific commands for checking logs that may contain abnormalities
Guidance on reviewing various network logs that could indicate anomalous Application Delivery Controller (ADC) activity
Their incident response guidance depicts basic steps to quarantine and reimage affected hosts, while provisioning account credentials and reviewing system and network artifacts such as processes, services, and logs.
Based on the amount of publicly available information, Palo Alto Networks highly recommends following CISA’s guidance on mitigations for protecting your organization against CVE-2023-3519, CVE-2023-3466 and CVE-2023-3467. These mitigations include applying vendor-provided patches as well as executing their described detection and mitigation methods in your network environment.
Palo Alto Networks and Unit 42 will continue to monitor the situation for updated information including release of proof-of-concept code or evidence of more widespread exploitation.
Palo Alto Networks customers are protected by our products, as listed below. We will update this threat brief as more relevant information becomes available.
Palo Alto Networks Product Protections for CVE-2023-3519
Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200
Next-Generation Firewalls and Prisma Access With Advanced Threat Prevention
Cortex Xpanse customers can identify external facing instances of the application through the “Insecure Citrix Application Delivery Controller” attack surface rule. The rule is available to all customers with a default state of “On.”
Figure 1. A screenshot of the Cortex Xpanse interface, showing the Insecure Citrix Application Delivery Controller rule enabled.
Within Cortex Xpanse’s Threat Response Center, organizations can also find curated threat intel summaries, exploit consequences, previous exploit activity, and links to other sources for additional information. This allows you to see how risk is distributed across your organization and build a remediation plan based on the guidance provided. Cortex Xpanse identifies service owners automatically, so organizations can easily assign a ticket to the right person.
Figure 2. A screenshot of the Cortex Xpanse interface, showing the Threat Summary, including Remediation and Mitigation Suggestions.
Threat actors seeking new ways to get their creations past victims’ defenses are increasingly turning to sending ransomware through URLs. They are also using increasingly dynamic behaviors to deliver their ransomware. In addition to treading the well-worn path of using polymorphic versions of their ransomware, threat actors often rotate hostnames, paths, filenames or a combination of all three to widely distribute ransomware.
We’ll show our findings on how threat actors are distributing ransomware via URLs, as well as discussing the following aspects of this data:
How threat actors are abusing hosting providers and top level domains
How threat actors are abusing public hosting, social media and sharing services
How threat actors rotate hostnames, paths or filenames in URLs using several case studies
Palo Alto Networks Next-Generation Firewall customers with Advanced URL Filtering and DNS Security subscriptions are protected against malicious ransomware campaigns similar to the ones described in this article. All the mentioned ransomware samples are also covered by WildFire products.
The three most popular methods of delivery for ransomware are through URLs, emails and third-party apps. People encounter ransomware delivered by URLs when they browse a site themselves, or if malware or other software surreptitiously placed on a compromised system accesses it. Ransomware delivered through email arrives as an attachment in the email itself rather than a ransomware URL included in the body of an email.
In 2021, Unit 42 published an article discussing trends in ransomware delivery methods. At that time, email attachments (e.g., SMTP and POP3 protocols) were the most widely-used channel for distributing ransomware. More recently, our analysis of ransomware samples from the entire year of 2022 revealed a shift in the primary entry vector for ransomware infections (as shown in Figure 1). URL or web browsing has emerged as the leading method for ransomware delivery, accounting for over 77% of cases.
Ransomware delivery through emails has decreased in prevalence to be the second most popular method, comprising almost 12% of the total.
Figure 1. Arrival protocols used to deliver ransomware in 2022.
Within the URLs that are used to deliver ransomware, we observed some notable trends including ransomware hosting URLs being used in various polymorphic forms to increase the agility of attacks. For example, threat actors have been observed both rotating different URLs to host the same ransomware (e.g., hxxp://oddsium[.]com/g76dbf and hxxp://clicktoevent[.]com/g76dbf?lrebib=kvqqhaohs) and using the same URL to deliver different ransomware (e.g., rgyui[.]top/dl/build.exe). We discuss various recent tactics in detail in the ransomware campaigns and case studies section below.
Ransomware Family Distributions
We also observed a variety of different families in the traffic we captured with our URL-based ransomware detection service. Figure 2 shows the distribution of the URLs in the top 10 ransomware families we observed in the last quarter of 2022. Lazy and Virlock ransomware, which have been in circulation for years, made up over 50% of the ransomware we observed.
Figure 2. Top 10 ransomware families detected by the URL-based ransomware detection service in 2022.
Web Hosting Infrastructure
Between October and December 2022, our Advanced URL Filtering and DNS Security services detected over 27,000 unique URLs and hostnames hosting ransomware. In this section, we analyze and provide insights into the hosting infrastructure of 7,000 random samples from these ransomware hosting URLs, which consist of 3,335 domains.
Domain Distribution
As we analyzed the hosts of ransomware URLs, we were concerned to see that (as of the end of December 2022) more than 20% of the URLs we observed were still active days or weeks after our detectors flagged them. Most of these URLs are compromised websites, and have likely gone undetected by site owners.
Figure 3 shows the most commonly abused top-level domains (TLDs), where the count shows the number of second level domains (2LDs). Aside from the expected abuse of generic top-level domains (gTLDs) (e.g., .com, .net, .org, .xyz, .top and .mobi) due to them comprising the lion’s share of the domain market, it is noteworthy to observe that attackers also abused country code top-level domains (ccTLDs) including .ru, and .cn, possibly indicating that these countries have less strict policies in place for registration of domains.
Figure 3. Most commonly abused TLDs for hosting ransomware.
Abuse of Public Hosting, Social Media and Sharing Services
Threat actors often abuse, take advantage of or subvert legitimate products for malicious purposes. This does not necessarily imply a flaw or malicious quality to the legitimate product being abused.
Figure 4 shows the most commonly abused public hosting, social media and sharing services. Attackers usually create subdomains or paths under these popular services to reach a wider audience and to stay under the radar. These URLs are likely to fall through the cracks of many existing URL blocking services due to the good reputation involved with these services.
Figure 4. Most commonly abused public hosting, social media and sharing services.
We analyzed the remaining 855 second-level domains hosting ransomware that are not abusing public hosting, social media or sharing services. We observed that 64% (547) of these domains were registered two or more years earlier and, according to passive DNS footprints, these domains were visited on average 215,892 times in the last six months.
Long lived domains coupled with consistently high DNS footprints indicate that these were compromised benign domains. Attackers take advantage of the trust in these websites to slip through people’s defenses.
Ransomware Campaigns and Case Studies
We observed a lot of different threat actors exhibiting differing campaign behaviors within our detections. For some campaigns, the attackers rotated different ransomware files with the same URLs. For other campaigns, the attackers rotated different URLs delivering the same ransomware.
Some attackers rotate both URLs and ransomware files. The same ransomware can be delivered through multiple URLs, and the same URL can deliver multiple ransomware variants, or even other types of malware (e.g., wipers, stealers or loaders).
Rotating Ransomware Using the Same URL
During our analysis of ransomware campaigns, we observed instances where a single URL or a group of URLs consistently delivers ransomware with a different SHA-256 hash value with each visit. This technique likely serves to evade hash-based blocking efforts.
In some cases, a single URL is used to distribute hundreds of distinct versions of ransomware. For example, in one STOP/DJVU ransomware campaign we captured, we identified over 800 different ransomware samples delivered through 14 different URLs.
Example URLs:
miiwes[.]top/dl/buildz.exe
rgyui[.]top/dl/build.exe
rgyui[.]top/dl/build2.exe
rgyui[.]top/dl/buildz.exe
uaery[.]top/dl/build.exe
uaery[.]top/dl/build2.exe
uaery[.]top/dl/buildz.exe
zerit[.]top/dl/build.exe
zerit[.]top/dl/build2.exe
zerit[.]top/dl/buildz.exe
ex3mall[.]com/files/1/build3.exe
spaceris[.]com/files/1/build3.exe
bihsy[.]com/files/1/build3.exe
ugll[.]org/files/1/build3.exe
SHA-256 hashes for example ransomware files delivered:
We also observed that some of the attackers use stealers and loaders (e.g., Racoon Stealer and Smoke Loader) as the initial stepping stones for the ransomware attack. With stealers deployed on a compromised environment, ransomware actors are enabled to get access to the environment.
Below is one loader campaign we identified, which is associated with the ransomware campaign above.
For example, the loader with SHA-256 4e1f743b60d65732d43e6a8c064016369a2cb6d03e81e04e114ed6a31297a2a7 is delivered through https://privacy-tools-for-you-780[.]com/downloads/toolspab3.exe. During execution, it contacts zerit[.]top/dl/buildz.exe from the above ransomware campaign to load ransomware binaries.
Similar to the ransomware delivery campaign above, the attacker keeps rotating the loader samples with a limited number of URLs. One URL could trigger the download of hundreds of different loader samples when visited at different times.
We observed that all the domains are registered with the same email radamir[.]ramiev@gmail[.]com. Using this information allowed us to identify other malicious infrastructure and malware delivery URLs related to this activity.
While most of the URLs mentioned above are hosted on public cloud infrastructure, the attacker is using geographically distributed locations, such as 34[.]69[.]12[.]51 (in Iowa), 34[.]65[.]61[.]83 (in Europe) and 34[.]106[.]70[.]53 (in Utah), possibly to increase the coverage and agility of the attack.
All of these domains are also related to a threat actor called superstar75737 who sold access to Raccoon Stealer logs on a Russian-speaking cybercrime forum, exploit[.]in, in November 2022.
Example SHA-256 hash values of the malware delivered by this campaign:
Another tactic frequently used by attackers is to distribute the same ransomware binary from different hostnames. It’s possible that this is done to avoid static blocklist-based URL blocking services and to evade takedown.
The following example shows a campaign (TeslaCrypt) that uses this tactic, possibly to evade detection.
Example URLs for the first campaign with the same SHA-256:
This sample was originally observed in 2016. However, it is still being actively reused with new delivery URLs.
Conclusion
As ransomware operators continue to probe victim’s defenses using a revolving set of tactics, these threats require a defense-in-depth strategy where both binaries and URLs are analyzed to proactively detect ransomware to keep networks secure.
We observed a wide variety of tactics threat actors used to distribute ransomware on the web. Ransomware binaries are often delivered from compromised websites, which should serve as a reminder for site administrators to maintain up-to-date web applications to minimize the impact of known vulnerabilities.
Since its inception in October 2022, the Palo Alto Networks Advanced URL Filtering and DNS Security product releases have automatically blocked over 2,000 sessions involving ransomware URLs daily. Our models also detect over 600 ransomware URLs per day.
In fact, over 49% of those ransomware URLs detected by our service are blocked from our customer traffic before reaching their devices. This indicates that our detectors identify active ransomware that is currently in circulation.
Our recent product release of a ransomware category of URLs is part of a continuous effort by Palo Alto Networks to secure our customers by more deeply analyzing URLs. This adds to the portfolio of static/dynamic analysis and deep learning-based detection of ransomware capabilities we already provide.
We have also trained a deep-learning model to identify ransomware based on the lexical patterns in the URLs. The model can search for words or chunks of text that frequently appear in malicious campaigns.
An added benefit of using these lexical similarities is that newly detected ransomware URLs can be traced back to patterns in the training samples. This serves as an explanation for detections and helps to identify campaigns of newly detected URLs.
Palo Alto Networks Next-Generation Firewall customers with Advanced URL Filtering and DNS Security subscriptions are protected against malicious ransomware campaigns similar to the ones described in this blog. All the mentioned ransomware samples are also covered by WildFire products.
Acknowledgments
We would like to thank Kyle Wilhoit and Doel Santos for their assistance in verifying ransomware samples and for their valuable feedback. We would also like to thank Billy Melicher, Alex Starov, Wenjun Hu, Billy Hewlett and Daiping Liu for their valuable feedback and support.
Mallox (aka TargetCompany, FARGO and Tohnichi) is a ransomware strain that targets Microsoft (MS) Windows systems. It has been active since June 2021, and is notable for exploiting unsecured MS-SQL servers as a penetration vector to compromise victims' networks.
Recently, Unit 42 researchers have observed an uptick of Mallox ransomware activities – with an increase of almost 174% compared to the previous year – exploiting MS-SQL servers to distribute the ransomware. Unit 42 incident responders have observed Mallox ransomware using brute forcing, data exfiltration and tools such as network scanners. In addition, we have found indications that the group is working on expanding their operations and recruiting affiliates on hacking forums.
Palo Alto Networks customers receive protections from Mallox ransomware and the techniques discussed in this blog through Cortex XDR, which provides a multilayer defense that includes behavioral threat protection and exploit protection.
Video showing Cortex preventing the execution of the Mallox ransomware.
Mallox ransomware, like many other ransomware threat actors, follows the double extortion trend: stealing data before encrypting an organization’s files, and then threatening to publish the stolen data on a leak site as leverage to convince victims to pay the ransom fee.
Figure 1 below displays the Mallox ransomware website on the Tor browser. Though the organizations’ names and logos have been redacted, this is how the group displays the leaked data of its targets.
Figure 1. Mallox website on Tor browser.
Each victim is given a private key to interact with the group and negotiate terms and payment. Figure 2 below presents the chat used for communicating with the group.
Figure 2. Mallox private chat Tor website.
The Mallox ransomware group claims hundreds of victims. While the actual number of victims remains unknown, our telemetry indicates dozens of potential victims worldwide, across multiple industries, including manufacturing, professional and legal services, and wholesale and retail.
Since the beginning of 2023, there has been a constant uptick in Mallox activities. According to our telemetry and data collected from open threat intel sources, in 2023, there has been an increase of approximately 174% in Mallox attacks compared to the latter half of 2022 (see Figure 3).
Figure 3. Mallox attack attempts from the second half of 2022 to the first half of 2023, based on Palo Alto Networks' telemetry.
Initial Access
Since its emergence in 2021, the Mallox group has kept the same approach to gaining initial access: The group targets unsecured MS-SQL servers to infiltrate a network. These attacks start with a dictionary brute force attack, trying a list of known or commonly used passwords against the MS-SQL servers. After gaining access, the attackers use a command line and PowerShell to download the Mallox ransomware payload from a remote server (see Figure 4).
Figure 4. Example of an alert raised in response to a Mallox ransomware dictionary brute force attack, as raised by Cortex XDR and XSIAM.
A command line example used for a Mallox ransomware infection:
Downloads the ransomware payload from: hxxp://80.66.75[.]36/aRX.exe, and saves it as tzt.exe
Runs a PowerShell script named updt.ps1
The payload then goes on to do the following (not pictured in the command line script shown above):
Downloads another file named system.bat, and saves it as tzt.bat
The tzt.bat file is used to create a user named SystemHelp and enable the remote desktop (RDP) protocol
Executes the ransomware payload tzt.exe using Windows Management Instrumentation (WMI)
Figure 5 below shows how Cortex XDR and XSIAM detect one of the first phases of the SQL server exploitation, as described above.
Figure 5. SQL server exploitation process tree, as shown by Cortex XDR and XSIAM (set to detect-only mode for testing purposes).
Ransomware Execution
Before any encryption takes place, the ransomware payload attempts multiple actions to ensure successful execution of the ransomware, such as:
Attempts to stop and remove SQL-related services using sc.exe and net.exe (see the Appendix for the full command line). This way, the ransomware can access and encrypt the victim’s file data.
Attempts to delete volume shadows, making it harder to restore files once they are encrypted. See Figure 6 for how this alert appears in Cortex XDR and XSIAM.
Figure 6. Alert for deleting shadow copies, raised by Cortex XDR and XSIAM.
Attempts to clear the application, security, setup and system event logs using Microsoft’s wevtutil command line utility to thwart detection and forensic analysis efforts.
Modifies file permission using the Windows built-in takeown.exe command, denying access to cmd.exe and other key system processes.
Prevents the system administrator from manually loading the System Image Recovery feature using bcdedit.exe.
Attempts to terminate security-related processes and services using taskkill.exe to evade security solutions.
Attempts to bypass the Raccine anti-ransomware product, if present, by deleting its registry key. See Figure 7 for an example of this process.
Figure 7. Deleting the Raccine registry key.
In Figure 8, some of these mentioned activities are shown in the process tree of the ransomware:
Figure 8. A full process tree of the attack, as shown by Cortex XDR and XSIAM (set to detect-only mode for testing purposes).
This investigated sample of Mallox ransomware encrypts files using the ChaCha20 encryption algorithm and appends the .malox extension for the encrypted files. Other file extensions observed were: .FARGO3, .exploit, .avast, .bitenc and .xollam, in addition to the use of victims’ names as the extension. See Figure 9 for an example of encrypted files in Cortex XDR.
Figure 9. Examples of files encrypted by Mallox ransomware, as detected by Cortex XDR (set to detect-only mode).
Mallox leaves a ransom note in every directory on the victim’s drive. This ransom note explains the infection and provides contact information. Figure 10 is an example of one of these ransom notes.
Figure 10. Example of Mallox ransom note.After execution, the malware deletes itself.
Growing Potential
According to one of its members – as stated in an interview in January 2023 – Mallox is a relatively small and closed group. However, the group appears to be working to expand its operations by recruiting affiliates.
A few days after this interview, a user named Mallx posted on the hacking forum RAMP that the Mallox ransomware group was recruiting affiliates for a new Mallox ransomware-as-a-service (RaaS) affiliate program, as shown in Figure 11.
Figure 11. User Mallx's post on RAMP.
Back in May 2022, a user named RansomR posted on the well-known hacking forum nulled[.]to that the Mallox group was looking for affiliates to join the team. As of June 2023, the option to join is still relevant, according to the comments in the thread.
Figure 12. RansomR's post on Nulled.
If recruitment efforts for their affiliate program succeed, the Mallox group might expand its reach to target more organizations.
Conclusion
The Mallox ransomware group has been more active in the past few months, and their recent recruiting efforts may enable them to attack more organizations if the recruitment drive is successful.
Organizations should implement security best practices and be prepared to defend against the ongoing threat of ransomware. This is true not only for Mallox ransomware but for other opportunistic criminal groups as well.
The Unit 42 team recommends making sure that all internet-facing applications are configured properly and all systems are patched and up to date wherever possible. These measures will help to reduce the attack surface, thereby limiting the exploitation techniques available to attackers.
Deploy an XDR/EDR solution to perform in-memory inspection and detect process injection techniques. Perform threat hunting, looking for signs of unusual behavior related to security product defense evasion, service accounts for lateral movement and domain administrator-related user behavior.
Protections and Mitigations
Palo Alto Networks Cortex XDR detects and prevents file manipulation and other activities performed by Mallox ransomware.
Figure 13. End user notification for blocking the Mallox execution.Figure 14. Alert for suspicious file modification, raised by the Cortex XDR and XSIAM (set to detect-only mode for testing purposes).
SmartScore, A unique ML-driven scoring engine that translates security investigation methods and their associated data into a hybrid scoring system, scored an incident involving Mallox ransomware at 100, which is its highest level of severity (Figure 15). This type of scoring helps analysts determine which incidents are more urgent and provides context about the reason for the assessment, assisting with prioritization.
Figure 15. SmartScore information about a Mallox ransomware incident.
For Palo Alto Networks customers, our products and services provide the following coverage against Mallox ransomware:
WildFire cloud-based threat analysis service identifies the known samples as malicious.
Cortex XDR detects user and credential-based threats by analyzing user activity from multiple data sources, including endpoints, network firewalls, Active Directory, identity and access management solutions, and cloud workloads. Cortex XDR also builds behavioral profiles of user activity with machine learning. By comparing new activity to past activity, peer activity and the expected behavior, Cortex XDR detects anomalous activity indicative of credential-based attacks. Cortex XDR also offers the following protections related to the attacks discussed in this post:
Prevents the execution of known malicious malware, and prevents the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.
Protects against credential gathering tools and techniques using the new Credential Gathering Protection available from Cortex XDR 3.4.
Protects from threat actors dropping and executing commands from webshells using Anti Webshell Protection as of Cortex XDR 3.4.
Protects against exploitation of different vulnerabilities, including ProxyShell, ProxyLogon and OWASSRF, using the Anti-Exploitation modules as well as Behavioral Threat Protection.
If you think you may have been impacted or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200
Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Appendix
Command line Used by Mallox To Stop and Remove SQL-Related Services
"C:\Windows\System32\cmd.exe" / C sc delete "MSSQLFDLauncher" && sc delete "MSSQLSERVER" && sc delete "SQLSERVERAGENT" && sc delete "SQLBrowser" && sc delete "SQLTELEMETRY" && sc delete "MsDtsServer130" && sc delete "SSISTELEMETRY130" && sc delete "SQLWriter" && sc delete "MSSQL$VEEAMSQL2012" && sc delete "SQLAgent$VEEAMSQL2012" && sc delete "MSSQL" && sc delete "SQLAgent" && sc delete "MSSQLServerADHelper100" && sc delete "MSSQLServerOLAPService" && sc delete "MsDtsServer100" && sc delete "ReportServer" && sc delete "SQLTELEMETRY$HL" && sc delete "TMBMServer" && sc delete "MSSQL$PROGID" && sc delete "MSSQL$WOLTERSKLUWER" && sc delete "SQLAgent$PROGID" && sc delete "SQLAgent$WOLTERSKLUWER" && sc delete "MSSQLFDLauncher$OPTIMA" && sc delete "MSSQL$OPTIMA" && sc delete "SQLAgent$OPTIMA" && sc delete "ReportServer$OPTIMA" && sc delete "msftesql$SQLEXPRESS" && sc delete "postgresql-x64-9.4" && rem Kill "SQL" && taskkill - f - im sqlbrowser.exe && taskkill - f - im sqlwriter.exe && taskkill - f - im sqlservr.exe && taskkill - f - im msmdsrv.exe && taskkill - f - im MsDtsSrvr.exe && taskkill - f - im sqlceip.exe && taskkill - f - im fdlauncher.exe && taskkill - f - im Ssms.exe && taskkill - f - im SQLAGENT.EXE && taskkill - f - im fdhost.exe && taskkill - f - im fdlauncher.exe && taskkill - f - im sqlservr.exe && taskkill - f - im ReportingServicesService.exe && taskkill - f - im msftesql.exe && taskkill - f - im pg_ctl.exe && taskkill - f - im postgres.exe
On July 11, 2023, Unit 42 cloud researchers discovered a new peer-to-peer (P2P) worm we call P2PInfect. Written in Rust, a highly scalable and cloud-friendly programming language, this worm is capable of cross-platform infections and targets Redis, a popular open-source database application that is heavily used within cloud environments. Redis instances can be run on both Linux and Windows operating systems. Unit 42 researchers have identified over 307,000 unique Redis systems communicating publicly over the last two weeks, of which 934 may be vulnerable to this P2P worm variant. While not all of the 307,000 Redis instances will be vulnerable, the worm will still target these systems and attempt the compromise.
The P2PInfect worm infects vulnerable Redis instances by exploiting the Lua sandbox escape vulnerability, CVE-2022-0543. While the vulnerability was disclosed in 2022, its scope is not fully known at this point. However, it is rated in the NIST National Vulnerability Database with a Critical CVSS score of 10.0. Additionally, the fact that P2PInfect exploits Redis servers running on both Linux and Windows operating systems makes it more scalable and potent than other worms. The P2P worm observed by Unit 42 researchers serves as an example of a serious attack threat actors could conduct using this vulnerability.
P2PInfect exploits CVE-2022-0543 for initial access and then drops an initial payload that establishes P2P communication to a larger P2P network. Once the P2P connection is established, the worm pulls down additional malicious binaries such as OS-specific scripts and scanning software. The infected instance then joins the P2P network to provide access to the other payloads to future compromised Redis instances.
Exploiting CVE-2022-0543 in this way makes the P2PInfect worm more effective at operating and propagating in cloud container environments. This is where Unit 42 researchers discovered the worm by it compromising a Redis container instance within our HoneyCloud environment, which is a set of honeypots that we use to identify and study novel cloud-based attacks across public cloud environments.
Unit 42 believes this P2PInfect campaign is the first stage of a potentially more capable attack that leverages this robust P2P command and control (C2) network. There are instances of the word “miner” within the malicious toolkit of P2PInfect. However, researchers did not find any definitive evidence that cryptomining operations ever occurred. Additionally, the P2P network appears to possess multiple C2 features such as “Auto-updating” that would allow the controllers of the P2P network to push new payloads into the network that could alter and enhance the performance of any of the malicious operations. Unit 42 researchers will continue to monitor for changes and update accordingly.
Palo Alto Networks customers receive protections against the types of threats discussed in this article through products including:
Unit 42 discovered the first known instance of P2PInfect on July 11, 2023, using our HoneyCloud environment, which is a set of honeypots that we use to identify and study novel cloud-based attacks across public cloud environments.
The P2PInfect worm uses a P2P network to support and facilitate the transmission of malicious binaries. We chose the name because the term P2PInfect appears in the leaked symbols reflecting the malware author project structure, as shown in Figure 1.
Figure 1. Artifacts of the Windows version, names and Redis module.
All collected samples of the P2P worm are written in Rust, a highly scalable and cloud-friendly programming language. This allows the worm to be capable of cross-platform infections that target Redis instances on both Linux and Windows operating systems (please note that Redis does not officially support the Windows OS).
The worm infects vulnerable Redis instances using the Lua sandbox escape vulnerability, CVE-2022-0543. The first exploit for this particular vulnerability was published in March 2022, which resulted in the connection of the infected Redis instance to the Muhstik botnet. However, the P2PInfect worm appears to be associated with a different malicious network, not known to be related to the Muhstik botnet.
After initial infection through the exploitation of the Lua vulnerability, an initial payload is executed that establishes a P2P communication to the larger C2 botnet, which serves as a P2P network for delivering other payloads to future compromised Redis instances. Once the P2P connection is established, the worm pulls down additional payloads, such as a scanner. The newly infected instance then joins the ranks of the P2P network to provide scanning payloads to future compromised Redis instances.
Exploiting CVE-2022-0543 makes P2PInfect effective in cloud container environments. Containers have a reduced set of functionalities – for example, they do not have “cron” services. Many of the most active worms exploiting Redis use a technique to achieve remote code execution (RCE) using cron services. This technique does not work in containers. P2PInfect incorporates the exploit for CVE-2022-0543 with the intention of covering as many vulnerable scenarios as possible, including cloud container environments.
Since the P2PInfect worm is newly discovered, we have focused here on providing an overview of its behavior and the P2P architecture it supports, as well as basic sample analysis. However, additional analysis and study is warranted in future research.
Exploitation of CVE-2022-0543
P2PInfect currently exploits the Lua sandbox escape vulnerability CVE-2022-0543 for initial access. This vulnerability has been used in previous attacks such as Muhstik and Redigo, both of which resulted in the compromised Redis instances participating in denial-of-service (DoS), flooding and brute-forcing attacks against other systems.
This exploit vector follows a similar pattern to what has been seen previously. However, the post-exploit operations of P2PInfect are significantly different from the previous uses of the vulnerability. It is important to note that this vulnerability is not a Redis application vulnerability — it is specifically a Lua sandbox vulnerability.
How P2PInfect Leverages CVE-2022-0543 to Infect Vulnerable Redis Instances
The P2PInfect worm’s initial infection vector – exploiting Redis through CVE-2022-0543 – is not common among other cryptojacking-focused worms known to target Redis instances, such as those created by Adept Libra (aka TeamTnT), Thief Libra (aka WatchDog) threat actors or the ones delivering Money Libra (aka Kinsing) variants. These groups use alternative Redis vulnerabilities or misconfigurations in order to operate.
CVE-2022-0543 is a vulnerability with the Lua library related to the way Redis is packaged and delivered by Debian Linux package management. As such, it only affects users of Redis who use the Debian or derived (Ubuntu and others) distributions. Due to the focus on the OS and leveraging a subcomponent of Redis to compromise, P2PInfect’s exploitation efforts are therefore complex. Figure 2 shows an example of a captured exploit for CVE-2022-0543.
Figure 2. Example of the P2PInfect exploit on the Debian OS.
Within the above image, one can see how the vulnerability is being weaponized. By using network requests through /dev/tcp, as seen on line four, the threat actor connects to a C2 IP address, written as ip-cnc over port 60100. Port 60100 is one of the P2P communication ports used by P2PInfect to maintain C2 communication. The initial payload, also seen on line four, sets the GET request to the directory /linux, which is the main dropper maintaining the core functionality of the P2PInfect worm. Other binaries are distributed within the P2P network, as we are going to see later in the article.
Network Communication Behavior
P2PInfect uses its P2P network to distribute follow-up malware to newly infected systems or cloud instances. When a system is first compromised, it will make a network connection to the P2P network and download the samples for the custom protocol to be used. As Figure 3 illustrates, the command: GET /linux, is followed by the image download of the core P2PInfect functionality.
Figure 3. Network communication protocol displaying the download of P2PInfect.
Both Linux and Windows OS P2PInfect samples communicate in the same manner. The following samples were downloaded from the P2P network in plaintext: linux, miner, winminer and windows (see Figure 4).
Figure 4. List of the malware samples pulled from the P2P network.
Once the core P2PInfect sample finishes execution, the payload will start scanning for additional hosts to compromise. The scanning operation focuses on exposed Redis hosts. However, researchers also found that compromised Redis instances also perform scanning attempts over port 22, SSH. While it is not clear why this scanning operation is taking place, as there are no known exploitation attempts by P2PInfect to compromise SSH, it is not altogether uncommon for port 22 to be scanned post-compromise by other known worms. Please see the Scanning Behavior section for additional details.
Node Communications
The main dropper communicates with any other listening P2P members on the current list of configured nodes using TLS 1.3. The C2 infrastructure is updated when the compromised node sends a json request with all known nodes to the P2P network. Updates to the C2 infrastructure will automatically be downloaded. The following image, Figure 5, shows an example of the nodes update.
Figure 5. P2P nodes update.
The values with x.x.x.x are the current node IP, or the new learned nodes.
Scanning Behavior
Figure 6 illustrates the network scanning behavior of an infected host scanning for exposed SSH instances. These scanning operations occur across a random netrange selected by the P2PInfect functionality.
Figure 6. Scanning traffic for SSH instances.
Figure 7 illustrates the P2PInfect scanning operations for exposed Redis instances.
Figure 7. Scanning traffic for Redis instances.
Other Observations of P2PInfect
Some of the initial payload P2PInfect samples delivered to exploited systems were packed with UPX, while the second-stage malware samples, miner and winminer, were not UPX packed.
After the first dropper runs, it starts decrypting the configuration received from a command line, with information about other nodes in the P2P network. We found that the P2P port was variable – a design choice that allows the attack to be resilient to blocking and network firewall mitigation techniques (see Figure 8).
Figure 8. Example of the variable port usage of P2PInfect.
All samples identified by Unit 42 researchers have been written in Rust, and some have “symbols leaked” inside, which gives indicators about the malware authors’ project structure. For example, the windows sample main execution thread leaks the name of the project as well as the file directory usage of the threat actor (see Figure 9).
Figure 9. Analysis pulled from the core Windows P2PInfect sample.
We also identified a PowerShell script designed to establish and maintain communication between the compromised host and the P2P network. The PowerShell script leveraged the encode command to obfuscate the communication initiation (see Figure 10).
Figure 10. Obfuscated PowerShell command to establish P2P network connection.
One of the first operations performed by the PowerShell command is to configure the local system firewall to block legitimate access to or from the compromised Redis application (see line five of Figure 11). Then (starting on line 17 in Figure 11), the script opens a communication port for the threat actor to access the compromised instance. This is a form of persistence, allowing the threat actors to maintain access to the infected host and keep it operable.
Figure 11. Modifying the network traffic rules of a compromised Windows instance.
Of note from the decoded PowerShell, shown in Figure 11, are the following firewall configuration settings:
Peer-to-peer port is 60102 – this port is variable, as not all nodes use the same port
Redis port 6379 is only allowed to connect known C2 IPs
The firewall rule is named Microsoft Sync
The Monitor Process
Another interesting feature of the initial P2PInfect payload when running in Windows OS is a process called the Monitor. The Monitor process fulfills the role of maintaining the functionality of the P2PInfect running processes on the infected host. The Monitor is dumped to C:\Users\username\AppData\Local\Temp\cmd.exe (see Figure 12 for an example of the Monitor (cmd.exe) enumerating system running processes).
Figure 12. The P2PInfect Monitor sample, cmd.exe process tree.
After launching the Monitor (cmd.exe), the initial P2PInfect payload downloads new versions of itself from the P2P network and persists them with random names into the same original folder and an encrypted configuration is dropped (.conf) (see Figure 13).
Figure 13. Example of the random filenames.
The new P2PInfect download versions are executed, and the scanning operations to locate additional vulnerable Redis instances starts. The initial P2PInfect dropper will attempt to delete itself (see Figure 14).
Figure 14. Deletion of the core P2PInfect payload.
Conclusion
The P2PInfect worm appears to be well designed with several modern development choices. Key among these is the use of the Rust language, which provides resilient capabilities and the flexibility to allow the worm to rapidly spread across multiple operating systems.
The design and building of a P2P network to perform the auto-propagation of malware is not something commonly seen within the cloud targeting or cryptojacking threat landscape. At the same time, we believe it was purpose-built to compromise and support as many Redis vulnerable instances as possible across multiple platforms.
We have caught several samples within our HoneyCloud platform, across multiple geographic regions, and we strongly believe the number of P2P nodes is growing. This is due to the volume of potential targets – over 307,000 Redis instances communicating publicly over the last two weeks – and since the worm was able to compromise multiple of our Redis honeypots across disparate regions. However, we don't have an estimate yet of how many nodes exist or how fast the malicious network associated with P2PInfect is growing.
We recommend that organizations monitor all Redis applications, both on-premises and within cloud environments, to ensure they do not contain random filenames within the /tmp directory. Additionally, DevOps personnel should continually monitor their Redis instances to ensure they maintain legitimate operations and maintain network access. All Redis instances should also be updated to their latest versions or anything newer than redis/5:6.0.16-1+deb11u2, redis/5:5.0.14-1+deb10u2, redis/5:6.0.16-2 and redis/5:7.0~rc2-2.
Palo Alto Networks customers receive protections against the types of threats in the following ways:
Prisma Cloud is capable of identifying the runtime environment of any cloud Redis instance to ensure it detects and prevents the unknown and malicious execution of the P2PInfect worm.
The Advanced WildFire cloud-delivered malware analysis service accurately identifies known samples as malicious.
If you think you might have been impacted or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200
Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
With July's Patch Tuesday release, Microsoft disclosed a zero-day Office and Windows HTML Remote Code Execution Vulnerability, CVE-2023-36884, which it rated "important" severity. Microsoft has observed active in-the-wild exploitation of this vulnerability using specially crafted Microsoft Office documents. It should be noted that exploitation requires the user to open the malicious document.
Unit 42 Threat Intelligence can confirm that this vulnerability has been utilized since at least July 3, 2023. Further analysis is being conducted; an update will be made to this Threat Brief as the analysis is completed.
Microsoft has released a patch for Microsoft Office that stops the attack chain leading to execution of this vulnerability. For those unable to patch, they recommend blocking Office applications from creating child processes or setting FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION registry key to avoid exploitation. See the Security Updates page for more information.
Palo Alto Networks customers receive protections from and mitigations for CVE-2023-36884 in the following ways:
Organizations can engage the Unit 42 Incident Response team for specific assistance with this threat and others.
Cortex XDR and XSIAM agents help protect against post-exploitation activities associated with exploitation of CVE-2023-36884 as well as use Local Analysis detections for RomCom binaries on Windows environments.
Cortex XDR blocks the publicly known exploit chain for CVE-2023-36884.
Advanced WildFire can help detect and prevent attacks involving highly evasive malware.
Next-Generation Firewall with Advanced Threat Prevention security subscriptions can help block associated payloads and attack.
Cloud-Delivered Security Services can categorize C2 domains associated with this activity as malicious.
Unit 42 will continue to monitor the situation for updated information, release of proof-of-concept code and evidence of more widespread exploitation. This brief will be updated as more information on the vulnerability and mitigations becomes available.
With July's Patch Tuesday release, Microsoft disclosed a zero-day Office and Windows HTML Remote Code Execution Vulnerability, CVE-2023-36884, which it rated “important” severity. Microsoft has observed active in-the-wild exploitation of this vulnerability using specially crafted Microsoft Office documents.
It should be noted that all exploitation examples seen so far require the user to open a malicious document. After the user opens the malicious document, it downloads a file containing a script that initiates an iframe injection resulting in the download of a malicious payload. It is not currently clear whether the underlying vulnerability is reliant on office documents for delivery. It is possible the vulnerability could be exploited using other, yet to be seen, delivery mechanisms. For example, Microsoft’s security advisory includes a mitigation that recommends adding wordpad.exe as one of nine applications under a registry key that would block urls using the file: protocol originating from untrusted zones, such as the Internet zone or Restricted Sites zone.
Current Scope of the Attack
Unit 42 Threat Intelligence can confirm that this vulnerability has been utilized since at least July 3, 2023. Early exploitation of this vulnerability includes the use of the RomCom malware, which was reported by Microsoft on July 11, 2023. RomCom, originally observed by Unit 42 in May 2022, is a low-volume malware family that was historically observed in various attacks throughout the past year, including ransomware attacks, as well as targeted espionage-related attacks. The malware acts as a Remote Access Trojan (RAT), and provides an attacker with various capabilities including, but not limited to, directory listings, filesystem modifications, uploading and downloading files, and execution of processes.
Interim Guidance
Microsoft recommends blocking Office applications from creating child processes or setting the FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION registry key to avoid exploitation. See the Security Updates page for more information.
Conclusion
Based on the amount of publicly available information and current research and analysis, Palo Alto Networks highly recommends applying the patch for Microsoft Office to protect your organization. Palo Alto Networks and Unit 42 will continue to monitor the situation for updated information, release of proof-of-concept code and evidence of more widespread exploitation.
Palo Alto Networks customers are protected by our products and services, as listed below. We will update this threat brief as more relevant information becomes available.
Palo Alto Networks has shared our findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Palo Alto Networks Product Protections for CVE-2023-36884
Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat.
Unit 42 Incident Response
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200
Advanced Wildfire
Advanced WildFire uses multiple techniques (Automated Unpacking, Dependency Emulation, Run-Time Memory Analysis, Machine Learning, Static Analysis, Dynamic Analysis, Heuristic Analysis, and others) to detect and protect against RomCom and other highly evasive malware and variants of such.
Next-Generation Firewalls and Prisma Access With Advanced Threat Prevention
Cloud-Delivered Security Services for the Next-Generation Firewall
Command and control (C2) domains associated with this malicious activity are categorized as malicious byAdvanced URL Filtering and DNS Security.
Cortex XSOAR
Cortex XSOAR has released a response pack and playbook for CVE-2023-36884 to help automate and speed the mitigation process.
This playbook automates the following tasks:
Indicators of compromise (IoC) downloads and hunting
Threat hunting queries related to behavior identified as part of exploitation patterns
Microsoft mitigation actions
The playbook can be triggered manually or run as a job.
Cortex XDR and XSIAM
Cortex XDR and XSIAMagents help protect againstpost-exploitation activities described in this article using Behavioral Threat Protection, the multiple protection modules and detect suspicious activity using Cortex Analytics as well as using Local Analysis detections for RomCom binaries on Windows environments. Cortex XDR blocks the publicly known exploit chain for CVE-2023-36884.
Updated July 13, 2023, at 3:00 p.m. PT to add Advanced Wildfire protections information.
Updated July 13, 2023, at 8:45 p.m. PT to note status of patch and detection guidance.
Updated July 14, 2023, at 11:58 a.m. PT to add protections information for Next-Generation Firewall and Cloud-Delivered Security Services. Cortex XDR and XSIAM protections information was updated. Details, attack scope, interim guidance, and threat hunting queries were added. IoCs are now listed.
Updated July 17, 2023, at 4:15 p.m. PT to add Cortex XSOAR information.
Updated August 9, 2023, at 10:35 a.m. PT to include patch released by Microsoft.
Updated August 10, 2023, at 10:25 a.m. PT to include additional Cortex XDR protections.
Russia’s Foreign Intelligence Service hackers, which we call Cloaked Ursa (aka APT29, UAC-0004, Midnight Blizzard/Nobelium, Cozy Bear) are well known for targeting diplomatic missions globally. Their initial access attempts over the past two years have predominantly used phishing lures with a theme of diplomatic operations such as the following:
These types of lures are generally sent to individuals who handle this type of embassy correspondence as part of their daily jobs. They are meant to entice targets to open the files on behalf of the organization they work for.
Recently, Unit 42 researchers observed instances of Cloaked Ursa using lures focusing on the diplomats themselves more than the countries they represent. We have identified Cloaked Ursa targeting diplomatic missions within Ukraine by leveraging something that all recently placed diplomats need – a vehicle.
We observed Cloaked Ursa targeting at least 22 of over 80 foreign missions located in Kyiv. While we don’t have details on their infection success rate, this is a truly astonishing number for a clandestine operation conducted by an advanced persistent threat (APT) that the United States and the United Kingdom publicly attribute to Russia’s Foreign Intelligence Service (SVR).
Our assessment that Cloaked Ursa is responsible for these lures is based on the following:
Similarities to other known Cloaked Ursa campaigns and targets
Use of known Cloaked Ursa TTPs
Code overlap with other known Cloaked Ursa malware
These unconventional lures are designed to entice the recipient to open an attachment based on their own needs and wants instead of as part of their routine duties.
The lures themselves are broadly applicable across the diplomatic community and thus are able to be sent and forwarded to a greater number of targets. They’re also more likely to be forwarded to others inside of an organization as well as within the diplomatic community.
Overall, these factors increase the odds of a successful compromise within targeted organizations. While not likely to fully supplant diplomatic operations-themed lures, these lures focusing on individuals do provide Cloaked Ursa with new opportunities and a broader range of susceptible potential espionage targets.
Palo Alto Networks customers receive protections against the types of threats discussed in this article by products including:
One of the most recent of these novel campaigns that Unit 42 researchers observed appeared to use the legitimate sale of a BMW to target diplomats in Kyiv, Ukraine, as its jumping off point.
The campaign began with an innocuous and legitimate event. In mid-April 2023, a diplomat within the Polish Ministry of Foreign Affairs emailed his legitimate flyer to various embassies advertising the sale of a used BMW 5-series sedan located in Kyiv. The file was titled BMW 5 for sale in Kyiv - 2023.docx.
The nature of service for professional diplomats is often one that involves a rotating lifestyle of short- to mid-term assignments at postings around the world. Ukraine presents newly assigned diplomats with unique challenges, being in an area of armed conflict between Russia and Ukraine.
How do you ship personal goods, procure safe accommodations and services, and arrange for reliable personal transportation while in a new country? The sale of a reliable car from a trusted diplomat could be a boon for a recent arrival, which Cloaked Ursa viewed as an opportunity.
We assess that Cloaked Ursa likely first collected and observed this legitimate advertising flyer via one of the email’s recipients’ mail servers being compromised, or by some other intelligence operation. Upon seeing its value as a generic yet broadly appealing phishing lure, they repurposed it.
Two weeks later, on May 4, 2023, Cloaked Ursa emailed their illegitimate version of this flyer to multiple diplomatic missions throughout Kyiv. These illegitimate flyers (shown in Figure 1) use benign Microsoft Word documents of the same name as that sent by the Polish diplomat.
Figure 1. Example lure used in BMW campaign (SHA256 311e9c8cf6d0b295074ffefaa9f277cb1f806343be262c59f88fbdf6fe242517).
The key difference with these illegitimate versions is that if a victim clicks on a link offering “more high quality photos,” a URL shortener service (either t[.]ly or tinyurl[.]com) will redirect them to a legitimate site. This site would have been coopted by Cloaked Ursa, resulting in the download of a malicious payload.
When a victim attempts to view any of the “high quality photos” (shown in Figure 2) in the download, the malware executes silently in the background while the selected image displays on the victim’s screen.
Figure 2. Windows shortcut files masquerading as image files.
Figure 3 illustrates the full execution flow.
Figure 3. Execution flow.
These pictures are actually Windows shortcut files masquerading as PNG image files.
We’ve observed two versions of these illegitimate flyers. The only difference between the two is the shortened URL used in each case. The URLs ultimately redirect the victim to the same coopted site (hxxps://resetlocations[.]com/bmw.htm).
At the time of this writing, one of the flyer versions (SHA256: 311e9c8cf6d0b295074ffefaa9f277cb1f806343be262c59f88fbdf6fe242517) is detected as malicious by multiple vendors according to VirusTotal, while the other version (SHA256: 8902bd7d085397745e05883f05c08de87623cc15fe630b36ad3d208f01ef0596) is not detected. For a full overview of the malware, please refer to the Appendix.
Overall, we observed Cloaked Ursa targeting at least 22 of over 80 foreign missions located in Kyiv in this campaign, as shown in Table 1. The actual number targeted is likely higher. This is staggering in scope for what generally are narrowly scoped and clandestine APT operations.
Known Embassies in Kyiv Targeted by Cloaked Ursa in BMW Campaign
Albania
Argentina
Canada
Cyprus
Denmark
Estonia
Greece
Iraq
Ireland
Kuwait
Kyrgyzstan
Latvia
Libya
Netherlands
Norway
Slovakia
Spain
Sudan
Turkey
Turkmenistan
United States
Uzbekistan
Table 1. Known embassy targets of BMW campaign.
For the activity we observed, Cloaked Ursa used publicly available embassy email addresses for approximately 80% of the targeted victims. The remaining 20% consisted of unpublished email addresses not found on the surface web.
This indicates that attackers likely also used other collected intelligence to generate their victim target list, to ensure they were able to maximize their access to desired networks. The majority of the targeted organizations in this campaign were embassies. However, we also observed Cloaked Ursa targeting both Turkish Ministry of Trade representatives in Ukraine (via their ticaret[.]gov[.]tr work emails) and their embassy in the BMW campaign.
While there were a handful of emails sent directly to individuals’ work addresses within the campaign, the majority of the targeted emails consisted of general inboxes for the embassy, such as country.embassy@mfa[.]gov[.]xx. Despite the thought and detail put into targets for this campaign, at least two of the email addresses contained errors and never reached the intended targets. Overall, the use of these group inboxes likely increased the odds of the emails being reviewed and passed on to individuals within the embassies looking for transportation.
With a few of the embassies we observed being targeted, this was done via group emails hosted on free online webmail services. While these services offer some protection, they also outsource a portion of the security provided to targeted organizations and their employees to external entities. The use of free online webmail could have the unintended consequence of increasing a diplomatic organization’s difficulty in observing and understanding the totality of threats targeting it while also increasing its attack surface.
Turkish Diplomats: Humanitarian Assistance for Earthquake
Another of the novel Cloaked Ursa campaigns we observed likely targeted the Turkish Ministry of Foreign Affairs (MFA) earlier in 2023, within a February to March timeframe. While we were unable to obtain the malicious email lure associated with this campaign, we know that it related to a document that purported to be Turkish MFA guidance on humanitarian assistance pertaining to the Feb. 21, 2023, earthquake in Turkey. The earthquake in late February further ravaged a region already devastated by a massive earthquake two weeks earlier, which ultimately killed more than 50,000 and displaced more than 5.9 million people.
We were able to determine this second campaign targeting the MFA based on a PDF (shown in Figure 4) that was contained in a downloaded payload (SHA256: 0dd55a234be8e3e07b0eb19f47abe594295889564ce6a9f6e8cc4d3997018839 – for a full overview of the malware, please refer to the Appendix).
Not one to let a disaster and the highly sympathetic charge it generates go to waste, Cloaked Ursa likely saw a lure providing MFA guidance on humanitarian support for this tragedy as a way to ensure a high level of interest from their targets – these recipients would feel a patriotic obligation and would understand the MFA’s expectations to support their nation and its victims. In addition, given the timely and momentous nature of the lure, it was almost certainly forwarded by concerned employees to others in their organization who would be interested in the guidance.
Figure 4. Excerpt from Turkish MFA memorandum.
Conclusion
Diplomatic missions will always be a high-value espionage target. Sixteen months into the Russian invasion of Ukraine, intelligence surrounding Ukraine and allied diplomatic efforts are almost certainly a high priority for the Russian government.
As the above campaigns show, diplomats should appreciate that APTs continually modify their approaches – including through spear phishing – to enhance their effectiveness. They will seize every opportunity to entice victims into compromise. Ukraine and its allies need to remain extra vigilant to the threat of cyber espionage, to ensure the security and confidentiality of their information.
Recommendations
Train newly assigned diplomats and employees to a diplomatic mission on the cybersecurity threats for the region prior to their arrival. This training should include the specific tactics, techniques and procedures (TTPs) used by APTs in that region.
Always take extra precautions to observe URL redirection when using URL-shortening services.
Always be cautious of downloads, even from seemingly innocuous or legitimate sites. APTs routinely co-opt legitimate sites or services for malicious purposes.
Always take extra precautions with attachments that require a web browser to open. These types of attachments include the following file extensions: .hta, .htm, .html, .mht, .mhtml, .svg, .xht and .xhtml.
Always verify file extension types to ensure you are opening the type of file you intend to. If the file extension does not match, or if it is attempting to obfuscate its nature, it is very likely malicious.
When received as an attachment to an email, or when downloaded from a link within an email, always look for hidden files and directories in archives such as those with the extensions .zip, .rar, .7z, .tar and .iso. The presence of hidden files or directories could indicate the archive is malicious.
Consider disabling JavaScript as a rule.
Palo Alto Networks customers receive protections against the types of threats discussed in this article by products including:
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200
Palo Alto Networks disclosed this activity to Microsoft and Dropbox.
Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
The hyperlinks found within the malicious BMW 5 for sale in Kyiv - 2023.docx flyers (SHA256: 311e9c8cf6d0b295074ffefaa9f277cb1f806343be262c59f88fbdf6fe242517 and (SHA256: 8902bd7d085397745e05883f05c08de87623cc15fe630b36ad3d208f01ef0596) lead to a site (hxxps://resetlocations[.]com/bmw.htm) that was offline in mid-June, but they originally retrieved a large HTA file. (SHA256: 47e8f705febc94c832307dbf3e6d9c65164099230f4d438f7fe4851d701b580b) This HTA file contains roughly 10 MB of Base64-encoded and XORed data, followed by JavaScript code.
The JavaScript code would first make a request to the same domain on the URI kll.php, before decoding the embedded data mentioned above and triggering the browser to download it using msSaveOrOpenBlob, or a mix of createElement and createObjectURL should msSaveOrOpenBlob fail. The downloaded file is assigned the name bmw.iso (SHA256: 79a1402bc77aa2702dc5dca660ca0d1bf08a2923e0a1018da70e7d7c31d9417f), matching the theme seen thus far.
Once downloaded, execution is reliant on the user clicking the downloaded file, which mounts the disk image to the system and opens up Windows File Explorer. This reveals nine total files masquerading as images, which are instead LNK shortcut files (shown in the execution flow diagram in Figure 3).
A hidden folder named $Recycle.Bin is created alongside the LNK files. This folder contains the real PNG images as well as three DLLs, an encrypted payload and a legitimate copy of Microsoft Word named windoc.exe.
If one of the LNK files is clicked, the following command line is executed. Note that the image name is changed depending on the LNK file clicked:
While windoc.exe is not malicious, it does attempt to load several DLLs on runtime and falls victim to DLL hijacking. As a result, it will load two of the three DLLs within its current directory, namely APPVISVSUBSYSTEMS64.dll (SHA256: 38f8b8036ed2a0b5abb8fbf264ee6fd2b82dcd917f60d9f1d8f18d07c26b1534) and MSVCP140.dll. (SHA256: 706112ab72c5d770d89736012d48a78e1f7c643977874396c30908fa36f2fed7). The third DLL (Mso20Win32Client.dll) does not appear to be essential to the malware’s functioning and is added so that windoc.exe runs correctly, similarly to the DLL described below.
MSVCP140 is not digitally signed, but does not contain any malicious functionality. It appears to only contain a select few exports from a legitimate copy of MSVCP140. It’s likely that this was included to execute windoc.exe on systems that did not have Microsoft Visual C++ Redistributables – at least enough so that it would load APPVISVSUBSYSTEMS64.
APPVISVSUBSYSTEMS64, on the other hand, is a fairly obfuscated DLL. It leverages a large number of unnecessary assembly instructions, including the following, likely hindering decompilation efforts and slowing down analysis:
Psllq
Emms
Pcmpeqd
Punpckhbw
APPVISVSUBSYSTEMS64 contains a number of anti-analysis techniques, including the following:
Making sure its process name is set to windoc.exe
Checking that the system has more than one processor
Leveraging NtQueryObject to search for any existing Debug Objects, to check for the existence of a debugger
If these checks are all passed, the sample will proceed to open the encrypted payload file found within the ISO file, in this case named ojg2.px. (SHA256: c62199ef9c2736d15255f5deaa663158a7bb3615ba9262eb67e3f4adada14111). Once read into memory, it will decrypt the file using an XOR operation, which results in a secondary shellcode layer.
The shellcode is then injected into the first two active Windows processes that it can inject into, such as taskhost.exe or sihost.exe, using a technique that is somewhat similar to one previously used by Cloaked Ursa (as recently described by the Military Counterintelligence Service and CERT.PL).
First, the shellcode is mapped and copied into the remote process using NtMapViewOfSection before a new remote thread is created in a suspended state using NtCreateThreadEx. The interesting aspect of this injection technique is that instead of the created thread pointing to the shellcode entry point or any Windows API, it is given a start address of a function within the APPVISVSUBSYSTEMS64 process. It’s possible that the authors did this to evade monitoring tools from identifying a newly created thread pointing to malicious shellcode.
Before the thread is resumed with NtResumeThread, APPVISVSUBSYSTEMS64 will use NtGetContextThread and NtSetContextThread to modify the RCX register (which will contain the thread entry) to point to the entry point of the shellcode.
Figure 5. Creation of thread pointing to a local function (resolves API) and modification of thread context.
This results in the resumed thread calling RtlUserThreadStart, which will move the value in the RCX register to R9 before calling it, thus triggering the shellcode.
The goal of the shellcode is to extract the final executable file payload in memory and transfer execution to it. This payload is the final sample in the infection chain and is responsible for handling communication to and from the command and control (C2) server.
The final payload contains a large array of obfuscation techniques, including string encryption and junk functions, as well as modifying exception handling structures to place “try and except” clauses part way through assembly instructions. This effectively breaks the instructions when disassembling, as many disassemblers will take these structure values into consideration when parsing a binary file. This results in a mangled control flow graph and failed decompilation due to the modifications in the exception handling structures.
For communication, the payload uses both the Microsoft Graph and Dropbox API. Cloaked Ursa has previously leveraged Dropbox as a C2 server. However, Cloaked Ursa’s use of Microsoft Graph API to facilitate C2 communications appears to be a relatively new addition to their toolkit.
In addition to the string encrypted tokens and API keys required to communicate with these platforms, there is another string that stands out (shown in Figure 6), used when communicating with the Microsoft Graph API: Teams_test.
Figure 6. String decryption functions used to decrypt core Dropbox and Microsoft Graph API information.
Given that the Graph API allows for interacting with a number of different Microsoft 365 Services including Microsoft Teams, it’s possible that this was an initial test for communicating via Teams or the Graph API.
If communication fails via the Graph API several times, communication via Dropbox is attempted. Several decrypted strings in the binary provide insight into the use of Dropbox for communication:
Previously, Cloaked Ursa-linked payloads that communicate with Dropbox had wrapped communications in a packet that resembled an MP3 file. The MP3 magic bytes (ID3\x04\x00\x00\x00\x00\x00#TSSE) were prepended to the encrypted data and uploaded to Dropbox as an MP3 file.
In this sample, it appears that they have opted to use BMP files. The threat actor-owned C2 will upload commands to Dropbox that are wrapped in the BMP format. These commands are retrieved by the payload and then parsed, decrypted and executed. Any data that the payload uploads to Dropbox will also be encrypted and wrapped in the BMP format.
In terms of handled commands, the payload accepts five possible requests from the C2 server, as described in the table below.
Command Value
Command Description
0
Inject shellcode into explorer.exe or smartscreen.exe
1
Execute specified command with CMD.exe
2
Read from local file
3
Write data to local file
4
Spawn and inject code into WerFault.exe
Table 2. Commands handled by sample.
Based on the lack of additional commands, it’s likely this is merely a loader for a further sample. As of mid-June, the Dropbox and Graph API credentials are no longer valid, preventing access to any information that was uploaded to either platform.
Technical Analysis of Turkey Campaign
We identified an additional sample with similar characteristics to other attributed Cloaked Ursa campaigns, which we believe to have been targeting the Turkish Ministry of Foreign Affairs. We did not observe the lure or lures used in this campaign, but we are able to identify the attack chain after the original lure. We assess that the original lure enticed the target to click on hxxps:// simplesalsamix[.]com/e-yazi.html. The URL is no longer active, but it originally retrieved an HTTP smuggling file named e-yazi.html (SHA256: cd4956e4c1a3f7c8c008c4658bb9eba7169aa874c55c12fc748b0ccfe0f4a59a).
The downloaded file is assigned the name e-yazi.zip. (SHA256: 0dd55a234be8e3e07b0eb19f47abe594295889564ce6a9f6e8cc4d3997018839). This sample contains five files.
Once again, a legitimate WinWord.exe binary was found within the archive, named e-yazi.docx.exe. However, whitespace was added between the .docx and .exe, resulting in the file appearing as a document file.
Alongside the WinWord.exe, a file named APPVISVSUBSYSTEMS64.dll (SHA256:
) was present once again, as well as a file named okxi4t.z (SHA256: 03959c22265d0b85f6c94ee15ad878bb4f2956a2b0047733edbd8fdc86defc48). This file is similar to the previously mentioned ojg2.px in that it contains encrypted shellcode.
On execution of WinWord.exe, APPVISVSUBSYSTEMS64.dll is sideloaded and (assuming the standard anti-analysis checks were passed) it would open and read the data from okxi4t.z before decrypting it and injecting it into the first running process it can.
The injected shellcode shares a number of similarities with code seen in the BMW-related sample, such as the following:
General execution flow
Functionality to unhook numerous Windows API calls
Its obfuscation techniques
We were also able to confirm that the shellcode contained overlaps with the fourth-stage shellcode dropper loader, shown in Figure 7, as described in the Cloaked Ursa QUARTERRIG malware report by Military Counterintelligence Service and CERT.PL. The same algorithm and payload structure can be seen within the injected shellcode, as shown in Figure 8, aside from minor differences such as the values of the magic_const and hashed_str.
The final payload within this infection chain is somewhat similar to the BMW-linked final payload, in that it leverages both Microsoft Graph API and the Dropbox API for C2 communication. Instead of Teams_test being the project name, it’s set to mytestworkapp1. The hard-coded API tokens are also different from the initially analyzed sample.
Similar obfuscation was employed within this sample, including string encryption and control flow obfuscation via abusing the exception handling structures. However, there are no junk functions added to the sample, resulting in a much smaller file size of 498 KB.
It’s worth noting that the string encryption algorithms appear to line up with those seen within the Cloaked Ursa SNOWYAMBER and QUARTERRIG malware reports by the Military Counterintelligence Service and CERT.PL. Many of the string decryption functions leverage inline assembly keys (as seen in Figure 9), while the rest retrieve keys from the .rdata directory.
Figure 9. First (left) and second (right) string decryption function types.
It’s clear that Cloaked Ursa remains dedicated to identifying legitimate platforms to host their C2 servers, based on their usage of the Microsoft Graph API within these two samples, as well as past reports describing C2 communication via Notion and Google Drive.
Updated July 20, 2023, at 12:43 p.m. PT to change UAC-0029 to UAC-0004.
In March 2023, Unit 42 researchers discovered six malicious packages on the Python Package Index (PyPI) package manager. The malicious packages were intended to steal Windows users’ application credentials, personal data and tracking information for their crypto wallets. The attack was an attempted imitation of the attack group W4SP, which had previously launched several supply chain attacks using malicious packages.
We will discuss the ease with which threat actors can use malicious packages to release malicious code in an open-source ecosystem. The behavior we observed is not an organized campaign planned by an attack group, but most likely an imitator who read technical reports of previous campaigns to execute their own attack. We will walk through a technical analysis of the malicious code and unravel what the threat actor tried to achieve in the attack.
We will describe the indicators used by Palo Alto Networks Prisma Cloud modules that identified the malicious packages discussed here. Palo Alto Networks customers receive protections from open-source packages containing malicious code via Prisma Cloud.
Malicious packages are software components that were intentionally designed to cause harm to computer systems or the data they process. Such packages can be distributed through various means, including phishing emails, compromised websites or even legitimate software repositories.
Malicious packages can have far-reaching consequences, from surreptitiously pilfering sensitive data to causing system disruptions and even assuming control over entire systems. Moreover, these nefarious packages possess the ability to spread to other interconnected systems, instigating widespread damage and impeding productivity. Thus, it is important to exercise utmost caution when engaging in software downloads and installations, especially when the source is unfamiliar or untrusted.
By remaining vigilant and discerning, users can safeguard their systems and prevent potential harm from threat actors infiltrating their technological environment.
New Malicious Packages Discovered in PyPI
In March 2023, Prisma Cloud researchers discovered six malicious packages on the PyPI package manager targeting Windows users. The malicious packages were intended to steal application credentials, personal data and cryptocurrency wallet information.
Our Prisma Cloud engine, designed to detect malicious PyPI packages, identified several packages with suspicious attributes that were uploaded within a short time frame:
The packages lacked an associated GitHub repository, which is commonly found with legitimate packages. This could indicate a desire to hide the code from view. This, coupled with a limited number of downloads, further raised our suspicions.
When executed, the packages performed malicious actions such as collecting sensitive data and sending it to third-party URLs.
The packages contained a malicious code pattern (as will be demonstrated later), which was detected by our engine.
Because the package authors were newly created, had only uploaded one package, and did not provide supporting information such as links to other projects or to any repository, they were not considered reputable.
Finally, the usernames of the packages’ author(s) were created within minutes of each other, following a distinctive pattern (e.g., Anne1337, Richard1337). Each of these usernames had uploaded only a single package.
The second stage of the attack was similar to previous attacks we have seen by the W4SP attack group. This group specializes in exploiting vulnerabilities in the open-source ecosystem, targeting organizations and spreading malware. Their primary goal is to gain unauthorized access to sensitive information, such as user credentials and financial data. They often use automated tools to scan for vulnerabilities and attempt to exploit them. In addition to traditional attacks, W4SP attackers were also seen executing supply chain attacks.
Findings
Prisma Cloud engine detected the packages that were marked as potentially containing malicious code. Each package contained a link to a suspicious remote URL, trying to download contents after having been uploaded individually by a single user.
The users for each uploaded package, whose usernames were created just before the upload, didn’t have any history of previously uploading packages. Each package reached hundreds of downloads, until they and the fraudulent user accounts that uploaded them were removed by PyPI due to our research team reporting the abuse.
We analyzed the code and tried to track down the package authors. We discovered a pattern in every package author’s username where they used “1337” as a suffix, which indicates that some automatic process created those users, as shown in Table 1. Figure 1 shows an author page for one of these usernames.
Package Name
Author
Malicious Link
Number of Downloads
ligitgays
Anne1337
hxxps://paste.bingner[.]com/paste/o27gb/raw
191
xboxredeemer
Richard1337
hxps://paste.bingner[.]com/paste/47rpu/raw
160
syntax-init
Debbie1337
hxxps://paste.bingner[.]com/paste/q77t3/raw
140
xboxlivepy
Christopher1337
hxxps://paste.bingner[.]com/paste/jr7ow/raw
153
Ligitkidss
Sara1337
hxxps://paste.bingner[.]com/paste/9mzzs/raw
158
tls-python
Kevin1337
hxxps://paste.bingner[.]com/paste/97vnn/raw
240
Table 1. Malicious package findings.
Figure 1. An author page on PyPI.
The Attack: Custom Package Entry Point
The attack was similar to previous attacks we have seen by the W4SP attack group, which was covered in detail in the Bleeping Computer article, “Devs targeted by W4SP Stealer malware in malicious PyPi packages.” These similarities led us to believe this was a copycat attack.
There were aspects of this case that were less complex than we would expect for a true W4SP attack, for example:
There was no targeting of any organization.
The malicious packages did not use typosquatting for common popular packages, as expected for W4SP attacks.
The second phase of the attack was not encrypted. In the true attacks from W4SP, this phase was encrypted and it made detection more difficult.
Most of the code used by W4SP for previous attacks was already available for download, so it could be easily accessed and repurposed.
In the previous attack, W4SP Stealer was delivered as a second stage payload downloaded from a free file hosting service, which allowed the attacker to avoid detection at the package repository itself.
Rather than containing overtly malicious code, these packages were crafted to have specific entry points that would be triggered during the installation or execution process. By leveraging free file hosting services and employing custom entry points, the attackers aimed to remain undetected, posing a significant challenge to security professionals and researchers tasked with detecting and mitigating such threats.
These attacks are easy to implement and can be launched with little security expertise. However, they can be very effective, as the installation process automatically executes the attack as opposed to a threat actor needing to launch the attack when the imported module is used.
When a software developer wants to use a Python package they have to perform two actions. The first is to install the package, and the second is to import or declare in the code to use it. As we discuss in the next section, the attack code actually starts in the installation file (setup.py), which means that the attack is already carried out during the installation of the package.
In the case we investigated, the attacker called themself @EVIL$ STEALER. However, the attacker’s name changed with every attack. Below is the collection of names, as found in the code signature:
ANGEL Stealer
Celestial Stealer
Fade Stealer
Leaf $tealer
PURE Stealer
Satan Stealer
@skid Stealer
Malicious Code
The setup.py file was the same in all packages and contained the following code snippet that downloads content from a remote URL before executing it:
Figure 2. Setup.py (first stage) malicious code.
Figure 2 (above) shows the following activities:
The attacker uses the _ffile object to create a temporary file, and the contents of the file are written using the write method.
The usage of a temporary file with the NamedTemporaryFile function is a well-known technique to hide malicious code from detection by antivirus software or other security measures.
The file's contents are obtained by downloading the contents of a URL using the urlopen function from the urllib.request module, and then executes the contents of the file using the exec function.
After the contents of the temporary file have been written, the file is closed and an attempt is made to execute it using the start command in the system shell. If this is successful, the setup function is called to create the package.
The attacker then uses the start command to start the Python engine's executable (pythonw.exe).
This executable will then execute the script file that is passed as a parameter. Since that malicious package targeted Windows users, if the script file is not signed, it will not be subject to SmartScreen (Windows security feature to detect and prevent the execution of potentially malicious files) or signature checking.
This means it will execute malicious code on a target computer, even if the target computer has SmartScreen and signature checking enabled.
The Second Stage: W4SP Stealer
According to our research, for the second stage, the attacker used a configured version of W4SP Stealer 1.1.6. This version is similar to previous ones where the code imports several libraries, including requests, Crypto.Cipher, json and sqlite3. Then, it uses various techniques to extract and decrypt stored browser credentials, including passwords and cookies, and sends this information to a Discord webhook.
This stage was similar within all of the malicious packages found. The W4SP Stealer is well known by the cybersecurity community. This section will give a short overview.
The main body of the code defines a class DATA_BLOB, which is used to store data for the CryptUnprotectData function. This function decrypts a Windows Data Protection API (DPAPI)-protected value, which is used to store sensitive data such as passwords and API keys. The code attempts to decrypt a value using the CryptUnprotectData and DecryptValue functions, and then sends it to a remote server via a Discord webhook, as shown in Figure 3.
Figure 3. Attempts to decrypt a Windows Data Protection API (DPAPI)-protected value.
The figures below show several examples from the malicious code in which the attacker tries to collect information about the victim. In Figure 4, the attacker tries to collect information about the victim including IP address, username, country and country code.
Figure 4. Code that retrieves information about the user's IP address, location and username among other things.
In Figure 5, the attacker interacts with the Discord API to retrieve a user's friend list and extract information about their owned badge.
Figure 5. Code to retrieve a list of a user's friends on Discord.
Later in code, they try to use a Discord webhook prepared in advance (shown in Figure 6) and then they try to send the victim information via HTTP requests to the associated Discord channel.
Figure 6. Discord webhook.
Finally, as shown in Figure 7, the attacker tries to verify whether the victim's machine is suitable for carrying out the attack. If it’s determined that the machine is suitable, the DETECTED variable will be set to true and the information from the victim's machine will be sent to the remote server.
Figure 7. Code searching for cookies.
PyPI as a Convenient Platform for Uploading Malicious Packages
Within the realm of PyPI, which is a revered and widely embraced repository that hosts a staggering number of Python packages, a disconcerting reality has emerged. The repository's unrivaled popularity has inadvertently attracted the attention of unscrupulous entities, fervently seeking to exploit its vast user base by surreptitiously disseminating malicious packages.
This distressing trend poses a paramount challenge, as the decentralized nature of PyPI renders the monitoring and detection of these malevolent entities an arduous endeavor. The ramifications of falling victim to such nefarious packages are profound, posing severe consequences for unsuspecting users and enterprises alike, such as data, credential or crypto theft. Hence, fortifying the safety and security of PyPI's package ecosystem assumes a critical imperative, necessitating the implementation of robust countermeasures to combat this persistent threat.
As a result of this, it was not surprising that on May 20, 2023, PyPI announced that they temporarily suspended the registration and upload of new packages due to a concerning rise in malicious activities, malicious users and projects on the platform. Unfortunately, no specific information about the nature of the malware or the threat actors involved has been disclosed at this time.
This decision to freeze new user and project registrations reflects the ongoing challenges software registries like PyPI face, as they have become attractive targets for attackers seeking to compromise developer environments and tamper with the software supply chain.
Conclusion
The rise and prevalence of open-source software and the proliferation of package managers have made it easier than ever for attackers to slip these dangerous packages into unsuspecting systems. With software becoming increasingly pervasive in our daily lives, the threat of malicious packages has become more significant. Attackers can disguise these packages as legitimate software and exploit vulnerabilities in unsuspecting systems, causing significant damage such as data theft, system shutdown and network control.
To combat this threat, software developers and organizations must prioritize software security in their development process. Implementing robust security measures, such as code reviews, automated testing and penetration testing can help identify and remediate vulnerabilities before deployment. Additionally, staying up to date with security patches and updates can prevent attackers from exploiting known vulnerabilities.
In addition to technical measures, increasing awareness and education around software security can also help mitigate the risk of malicious packages. Regular training for developers, IT staff and end users on best security practices (e.g., password hygiene and suspicious email identification) can help prevent successful attacks. The collective effort of security professionals, developers and end users is necessary to ensure that malicious packages are identified and prevented from causing harm to systems and networks.
Publishing technical reports about malware and malicious packages also plays a critical role in advancing our understanding of these threats and improving our ability to protect against them. Technical reports provide an in-depth analysis of the behavior and functionality of malware, which helps researchers and security professionals develop more effective countermeasures. Additionally, sharing technical details about malware can help organizations stay up to date with the latest threats and vulnerabilities, allowing them to improve their security posture and reduce the risk of cyberattacks.
Palo Alto Networks Product Protections
Prisma Cloud Runtime Protection Solution
Prisma Cloud runtime defenses involve a configurable set of features that provide the identification of specified and predictive protections for cloud virtual machines, containers and serverless functions. Predictive protections include capabilities like determining when a cloud or container instance executes an unknown process or creates an unexpected network socket.
Threat-based protections include capabilities like detecting when malware is added to a workload, or when a workload connects to a botnet. This detection of malicious binaries is made possible through the integration of the Palo Alto Networks WildFire cloud-based malware protection engine. These runtime incidents can also be detected predeployment, using the Image Analysis Sandbox.
Prisma Cloud Malicious Package Solution
Prisma Cloud offers an advanced end-to-end cybersecurity solution that encompasses a comprehensive suite of proactive measures designed to safeguard Prisma customers against a wide array of potential attacks, mitigating risks well in advance of their public exposure.
At the heart of this cutting-edge defense system lies the Prisma CVE Viewer, a dynamic resource that operates in real-time, continuously updated to reflect the latest threat landscape.
Incorporating a unique identification system known as Prisma-IDs, this viewer serves as a central repository for public vulnerabilities meticulously unearthed by our diligent research team. Leveraging this proprietary identifier, it bridges the gap for vulnerabilities that have yet to receive a Common Vulnerabilities and Exposures (CVE) ID, ensuring no security gaps go unnoticed or unaddressed. Moreover, the Prisma CVE Viewer diligently archives any malicious packages discovered by our expert researchers, empowering Prisma customers with unparalleled visibility into potential threats lurking within their software supply chain.
As shown in Figure 8, by arming customers with Prisma-IDs and equipping them with preemptive protection, Prisma Cloud protects against possible exploits before they have an opportunity to materialize. This robust security approach serves as a formidable deterrent against supply chain attacks, proactively thwarting threats and preserving the integrity and resilience of our customers' systems and infrastructure.
Figure 8. Prisma Cloud detection.
On top of that, the new Prisma Cloud CI/CD Security module (shown in Figure 9) offers comprehensive protection against emerging methods of executing code in CI pipelines and developers’ environments through malicious software dependencies (e.g., dependency confusion, typosquatting and compromised known packages). This is done by analyzing the different settings, configurations and interconnections of the various systems across the software delivery pipelines, such as the version control and CI systems.
Figure 9. Prisma Cloud CI/CD Security module.
Cortex EDR analytics
Cortex XDR provides EDR analytics capabilities on top of Cortex XDR agents, thus providing analytics-based detection capabilities for runtime command and control (C2) detection of malicious Python packages being used at runtime. An example for EDR analytics C2 coverage is discussed in our Cortex XDR technical documentation. See the Variant subsection “UNIX LOLBIN process connected to a rare external host” under the "A process connected to a rare external host" section.
Unit 42 researchers discovered an active campaign that targeted several web hosting and IT providers in the United States and European Union from late 2020 to late 2022. Unit 42 tracks the activity associated with this campaign as CL-CRI-0021 and believes it stems from the same threat actor responsible for the previous campaign known as Manic Menagerie.
The threat actor deployed coin miners on hijacked machines to abuse the compromised servers’ resources. They have further deepened their foothold in victims’ environments by mass deployment of web shells, which granted them sustained access, as well as access to internal resources of the compromised websites.
In doing so, the attackers could potentially have turned the hijacked legitimate websites – hosted by the targeted web hosting and IT providers – into command and control (C2) servers at scale, affecting thousands of web pages. The threat actor could thus run their C2 activity from legitimate websites that have good reputations, and which are not necessarily flagged by security solutions as malicious. This could have a tremendous impact on the abused legitimate websites, which would in that circumstance be made to unknowingly host malicious content and harbor criminal activity. Such criminal activity could inflict legal and/or reputational damages upon the owners of the websites or the web hosting companies.
While operating in the victims’ networks, the attackers attempted multiple techniques to evade the detection of various monitoring tools as well as active commercial cybersecurity products. They also kept executing payloads, redeploying and rerunning tools that were previously blocked, or using other similar tools. Attackers tried to stay under the radar by avoiding known malware, introducing custom tools and relying on publicly available legitimate tools.
Based on the tactics, techniques and procedures (TTPs) that we observed in this attack, the threat actor whose previous campaign was dubbed Manic Menagerie carried out this more recently observed campaign, which we therefore call Manic Menagerie 2.0.
This threat actor was reported as active from at least 2018, targeting web hosting companies in Australia, by the Australian Cyber Security Center. The name is most likely a reference to their noisy activity, plus the large number of attacked web hosting companies and different tools used by the attacker.
Palo Alto Networks customers receive protections from the threats mentioned in this article through the following products and services:
Cortex XDR and XSIAM with Local Analysis, Behavioral Threat Protection, the Cryptominers module and Analytics
The initial foothold in the Manic Menagerie 2.0 campaign was first observed in late 2020, targeting companies in the United States and European Union. In this campaign, the threat actors gained access to target machines by exploiting vulnerable web applications and IIS servers, and deploying different web shells on these infected servers.
Deploying web shells on an active web server allows the threat actor to hijack legitimate websites. The web shells are placed on these hosted websites in the following folders on the compromised server: C:\[hosted websites on the server path]\wwwroot\example.com\webshell.aspx)
These actions also allow public access from outside the victim’s network in the future. This effectively allows these websites to be turned into future C2 servers for the attacker.
We also observed the same web shell, xn.aspx, mentioned in the Australian Cyber Security Center’s (ACSC) report about the original Manic Menagerie operation targeting web host companies in Australia.
After deploying web shells in Manic Menagerie 2.0, the threat actor initiated the deployment of coin miners. This was likely done to abuse the compromised servers' powerful computing resources for the threat actor’s financial gain through coin mining.
During 2021-2022, upon the public disclosure of multiple Microsoft Exchange Server vulnerabilities, the threat actor attempted to exploit the following vulnerabilities in some targets:
CVE-2021-34473: (One of the ProxyShell vulnerabilities) Exchange Server remote code execution vulnerability
CVE-2021-33766: (ProxyToken) Allows an attacker to modify the configuration of mailboxes of arbitrary users
Therefore, in addition to vulnerabilities in the IIS servers as well as vulnerable web applications in the environment, the previously mentioned vulnerabilities provided the threat actor another penetration and persistence vector. Morphisec recently researched a campaign where attackers used Exchange Server vulnerabilities (collectively known as ProxyShell) to drop cryptominers.
Reconnaissance and Privilege Escalation
From late 2020, threat actors involved in the Manic Menagerie 2.0 campaign began periodically trying to execute local privilege escalation proof-of-concept (PoC) tools (detailed below) to add their own users to the Administrators group in IIS servers, to further promote their interests. When one tool failed, they would try another tool with similar functionality.
Attackers employed a runas.exe .NET wrapper called RunasCs. This publicly available tool enables extended functionality that the original runas.exe utility lacks, such as executing processes by using explicit user credentials.
The threat actors were observed attempting to perform further network reconnaissance in an infected environment by running under a vulnerable web application. They then attempted to add their own user by running au.exe (shown in Figure 1), which is short for “add user.” This file must be run by an elevated user. They then made sure their username existed by running net commands.
Their usage of the usernames iis_user and iis_uses is notable, as the latter might initially seem to be a typo. This naming convention is also mentioned in the ACSC report mentioned above.
Figure 1. au.exe creates iis_user user and generates a password for it.
The aforementioned au.exe is a tool that the threat actor attempted to run multiple times, chained with different PoC local privilege escalation tools, as shown in Figure 2.
Figure 2. Attempted execution of RunasCs together with other commands under a vulnerable web application, blocked by Cortex XDR.
The threat actor was observed using multiple tools for the same purpose of privilege escalation. In Figure 2 above, a 64-bit version of PrintSpoofer is one of these tools. This public tool was used by attackers to elevate au.exe, which otherwise wouldn’t add the user it was intended to.
Fork Bomb and More Local Privilege Escalations
The threat actors were observed attempting local privilege escalation (LPE) using multiple publicly available tools, leveraging the following vulnerabilities:
Another interesting execution that we observed in Manic Menagerie 2.0 is the svchost.exefork bomb. The ACSC report on the original Manic Menagerie campaign also mentioned the presence of this type of denial-of-service (DoS) tool.
The code for this fork bomb is very simple, as it runs in an endless loop (shown in Figure 3), opening more and more instances of itself until the machine runs out of memory. This activity is intended to crash the machine and force a reboot. This allows the persistence mechanism of an executable that requires a reboot to fire up.
Figure 3. The endless loop code snippet from the fork bomb binary.
dllnc.dll: Run Payloads and Add User Tool
Another tool that we observed in the Manic Menagerie 2.0 campaign called dllnc has two main features. One is loading some of the attacker's executables and batch files, and the other one is serving as another tool that is supposed to add the attacker’s user to the Administrators group.
It contains an indicative PDB path:
F:\upfile\3389\opents\dlladduser\x64\Release\dllnc.pdb, which did not yield any other results in VirusTotal as of the middle of May 2023. This is a good indication that this is a custom tool for this specific attacker.
The loader code segment attempts to load some of the tools it expects to already be in the attacker’s path (as shown in Figure 4), since there are no checks whether they are actually present or not. While doing so, it considers several possible hard-coded paths, most of them seen in this campaign.
Figure 4. Hard-coded paths of the attacker’s tools as seen in dllnc.dll.
The tool then deletes the current iis_user user and then re-adds it, this time with a hard-coded password. Again, this behavior correlates with the ACSC report on the original Manic Menagerie campaign. An old variant of the Relative ID (RID) hijacking tool (shown in Figure 5), which was also mentioned in that report, resembles this behavior.
There is a clear, strong resemblance between the password in both variants, as both use the xman prefix and a similar suffix (shown in Figure 6).
Figure 6. The user iis_user and its hard-coded password.
PCHunter
PCHunter, another tool we observed being used by the Manic Menagerie 2.0 campaign, is reminiscent of older tools like GMER and Rootkit Unhooker. It is a legitimate and powerful toolkit for browsing and modifying different Windows Internals components. Figure 7 shows the attempted execution of PCHunter being blocked.
Figure 7. PCHunter blocked execution.
Figure 8 shows the digital signature of PCHunter, by “Epoolsoft Corporation.” The comments in Chinese provide a quick description of the tool. This is translated as “Yipmin is a Windows system information viewing tool (security category).”
Figure 8. PCHunter signer information.
Second Wave: Backdooring at Scale
Deploying a Known Web Shell to Multiple Destinations
The second distinct wave of attacks observed in the Manic Menagerie 2.0 campaign is characterized mainly by massive deployment of web shells to the hosted websites. This allows the attacker to strengthen their foothold by enabling them future public access, and to hide their web shells deep in nested folders. These legitimate hijacked websites could potentially be used as C2 servers in the future (e.g., as part of a botnet infrastructure).
The attacker’s deployment attempts go back to early 2022, when they deployed the same known web shell called ASPXSpy to multiple hosted websites. We observed this web shell being written to hundreds of different paths, as shown in Figure 9.
Figure 9. ASPXSpy web shell being written to different hosted websites paths.
GoIIS
The attackers also ran a tool called IIS1.asp or GoIIS.exe (shown in Figure 10), compiled in 2017. The tool is written in Golang and is used to traverse the server’s folders to retrieve the server’s configuration information. This allows the attacker to gain valuable information about the compromised server.
Figure 10. IIS tool output.
Sh.exe: A Custom Web Shell Deployment Tool
Later in 2022, the attacker deployed a custom tool named sh.exe as part of the Manic Menagerie 2.0 campaign, whose execution can be seen in Figure 11 below. The role of this tool is to write web shells at scale to hosted websites, based on a preconfigured list of paths and legitimate hijacked websites on the server sharing the same public IP address.
In order to facilitate the use of this tool, the attackers used a custom wrapper for caclcs.exe (that they named mycacls.com), which is a command-line tool used to manage access control lists (ACLs). This tool enabled them to change the web server’s ACL permissions in bulk as well as lowering the IIS security settings.
Figure 11. Attempted sh.exe execution along with other tools and commands, as blocked by Cortex XDR.
The parameters passed on to sh.exe contain a list of relevant websites that share the same public IP. Upon execution, the sh.exe tool generates various legitimate-looking subfolders, such as images and css to further conceal their activity. It’s possible that this was intended to give attackers future access to victims’ machines from the internet and to potentially use this infrastructure in the future as C2 servers at scale.
sh.exe is signed with an invalid certificate issued by "Fujian identical investment co.,Ltd." as shown in Figure 12. This is the same name used to sign another tool, which the ACSC report described in a previous campaign.
In the sample we observed, sh.exe was compiled on Nov. 3, 2022. Its certificate was signed on Dec. 6, 2022. Shortly after signing it, threat actors were seen executing sh.exe in one of the compromised environments. The compilation timestamp and the date range of the invalid certificate could indicate the tool was made specifically for this particular campaign.
Figure 12. sh.exe invalid signature.
While the threat actor deleted most of the files, we found a connection between sh.exe and the files it dropped that could not be recovered. Our investigation uncovered three distinct compiled .NET DLLs that the attackers used.
These DLLs are compiled by the IIS server once a “raw” ASPX file is accessed for the first time. Upon decompiling the code, interesting similarities were found between the web shell and sh.exe, based on indicative strings found in both files.
Browsing to one of the websites where one of the web shells was dropped, the content on the page is the string ONEPIECE, as shown in Figure 13 below.
Figure 13. Browsing the web shell resource in one of the hijacked websites.
Browsing the code of one of the web shells and looking at the code responsible for showing the HTML content, this string can be seen together with other indicative strings, such as x_best_911 (shown in Figure 14).
Figure 14. The ONEPIECE string hard-coded in the compiled web shell’s DLL code.
The x_best_911 string can also be found in sh.exe, as shown in Figure 15.
Figure 15. The x_best_911 string hard-coded in sh.exe.
Going back to the report by the ACSC, the password generated upon execution of the aforementioned RID Hijack tool contains the xman string. This string can be also found in sh.exe, as shown in Figure 16, which indicates yet another similarity between the novel tool seen in this recent campaign and the previous Manic Menagerie campaign.
Figure 16. The xman string is hard-coded in sh.exe.
More LPE Attempts
LPE Toolset: Hippos and Potatoes
As mentioned in the previous section, once the IIS server accesses a web shell, a .NET DLL is compiled on the fly and placed in a temporary directory. One such compiled DLL web shell file, which can be seen in Figure 17 below, is App_Web_xvuga1zl.dll.
The connection the attackers had made with the web shell resulted in yet another attempt to remotely execute multiple LPE publicly available tools, as seen in many stages of attacks associated with this campaign.
As the attacker had done previously, they also used several privilege escalation tools. In one case, there were only minutes separating each execution, to try to avoid being blocked:
JuicyPotato
PrintSpoofer
JuicyPotatoNG
EfsPotato
PetitPotam (“little hippo” in French)
Figure 17. Multiple local privilege escalation tools detected and blocked by Cortex XDR.
MyComEop
As we analyzed several loaders recovered from organizations targeted by the Manic Menagerie 2.0 campaign, another finding caught our eye. These loaders included hard-coded strings for the files x and x.tmp. When executing these loaders in a debugger, they successfully decrypted their payloads, revealing yet another PoC LPE tool and backdoor, with distinctive PDB paths:
While searching for the PDB paths in VirusTotal, we found more notable metadata from two other variants, as shown in Figure 18.
Figure 18. File metadata retrieved from another variant sharing the same PDB path.
The product name and description translate to “protocol rights escalation tool” and “internal special edition.” Pivoting on the two different metadata components returned more similar variants with very similar PDB paths. Some of these variants are tagged with the CVE-2017-0213 tag in VirusTotal.
After further research, we found this is yet another rarely seen privilege escalation tool and backdoor, as shown in Figures 19a and 19b.
Figure 19a. Hardcoded paths from the described tool.Figure 19b. Backdoor logs from the described tool.
Back in the Game
In April 2023, while monitoring activity associated with Manic Menagerie 2.0, we began to see the threat actor deploying new modified tools and accessing compromised environments via a previously deployed web shell. This was found in addition to indicators of older tools being deployed in parallel, as well as updated tools, such as au.exe.
The attacker also searched for the presence of their iis_user by executing net commands. They then started deploying modified tools in the %programdata%\x path, which was also familiar behavior.
One of the tools they deployed is called GodPotato, shown in Figure 20, which is another variant of the known “potatoes” LPE family. This tool is also publicly available.
Figure 20. A screenshot from the GodPotato tool.
Another tool that we observed is yet another custom backdoor, shown in Figure 21. By looking at its PDB path, D:\project\后门类\dllnc\exenc\x64\Release\exenc.pdb, it appears to be a new variant to the aforementioned dllnc tool. This variant focuses on backdooring capabilities rather than serving mainly as a loader. “后门类” literally means “back door” when translated into English.
Figure 21. The main method of the new backdoor.
Conclusion
Unit 42 researchers uncovered an active campaign, which we have called “Manic Menagerie 2.0,” that targeted web hosting and IT companies for over two years. We believe the campaign was conducted by a threat actor whose previous endeavor was dubbed “Manic Menagerie.” The current campaign demonstrates an evolved iteration of that operation.
Unit 42 tracks the activity associated with this campaign under CL-CRI-0021. The threat actor associated with Manic Menagerie 2.0 is still active, continuing to change their TTPs to try to remain under the radar.
The main goal of the threat actor behind this operation appeared to be to abuse the resources of the compromised web servers for monetary gain. The threat actor deployed multiple coin miners in Manic Menagerie 2.0, as previously reported by the ACSC that they did in the original campaign.
Our investigation also revealed that the attackers expanded their arsenal and evolved their TTPs over time to hijack legitimate websites. They did this by mass deploying web shells to compromised sites at scale, which they could then use as C2 servers.
Protections and Mitigations
Palo Alto Networks customers receive protections from the campaign mentioned in this article through the following products and services:
Cortex XDR detects user and credential-based threats by analyzing user activity from multiple data sources including endpoints, network firewalls, Active Directory, identity and access management solutions, and cloud workloads. It builds behavioral profiles of user activity over time with machine learning. By comparing new activity to past activity, peer activity and the expected behavior of the entity, Cortex XDR detects anomalous activity indicative of credential-based attacks.
It also offers the following protections related to the attacks discussed in this post:
Prevents the execution of known malicious malware, and also prevents the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.
Protects against credential gathering tools and techniques using the new Credential Gathering Protection available from Cortex XDR 3.4.
Protects from threat actors dropping and executing commands from web shells using Anti-Webshell Protection, newly released in Cortex XDR version 3.4.
Protects against exploitation of different vulnerabilities including ProxyShell and ProxyLogon using the Anti-Exploitation modules as well as Behavioral Threat Protection.
If you think you might have been impacted or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200
Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Unit 42 researchers identified two Cobalt Strike Team Server instances hosted on the internet and uncovered new profiles that are not available on public repositories. We will highlight the distinct techniques attackers use to exploit the Cobalt Strike platform and circumvent signature-based detections.
We identified Team Server instances connected to the internet that host Beacon implants and provide command-and-control (C2) functionality. We have also extracted the Malleable C2 profile configuration from the Beacon binary to help us understand the various methods used to evade conventional detections.
The operators of the Cobalt Strike Team Servers attempted to conceal their C2 infrastructure behind benign and well-known services to evade detection. We have also found Team Server C2 infrastructure hosted on well-known public cloud infrastructure providers. The operators also deployed new Malleable C2 profiles. Threat and red team actors create new profiles to deceive security controls, bypass security measures and avoid detection. These tactics involve modifying HTTP URLs, header parameters and host headers with harmless and widely recognized domains.
Palo Alto Networks customers receive protections and mitigations for Cobalt Strike Beacon and Team Server C2 communication in the following ways:
The Next-Generation Firewall (NGFW) with an Advanced Threat Prevention subscription can identify and block Cobalt Strike HTTP C2 requests generated by custom profiles and block Cobalt Strike HTTP C2 requests and responses that are masked with the Base64-encoding settings of the default profile (signatures 86445 and 86446).
WildFire and Cortex XDR can identify and block Cobalt Strike Beacon binaries, and XDR will report related exploitation attempts.
Cobalt Strike is a highly effective platform used by professionals to simulate threats in enterprise network environments. Its primary objective is to establish a secure and undetectable communication channel between Beacon implants and the Team Server. With the use of Malleable C2, Cobalt Strike operators can easily create highly flexible and evasive network profiles, generating different C2 traffic with ease.
Unit 42 researchers have discovered two distinct tactics used by threat or red team actors to evade detections from current security controls. By examining these cases, we can better understand the techniques these people use to carry out harmful actions without raising any security alerts.
The case studies below are derived from true positive detection analysis. In the following scenarios, we identified Cobalt Strike Team Server infrastructure, extracted Malleable C2 profile configuration information and reconstructed the configuration and implant data for use in detection improvements.
Case 1: Brand New Profile
Cobalt Strike has a well-documented custom profile language. Attackers and red teamers tend to craft well-designed and unique Malleable C2 profiles to conduct their operations, aiming to bypass security filters that look for known public Malleable C2 profiles.
We found a Team Server running on 23.95.44[.]80:80 that hosted a Beacon file with the SHA-256 hash 22631d171fd7d531c0bc083a5335a910a95257e3194b50d8b471740d3a91fe34. We used internal tools to derive and reconstruct the Malleable C2 profile from the configuration extracted from the Beacon binary.
Figure 1 shows an extracted and recreated custom profile. The left half of the image shows the GET transaction and the right side shows the POST transaction of the Beacon communication.
The encrypted and encoded data in the GET transaction is placed in a Cookie Parameter SESSIONID. The ID in the POST transaction is added to the custom header User. The ID is double encoded using Mask and NetBIOSU. The output from the task execution is also double encoded and appended to the data parameter in the POST body.
Security vendors use elements of HTTP traffic to determine if a given flow is suspicious or malicious. If the domain in the Host header of an HTTP request is on a ranked list of popular domains, some malicious criteria could be discarded as the request might be identified as benign. Similarly, if the destination server belongs to a well-known cloud provider, that IP address could be on the allow list and considered benign.
Attackers use these detection criteria to their advantage by generating HTTP request traffic to mimic known good services in order to evade identification. We routinely catch Malleable C2 profiles that mimic well-known benign websites such as e-commerce sites, search engines and email providers.
Case 2.1: Host with Benign/Famous Domain to Evade Security Detection
Attackers often use forged host headers to generate traffic that appears to be benign, thus evading network security inspection. However, this traffic can still be identified as malicious when inspected by an expert.
Figure 2 shows a Beacon sample using a modified Malleable C2 profile hosted on GitHub. The person intended to disguise the malicious traffic as benign traffic from a highly reputable website. However, the ASN record for the destination IP address shows a different owner, confirming the deception.
Figure 2. Malleable C2 Profile with forged HTTP Host header.
Case 2.2: Destination IP Used from Public Cloud to Evade Security Detection
This example shows how threat or red team actors can use public cloud platforms as a C2 server. Generally, these cases are hard to detect by IP reputation services such as VirusTotal or URL filtering products due to the benign nature of the service provider.
Penetration testers are well aware of the popularity of online services and use them to their advantage. They can hide payloads in seemingly harmless services, making it harder to detect malicious activity.
Unit 42 researchers identified a Team Server on the IP 35.224.140[.]15:443 that hosted the Cobalt Strike Beacon with the SHA-256 hash 3ac4be4291bddaaa39a815cc05ece6d611cd69a1604fec8dec0f7e5451659cfa. The Team Server IP belongs to a prominent cloud provider.
Figure 3 shows the Malleable C2 profiles recreated from the Beacon binary hosted on the Team Server instance. The Team Server was running on a well-known cloud provider.
Figure 3. Malleable C2 Profile using a known public cloud service.
Conclusion
Cobalt Strike is a highly versatile tool, and most security vendors struggle to detect its C2 traffic accurately. This makes Cobalt Strike an ideal choice for attackers looking to increase their malware's chances of success.
We are continuously discovering new Team Servers that host active Beacon binaries. This threat hunting has proven fruitful against the misuse of Cobalt Strike in cyberattacks. The continuous cycle of scanning and learning helps us remain vigilant and provide active defenses against cybercrime.
Palo Alto Networks customers receive protection from the attack above with the following products:
The Next-Generation Firewall with an Advanced Threat Prevention subscription can identify and block the Cobalt Strike HTTP C2 request in nondefault profiles. ATP signatures 86445 and 86446 can identify HTTP C2 requests with the Base64 metadata encoding in default profiles.
WildFire, an NGFW security subscription and Cortex XDR identify and block CobaltStrike Beacon.
Cortex XSOAR response pack and playbook can automate the mitigation process.
Cortex XDR will report related exploitation attempts.
Since March 2023, Unit 42 researchers have observed threat actors leveraging several IoT vulnerabilities to spread a variant of the Mirai botnet. The vulnerabilities exploited include those listed in the following table:
The threat actors have the ability to gain complete control over the compromised devices, integrating those devices into the botnet. These devices are then used to execute additional attacks, including distributed denial-of-service (DDoS) attacks.
On March 14, 2023, Unit 42 researchers observed some remote command execution exploit traffic from our internal threat-hunting system, originating from 185.44.81[.]114. The threat actor tried to download a shell script downloader as a file named y from hxxp://zvub[.]us/.
If executed, the shell script downloader would download and execute the following bot clients to accommodate different Linux architectures:
hxxp://185.225.74[.]251/armv4l
hxxp://185.225.74[.]251/armv5l
hxxp://185.225.74[.]251/armv6l
hxxp://185.225.74[.]251/armv7l
hxxp://185.225.74[.]251/mips
hxxp://185.225.74[.]251/mipsel
hxxp://185.225.74[.]251/sh4
hxxp://185.225.74[.]251/x86_64
hxxp://185.225.74[.]251/i686
hxxp://185.225.74[.]251/i586
hxxp://185.225.74[.]251/arc
hxxp://185.225.74[.]251/m68k
hxxp://185.225.74[.]251/sparc
After executing the bot client, the shell script downloader will delete the client executable file to cover its tracks.
Unit 42 researchers conducted an analysis of the malware host domain and found out there are two IP addresses corresponding to the domain zvub[.]us:
185.44.81[.]114 (From Aug. 15, 2022, to March 24, 2023)
185.225.74[.]251 (After March 25, 2023)
Upon conducting a thorough retrospective analysis, we noticed telnet brute force attempts from 185.44.81[.]114 since Oct. 6, 2022, and attempts to exploit multiple vulnerabilities since March 14, 2023.
Unit 42 researchers also noticed another campaign from source IP 193.32.162[.]189 since April 11, 2023, that delivers the same shell downloader from zvub[.]us, as shown in Figure 1. Based on our analysis, we believe that the same threat actor operated these two campaigns for the following reasons:
The two campaigns share the same infrastructure.
The botnet samples are almost identical.
Figure 1. Vulnerability exploit attempts.
Figure 2 is a diagram illustrating the campaign overview.
Figure 2. Campaign overview diagram.
Malware Analysis
Based on behavior and patterns Unit 42 researchers observed while analyzing the downloaded botnet client samples, we believe the sample is a variant of the Mirai botnet.
Upon execution, the botnet client prints listening tun0 to the console. The malware also contains a function that ensures only one instance of this malware runs on the same device. If a botnet process already exists, the botnet client will terminate the current running process and start a new one.
For the botnet client configuration string, the Mirai variant (like IZ1H9 and V3G4) will first initialize an encrypted string table and then retrieve the strings through an index. However, this Mirai variant will directly access the encrypted strings in the .rodata section via an index (as shown in Figure 3).
Also, notice that for Mirai variants like IZ1H9 and V3G4, the configuration contains a string that indicates the branch name of this variant (for example, /bin/busyboxIZ1H9) while this variant does not have a branch name.
For the configuration decryption, this Mirai variant first uses a table key 0xDEADBEEF to generate a single-byte config decryption key 0x22, then for the encrypted configuration, the malware performs XOR decryption with the following bytewise operations:
encrypted_char ^ 0x22 = decrypted_char
During the analysis, Unit 42 researchers noticed that this Mirai sample doesn’t contain the functionality to brute force telnet/SSH login credentials and exploit vulnerabilities, which means the only channels for spreading this variant are the botnet operator’s manual vulnerability exploitation attempts.
Conclusion
The widespread adoption of IoT devices has become a ubiquitous trend. However, the persistent security concerns surrounding these devices cannot be ignored. The Mirai botnet, discovered back in 2016, is still active today. A significant part of the reason for its popularity among threat actors lies in the security flaws of IoT devices.
These remote code execution vulnerabilities targeting IoT devices exhibit a combination of low complexity and high impact, making them an irresistible target for threat actors. As a result, protecting IoT devices against such threats becomes an urgent task.
To combat this threat, it is highly recommended that patches and updates are applied when possible.
Palo Alto Networks customers receive protection against vulnerabilities and malware through the following products and services:
The Palo Alto Networks IoT security platform can leverage network traffic information to identify the vendor, model and firmware version of a device and identify specific devices that are vulnerable to the aforementioned CVEs.
In addition, IoT Security has an inbuilt machine learning-based anomaly detection that can alert the customer if a device exhibits nontypical behavior, such as the following:
The sudden appearance of traffic from a new source
An unusually high number of connections
An inexplicable surge of certain attributes typically appearing in IoT application payloads
Palo Alto Networks has shared our findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
This malicious traffic was first detected as a part of the campaign on March 14, 2023. The command execution vulnerability is due to the failure to sanitize the value of x509type in the kerbynet component of Zeroshell
We captured this exploit traffic on May 1, 2023. The exploit targets a command injection vulnerability in the D-Link wireless router’s /gena.cgi component, which does not successfully sanitize the user input in the service parameter. This leads to arbitrary command execution.
The exploit was detected on April 11, 2023. The exploit works due to the D-Link wireless router admin.cgi component failing to adequately sanitize the user-supplied input data, which leads to remote command execution.
Figure 6. CVE-2019-20500 exploit in the wild.
CVE-2021-25296: Nagios XI Remote Command Injection Vulnerability
We observed this exploit traffic on April 11, 2023. The exploit targets the Nagios XI device’s /nagiosxi/config/monitoringwizard.php component. If insufficient input validation is found, the attacker can exploit the vulnerability to launch a remote command injection attack.
The malicious traffic was first detected on March 14, 2023. The command injection vulnerability is due to the failure to sanitize the value of the cmd parameter in the cgi-bin/admin.cgi interface of the Telesquare router.
We captured this exploit traffic on April 14, 2023. The exploit targets a command injection vulnerability in the Arris TR3300’s user.cgi component, which does not successfully sanitize the user input in the DDNS_HOST parameter. This leads to a command injection.
This exploit was detected on March 15, 2023. The exploit works due to the SolarView Compact confi_mail.php component failing to adequately sanitize the user-supplied input data, which leads to command injection.
We observed this exploit traffic on March 14, 2023. The exploit targets the Tenda HG9 router’s /boaform/formPing component. If insufficient input validation is found, the attacker can exploit the vulnerability to launch a remote code execution attack
This malicious traffic was first detected on March 14, 2023. The command injection vulnerability is due to the failure to sanitize the value of the mtu parameter in the /cgi-bin/handler interface of Zyxel.
Figure 12. CVE-2022-30525 exploit in the wild.
CVE-2022-31499: Nortek Linear eMerge Command Injection Vulnerability
We captured this exploit traffic on May 1, 2023. The exploit targets a command injection vulnerability in the Nortek Linear eMerge device’s card_scan.php component, which does not successfully sanitize the user input in the ReaderNo parameter. This leads to remote command injection.
Figure 13. CVE-2022-31499 exploit in the wild.
CVE-2022-37061: FLIR AX8 Unauthenticated OS Command Injection Vulnerability
This exploit was detected on May 1, 2023. The exploit works due to the FLIR AX8 device’s res.php component failing to adequately sanitize the user-supplied input data, which leads to OS command injection.
We observed this exploit traffic on March 15, 2023. The exploit targets the Intelbras WiFiber device’s /boaform/formPing6 component. If insufficient input validation is found, the attacker can exploit the vulnerability to launch a command injection attack.
This malicious traffic was first detected on April 12, 2023. The remote command execution vulnerability is due to a failure to sanitize the value of the timezone parameter in the /management/set_timezone.
We captured this exploit traffic on April 12, 2023. The exploit targets a command injection vulnerability in the TP-Link Archer router’s cgi-bin/luci component, which does not successfully sanitize the user input in the country parameter. This leads to arbitrary command execution.
The exploit was detected on April 11, 2023. The exploit works due to the D-Link device /ping.ccp component failing to adequately sanitize the user-supplied input data, which leads to a command injection vulnerability.
We observed this exploit traffic on April 12, 2023. The exploit targets the Tenda AX3 router’s /goform/AdvSetLanip component. If insufficient input validation is found, the attacker can exploit the vulnerability to launch a remote command injection attack.
This exploit traffic was detected on March 14, 2023. The exploit targets a remote code execution in multiple CCTV/DVR devices’ /language components. The component does not successfully sanitize the value of the HTTP parameter.
We detected this exploit traffic on April 12, 2023. The exploit works due to the /cgi-bin/usbinteract.cgi component of the EnGenius EnShare device failing to sanitize the value of the HTTP parameter path.
This malicious traffic was captured on April 11, 2023. The exploit works due to the MVPower DVR failing to sanitize user input, which in turn could lead to remote command execution.
We captured this exploit traffic on March 14, 2023. The exploit targets the setup.cgi component of Netgear DGN1000. The component does not sanitize the value of the HTTP parameter cmd, which leads to remote code execution.
We observed this exploit traffic on March 14, 2023. The exploit targets the Vacron NVR device’s board.cgi component. If insufficient input validation is found, the attacker can exploit the vulnerability to launch a remote code execution attack.
The exploit traffic was first detected as a part of a campaign on April 12, 2023. The remote code execution vulnerability is due to the failure to sanitize the value of the SYSLOGD_REMOTE_HOST parameter in the user.cgi interface of a MediaTek WiMAX device.
After seeing reports of two similar privilege escalation vulnerabilities in Microsoft Windows – CVE-2021-1732 and CVE-2022-21882 – we decided to analyze both to better understand the code involved in each. This is a continuation of Inside Win32k Exploitation, in which we discussed the Win32k internals and exploitation in general as background information to explore the issues surrounding CVE-2021-1732 and CVE-2022-21882.
Here, we will dig deeper into CVE-2021-1732 and CVE-2022-21882 and their related proof-of-concept (PoC) exploits. We’ll walk through an analysis of these two exploits, and thus see why the patch for CVE-2021-1732 was not sufficient to prevent CVE-2022-21882.
Both vulnerabilities discussed in this series are detected and blocked by the Cortex XDR Anti-LPE protection module. Both vulnerabilities are data-only exploits that copy the NT/Authority System privilege token to that of the current (exploit) process for privilege escalation. The XDR Anti-LPE modules monitor for this specific type of privilege escalation technique.
In this section we’ll discuss two Win32k PoC exploits, CVE-2021-1732 and CVE-2022-21882. Both of these vulnerabilities abused xxxClientAllocWindowClassExtraBytes and NtUserConsoleControl to overwrite the tagWND.cbWndExtra data field of an adjacent window to a large value, allowing for an arbitrary write primitive. They each use this arbitrary write to create a fake spmenu in the adjacent window, and then use GetMenuBarInfo to create an arbitrary read primitive. The arbitrary read/write primitives are then used to copy the NT/AUTHORITY SYSTEM token to the current (exploited) process.
We analyze the CVE-2022-21882 PoC in detail, and we’ll discuss CVE-2021-1732 during relevant sections of this analysis to explain how it differs from CVE-2022-21882. Then we’ll discuss why the patch Microsoft issued for CVE-2021-1732 wasn’t sufficient to prevent CVE-2022-21882.
The reason we decided to spend more time discussing CVE-2022-21882 is because there are several blogs with a detailed analysis of CVE-2021-1732 by Google and DBAPPSecurity Threat Intelligence Center.
Both of these exploits are examples of data-only attacks, which means they only require a read/write primitive and do not execute any attacker controlled code. These types of exploits are becoming more common due to the increased difficulty of bypassing modern-day exploit mitigations being deployed within the latest operating systems.
Microsoft did release a patch for Windows 11 for this vulnerability as well. The PoC we are analyzing here was tested on Windows 10 version 21H2.
Triggering the vulnerability
Historically, exploit authors have relied heavily on abusing tagWND or bitmap objects to implement read/write primitives. As we mentioned earlier, Microsoft has gone through great pains to make abusing these objects much more difficult. Specifically, as of Windows 10 version 1703, using SetWindowLong only changes the ExtraBytes field in the user-mode copy of the desktop heap and not the kernel desktop heap, except when operating on a console window.
To get past this limitation, both vulnerabilities rely on changing a window to a console window during a user-mode callback by calling NtUserConsoleControl at a time when the Windows operating system is not expecting it. As a result of converting the window to a console window, this function adds 0x800 to the tagWND.dwExtraFlag mask to indicate that the tagWND.pExtraBytes field is now an offset into the kernel rather than a user-mode pointer.
Because Windows did not have any checks in place to verify window types, when SetWindowLong is called on this window, it will now make changes to the kernel desktop heap just like it did before Windows 10 version 1703. Let’s take a look at how this is implemented by walking through a PoC for CVE-2022-21882.
Store pointers to xxxClientAllocWindowClassExtraBytes and xxxClientFreeWindowClassExtraBytes
Define a couple of window classes
Groom the heap
Create some windows
Leak user-mode tagWND locations with HMValidateHandle
Leak user-mode tagWND locations with HMValidateHandle
Calculate offsets between windows
Call NtUserConsoleControl on lowest window address
Create a third (magic) window
Hook xxxClientAllocWindowClassExtraBytes with a malicious version that calls NtUserConsoleControl and NtCallbackReturn, then returns to the real xxxClientAllocWindowClassExtraBytes
Use NtUserMessageCall to trigger the hooked function on WndMagic
Use SetWindowlongA to create an arbitrary write primitive
Use SetWindowLongPtrA to leak Wnd1’s spmenu kernel address and replace it with a fake spmenu object
Use arbitrary read/write to clone system token
Create a new process with System privileges and fix up any changed kernel values
In the next section, we will begin to walk through this summary, starting with steps 1-5.
![Image 10 is an example Mallox ransomware note. Hello, your files are encrypted and cannot be used. To return your files in work condition you need decryption tool. Follow the instructions to decrypt all your data. Do not try to change or restore files yourself, this will break them. If you want, on our site, you can decrypt one file for free. Free test decryption allowed only for not valuable file with size less than 3MB. How to get decryption tool: 1. Download and install Tor browser by this link [Tor link]. 2: If Tor blocked in your country and you can't access to the link use any VPN software. 3. Run Tor browser and open the site. 4. Copy your private ID in the input field. Your private key (this portion is blurred). 5. You will see payment information and we can make free test decryption here. Our blog of leaked companies [this is an Onion link]. If you are unable to contact us through the site, then you can email us: [this is an email at onionmail[.]org.] If you are unable to contact us through the site, waiting for a response via email can be several days. Do not use it if you have not tried contacting through the site.](https://unit42.paloaltonetworks.com/wp-content/uploads/2023/07/word-image-129264-10.png)
Get updates from Unit 42 