Recent August-October 2022 observations of exploits used in the wild reveal that threat actors have been leveraging significant numbers of attacks against the Realtek Jungle SDK remote code execution vulnerability (CVE-2021-35394).
In our observations of network security trends, Unit 42 researchers have pinpointed several attacks based on proof-of-concept (PoC) availability and impact. We have detailed below which of these we believe should be on a defender’s radar.
Other insights that could assist defenders include the following:
Rankings of the most commonly used attack techniques and the types of vulnerabilities that attackers have recently favored. For example, among 5,190 newly published vulnerabilities, a large portion (almost 9.8%) involves cross-site scripting.
Lists of major vulnerabilities identified by evaluating more than 232 million attack sessions including remote code execution.
Insight into how these vulnerabilities are exploited in the wild based on real-world data collected from our Next-Generation Firewalls.
Summaries of key trends from August-October 2022.
Analysis of the most recently published vulnerabilities, including the severity and attack origin distribution.
Classification of these vulnerabilities to provide a clear view of the prevalence of the different types, such as cross-site scripting or SQL injection.
Lists of the most commonly exploited vulnerabilities attackers are using, as well as the severity, category and origin of each attack.
Palo Alto Networks customers receive protections from the vulnerabilities discussed here through the Next-Generation Firewall and associated Cloud-Delivered Security Services including Threat Prevention, WildFire and Advanced URL Filtering. Protections are also available from Prisma Cloud’s Web Application and API Security (WAAS) and Cortex XDR.
Analysis of Published Vulnerabilities, August-October 2022
From August-October 2022, a total of 5,190 new Common Vulnerabilities and Exposures (CVE) numbers were registered. To better understand the potential impact these newly published vulnerabilities could have on network security, we provide our observations based on the severity, availability of working proof-of-concept (PoC) code, and vulnerability categories.
How Severe Are the Latest Vulnerabilities?
To estimate the potential impact of vulnerabilities, we consider their severity and examine any reliable PoCs available that attackers could easily launch. Some of the public sources we use to find PoCs are Exploit-DB, GitHub and Metasploit. Distribution of the 5,190 CVEs that have an assigned severity score of medium or higher can be seen in the following table:
Severity
Count
Ratio
Ratio Change From Last Quarter %
PoC Availability
Change in PoC Availability
Critical
980
18.9%
-0.1%
2.9%
-2.6%
High
2184
42.1%
+2.0%
2.2%
-1.6%
Medium
2026
39.0%
-1.9%
2.3%
-1.1%
Table 1. Severity distribution for CVEs registered August-October 2022, including only those rated medium to critical.
Figure 1. Severity distribution for CVEs registered August-October 2022, including only those rated medium to critical.
Our classification of vulnerability levels is based on CVSS v3 scores. Many conditions must be met to rate a vulnerability as critical, so there are very few at this level. One of the common factors for rating a vulnerability at this level is whether it has a working PoC available. To be considered critical, vulnerabilities generally have low attack complexity, and it is often easy to create a PoC to exploit them.
In the period we discuss here, PoC ratios decreased slightly for all severity levels.
Vulnerability Category Distribution
It is crucial to understand each type of vulnerability and its consequences. Out of the newly published CVEs that were analyzed, 26.6% are classified as local vulnerabilities, requiring prior access to compromised systems, while the remaining 73.4% are remote vulnerabilities, which can be exploited over a network. This means that most newly published vulnerabilities introduce potential opportunities for threat actors to attack vulnerable organizations from anywhere in the world.
In Figure 2, the most common vulnerability types are ranked by how prevalent they were among the most recent set of published vulnerabilities.
Figure 2. Vulnerability category distribution for CVEs registered August-October 2022.
Cross-site scripting remains the most reported vulnerability during August-October 2022. We also saw that the prevalence of buffer overflow vulnerabilities increased during this time. The number of new vulnerabilities of other types, such as cross-site scripting and denial-of-service, has decreased. Most of the recently published cross-site scripting and information disclosure vulnerabilities are usually at medium or high severity (rather than critical).
Figure 3. Vulnerability category distribution compared with the previous quarter.
Network Security Trends: Analysis of Exploits in the Wild, August-October 2022
Data Collection
By leveraging Palo Alto Networks Next-Generation Firewalls as sensors on the perimeter, Unit 42 researchers observed malicious activities from August-October 2022. The malicious traffic we identified is further processed and based on metrics such as IP addresses, port numbers and timestamps. This ensures the uniqueness of each attack session and thus eliminates potential data skews. We analyzed 232 million valid malicious sessions and then correlated the refined data with other attributes to infer attack trends over time to get a picture of the threat landscape.
How Severe Were the Attacks Exploited in the Wild?
To arrive at 232 million valid malicious sessions, we excluded the original set of low-severity signature triggers used to detect scanning and brute-force attacks, as well as internal triggers used for research purposes. Therefore, we consider exploitable vulnerabilities with a medium and higher severity ranking (based on the CVSS v3 Score) as a verified attack.
Figure 4. Attack severity distribution, August-October 2022, including only medium-critical vulnerabilities.
Figure 4 shows the ratio of attacks grouped by the severity of each vulnerability. Compared with the previous quarters' severity distribution, this quarter shows an increase in critical attacks. We further analyzed the data and found that the attacks against the Realtek Jungle SDK remote code execution vulnerability (CVE-2021-35394) accounted for 71.4% of all critical attacks, accounting for 41.8% of the total number of attacks.
Figure 5. Vulnerability severity distribution compared with the previous quarter.Figure 6. Proportion of attacking CVE-2021-35394. Numbers are rounded to the nearest million.
When Did the Network Attacks Occur?
Figure 7. Severity of exploits in the wild measured weekly from August-October 2022.
During August-October 2022, there has been a spike in critical attacks over several weeks, most likely related to the increase in attacks referenced in the previous section, and a slight increase in attacks exploiting medium-severity vulnerabilities in September. There were no significant fluctuations in the number of attacks of other severities at other times.
As we’ve seen in the past, attackers frequently use recently disclosed vulnerabilities, especially those from 2021-2022. This shows the importance of updating security products and applying software patches as soon as they become available to protect against the most recently discovered vulnerabilities. Due to the extremely large number of attacks exploiting the Realtek Jungle SDK remote code execution vulnerability (CVE-2021-35394), the distribution of CVE numbers in attacks in the wild this quarter has been dramatically different from that of previous quarters.
Figure 8. Observed attacks broken down by the year in which the exploited CVE was disclosed, measured weekly from August-October 2022.
Attack Category Distribution
We classified each network attack by category and organized them in terms of prevalence. In the period discussed, remote code execution ranks first, followed by traversal.
Figure 9. Attack category and severity, August-October 2022.
Compared with the previous quarter, due to the aforementioned Realtek Jungle SDK remote code execution vulnerability being greatly exploited, this quarter's remote code execution increased sharply. In addition, traversal rose almost double compared to the previous quarter, and information disclosure fell by almost a third of the previous quarter.
Where Did the Attacks Originate?
After identifying the region from which each network attack originated, we discovered that the majority of them seem to originate from the United States, followed by Vietnam then Russia. Attacks from Vietnam increased significantly this quarter. However, we recognize that the attackers might leverage proxy servers and VPNs located in those countries to hide their actual physical locations.
Figure 10. Locations ranked in terms of how frequently they were the origin of observed attacks from August-October 2022.Figure 11. Attack originate distribution compared to the previous quarter.Figure 12. Attack geolocation distribution from August-October 2022.
Conclusion
The vulnerabilities disclosed from August-October 2022 indicate that web applications remain popular targets for attackers, and that critical vulnerabilities are more likely to have PoCs publicly available.
In the meantime, we continue to capture newly published vulnerabilities that are exploited in the wild. This emphasizes the need for organizations to promptly patch their systems and implement security best practices. Attackers continue to make a concerted effort to expand their tool kit of exploits whenever possible.
Run a Next-Generation Firewall to identify where your configuration could be altered to improve your security posture.
Run a Security Lifecycle Review to get a consolidated view of your largest threats and if you have coverage to prevent them.
Continuously update your Next-Generation Firewalls with the latest Palo Alto Networks Threat Prevention content (e.g., versions 8649 and above).
Prisma Cloud customers using WAAS receive protection from these threats through the App Firewall feature, which detects attacks such as cross-site scripting, SQL injection, directory traversals and more.
After hearing the community's feedback about the prerequisites of the exploitation scenario of the vulnerability, we made the decision to work with Auth0 to retract CVE-2022-23529.
The security issue described in this blog remains a concern when the JsonWebToken library is used in an insecure way. In that scenario, if all the prerequisites are met, the issue may be exploitable. We agree that the source of this risk in that case will be in the calling code, and not in the library.
Important security checks were added to the JsonWebToken code to address this issue.
Users of jsonwebtoken 8.5.1 and earlier are encouraged to update to the latest version, 9.0.0, which presents safer code that fixes this security flaw and others, and prevents misuse of the package that was presented in this blog.
We want to thank Auth0 for their work to address the security issue, as well as the security community for the interest and feedback. We would also like to thank GitHub for their help. The update can be read on the Auth0 GitHub.
Jan. 12, 2023
After receiving feedback from the community, we decided to make some clarifications regarding possible exploitation. We originally mentioned that an attacker needs to have control over the secret manager and decided that there was a practical need to make this even more clear in our language and associated figures.
Executive Summary
Unit 42 researchers discovered a new vulnerability in the popular JsonWebToken open source project. The vulnerability is identified as CVE-2022-23529, rated high severity (CVSS 7.6).
By exploiting this vulnerability, attackers could achieve remote code execution (RCE) on a server verifying a maliciously crafted JSON web token (JWT) request. This vulnerability requires several prerequisites in order to be exploitable, which makes it less likely for an attacker to use it in the wild.
If you are using JsonWebToken 8.5.1 or an earlier version, we suggest updating to JsonWebToken version 9.0.0, which includes a fix for this vulnerability.
JsonWebToken is an open source JavaScript package that allows you to verify/sign JWTs, which are mainly used for authorization and authentication purposes. Developed and maintained by Auth0, the package had over 9 million weekly downloads at the time of writing, and over 20,000 dependents (according to the JsonWebToken page). This package plays a big role in the authentication and authorization functionality for many applications.
Palo Alto Networks customers can identify assets that are running vulnerable versions of the JsonWebToken package with Prisma Cloud, and they can identify the relevant CVE within scan results.
JWT (pronounced “jot”) is an open standard that defines a method of transferring information securely by encoding and signing JSON data. JWTs have a string structure that consists of 3 parts separated by a dot (.):
Header.Payload.Signature
JWTs are used to transmit different types of information, but are mainly used to deliver “claims,” which are pieces of information about some subject. In practice, this will most likely contain useful information about a user.
The most common use case of JWTs is for authorization and authentication. Let’s quickly go over the JWT structure.
JWT Header
As shown in Figure 1, the header consists mostly of two parameters that indicate the type of the token and the signing algorithm.
Figure 1. JWT header.
JWT Payload
The payload (shown in Figure 2) is the second part of the token, which will contain the claims. In most cases, this will provide useful information about a user.
Figure 2. JWT payload.
There are three different types of claims: registered, public and private. You can find more information about them in RFC 7519.
The header and payload are each Base64Url encoded to form the first and second parts of a JWT string (Header.Payload.Signature):
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 and eyJ1c2VyX25hbWUiOiJKb2huIERvZSIsImFkbWluIjp0cnVlfQ.
The third part of the JWT, the signature, is then computed (signed) by the following formula using a secret key. A signature is used to verify that the token isn’t forged or manipulated. Because it is signed with a secret key, we can validate the authenticity of the sender. Here is an example of a signature calculation:
Putting it all together, we will get a JWT in its complete form, as shown in Figure 3.
Figure 3. Full JSON web token.
How Does the Authentication Process Work?
Let’s take a look at a simple authentication process using a JSON web token (also shown in Figure 4):
To access a protected resource, the user will log in using credentials, usually username and password.
A request containing this information will be sent to the authentication server.
An authentication server will validate the information sent within a request and issue a JWT signed with a secret key, which can be stored on a server or in a different location using a secret manager.
From now on, each user request will contain a JWT in the authorization header. This way, users with the right permissions can receive access to protected resources.
When a user requests access to a protected resource, a request containing a JWT will be generated from the application to the JWT authentication server.
Before the user receives access to a requested resource, the JWT that was sent in the authorization header will be verified using the secret key. This is done to verify it was not tampered along the way and that the user has the right permissions to view the requested information. In the node.js JsonWebToken package, this is done with the verify() function.
Figure 4. Diagram of the process of authentication with JWT.
JWT and Open Source
Open source projects help a lot of organizations to save time and other resources. At times, this can serve as an elegant and quick problem solver. JWT became a very popular technology that many organizations rely on, and this is one of the reasons that some of the open source projects implementing JWT have become a great success.
One such project is a well-known JavaScript solution for signing, verifying and decoding JWTs named JsonWebToken. This tool is developed and maintained by Auth0, part of Okta.
The Vulnerability (CVE-2022-23529)
Typically, attacks on JWT will involve different forgery techniques abusing buggy JWT implementations. These kinds of attacks have severe consequences because, in most cases, a successful attack allows an attacker to bypass authentication and authorization mechanisms to access confidential information or steal and/or modify data.
One of the methods provided by the JsonWebToken package is verify. The verify method receives three parameters: token, secretOrPublicKey and options. This function verifies the validity of the JWT and returns the decoded payload part.
According to the documentation, secretOrPublicKey is a string or buffer. We can see the lines of code shown in Figure 5 in the JsonWebToken verify.js source code.
Figure 5. Code snippet from verify.js.
When no allowed algorithms are provided within the options algorithms list, the values within the privacy enhanced mail (PEM) file, which is provided by the secretOrPublicKey parameter, will be assigned instead. This presents a problem: There is no check in place that secretOrPublicKey is actually a valid PEM file’s content, and this unverified object’s toString method is blindly being used. Attackers with control over this object can supply their own toString method, which will then be executed by JsonWebToken’s verify in line 114.
Let's observe the following scenario, using node.js (a JavaScript runtime environment) version 18.9.1 and JsonWebToken package version 8.5.1, and see what will happen if we pass a malicious object to the verify function via the secretOrPublicKey parameter and override its toString() method.
Figure 6. Arbitrary Write File PoC.
Our malicious code will execute and exit the node process before the .includes(‘BEGIN CERTIFICATE’)check in the verify function, resulting in an arbitrary write file on the hosting machine.
Figure 7. PoC result, file created.
With the same technique, it is possible to achieve RCE, but we will have to slightly modify our payload by using the child_process module (as shown in Figure 8).
Figure 8. RCE PoC.
Secrets can be stored outside of the authenticating server – for example, they can be kept within a secret manager in a different location. An attacker that only had write access to the secret manager can now execute code on the authentication server. If there was a check in place that the malicious object was a valid secret, code execution was not possible.
Exploitation Prerequisites
In the previous section, we demonstrated how a poisoned secret key could lead to an RCE. In reality, keeping and maintaining secret keys usually involves secret managers, secret key rotations, encryption and other best practices.
In order to exploit the vulnerability described in this post and control the secretOrPublicKey value, an attacker will need to have control or exploit a flaw within the secret management process. Even then, exploitation might be complicated as the output of a secret manager is uncertain. It can be of a type not suited for an exploitation (a string, for example) or many other possible scenarios.
Due to the complexity of exploitation of this vulnerability, we initially suggested a CVSS score of 6.6. However, we decided to accept the CVSS calculation made by the vendor, which yielded a higher severity of 7.6.
JsonWebToken Fix
JsonWebToken version 9.0.0 contains the following fix:
Figure 9. Patch.
The vulnerable code was removed and replaced with checks for the type of secretOrPublickey parameter, which prevents secretOrPublicKey from containing malicious objects.
Disclosure Process
July 13, 2022 – Unit 42 researchers sent a disclosure to the Auth0 team under responsible disclosure procedures
July 27, 2022 – Auth0 team updated that the issue was under review
Aug. 23, 2022 – Unit 42 researchers sent an update request
Aug. 24, 2022 – Auth0 team updated that the engineering team was working on the resolution
Dec. 21, 2022 – A patch was provided by the Auth0 engineering team
Conclusion
Open source projects are commonly used as the backbone of many services and platforms today. This is also true for the implementation of sensitive security mechanisms such as JWT, which play a huge role in authentication and authorization processes.
Security awareness is crucial when using open source software. Reviewing commonly used security open source implementations is necessary for maintaining their dependability, and it's something the open source community can take part in.
As part of the commitment of Palo Alto Networks to open source software security, we regularly conduct security research efforts that include identifying security vulnerabilities in open source projects.
Palo Alto Networks Prisma Cloud customers can detect affected images and hosts under the Vulnerabilities tab. The platform detects JsonWebToken packages and alerts on entities running with a vulnerable version. In addition, our users can search for CVE-2022-23529 in the Vulnerability Explorer section to discover more details about the vulnerability and assets affected by it.
We would like to thank the Auth0 team for professionally handling the disclosure process and providing a patch for the reported vulnerability.
Updated January 12, 2023, at 3:31 p.m. PT.
Updated January 30, 2023, at 7:20 a.m. PT.
Unit 42 researchers perform a deep dive into Automated Libra, the cloud threat actor group behind the freejacking campaign PurpleUrchin. Automated Libra is a South African-based freejacking group that primarily targets cloud platforms offering limited-time trials of cloud resources in order to perform their cryptomining operations.
Freejacking is the process of using free (or limited-time) cloud resources to perform cryptomining operations.
Key Points:
In order to take advantage of the limited resources offered by free trials, the actors heavily leveraged DevOps automation techniques such as continuous integration and continuous delivery (CI/CD). They accomplished this by containerizing user account creations on cloud platforms and through automating their cryptomining operations.
We collected more than 250 GB of container data created for the PurpleUrchin operation and discovered that the threat actors behind this campaign were creating three to five GitHub accounts every minute during the peak of their operations in November 2022.
We also found that some of the automated account creation cases bypassed CAPTCHA images using simple image analysis techniques. We also identified the creation of more than 130,000 user accounts created on various cloud platform services like Heroku, Togglebox and GitHub.
We found evidence of unpaid balances on some of these cloud service platforms from several of the created accounts. This finding suggests that the actors created fake accounts with stolen or fake credit cards.
With this finding, we assess that the actors behind PurpleUrchin operations stole cloud resources from several cloud service platforms through a tactic Unit 42 researchers call “Play and Run.” This tactic involves malicious actors using cloud resources and refusing to pay for those resources once the bill arrives.
Palo Alto Networks customers receive protection from the events listed within the blog through the Prisma Cloud container vulnerability scanning and runtime protection policies.
The PurpleUrchin cryptomining campaign, first uncovered in October 2022, is characterized as a freejacking operation. While doing our own investigation of this threat actor, Unit 42 researchers found evidence that PurpleUrchin threat actors employed Play and Run tactics, using cloud resources and not paying the cloud platform vendor’s resource bill.
PurpleUrchin actors performed these Play and Run operations through the creation and use of fake accounts, with falsified or potentially stolen credit cards. These fake accounts held a pending unpaid balance. Although one of the largest unpaid balances we found was $190 USD, we suspect the unpaid balances in other fake accounts and cloud services used by the actors could have been much larger due to the scale and breadth of the mining operation.
Background
Unit 42 researchers analyzed more than 250 GB of data that included container data as well as system access logs by the actor (with geolocation information), and hundreds of indicators of compromise (IoCs). The IoCs collected during this research are published in the Unit 42 ATOM for Automated Libra.
The infrastructure architecture employed by the actors uses CI/CD techniques, in which each individual software component of an operation is placed within a container. This container operates within a modular architecture within the larger mining operation.
CI/CD architectures provide highly modular operational environments, allowing some components of an operation to fail, be updated, or even be terminated and replaced, without affecting the larger environment.
By analyzing the collected container data, we traced the actor’s activity back to August 2019. Their activity was spread across several cloud providers and crypto exchanges.
We also found that the actors have a preference for using cloud services via traditional virtual service providers (VSPs). Many traditional VSPs extend their service portfolio to include cloud-related services, such as Cloud Application Platform (CAP) and Application Hosting Platform (AHP). Some of the cloud service providers that offer CAP and AHP services that were targeted by the PurpleUrchin actors include Heroku and Togglebox, among others.
Unit 42 researchers identified more than 40 individual crypto wallets and seven different cryptocurrencies or tokens being used within the PurpleUrchin operation. We also identified that specific containerized components of the infrastructure the actors created were not only designed to perform mining functionality, but they also automated the process of trading the collected cryptocurrencies across several crypto trading platforms such as CRATEX ExchangeMarket, crex24 and Luno.
Mining With GitHub Workflows
The actor operations on GitHub used a combination of Play and Run and freejacking tactics. The likely reason the actors used GitHub is due to its decreased resistance in account creation. The actors were able to leverage a weakness within the CAPTCHA check on GitHub, which we discuss in more detail in the following section.
The actors automatically created GitHub accounts at an average rate of three to five accounts per minute. Once the actors had established their account base, they began their freejacking activity.
Each of the GitHub accounts was subsequently involved in a Play and Run strategy, where each account would use computational resources, but threat actors ultimately left their tabs unpaid. This appears to be a standard operational procedure for PurpleUrchin, as there is evidence that they created more than 130,000 accounts across various virtual private server (VPS) providers and cloud service providers (CSPs).
The actor also appeared to reserve a full server or cloud instances and they sometimes used CSP services such as AHPs. They did so in order to facilitate hosting web servers that were required to monitor and track their large-scale mining operations.
We have high confidence that some of the accounts created by this threat group were created using fake profiles and credit card information. This tactic allowed them to leave unpaid tabs with CSPs after their mining operations were completed.
Unit 42 researchers have found the actors behind PurpleUrchin appear to continuously evolve their operations such as refining their Play and Run and freejacking tactics.
Let’s look further into how the actors have refined the automation of account creations within GitHub.
Automating GitHub Account Creations
One of the threat actor’s latest deployments involved running Togglebox using AHP services. Togglebox is a fully managed solid-state drive (SSD) Cloud VPS and Application Hosting platform.
The actors used this platform to run a series of containers using the naming convention format repo_name/vgenerated_name:latest. Each container was capable of automatically creating GitHub accounts.
Researchers found a switch called “named” based accounts (meaning they were based on dictionary words) within the user account creation Python process, which was contained within the aforementioned container. This process uses randomly generated named accounts based on MD5 hashes.
The tools needed for the automatic account creation process were shipped as a container. In the latest version of the container, the actor combined several publicly available and legitimate tools to perform their operations, such as the following:
xdotool, a tool used to generate keyboard and mouse inputs
ImageMagick tool kit, used to convert, edit and compose digital photos
Once the necessary tools were in place, threat actors could begin creating accounts. The first step to creating a GitHub account is to populate the email address, password and username fields (as shown in Figure 1).
Figure 1. GitHub form completion process.
The container ran a virtual network computing (VNC) server on display:1 where the Iron Browser was launched with the following command, as shown in Figure 2.
Figure 2. Iron Browser display on VNC server.
Then using xdotool, the main script completed the GitHub form. After the form was completed, GitHub presented a CAPTCHA challenge as shown in Figure 3.
Figure 3. GitHub CAPTCHA challenge.
The actor implemented a very simple mechanism for solving this CAPTCHA. While we did not evaluate the effectiveness of this CAPTCHA solving process, in the following section, we will show statistics about how many GitHub accounts the actor was able to create in the span of three months. Based on this information, we think that this process (in combination with other tactics) was very effective.
Leveraging a CAPTCHA Weakness
To solve this particular CAPTCHA, which consists of identifying the spiral galaxies, the actor used two tools from the ImageMagick tools kit: convert and identify.
First, the images were converted into a red, green and blue (RGB) complemented image using the convert tool. Figure 4 shows an example of this conversion.
Figure 4. Converting image to an RBG complement.
Once the images were converted, the identify command was executed over each image to extract the “skewness” feature of the Red channel, as shown in Figure 5.
Figure 5. Command to extract the skewness feature of the Red channel.
The final result, shown in Figure 6, was arranged in order from largest to smallest, and the image with the smallest value was selected as the spiral image. For example, using the values for the previous images:
Figure 6. Example of Red channel outputs for each image.
In this case, Image 2 (from Figure 4) is identified as the spiral galaxy. Once the CAPTCHA is solved, GitHub requires a “launch code,” as shown in Figure 7.
Figure 7. GitHub requesting a launch code.
The actor used a Gmail account to automate the process of getting the launch code. They enabled this using Internet Message Access Protocol (IMAP) as well as a PHP script to read incoming IMAP messages.
Once the access code was entered, the automation generated a personal access token (PAT) with workflow permissions. The final result of the GitHub registering process was a username and PAT used for deploying workflows on GitHub. With the username and token, another container was invoked, as shown in Figure 8.
Figure 8. Invoking a running container.
This container subsequently performed the following actions:
Setting up SSH keys
Creating a GitHub repo using the GitHub API
Configuring the permissions for the created repo
As part of a naming convention change within more recent operations, the actor started to use random names for the repos, which were based on MD5 hashes. This followed the same convention as prior username creations. The command shown in Figure 9 demonstrates the naming convention process.
Figure 9. Random naming convention command.
Once the repo was created within GitHub, a Bash script was invoked to update the repo with the desired workflow. The workflow was generated using a PHP script that worked as a template for randomizing the differently named attributes of the workflow configuration. Figure 10 provides an example of how the workflow PHP template was coded.
Figure 10. PHP template for randomizing script attributes.
In one version we observed, the workflow (generated from a template shown in Figure 10) had 64 jobs. The generated workflows were configured to run as a repository_dispatch under the event github.event.client_payload.app.
This workflow mechanism allowed the actors to execute external applications. In this case, the actor was running external Bash scripts and containers, as shown in Figure 11.
Figure 11. Workflow mechanism to execute external applications.
The workflow runs the Bash script that is accessed from an external domain. During the last design change we observed, the actor built and ran containers that were used to install and initiate the cryptomining functionalities, as shown in Figure 12.
Figure 12. Remote establishment of mining containers.
The generated workflow ran 64 jobs, and each job randomly selected one out of five available, unique configurations.
We did not evaluate how effectively the complete design performed. However, as part of the research, we were able to retrieve many GitHub accounts the actor was able to create during a three month period of time.
The following chart in Figure 13 illustrates statistics about the GitHub-created accounts performed by the system. It’s important to note that we don’t know if all accounts were created with the same design mechanism for all GitHub accounts. However, the statistics show actual accounts created by the actor’s infrastructure.
This chart is an estimate of confirmed GitHub-created accounts. It is not meant to be fully comprehensive because of the limited visibility we had during the investigation.
Figure 13. The number of GitHub accounts created by the PurpleUrchin actors.
Earlier Campaign, Pandemic Time
One of the preferred cloud services used by the actor during 2021 was Heroku. Heroku is a CAP that allows users to create and deploy applications without the need for maintaining the hosting cloud infrastructure. PurpleUrchin actors made use of this capability throughout their operations.
After analyzing the data within the collected containers, we identified a total of 100,723 unique accounts created on the Heroku platform. The chart in Figure 14 shows the Heroku account creation stats by year and month.
Figure 14. Unique accounts created on the Heroku CAP.
As the above chart shows, this actor was active and using Heroku since at least November 2021.
We have a medium level of confidence that the operations started early in 2020, given that the actor created multiple certificates with the Let’s Encrypt service, which was used with the generated domains. One of the domains, linux84[.]distro[.]cloudns.cl, had an SSL certificate with a valid date starting on Nov. 17, 2020 (shown in Figure 15).
Figure 15. SSL certificate for linux84.distro.cloudns.cl.
Conclusion
Automated Libra, the cloud threat actor behind the freejacking campaign PurpleUrchin, has created more than 130,000 accounts on free or limited-use cloud platforms such as Heroku and GitHub. They have also engaged in the illegal theft of cloud resources from these platforms.
Automated Libra constantly improve their CI/CD operation and infrastructure architecture to perform the following actions:
Bypass or resolve the CAPTCHA presented by GitHub during account creation
Increase the number of accounts that can be created per minute
Utilize as much CPU time as possible before losing access to resources
It is important to note that Automated Libra designs their infrastructure to make the most use out of CD/CI tools. This is getting easier to achieve over time, as the traditional VSPs are diversifying their service portfolios to include cloud-related services. The availability of these cloud-related services makes it easier for threat actors, because they don’t have to maintain infrastructure to deploy their applications. In the majority of cases, all they’ll need to do is to deploy a container.
While PurpleUrchin is a freejacking crypto mining operation, Automated Libra also employs Play and Run tactics to gain access to computational resources. The threat actors use these limited-use cloud resources until the allotted time or dollar balance is reached, at which time Automated Libra ceases using those resources. This often results in an outstanding balance due, which actors do not pay.
Palo Alto Networks Prisma Cloud is capable of monitoring the usage of cloud resources, specifically those initiated within a containerized environment. Prisma Cloud’s ability to scan all containers for vulnerabilities and misuse prior to deployment, as well as monitoring the runtime status of these containers, would prevent the activities of Automated Libra from persisting within a cloud environment.
When malware authors go to great lengths to avoid behaving maliciously if they detect they’re running in a sandbox, sometimes the best answer for security defenders is to write their own sandbox that can’t easily be detected. There are a lot of sandboxing approaches out there with pros and cons to each. We’ll talk about why we chose to go the bespoke route, and we’ll discuss many of the evasion types we had to cover in that effort as well as strategies that can be used to counter them.
There are many variations on how malware authors specifically detect sandboxes, but the general theme is that they will check the characteristics of the environment to see whether it looks like a targeted host rather than an automated system.
Palo Alto Networks customers receive improved detection for the evasions discussed in this blog through Advanced WildFire.
You could say that our day to day in the world of malware analysis has made the WildFire malware team sandbox evasion connoisseurs. Our team’s Slack channel has had its share of “look at this one!” over the years, sharing the joy of finding new evasion techniques. Getting to the bottom of these has been a big part of our team mission to help improve detection.
There’s a vast number of techniques malware authors use to check if they are running on a “real” targeted host, such as counting the number of cookies in browser caches, or checking whether video memory appears too small. Given that sandbox evasions are legion and there are far too many to cover in a single article, we will first examine some of the major categories we typically encounter and then cover what we can do about them.
Checks for Instrumentation or “Hooks”
The first broad category of evasions involves the detection of any sandbox instrumentation. This is definitely one of the most popular techniques. The most common example is checking for API hooks, as this is a common method for sandboxes and antivirus vendors alike to instrument and log all of the API calls made by an executable under analysis. This can be as simple as checking the function prologues of common functions to see if they are hooked.
In Figure 1, we see what the disassembly looks like for the prologue of CreateFileA in Windows 10 as well as what it might look like if it’s been instrumented in a sandbox.
Figure 1. A typical sandbox hook on a function in the system API.
As you can see, this is pretty easy for attackers to detect, which is why it’s one of the most prevalent evasions we’ve seen out there.
A fun variation on this technique is when malware detects and unhooks existing hooks in order to stealthily execute without having its activity logged. This happens when malware authors want to slide past endpoint protections without being detected on a targeted host.
Figure 2 shows an example of how GuLoader unpatches the bytes of the ZwProtectVirtualMemory function prologue to restore the original functionality.
Figure 2. GuLoader unhooking instrumentation in a system API function.
Mitigating Instrumentation Evasions
The gold standard for preventing malware authors from detecting instrumentation is simply not to have anything out of the ordinary that’s visible to the program you’re analyzing. A growing number of sandboxes are making this idea the focus of their detection strategy. It’s easier to be evasion resistant when you don’t change a single byte anywhere in the OS.
Instead of instrumenting APIs by changing code, it’s a better strategy to use virtualization to invisibly instrument programs under analysis. There are a lot of advantages to instrumenting malware from outside of the guest VM, as shown in Figure 3.
Figure 3. In-guest versus a hypervisor based hooking engine. Left: Program analysis components exist in the guest VM along with the malware sample it executes. Right: Analysis components exist entirely outside of the guest VM and are thus invisible to the program under analysis.
Detecting Virtual Environments
Another common evasion category involves detecting that a file is executing in a virtual machine (VM). This can involve fingerprinting resources like low CPU core count, system or video memory, or screen resolution. It can also involve fingerprinting artifacts of the specific VM.
When building a sandbox, vendors have a large number of VM solutions to choose from, such as KVM, VirtualBox and Xen. Each one has various artifacts and idiosyncrasies that are detectable by software running in VMs underneath them.
Some of these idiosyncrasies are particular to a specific system, like checking for the backdoor interface of VMware, or checking whether the hardware presented to the OS matches the virtual hardware provided by QEMU. Other approaches can simply detect hypervisors in general. For example, Mark Lim discussed a general evasion for hypervisors in an article, which capitalizes on the fact that many hypervisors incorrectly emulate the behavior of the trap flag.
One of the earliest and most widely used mechanisms for malware to determine whether it’s running inside a VMware virtual machine is to use the backdoor interface of VMware to see whether there is any valid response from the VMware hypervisor. An example of such a check is shown in Figure 4.
Figure 4. Malware checking if it’s running inside a VMware virtual machine.
Malware families can also query the computer manufacturer or model information using Windows Management Instrumentation (WMI) queries. This allows them to get information about the system and compare it with known sandbox and/or hypervisors strings.
Figure 5 shows how this is used to query against VMware, Xen, VirtualBox and QEMU. The same technique can also be found in Al-Khaser, which is an open-source tool that contains many anti-sandbox techniques.
Figure 5. WMI queries used for querying computer information.
Figure 6 shows the software components that malware can potentially interact with, to reveal whether it’s executing in a virtual environment.
Figure 6. Additional surfaces that processes can interact with to assess whether they’re inside a VM.
Additionally, there is also often a great deal of information sprinkled around the guest VM that can easily provide clues as to what VM platform the guest OS is running underneath. In all cases, the specifics are dependent on the VM infrastructure used (e.g., VMware, KVM or QEMU).
The following are just a few examples of what malware authors can check for:
Registry key paths showing VM-specific hardware, drivers or services.
Filesystem paths for VM-specific drivers or other services.
MAC addresses specific to some VM infrastructures.
Virtual hardware (e.g., if a query reports that your network card is an Intel e1000, which hasn’t been made in many years, it can infer that you’re probably running with the Qemu hardware model).
Running processes showing VM platform-specific services to support paravirtualization, or systems for user convenience like VMware tools.
CPUID instruction that will, in many cases, helpfully inform software of the guest of the VM platform.
Mitigating VM Evasions
The main issue with most of these mitigations is that the mainstream virtualization platform alternatives are well known to malware authors. For ease of implementation, most sandboxes are based on systems like KVM, Xen or QEMU, which makes this class of evasions particularly tricky to defeat.
Every mainstream VM platform out there has been targeted by sandbox evasions. The problem is that nothing short of writing your own custom hypervisor to support malware analysis would effectively address this class of evasions.
… So that’s what we did!
Our detection team made the decision years ago to implement our own custom hypervisor tailored specifically for malware analysis. The dev teams went to great lengths to build (from scratch!) our own virtualization platform for dynamic analysis.
This decision has two advantages. The first is that we are not susceptible to the same fingerprinting techniques that are used against other VM infrastructure. We do not have any backdoor interfaces, but we do have different virtual hardware and a completely different codebase.
The second advantage is that, because we have built our own system, it is easier for us to adapt and address issues wherever we see malware using trickery on us for evasion purposes. For example, the linked article mentioned earlier discussed how many hypervisors incorrectly emulated the trap flag for guest VMs. Our malware analysts were able to close the loop with our dev teams to ensure that we emulated correctly and were not susceptible.
Lack of Human Interaction
This category includes evasions requiring specific human interaction. For example, a malware author would expect to see mouse clicks or some other event that would happen on a system with a “real” user driving it, but this would be absent in a typical automated analysis platform. Malware families often check for human interaction and cease execution if it looks like there is no user driving the system, because user activity is being simulated.
The following are the general themes we’ve observed for human interaction checks:
Prompting users for interaction. For example, dialogue boxes or fake EULAs that a sandbox might not know should be clicked to ensure detonation.
Checking for mouse clicks, mouse movement and key presses. Even the locations of mouse events or timing of keystrokes can be analyzed to determine whether they look “natural” versus programmatically generated.
Placing macros in documents to check for evidence of human interaction like scrolling, clicking a cell in a spreadsheet or checking a different worksheet tab.
Let’s take a look at a specific example (shown in Figure 7) of how malware might get the time elapsed since last user input (GetLastUserInput) and the time elapsed since the system has started (GetTickCount). It can then compare how much time has passed since the last key was pressed, to detect if there is any activity on the system.
Figure 7. User interaction required to detonate.
Mitigating Human Interaction Evasions
When implementing a sandbox, we have control of the virtual keyboard, mouse and monitor. If for some reason the analyzed executable requires any input keys, we can send key presses to the analysis, or make sure to click the correct button to continue the execution of the executable. It’s really just a question of knowing how to automatically do what a human would do to put on a convincing show for the malware we’re executing.
Like with all the other areas of the VM detection problem, we need to remain vigilant to what malware families are looking for, and continually improve our evasion strategy. A recent example involved malware that required individual mouse clicks on multiple cells within an Excel spreadsheet. We had to go the extra mile to ensure that we had a solid recipe for detection in place, in case this was used against us in the future.
Timing and Computing Resource Evasions
Early on, one of the most common sandbox evasions was to just call sleep for about an hour before doing anything evil. By doing this, it would guarantee that the malware would be well beyond the short analysis time window used by almost all sandboxes, as it’s not feasible to run every sample for more than a few minutes.
The reaction to this by sandbox authors was to instrument sleep to shorten any long sleeps to small ones. After many more iterations of this cat-and-mouse game, we now have a staggeringly diverse set of ever-evolving ways for malware to waste time in sandboxes and thus prevent any meaningful analysis results.
Figure 8 shows one evasion technique using Windows timers and Windows messages. The idea is to install a timer that will be fired each second, which then increments an internal variable when it’s executing the timer’s callback.
Once the variable hits a specific threshold, it will send another Windows message to notify the sample to start the execution of the malware. The problem with this evasion is that sandboxes can’t simply reduce the timer's timeout to a low number because it might break execution for other software, but it still must be executed somehow.
Figure 8. Example of sleep using timers and Windows messages.
Another example is shown in Figure 9, below, where the malicious executables simply call the time stamp counter instruction in a loop.
Figure 9. Sleep loop using time stamp counter instruction.
Timing Evasion Mitigations
Timing evasions can be very difficult to counter, depending on the situation. As previously mentioned, we can always adjust sleep arguments and timers but this does not completely solve the problem.
Another strategy that we’ve found useful is that, because we control the hypervisor, we can use techniques to control all hardware and software to make time move faster inside the guest VM. It’s even possible to do this without having to change arguments or install any hooks. We can run executables for an hour within minutes in real time, which allows us to reach the malicious code faster.
Junk instruction loops or VM exit loops are probably the hardest scenario to counter. If a malware author executes a few million CPUID instructions, which take exponentially longer to perform underneath a hypervisor, it’s a dead giveaway that our code is running in a VM. This is another situation where having a custom hypervisor tailored for malware analysis is useful, because we can detect and log this kind of activity.
Pocket Litter Checks
The term “pocket litter” has been co-opted from the field of espionage, where the items in one's pocket can be used for “confirming or refuting suspects' accounts of themselves.” This is a term we’ve internally adopted for all evasions in which malware authors are checking to see if the environment shows evidence of being a real, targeted host.
In terms of sandbox environments, checking for “pocket litter” commonly includes looking for things like a reasonable amount of system uptime, a sufficient number of files in the My Documents folder or a good number of pages in the system’s browser cache. These are all things that would help corroborate that the system is “real” and not a sandboxed environment. Like with the other categories, the number of variations are seemingly infinite.
Figure 10 shows another example where the malware checks if there are more than two processors available and whether there is enough memory available. Usually sandbox environments don’t have as much memory available as regular PCs, and this check is testing whether the target system is likely to be a desktop PC or running inside a sandbox environment.
Figure 10. Check for the minimum required number of processors and required memory to run.
In Figure 11, there is another example where an AutoIt executable exits if the volume disk serial numbers match those of emulators used by known antivirus vendors.
Figure 11. Check for volume serial numbers.
Pocket Litter Check Mitigations
In terms of mitigations, there is no single broad stroke that can be used to cover all available techniques. Rather, we attempt to address these on a case by case basis, where we can.
For example, when we see checks for specific types of files in particular places being used by evasions (if it appears to be an innocuous change to the VM image) we add them for any related samples to see. This pocket litter approach can feel like a cat and mouse game because there really is no panacea that addresses all threat actor mice. Persistence is key.
Conclusion
We emphasize that we are in no way claiming to have “solved” all sandbox evasions. In fact, the situation is quite the opposite when you consider that evasion classes are more or less infinite.
If there is a single takeaway from our discussion, it is that there are too many sandbox evasions out there to effectively address every single one. Anyone who tells you their sandbox is 100% evasion-proof is overdue for a run-in with reality.
We have discussed some of the high-level category evasions in broad strokes, as well as some of the strategies we’re using to address them. Because we can’t come close to addressing them all comprehensively, we recommend a defense-in-depth strategy. This allows us to architect detection systems in such a way that we can still detect malware when an evasion is successful and there is no execution of the payload.
For us on the WildFire team, this means a departure from simply relying on system API calls and other observable activity as the sole basis for detection. Because we have our own hypervisor, we have been able to utilize our control of all hardware/software to instrument software in the VM in a way that is invisible to the malware that is running.
As we discussed in our previous post on hypervisor memory analysis in Advanced WildFire, our goal is to make a new kind of analysis engine that targets malware in memory. For any evasion technique discussed here, the code to execute it must, at some point, exist in memory in order for it to execute and then successfully detect it is being analyzed.
Figure 12. Detecting malware in memory.
In our system, we’ve shifted detection focus to the deltas in memory during execution. As shown in Figure 12, if the payload or any code is decoded, decompressed or decrypted in memory, our system will have visibility and a solid chance at catching it.
In closing, our advice to anyone building out an automated malware analysis system is to be as flexible as possible in terms of reacting to the broad categories of sandbox evasions out there. It is guaranteed that you will run into many variations of the themes we discussed here.
We also recommend that you architect your system in a way that is tolerant to sandbox evasions. In other words, when all else fails and there are no execution events to scrutinize for malicious behaviors, there should be additional methods to fall back on. An example of what this looks like in practice is how we can analyze memory in Advanced WildFire to detect evasive malware even when payloads choose to remain dormant and not execute.
Thanks for joining us on this odyssey as we toured all of the ways malware authors go out of their way to avoid detection. Happy hunting!
Palo Alto Networks customers receive protections from threats such as those discussed in this post with Advanced WildFire.
On Dec. 20, 2022, CrowdStrike published a blog discussing a new exploit method for Microsoft Exchange Server, which they named OWASSRF, referring to server-side request forgery in relation to Outlook on the web. (Outlook on the web is known as both Outlook Web Access and Outlook Web Application.)
The OWASSRF exploit method involves two different vulnerabilities tracked by CVE-2022-41080 and CVE-2022-41082 that allow remote code execution (RCE) via Outlook Web Access (OWA). The CVE-2022-41082 vulnerability was previously used by the ProxyNotShell exploit. However, the OWASSRF exploit method bypasses mitigations previously provided by Microsoft for ProxyNotShell. OWASSRF requires authentication to the Exchange Server prior to exploitation, thus we are seeing isolated rather than mass exploitation attempts.
Unit 42 observed that active exploitation of the OWASSRF vulnerability was occurring in late November and early December 2022.
Unit 42 did observe threat actor activity exploiting these vulnerabilities, in which the actor used a PowerShell-based backdoor that we are tracking as SilverArrow to run commands on the Exchange Server. The actors ran commands to do the following:
Create an administrator account
Install the AnyDesk remote desktop application
Create an SSH tunnel using PuTTY Link to remotely access Windows Remote Desktop Protocol (RDP)
Dump memory of the LSASS process to harvest credentials
Our Cortex XDR customers were protected against the RCE portion of the OWASSRF vulnerability, as XDR prevented the PowerShell scripts from running in the event of exploitation.
Palo Alto Networks customers receive protections through a variety of products and services, including the following:
The Cortex XSOAR playbook, “CVE-2022-41040 & CVE-2022-41082 - ProxyNotShell,” was updated with more hunting, remediation and mitigation tasks to identify and respond to exploitation attempts.
Prisma Cloud has detection capabilities in place for CVE-2022-41080 and CVE-2022-41082. Prevention capabilities also exist with runtime defenses on virtual machines (VMs), serverless functions and containers performing malicious operations on vulnerable containers.
On Dec. 20, 2022, CrowdStrike published a blog discussing a new exploit method for Microsoft Exchange Server, which they named OWASSRF. The exploit method involves two different vulnerabilities tracked by CVE-2022-41080 and CVE-2022-41082 that allow remote code execution (RCE) via Outlook Web Access (OWA). The CVE-2022-41082 vulnerability was previously used by the ProxyNotShell exploit, however, the OWASSRF exploit method bypasses mitigations previously provided by Microsoft for ProxyNotShell.
Both ProxyNotShell and OWASSRF use a server side request forgery (SSRF) vulnerability. However, the ProxyNotShell method used an AutoDiscover endpoint to exploit CVE-2022-41040, while OWASSRF uses the OWA frontend endpoint to exploit CVE-2022-41080. Much like ProxyNotShell, the newly found exploit method requires the actor to be authenticated to the server prior to exploitation.
According to a tweet by @Purp1eW0lf on Dec. 14, 2022, actors exploiting the OWASSRF vulnerability left an open directory on their web server that contains several of their tools, including the Python script that contains code to exploit OWASSRF. Additionally, the open directory included a readme file. Its contents (see Figure 1) describe how to use the script to exploit ProxyNotShell, and also suggest that this was developed specifically to bypass hotfixes for the ProxyNotShell vulnerability.
Figure 1. readme.txt on actors' open directory that contains usage for the exploit code that exploits OWASSRF
Using the code found in this open directory, we were able to better understand how this exploit works. After successfully authenticating to the Exchange Server, the exploit code will issue POST requests to /owa/mastermailbox%40outlook.com/powershell as seen in Figure 2, which is the same URL structure mentioned in CrowdStrike’s OWASSRF blog.
The POST request also includes a header X-OWA-ExplicitLogonUser that has a value of owa/mastermailbox@outlook[.]com. The header value is removed from the URL during processing. The change in the URL is likely the cause of the server side request forgery tracked in CVE-2022-41080.
It should be noted that this traffic would occur over HTTPS so the POST request would be within an encrypted session. Also, we determined that the email address does not necessarily have to be mastermailbox@outlook[.]com, as any email address would suffice.
Figure 2. Initial POST request to Exchange Server from OWASSRF exploit script.
After exploitation, the exploit code will run supplied PowerShell in the form of a base64-encoded string. The exploit code replaces $$POWERSHELL_ENCODE_PAYLOAD_HERE$$ in the XML seen in Figure 3 with the base64-encoded PowerShell and will send this XML to the Exchange Server to run.
Figure 3. Message data sent to an Exchange Server to run encoded PowerShell after exploiting OWASSRF.
Current Scope of the Attack
At the time of writing, Unit 42 is aware of eight organizations that have seen exploitation activity. In exploit attempts we observed on Dec. 2 and 3, the actors attempted to run PowerShell that was base64-encoded, as seen in Figure 4. The decoded PowerShell code is a backdoor that we are tracking as SilverArrow.
Figure 4. Example of the encoded PowerShell script seen in OWASSRF exploit attempts in early December 2022.
The SilverArrow backdoor – decoded from what is seen in Figure 5 – is effectively a remote shell. It connects to a remote server (0xd8809226 or 216.128.146[.]38 in this specific case) and enters a loop to receive additional PowerShell commands that it will run and then respond to the server with the result. This particular remote shell provides the actors with a shell prompt of SL>, which is the basis of the name SilverArrow.
Figure 5. Decoded PowerShell script delivered in OWASSRF exploit attempts in early December 2022.
All OWASSRF exploit attempts observed by Unit 42 have resulted in the same PowerShell backdoor. We have observed the following IP addresses used as command and control (C2) servers for these backdoors:
216.128.146[.]38
95.179.162[.]125
192.248.176[.]138
140.82.52[.]35
45.32.144[.]71
Several of our XDR customers experienced exploit attempts, in which the post-exploitation PowerShell activity was prevented (see Figure 6). The prevention of the PowerShell code from executing blocked the threat actors from carrying out any post-exploitation activities.
Figure 6. PowerShell activity prevented by Cortex XDR after OWASSRF exploitation.
Unfortunately, one Exchange Server did not have XDR in blocking mode and the OWASSRF exploit was successful on Nov. 28, 2022, which resulted in the execution of PowerShell code. After exploitation, the threat actors used PowerShell to run several commands. The threat actors used the whoami command, created a user named Admon and added the Admon user to the local administrators and remote desktop users groups (see Figure 7).
The actors also downloaded PuTTY Link (pta.exe) and the AnyDesk remote desktop application to the server, the latter of which the actors installed to start up with Windows to persist reboots. The actors used PuTTY Link to create an SSH tunnel to 217.69.10[.]255 to be able to access RDP on the local server, which further shows the threat actors’ interest in using remote desktop tools to interact with the compromised server. We are also aware of the threat actors creating SSH tunnels to the IP address 45.76.246[.]112.
Figure 7. PowerShell activity post-exploitation showing threat actor activity.
Shortly after the activity seen in Figure 7, the threat actors used their newly created Admon user account and their remote desktop access to dump the memory of the LSASS process. The actor used the legitimate Task Manager application in Windows to dump the LSASS process memory, as seen in Figure 8. We believe the threat actors dumped the LSASS memory and exfiltrated the dump file to extract credentials rather than doing so locally on the server, as we saw no processing of the dump file on the server.
Figure 8. Threat actor using Task Manager to dump the memory of LSASS for credential gathering.
Interim Guidance
Unit 42 recommends customers apply the Nov. 8, 2022, security update to their Exchange Servers. Palo Alto Networks Cortex XDR protected customers from the payloads deployed by this exploit using the Anti Webshell Protection module and behavioral threat protection.
Unit 42 Managed Threat Hunting Queries
The Unit 42 Managed Threat Hunting team continues to track any attempts to exploit these CVEs across our customers, using Cortex XDR and the XQL queries below. Cortex XDR customers can also use these XQL queries to search for signs of exploitation.
1
2
3
4
5
6
7
8
9
10
11
12
13
// Processes spawned by exploiting this vulnerability will have a parent process of w3wp.exe in the "MSExchangePowerShellAppPool" application pool. Review the results of this query for suspicious child processes.
// Description: In activity we observed in the wild, a w3wp.exe process belonging to the "MSExchangePowerShellAppPool" application pool spawned PowerShell one-liners with "frombase64string" in the command line.
Unit 42 observed active exploitation of the OWASSRF method in the wild via the exploitation of CVE-2022-41080 and CVE-2022-41082. We are not seeing mass exploitation attempts of OWASSRF as it requires authentication to the Exchange Server. We saw isolated OWASSRF attempts to exploit Exchange Server in which the threat actors likely used credentials previously stolen by unknown means.
In known successful exploitation attempts, the threat actors used PowerShell to run additional commands to gain remote desktop access to the Exchange Server. This involved the creation of a new administrator account, the creation of an SSH tunnel using PuTTY Link to access Windows Remote Desktop and the installation of the AnyDesk application. The actors used these remote desktop tools to gather credentials, but we are unsure of the actors’ goals as the server was quickly mitigated.
Due to the availability of a proof-of-concept exploit script for the OWASSRF method, Palo Alto Networks highly recommends applying Microsoft’s Nov. 8, 2022, security update to your Exchange Servers to mitigate this vulnerability. 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 Product Protections for OWASSRF
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
Next-Generation Firewalls (PA-Series, VM-Series and CN-Series) or Prisma Access with an Advanced Threat Prevention security subscription can automatically block sessions related to CVE-2022-41080 using Threat ID 93319 (Application and Threat content update 8658).
Cloud-Delivered Security Services for the Next-Generation Firewall
The Cortex XSOAR playbook, “CVE-2022-41040 & CVE-2022-41082 - ProxyNotShell,” was updated with more hunting, remediation and mitigation tasks to identify and respond to exploitation attempts. This playbook is part of the Rapid Response Pack, which includes various playbooks for trending vulnerabilities and threats and is available on Cortex Marketplace.
Cortex XDR Agent running on version 7.8 and above with content version 810-32342 and above will block the exploitation attempt of the exploitation chain that we have identified. Please make sure your agents are configured in blocking mode for Exploit Protection, behavioral threat protection and the Anti Webshell Protection module.
Prisma Cloud
Prisma Cloud has detection capabilities in place for CVE-2022-41080 and CVE-2022-41082. Prevention capabilities also exist with runtime defenses on virtual machines (VMs), serverless functions and containers performing malicious operations on vulnerable containers. Compute agents should be installed on container hosts, serverless functions and VM instances, and ensure they are configured with the latest Prisma Cloud Intelligence Stream (IS) offering and have runtime protection set to active.
We’ve probably all received advice for how to avoid phishing, such as to be on the lookout for spelling errors or other mistakes that would alert us to the presence of fraudsters. However, this advice is only helpful for traditional phishing techniques. Meddler in the Middle (MitM) phishing attacks show how threat actors find ways to get around traditional defenses and advice.
MitM phishing attacks are a state-of-the-art type of phishing attack capable of breaking two-factor authentication (2FA) while avoiding many content-based phishing detection engines. Rather than showing a spoofed version of a target login page, a MitM attack uses a reverse-proxy server to relay the original login page directly to the user’s browser.
As of November 2022, several phishing attacks have used MitM tactics to compromise business email accounts and to successfully steal organizations’ confidential information. There are several popular MitM phishing toolkits that make it easy for hackers to launch their own MitM phishing attacks in just a few clicks.
These toolkits are continually expanding their sets of features while simultaneously becoming more intuitive and easy to use. Many already employ sophisticated cloaking techniques, allowing them to evade detection by traditional phishing detection systems. As such, we expect that the prevalence of these MitM phishing attacks will continue to rise in the near future.
Palo Alto Networks customers receive protection from the attacks discussed in this blog through Advanced URL Filtering by blocking MitM phishing pages in real time.
The purpose of a phishing attack is to set up a false login page to trick users into entering their login credentials.
In traditional phishing attacks, attackers will usually create their own phishing page to mimic a legitimate login page. They might host this either on a newly created domain, compromise a legitimate domain and host their phishing page on this domain, or use an existing SaaS platform to host their phishing content.
“Phishing kits” simplify the process of creating and deploying phishing attacks by providing a set of programs and/or scripts that allow even inexperienced cybercriminals to launch their own phishing attacks. These kits often employ templated webpages that mimic targeted companies’ actual login pages. Web-based phishing-as a-service (PhaaS) platforms such as Caffeine (shown in Figure 1) and Robin Banks go one step further by providing easy-to-use interfaces that allow threat actors to configure and deploy phishing attacks.
Figure 1. The homepage for Caffeine, a phishing-as-a-service (PhaaS) platform first revealed in October 2022.
In traditional phishing attacks, the phishing page is typically hosted directly on the malicious or compromised server, and might not necessarily be a perfect replica of a legitimate login page. For example, if an attacker were to create a phishing page mimicking a GitHub login, they might not care to recreate all the various other features surrounding the core login feature, such as the “Forgot My Password” link.
An expert or careful observer might be able to notice subtle discrepancies between the legitimate GitHub login page and the spoofed phishing page and realize that the spoofed page is illegitimate. Figure 2 shows an example of how phishing pages can differ from the original target login page.
Similarly, automated content-based phishing prevention engines might notice that these illegitimate login pages contain signs of suspicious content (such as broken links or misspellings) and flag them as a possible phishing site.
Figure 2. Left: An example of a spoofed Microsoft login page used in a phishing attack. Right: Original Microsoft login page, as of Nov. 21, 2022.
Even with these flaws, the sheer number of recipients in these phishing campaigns mean that some targets could still fall victim to these attacks. Two-factor authentication (2FA), aka multifactor authentication (MFA), has become an increasingly popular way of adding an additional layer of security to protect against successful phishing attacks.
An example of 2FA in action is when, in addition to requiring a username and password, a legitimate login site also requires an additional form of authentication such as a one-time password (OTP) sent to the user’s registered email address. Even if an attacker were to gain access to a victim’s username and password via a successful phishing attack, they would not be able to log in as that user, because they would not be able to retrieve the OTP that would be sent during the malicious login attempt.
MitM Phishing Attacks
MitM phishing attacks are a new type of phishing attack that bypasses both content-based defenses and 2FA. Unlike traditional phishing attacks, which show a separate but spoofed version of a legitimate login page, MitM attacks show the user the exact same content that they would see on the legitimate login page. Instead of hosting a replica of a legitimate login page, MitM servers simply take the content rendered on the legitimate site and relay it to the end user, as shown in Figure 3.
In other words, MitM servers act as a proxy between the target and the legitimate login page. When the target enters their credentials into the proxied page, the MitM server stores the credentials away and forwards them to the legitimate login page, resulting in a successful login attempt. From the victim’s perspective, everything appears as if they had logged in to the legitimate page itself.
Furthermore, both connections (MitM server to legitimate site, and victim to MitM server) are served via the HTTPS protocol, so the victim will see that the connection is “secure” according to the padlock icon in the web browser’s address bar.
Since the content shown to the target is exactly the same as the content that they would see on the legitimate login page, this proxy-based approach makes it much harder for victims to visually discern that something suspicious is happening, and makes it very difficult for content-based phishing detection engines to notice anything suspicious.
To use a painting as an analogy, we can consider a traditional phishing attack to be like looking at a (potentially sloppy) replica of a $20 million Van Gogh painting made by a fraudulent artist. A MitM phishing attack is like viewing the original painting via a well-hidden mirror.
MitM attacks have several other benefits in addition to cosmetic ones. For example, if the user has 2FA set up, this proxy-based approach allows the MitM server to automatically bypass this 2FA as well.
After the MitM server forwards the username and password to the legitimate site, the legitimate site will then follow its normal behavior of sending an OTP to their client. The target – if tricked – will then input the one-time password into the MitM phishing page. This allows the MitM server to relay the password to the legitimate site, thereby fully completing the login attempt.
At this point, the MitM server would receive a real session cookie from the legitimate site. This persistent login allows the victim to continue to browse the site apparently as normal (though still via the attacker’s web server), further perpetuating the phishing attack’s air of legitimacy.
MitM Phishing Attacks in the Real World
At the time of writing, there are several tools that make it easy for hackers to deploy their own MitM phishing attacks in just a few clicks. Similar to traditional phishing kits, these MitM phishing kits provide a set of scripts – or in some cases, even graphical user interfaces (GUIs) – that make it easy for attackers to configure and launch MitM phishing attacks.
In Table 1, we introduce some of the more popular MitM phishing kits available at the time of writing. Each of these kits employ the core tactic of relaying the original login page to the victim’s browser, but they differ in their implementation details and additional features (e.g., cloaking and TLS certificate generation).
For example, Evilginx2 generates unique tokenized URLs (aka “lures”) that must be directly visited to show the phishing content. Requests to any other path result in a redirect to a benign site.
Name
First Released/Reported
Description
Evilginx2
July 2018 (first version released May 2017)
Feature-rich MitM phishing kit with an easy-to-use command-line interface. Has cloaking features built in. Generates unique tokens (lures) that must be present in the URL to reveal the phishing content. The command-line interface for this tool is shown in Figure 4.
Modlishka
January 2019
Automates several configuration steps and post-compromise actions, such as launching an instrumented Chrome instance with the stolen session cookie.
Muraena
May 2019
Barebones MitM toolkit. Unlike some other toolkits that automatically create TLS certificates, Muraena requires the attacker to provide their own certificate.
EvilnoVNC
September 2022
Uses a real web browser to render the login page on the attack server, and serves the content to the victim’s browser via VNC.
EvilProxy
September 2022
Phishing-as-a-service platform for MitM phishing attacks. Provides an easy-to-use GUI for threat actors to set up and manage their own MitM phishing campaigns.
Table 1. Breakdown of popular MitM phishing kits.
Figure 4. Screenshot demonstrating the use of the Evilginx2 command-line interface to launch and execute a MitM phishing attack.
In July 2022, Microsoft reported a phishing campaign using Evilginx2 to steal targets’ Microsoft credentials. The campaign sent emails to potential victims prompting them to download an important attachment. After opening the attachment and routing through a series of redirects, the victim would arrive at a MitM phishing page like that shown in Figure 5. After the attackers successfully intercept an authentication cookie, they would log on to the compromised Outlook account and continually search for finance-related emails and attachments in order to find opportunities for payment fraud.
Figure 5. MitM credential-stealing page that was a part of the campaign reported by Microsoft in July 2022.
In an attempt to avoid detection, the campaign used a variety of cloaking techniques to ensure that the phishing content would only load if the victim had navigated to the page via the original HTML attachment. By the time Microsoft’s threat intelligence article was published, more than 10,000 organizations had been targeted by this campaign over the span of several months.
According to Palo Alto Networks Advanced URL Filtering logs, our Advanced URL Filtering service had begun blocking web traffic to tokenized phishing URLs hosted on the attackers’ domains (e.g., login[.]mcrsfts-passwdupdate[.]com/HMxVQmxZ) as early as September 2021.
Late 2022 MitM Phishing Campaigns
In September 2022, a separate campaign was found to be using MitM phishing tactics to steal targets’ GitHub login credentials. Several domains were used to mimic a CircleCI login page, prompting victims to log in with their GitHub credentials (as shown in Figures 6 and 7).
Figure 6. circle-ci[.]com. Example landing page for the September 2022 GitHub phishing campaign. Upon clicking “Log in with GitHub,” the user would be shown a MitM credential stealing page which mirrored GitHub’s actual login page.Figure 7. MitM credential stealing page linked to by the webpage in the previous figure. The webpage is not hosted on the phishing server, but rather relayed from GitHub itself.
For targets with OTP-based 2FA set up, the MitM server also prompted them to enter the OTP, which was then forwarded to GitHub, allowing for a successful login. From there, attackers would persist in their access by quickly creating personal access tokens (PATs) or adding their own SSH keys to the victim’s account. That way, attackers would continue to have access to the compromised account even if the victim were to change their username and password.
In November 2022, it was revealed that Dropbox had fallen victim to a MitM phishing attack that allowed attackers to compromise and copy 130 private repositories. This shows that these MitM phishing attacks are already making a significant impact in the real world. In Dropbox's response to this attack, they stated that they plan to move their 2FA protocols from OTP to WebAuthn, which is a more phishing-resistant form of 2FA.
Present Day Phishing Activity
In recent weeks, our Advanced URL Filtering service has been detecting more MitM phishing URLs, with enterprise logins like Microsoft 365 being prime targets (shown in Figures 8 and 9).
Figure 8. -r-us[.]co[.]uk. A MitM phishing page targeting Microsoft, detected by our Advanced URL Filtering service.Figure 9. microsoftonlinesupport[.]cf. A MitM phishing page targeting Microsoft 365, detected by our Advanced URL Filtering service.As MitM phishing kits grow in popularity and continue to expand their feature sets, we expect the prevalence of MitM phishing attacks to increase as well. Threat actors are already making strides in this direction. In fact, Evilginx 3.0 is expected to be released in the near future, along with an online course on how to successfully execute a MitM phishing attack.
Conclusion
MitM phishing attacks have already resulted in significant real-world breaches, and are expected to rise in prevalence as MitM phishing toolkits continue to expand and evolve. As such, it becomes increasingly important for organizations to protect themselves from these sorts of cutting-edge phishing attacks.
At the moment, actions that end users can take to protect themselves against MitM phishing attacks include:
Verifying the validity of a URL before inputting any credentials
(e.g., ensure that a URL is really “github[.]com” and not something like “github-impersonator[.]org”).
Using a password manager to store and enter credentials. If you find yourself on a MitM phishing page hosted on a website that the password manager does not recognize, the password manager will warn you before entering your credentials.
Furthermore, customers who subscribe to Palo Alto Networks Advanced URL Filtering service receive protection from MitM phishing attacks via our in-line phishing URL detection, including the MitM phishing URLs mentioned in this article. Advanced URL Filtering analyzes web traffic in real time to block attacks before they make their way to the target. That way, even if a MitM phishing attack uses cloaked URLs (as is the case with Evilginx2), Advanced URL Filtering can block the attack before credentials are stolen.
As the conflict has continued on the ground and in cyberspace, Trident Ursa has been operating as a dedicated access creator and intelligence gatherer. Trident Ursa remains one of the most pervasive, intrusive, continuously active and focused APTs targeting Ukraine.
Given the ongoing geopolitical situation and the specific target focus of this APT group, Unit 42 researchers continue to actively monitor for indicators of their operations. In doing so, we have mapped out over 500 new domains, 200 samples and other Indicators of Compromise (IoCs) used within the past 10 months that support Trident Ursa’s different phishing and malware purposes.
We are providing this update along with known IoCs to highlight and share our current overall understanding of Trident Ursa’s operations.
While monitoring these domains as well as open source intelligence, we have identified multiple items of note:
An unsuccessful attempt to compromise a large petroleum refining company within a NATO member nation on Aug. 30.
An individual who appears to be involved with Trident Ursa threatened to harm a Ukraine-based cybersecurity researcher immediately following the initial invasion.
Multiple shifts in their tactics, techniques and procedures (TTPs).
Traditionally, Trident Ursa has primarily targeted Ukrainian entities with Ukrainian language lures. While this is still the most common scenario for this group, we saw a few instances of them using English language lures. We assess that these samples indicate that Trident Ursa is attempting to boost their intelligence collection and network access against Ukrainian and NATO allies.
In line with these efforts to target allied governments, during a review of their IoCs we identified an unsuccessful attempt to compromise a large petroleum refining company within a NATO member nation on Aug. 30.
List of necessary things for the provision of military humanitarian assistance to Ukraine.lnk (Note: File bundled in above .rar)
Table 1. English language samples used by Trident Ursa.
Beyond Just Hacking: Open Threats to Cybersecurity Community
One of our most surprising observations was when an individual named Anton (in Cyrillic, Антон) who appeared to be tied to Trident Ursa threatened a small group of cybersecurity researchers on Twitter, on the same day Russia invaded Ukraine (Feb. 24, 2022). It appears that Anton chose these researchers based on their tweets highlighting Trident Ursa’s IoCs in the days prior to the invasion.
The first tweets (shown in Figure 1) came from Anton (@Anton15001398) as the invasion was underway, to Ukraine-based threat researcher Mikhail Kasimov (@500mk500). In several tweets, he said, “run, i’m coming for you.” Likely figuring his first tweets to Kasimov were too unnoticeable, his last tweet included the #Gamaredon hashtag so it would be more publicly discoverable by other researchers.
Figure 1. Threatening Mikhail Kasimov.
Later that same day, Anton used a different account (@YumHSh2UdIkz64w) to send Shadow Chaser Group (@ShadowChasing1) and TI Research (@tiresearch1) the ominous message “let's be friends. We do not want to fight, but we do it well!” as shown in Figure 2.
Figure 2. Warning away Shadow Chaser Group and TI Research.
Two days later, on Feb. 26, Anton sent his last and most threatening tweet yet (Figure 3). In it, he provides Mikhail Kasimov’s full name, date of birth and address along with the message, “We are already in the city, there is nowhere to run. You had a chance.”
Figure 3. Doxing and threatening Mikhail Kasimov (full name, date of birth, and address redacted from the original tweet).
We imagine these direct, threatening communications from this purported Trident Ursa associate were unsettling to the recipients (especially Mikhail Kasimov, a researcher operating from within the war zone). To their credit, the targeted researchers were undaunted, and tweeted additional Trident Ursa IoCs over the weeks following these threats. Kasimov, along with a large number of other researchers from around the world, continues to routinely publish new IoCs for this APT.
DNS Shenanigans
Trident Ursa has used fast flux DNS as a way to increase the resilience of their operations, and to make analysis of their infrastructure more difficult for cybersecurity analysts. Infrastructure using fast flux DNS rotates through many IPs daily, using each one for a short time to make IP-based block listing, takedown efforts and forensic analysis difficult.
The use of this technique is the primary reason Unit 42 researchers focus on Trident Ursa’s domains instead of their IPs. Since June 2022, we’ve seen Trident Ursa use several other techniques in addition to fast flux to enhance their operational efficacy.
A number of legitimate tools and services have been used by this threat actor in their operations. 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.
Bypassing DNS Through Legitimate Web Services
The first example of additional techniques we’ve observed uses legitimate services to query IP assignments for malicious domains. By using these services, Trident Ursa is effectively bypassing DNS and DNS logging for the malicious domains. For example, the sample SHA256 499b56f3809508fc3f06f0d342a330bcced94c040e84843784998f1112c78422 calls the legitimate service ip-api[.]com to get the IP associated with josephine71.alabarda[.]ru through the following URL: hxxp://ip-api[.]com/csv/josephine71.alabarda.ru.
As of the time of writing this post, this process returns the following:
The malware uses the IP returned through this communication for follow-on communications with the malicious domain. The only DNS query that would show up in logging would be the original request for ip-api[.]com.
Bypassing DNS Through a Messaging Service
In the second example, Trident Ursa uses Telegram Messenger content to look up the latest IP used for command and control (C2). In this way, the actor is attempting to supplement DNS for when targets successfully block malicious domains.
For example, the sample SHA256 3e72981a45dc4bdaa178a3013710873ad90634729ffdd4b2c79c9a3a00f76f43 calls to hxxps://t[.]me/s/dracarc. As of Nov. 18, this account (@dracarc) returned the Telegram post ==104@248@36@191==. This is converted to the IP 104.248.36[.]191 and it is used for follow-on communications.
Hiding True IP Assignment Through Separate IPs for Root Domain and Subdomains
On Nov. 15, we noticed that the Trident Ursa domain niobiumo[.]ru was assigned to the U.S. Department of Defense Network Information Center IP 147.159.180[.]73. We quickly identified that Trident Ursa had no operational control over, or use of, that IP.
Trident Ursa had seeded the fast flux DNS tables for its root domains with “junk” IPs in an attempt to confuse researchers and protect its true operational infrastructure. Instead of using root domains, they were instead using subdomains for their operations.
The true operational IP could only be found by querying DNS upon a subdomain. In this case (shown in Figure 4), querying upon subdomain aaa.niobiumo[.]ru returned the operational IP 64.227.67[.]175.
Figure 4. reg[.]ru name servers send a fake address for the domain and a real address for the subdomain (note: DNS lookup for aaa.niobium[.]ru as of Nov. 15).We highlight two observations stemming from our analysis of Trident Ursa’s DNS activity:
For its operational infrastructure outside of Russia, Trident Ursa has relied primarily on VPS providers located within one of two autonomous systems (AS), AS14061 (DigitalOcean, LLC) and AS20473 (The Constant Company, LLC). Over the past six weeks, of the 122 IP addresses we identified outside of Russia, 63% of them were within AS14061 and 29% were within AS20473. The remainder were located across several AS owned by UAB Cherry Servers.
Over 96% of Trident Ursa’s domains continue to be registered and under the DNS of the Russian company reg[.]ru, a company that – to date – has taken no action to block or deny this malicious infrastructure.
Various Malware Types Used
Over the past few months, Trident Ursa has relied upon a couple of different tactics to initially compromise victim devices using VBScripts with randomly generated variable names and concatenation of strings for obfuscation. Each of these tactics ultimately rely on the delivery of malicious content through spear phishing.
The first delivery method we will look at uses .html files, and the second uses Word documents.
Phishing Using HTML Files
Trident Ursa delivers an .html file either as an attachment to their phishing email, or via a link to the .html file (in an attempt to bypass email threat scanning). They use seemingly benign URLs such as hxxp://state-cip[.]org/arhiv, as shown in Figure 5. This site appears to still be active at the time of writing this post.
Figure 5. Example of phishing email with link used by Trident Ursa.
These .html files contain Base64-encoded .rar archives that in turn contain a malicious .lnk file. Once a user clicks on these .lnk files, they use the Microsoft HTML Application (mshta.exe) to download additional files via URL, as shown in Figure 6.
Figure 6. Exploitation path for phishing using malicious .lnk files.
Taking a deeper look into recent .lnk file SHA256 0d51b90457c85a0baa6304e1ffef2c3ea5dab3b9d27099551eef60389a34a89b, we see that the file is 99.8 KB, which is approximately 98 KB larger than your average .lnk file.
Based on our review of these larger than expected .lnk files used by Trident Ursa, the file contains random 10-character strings that we assess were appended during the creation process. These are used to confuse analysis, and they have no purpose we can identify for Trident Ursa’s operations.
Once opened, this .lnk shortcut uses mshta.exe to contact hxxps://admou[.]org/29.11_mou/presented.rtf via a command line argument.
Trident Ursa appears to be using various techniques to limit who can access this URL. As other researchers have highlighted, Trident Ursa appears to be using geoblocking in order to limit downloads of this file to specific geographic locations.
In this case, we assess the ability to download presented.rtf via this URL is limited to Ukraine. There are some exceptions to this, however.
It appears that these threat actors are currently trying to stymie threat researchers by blocking ExpressVPN and NordVPN nodes within Ukraine. In addition, it appears that the actor is potentially conducting additional filtering to further control access to payloads. For example, VirusTotal receives an HTTP status code of 200, indicating success when requesting the above URL, but the overall content length of the reply is 0 bytes.
If the filtering conditions are met, the target downloads presented.rtf (SHA256 3990c6e9522e11b30354090cd919258aabef599de26fc4177397b59abaf395c3) upon opening the .lnk. The presented.rtf file is actually an HTA file that contains VBScript code.
This HTA file decodes two embedded Base64-encoded VBScripts, one of which it will save to %USERPROFILE%\josephine, and the other it runs using Execute. The VBScript decoded and executed by the presented.rtf file is responsible for adding persistence by running the VBScript saved to the josephine file each time the user logs in. The VBScript file saved to josephine is the payload at the end of this installation process.
The first VBScript responsible for enabling persistent access to the system does so by creating a Windows scheduled task and a registry key, both of which are common Trident Ursa techniques. This script creates a new scheduled task named Filmora.Complete that runs the josephine script every five minutes, as shown in the scheduled task information displayed in Figure 7.
Figure 7. Filmora.Complete scheduled task used to run payload every five minutes.
The script also creates an autorun registry key to automatically run the josephine VBScript when the user logs in. Figure 8 shows the autorun registry key named telemetry added to the system to run the VBScript at user login.
Figure 8. Autorun registry key used to run VBScript at user login.
The josephine script acts as the functional code of the backdoor, which allows the threat actors to run additional VBScript code supplied by a C2 server. The script contains two different methods to determine the IP address of its C2 server, with which it communicates directly.
The first method involves pinging the domain THEN<random number>.ua-cip[.]org using the following Windows Management Instrumentation (WMI) query and checking the ProtocolAddress value to determine the C2 IP address:
If the script is unable to reach this domain, it attempts to access the Telegram URL hxxps://t[.]me/s/vzloms to get the C2 IP address. It does this by checking the response using a regular expression of ==([0-9\@]+)==.
After obtaining the C2 IP address, this script will communicate with its C2 by issuing a custom crafted HTTP GET request, as seen in Figure 9. The custom fields modified in the HTTP request include a hardcoded user-agent with the computer name, volume serial number and the string ::/.josephine/. appended, as well as a hardcoded string used in the Accept-Language field.
Figure 9. HTTP request sent to the C2 server.
The josephine script reads the responses to this HTTP request, decodes the Base64 data within the response and executes it as a VBScript. We have not observed an active C2 server providing VBScripts in response to HTTP requests from the josephine script.
Phishing Using Word Documents
The latest phishing documents we’ve seen Trident Ursa use have low detection rates in VirusTotal, likely due to their simplicity. For example, SHA256 c22b20cee83b0802792a683ea7af86230288837bb3857c02e242fb6769fa8b0c shows 0/61 detections as of Dec. 8, 2022.
Figure 10. VirusTotal detections for c22b20cee83b0802792a683ea7af86230288837bb3857c02e242fb6769fa8b0c.
This file relates to a purported tender to purchase computer equipment for the National Academy of Security Service of Ukraine. The file contains no malicious code in and of itself. When opened, the file attempts to contact and download its remote template from hxxp://relax.salary48.minhizo[.]ru/MAIL/gloomily/along.rcs.
This template, along.rcs (SHA256: 007483ad49d90ac2cabe907eb5b3d7eef6a5473217c83b0fe99d087ee7b3f6b3) is an object linking and embedding (OLE) file that contains a macro that runs the malicious code. The macro itself resembles the VBScript code within the HTA file mentioned above, used to load additional scripts.
The installation VBScript saves the payload VBScript to %USERPROFILE%\Downloads\frontier\decisive and creates a scheduled task named GetSynchronization-USA to automatically run this payload every five minutes.
The payload VBScript is the same as the payload above. It attempts to get the C2 IP address via a ping to <random number>decisive.hungzo[.]ru and a regular expression on the response from a specific Telegram URL, hxxps://t[.]me/s/templ36.
Once it has the IP address, the script creates an HTTP GET request to hxxp://<IP address of C2>/snhale<random number>/index.html=?<random number> with custom HTTP fields it populates with the following activities:
Appending the computer name and volume serial number in the custom user-agent field, (windows nt 6.1; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/90.0.4430.85 safari/537.36, along with the static string ;;/.insufficient/.
Using frameS5V as the cookie value
Setting the Referrer to hxxps://developer.mozilla[.]org/en-US/docs/Web/JavaScript
Setting Accept-Language to ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Setting Content-Length to 4649
Lastly, the script will Base64 encode the response to this URL and attempt to execute it.
Recently Seen Droppers
Over the past three months, we’ve seen Trident Ursa use two different, yet very similar, droppers. The first dropper, usually named 7ZSfxMod_x86.exe, is the traditional 7-Zip self-extracting (SFX) archive technique the actor has used for years.
In these SFX files, the installation configuration script runs an embedded VBScript using Windows Script Host (wscript.exe). The second dropper, usually named myfile.exe according to the executable’s RT_VERSION resource, is effectively a loader that drops two files and eventually runs them as VBScript using wscript.
7ZSfxMod_x86.exe
A recent sample (SHA256 ac1f3a43447591c67159528d9c4245ce0b93b129845bed9597d1f39f68dbd72f) runs the following installation script when opened:
Along with the installation script, the archive contains a VBScript named 19698.mov (SHA256: f488bd406f1293f7881dd0ade8d08f2b1358ddaf7c4af4d27d95f6f047339b3a) referenced within the installation script. Similar to the examples above, the VBScript will try two different methods to obtain its C2 location.
First, the script runs a WMI query to ping the C2 domain <random number>delirium.sohrabt[.]ru. Should this fail, it also includes a second C2 location routine that will reach out to a Telegram page at hxxps://t[.]me/s/vbs_run14. It then uses a regular expression of ==([0-9\@]+)== to find an IP address within the response.
The script replaces the "@" characters with a "." within the match of the regex to make an IPV4 address in dot notation, and it writes the resulting IP address to the file %TEMP%\prDK6.
Once it has the IP address, the script creates an HTTP GET request to hxxp://<IP address of C2>/snhale<random number>/index.html=?<random number> with custom HTTP fields it populates with the following activities:
Appending the computer name and volume serial number in the custom user-agent field, mozilla/5.0 (windows nt 6.1; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/86.0.4240.193 safari/537.36, along with the static string ;;/.snventor/.
Using defective as the cookie value
Setting the Referrer to hxxps://www.unn.com[.]ua/ru/
Setting Accept-Language to ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Setting Content-Length to 2031
The script, like the one mentioned above, reads the response to this beacon, decodes the Base64 data within the response and runs the result as a VBScript using the Execute method. This script also has a backup URL that it will use if it receives an HTTP response status other than 200 or 404, specifically hxxp://<IP address of C2>/snquiries<random number>/index.html=?<random number>.
Myfile.exe
A recent sample (SHA256: a79704074516589c8a6a20abd6a8bcbbcc5a39a5ddbca714fbbf5346d7035f42) works as a loader that drops two files and eventually runs them as VBScripts using the wscript application.
First, the executable reads its own file data and skips to the end of the Portable Executable (PE) file to access the overlay data that was appended to the executable. The executable then decrypts the overlay data in reverse by using XOR on each byte with the byte that precedes it. Using this data, the executable writes the cleartext to the following locations:
C:\Users\<username>\nutfgqsjs.fjyc
C:\Users\<username>\16403.dll
The binary concatenates some strings to the contents written to nutfgqsjs.fjyc before writing this file to disk, specifically lines of VBScript code to delete the initial executable and the two VBScript files. The executable concludes by running the nutfgqsjs.fjyc script by calling CreateProcessA using the following command line:
The nutfgqsjs.fjyc file is a VBScript file that contains a significant amount of comments that are meant to hide the actual code. This script includes the following functional code that runs the 16403.dll VBScript:
The file 16403.dll is another VBScript with the functional code that decodes another VBScript and runs it. After several layers of decoding and replacing text, the ultimate VBScript eventually runs. This final VBScript uses the same techniques described in the .lnkand 7ZSfxMod_x86.exe descriptions above.
First, the script runs a WMI query to ping the C2 domain morbuso[.]ru. Should this fail, it also includes a second C2 location routine that will reach out to a Telegram page, specifically hxxps://t[.]me/s/dracarc. As of Nov. 18, this account (@dracarc) returned the following, ==104@248@36@191==. Using the regular expression of ==([0-9\@]+)== this is converted to the IP 104.248.36[.]191 and used for follow-on communications.
The script then creates an HTTP GET request to hxxp://<IPV4>/justly/CRONOS.icn?=Chr with custom HTTP fields it populates with the following activities:
Appending the computer name and volume serial number in the custom user-agent field, mozilla/5.0 (macintosh; intel mac os x 10_15_3) applewebkit/605.1.15 (khtml, like gecko) version/13.0.5 safari/605.1.15;; along with the static string ;;/.justice/.
Using jealous as the cookie value
It does not set Referrer in this instance
Setting Accept-Language to ru-RU,ru;q=0.8,en-US;q=0.6,en;q=0.4
Setting Content-Length to 5537
Lastly, the script will Base64 encode the response to this URL and attempt to execute it.
Conclusion
Trident Ursa remains an agile and adaptive APT that does not use overly sophisticated or complex techniques in its operations. In most cases, they rely on publicly available tools and scripts – along with a significant amount of obfuscation – as well as routine phishing attempts to successfully execute their operations.
This group’s operations are regularly caught by researchers and government organizations, and yet they don’t seem to care. They simply add additional obfuscation, new domains and new techniques and try again – often even reusing previous samples.
Continuously operating in this way since at least 2014 with no sign of slowing down throughout this period of conflict, Trident Ursa continues to be successful. For all of these reasons, they remain a significant threat to Ukraine, one which Ukraine and its allies need to actively defend against.
Protections and Mitigations
The best defense against Trident Ursa is a security posture that favors prevention. We recommend that organizations implement the following measures:
Search network and endpoint logs for any evidence of the indicators of compromise associated with this threat group.
Ensure cybersecurity solutions are effectively blocking against the active infrastructure IoCs.
Implement a DNS security solution in order to detect and mitigate DNS requests for known C2 infrastructure. In addition, if an organization does not have a specific use case for services such as Telegram Messaging and domain lookup tools within their business environment, add these domains to the organization’s block list or do not add them to the allow list in the case of Zero Trust networks.
Apply additional scrutiny to all network traffic communicating with AS 197695 (Reg[.]ru).
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
For Palo Alto Networks customers, our products and services provide the following coverage associated with this campaign:
Cortex XDR customers receive protection at the endpoints from the malware techniques described in this blog.
WildFire cloud-based threat analysis service accurately identifies the malware described in this blog as malicious.
Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with the Computer Emergency Response Team of Ukraine as well as our fellow Cyber Threat Alliance members. These organizations use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors.
Indicators of Compromise
A list of the domains, IP addresses and malware hashes is available on the Unit 42 GitHub.
Unit 42 researchers investigated Azure’s serverless architecture and found that we were able to break out of the serverless function to the underlying host. We also discovered that our host was actually a HyperV virtual machine that hosted several other serverless functions.
Azure serverless functions (commonly referred to as Azure Functions) is a serverless compute service that enables users to run event-triggered code without having to provision or manage the infrastructure. Being a trigger-based service, it runs code in response to a variety of events. In the case of our research, this event was a web page request.
We found out that for each function, a new container is generated by the host. Each container will be terminated and deleted after several minutes, to differentiate serverless function from traditional containers as a service.
The host in question hosted only functions that our Azure user had access to anyway, so no real damage could be done. It is clear Microsoft went to great lengths to stop people from getting to the host, so it is possible there are other findings yet to be uncovered there. There could be important information on the virtual machine that shouldn’t be visible, which could be discovered by a sufficiently motivated attacker.
Microsoft often uses containers to strengthen security but – because containers inherently aren’t as secure as virtual machines – they usually do not treat them as a security boundary. In this case, they implemented additional layers of security, which proved to be effective.
Prisma’s serverless solution has function discovery and vulnerability scanning for most cloud providers. These features effectively put another set of eyes on the organization’s serverless functions, alerting you in case known vulnerabilities are observed in those functions.
Serverless functions are a feature of serverless computing (commonly shortened to ”serverless”), where the cloud provider supplies all computing resources for its customers on demand and manages all architectures, including cloud infrastructure.
A great example of an ideal application for serverless is a chatbot. Slack, for instance, uses a serverless application called marbot to send notifications to DevOps teams through Slack.
The name “serverless” is a bit misleading. Despite what its name implies, serverless computing still requires physical servers to execute the code. The major difference from traditional computing is that serverless abstracts away anything that isn’t directly related to the code itself, from the operating system the code runs on to the hardware of the machine actually running the code.
The Internals of Serverless Functions
The first question you might be asking yourself is how one starts to research a serverless platform. Anyone who has ever used Azure Serverless Functions knows that there are not many places to poke around. You can upload some code or change a few settings, as shown in Figure 1, but that’s about it.
Figure 1. All the different runtimes available through Azure Functions.
We decided to start our research with a Python function over Linux, triggered by an HTTP request. (As a side note: For some runtimes, Windows is also available.)
Our next step was to get a working interactive shell inside the function, to better understand what we are dealing with, and to get some information about the machine running our code. We decided to go with a reverse shell for ease of use. We also decided to use the data transfer tool socat (shown in Figure 2) rather than netcat, as it supports a wider range of the protocols we deemed necessary for the rest of our research.
Figure 2. The socat binary in our project, in Visual Studio Code.
We simply dropped the socat binary in our project directory in Visual Studio Code and deployed the entire thing into the serverless function that we created earlier. The code to actually launch the reverse shell was very simple, as the entire logic lies in the socat application, as shown in Figure 3.
Figure 3. Our simple function code connecting to the reverse shell listener.
Executing our reverse shell landed us inside the function directory under a user-named app. We immediately found out we were running inside a container by using the
1
cat/proc/1/cgroupp_last_cap
command. The machine hostname, which started with SandboxHost (shown in Figure 4), also hinted at that.
Figure 4. A shell inside the serverless function.
There was nothing too interesting in the working directory we landed in. This directory included all the files we uploaded plus one additional lib folder, which contained the necessary libraries for Python to communicate with Azure.
The Container
This research started without a specific goal in mind, other than to improve Prisma serverless protections. However, after learning more about the architecture, we were eager to break out of the container and see how deep the rabbit hole goes.
After familiarizing ourselves with the container and its files, as well as our user permissions and such, we decided to check the environment variables because they often include interesting pieces of information. This time was no different. Among other interesting things, we noted the environment variables gave away the image name (shown in Figure 5).
Figure 5. Image name in the environment variables.
Searching this image name in Google led us to a Microsoft official catalog that listed image names, which led to an official repository that provided all of Microsoft images, including the one we were looking at.
Having the image and being able to research it locally made our life much easier. We were eager to pull the image to our local machine and start investigating it.
Our first approach was to get the image “source code” (or Dockerfile, if you’re using Docker). Surprisingly, this appeared not to be a trivial task. After some searching, we found out there is a handy utility tool called Whaler that is designed to reverse engineer Docker images into the Dockerfile that created them. Figure 6 illustrates this process.
Figure 6. Reverse engineering Microsoft image using Whaler.
There are plenty of images that wrap Whaler, resulting in a one-line command that is easy to use. Using this method, we managed to generate a good-enough version of the Dockerfile, as shown in Figure 7. The most interesting part of that file was the last line.
Figure 7. The “reversed” Dockerfile version.
It seems like the mesh folder contains some interesting files, in particular, the launch.sh script, which seems to be the first thing executed inside the container. At this point, we simply copied the entire mesh folder from inside the image to investigate it further.
There were some more scripts in there that called some other scripts in different scenarios. The interesting part of that folder was a binary called init, which runs in the background of every Azure serverless container. Lucky for us, this binary also came packed with symbols, so reverse engineering it was a breeze.
After investigating the functions and strings lists, one function was particularly interesting: init_server_pkg_mount_BindMount (shown in Figures 8a and 8b). After reverse engineering it, we discovered that this function binds a path inside the container to another path, which is also inside the container. This function also doesn’t require the user to be privileged, but it runs in the context of root! All you would need to do to bind one file to any other file, is to perform an HTTP query inside the container on the correct port, with the correct arguments.
Figure 8a. The init_server_pkg_mount_BindMount function signature.Figure 8b. The init_server_pkg_mount_BindMount function parses sourcePath and targetPath from the HTTP request.
In the process of this part of the investigation, we also discovered a lot of information about how Azure serverless architecture works behind the scenes. While this is outside the scope of this article, it would be possible to explore this matter in depth in its own article.
Escalating Privileges
To quickly recap, at this point in the research we were inside a container with an unprivileged user, but we had the ability to bind any one file to any other file as root. Our goal at this point was to escalate privileges to root, inside the container. There are probably several ways to achieve this, but we chose to replace the /etc/shadow file with the one we generated (shown in Figure 9), and then to change the user to root.
Figure 9. Generating /etc/shadow using OpenSSL.
To accomplish this, we performed the following steps (also shown in Figure 10):
Generated an /etc/shadow file with a known password for the root user.
Uploaded said file to our local directory in the Function container.
Used the running init service and the BindMount function to bind our local shadow file to the actual /etc/shadow file by querying http://localhost:6060.
Changed user to root using the su - root command.
Figure 10. Escalating privileges.
Escaping the Container: I Am Root
The next step in our escape was to leverage our newly achieved root access to break out of the container. We chose to use an old exploit that was discovered by Felix Wilhelm years ago.
Figure 11. Breaking out of the container PoC.
Using this exploit is not trivial, and there are several requirements that need to be met in order for it to work:
We must be running as root inside the container.
The container needs to have SYS_ADMIN capability.
The container must either not have an AppArmor profile or allow the mount syscall.
The cgroup v1 virtual filesystem must be mounted read-write inside the container.
We had already achieved the first requirement earlier. Surprisingly, the rest of the requirements were also available in our container. This was surprising because, by default, Docker containers are launched with a restricted set of capabilities and do not have the SYS_ADMIN capability enabled. Furthermore, Docker usually starts containers with AppArmor policy by default, which prevents the use of the mount syscall even when the container is run with SYS_ADMIN. We confirmed we have all the necessary capabilities by running the capsh command on our shell status file under /proc/PID/status, as shown in Figure 12.
Figure 12. Using capsh with some sed scripting to print our privileged user capabilities.
As a detailed explanation of this exploit is slightly outside the scope of this blog, we recommend reading "Digging into cgroups Escape" to get a better understanding of this technique. In short, we’ll describe the exploit with the following steps:
Find or create access to a cgroup controller (most versions of the exploit use RDMA).
Create a new cgroup within that controller.
Set notify_on_release for that cgroup to 1.
Set the release agent to a file accessible from both the container and host.
Start a quickly completing process within that cgroup that will trigger execution of the release agent on termination.
We decided to demonstrate achieving host execution context by running ps aux and comparing it to the container’s ps aux. In the video at the beginning of this section, you can see the entire exploit from start to finish in action. It is important to note that the machine hosting our container was a HyperV virtual machine and not a physical server.
Possible Impact and Conclusions
All the resources the virtual machine hosted were accessible by our Azure’s user regardless, so in that regard this escape had no actual immediate impact. This is an example of cloud providers' mitigations working as intended. In this case, their choice of not relying on the container as a security boundary plus implementing another line of defense proved to be a smart move.
However, this issue could have a huge impact if (for example) another vulnerability in the virtual machine itself is found. Furthermore, Microsoft is known to have fixed similar issues in the past, even if they’ve not called them vulnerabilities per se.
We felt like this was a good place to stop the research and post our findings, rather than investigating the virtual machine thoroughly. It is possible that the virtual machine contains important information or secrets that shouldn’t be visible to the serverless function user, or to a possible attacker. We are certain that other researchers in the cloud community would take it from here and investigate further, until Microsoft patches this issue.
After sharing our findings with Microsoft, they have taken the following defense-in-depth measures into consideration to better protect customers:
Additional validation for bind mount APIs to prevent mounting over.
Removing symbols from binaries where possible.
Appendix: Prisma’s Solution
Prisma’s serverless solution has function discovery and vulnerability scanning for most cloud providers. These features implement another set of eyes for the organization’s serverless functions, and they will alert in case of known vulnerabilities in those functions.
For AWS specifically, Prisma also offers deep visibility with Prisma’s Serverless Radar, compliance and detection of over-privileged roles, and serverless WAAS.
Furthermore, Prisma’s Serverless Defender also protects serverless functions at runtime. It monitors the customer’s functions to ensure they execute as designed. Per-function policies let the customer control the following:
Process activity – Enables verification of launched subprocesses against policy.
Network connections – Enables verification of inbound and outbound connections and permits outbound connections to explicitly allowed domains.
File system activity – Controls which parts of the file system functions can access.
Unit 42 researchers show new detection methods that help improve detection of a new line of Kerberos attacks, which allow attackers to modify Kerberos tickets to maintain privileged access. The most well-known example of this is the Golden Ticket attack, which allows threat actors to forge a ticket to masquerade as a high-privileged user.
These two newer attacks extend the Golden Ticket attack in that the forged tickets are not created from scratch, but instead based on modifying an existing ticket to include high-privileged access. We’ll discuss the difference between these three types of attacks, to explain why the newer ones are harder to detect.
The broad usage of Active Directory has made Kerberos attacks the bread and butter of many threat actors. Researchers have discovered the following new attack techniques that allow an adversary to gain unconstrained access to all services and resources within an Active Directory (AD) domain:
Diamond Ticket
Sapphire Ticket
Because of their similarity to the well-known Golden Ticket attack, threat actors might also use these attacks in future campaigns. People can better protect themselves by employing the new detection methods we’ll discuss for these new Kerberos attacks.
Palo Alto Networks customers receive improved detection for the attacks discussed in this blog through Cortex XDR.
To understand the ticket attacks and their implications, it helps to understand a few things about how Kerberos works. This includes some common terms for features used in these attacks, as well as the structure of how tickets are used.
Kerberos is a network authentication protocol that is primarily used in Active Directory (AD) environments. Thousands of companies across different industries use Active Directory technology for managing user accounts and other resources within an organization. Active Directory’s first version was released in Windows Server 2000 and since then, it has become particularly common in businesses and other large organizations that have a significant number of users and resources to manage.
Kerberos provides strong authentication by issuing tickets to authenticate users and allow access to services. The tickets are distributed by the key distribution center (KDC). In most environments, the KDC is installed on the domain controller (DC).
During the initial authentication, a Ticket Granting Ticket (TGT) is a ticket assigned to a user. The TGT is later used to authenticate the user to the KDC and request a service ticket from the Ticket Granting Service (TGS). Service tickets are granted for authentication against services.
A Kerberos authentication would consist of the following steps:
The user requests (AS-REQ) a TGT from the KDC and the KDC verifies and validates the credentials and user information.
After authenticating the user, the KDC sends an encrypted TGT back to the requester (AS-REP).
The user presents the TGT to the DC and requests a TGS (TGS-REQ).
The TGS is encrypted and sent back to the requesting user (TGS-REP).
The user connects to the server hosting the service requested and presents the TGS (AP-REQ) in order to access the service.
The application server sends an (AP-REP) to the client.
Server name. All the components of the name are part of the server's
identity.
Enc-part
Encrypted with the server's secret key.
Table 1. Kerberos ticket.
The enc-part contains different fields but we will focus on the following:
cname – The name part of the client's principal identifier.
authorization-data – used to pass authorization data from the principal on whose behalf a ticket was issued to the application service. This part includes the Privileged Attribute Certificate (PAC).
What Is a Kerberos Privilege Attribute Certificate (PAC)?
As Microsoft’s documentation states, the PAC is a structure that conveys authorization-related information provided by DCs. The PAC is used by authentication protocols that verify identities to transport authorization information, which controls access to resources.
A common use case for Kerberos delegation is a web server fetching user data from a database server. The database server can grant access to the user data only for the user. In this scenario, the web server will need to impersonate the user. This impersonation is called Kerberos delegation.
Constrained Delegation: Microsoft has implemented Kerberos extensions in order to avoid keeping the user’s TGT in memory. This extension is called S4U (Service for User), and it consists of S4U2Self and S4U2Proxy. S4U2Self allows a service to ask for a ticket to itself on behalf of any user. S4U2Proxy will allow a service to authenticate to a different service.
To use this protocol extension, the user that issues the KRB_TGS_REQ must have at least one Service Principal Name (SPN) to allow the DC to encrypt the generated service ticket with the service secret key.
S4U2U KRB_TGS exchange flow:
The service fills out the PA_FOR_USER data structure, which contains the information about the user on whose behalf the service requests the service ticket, and sends the KRB_TGS_REQ message to the TGS.
The service ticket will be sent back to the service via KRB_TGS_REQ message. The PAC returned in the service ticket contains the authorization data.
U2U Authentication
User-to-User authentication is described in the Kerberos RFC as a method that “allows the client to request that the ticket issued by the KDC be encrypted using a session key from a TGT issued to the party that will verify the authentication.”
The KRB_TGS_REQ will have the following features:
additional-tickets: will contain the TGT from which the secret-key is taken
ENC-TKT-IN-SKEY: option indicates that the ticket for the end server is to be encrypted in the session key from the additional TGT provided.
The service name (sname) can refer to a user and not necessarily a service with SPN.
U2U + S4U2Self
Combining the two methods together allows using the S4U2Self extension for users with no SPN. The service ticket received in this exchange is encrypted with the server’s secret-key (in this specific case the server can be a user with no SPN), therefore, the PAC of the target user can be decrypted using the server’s secret-key.
The KRB_TGS_REQ packet will have all the features of both methods.
How Do These Kerberos Attacks Work?
Both the Sapphire and Diamond Ticket attacks decrypt a legitimate TGT and change its PAC, and in order to do that, the adversary needs to have access to the KRBTGT account’s key (the password hash). The KRBTGT account, as described by Microsoft TechNet (now Microsoft Docs), is a local default account that acts as a service account for the KDC service.
Sapphire Ticket
The Sapphire ticket attack (introduced by Charlie Bromberg), requires getting credentials of any user in the domain. Let's call that user Joe. Joe’s credentials will be used to obtain a TGT (using a regular KRB_AS_REQ) and later to decrypt the PAC of a high-privileged user.
Once the TGT is received, the adversary will use the U2U + S4U2Self:
Decide on the user they want to impersonate (high-privileged user)
Generate a KRB_TGS_REQ with the following attributes:
The PA_FOR_USER struct contains the impersonated user
The service name (sname) is Joe’s username
Joe’s TGT will be added to the additional-tickets field
ENC-TKT-IN-SKEY flag in the KDC Option is set
Obtain a service ticket for the impersonated user
KRB_TGS_REQ -
Figure 2. KRB_TGS_REQ created using U2U + S4U2Self methods.Figure 3. ENC-TKT-IN-SKEY flag is set in the KDC Option.
KRB_TGS_REP
Figure 4. U2U + S4U2Self TGS-REP.
As we know, a service ticket is encrypted with the service’s long-term secret, which means that if the adversary has Joe’s credentials, they will be able to decrypt the service ticket. The adversary also has the KRBTGT account’s secret key and therefore they can decrypt and modify Joe’s TGT, which is signed with said secret key.
To forge the Sapphire Ticket, the attacker will extract the PAC of the impersonated user, and modify Joe’s TGT in 2 ways:
Replace Joe’s original PAC with the high-privileged PAC.
Match the cname to be the impersonated user’s name.
This gives the attacker a usable TGT of a high-privileged user.
Diamond Ticket
The first part of the Diamond Ticket attack (introduced by Charlie Clark and Andrew Schwartz) is obtaining a TGT. This can be done by using one of the following techniques:
Adversaries will use the low-privileged user’s credentials to initiate a KRB_AS_REQ, which will result in a legitimate TGT.
Once receiving the TGT in the KRB_AS_REP, the adversary can now decrypt the TGT using the KRBTGT account’s key and modify each part of the ticket.
After modifying the ticket, an attacker can escalate their privileges using one of the following approaches:
Generating a TGT to impersonate a domain admin or any other user in the domain.
In this scenario the attacker will need to change the cname field in the ticket as well as the PAC. This method will result in a forged ticket under the name of the domain admin (or any other user in the domain), which is pretty similar to the Golden Ticket attack.
Elevating a normal domain user’s privileges to domain admin privileges by modifying the PAC.
This method will supply the attacker with a ticket under the name of the low-privileged user with domain admin permissions.
How Powerful Are the New Kerberos Attacks?
Diamond and Sapphire Tickets are forged TGTs created by modifying a legitimate TGT, which gives it additional privileges or a new identity. While many Golden Ticket detections are based on the absence of a TGT creation by a legitimate DC, the new attacks manipulate a legitimate TGT that was issued by the DC, which makes them harder to detect.
After the TGT is forged, the attacker uses it to request a TGS to any service or resource they desire. For example, they can request access to all computers, files and folders in the domain.
What’s the Difference Between a Diamond Ticket and a Sapphire Ticket Attack?
In both attacks, the manipulation happens on the PAC of a legitimate TGT, but the main difference is in the way it is modified. With a Diamond Ticket, the modification is to the original PAC of the requested TGT, by adding additional privileges or modifying it completely. With a Sapphire Ticket, the attacker modifies the TGT by getting a legitimate PAC of a high-privileged user using Kerberos delegation, and replaces it with the original ticket’s PAC.
Can Anyone Forge TGTs?
In order to perform such an attack, the basic requirement is that the adversary needs access to the KRBTGT account’s password hash.
The KRBTGT account encrypts and signs all the Kerberos TGT tickets for the domain. All verification of Kerberos tickets, including encrypting and decrypting TGTs for the KDC service, is done by the KRBTGT. This means a forged TGT will be considered a valid ticket simply because it was encrypted with the KRBTGT account.
Moreover, the adversary has to encrypt the forged TGT with the KRBTGT password hash once the TGT is forged, to make sure the new TGT will pass the KDC’s verification and issue a service ticket to the desired service.
With that being said, it’s important to remember that getting the KRBTGT password hash is not an easy task. Doing so not only provides access to all the services and resources in the domain, but also enables network persistence.
Forged Ticket Attacks in the Wild
Forged ticket attacks have been sighted in the wild, such as in attacks by Playful Taurus, also known as APT15, Ke3chang and NICKEL. This group is attributed to actors operating out of China and has targeted oil, government, diplomatic, military and non-governmental organizations around the world since 2010.
An investigation done by NCC Group’s IR team in May 2017 states that, to gain persistence in the victim’s network in the event of remediation actions being undertaken, Playful Taurus used Mimikatz to dump credentials and generate Kerberos Golden Tickets.
In a different campaign around December 2021, MSTIC found that the same threat actor used malicious tools such as Mimikatz, WDigest, NTDSDump, and other password-dumping tools to gather credentials on a targeted system.
Mimikatz allows attackers to perform the following activities:
These simulate the Active Directory replication process and retrieve the user’s password hash. They can be used to collect the KRBTGT password hash.
Forge a Golden Ticket
Our assumption is that – because Sapphire and Diamond Ticket attacks resemble Golden Ticket attacks but are harder to discover – different threat actors (like Playful Taurus) are likely to use these attacks in the future.
Proposing Detection Methods for Forged Ticket Attacks
Due to the difficulty of finding the KRBTGT password hash, these attacks would probably cause a lot of noise even before the attack took place. In this case, the detection ideas that apply to Golden Ticket attacks are relevant here as well.
Since the Sapphire Ticket should appear valid (i.e., a ticket with a legitimate PAC), we would have a difficult time detecting its utilization solely by analyzing it. However, we can detect other suspicious activities on the host:
Signs of KRBTGT password hash theft
Suspicious tools usage
DCSync attacks in the environment or suspicious connections from the host to a DC
Irregular KRB_TGS_REQ with U2U + S4U2Self attributes
KRB_TGS_REQ by a high-privileged user from that host
If the adversary uses the ticket right after performing the attack, we will observe a TGT request and TGS from the same IP for two different users. There would be no indication for the second user’s (i.e., the one that appears in the TGS request) authentication to that machine. This can be monitored by Windows Event 4768 and 4769 as well as network traffic.
Figure 5. TGT request by low-privileged user.Figure 6. TGS request by high-privileged user.
Diamond Ticket
Generating a Ticket for Domain Admin Account
The detection here is pretty similar to any Golden Ticket detector or the suggested Sapphire Ticket detector.
Elevating Normal Domain User’s Privileges
If the adversary uses this technique, it will look like legitimate authentication. The TGT and TGS requests will be for the same user, and the suggested detectors won’t be relevant.
This activity can be monitored by looking for anomalies in both the number of resources being accessed and what resources the user accessed. Attackers will likely be accessing high-privileged resources, so this activity will be new. Anomaly detection can be tricky in big environments and can cause distraction rather than finding an attack.
It’s important to note that the main difference between Diamond Ticket and Sapphire Ticket is that a Sapphire Ticket has an actual PAC of a real high-privileged user. In Diamond Ticket and Golden Ticket attacks, the PAC is modified by the attacker, and might therefore be inaccurate. This information can be used to detect these attacks.
Group Membership Detection
To make this detection method more approachable, let me introduce you to Windows event 4627(S): Group membership information. This event is generated with Windows event “4624(S): An account was successfully logged on,” and it shows the list of groups that the logged-on account belongs to.
This requires OS Version Windows Server 2016, Windows 10 and above. To enable it, you must enable the Success Audit for the Audit Logon subcategory.
Monitoring this event will allow you to discover irregularities in the user’s group memberships. When an attacker wants to assign domain admin privileges to a forged ticket, they add the domain admin rid (512) to the PAC. Thus, during the login, it appears the user is part of the domain admins.
An example of this would be using Diamond Ticket attacks to elevate a low-privileged user (we’ll continue to use “Joe”) to domain admin privileges, as shown in Figures 8 and 9.
Figure 8. Low-privileged user appears in domain admin.Figure 9. Joe is not a member of domain admins.
It is worth noting that, if an adversary impersonates a high-privileged user using a forged TGT, they might assign the wrong group membership. Therefore, it is worth paying attention to those as well.
To avoid false positives (when a user is intentionally added to a high-privileged group), event 4627 can be correlated with Windows events 4732 and 4728, which indicate when a user is added to a group.
Conclusion
In this blog, after a brief primer on relevant Kerberos terms and the attacks themselves, we discussed the privileges required to perform such attacks and the importance of monitoring different forged ticket attacks. Additionally, we examined possible detection ideas that might help cover Golden Ticket attacks as well as new attack methods.
Forged ticket attacks might be hard to detect with a cursory glance, since they can initially appear to be legitimate. However, if enough information is collected about suspicious network activity, malicious tool usage, or Windows events, we might be able to detect some of the most effective Kerberos attacks.
In addition, deploying a security platform such as Cortex XDR can provide an additional layer of protection and visibility to the various stages of the attack.
Constrained delegation – Provides a safer form of delegation that could be used by services. When it is configured, constrained delegation restricts the services to which the specified server can act on the behalf of a user.
DCSync Attack – Abusing a Windows Domain Controller's application programming interface (API) to simulate the replication process from a remote domain controller.
Domain controller (DC) – A server computer that responds to security authentication requests within a computer network domain. It is a network server that is responsible for allowing host access to domain resources. Serves as the KDC in AD environments.
ENC-TKT-IN-SKEY – The option indicates that the ticket for the end server is to be encrypted in the session key from the additional TGT provided.
Golden Ticket attack – Adversaries who have the KRBTGT account password hash may forge Kerberos ticket-granting tickets (TGT) called “Golden ticket” which enable adversaries to generate authentication material for any account in Active Directory.
Kerberos – Kerberos is a network authentication protocol that is primarily used in Active Directory environments.
Kerberos delegation – Kerberos delegation is a delegation setting that allows applications to request end-user access credentials to access resources on behalf of the originating user.
Key Distribution Center (KDC) – A key distribution center (KDC) in cryptography is a system that is responsible for providing keys to the users in a network that shares sensitive or private data.
KRBTGT account – A local default account that acts as a service account for the KDC service.
PA-FOR-USER – A struct used to identify the user, on whose behalf the service requests the service ticket, using the user name and user realm.
Privileged Attribute Certificate (PAC) – The PAC is a structure that conveys authorization-related information provided by domain controllers (DCs). The PAC is used by authentication protocols that verify identities to transport authorization information, which controls access to resources.
S4U – Kerberos extensions in order to avoid keeping the user’s TGT in memory. It consists of S4U2Self and S4U2Proxy.
S4U2Proxy – Will allow a service to authenticate to a different service.
S4U2Self – Allows a service to ask for a ticket to itself on behalf of any user.
Service Principal Names (SPN) – A unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service logon account.
Ticket Granting Server (TGS) – A TGS validates the use of a ticket for a specified purpose, such as network service access.
Ticket Granting Ticket (TGT) – A user authentication token issued by the KDC that is used to request access tokens from the Ticket Granting Service (TGS) for specific resources/systems joined to the domain.
U2U authentication – A method to perform authentication when the verifier does not have access to a long-term service key. To address this problem, the Kerberos protocol allows the client to request that the ticket issued by the KDC be encrypted using a session key from a TGT issued to the party that will verify the authentication.
Cloud breaches often stem from misconfigured storage services or exposed credentials. A growing trend of attacks specifically targets cloud compute services to steal associated credentials and illicitly gain access to cloud infrastructure. These attacks could cost targeted organizations both in terms of unexpected charges for extra cloud resources added by the threat actor, as well as time required to remediate the damage.
This blog highlights two examples of cloud compute credentials attacks in the wild. While the initial access phase is important, we will focus on the post-breach actions executed during the attack, and share the flow of these two attacks against the cloud infrastructure. The attack flows show how threat actors abuse stolen compute credentials to pursue a variety of attack vectors (such as cryptomining, data theft, etc.) and abuse cloud services in unexpected ways.
To detect the attacks described below, cloud logging and monitoring best practices as outlined by Amazon Web Services (AWS) and Google Cloud are essential, as they provide visibility into activity at the cloud infrastructure level. This emphasizes how important it is to follow Amazon Web Services and Google Cloud logging and monitoring best practices.
Palo Alto Networks helps organizations address security issues in the cloud with Cortex XDR for cloud, which detects cloud attacks such as cloud compute credentials theft and Prisma Cloud, which manages identity entitlement with least privilege entitlements.
Before diving in, we should understand a very basic and important rule of working in the cloud. An entity, whether a human or a compute workload, needs legitimate and associated credentials to access a cloud environment at the infrastructure level. The credentials are used for authentication (to verify the entity’s identity) and authorization (to verify what the entity is allowed to do).
As a best practice, when a compute workload executes API calls in the cloud (e.g., to query a storage service), the workload’s associated credentials should be dedicated only to it. They should also be used only by that workload or human, and not by anyone else.
As we will see in both examples, an important security principle that can help reduce risk in cloud compute credentials attacks is least privilege access. In particular, this means that the privileges associated with those credentials should be scoped down to the minimum set actually required by the code using them.This limits the actions an attacker can take when compute credentials are stolen.
Attack Case 1: Compromised AWS Lambda Credentials Led to Phishing Attack
An attacker was able to execute API calls on the behalf of the Lambda function by stealing the Lambda’s credentials. This allowed the attacker to execute multiple API calls and enumerate different services in the cloud environment, as shown in Figure 1. While most of these API calls were not allowed due to lack of privileges, the attack resulted in a phishing attack launched from a AWS Simple Email Service (SES) that the threat actor created.
Figure 1. An attacker enumerating the cloud environment using a compromised Lambda function’s credentials.
This phishing attack not only resulted in unexpected costs for the organization, it also exposed other organizations to extra risk as well.
While the outcome of this attack caused substantial impact, it could have been greater. In this case the victim didn’t have an active SES, but if they had, the attacker could have abused it to launch an attack on the victim’s organization or they could even have used a legitimate email account for the phishing attack.
Due to the variety of cloud services used by organizations, it can be difficult to predict where a cloud attack will end. Going from cloud to phishing was not necessarily an expected path.
Attack Flow
An attacker was able to exfiltrate the Lambda’s environment variables and export them into their attacking machine (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN).
As the credentials were exfiltrated, the attack was launched with the following steps:
> WHOAMI - 2022-05-20T20:35:49 UTC
The attack started with the GetCallerIdentity command. This command is equivalent to whoami, as it provides information about the entity the credentials are associated with. From the response, the attacker can gain additional information such as the account ID and the credentials type that was stolen. They cannot, however, determine anything about the privileges associated with the identity.
> Identify and Access Management (IAM) Enumeration - 2022-05-20T20:35:55 UTC
The next phase of the attack was an identity and access management (IAM) enumeration. IAM is considered to be a crown jewel for an attack. By gaining access to IAM, an attacker can elevate permissions and gain persistence on the victim’s account.
The IAM enumeration included two API calls, which were denied due to lack of permissions:
ListAttachedRolePolicies
ListRolePolicies
It is fair to assume that the attacker noticed the lack of permission and therefore terminated the IAM enumeration after only two commands (possibly to avoid making unnecessary noise).
> General Enumeration 2022-05-20T20:39:59 UTC
After failing to enumerate IAM, the attacker started an enumeration on different services in different regions. This technique is much noisier as the attacker is trying to learn the architecture of the targeted account and, more importantly, gain access to sensitive information that could exist in the cloud account.
Some of the main services and API calls that were executed were:
Storage Enumeration
ListBuckets
GetBucketCors
GetBucketInventoryConfiguration
GetBucketPublicAccessBlock
GetBucketMetricsConfiguration
GetBucketPolicy
GetBucketTagging
EC2 Enumeration
GetConsoleScreenshot
GetLaunchTemplateData
DescribeInstanceTypes
DescribeBundleTasks
DescribeInstanceAttribute
DescribeReplaceRootVolumeTasks
Network Enumeration
DescribeCarrierGateways
DescribeVpcEndpointConnectionNotifications
DescribeTransitGatewayMulticastDomains
DescribeClientVpnRoutes
DescribeDhcpOptions
GetTransitGatewayRouteTableAssociations
Logging Enumeration
GetQueryResults
GetBucketLogging
GetLogRecord
GetFlowLogsIntegrationTemplate
DescribeLogGroups
DescribeLogStreams
DescribeFlowLogs
DescribeSubscriptionFilters
ListTagsLogGroup
Backup Enumeration
GetPasswordData
GetEbsEncryptionByDefault
GetEbsDefaultKmsKeyId
GetBucketReplication
DescribeVolumes
DescribeVolumesModifications
DescribeSnapshotAttribute
DescribeSnapshotTierStatus
DescribeImages
SES Enumeration
GetAccount
ListIdentities
General Enumeration
DescribeRegions
DescribeAvailabilityZones
DescribeAccountAttributes
> Backdoor 2022-05-20T20:43:22 UTC
While failing to enumerate IAM, the attacker tried (unsuccessfully) to create a new user by executing the CreateUser command.
> From the Cloud to a Phishing Attack 2022-05-20T20:44:40 UTC
As most of the API calls during the enumeration resulted in permission denied, the attacker was able to successfully enumerate SES. Therefore, the attacker launched a phishing attack by abusing the cloud email service, which included executing commands such as VerifyEmailIdentity and UpdateAccountSendingEnabled.
> Defense Evasion 2022-05-20T23:07:06 UTC
Finally, the attacker tried to hide some of his activities by deleting the SES identity by executing the DeleteIdentity command.
Additional Insights for Detection
A very important indicator of compromise (IoC) for this attack was the IP address 50.82.94[.]112.
API calls from the Lambda function are typically executed from its IP with the credentials (including AccessKeyId) that were generated for the Lambda. Therefore, every API call with that AccessKeyId is considered to be the Lambda function. However, during the attack, the threat actor was able to steal the Lambda's credentials, allowing the attacker to impersonate it.
Because of this, the IP is the key IoC as it is the way to detect that this is not the Lambda. The attacker was using the stolen credentials to impersonate and execute API calls on behalf of the Lambda function, but they were doing so from an IP address that wasn't attached to the Lambda, nor did it belong to the cloud environment.
Attack Case 2: A Compromised Google Cloud App Engine Service Account Deploying Cryptomining Instances
An attacker was able to steal the credentials for a Google Cloud App Engine service account (SA). There are many ways that attackers can accomplish this that are not necessarily related to any vulnerability in the cloud service provider. In many cases, for example, users store credentials in insecure locations or use easily guessed or brute-forced passwords.
In this case, the stolen SA was the default SA, which had a highly privileged role (Project Editor). This allowed the threat actor to launch an attack that ended with the creation of multiple high-core CPU virtual machines (VMs) for cryptomining purposes, as shown in Figure 2.
Figure 2. An attacker abusing a compromised App Engine SA to allocate multiple cloud instances for mining.
When the threat actor launched thousands of VMs in the victim’s environment, it significantly increased their expected costs. Even if someone had noticed an attack like this in their environment after a short period of time, it would still have had a substantial cost impact.
Attack Flow
Google App Engine is a Google Cloud fully managed serverless platform, and the service account is the token. When the user creates an App Engine instance, the cloud provider creates a default SA and attaches it to the created App Engine.
This App Engine default SA has the editor role in the project. The editor role is highly privileged, which is a key factor the attacker took advantage of. This role allowed execution of high-privilege API calls, such as the following:
Compute workload launch
Firewall (FW) rule modification
SA key creation
> Privilege Escalation 2022-06-16T12:21:17.624 UTC
The attack started with an attempt to escalate privileges. As mentioned above, by default the App Engine’s SA has editor permissions on the project. With these permissions, the attacker tried to add the compute/admin role by adding the following object into the IAM policy:
As we can see, the appspot in the SA domain prefix indicates this SA belongs to an App Engine service.
> Allow Any/Any 2022-06-16T12:21:29.406 UTC
Next the attacker modified the FW rules on the project level. First, the attacker attempted to create a subnet (named default). Then, the attacker added the rule below into that subnet:
This action furthers the attacker’s goal of mining cryptocurrency. To enable unlimited cryptocurrency mining, the attacker removed any limitation on the networking level.
It is important to note the priority field. By setting this to zero, the attacker’s rule is set to the highest priority, meaning it will take effect first in the order of the existing FW rules.
> An Army of Miners 2022-06-16T12:21:38.916 UTC
Once setup was complete, the main phase of the attack began, launching VMs in multiple regions.
While the attacker could have created high CPU machines, in this case the attacker instead created a standard VM (e.g., n1-standard-2) equipped with four high performance GPUs (e.g., nvidia-tesla-p100):
Overall, more than 1,600 VMs were created during this attack.
> Backdoor 2022-06-16T13:25:56.037 UTC
The attacker assumed the SA key used for the attack would be detected and revoked, and therefore created multiple SA keys (for later usage) by executing the google.iam.admin.v1.CreateServiceAccountKey API call.
Additional Insights for Detection
As in the first case we discussed, the IP is an important IoC. In this case, the attack was launched from multiple IPs (nine different IPs overall), some of which were active Tor exit nodes.
Again, we expect the App Engine’s SA to be used from an IP within the cloud environment. It definitely should not be used from a Tor exit node.
Firewall rule modification is a common and popular technique used in attacks like these. Many organizations enforce network traffic rules that deny access to active mining pools, so attackers must modify firewall rules to accomplish their goals.
Lastly, by editing a network named default, the attacker tried to avoid detection. Unless this option is disabled, by default each new project is created with a default network. It seems the attacker was trying to take advantage of this, thus avoiding having to create their own network.
Conclusion: Compute Token Theft Is a Growing Threat
The theft of a compute workload’s token is the common denominator for both cases we’ve discussed. While both examples above involve serverless services, this attack vector is relevant to all compute services.
It is important to emphasize that this type of attack could occur from different attack paths – including application vulnerabilities or zero-day exploits such as Log4Shell – not only from misconfigurations or poor cloud security posture management (CSPM).
To handle such attacks, cloud audit logs are essential, both for detection and for investigation and response (IR). Cloud audit monitoring is even more critical for serverless workloads where agents cannot be installed, thus making it harder to stop such attacks.
Cortex XDR for cloud, which 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.
Prisma Cloud, which assists organizations in managing identity entitlement, addresses the security challenges of managing IAM in cloud environments. Prisma Cloud IAM security capabilities automatically calculate effective permissions across cloud service providers, detect overly permissive access, and suggest corrections to reach least privilege entitlements.
Find out how you can protect your organization from cloud environment attacks with Unit 42 Cloud Incident Response services to investigate and respond to attacks and Cyber Risk Management Services to assess your security posture before an attack takes place.
Learn How to Detect Cloud Threats at Ignite ’22
Attend the session “Unearth advanced threats using your network and cloud data,” at Palo Alto Networks Ignite ’22, the security conference of the future, to find out how to detect compromised cloud compute tokens. Our researchers will show you how to investigate and respond to cloud attacks with a live demonstration. Register now!
Vice Society is a ransomware gang that has been involved in high-profile activity against schools this year. Unlike many other ransomware groups such as LockBit that follow a typical ransomware-as-a-service (RaaS) model, Vice Society’s operations are different in that they’ve been known for using forks of pre-existing ransomware families in their attack chain that are sold on DarkWeb marketplaces. These include the HelloKitty (aka FiveHands) and Zeppelin strains of ransomware as opposed to Vice Society developing their own custom payload.
In September 2022, a joint Cybersecurity Advisory (CSA) from the FBI, CISA and the MS-ISAC declared they had recently observed Vice Society actors disproportionately targeting the education sector with ransomware attacks. The CSA continued that attacks could increase as the 2022-23 school year begins and criminal ransomware groups perceive opportunities for successful attacks.
Vice Society first surfaced in the summer of 2021, and in that time frame it was seen exploiting the CVE-2021-34527 (aka PrintNightmare) vulnerability as part of their attack chain. The gang is also known to target backups and exfiltrate data from compromised systems to be leveraged for the purpose of double extortion, a common ransomware operation tactic where victims are pressured to pay a specified ransom amount in exchange for decryption and to avoid having sensitive data published on the attacker’s dedicated leak site.
Palo Alto Networks customers receive protections against ransomware used by Vice Society from Cortex XDR, as well as from the WildFire cloud-delivered security service for the Next-Generation Firewall. The Unit 42 Incident Response team can also be engaged to help with a compromise or to provide a proactive assessment to lower your risk.
Early reports of the extortion group Vice Society were shared on Twitter by malware researchers such as Michael Gillespie. These tweets depicted HelloKitty ransomware payloads appending a .v-society extension to encrypted files on June 10, 2021.
Since then, Vice Society has used a variety of different ransomware strains including the following notable examples:
In June 2021, Vice Society infected victims with HelloKitty.
In 2021 and 2022, Vice Society used Zeppelin to target Windows hosts.
During their 2021 infections, these attackers also exploited vulnerabilities such as PrintNightmare to escalate privileges and spread laterally across targeted networks.
Based on leak site activity we’ve observed in recent months, as shown in Figure 1, we saw a subtle spike at the turning point from 2021 to 2022. This was followed by one large spike of activity at the end of spring 2022.
Figure 1. Vice Society activity timeline (all leak site victim data).
Fast forward to fall 2022, when we saw another wave of Vice Society activity across the education sector, as shown in Figure 2, which prompted a flood of advisories and reports about the group.
The noticeable spikes in spring and fall give us a hint at some of their motivations. As education organizations are the group’s prime target, this could be an indication that they’re timing campaigns to coincide with this sector’s unique calendar year. The school year for most educational institutions in the U.S. typically starts in late August-September and ends in June. They might have been trying to time their attacks in 2022 with the transitions of the beginning and end of the school year.
Figure 2. Vice Society activity timeline (education-specific leak site victim data).
Study of Vice Society’s Victims
Vice Society is notorious for targeting the education sector – K-12 and higher education institutions in particular (as referenced in the recent CISA Advisory). Other targeted sectors include healthcare and nongovernmental organizations (NGOs).
Common targets are small- to medium-size businesses, with no geographical focus apparent at this time. Rather, as noted in a report by SOCRadar, Vice Society focuses on targets of opportunity.
For years, sectors such as education and healthcare have suffered from many challenges in combating ransomware that have made them particularly attractive targets. A lack of budgeting for systems and security solutions has led many organizations to run legacy hardware that isn’t patched against the latest vulnerabilities.
Other challenges that could increase the overall attack surface of these organizations include difficulties in controlling and managing a large number of personal devices brought in by students and staff members. These personal devices introduce inherent risk because they may interact with personal files via cloud services.
Although these sectors might have dedicated IT or security teams that run traditional security solutions such as an intrusion detection system (IDS) or intrusion prevention system (IPS), ransomware threat actors are leveraging living off the land techniques that can effectively circumvent traditional signature-based detection mechanisms. These tactics require an extended detection and response (XDR) platform for more robust behavioral monitoring within a network.
The education and healthcare sectors also experience the common challenge of finding staff who are adequately trained to handle the ongoing threat of ransomware. And lastly, many of these organizations are charged with protecting some of the most sensitive and valuable personally identifiable information (PII) of any business sector.
Geographical Impact
Vice Society is primarily opportunistic, and its targets have included organizations across the globe. The group has infected organizations based in all regions, as shown in Figures 3 and 4, with the largest numbers in the U.S., followed by the U.K., Spain, France, Brazil, Germany and Italy.
Figure 3. Global geographic distribution of organizations listed on Vice Society leak site.Figure 4. Chart version of global geographic distribution of organizations listed on Vice Society leak site.
The CISA advisory mentions how Vice Society has disproportionately targeted educational institutions in the United States. Looking at leak site data in more detail, the group appears to be targeting more educational organizations based in California, as shown in Figure 5.
Figure 5. Vice Society United States victimology (all leak site victim data).
Impacted Industry Verticals
Although Vice Society has been in the headlines for targeting educational organizations, they also extort victims in many other industry verticals, as shown in Figure 6, including those supplying critical infrastructure, such as healthcare, government entities and manufacturing.
Figure 6. Industry verticals targeted by Vice Society (leak site data).
Leak Site Metric Comparisons
According to analysis of ransomware leak sites, Unit 42 has identified Vice Society as being in the top 10 of the most impactful ransomware gangs of 2022. We estimate that, since it started operations in 2021, Vice Society has impacted more than 100 organizations in total. More than 90 of the total published leak site infections occurred in the year 2022 alone.
Leak site data suggests that Vice Society has had the highest impact on education organizations this year, with at least 33 educational institutions having been listed on the group’s dedicated ransomware leak site. This impact is closely followed by ransomware families such as LockBit 2.0 and 3.0, as shown in Figure 7.
Figure 7. Top ransomware families targeting educational institutions in 2022 (leak site data).
Unit 42 Incident Response Data on Vice Society
Since Vice Society’s inception in 2021, Unit 42 has performed incident response (IR) engagements with clients who have been impacted by Vice Society. Let’s look at some of the data from these incidents.
Dwell Time
In Unit 42 IR cases regarding Vice Society, we observed dwell times as high as six days. This represents the time elapsed between the date of initial compromise and the date of initial discovery.
Ransom Demands
When tracking ransomware group operations, Unit 42 takes note of the initial and final ransom demands made by each ransomware group. This allows us to better understand how aggressive a particular ransomware gang’s demands might be for particular industry verticals, and to get a general view into the rate at which a particular actor might drive their demands down after negotiations take place.
Our observations of ransom demands by Vice Society across IR cases include:
Initial demands by this actor could exceed $1 million.
Final demands after negotiations were as high as $460,000.
The difference between initial demands and final demands could be significant. We saw decreases as large as 60%.
Vice Society Technical Details
Leak Site Synopsis
Over the past year, Vice Society has operated sites on the Tor network using the following .onion address: vsociethok6sbprvevl4dlwbqrzyhxcxaqpvcqt5belwvsuxaxsutyad[.]onion
On Oct. 20, the primary .onion address became inactive, while the following site mirror was still active: ssq4zimieeanazkzc5ld4v5hdibi2nzwzdibfh5n5w4pw5mcik76lzyd[.]onion
Recently, the header for the group’s blog site bears a striking resemblance to the logo of a popular video game titled “Grand Theft Auto: Vice City” (shown in Figure 8).
Figure 8. Vice Society active leak site mirror (Oct. 20).
On Oct. 25, the original .onion address became active again. It was updated to include additional blog sections. As of early November, the “Our Blog” page showcased one article that highlights the group's notoriety, as shown in Figure 9.
Figure 9. Vice Society leak site including additional blog content (early November).
The new “Our Partners” page takes the place of the main page from the previous incarnation of the leak site, including links to view leaked victim data.
The new “For Victims” page directs victims to the ransom note that is dropped as part of the group’s infection chain. This is followed by additional instructions in case the victim doesn’t respond to one of the contact emails provided in their ransom note. During the extortion process, the attacker typically gives victims seven days to fulfill ransom demands, as shown in Figure 10.
Figure 10. Vice Society leak site victims page.
The “For Journalists” page depicts a “Frequently Asked Questions” section to address general questions about the group, as shown in Figure 11.
Figure 11. Vice Society leak site journalists page.
HelloKitty Usage
At the start of the group’s observed operations in 2021, Vice Society affiliates used the HelloKitty Ransomware variant as a primary payload in their infection chain.
This ransomware family was first observed in December 2020, primarily targeting Windows systems. This variant gets its name from its mutex: HELLOKITTYMutex.
In July 2021, as described in our HelloKitty ATOM, Unit 42 came across a Linux (ELF) sample with the name funny_linux.elf that had a ransom note with contents similar to those of HelloKitty for Windows samples. This Linux sample led to the discovery of additional HelloKitty samples for Linux dating back to October 2020. In March 2021, HelloKitty’s Linux variant was also observed in the wild to target ESXi servers.
Similar to ransomware variants like BlackCat, HelloKitty ransomware typically requires a key to execute, to hinder analysis efforts. In HelloKitty’s case, this key is typically obfuscated with AES 256 encryption. As mentioned in our previous report detailing emerging ransomware families in 2021, HelloKitty features multiple flags that could be set as command line arguments, which are detailed in Table 1 of the linked report.
Figure 12. Vice Society ransom note using HelloKitty ransomware.
When the encryption process is complete, encrypted files are typically appended with an extension using the following format: .v-society.<victim ID>.
Zeppelin Usage
As previously mentioned, the Vice Society group has also been known to adopt other ransomware families such as Zeppelin as a part of their infection chain. Upon execution, the ransomware binary deletes itself and drops a ransom note on the victim machine’s desktop titled !!! ALL YOUR FILES ARE ENCRYPTED !!!.TXT. The contact email address provided by the threat actor vary between samples, but the public v-society.official@onionmail[.]org address and the Tor .onion link remain consistent.
Figure 13. Vice Society ransom note using Zeppelin ransomware.
Additional execution details include the following:
Creating the HKCU\Software\Zeppelin registry key
Appending an extension with the format A1A-A80-4CD to encrypted files
Creating a file called README.txt.v-society
Imphash: 8acb34bed3caa60cae3f08f75d53f727
Creating a temp file with a .Zeppelin extension using the following format - C:\Users\<User>\AppData\Local\Temp\7D3ED7F1.Zeppelin
Conclusion
School districts with limited cybersecurity capabilities and constrained resources are often the most vulnerable to threat actors. The opportunistic targeting often seen with cybercriminals can put even school districts with robust cybersecurity programs at risk. K-12 institutions may be seen as particularly lucrative targets due to the amount of sensitive student data accessible through school systems or their managed service providers.
Vice Society and its consistent targeting of the education industry vertical, particularly around the September time frame, serves as a warning that this group has shaped their campaigns to take advantage of the school year in the U.S. It’s likely they’ll maintain use of these tactics to impact the cyberthreat landscape moving forward, as long as their activities continue to be lucrative for them.
Educational institutions should continue to implement security best practices and be wary of the ongoing threat of ransomware, especially during the start and end of the school year.
K-12 institutions and universities do have an advantage when it comes to protecting themselves that too few organizations use to its full potential. In a school environment, there are many educators who can help inform trainings for both staff and students to learn what they need to do to maintain security for everyone in the organization.
Vice Society’s use of multiple ransomware payloads across both Windows and Linux hosts shows that they’re continually evolving. They will likely continue leveraging additional ransomware strains in the future, as well as exploiting newly disclosed vulnerabilities.
As we do with other ransomware groups, Unit 42 strongly advises organizations that have been impacted by Vice Society to avoid paying a ransom if possible, and to instead consult a trusted IR negotiation team for the best course of action.
Palo Alto Networks customers receive protections against ransomware used by Vice Society from Cortex XDR, as well as from the WildFire cloud-delivered security service for the Next-Generation Firewall.
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
Tactics, Techniques and Procedures (TTPs)
Unit 42 has observed the following TTPs being used by Vice Society in past incident response engagements involving the group. The following table illustrates these TTPs according to the MITRE ATT&CK framework.
TA0001 Initial Access
T1566 Phishing
Vice Society is known to use phishing to gain initial access to victims’ systems.
T1078 Valid Accounts
Compromised valid credentials have been used by Vice Society to gain initial access.
T1190 Exploit Public-Facing Applications
Internet-facing applications and systems vulnerabilities can be exploited, such as PrintNightmare (CVE-2021-1675) and (CVE-2021-34527), to gain initial access.
TA0002 Execution
T1047 Windows Management Instrumentation (WMI)
Malicious commands are executed via WMI as a means of “living off the land” and avoiding detection.
T1053.005 Scheduled Task/Job
Vice Society is known to execute commands via scheduled tasks/jobs.
T1059.001 Command and Scripting Interpreter: Powershell
Vice Society utilizes PsExec for execution, persistence and defense evasion.
T1059.003 Command and Scripting Interpreter: Command Shell
Batch files are used by Vice Society to deploy the ransomware via PsExec.
TA0003 Persistence
T1543.003 Modify System Process
To maintain access to compromised systems, Vice Society leverages Windows operating functions to execute encrypted PowerShell.
T1547.001 Registry Run Keys/Startup Folder
Persistence is maintained after boot/reboot via malicious autostart registry keys.
T1574.002 DLL Side-Loading
Vice Society utilizes legitimate programs to side-load the group’s own DLL to execute their payload.
TA0004 Privilege Escalation
T1068 Exploitation for Privilege Escalation
Software vulnerabilities, such as PrintNightmare (CVE-2021-1675) and (CVE-2021-34527), may be exploited in an attempt to elevate privileges.
TA0005 Defense Evasion
T1036 Masquerading
Files dropped in the victim’s environment by Vice Society may have been altered to appear legitimate.
T1055 Process Injection
Legitimate processes have been corrupted by Vice Society via code injection, as a means to evade defenses.
T1070 Indicator Removal on Host
As with many other ransomware groups, Vice Society attempts to clear system, security and application logs on compromised machines.
T1112 Modify Registry
Vice Society attempts to disable Windows Defender by modifying the Registry.
T1497 Sandbox Evasion
Vice Society attempts to thwart reverse engineering and/or dynamic analysis via various sandbox evasion techniques.
T1562.001 Impair Defenses: Disable or Modify Tools
Attempts to disable or modify endpoint security, such as Microsoft Defender, on compromised devices.
TA0006 Credential Access
T1003 OS Credential Dumping
Vice Society is known to utilizentds.dit and comsvcs.dll to extract credentials.
T1003.001 OS Credential Dumping: LSASS Memory
Vice Society utilizes comsvcs.dll to dump credentials from Local Security Authority Subsystem Service.
T1003.003 OS Credential Dumping: NTDS
Vice Society attempts to “live off the land” by utilizing ntds.dit and ntdsutil.exe to dump Active Directory Database in an effort to obtain credentials.
TA0007 Discovery
T1046 Network Service Discovery
Vice Society has been seen using the recon tool called Advanced Port Scanner to identify running services and local network infrastructure.
T1482 Domain Trust Discovery
Vice Society has been seen using the attack path reconnaissance tool Bloodhound during the initial stages of their attack before ransomware is deployed.
Unit 42 researchers examine several malware samples that incorporate Cobalt Strike components, and discuss some of the ways that we catch these samples by analyzing artifacts from the deltas in process memory at key points of execution. We will also discuss the evasion tactics used by these threats, and other issues that make their analysis problematic.
Cobalt Strike is a clear example of the type of evasive malware that has been a thorn in the side of detection engines for many years. It is one of the most well-known adversary simulation frameworks for red team operations. However, it’s not only popular among red teams, but it is also abused by many threat actors for malicious purposes.
Although the toolkit is only sold to trusted entities to conduct realistic security tests, due to source code leaks, its various components have inevitably found their way into the arsenal of malicious actors ranging from ransomware groups to state actors. Malware authors abusing Cobalt Strike even played a role in the infamous SolarWinds incident in 2020.
The main driver for the proliferation of Cobalt Strike is that it is very good at what it does. It was designed from the ground up to help red teams armor their payloads to stay ahead of security vendors, and it regularly introduces new evasion techniques to try to maintain this edge.
One of the main advantages of Cobalt Strike is that it mainly operates in memory once the initial loader is executed. This situation poses a problem for detection when the payload is statically armored, exists only in memory and refuses to execute. This is a challenge to many security software products, as scanning memory is anything but easy.
In many cases, Cobalt Strike is a natural choice for gaining an initial footprint in a targeted network. A threat actor can use a builder with numerous deployment and obfuscation options to create the final payload based on a customizable template.
This payload is typically embedded into a file loader in encrypted or encoded form. When the file loader is executed by a victim, it decrypts/decodes the payload into memory and runs it. As the payload is present in memory in its original form, it can be detected easily due to some specific characteristics.
As malware researchers, we often see potentially interesting malicious samples that turn out to just be loaders for Cobalt Strike. It’s also often unclear if a loader was created by a red team or a real malicious actor, thus making attribution even more challenging.
In the next few sections, we’re going to take a closer look into three different Cobalt Strike loaders that were detected out of the box by a new hypervisor based sandbox we designed to allow us to analyze artifacts in memory. Each sample loads a different implant type, namely an SMB, HTTPS and stager beacon. We dubbed these Cobalt Strike loaders KoboldLoader, MagnetLoader and LithiumLoader. We will also discuss some of the methods we can use to detect these payloads.
KoboldLoader SMB Beacon
The sample we’re looking at was detected during a customer incident.
This 64-bit KoboldLoader executable uses various known tricks to try to bypass sandboxes and to make the analysis process more time consuming.
To bypass sandboxes that hook only high-level user mode functions, it solely calls native API functions. To make the analyst's life harder, it dynamically resolves the functions by hash instead of using plain text strings. The malware contains code to call the following functions:
NtCreateSection
NtMapViewOfSection
NtCreateFile (unused)
NtAllocateVirtualMemory (unused)
RtlCreateProcessParameters
RtlCreateUserProcess
RtlCreateUserThread
RtlExitUserProcess
The malware creates two separate tables of function hash/address pairs. One table contains one pair for all native functions, while the second table only pairs for Nt* functions.
For the Rtl* functions that were used, it loops through the first table and searches for the function hash to get the function address. For the Nt* functions that were used, it loops through the second table and simultaneously increases a counter variable.
When the hash is found, it takes the counter value that is the system call number of the corresponding native function, and it enters a custom syscall stub. This effectively bypasses many sandboxes, even if the lower level native functions are hooked instead of the high-level ones.
The overall loader functionality is relatively simple and uses mapping injection to run the payload. It spawns a child process of the Windows tool sethc.exe, creates a new section and maps the decrypted Cobalt Strike beacon loader into it. The final execution of the Cobalt Strike loader that in turn loads an SMB beacon happens by calling RtlCreateUserThread.
You can find the decrypted beacon configuration data in the Appendix section.
In-Memory Evasion
With our new hypervisor-based sandbox, we were able to detect the decrypted Cobalt Strike SMB beacon in memory. This beacon loader even uses some in-memory evasion features that create a strange sort of chimeric file. While it’s actually a DLL, the “MZ'' magic PE bytes and subsequent DOS header are overwritten with a small loader shellcode as shown in Figure 1.
The shellcode loader jumps to the exported function DllCanUnloadNow, which prepares the SMB beacon module in memory. To do this, it first loads the Windows pla.dll library and zeroes out a chunk of bytes inside its code section (.text). It then writes the beacon file into this blob and fixes the import address table, thus creating an executable memory module.
During the analysis of the file, we could figure out some of the in-memory evasion features that were used, as shown in Table 1.
Evasion feature
Description
Used in our sample
allocator
Set how beacon's ReflectiveLoader allocates memory for the agent. Options are: HeapAlloc, MapViewOfFile and VirtualAlloc.
No
cleanup
Ask beacon to attempt to free memory associated with the reflective DLL package that initialized it.
Yes
magic_mz_x64
Override the first bytes (MZ header included) of beacon's reflective DLL. Valid x86 instructions are required. Follow instructions that change CPU state with instructions that undo the change.
Yes
magic_pe
Override the PE character marker used by beacon's ReflectiveLoader with another value.
No
module_x64
Ask the x86 reflective loader to load the specified library and overwrite its space instead of allocating memory with VirtualAlloc.
Yes
obfuscate
Obfuscate the reflective DLL’s import table, overwrite unused header content, and ask ReflectiveLoader to copy beacon to new memory without its DLL headers.
Yes
sleep_mask
Obfuscate beacon and its heap, in-memory, prior to sleeping.
No
smartinject
Use embedded function pointer hints to bootstrap beacon agent without walking kernel32 Export Address Table (EAT).
No
stomppe
Ask ReflectiveLoader to stomp MZ, PE and e_lfanew values after it loads beacon payload.
No
userwx
Ask ReflectiveLoader to use or avoid read, write or execute (RWX) permissions for Beacon DLL in memory.
No
Table 1. Cobalt Strike evasion techniques that were used.
To sum up, the beacon loader and the beacon itself are the same file. Parts of the PE header are used for a shellcode that jumps to an exported function, which in turn creates a module of itself inside a Windows DLL. Finally, the shellcode jumps to the entry point of the beacon module to execute it in memory.
As discussed, there is no way for us to detect this beacon of our KoboldLoader sample successfully unless we can peer inside memory during execution.
MagnetLoader
The second loader we will look into is a 64-bit DLL that imitates a legitimate library.
This MagnetLoader sample tries to look like the Windows file mscms.dll in a few ways, by using the following similar features:
The same file description
An export table with many of the same function names
Almost identical resources
A very similar mutex
These features are also shown in Figure 2, where the malware file is contrasted with the valid mscml.dll.
Figure 2. Comparison of file description, export table and resources of MagnetLoader (left) and mscml.dll (right) as seen with EXE Explorer.
MagnetLoader not only tries to mimic the legitimate Windows library statically, but also at runtime.
All of the exported functions of MagnetLoader internally call the same main malware routine. When one of them is called, the DLL entry point is run first. In the entry point, the malware loads the original mscms.dll and it resolves all the functions it fakes.
The addresses of these original functions are stored and called after a fake method is executed. Thus, whenever an exported function of MagnetLoader is called, it runs the main malware routine and afterward calls the original function in mscms.dll.
The main malware routine is relatively simple. It first creates a mutex named SM0:220:304:WilStaging_02_p1h that looks very similar to the original one created by mscms.dll.
The Cobalt Strike beacon loader gets decrypted into a memory buffer and executed with the help of a known trick. Instead of calling the beacon loader directly, the loader uses the Windows API function EnumChildWindows to run it.
This function contains three parameters, one of which is a callback function. This parameter can be abused by malware to indirectly call an address via the callback function and thus conceal the execution flow.
You can also find the decrypted beacon configuration data in the Appendix section.
LithiumLoader
This last Cobalt Strike sample is part of a DLL side-loading chain where a custom installer for a type of security software was used. DLL side-loading is a technique that hijacks a legitimate application to run a separate, malicious DLL.
This 32-bit LithiumLoader DLL is part of a custom attacker-created Fortinet VPN installation package submitted to VirusTotal as FortiClientVPN_windows.exe (SHA256: a1239c93d43d657056e60f6694a73d9ae0fb304cb6c1b47ee2b38376ec21c786).
The FortiVPN.exe file is not malicious or compromised. Because the file is signed, attackers used it to evade antivirus detection.
The installer is a self-extracting RAR archive that contains the following files:
File name
Description
FortiVPN.exe
Legit signed FortiClient VPN Online installer v7.0.1.83
The self-extracting script commands are as follows:
Table 2b. List of self-extracting script commands.
When the installer is run, all files get silently dropped to the local %AppData% folder and both executable files get started. While the FortiClient VPN installer executes, the WinGup tool side-loads the libcurl.dll LithiumLoader malware. The malware does so because it imports the following functions from a legit copy of the libcurl library as shown in Figure 3.:
Figure 3. Import address table of WinGup.exe.
This threat also tries to add the %AppData% folder path to the exclusion list in Windows Defender via PowerShell.
On the startup of GUP.exe, the malicious libcurl.dll file is loaded into the process space as it statically imports the functions shown in Figure 3, above. While all four libcurl functions are run, only curl_easy_cleanup contains a malicious routine that was injected while compiling a new version of the library. Thus, we’re not dealing with a patched version of the legitimate DLL. This is a cleaner solution that doesn’t break the code after the inserted malicious routine, as is often seen in other malware.
Figure 4. Modified curl_easy_cleanup export function of libcurl.dll.
The load_shellcode function decrypts the shellcode via XOR and key 0xA as shown in Figure 5.
Figure 5. Shellcode loader function load_shellcode().
This function runs the Cobalt Strike stager shellcode indirectly via EnumSystemGeoID instead of directly jumping to it. This Windows API function has three parameters, the last one of which is a callback function abused by LithiumLoader.
The Cobalt Strike stager shellcode is borrowed from Metasploit and is the reverse HTTP shell payload, which uses the following API functions:
LoadLibrary
InternetOpenA
InternetConnectA
HttpOpenRequestA
InternetSetOptionA
HttpSendRequestA
GetDesktopWindow
InternetErrorDlg
VirtualAllocStub
InternetReadFile
The shellcode connects to the IP address of a university in Thailand.
LithiumLoader Detection Issues
At the time of writing this analysis, the Cobalt Strike beacon payload was no longer available. Without a payload or any actionable information in the execution report of API calls, it’s often challenging for a sandbox to determine whether the sample is malicious. This sample doesn’t have any functionality that can be classified as malicious per se.
Catching Cobalt Strike Through Analyzing Its Memory
In all three of these examples there are some common detection challenges. These samples do not execute in normal sandbox environments. But as we discussed, there is a wealth of information that we can use for detection if we look inside memory during execution, like function pointers, decoded stages of the loader, and other artifacts.
For many years now, it has been standard practice for sandbox systems to instrument and observe the activity of executing programs. If our team has learned anything over the years, it’s that this alone is not enough for highly evasive malware. This is why we’ve been working hard the past few years on figuring out how we can add more thorough processing for this type of highly evasive malware.
For accurate detection, one of the key features we’ve found to address highly evasive malware is that we need to look at memory as samples execute in addition to using the system API to get a better understanding of what’s happening.
Figure 6. High level Advanced WildFire detection strategy.
We’ve found that, in malware detection, it’s useful to look at the deltas in memory at key points of execution to extract meaningful information and artifacts. As our system processes a vast number of samples, there have been a lot of challenges to make this work at scale. However, a lot of clever engineering built on top of our flagship custom hypervisor tailored for malware analysis has helped make this idea a reality.
In these next few sections, we will detail some of the main types of data that we are currently collecting from memory to aid detection. This data can be utilized by both our analysts for manual signatures as well as machine learning pipelines, which we’ll be discussing in a future post.
Although we are focusing on memory here, we are by no means suggesting that instrumenting and logging API calls are not useful for detection. Our belief is that bringing execution logs and memory analysis data together creates a sum greater than its parts.
Automatic Payload Extraction
As previously discussed, it is increasingly common for malware authors to obfuscate their initial payloads. While using executable packers that can compress and obfuscate files to accomplish this is nothing new, it becomes problematic when it’s used in combination with evasion strategies, because there is no static or dynamic data that’s useful for an accurate detection.
There are infinite combinations of strategies for encoding, compressing, encrypting or downloading additional stages for execution. The ability to craft signatures for these payloads is obviously an important way that our analysts can catch lots of different malware components from frameworks like Cobalt Strike. If we can catch them in memory, it ultimately doesn’t matter if the malware decides not to execute.
The following simplified diagram in Figure 7 shows an example of what we might see in a couple of stages that were never present in the initial executable file.
Figure 7. Typical stages we might see in a packed malware executable.
On the left side of the diagram, we see an example of a shellcode stage. Although the term “shellcode” was originally coined for hand crafted assembly utilized in exploits to pop a shell on a target system, the word has evolved to encompass any blobs of custom assembly written for nefarious purposes. Some malware stages are blobs of custom assembly with no discernable executable structure. A common pattern for malware authors taking this approach is to dynamically resolve all of the function pointers into a table for ease of access.
On the right side of the diagram, we see that the later stage is an example of a well-formed executable. Some malware stages or payloads are well-formed executables. These can be loaded by the OS via the system API, or the malware author might use their own PE loader if they’re trying to be stealthy in avoiding calling any APIs to do this for them.
Function Pointer Data
Another rich set of data we can pull from memory that we’ve begun to use for detection is dynamically resolved function pointers, as shown in Figure 8. Malware authors learned long ago that if they explicitly call out all of the WINAPI functions they plan to use in the import table, it can be used against them. It is now standard practice to hide the functions that will be used by the malware or any of its stages.
Shellcode hashing is another common stealthy strategy used to resolve pointers for functions without needing their string.
Figure 8. Examples of dynamically resolved WINAPI pointers we might see in a memory segment.
In Advanced WildFire we have begun to selectively search for and use this information about which WINAPI function pointers were resolved in our detection logic.
OS Structure Modifications
Another useful source of detection data we’ve found from analyzing memory is to look for any changes to Windows bookkeeping structures (Malware authors love to mess with these!). These structures are important for the OS to maintain state about the process, such as what libraries have been loaded, where the executable image was loaded, and various other characteristics about the process that the OS might need to know later. Given that many of these fields should never be modified, it’s often useful to keep track of when and how malware samples are manipulating them.
The diagram in Figure 9 shows how a sample might unhook a module it loaded from the LDR Module list. Unhooking a module would mean that there is no longer a record that the module exists. So, for example, after doing this the Task Manager in Windows would no longer list it.
This diagram represents only one of many different OS Structure modifications we’ve seen, but it shows that there are many different types of OS structure modifications that are useful for the malware detection problem.
Figure 9. An example of how a module might be unhooked from the LDR Modules List.
Page Permissions
Finally, another useful source of detection data is a full log of all changes made to page permissions. Authors of packed malware often need to change memory permissions in order to properly load and execute further stages. Understanding which pages of memory had their permissions changed often provides important insights into where code was loaded and executed, which can be useful for detection.
Conclusion
Although Cobalt Strike has been around for some years, detecting it is still a challenge to many security software providers. That is because this tool works mostly in memory and doesn’t touch the disk much, other than with the initial loader.
We’ve looked into three new loaders and showed how they can be detected using a variety of techniques. These detection techniques are available within our new hypervisor based sandbox.
Figure 10 illustrates our detection reasons for KoboldLoader.
BeaconType - SMB Port - 4444 SleepTime - 10000 MaxGetSize - 1048576 Jitter - 0 MaxDNS - 0 PublicKey_MD5 - 633dc5c9b3e859b56af5edf71a178590 C2Server - UserAgent - HttpPostUri - Malleable_C2_Instructions - Empty PipeName - \\.\pipe\servicepipe.zo9keez4weechei8johR.0521cc13 DNS_Idle - Not Found DNS_Sleep - Not Found SSH_Host - Not Found SSH_Port - Not Found SSH_Username - Not Found SSH_Password_Plaintext - Not Found SSH_Password_Pubkey - Not Found SSH_Banner - Not Found HttpGet_Verb - Not Found HttpPost_Verb - Not Found HttpPostChunk - Not Found Spawnto_x86 - %windir%\syswow64\dfrgui.exe Spawnto_x64 - %windir%\sysnative\dfrgui.exe CryptoScheme - 0 Proxy_Config - Not Found Proxy_User - Not Found Proxy_Password - Not Found Proxy_Behavior - Not Found Watermark_Hash - Not Found Watermark - 666 bStageCleanup - True bCFGCaution - True KillDate - 0 bProcInject_StartRWX - True bProcInject_UseRWX - False bProcInject_MinAllocSize - 35485 ProcInject_PrependAppend_x86 - b'\x90\x90\x90\x90\x90\x90\x90' b'\x90\x90\x90\x90\x90\x90\x90' ProcInject_PrependAppend_x64 - b'\x90\x90\x90\x90\x90\x90\x90' b'\x90\x90\x90\x90\x90\x90\x90' ProcInject_Execute - ntdll.dll:RtlUserThreadStart NtQueueApcThread NtQueueApcThread-s SetThreadContext RtlCreateUserThread kernel32.dll:LoadLibraryA ProcInject_AllocationMethod - NtMapViewOfSection bUsesCookies - Not Found HostHeader - Not Found headersToRemove - Not Found DNS_Beaconing - Not Found DNS_get_TypeA - Not Found DNS_get_TypeAAAA - Not Found DNS_get_TypeTXT - Not Found DNS_put_metadata - Not Found DNS_put_output - Not Found DNS_resolver - Not Found DNS_strategy - Not Found DNS_strategy_rotate_seconds - Not Found DNS_strategy_fail_x - Not Found DNS_strategy_fail_seconds - Not Found Retry_Max_Attempts - Not Found Retry_Increase_Attempts - Not Found Retry_Duration - Not Found
MagnetLoader beacon configuration data:
BeaconType - HTTPS Port - 443 SleepTime - 3600000 MaxGetSize - 1402498 Jitter - 70 MaxDNS - Not Found PublicKey_MD5 - 965fe5c869f3eea5e211fa7ee12130d3 C2Server - tileservice-weather.azureedge[.]net,/en-au/livetile/front/ UserAgent - Microsoft-WebDAV-MiniRedir/10.0.19042 HttpPostUri - /en-CA/livetile/preinstall Malleable_C2_Instructions - Remove 1380 bytes from the end Remove 3016 bytes from the beginning Base64 URL-safe decode HttpGet_Metadata - ConstHeaders Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Cache-Control: max-age=0 Connection: keep-alive Host: tileservice-weather.azureedge[.]net Origin: https://tile-service-weather.azureedge[.]net Referer: https://tile-service.weather.microsoft[.]com/ Metadata base64url append "/45.40,72.73" uri_append HttpPost_Metadata - ConstHeaders Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Cache-Control: max-age=0 Connection: keep-alive Host: tileservice-weather.azureedge[.]net Origin: https://tile-service-weather.azureedge[.]net Referer: https://tile-service.weather.microsoft[.]com/ ConstParams region=CA SessionId base64url parameter "appid" Output base64 print PipeName - Not Found DNS_Idle - Not Found DNS_Sleep - Not Found SSH_Host - Not Found SSH_Port - Not Found SSH_Username - Not Found SSH_Password_Plaintext - Not Found SSH_Password_Pubkey - Not Found SSH_Banner - HttpGet_Verb - GET HttpPost_Verb - POST HttpPostChunk - 0 Spawnto_x86 - %windir%\syswow64\conhost.exe Spawnto_x64 - %windir%\sysnative\conhost.exe CryptoScheme - 0 Proxy_Config - Not Found Proxy_User - Not Found Proxy_Password - Not Found Proxy_Behavior - Use IE settings Watermark_Hash - Not Found Watermark - 1700806454 bStageCleanup - True bCFGCaution - False KillDate - 0 bProcInject_StartRWX - False bProcInject_UseRWX - False bProcInject_MinAllocSize - 17500 ProcInject_PrependAppend_x86 - b'\x90\x90' Empty ProcInject_PrependAppend_x64 - b'\x90\x90' Empty ProcInject_Execute - CreateThread SetThreadContext ProcInject_AllocationMethod - NtMapViewOfSection bUsesCookies - False HostHeader - headersToRemove - Not Found DNS_Beaconing - Not Found DNS_get_TypeA - Not Found DNS_get_TypeAAAA - Not Found DNS_get_TypeTXT - Not Found DNS_put_metadata - Not Found DNS_put_output - Not Found DNS_resolver - Not Found DNS_strategy - round-robin DNS_strategy_rotate_seconds - -1 DNS_strategy_fail_x - -1 DNS_strategy_fail_seconds - -1 Retry_Max_Attempts - Not Found Retry_Increase_Attempts - Not Found Retry_Duration - Not Found
Unit 42 investigated several incidents related to the Luna Moth/Silent Ransom Group callback phishing extortion campaign targeting businesses in multiple sectors including legal and retail. This campaign leverages extortion without encryption, has cost victims hundreds of thousands of dollars and is expanding in scope.
By design, this style of social engineering attack leaves very few artifacts because of the use of legitimate trusted technology tools to carry out attacks. However, Unit 42 has identified several common indicators implying that these attacks are the product of a single highly organized campaign. This threat actor has significantly invested in call centers and infrastructure that’s unique to each victim.
Cybersecurity awareness training is the most effective defense against these stealthy and discreet attacks. However, Palo Alto Networks customers receive protection from the attacks discussed in this blog through the Next-Generation Firewall and Cortex XDR detecting data exfiltration or connections to suspicious networks.
Callback phishing, also referred to as telephone-oriented attack delivery (TOAD), is a social engineering attack that requires a threat actor to interact with the target to accomplish their objectives. This attack style is more resource intensive, but less complex than script-based attacks, and it tends to have a much higher success rate.
In the past, threat actors associated with the Conti group have had great success with this attack style in the BazarCall campaign. Unit 42 has been tracking these types of attacks since 2021. Early iterations of this attack focused on tricking the victim into downloading the BazarLoader malware using documents with malicious macros.
This new campaign, which Sygnia has attributed to a threat actor dubbed "Luna Moth," does away with the malware portion of the attack. In this campaign, attackers use legitimate and trusted systems management tools to interact directly with a victim’s computer, to manually exfiltrate data to be used for extortion. As these tools are not malicious, they’re not likely to be flagged by traditional antivirus products.
Please note that the tools named in this post are legitimate. Threat actors often abuse, take advantage of or subvert legitimate products for malicious purposes. This does not imply a flaw or malicious quality to the legitimate product being abused.
The Typical Callback Phishing Attack Chain
The initial lure of this campaign is a phishing email to a corporate email address with an attached invoice indicating the recipient’s credit card has been charged for a service, usually for an amount under $1,000. People are less likely to question strange invoices when they are for relatively small amounts. However, if people targeted by these types of attacks reported these invoices to their organization’s purchasing department, the organization might be better able to spot the attack, particularly if a number of individuals report similar messages.
The phishing email is personalized to the recipient, contains no malware and is sent using a legitimate email service. These phishing emails also have an invoice attached as a PDF file. These features make a phishing email less likely to be intercepted by most email protection platforms.
The attached invoice includes a unique ID and phone number, often written with extra characters or formatting to prevent data loss prevention (DLP) platforms from recognizing it. When the recipient calls the number, they are routed to a threat actor-controlled call center and connected to a live agent.
Under the guise of canceling the subscription, the threat actor agent guides the caller through downloading and running a remote support tool to allow the attacker to manage the victim’s computer. This step usually generates another email from the tool’s vendor to the victim with a link to start the support session.
The attacker then downloads and installs a remote administration tool that allows them to achieve persistence. If the victim does not have administrative rights on their computer, the attacker will skip this step and move directly to finding files for exfiltration.
The attacker will then seek to identify valuable information on the victim’s computer and connected file shares, and they will quietly exfiltrate it to a server they control using a file transfer tool.
In this way, the threat actor is able to compromise organizational assets through a social engineering attack on an individual.
After the data is stolen, the attacker sends an extortion email demanding victims pay a fee or else the attacker will release the stolen information. If the victim does not establish contact with the attackers, they will follow up with more aggressive demands. Ultimately, attackers will threaten to contact victims’ customers and clients identified through the stolen data, to increase the pressure to comply.
Luna Moth Campaign Analysis
Unit 42 has responded to multiple cases related to a single campaign that occurred from mid-May to late October 2022. ADVIntel attributes this campaign to a threat actor dubbed Silent Ransom with ties to Conti. While Unit 42 cannot confirm Silent Ransom’s tie to Conti at this time, we are monitoring this closely for attribution.
These cases show a clear evolution of tactics that suggests the threat actor is continuing to improve the efficiency of their attack. Cases analyzed at the beginning of the campaign targeted individuals at small- and medium-sized businesses in the legal industry. In contrast, cases later in the campaign indicate a shift in victimology to include individuals at larger targets in the retail sector.
During the initial campaign, the phishing email frequently originated from an address using the format FirstName.LastName.[SpoofedBusiness]@gmail[.]com as seen in Figure 1. The attacker often spoofs the names of obscure athletes for these email addresses.
Unit 42 has also observed emails with the format [RandomWords]@outlook[.]co.th.
Figure 1. Redacted phishing email.
The wording in the body of the phishing email has changed throughout the campaign. This was likely done to thwart email protection platforms. Regardless of what wording was used, the email always indicated the victim is responsible for the charges detailed in the attached invoice.
PDF documents containing an invoice number were attached to the phishing emails. Unit 42 observed fake invoices spoofing both an online class platform and a health club aggregator in this campaign.
Early incidents used a logo from one of the spoofed businesses at the top of the invoice. Later cases replaced this with the simple header welcoming the target to the second spoofed business on a plain blue background, as shown in Figure 2. Each invoice features a nine- or 10-digit confirmation number near the top, which is also incorporated into the filename. When the recipient contacts the threat actor, this confirmation number is used to identify them.
Figure 2. Redacted fake invoice.
Early iterations of the extortion campaign recycled phone numbers, but later attacks either used a unique phone number per victim, or victims would be presented with a large pool of available phone numbers in the invoice.
The attacker registered all of the numbers they used via a Voice over IP (VoIP) provider. When the victim called one of the attacker’s numbers, they were placed into a queue and eventually connected with an agent who sent a remote assist invitation for the remote support tool Zoho Assist.
The footer of these invitation emails (shown in Figure 3) revealed the email address the threat actor used to register with Zoho. In most incidents, the attacker chose an address from an encrypted email service provider to masquerade as the same vendor used in the fake invoice.
Figure 3. Redacted remote assistance invitation.
Once the victim connected to the session, the attacker took control of their keyboard and mouse, enabled clipboard access, and blanked out the screen to hide their actions.
Once the attacker blanked the screen, they installed remote support software Syncro for persistence and open source file management tools Rclone or WinSCP for exfiltration. Early cases also included remote management tools Atera and Splashtop, but recently the attacker appears to have tightened their toolset.
In cases where the victim did not have administrative rights to their operating system, the attacker skipped installing software to establish persistence. Attackers instead downloaded and executed WinSCP Portable, which does not require administrative privileges and is able to run within the user’s security context.
In cases where the attacker established persistence, exfiltration occurred hours to weeks after initial contact. Otherwise, the attacker only exfiltrated what they could during the call. The attacker exfiltrated data shortly before the attack.
The domains used early in the campaign were random words with a top-level domain (TLD) of .xyz. Later in the campaign, domains consistently followed the format of [5 letters].xyz. All observed domains fell into the 192.236.128[.]0/17 network range.
Exfiltration was followed with an extortion email, as shown in Figure 4. Like in other templates used in this campaign, the wording and format in the extortion email has evolved over time. In the cases Unit 42 investigated, the attacker claimed to have exfiltrated data in amounts ranging from a few gigabytes to over a terabyte.
Figure 4. Redacted extortion email.
The threat actor created unique Bitcoin wallets for each victim’s extortion payments. These wallets contained only two or three transactions and were emptied immediately after funding.
Attacker’s monetary demands ranged from 2-78 BTC. They researched the target organization’s revenue and used it to justify this extortion amount. However, attackers were quick to offer discounts of approximately 25% for prompt payment.
Paying the attacker did not guarantee they would follow through with their promises. At times they stopped responding after confirming they had received payment, and did not follow through with negotiated commitments to provide proof of deletion.
Prevention and Detection
The threat actors behind this campaign have taken great pains to avoid all non-essential tools and malware, to minimize the potential for detection. Since there are very few early indicators that a victim is under attack, employee cybersecurity awareness training is the first line of defense.
People should always be cautious of messages that invoke fear or a sense of urgency. Do not respond directly to suspicious invoices. Contact the requester directly via the channels made available on the vendor’s official website. People should also consult internal support channels before downloading or installing software on their corporate computers.
The second line of defense against this attack type is a robust security technology stack designed to detect behavioral anomalies in the environment. Palo Alto Networks customers receive protection from the attacks discussed in this blog through the Next-Generation Firewall and Cortex XDR detecting data exfiltration or connections to suspicious networks.
Conclusion
Unit 42 expects callback phishing attacks to increase in popularity due to the low per-target cost, low risk of detection and fast monetization. While groups that can establish infrastructure to handle inbound calls and identify sensitive data for exfiltration are likely to dominate the threat landscape initially, a low barrier to entry makes it probable that more threat actors will enter the fray.
Common observables suggest a pervasive multi-month campaign that is actively evolving. Therefore, organizations in currently targeted industries, such as legal and retail, should be particularly vigilant to avoid becoming victims.
All organizations should consider strengthening cybersecurity awareness training programs with a particular focus on unexpected invoices, as well as requests to establish a phone call or to install software. Additionally, expand investments in cybersecurity tools designed to detect and prevent anomalous activity, such as installing unrecognized software or exfiltrating sensitive data.
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)
Unit 42 researchers introduce a machine learning model that predicts the maliciousness of .NET samples based on specific structures in the file, by analyzing a .NET wiper named DoubleZero. We identify the challenges of detecting this threat through PE structural analysis and conclude by examining the cues picked up by the machine learning model to detect this sample.
While wipers are not necessarily new, the recent discovery of several new wipers associated with the ongoing Russia-Ukraine cyber activity has driven renewed public interest in understanding how to identify and defend against their use.
Palo Alto Networks customers receive protections from .NET malwares with Cortex XDR or the Next-Generation Firewall with cloud-delivered security services, including WildFire and Advanced Threat Prevention.
The wiper DoubleZero was revealed to the public by Ukraine CERT in March 2022. It is one of many wipers – including HermeticWiper, IsaacWiper and CaddyWiper – that were apparently targeted against their country.
DoubleZero is implemented in C#, and it is heavily obfuscated. This wiper is capable of typical, non-reversible and destructive actions that include the following:
Gaining the highest privilege in the host
Hunting down all available targeted files from every volume
Destroying targeted files or disk volumes within a short period of time
Unlike HermeticWiper and other wipers that damage the Master Boot Record (MBR) or GUID Partition Table (GPT), DoubleZero only wipes the first 4096 bytes in selected files using the file system driver. We limit our focus on the .NET samples feature engineering, but this Splunk article provides a more in-depth technical analysis of the wiper sample.
Researchers have been commonly using Microsoft Windows Portable Executable (PE) file structure to detect PE malware for many years. The thought behind this tactic is that variants of the same malware family can often share similarities in their file structure.
Machine learning models also detect PE malware based on the file structure. To do so, they have historically used PE header characteristics, imports and section attributes to recognize known malware characteristics.
While the .NET PE file structure is based on the PE format, a lot of its functionality is encoded within the .NET specific structures. In the next section, we’ll dive deeper into the .NET structural attributes.
An Inside Look Into .NET files
The .NET open source framework was introduced in 2002 and is available by default in most Microsoft Windows platforms. The framework provides developers with powerful, built-in methods to access the internet, file system and encryption. Having these options already available makes this framework attractive to both system administrators and malware authors.
Microsoft Windows PE loader will already know how to load and execute the .NET sample once the framework is ready, since .NET assembly re-uses the PE file format.
During code generation, the source code for .NET compatible languages is compiled to platform-agnostic Common Intermediate Language (CIL) byte code. A special .NET IMAGE_DIRECTORY_ENTRY_COM_DESCRIPTOR can be found in the data directory for referencing the Cor20 header, as shown in Figure 1. The Cor20 header (otherwise known as the CLR header) contains .NET specific information like versioning and resource information and the location of the Metadata header. The resources, streams, type references, methods, CIL byte codes and usage of external assemblies are all in the metadata. For a more detailed description, please refer to our article on dotnetfile.
Figure 1. A simple illustration of .NET file structure.
Unlike most PE files, where dependent libraries and APIs can be found in the import table, for a .NET file the import table contains just one module (the mscoree.dll) and one imported function (_CorExeMain for executables and _CorDllMain for dynamic load libraries). The resources are contained within the .NET storage stream instead of the .rsrc section.
The entry point of the PE header points to the _CorExeMain or _CorDllMain of the mscoree.dll, while the actual entry point can be found in the Cor20 header as shown in Figure 2. Thus, some of the most useful attributes to identify PE malware files do not contain many clues for .NET malware.
Figure 2. .NET specific structures and the data they hold.
The metadata table contains defined tables for Module, MethodDef and Assembly among others. By examining the .NET file structure, we can see it provides a lot more information about the file as compared to the PE file structure alone. Instead of only using the general PE features for the .NET machine learning solution, we added the data specifically parsed from the structure of .NET samples. These customized features improve the quality of our machine learning solutions.
Applying Machine Learning to .NET Malware Detection
We have trained a machine learning model on custom features learned on the PE file structure, .NET file structure and other file characteristics of .NET samples, as shown in Figure 3.
As .NET is an extremely popular file type in customer environments, it is necessary for us to have a quick turnaround time in case any disruptive false positives emerge. This means that our model’s functionality has to be well understood by researchers, and that the predictions could be reverse engineered.
Because .NET files are so ubiquitous, they also have a highly imbalanced distribution of benign vs. malicious samples. Consequently, the trained model has to ensure that we maintain extremely low false positive rates while retaining detection accuracy.
Figure 3. An overview of our detection workflow.
Detecting the DoubleZero Wiper
The malware sample has a single import, _CorExeMain, from mscoree.dll, consistent with other .NET executable files. It contains only .text and .reloc sections, all of which are native to the PE file format and have fairly low entropy. Hence, there’s not much we can learn from this file’s PE structure.
The CIL bytecode uses obfuscation to hide the string resources that are critical for pattern based detection. It also interleaves random code among actual operations, together with flattened control flow, to make the code harder to follow. However, we can glean a lot about the objective of this malware by observing the imported libraries and associated API calls found in the decompiled code.
The imports System.DirectoryServices.ActiveDirectory and System.Security.AccessControl indicate the intention to interact with the Active Directory and access control attributes of the files.
The regular expression function imported by System.Text.RegularExpressions is used to locate certain files by patterns.
The most significant signs of malicious code usage are the calls to the unmanaged DLL functions. Platform Invoke (P/Invoke) enables the managed codes in .NET to call the unmanaged functions. Calling the lower level APIs directly is a well known anti-analysis technique to evade API hooking by sandbox. The following unmanaged APIs are used in the sample:
ntdll.ntopenfile
ntdll.ntfscontrolfile
ntdll.rtlntstatustodoserror
ntdll.rtladjustprivilege
kernel32.closehandle
kernel32.getfilesizeex
kernel32.getlasterror
user32.exitwindowsex
In most of the use cases, there are equivalent managed functions in .NET runtime libraries to use. However, this sample intends to operate at a lower level with some of the unmanaged APIs in ntdll.dll.
The target files and the regular expression patterns are surprisingly stored as plain strings, as shown in Figure 4. This possible mistake by the threat actor allows us to get more insights about the objective of the sample.
Figure 4. An example decompiled code snippet where the sample uses regular expressions to search the target files.
Though obfuscation exists, we are still able to get the argument FsControlCode for the call to ntdll.NtFsControlFile, which is 0x980c8 = FSCTL_SET_ZERO_DATA. This is how the wiper writes 4K of null bytes to a targeted file that was opened by ntdll.NtOpenFile.
The sample calls ntdll.RtlAdjustPrivilege several times with privileges 9, 17, 18 and 19. These privileges are SeTakeOwnershipPrivilege, SeBackupPrivilege, SeRestorePrivilege and SeShutdownPrivilege respectively. These privileges are used to ensure the wiper has the access right to destroy the target file and reboot the system after all the actions are done.
Unlike HermeticWiper and ransomware like LockBit, DoubleZero doesn’t delete the shadow copies that can possibly be used to recover files from the damage. However, the wiper does kill any process named lsass. Lsass is important to the Windows system, and any application that kills this process is most likely malicious.
The aforementioned file characteristics give us clues that the machine learning model uses to detect the sample. Though obfuscation is more common among malicious .NET files, because the sample uses several unmanaged APIs as well as sensitive target path patterns, these stand out as potentially malicious indicators.
Conclusion
Researchers have been using PE file structure to detect variants within malware families for years, as they often share similarities in their file structure. Despite the .NET framework being well known, it can still be challenging to detect files using this strategy. Some of the most useful attributes for identifying PE malware files don’t offer many clues for identifying .NET malware.
We have highlighted the fundamental difference between .NET and PE samples to help identify where those clues could be hiding. In doing so, we illustrated that machine learning feature engineering can be improved by correctly parsing out the .NET specific data structure.
We also showed that imported libraries, unmanaged API calls and unencrypted strings are the most useful features for detecting .NET malware. While a recent wiper called DoubleZero was analyzed as an example, the features that are important for detecting .NET can be generalized, and this feature can be broadly useful for future research efforts.
Recent May-July 2022 observations of network security trends and exploits used in the wild reveal that attackers have been making use of newly published remote code execution vulnerabilities. In our observations of network security trends, Unit 42 researchers have pinpointed several attacks based on proof-of-concept (PoC) availability and impact. We have detailed below which of these we believe should be on the defender’s radar.
Other insights that could assist defenders include the following:
Rankings of the most commonly used attack techniques and the types of vulnerabilities that attackers have recently favored. For example, among 5,976 newly published vulnerabilities, a large portion (almost 11.6%) involves cross-site-scripting.
Lists of major vulnerabilities identified by evaluating more than 340 million attack sessions including remote code execution, directory traversal and information disclosure.
Insight into how these vulnerabilities are exploited in the wild based on real-world data collected from our Next-Generation Firewalls.
Summaries of key trends from May-July 2022.
Analysis of the most recently published vulnerabilities, including the severity and attack origin distribution.
Classification of these vulnerabilities to provide a clear view of the prevalence of the different types, such as cross-site scripting or denial-of-service.
Lists of the most commonly exploited vulnerabilities attackers are using, as well as the severity, category and origin of each attack.
Palo Alto Networks customers receive protections from the vulnerabilities discussed here through the Next-Generation Firewall and Cloud-Delivered Security Services, including Threat Prevention, WildFire, Advanced URL Filtering and Cortex XDR.
Analysis of Published Vulnerabilities, May-July 2022
From May-July 2022, a total of 5,976 new Common Vulnerabilities and Exposures (CVE) numbers were registered. To better understand the potential impact these newly published vulnerabilities could have on network security, we provide our observations based on the severity, availability of working proof-of-concept (PoC) code, and vulnerability categories.
How Severe Are the Latest Vulnerabilities?
To estimate the potential impact of vulnerabilities, we consider their severity and examine any reliable PoCs available that attackers could easily launch. Some of the public sources we use to find PoCs are Exploit-DB, GitHub and Metasploit. Distribution of the 5,976 CVEs that have an assigned severity score of medium or higher can be seen in the following table:
Severity
Count
Ratio
PoC Availability
Change
Critical
1133
19.0%
5.5%
-2.3%
High
2399
40.1%
3.8%
-1.0%
Medium
2444
40.9%
3.4%
-0.2%
Table 1. Severity distribution for CVEs registered May-July 2022,including only those rated medium-critical.
Figure 1. Severity distribution for CVEs registered May-July 2022, including only those rated medium-critical.
Our classification of vulnerabilities is based on CVSS v3 scores. Many conditions must be met to rate a vulnerability as critical, so there are very few at this level. One of the common factors for rating a vulnerability at this level is having a working PoC available. To be considered critical, vulnerabilities generally have low attack complexity, and it is often easy to create a PoC to exploit them.
In the period discussed, the critical-severity ratios increased while high-severity and medium-severity PoC ratios decreased slightly.
Vulnerability Category Distribution
It is crucial to understand each type of vulnerability and its consequences. Out of the newly published CVEs that were analyzed, 23.5% are classified as local vulnerabilities, requiring prior access to compromised systems, while the remaining 76.5% are remote vulnerabilities, which can be exploited over a network. This means that most newly published vulnerabilities introduce potential opportunities for threat actors to attack vulnerable organizations from anywhere in the world.
In Figure 2, the most common vulnerability types are ranked by how prevalent they were among the most recent set of published vulnerabilities.
Figure 2. Vulnerability category distribution for CVEs registered May-July 2022.
Cross-site scripting remains the most reported vulnerability during May-July 2022. We also saw that the prevalence of SQL injection vulnerabilities increased during this time, and many of the vulnerabilities in this category are ranked critical. The number of SQL injection and cross-site scripting vulnerabilities slightly increased and out-of-bound vulnerabilities decreased. Most of the recently published cross-site scripting and information disclosure attacks are usually at medium or high severity (rather than critical).
Figure 3. Vulnerability category distribution compared with the previous quarter.
Network Security Trends: Analysis of Exploits in the Wild, May-July 2022
Data Collection
By leveraging Palo Alto Networks Next-Generation Firewalls as sensors on the perimeter, Unit 42 researchers observed malicious activities from May-July 2022. The malicious traffic we identified is further processed and based on metrics such as IP addresses, port numbers and timestamps. This ensures the uniqueness of each attack session and thus eliminates potential data skews. We analyzed 340 million valid malicious sessions and then correlated the refined data with other attributes to infer attack trends over time to get a picture of the threat landscape.
How Severe Were the Attacks Exploited in the Wild?
To arrive at 340 million valid malicious sessions, we excluded the original set of low-severity signature triggers used to detect scanning and brute-force attacks, as well as internal triggers used for research purposes. Therefore, we consider exploitable vulnerabilities with a medium and higher severity ranking (based on the CVSS v3 Score) as a verified attack.
Figure 4. Attack severity distribution, May-July 2022, including only medium-critical vulnerabilities.
Figure 4 shows the ratio of attacks grouped by the severity of each vulnerability. Compared with the previous quarters' severity distribution, this quarter shows a decrease in critical- and high-severity attacks and an increase in medium-severity attacks. However, we still focus more on critical-severity attacks because of their greater potential impact. Many published vulnerabilities are scored medium severity, but attackers typically leverage more severe vulnerabilities for exploits. Defenders should prioritize preventing and mitigating high- and critical-severity network attacks.
Figure 5. Vulnerability severity distribution compared with the previous quarter.
When Did the Network Attacks Occur?
Figure 6. Severity of exploits in the wild measured weekly from May-July 2022.
During May-July 2022, attackers gradually increased their exploitation of vulnerabilities of medium severity, and the number of attacks gradually increased (the last set of data records eight days of attack volume instead of seven days).
As we’ve seen in the past, attackers frequently use recently disclosed vulnerabilities, especially those from 2021-22. This shows the importance of updating security products and applying software patches as soon as they become available to protect against the most recently discovered vulnerabilities.
Figure 7. Observed attacks broken down by the year in which the exploited CVE was disclosed, measured weekly from May-July 2022.
Exploits in the Wild, May-July 2022: A Detailed View of Network Security Trends
Attack Category Distribution
We classified each network attack by category and organized them in terms of prevalence. In the period discussed, remote code execution ranks first, followed by information disclosure. Attackers typically want to gain as much information and control as possible over the systems they target. Traversal attacks decreased this quarter.
Figure 8. Attack category and severity, May-July 2022.Figure 9. Attack category distribution compared to the previous quarter.
Where Did the Attacks Originate?
After identifying the region from which each network attack originated, we discovered that the majority of them seem to originate from the United States, followed by Germany then the Netherlands. Attacks from the Netherlands and Romania increased significantly this quarter. However, we recognize that the attackers might leverage proxy servers and VPNs located in those countries to hide their actual physical locations.
Figure 10. Locations ranked in terms of how frequently they were the origin of observed attacks from May-July 2022.Figure 11. Attack originate distribution compared to the previous quarter.Figure 12. Attack geolocation distribution from May-July 2022.
Conclusion
The vulnerabilities disclosed from May-July 2022 indicate that web applications remain popular targets for attackers, and that critical vulnerabilities are more likely to have PoCs publicly available.
In the meantime, we continue to capture newly published vulnerabilities that are exploited in the wild. This emphasizes the need for organizations to promptly patch their systems and implement security best practices. Attackers continue to make a concerted effort to expand their tool kit of exploits whenever possible.
Get updates from Unit 42 