Six Malicious Python Packages in the PyPI Targeting Windows Users

Posted on by Samantha Stallings

Executive Summary

In March 2023, Unit 42 researchers discovered six malicious packages on the Python Package Index (PyPI) package manager. The malicious packages were intended to steal Windows users’ application credentials, personal data and tracking information for their crypto wallets. The attack was an attempted imitation of the attack group W4SP, which had previously launched several supply chain attacks using malicious packages.

We will discuss the ease with which threat actors can use malicious packages to release malicious code in an open-source ecosystem. The behavior we observed is not an organized campaign planned by an attack group, but most likely an imitator who read technical reports of previous campaigns to execute their own attack. We will walk through a technical analysis of the malicious code and unravel what the threat actor tried to achieve in the attack.

We will describe the indicators used by Palo Alto Networks Prisma Cloud modules that identified the malicious packages discussed here. Palo Alto Networks customers receive protections from open-source packages containing malicious code via Prisma Cloud.

Related Unit 42 Topics Cloud, Python, Open Source

Overview

Malicious packages are software components that were intentionally designed to cause harm to computer systems or the data they process. Such packages can be distributed through various means, including phishing emails, compromised websites or even legitimate software repositories.

Malicious packages can have far-reaching consequences, from surreptitiously pilfering sensitive data to causing system disruptions and even assuming control over entire systems. Moreover, these nefarious packages possess the ability to spread to other interconnected systems, instigating widespread damage and impeding productivity. Thus, it is important to exercise utmost caution when engaging in software downloads and installations, especially when the source is unfamiliar or untrusted.

By remaining vigilant and discerning, users can safeguard their systems and prevent potential harm from threat actors infiltrating their technological environment.

New Malicious Packages Discovered in PyPI

In March 2023, Prisma Cloud researchers discovered six malicious packages on the PyPI package manager targeting Windows users. The malicious packages were intended to steal application credentials, personal data and cryptocurrency wallet information.

Our Prisma Cloud engine, designed to detect malicious PyPI packages, identified several packages with suspicious attributes that were uploaded within a short time frame:

  • The packages lacked an associated GitHub repository, which is commonly found with legitimate packages. This could indicate a desire to hide the code from view. This, coupled with a limited number of downloads, further raised our suspicions.
  • When executed, the packages performed malicious actions such as collecting sensitive data and sending it to third-party URLs.
  • The packages contained a malicious code pattern (as will be demonstrated later), which was detected by our engine.
  • Because the package authors were newly created, had only uploaded one package, and did not provide supporting information such as links to other projects or to any repository, they were not considered reputable.
  • Finally, the usernames of the packages’ author(s) were created within minutes of each other, following a distinctive pattern (e.g., Anne1337, Richard1337). Each of these usernames had uploaded only a single package.

The second stage of the attack was similar to previous attacks we have seen by the W4SP attack group. This group specializes in exploiting vulnerabilities in the open-source ecosystem, targeting organizations and spreading malware. Their primary goal is to gain unauthorized access to sensitive information, such as user credentials and financial data. They often use automated tools to scan for vulnerabilities and attempt to exploit them. In addition to traditional attacks, W4SP attackers were also seen executing supply chain attacks.

Findings

Prisma Cloud engine detected the packages that were marked as potentially containing malicious code. Each package contained a link to a suspicious remote URL, trying to download contents after having been uploaded individually by a single user.

The users for each uploaded package, whose usernames were created just before the upload, didn’t have any history of previously uploading packages. Each package reached hundreds of downloads, until they and the fraudulent user accounts that uploaded them were removed by PyPI due to our research team reporting the abuse.

We analyzed the code and tried to track down the package authors. We discovered a pattern in every package author’s username where they used “1337” as a suffix, which indicates that some automatic process created those users, as shown in Table 1. Figure 1 shows an author page for one of these usernames.

Package Name Author  Malicious Link Number of Downloads
ligitgays Anne1337 hxxps://paste.bingner[.]com/paste/o27gb/raw 191
xboxredeemer Richard1337 hxps://paste.bingner[.]com/paste/47rpu/raw 160
syntax-init Debbie1337 hxxps://paste.bingner[.]com/paste/q77t3/raw 140
xboxlivepy Christopher1337 hxxps://paste.bingner[.]com/paste/jr7ow/raw 153
Ligitkidss Sara1337 hxxps://paste.bingner[.]com/paste/9mzzs/raw 158
tls-python Kevin1337 hxxps://paste.bingner[.]com/paste/97vnn/raw 240

Table 1. Malicious package findings.

Image 1 is a screenshot of an author page on PyPI. The user has not uploaded any projects. The name of the user is Travis Elliott, they joined March 13, 2023, and their user name is Richard1337.
Figure 1. An author page on PyPI.

The Attack: Custom Package Entry Point

The attack was similar to previous attacks we have seen by the W4SP attack group, which was covered in detail in the Bleeping Computer article, “Devs targeted by W4SP Stealer malware in malicious PyPi packages.” These similarities led us to believe this was a copycat attack.

There were aspects of this case that were less complex than we would expect for a true W4SP attack, for example:

  • There was no targeting of any organization.
  • The malicious packages did not use typosquatting for common popular packages, as expected for W4SP attacks.
  • The second phase of the attack was not encrypted. In the true attacks from W4SP, this phase was encrypted and it made detection more difficult.
  • Most of the code used by W4SP for previous attacks was already available for download, so it could be easily accessed and repurposed.

In the previous attack, W4SP Stealer was delivered as a second stage payload downloaded from a free file hosting service, which allowed the attacker to avoid detection at the package repository itself.

Rather than containing overtly malicious code, these packages were crafted to have specific entry points that would be triggered during the installation or execution process. By leveraging free file hosting services and employing custom entry points, the attackers aimed to remain undetected, posing a significant challenge to security professionals and researchers tasked with detecting and mitigating such threats.

These attacks are easy to implement and can be launched with little security expertise. However, they can be very effective, as the installation process automatically executes the attack as opposed to a threat actor needing to launch the attack when the imported module is used.

When a software developer wants to use a Python package they have to perform two actions. The first is to install the package, and the second is to import or declare in the code to use it. As we discuss in the next section, the attack code actually starts in the installation file (setup.py), which means that the attack is already carried out during the installation of the package.

In the case we investigated, the attacker called themself @EVIL$ STEALER. However, the attacker’s name changed with every attack. Below is the collection of names, as found in the code signature:

  • ANGEL Stealer
  • Celestial Stealer
  • Fade Stealer
  • Leaf $tealer
  • PURE Stealer
  • Satan Stealer
  • @skid Stealer

Malicious Code

The setup.py file was the same in all packages and contained the following code snippet that downloads content from a remote URL before executing it:

Image 2 is a screenshot of many lines of python code. This code snippet downloads content from a remote URL before executing it.
Figure 2. Setup.py (first stage) malicious code.

Figure 2 (above) shows the following activities:

  1. The attacker uses the _ffile object to create a temporary file, and the contents of the file are written using the write method.
    • The usage of a temporary file with the NamedTemporaryFile function is a well-known technique to hide malicious code from detection by antivirus software or other security measures.
  2. The file's contents are obtained by downloading the contents of a URL using the urlopen function from the urllib.request module, and then executes the contents of the file using the exec function.
  3. After the contents of the temporary file have been written, the file is closed and an attempt is made to execute it using the start command in the system shell. If this is successful, the setup function is called to create the package.
    • The attacker then uses the start command to start the Python engine's executable (pythonw.exe).
    • This executable will then execute the script file that is passed as a parameter. Since that malicious package targeted Windows users, if the script file is not signed, it will not be subject to SmartScreen (Windows security feature to detect and prevent the execution of potentially malicious files) or signature checking.
    • This means it will execute malicious code on a target computer, even if the target computer has SmartScreen and signature checking enabled.

The Second Stage: W4SP Stealer

According to our research, for the second stage, the attacker used a configured version of W4SP Stealer 1.1.6. This version is similar to previous ones where the code imports several libraries, including requests, Crypto.Cipher, json and sqlite3. Then, it uses various techniques to extract and decrypt stored browser credentials, including passwords and cookies, and sends this information to a Discord webhook.

This stage was similar within all of the malicious packages found. The W4SP Stealer is well known by the cybersecurity community. This section will give a short overview.

The main body of the code defines a class DATA_BLOB, which is used to store data for the CryptUnprotectData function. This function decrypts a Windows Data Protection API (DPAPI)-protected value, which is used to store sensitive data such as passwords and API keys. The code attempts to decrypt a value using the CryptUnprotectData and DecryptValue functions, and then sends it to a remote server via a Discord webhook, as shown in Figure 3.

Image 3 is a screenshot of many lines of code. It first defines the DATA_BLOB class before attempting to decrypt a value.
Figure 3. Attempts to decrypt a Windows Data Protection API (DPAPI)-protected value.

The figures below show several examples from the malicious code in which the attacker tries to collect information about the victim. In Figure 4, the attacker tries to collect information about the victim including IP address, username, country and country code.

Image 4 is a screenshot of code that retrieved information about the user’s IP address, location, and user name along with country code, country name, and other information.
Figure 4. Code that retrieves information about the user's IP address, location and username among other things.

In Figure 5, the attacker interacts with the Discord API to retrieve a user's friend list and extract information about their owned badge.

Image 5 is a screenshot of code that retrieves a list of a user’s friend on Discord, which is an application that acts like a custom chat room. These chat rooms are called channels.
Figure 5. Code to retrieve a list of a user's friends on Discord.

Later in code, they try to use a Discord webhook prepared in advance (shown in Figure 6) and then they try to send the victim information via HTTP requests to the associated Discord channel.

Image 6 is a screenshot of a Discord API webhook.
Figure 6. Discord webhook.

Finally, as shown in Figure 7, the attacker tries to verify whether the victim's machine is suitable for carrying out the attack. If it’s determined that the machine is suitable, the DETECTED variable will be set to true and the information from the victim's machine will be sent to the remote server.

Image 7 is a screenshot of code that can search for cookies.
Figure 7. Code searching for cookies.

PyPI as a Convenient Platform for Uploading Malicious Packages

Within the realm of PyPI, which is a revered and widely embraced repository that hosts a staggering number of Python packages, a disconcerting reality has emerged. The repository's unrivaled popularity has inadvertently attracted the attention of unscrupulous entities, fervently seeking to exploit its vast user base by surreptitiously disseminating malicious packages.

This distressing trend poses a paramount challenge, as the decentralized nature of PyPI renders the monitoring and detection of these malevolent entities an arduous endeavor. The ramifications of falling victim to such nefarious packages are profound, posing severe consequences for unsuspecting users and enterprises alike, such as data, credential or crypto theft. Hence, fortifying the safety and security of PyPI's package ecosystem assumes a critical imperative, necessitating the implementation of robust countermeasures to combat this persistent threat.

As a result of this, it was not surprising that on May 20, 2023, PyPI announced that they temporarily suspended the registration and upload of new packages due to a concerning rise in malicious activities, malicious users and projects on the platform. Unfortunately, no specific information about the nature of the malware or the threat actors involved has been disclosed at this time.

This decision to freeze new user and project registrations reflects the ongoing challenges software registries like PyPI face, as they have become attractive targets for attackers seeking to compromise developer environments and tamper with the software supply chain.

Conclusion

The rise and prevalence of open-source software and the proliferation of package managers have made it easier than ever for attackers to slip these dangerous packages into unsuspecting systems. With software becoming increasingly pervasive in our daily lives, the threat of malicious packages has become more significant. Attackers can disguise these packages as legitimate software and exploit vulnerabilities in unsuspecting systems, causing significant damage such as data theft, system shutdown and network control.

To combat this threat, software developers and organizations must prioritize software security in their development process. Implementing robust security measures, such as code reviews, automated testing and penetration testing can help identify and remediate vulnerabilities before deployment. Additionally, staying up to date with security patches and updates can prevent attackers from exploiting known vulnerabilities.

In addition to technical measures, increasing awareness and education around software security can also help mitigate the risk of malicious packages. Regular training for developers, IT staff and end users on best security practices (e.g., password hygiene and suspicious email identification) can help prevent successful attacks. The collective effort of security professionals, developers and end users is necessary to ensure that malicious packages are identified and prevented from causing harm to systems and networks.

Publishing technical reports about malware and malicious packages also plays a critical role in advancing our understanding of these threats and improving our ability to protect against them. Technical reports provide an in-depth analysis of the behavior and functionality of malware, which helps researchers and security professionals develop more effective countermeasures. Additionally, sharing technical details about malware can help organizations stay up to date with the latest threats and vulnerabilities, allowing them to improve their security posture and reduce the risk of cyberattacks.

Palo Alto Networks Product Protections

Prisma Cloud Runtime Protection Solution

Prisma Cloud runtime defenses involve a configurable set of features that provide the identification of specified and predictive protections for cloud virtual machines, containers and serverless functions. Predictive protections include capabilities like determining when a cloud or container instance executes an unknown process or creates an unexpected network socket.

Threat-based protections include capabilities like detecting when malware is added to a workload, or when a workload connects to a botnet. This detection of malicious binaries is made possible through the integration of the Palo Alto Networks WildFire cloud-based malware protection engine. These runtime incidents can also be detected predeployment, using the Image Analysis Sandbox.

Prisma Cloud Malicious Package Solution

Prisma Cloud offers an advanced end-to-end cybersecurity solution that encompasses a comprehensive suite of proactive measures designed to safeguard Prisma customers against a wide array of potential attacks, mitigating risks well in advance of their public exposure.

At the heart of this cutting-edge defense system lies the Prisma CVE Viewer, a dynamic resource that operates in real-time, continuously updated to reflect the latest threat landscape.

Incorporating a unique identification system known as Prisma-IDs, this viewer serves as a central repository for public vulnerabilities meticulously unearthed by our diligent research team. Leveraging this proprietary identifier, it bridges the gap for vulnerabilities that have yet to receive a Common Vulnerabilities and Exposures (CVE) ID, ensuring no security gaps go unnoticed or unaddressed. Moreover, the Prisma CVE Viewer diligently archives any malicious packages discovered by our expert researchers, empowering Prisma customers with unparalleled visibility into potential threats lurking within their software supply chain.

As shown in Figure 8, by arming customers with Prisma-IDs and equipping them with preemptive protection, Prisma Cloud protects against possible exploits before they have an opportunity to materialize. This robust security approach serves as a formidable deterrent against supply chain attacks, proactively thwarting threats and preserving the integrity and resilience of our customers' systems and infrastructure.

Image 8 is a screenshot of the Prisma Cloud application. It is the CVE viewer. It has detected a malicious package in its CVE database. There is a search field, and then a table displaying the CVE, package, distro, release, CVSS score, which is 7.5, the severity, which is high, the affected versions, and when it was modified in IS.
Figure 8. Prisma Cloud detection.

On top of that, the new Prisma Cloud CI/CD Security module (shown in Figure 9) offers comprehensive protection against emerging methods of executing code in CI pipelines and developers’ environments through malicious software dependencies (e.g., dependency confusion, typosquatting and compromised known packages). This is done by analyzing the different settings, configurations and interconnections of the various systems across the software delivery pipelines, such as the version control and CI systems.

Image 9 is a screenshot of the Prisma Cloud CI/CD Security module. It is a dashboard with many different statistics displaying a wide range of data.
Figure 9. Prisma Cloud CI/CD Security module.

Cortex EDR analytics

Cortex XDR provides EDR analytics capabilities on top of Cortex XDR agents, thus providing analytics-based detection capabilities for runtime command and control (C2) detection of malicious Python packages being used at runtime. An example for EDR analytics C2 coverage is discussed in our Cortex XDR technical documentation. See the Variant subsection “UNIX LOLBIN process connected to a rare external host” under the "A process connected to a rare external host" section.

Indicators of Compromise

Malicious Packages

  • ligitgays
  • xboxredeemer
  • syntax-init
  • xboxlivepy
  • Ligitkidss
  • Tls-python


Malicious URLs

  • hxxps://paste.bingner[.]com/paste/o27gb/raw
  • hxps://paste.bingner[.]com/paste/47rpu/raw
  • hxxps://paste.bingner[.]com/paste/q77t3/raw
  • hxxps://paste.bingner[.]com/paste/jr7ow/raw
  • hxxps://paste.bingner[.]com/paste/9mzzs/raw
  • hxxps://paste.bingner[.]com/paste/97vnn/raw

Malicious Users

Updated July 14, 2023, at 9:15 a.m. PT to add more context to the code in Figure 2. 

Manic Menagerie 2.0: The Evolution of a Highly Motivated Threat Actor

Posted on by Samantha Stallings

Executive Summary

Unit 42 researchers discovered an active campaign that targeted several web hosting and IT providers in the United States and European Union from late 2020 to late 2022. Unit 42 tracks the activity associated with this campaign as CL-CRI-0021 and believes it stems from the same threat actor responsible for the previous campaign known as Manic Menagerie.

The threat actor deployed coin miners on hijacked machines to abuse the compromised servers’ resources. They have further deepened their foothold in victims’ environments by mass deployment of web shells, which granted them sustained access, as well as access to internal resources of the compromised websites.

In doing so, the attackers could potentially have turned the hijacked legitimate websites – hosted by the targeted web hosting and IT providers – into command and control (C2) servers at scale, affecting thousands of web pages. The threat actor could thus run their C2 activity from legitimate websites that have good reputations, and which are not necessarily flagged by security solutions as malicious. This could have a tremendous impact on the abused legitimate websites, which would in that circumstance be made to unknowingly host malicious content and harbor criminal activity. Such criminal activity could inflict legal and/or reputational damages upon the owners of the websites or the web hosting companies.

While operating in the victims’ networks, the attackers attempted multiple techniques to evade the detection of various monitoring tools as well as active commercial cybersecurity products. They also kept executing payloads, redeploying and rerunning tools that were previously blocked, or using other similar tools. Attackers tried to stay under the radar by avoiding known malware, introducing custom tools and relying on publicly available legitimate tools.

Based on the tactics, techniques and procedures (TTPs) that we observed in this attack, the threat actor whose previous campaign was dubbed Manic Menagerie carried out this more recently observed campaign, which we therefore call Manic Menagerie 2.0.

This threat actor was reported as active from at least 2018, targeting web hosting companies in Australia, by the Australian Cyber Security Center. The name is most likely a reference to their noisy activity, plus the large number of attacked web hosting companies and different tools used by the attacker.

Palo Alto Networks customers receive protections from the threats mentioned in this article through the following products and services:

Related Unit 42 Topics Cryptominers, Web shells

Initial Access and Persistence

The initial foothold in the Manic Menagerie 2.0 campaign was first observed in late 2020, targeting companies in the United States and European Union. In this campaign, the threat actors gained access to target machines by exploiting vulnerable web applications and IIS servers, and deploying different web shells on these infected servers.

Deploying web shells on an active web server allows the threat actor to hijack legitimate websites. The web shells are placed on these hosted websites in the following folders on the compromised server: C:\[hosted websites on the server path]\wwwroot\example.com\webshell.aspx)

These actions also allow public access from outside the victim’s network in the future. This effectively allows these websites to be turned into future C2 servers for the attacker.

We also observed the same web shell, xn.aspx, mentioned in the Australian Cyber Security Center’s (ACSC) report about the original Manic Menagerie operation targeting web host companies in Australia.

After deploying web shells in Manic Menagerie 2.0, the threat actor initiated the deployment of coin miners. This was likely done to abuse the compromised servers' powerful computing resources for the threat actor’s financial gain through coin mining.

During 2021-2022, upon the public disclosure of multiple Microsoft Exchange Server vulnerabilities, the threat actor attempted to exploit the following vulnerabilities in some targets:

  • CVE-2021-26855, CVE-2022-41040: (ProxyNotShell) Exchange Server SSRF vulnerabilities
  • CVE-2021-34473: (One of the ProxyShell vulnerabilities) Exchange Server remote code execution vulnerability
  • CVE-2021-33766: (ProxyToken) Allows an attacker to modify the configuration of mailboxes of arbitrary users

Therefore, in addition to vulnerabilities in the IIS servers as well as vulnerable web applications in the environment, the previously mentioned vulnerabilities provided the threat actor another penetration and persistence vector. Morphisec recently researched a campaign where attackers used Exchange Server vulnerabilities (collectively known as ProxyShell) to drop cryptominers.

Reconnaissance and Privilege Escalation

From late 2020, threat actors involved in the Manic Menagerie 2.0 campaign began periodically trying to execute local privilege escalation proof-of-concept (PoC) tools (detailed below) to add their own users to the Administrators group in IIS servers, to further promote their interests. When one tool failed, they would try another tool with similar functionality.

Attackers employed a runas.exe .NET wrapper called RunasCs. This publicly available tool enables extended functionality that the original runas.exe utility lacks, such as executing processes by using explicit user credentials.

The threat actors were observed attempting to perform further network reconnaissance in an infected environment by running under a vulnerable web application. They then attempted to add their own user by running au.exe (shown in Figure 1), which is short for “add user.” This file must be run by an elevated user. They then made sure their username existed by running net commands.

Their usage of the usernames iis_user and iis_uses is notable, as the latter might initially seem to be a typo. This naming convention is also mentioned in the ACSC report mentioned above.

Image 1 is a screenshot of the Command Prompt. The user is au.exe and creates iis_user as well as a password. There is some redacted information in this screenshot.
Figure 1. au.exe creates iis_user user and generates a password for it.

The aforementioned au.exe is a tool that the threat actor attempted to run multiple times, chained with different PoC local privilege escalation tools, as shown in Figure 2.

Image 2 is a tree diagram of the blocked execution of RunasCs. The execution is blocked at the second level.
Figure 2. Attempted execution of RunasCs together with other commands under a vulnerable web application, blocked by Cortex XDR.

The threat actor was observed using multiple tools for the same purpose of privilege escalation. In Figure 2 above, a 64-bit version of PrintSpoofer is one of these tools. This public tool was used by attackers to elevate au.exe, which otherwise wouldn’t add the user it was intended to.

Fork Bomb and More Local Privilege Escalations

The threat actors were observed attempting local privilege escalation (LPE) using multiple publicly available tools, leveraging the following vulnerabilities:

Another interesting execution that we observed in Manic Menagerie 2.0 is the svchost.exe fork bomb. The ACSC report on the original Manic Menagerie campaign also mentioned the presence of this type of denial-of-service (DoS) tool.

The code for this fork bomb is very simple, as it runs in an endless loop (shown in Figure 3), opening more and more instances of itself until the machine runs out of memory. This activity is intended to crash the machine and force a reboot. This allows the persistence mechanism of an executable that requires a reboot to fire up.

Image 3 is a screenshot of the code snippet creating an endless loop from the form bomb binary. It starts with while(1).
Figure 3. The endless loop code snippet from the fork bomb binary.

dllnc.dll: Run Payloads and Add User Tool

Another tool that we observed in the Manic Menagerie 2.0 campaign called dllnc has two main features. One is loading some of the attacker's executables and batch files, and the other one is serving as another tool that is supposed to add the attacker’s user to the Administrators group.

It contains an indicative PDB path:

F:\upfile\3389\opents\dlladduser\x64\Release\dllnc.pdb, which did not yield any other results in VirusTotal as of the middle of May 2023. This is a good indication that this is a custom tool for this specific attacker.

The loader code segment attempts to load some of the tools it expects to already be in the attacker’s path (as shown in Figure 4), since there are no checks whether they are actually present or not. While doing so, it considers several possible hard-coded paths, most of them seen in this campaign.

Image 4 is many lines of code — the hard-coded paths of the attacker’s tools.
Figure 4. Hard-coded paths of the attacker’s tools as seen in dllnc.dll.

The tool then deletes the current iis_user user and then re-adds it, this time with a hard-coded password. Again, this behavior correlates with the ACSC report on the original Manic Menagerie campaign. An old variant of the Relative ID (RID) hijacking tool (shown in Figure 5), which was also mentioned in that report, resembles this behavior.

Image 5 is a screenshot of the Administrator command line. It is the RID hijacking tool output. There is some redacted information in this screenshot.
Figure 5. RID hijacking tool output. Source: Figure 6 of the Australian Cyber Security Centre (ACSC) Report 2018-143.

There is a clear, strong resemblance between the password in both variants, as both use the xman prefix and a similar suffix (shown in Figure 6).

Image 6 is a screenshot of the iis_user and the password. Some of the informal is redacted.
Figure 6. The user iis_user and its hard-coded password.

PCHunter

PCHunter, another tool we observed being used by the Manic Menagerie 2.0 campaign, is reminiscent of older tools like GMER and Rootkit Unhooker. It is a legitimate and powerful toolkit for browsing and modifying different Windows Internals components. Figure 7 shows the attempted execution of PCHunter being blocked.

Image 7 is a screenshot of Cortex XDR where PCHunter64.exe has been blocked. Included is the path and the SHA and signature.
Figure 7. PCHunter blocked execution.

Figure 8 shows the digital signature of PCHunter, by “Epoolsoft Corporation.” The comments in Chinese provide a quick description of the tool. This is translated as “Yipmin is a Windows system information viewing tool (security category).”

Image 8 is a screenshot of the PCHunter signer information. It includes the copyright, product, description, original name, internal name, file version, comments (which are written in Chinese characters) and the date signed.
Figure 8. PCHunter signer information.

Second Wave: Backdooring at Scale

Deploying a Known Web Shell to Multiple Destinations

The second distinct wave of attacks observed in the Manic Menagerie 2.0 campaign is characterized mainly by massive deployment of web shells to the hosted websites. This allows the attacker to strengthen their foothold by enabling them future public access, and to hide their web shells deep in nested folders. These legitimate hijacked websites could potentially be used as C2 servers in the future (e.g., as part of a botnet infrastructure).

The attacker’s deployment attempts go back to early 2022, when they deployed the same known web shell called ASPXSpy to multiple hosted websites. We observed this web shell being written to hundreds of different paths, as shown in Figure 9.

Image 9 is a screenshot of Cortex XDR. The columns are action type, file, path, and the SHA. The action type is File Write and most of the file path has been redacted.
Figure 9. ASPXSpy web shell being written to different hosted websites paths.

GoIIS

The attackers also ran a tool called IIS1.asp or GoIIS.exe (shown in Figure 10), compiled in 2017. The tool is written in Golang and is used to traverse the server’s folders to retrieve the server’s configuration information. This allows the attacker to gain valuable information about the compromised server.

Image 10 is a screenshot of the ISS tool output. This is highlighted in the two red boxes.
Figure 10. IIS tool output.

Sh.exe: A Custom Web Shell Deployment Tool

Later in 2022, the attacker deployed a custom tool named sh.exe as part of the Manic Menagerie 2.0 campaign, whose execution can be seen in Figure 11 below. The role of this tool is to write web shells at scale to hosted websites, based on a preconfigured list of paths and legitimate hijacked websites on the server sharing the same public IP address.

In order to facilitate the use of this tool, the attackers used a custom wrapper for caclcs.exe (that they named mycacls.com), which is a command-line tool used to manage access control lists (ACLs). This tool enabled them to change the web server’s ACL permissions in bulk as well as lowering the IIS security settings.

Image 11 is a screenshot of Cortex XDR. It is a tree diagram showing where exactly the sh.exe was blocked. Included in the screenshot are multiple file paths.
Figure 11. Attempted sh.exe execution along with other tools and commands, as blocked by Cortex XDR.

The parameters passed on to sh.exe contain a list of relevant websites that share the same public IP. Upon execution, the sh.exe tool generates various legitimate-looking subfolders, such as images and css to further conceal their activity. It’s possible that this was intended to give attackers future access to victims’ machines from the internet and to potentially use this infrastructure in the future as C2 servers at scale.

sh.exe is signed with an invalid certificate issued by "Fujian identical investment co.,Ltd." as shown in Figure 12. This is the same name used to sign another tool, which the ACSC report described in a previous campaign.

In the sample we observed, sh.exe was compiled on Nov. 3, 2022. Its certificate was signed on Dec. 6, 2022. Shortly after signing it, threat actors were seen executing sh.exe in one of the compromised environments. The compilation timestamp and the date range of the invalid certificate could indicate the tool was made specifically for this particular campaign.

Image 12 is a pop-up window of the digital signature details. It is open to the general tab. The information included is the name, email, signing time, and an option to view the certificate. Countersignatures are also available.
Figure 12. sh.exe invalid signature.

While the threat actor deleted most of the files, we found a connection between sh.exe and the files it dropped that could not be recovered. Our investigation uncovered three distinct compiled .NET DLLs that the attackers used.

These DLLs are compiled by the IIS server once a “raw” ASPX file is accessed for the first time. Upon decompiling the code, interesting similarities were found between the web shell and sh.exe, based on indicative strings found in both files.

Browsing to one of the websites where one of the web shells was dropped, the content on the page is the string ONEPIECE, as shown in Figure 13 below.

Image 13 is a screenshot of the web shell resource with information redacted.
Figure 13. Browsing the web shell resource in one of the hijacked websites.

Browsing the code of one of the web shells and looking at the code responsible for showing the HTML content, this string can be seen together with other indicative strings, such as x_best_911 (shown in Figure 14).

Image 14 is a screenshot of a few lines of code. These are the strings, and included is ONEPIECE, which is hard coded in the web shell's DLL code.
Figure 14. The ONEPIECE string hard-coded in the compiled web shell’s DLL code.

The x_best_911 string can also be found in sh.exe, as shown in Figure 15.

Image 15 is a screenshot of a few lines of code. Hardcoded is a string for x_best_911.
Figure 15. The x_best_911 string hard-coded in sh.exe.

Going back to the report by the ACSC, the password generated upon execution of the aforementioned RID Hijack tool contains the xman string. This string can be also found in sh.exe, as shown in Figure 16, which indicates yet another similarity between the novel tool seen in this recent campaign and the previous Manic Menagerie campaign.

Image 16 is a screenshot of a few lines of code. Hard-code into sh.exe is the xman string.
Figure 16. The xman string is hard-coded in sh.exe.

More LPE Attempts

LPE Toolset: Hippos and Potatoes

As mentioned in the previous section, once the IIS server accesses a web shell, a .NET DLL is compiled on the fly and placed in a temporary directory. One such compiled DLL web shell file, which can be seen in Figure 17 below, is App_Web_xvuga1zl.dll.

The connection the attackers had made with the web shell resulted in yet another attempt to remotely execute multiple LPE publicly available tools, as seen in many stages of attacks associated with this campaign.

As the attacker had done previously, they also used several privilege escalation tools. In one case, there were only minutes separating each execution, to try to avoid being blocked:

  • JuicyPotato
  • PrintSpoofer
  • JuicyPotatoNG
  • EfsPotato
  • PetitPotam (“little hippo” in French)
Image 17 is a Cortex XDR screenshot. It is a tree diagram. It displays the multiple local privilege escalation tools that were detected and blocked by the program. Highlighted in a red rectangle is a DLL.
Figure 17. Multiple local privilege escalation tools detected and blocked by Cortex XDR.

MyComEop

As we analyzed several loaders recovered from organizations targeted by the Manic Menagerie 2.0 campaign, another finding caught our eye. These loaders included hard-coded strings for the files x and x.tmp. When executing these loaders in a debugger, they successfully decrypted their payloads, revealing yet another PoC LPE tool and backdoor, with distinctive PDB paths:

  • E:\git\MyComEopPower\MyComEopPipe\Build\Quantum.pdb
  • E:\git\MyComEopPower\MyComEopPipe\Build\MyComEop.pdb

While searching for the PDB paths in VirusTotal, we found more notable metadata from two other variants, as shown in Figure 18.

Image 18 is the file version information of a variant. Included is the copyright, product, description, original name, internal name, and the file version. It is a mix of English language as well as Chinese characters.
Figure 18. File metadata retrieved from another variant sharing the same PDB path.

The product name and description translate to “protocol rights escalation tool” and “internal special edition.” Pivoting on the two different metadata components returned more similar variants with very similar PDB paths. Some of these variants are tagged with the CVE-2017-0213 tag in VirusTotal.

After further research, we found this is yet another rarely seen privilege escalation tool and backdoor, as shown in Figures 19a and 19b.

Image 19 is a screenshot of a few lines of code. It is a hard-coded paths from a privilege escalation tool.
Figure 19a. Hardcoded paths from the described tool.
Image 20 is a screenshot of a few lines of code. Highlighted in red through the screenshot is the word backdoor. These are backdoor logs from the described tool.
Figure 19b. Backdoor logs from the described tool.

Back in the Game

In April 2023, while monitoring activity associated with Manic Menagerie 2.0, we began to see the threat actor deploying new modified tools and accessing compromised environments via a previously deployed web shell. This was found in addition to indicators of older tools being deployed in parallel, as well as updated tools, such as au.exe.

The attacker also searched for the presence of their iis_user by executing net commands. They then started deploying modified tools in the %programdata%\x path, which was also familiar behavior.

One of the tools they deployed is called GodPotato, shown in Figure 20, which is another variant of the known “potatoes” LPE family. This tool is also publicly available.

Image 21 is a screenshot from the GodPotato tool. The word GodPotato is text art made from capital F. The screenshot also includes arguments and eggs, an example of what to enter in the command line.
Figure 20. A screenshot from the GodPotato tool.

Another tool that we observed is yet another custom backdoor, shown in Figure 21. By looking at its PDB path, D:\project\后门类\dllnc\exenc\x64\Release\exenc.pdb, it appears to be a new variant to the aforementioned dllnc tool. This variant focuses on backdooring capabilities rather than serving mainly as a loader. “后门类” literally means “back door” when translated into English.

Image 22 is a screenshot of money lines of code. It shows the main method of the new back door. There is some redacted information in the screenshot.
Figure 21. The main method of the new backdoor.

Conclusion

Unit 42 researchers uncovered an active campaign, which we have called “Manic Menagerie 2.0,” that targeted web hosting and IT companies for over two years. We believe the campaign was conducted by a threat actor whose previous endeavor was dubbed “Manic Menagerie.” The current campaign demonstrates an evolved iteration of that operation.

Unit 42 tracks the activity associated with this campaign under CL-CRI-0021. The threat actor associated with Manic Menagerie 2.0 is still active, continuing to change their TTPs to try to remain under the radar.

The main goal of the threat actor behind this operation appeared to be to abuse the resources of the compromised web servers for monetary gain. The threat actor deployed multiple coin miners in Manic Menagerie 2.0, as previously reported by the ACSC that they did in the original campaign.

Our investigation also revealed that the attackers expanded their arsenal and evolved their TTPs over time to hijack legitimate websites. They did this by mass deploying web shells to compromised sites at scale, which they could then use as C2 servers.

Protections and Mitigations

Palo Alto Networks customers receive protections from the campaign mentioned in this article through the following products and services:

    • The Next-Generation Firewall with a Threat Prevention security subscription can block the attacks with Best Practices via Threat Prevention signatures 90796, 90815, 91505, 91651, 91368, 91589 and 91577
    • The WildFire cloud-delivered malware analysis service accurately identifies known samples as malicious.
    • Advanced URL Filtering and DNS Security identify domains associated with this group as malicious.
    • Cortex XDR detects user and credential-based threats by analyzing user activity from multiple data sources including endpoints, network firewalls, Active Directory, identity and access management solutions, and cloud workloads. It builds behavioral profiles of user activity over time with machine learning. By comparing new activity to past activity, peer activity and the expected behavior of the entity, Cortex XDR detects anomalous activity indicative of credential-based attacks.
      It also offers the following protections related to the attacks discussed in this post:

      • Prevents the execution of known malicious malware, and also prevents the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.
      • Protects against credential gathering tools and techniques using the new Credential Gathering Protection available from Cortex XDR 3.4.
      • Protects from threat actors dropping and executing commands from web shells using Anti-Webshell Protection, newly released in Cortex XDR version 3.4.
      • Protects against exploitation of different vulnerabilities including ProxyShell and ProxyLogon using the Anti-Exploitation modules as well as Behavioral Threat Protection.
      • Cortex XDR Pro detects post-exploit activity, including credential-based attacks, with behavioral analytics.

If you think you might have been impacted or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

North America Toll-Free: 866.486.4842 (866.4.UNIT42)

  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

Web Shells

  • B00cd3b39bc2fd6a4077c679f050d97ed26ef20a1fe80ad3525ea0dbbd131f74
  • 0153246cf5e1d980d65d4920bdc5b2ac4c9aba6d5b6676f0e9bbde794dd04314
  • 0f9dca8599d7b350050149e63a6a977f1d157d5967ba6da534919530063cdcde
  • 9215371ec6058ba38780a5d336eb3201a47c77bb97bb00a60f1bec0386185c77
  • adf2ee0ad2f5f13b9bf72741c75910f786d2cfee84b5ae78ea3e5464f46addde

Compiled Web Shell DLLs

  • fcd44c32ae6078f2ba44c8c5e2efa3f9b788d4c6470a5ee9bd4944699fb8357a
  • 2e24c384f9ae7d09179bd41e51c4a9bb43102d170990e8e1576e79362b049ed6
  • 3ab6a849d81b66a52d717cc1b0178882e30d44c39b1089604c5746a187b2e4ce
  • 905cf864acad6b4a664582eb9fc6e0afab87198274a29e5f7d7863fee29f37cd

StreamEx Malware

  • a812d5472458c6fc993ae1e9e8b9f04e31d176e2ec9f5ce5ac48e32ed72fb414
  • 8402967a4b0bff39fc3ccc7a5b613734135551e9f6f32cf8c14fd6541a85d4d5

Coin Miners

  • 4cdcec18ef5d3657b488f32912a8ccf4541891e4e4c8518afbc1e1b0e147e96b
  • db2712470ca60e874b15fa1e5ef667dbf6b755223ee5eb20843843115537e1c4
  • c67ce681677909aa5ae9abcf42c35faffee08cd73b5cee8d975fa07159f76c87
  • 308643ef08bd65afaba08315826985975515845fb5d6235db80a9bc5bdbb00f3

SpoolPotato

  • 238f5771b8350633e258221e25223e52545709b74cbe2c9361e2b730f9dbfa00

JuicyPotato

  • 5cb0710bef7c7b0ff226bf5ca12f499859505547696f22fa06ce1f47ea312d82

x.bat

  • f20b0a716c3980c46a2996ae21e3566c0151202557417d171566b82e97057f2f

x.tmp

  • b4de4eb9763ad18e060513048eed4ac39481cfe62127345d0bb058eb26a18528

x.tmp (decrypted)

  • 2092ce3cef30198cb7833851a1b1805bbfe71474152c1357ecd27f71ce807527

x

  • 6f77fea2e8e34fe3bb7134e110036e44e30a6d5144794669a6de21a30f3b7247

x (decrypted)

  • db7290032479a53fa7a43262188132d572fab63d00d6d64d39f9256df6c10f55

PCHunter

  • 5cb0710bef7c7b0ff226bf5ca12f499859505547696f22fa06ce1f47ea312d82

PrintSpoofer

  • 609d04a4be3878328503c342f0d73c9ba5ff1c6c62f4c894516e50721207ef83

PetitPotam

  • 419e8bfae7a0887fad0eb273791cf0d03c0ed01d1957c7dc796c6e0d1a43f3d6

JuicyPotatoNG

  • 181daac34fd958aaadf1c9de1414cc3b331ef394ba47d5d2c77d30e9ac89ef17

EfsPotato

  • ef8eae74cddea603c5051de7808f402943d674c6bb557db1eff6a50d25114b6b

au.exe

  • b08a089f0e44c2703a9e0dc4f6ef8d9285a08241499ad21dbf7f1fbc262d22bd
  • 1d61842f5ecdca970f43246ce93f51fa4c85c00b93b6b9e37db17325077497eb

RunasCs_net2

  • 009a28656abb84a6e7794fdd721565a2e2ca2565870597962d67a8e2c3707241

CVE-2018-8120

  • 88f62989cb2f220db3d289ffea924423487b180fabe37711d2ef5c7f2e306f13

CVE-2019-0803

  • 068bfbb2dc6dadc3860eb16cc7ece97d935948f9b64ec66d5afda08e682be790

CVE-2019-1458

  • 3e2041c2efd120960c00bf794b5db4c967fc862e2d536ed5f7b5d5d1cf9bfda0

CVE-2019-0623

  • 74b95e6b8e02ea623849b6bcbf702922dd064ae06238b27cbb20504e38d85756

Fork bomb

  • 6c569dd683df9600a098a93c9200d44778d535f58f5a82f4a58aeed3855fb9ca

dllnc

  • 67fdef1b6fdf6fbec44e4df1608fb46dfbcfa3363bf62872ec132d000092a18f
  • ae35de63065040d752ef9fa76c553c0fa5c3cc5c8d67cf6981c66d3c8d86a6a6

sh.exe

  • 9e761c6811679311c80291b7d65f23cdd53865f72af64b5a72ae1a86d9ef27d0

GodPotato

  • 4e04472b21365c76d9cf0a324f889f723621fc42433a2f211a23dce728fa4a8a
  • 5a4a2272ce4388e56fb9d33255ac8c584d41c7099588ef9f39e4bee54be92992

MyCACLS

  • 15c52422bfa461b01901953f5e0d9c77aa0f898c8de4841303a572c59a269674

PDB Paths

  • “F:\upfile\3389\opents\dlladduser\x64\Release\dllnc.pdb”
  • “E:\git\MyComEopPower\MyComEopPipe\Build\Quantum.pdb”
  • “E:\git\MyComEopPower\MyComEopPipe\Build\MyComEop.pdb”
  • “D:\project\后门类\dllnc\exenc\x64\Release\exenc.pdb”

Additional Resources

Detecting Popular Cobalt Strike Malleable C2 Profile Techniques

Posted on by Durgesh Sangvikar

Executive Summary

Unit 42 researchers identified two Cobalt Strike Team Server instances hosted on the internet and uncovered new profiles that are not available on public repositories. We will highlight the distinct techniques attackers use to exploit the Cobalt Strike platform and circumvent signature-based detections.

We identified Team Server instances connected to the internet that host Beacon implants and provide command-and-control (C2) functionality. We have also extracted the Malleable C2 profile configuration from the Beacon binary to help us understand the various methods used to evade conventional detections.

The operators of the Cobalt Strike Team Servers attempted to conceal their C2 infrastructure behind benign and well-known services to evade detection. We have also found Team Server C2 infrastructure hosted on well-known public cloud infrastructure providers. The operators also deployed new Malleable C2 profiles. Threat and red team actors create new profiles to deceive security controls, bypass security measures and avoid detection. These tactics involve modifying HTTP URLs, header parameters and host headers with harmless and widely recognized domains.

Palo Alto Networks customers receive protections and mitigations for Cobalt Strike Beacon and Team Server C2 communication in the following ways:

  • The Next-Generation Firewall (NGFW) with an Advanced Threat Prevention subscription can identify and block Cobalt Strike HTTP C2 requests generated by custom profiles and block Cobalt Strike HTTP C2 requests and responses that are masked with the Base64-encoding settings of the default profile (signatures 86445 and 86446).
  • WildFire and Cortex XDR can identify and block Cobalt Strike Beacon binaries, and XDR will report related exploitation attempts.
  • Cortex XSOAR response pack and playbook can automate the mitigation process.
  • Malicious URLs and IPs have been added to Advanced URL Filtering.
Related Unit 42 Topics Cobalt Strike, Cloud

Case Analysis

Cobalt Strike is a highly effective platform used by professionals to simulate threats in enterprise network environments. Its primary objective is to establish a secure and undetectable communication channel between Beacon implants and the Team Server. With the use of Malleable C2, Cobalt Strike operators can easily create highly flexible and evasive network profiles, generating different C2 traffic with ease.

Unit 42 researchers have discovered two distinct tactics used by threat or red team actors to evade detections from current security controls. By examining these cases, we can better understand the techniques these people use to carry out harmful actions without raising any security alerts.

The case studies below are derived from true positive detection analysis. In the following scenarios, we identified Cobalt Strike Team Server infrastructure, extracted Malleable C2 profile configuration information and reconstructed the configuration and implant data for use in detection improvements.

Case 1: Brand New Profile

Cobalt Strike has a well-documented custom profile language. Attackers and red teamers tend to craft well-designed and unique Malleable C2 profiles to conduct their operations, aiming to bypass security filters that look for known public Malleable C2 profiles.

We found a Team Server running on 23.95.44[.]80:80 that hosted a Beacon file with the SHA-256 hash 22631d171fd7d531c0bc083a5335a910a95257e3194b50d8b471740d3a91fe34. We used internal tools to derive and reconstruct the Malleable C2 profile from the configuration extracted from the Beacon binary.

Figure 1 shows an extracted and recreated custom profile. The left half of the image shows the GET transaction and the right side shows the POST transaction of the Beacon communication.

The encrypted and encoded data in the GET transaction is placed in a Cookie Parameter SESSIONID. The ID in the POST transaction is added to the custom header User. The ID is double encoded using Mask and NetBIOSU. The output from the task execution is also double encoded and appended to the data parameter in the POST body.

Beacon Information

  • Team Server IP/Port: 23.95.44[.]80:80
  • Autonomous System Number (ASN): AS-36352
  • Used profile: New Profile
  • Beacon payload SHA-256 hash: 22631d171fd7d531c0bc083a5335a910a95257e3194b50d8b471740d3a91fe34
Image 1 is a screenshot of a new Malleable C2 profile. The lines of code on the left are the GET transaction. The lines of code on the right are the POST transaction. Also included in the screenshot is the Beacon information.
Figure 1. A brand new Malleable C2 Profile.

Case 2: Hiding Behind Known Good Services

Security vendors use elements of HTTP traffic to determine if a given flow is suspicious or malicious. If the domain in the Host header of an HTTP request is on a ranked list of popular domains, some malicious criteria could be discarded as the request might be identified as benign. Similarly, if the destination server belongs to a well-known cloud provider, that IP address could be on the allow list and considered benign.

Attackers use these detection criteria to their advantage by generating HTTP request traffic to mimic known good services in order to evade identification. We routinely catch Malleable C2 profiles that mimic well-known benign websites such as e-commerce sites, search engines and email providers.

Case 2.1: Host with Benign/Famous Domain to Evade Security Detection

Attackers often use forged host headers to generate traffic that appears to be benign, thus evading network security inspection. However, this traffic can still be identified as malicious when inspected by an expert.

Figure 2 shows a Beacon sample using a modified Malleable C2 profile hosted on GitHub. The person intended to disguise the malicious traffic as benign traffic from a highly reputable website. However, the ASN record for the destination IP address shows a different owner, confirming the deception.

Beacon Information
  • Team Server IP/Port: 159.65.219[.]189:443
  • ASN: AS-14061
  • Used profile: Modified profile hosted on GitHub
  • Beacon payload SHA-256 hash: 3528313aeff15375a2bce7b7587b188dcf1befb1e50c9db65d46e81a77a4a096
Image 2 is a screenshot of a Malleable C2 profile with a forged HTTP host header. The lines of code on the left are the GET transaction. The lines of code on the right are the POST transaction. Also included in the screenshot is the Beacon information. What shows the modification is that the ASN record for the destination IP address is a different owner.
Figure 2. Malleable C2 Profile with forged HTTP Host header.

Case 2.2: Destination IP Used from Public Cloud to Evade Security Detection

This example shows how threat or red team actors can use public cloud platforms as a C2 server. Generally, these cases are hard to detect by IP reputation services such as VirusTotal or URL filtering products due to the benign nature of the service provider.

Penetration testers are well aware of the popularity of online services and use them to their advantage. They can hide payloads in seemingly harmless services, making it harder to detect malicious activity.

Unit 42 researchers identified a Team Server on the IP 35.224.140[.]15:443 that hosted the Cobalt Strike Beacon with the SHA-256 hash 3ac4be4291bddaaa39a815cc05ece6d611cd69a1604fec8dec0f7e5451659cfa. The Team Server IP belongs to a prominent cloud provider.

Figure 3 shows the Malleable C2 profiles recreated from the Beacon binary hosted on the Team Server instance. The Team Server was running on a well-known cloud provider.

Beacon Information
  • Team Server IP/Port: 35.224.140[.]15:443
  • ASN: AS-396982
  • Used profile: Default profile
  • Beacon payload SHA-256 hash: 3ac4be4291bddaaa39a815cc05ece6d611cd69a1604fec8dec0f7e5451659cfa
Image 3 is a screenshot of a Malleable C2 profile using a known public cloud service. The lines of code on the left are the GET transaction. The lines of code on the right are the POST transaction. Also included in the screenshot is the Beacon information.
Figure 3. Malleable C2 Profile using a known public cloud service.

Conclusion

Cobalt Strike is a highly versatile tool, and most security vendors struggle to detect its C2 traffic accurately. This makes Cobalt Strike an ideal choice for attackers looking to increase their malware's chances of success.

We are continuously discovering new Team Servers that host active Beacon binaries. This threat hunting has proven fruitful against the misuse of Cobalt Strike in cyberattacks. The continuous cycle of scanning and learning helps us remain vigilant and provide active defenses against cybercrime.

Palo Alto Networks customers receive protection from the attack above with the following products:

  1. The Next-Generation Firewall with an Advanced Threat Prevention subscription can identify and block the Cobalt Strike HTTP C2 request in nondefault profiles. ATP signatures 86445 and 86446 can identify HTTP C2 requests with the Base64 metadata encoding in default profiles.
  2. WildFire, an NGFW security subscription and Cortex XDR identify and block CobaltStrike Beacon.
  3. Cortex XSOAR response pack and playbook can automate the mitigation process.
  4. Cortex XDR will report related exploitation attempts.
  5. Malicious URLs and IPs have been added to Advanced URL Filtering.

Indicators of Compromise

CS Beacon Samples

  • 22631d171fd7d531c0bc083a5335a910a95257e3194b50d8b471740d3a91fe34
  • 3528313aeff15375a2bce7b7587b188dcf1befb1e50c9db65d46e81a77a4a096
  • 3ac4be4291bddaaa39a815cc05ece6d611cd69a1604fec8dec0f7e5451659cfa

CS Team Server IP Addresses

  • 23.95.44[.]80:80
  • 159.65.219[.]189:443
  • 35.224.140[.]15:443

Additional Resources

IoT Under Siege: The Anatomy of the Latest Mirai Campaign Leveraging Multiple IoT Exploits

Posted on by Zhibin Zhang

Executive Summary

Since March 2023, Unit 42 researchers have observed threat actors leveraging several IoT vulnerabilities to spread a variant of the Mirai botnet. The vulnerabilities exploited include those listed in the following table:

CVE/Product Description
CVE-2019-12725 Zeroshell Remote Command Execution Vulnerability
CVE-2019-17621 D-Link DIR-859 Remote Command Injection Vulnerability
CVE-2019-20500 D-Link DWL-2600AP Remote Command Execution Vulnerability
CVE-2021-25296 Nagios XI Remote Command Injection Vulnerability
CVE-2021-46422 Telesquare SDT-CW3B1 Router Command Injection Vulnerability
CVE-2022-27002 Arris TR3300 Remote Command Injection Vulnerability
CVE-2022-29303 SolarView Compact Command Injection Vulnerability
CVE-2022-30023 Tenda HG9 Router Command Injection Vulnerability
CVE-2022-30525 Zyxel Command Injection Vulnerability
CVE-2022-31499 Nortek Linear eMerge Command Injection Vulnerability
CVE-2022-37061 FLIR AX8 Unauthenticated OS Command Injection Vulnerability
CVE-2022-40005 Intelbras WiFiber 120 AC inMesh Command Injection Vulnerability
CVE-2022-45699 APsystems ECU-R Remote Command Execution Vulnerability
CVE-2023-1389 TP-Link Archer Router Command Injection Vulnerability
CVE-2023-25280 D-link DIR820LA1_FW105B03 Command injection vulnerability
CVE-2023-27240 Tenda AX3 Command Injection Vulnerability
CCTV/DVR CCTV/DVR Remote Code Execution
EnGenius EnShare EnGenius EnShare Remote Code Execution Vulnerability
MVPower DVR MVPower DVR Shell Unauthenticated Command Execution Vulnerability
Netgear DGN1000 Netgear DGN1000 Remote Code Execution Vulnerability
Vacron NVR Vacron NVR Remote Code Execution Vulnerability
MediaTek WiMAX MediaTek WiMAX Remote Code Execution

The threat actors have the ability to gain complete control over the compromised devices, integrating those devices into the botnet. These devices are then used to execute additional attacks, including distributed denial-of-service (DDoS) attacks.

Palo Alto Networks Next-Generation Firewall customers receive protection through Cloud-Delivered Security Services such as Internet of Things (IoT) Security, Advanced Threat Prevention, WildFire and Advanced URL Filtering, which can help detect and block the exploit traffic and malware.

Related Unit 42 Topics IoT, Mirai, botnet

Campaign Analysis

On March 14, 2023, Unit 42 researchers observed some remote command execution exploit traffic from our internal threat-hunting system, originating from 185.44.81[.]114. The threat actor tried to download a shell script downloader as a file named y from hxxp://zvub[.]us/.

If executed, the shell script downloader would download and execute the following bot clients to accommodate different Linux architectures:

  • hxxp://185.225.74[.]251/armv4l
  • hxxp://185.225.74[.]251/armv5l
  • hxxp://185.225.74[.]251/armv6l
  • hxxp://185.225.74[.]251/armv7l
  • hxxp://185.225.74[.]251/mips
  • hxxp://185.225.74[.]251/mipsel
  • hxxp://185.225.74[.]251/sh4
  • hxxp://185.225.74[.]251/x86_64
  • hxxp://185.225.74[.]251/i686
  • hxxp://185.225.74[.]251/i586
  • hxxp://185.225.74[.]251/arc
  • hxxp://185.225.74[.]251/m68k
  • hxxp://185.225.74[.]251/sparc

After executing the bot client, the shell script downloader will delete the client executable file to cover its tracks.

Unit 42 researchers conducted an analysis of the malware host domain and found out there are two IP addresses corresponding to the domain zvub[.]us:

  • 185.44.81[.]114 (From Aug. 15, 2022, to March 24, 2023)
  • 185.225.74[.]251 (After March 25, 2023)

Upon conducting a thorough retrospective analysis, we noticed telnet brute force attempts from 185.44.81[.]114 since Oct. 6, 2022, and attempts to exploit multiple vulnerabilities since March 14, 2023.

Unit 42 researchers also noticed another campaign from source IP 193.32.162[.]189 since April 11, 2023, that delivers the same shell downloader from zvub[.]us, as shown in Figure 1. Based on our analysis, we believe that the same threat actor operated these two campaigns for the following reasons:

  • The two campaigns share the same infrastructure.
  • The botnet samples are almost identical.
Image 1 is a chart of the vulnerability, exploit attempts from October 2022 to May 2023. The highest count is in April the highest counts are in April, 2023, with 821, and then in May 2023 with 924.
Figure 1. Vulnerability exploit attempts.

Figure 2 is a diagram illustrating the campaign overview.

Image 2 is a timeline of the campaign overview. It starts with the attack source, IP, and lists all of the exploits, including new exploits. It starts mid August, 2022, and flows through May 1, 2023.
Figure 2. Campaign overview diagram.

Malware Analysis

Based on behavior and patterns Unit 42 researchers observed while analyzing the downloaded botnet client samples, we believe the sample is a variant of the Mirai botnet.

Upon execution, the botnet client prints listening tun0 to the console. The malware also contains a function that ensures only one instance of this malware runs on the same device. If a botnet process already exists, the botnet client will terminate the current running process and start a new one.

For the botnet client configuration string, the Mirai variant (like IZ1H9 and V3G4) will first initialize an encrypted string table and then retrieve the strings through an index. However, this Mirai variant will directly access the encrypted strings in the .rodata section via an index (as shown in Figure 3).

Image 3 is a screenshot of the Mirai fairy and retrieving configurations strings. This is highlighted within a red box.
Figure 3. Mirai variant retrieving configuration strings.

Also, notice that for Mirai variants like IZ1H9 and V3G4, the configuration contains a string that indicates the branch name of this variant (for example, /bin/busybox IZ1H9) while this variant does not have a branch name.

For the configuration decryption, this Mirai variant first uses a table key 0xDEADBEEF to generate a single-byte config decryption key 0x22, then for the encrypted configuration, the malware performs XOR decryption with the following bytewise operations:

encrypted_char ^ 0x22 = decrypted_char

During the analysis, Unit 42 researchers noticed that this Mirai sample doesn’t contain the functionality to brute force telnet/SSH login credentials and exploit vulnerabilities, which means the only channels for spreading this variant are the botnet operator’s manual vulnerability exploitation attempts.

Conclusion

The widespread adoption of IoT devices has become a ubiquitous trend. However, the persistent security concerns surrounding these devices cannot be ignored. The Mirai botnet, discovered back in 2016, is still active today. A significant part of the reason for its popularity among threat actors lies in the security flaws of IoT devices.

These remote code execution vulnerabilities targeting IoT devices exhibit a combination of low complexity and high impact, making them an irresistible target for threat actors. As a result, protecting IoT devices against such threats becomes an urgent task.

To combat this threat, it is highly recommended that patches and updates are applied when possible.

Palo Alto Networks customers receive protection against vulnerabilities and malware through the following products and services:

  • Next-Generation Firewall with a Threat Prevention security subscription can block the attacks with Best Practices via Threat Prevention signatures 30760, 37073, 37752, 54659, 54553, 54537, 54619, 58706, 57437, 55795, 57191, 90873, 92611, 93863, 92626, 92714, 93859, 92579, 93044, 93283, 93587, 93872, 93749, 93874, 93973.
  • Advanced Threat Prevention has an inbuilt machine learning-based security detection that can detect exploit traffic in real time.
  • WildFire can stop the malware with static signature detections.
  • Advanced URL Filtering and DNS Security are able to block the C2 domain malware-hosting URLs.
  • The Palo Alto Networks IoT security platform can leverage network traffic information to identify the vendor, model and firmware version of a device and identify specific devices that are vulnerable to the aforementioned CVEs.
  • In addition, IoT Security has an inbuilt machine learning-based anomaly detection that can alert the customer if a device exhibits nontypical behavior, such as the following:
    • The sudden appearance of traffic from a new source
    • An unusually high number of connections
    • An inexplicable surge of certain attributes typically appearing in IoT application payloads

Palo Alto Networks has shared our findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

Shell Script Downloader Samples

  • 888f4a852642ce70197f77e213456ea2b3cfca4a592b94647827ca45adf2a5b8

Mirai Samples

  • b43a8a56c10ba17ddd6fa9a8ce10ab264c6495b82a38620e9d54d66ec8677b0c
  • b45142a2d59d16991a38ea0a112078a6ce42c9e2ee28a74fb2ce7e1edf15dce3
  • 366ddbaa36791cdb99cf7104b0914a258f0c373a94f6cf869f946c7799d5e2c6
  • 413e977ae7d359e2ea7fe32db73fa007ee97ee1e9e3c3f0b4163b100b3ec87c2
  • 2d0c8ab6c71743af8667c7318a6d8e16c144ace8df59a681a0a7d48affc05599
  • 4cb8c90d1e1b2d725c2c1366700f11584f5697c9ef50d79e00f7dd2008e989a0
  • 461f59a84ccb4805c4bbd37093df6e8791cdf1151b2746c46678dfe9f89ac79d
  • aed078d3e65b5ff4dd4067ae30da5f3a96c87ec23ec5be44fc85b543c179b777
  • 0d404a27c2f511ea7f4adb8aa150f787b2b1ff36c1b67923d6d1c90179033915
  • eca42235a41dbd60615d91d564c91933b9903af2ef3f8356ec4cfff2880a2f19
  • 3f427eda4d4e18fb192d585fca1490389a1b5f796f88e7ebf3eceec51018ef4d
  • aaf446e4e7bfc05a33c8d9e5acf56b1c7e95f2d919b98151ff2db327c333f089
  • 4f53eb7fbfa5b68cad3a0850b570cbbcb2d4864e62b5bf0492b54bde2bdbe44b

Infrastructure

  • zvub[.]us
  • 185.225.74[.]251
  • 185.44.81[.]114
  • 193.32.162[.]189

Additional Resources

Appendix

Campaign-related vulnerability information is listed below:

CVE-2019-12725: Zeroshell Remote Command Execution Vulnerability

This malicious traffic was first detected as a part of the campaign on March 14, 2023. The command execution vulnerability is due to the failure to sanitize the value of x509type in the kerbynet component of Zeroshell

Image 4 is a screenshot of the Zeroshell remote command execution vulnerability. The name of the host is redacted.
Figure 4. CVE-2019-12725 exploit in the wild.

CVE-2019-17621: D-Link DIR-859 Remote Command Injection Vulnerability

We captured this exploit traffic on May 1, 2023. The exploit targets a command injection vulnerability in the D-Link wireless router’s /gena.cgi component, which does not successfully sanitize the user input in the service parameter. This leads to arbitrary command execution.

Image 5 is a screenshot of the D-Link DIR-859 remote command injection vulnerability. The host has been redacted.
Figure 5. CVE-2019-17621 exploit in the wild.

CVE-2019-20500: D-Link DWL-2600AP Remote Command Execution Vulnerability

The exploit was detected on April 11, 2023. The exploit works due to the D-Link wireless router admin.cgi component failing to adequately sanitize the user-supplied input data, which leads to remote command execution.

Image 6 is a screenshot of the D-Link DWL-2600AP remote command execution vulnerability. The host has been redacted. This exploit allows for remote command execution.
Figure 6. CVE-2019-20500 exploit in the wild.

CVE-2021-25296: Nagios XI Remote Command Injection Vulnerability

We observed this exploit traffic on April 11, 2023. The exploit targets the Nagios XI device’s /nagiosxi/config/monitoringwizard.php component. If insufficient input validation is found, the attacker can exploit the vulnerability to launch a remote command injection attack.

Image 7 is a screenshot of the Nagios XI remote command injection vulnerability. The host has been redacted. The screenshot is of the exploit traffic.
Figure 7. CVE-2021-25296 exploit in the wild.

CVE-2021-46422: Telesquare SDT-CW3B1 Router Command Injection Vulnerability

The malicious traffic was first detected on March 14, 2023. The command injection vulnerability is due to the failure to sanitize the value of the cmd parameter in the cgi-bin/admin.cgi interface of the Telesquare router.

Image 8 is a screenshot of the Telesquare SDT-CW3B1 router command injection vulnerability. It is a screenshot of the malicious traffic with the host redacted. The important portion is the command parameter in the CGI bin.
Figure 8. CVE-2021-46422 exploit in the wild.

CVE-2022-27002: Arris TR3300 Remote Command Injection Vulnerability

We captured this exploit traffic on April 14, 2023. The exploit targets a command injection vulnerability in the Arris TR3300’s user.cgi component, which does not successfully sanitize the user input in the DDNS_HOST parameter. This leads to a command injection.

Image 9 is a screenshot of the exploit traffic of Arris TR3300 remote command injection vulnerability. The host has been redacted. The affected portion is part is the user.cgi component.
Figure 9. CVE-2022-27002 exploit in the wild.

CVE-2022-29303: SolarView Compact Command Injection Vulnerability

This exploit was detected on March 15, 2023. The exploit works due to the SolarView Compact confi_mail.php component failing to adequately sanitize the user-supplied input data, which leads to command injection.

Image 10 is a screenshot of the SolarView compact command injection vulnerability. The host, origin, and referrer have all been redacted.
Figure 10. CVE-2022-29303 exploit in the wild.

CVE-2022-30023: Tenda HG9 Router Command Injection Vulnerability

We observed this exploit traffic on March 14, 2023. The exploit targets the Tenda HG9 router’s /boaform/formPing component. If insufficient input validation is found, the attacker can exploit the vulnerability to launch a remote code execution attack

Image 11 is a screenshot of the Tenda HG9 router command injection vulnerability. The host has been redacted. The screenshot is of the exploit traffic.
Figure 11. CVE-2022-30023 exploit in the wild.

CVE-2022-30525: Zyxel Command Injection Vulnerability

This malicious traffic was first detected on March 14, 2023. The command injection vulnerability is due to the failure to sanitize the value of the mtu parameter in the /cgi-bin/handler interface of Zyxel.

Image 12 is a screenshot of the Zyxel command injection vulnerability. The host is redacted. The affected portion is the mtg parameter in the CGI bin.
Figure 12. CVE-2022-30525 exploit in the wild.

CVE-2022-31499: Nortek Linear eMerge Command Injection Vulnerability

We captured this exploit traffic on May 1, 2023. The exploit targets a command injection vulnerability in the Nortek Linear eMerge device’s card_scan.php component, which does not successfully sanitize the user input in the ReaderNo parameter. This leads to remote command injection.

Image 13 is a screenshot of the Nortek Linear eMerge command injection vulnerability. The host is redacted. The exploit affects the PHP code.
Figure 13. CVE-2022-31499 exploit in the wild.

CVE-2022-37061: FLIR AX8 Unauthenticated OS Command Injection Vulnerability

This exploit was detected on May 1, 2023. The exploit works due to the FLIR AX8 device’s res.php component failing to adequately sanitize the user-supplied input data, which leads to OS command injection.

Image 14 is a screenshot of the FLIR AX8 Unauthenticated OS command injection vulnerability. The host has been redacted.
Figure 14. CVE-2022-37061 exploit in the wild.

CVE-2022-40005: Intelbras WiFiber 120AC inMesh Command Injection Vulnerability

We observed this exploit traffic on March 15, 2023. The exploit targets the Intelbras WiFiber device’s /boaform/formPing6 component. If insufficient input validation is found, the attacker can exploit the vulnerability to launch a command injection attack.

Image 15 is a screenshot of the Intelbras WiFiber 120AC inMesh command injection vulnerability. It is a screenshot of the exploit traffic with the host redacted.
Figure 15. CVE-2022-40005 exploit in the wild.

CVE-2022-45699: APsystems ECU-R Remote Command Execution Vulnerability

This malicious traffic was first detected on April 12, 2023. The remote command execution vulnerability is due to a failure to sanitize the value of the timezone parameter in the /management/set_timezone.

Image 16 is a screenshot of the APsystems ECU-R remote command execution vulnerability. It is a screenshot of the malicious traffic with the host redacted.
Figure 16. CVE-2022-45699 exploit in the wild.

CVE-2023-1389: TP-Link Archer Router Command Injection Vulnerability

We captured this exploit traffic on April 12, 2023. The exploit targets a command injection vulnerability in the TP-Link Archer router’s cgi-bin/luci component, which does not successfully sanitize the user input in the country parameter. This leads to arbitrary command execution.

Image 17 is a screenshot, with the host redacted, of the exploit traffic of the TP-Link Archer command injection vulnerability.
Figure 17. CVE-2023-1389 exploit in the wild.

CVE-2023-25280: D-Link DIR820LA1_FW105B03 Command injection vulnerability

The exploit was detected on April 11, 2023. The exploit works due to the D-Link device /ping.ccp component failing to adequately sanitize the user-supplied input data, which leads to a command injection vulnerability.

Image 18 as a screenshot of the D-Link DIR820LA1_FW105B03 command injection vulnerability. Redacted in the screenshot is the host, the origin, and the referrer.
Figure 18. CVE-2023-25280 exploit in the wild.

CVE-2023-27240: Tenda AX3 Command Injection Vulnerability

We observed this exploit traffic on April 12, 2023. The exploit targets the Tenda AX3 router’s /goform/AdvSetLanip component. If insufficient input validation is found, the attacker can exploit the vulnerability to launch a remote command injection attack.

Image 19 is a screenshot of the Tenda AX3 command injection vulnerability. In the exploit traffic, the host has been redacted.
Figure 19. CVE-2023-27240 exploit in the wild.

CCTV/DVR Remote Code Execution

This exploit traffic was detected on March 14, 2023. The exploit targets a remote code execution in multiple CCTV/DVR devices’ /language components. The component does not successfully sanitize the value of the HTTP parameter.

Image 20 is a screenshot of the CCTV/DVR remote code execution. The exploit traffic has the host redacted. The exploit targets /language.
Figure 20. CCTV/DVR exploit in the wild.

EnGenius EnShare Remote Code Execution Vulnerability

We detected this exploit traffic on April 12, 2023. The exploit works due to the /cgi-bin/usbinteract.cgi component of the EnGenius EnShare device failing to sanitize the value of the HTTP parameter path.

Image 21 is a screenshot of EnGenius EnShare exploit traffic.
Figure 21. EnGenius Enshare exploit in the wild.

MVPower DVR Shell Unauthenticated Command Execution Vulnerability

This malicious traffic was captured on April 11, 2023. The exploit works due to the MVPower DVR failing to sanitize user input, which in turn could lead to remote command execution.

Image 22 is a screenshot of the MVPower DVR Shell unauthenticated command execution vulnerability. The host has been redacted.
Figure 22. MVPower DVR exploit in the wild.

Netgear DGN1000 Remote Code Execution Vulnerability

We captured this exploit traffic on March 14, 2023. The exploit targets the setup.cgi component of Netgear DGN1000. The component does not sanitize the value of the HTTP parameter cmd, which leads to remote code execution.

Image 23 is a screenshot of a Netgear DGN1000 exploit command code execution vulnerability. The host has been redacted in the screenshot.
Figure 23. Netgear exploit in the wild.

Vacron NVR Remote Code Execution Vulnerability

We observed this exploit traffic on March 14, 2023. The exploit targets the Vacron NVR device’s board.cgi component. If insufficient input validation is found, the attacker can exploit the vulnerability to launch a remote code execution attack.

Image 24 is a screenshot of the Vacron NVR remote code execution, vulnerability. The host has been redacted in the screenshot.
Figure 24. Vacron NVR exploit in the wild.

MediaTek WiMAX Remote Code Execution

The exploit traffic was first detected as a part of a campaign on April 12, 2023. The remote code execution vulnerability is due to the failure to sanitize the value of the SYSLOGD_REMOTE_HOST parameter in the user.cgi interface of a MediaTek WiMAX device.

Image 25 as a screenshot of the MediaTek WiMAX remote code execution.
Figure 25. MediaTek WiMAX exploit in the wild.

Inside Win32k Exploitation: Analysis of CVE-2022-21882 and CVE-2021-1732

Posted on by Samantha Stallings

Executive Summary

After seeing reports of two similar privilege escalation vulnerabilities in Microsoft Windows – CVE-2021-1732 and CVE-2022-21882 – we decided to analyze both to better understand the code involved in each. This is a continuation of Inside Win32k Exploitation, in which we discussed the Win32k internals and exploitation in general as background information to explore the issues surrounding CVE-2021-1732 and CVE-2022-21882.

Here, we will dig deeper into CVE-2021-1732 and CVE-2022-21882 and their related proof-of-concept (PoC) exploits. We’ll walk through an analysis of these two exploits, and thus see why the patch for CVE-2021-1732 was not sufficient to prevent CVE-2022-21882.

Both vulnerabilities discussed in this series are detected and blocked by the Cortex XDR Anti-LPE protection module. Both vulnerabilities are data-only exploits that copy the NT/Authority System privilege token to that of the current (exploit) process for privilege escalation. The XDR Anti-LPE modules monitor for this specific type of privilege escalation technique.

Related Unit 42 Topics Microsoft Windows, CVE-2021-1732, CVE-2022-21882

Analysis of CVE-2021-1732 and CVE-2022-21882

In this section we’ll discuss two Win32k PoC exploits, CVE-2021-1732 and CVE-2022-21882. Both of these vulnerabilities abused xxxClientAllocWindowClassExtraBytes and NtUserConsoleControl to overwrite the tagWND.cbWndExtra data field of an adjacent window to a large value, allowing for an arbitrary write primitive. They each use this arbitrary write to create a fake spmenu in the adjacent window, and then use GetMenuBarInfo to create an arbitrary read primitive. The arbitrary read/write primitives are then used to copy the NT/AUTHORITY SYSTEM token to the current (exploited) process.

We analyze the CVE-2022-21882 PoC in detail, and we’ll discuss CVE-2021-1732 during relevant sections of this analysis to explain how it differs from CVE-2022-21882. Then we’ll discuss why the patch Microsoft issued for CVE-2021-1732 wasn’t sufficient to prevent CVE-2022-21882.

The reason we decided to spend more time discussing CVE-2022-21882 is because there are several blogs with a detailed analysis of CVE-2021-1732 by Google and DBAPPSecurity Threat Intelligence Center.

Both of these exploits are examples of data-only attacks, which means they only require a read/write primitive and do not execute any attacker controlled code. These types of exploits are becoming more common due to the increased difficulty of bypassing modern-day exploit mitigations being deployed within the latest operating systems.

Overview of CVE-2022-21882

This vulnerability was discovered by RyeLv (@b2ahex) for the Tianfu cup hacking competition in October 2021. Microsoft released a patch in January 2022. Based on how similar this was to CVE-2021-1732, it’s highly likely to have affected Windows 10 versions 1709 through 21H2 with a few modifications.

Microsoft did release a patch for Windows 11 for this vulnerability as well. The PoC we are analyzing here was tested on Windows 10 version 21H2.

Triggering the vulnerability

Historically, exploit authors have relied heavily on abusing tagWND or bitmap objects to implement read/write primitives. As we mentioned earlier, Microsoft has gone through great pains to make abusing these objects much more difficult. Specifically, as of Windows 10 version 1703, using SetWindowLong only changes the ExtraBytes field in the user-mode copy of the desktop heap and not the kernel desktop heap, except when operating on a console window.

To get past this limitation, both vulnerabilities rely on changing a window to a console window during a user-mode callback by calling NtUserConsoleControl at a time when the Windows operating system is not expecting it. As a result of converting the window to a console window, this function adds 0x800 to the tagWND.dwExtraFlag mask to indicate that the tagWND.pExtraBytes field is now an offset into the kernel rather than a user-mode pointer.

Because Windows did not have any checks in place to verify window types, when SetWindowLong is called on this window, it will now make changes to the kernel desktop heap just like it did before Windows 10 version 1703. Let’s take a look at how this is implemented by walking through a PoC for CVE-2022-21882.

Proof of Concept Walkthrough

We’ll be looking at the PoC. Here is a brief summary:

  1. Find HMValidateHandle
  2. Load NtUserConsoleControl, NtCallbackReturn
  3. Find KernelCallbackTable
    1. Store pointers to xxxClientAllocWindowClassExtraBytes and xxxClientFreeWindowClassExtraBytes
  4. Define a couple of window classes
  5. Groom the heap
    1. Create some windows
    2. Leak user-mode tagWND locations with HMValidateHandle
    3. Leak user-mode tagWND locations with HMValidateHandle
  6. Calculate offsets between windows
  7. Call NtUserConsoleControl on lowest window address
  8. Create a third (magic) window
  9. Hook xxxClientAllocWindowClassExtraBytes with a malicious version that calls NtUserConsoleControl and NtCallbackReturn, then returns to the real xxxClientAllocWindowClassExtraBytes
  10. Use NtUserMessageCall to trigger the hooked function on WndMagic
  11. Use SetWindowlongA to create an arbitrary write primitive
  12. Use SetWindowLongPtrA to leak Wnd1’s spmenu kernel address and replace it with a fake spmenu object
  13. Use arbitrary read/write to clone system token
  14. Create a new process with System privileges and fix up any changed kernel values

In the next section, we will begin to walk through this summary, starting with steps 1-5.

Continue Reading ➠ Section 2 – Detailed Analysis, Steps 1-5

Back to Top

Pages: 1 2 3 4 5 6 7

Android Malware Impersonates ChatGPT-Themed Applications

Posted on by Yang Ji

Executive Summary

Unit 42 researchers have observed a surge of malware written for the Android platform that is attempting to impersonate the popular ChatGPT application. These malware variants emerged along with the release by OpenAI of GPT-3.5, followed by GPT-4, infecting victims interested in using the ChatGPT tool.

Here, we provide an in-depth analysis of two types of currently active malware clusters. The first cluster is a Meterpreter Trojan disguised as a "SuperGPT" app. The second is a "ChatGPT" app that sends short-text messages to premium-rate numbers in Thailand, resulting in charges for the victim that are pocketed by the threat actor.

Android users can download applications written for the Android platform from a variety of places. The Google Play store is the official source, but users are also free to obtain applications from other sources such as websites or links in emails. This means there is potential for users to obtain applications that have not been vetted by Google.

The files described here have been sent to Google and will be blocked from the Google Play store. Google Play Protect also protects users from apps known to contain this malware on Android devices with Google Play Services, even when those apps come from other sources. This underscores the need for users to be aware of the risks when obtaining applications for mobile devices outside of official channels. It is still possible that users could encounter malicious applications for download elsewhere on the internet.

Palo Alto Networks customers with Cortex XDR, the Next-Generation Firewall and Advanced URL Filtering benefit from protections against the ChatGPT-themed attacks discussed in this article. Additionally, the malicious indicators (domains, URLs and hashes) can be prevented with our DNS Security and WildFire services.

Related Unit 42 Topics ChatGPT, Meterpreter, Scams

Introduction

OpenAI created a tool known as Chat "Generative Pre-trained Transformer," or ChatGPT for short. This tool is powered by a large language model (LLM) and is currently in its fourth version.

ChatGPT first became publicly available on Nov. 30, 2022. It quickly went viral, since it demonstrated remarkable question-answering ability, though not necessarily in an accurate manner.

Threat actors are always seeking to distribute their wares via effective attack vectors, and impersonating prevalent applications according to the current global trend is among the most effective means to accomplish this objective. For instance, attackers commonly leveraged the COVID-19 pandemic to spread their own malicious versions of “Health and Wellness” category applications written for the Android platform.

Past reports on malware masquerading as a ChatGPT-related tool, as well as our earlier publication "ChatGPT-Themed Scam Attacks on the Rise," found that scammers were taking advantage of ChatGPT's popularity to launch attacks. Threat actors are using similarly worded domain names to trick victims into giving away personal information or downloading malware.

Here, we continue to report on this trend, sharing our findings on some malicious Android applications we've recently discovered in our telemetry. Specifically, we found two types of active malware. One is a Meterpreter Trojan disguised as a "SuperGPT" app, and the other is a "ChatGPT" app that sends messages to premium-rate numbers in Thailand.

Meterpreter Trojan

Our team uncovered a malicious Android Package Kit (APK) sample, which turned out to be a Trojanized version of a legitimate application. The legitimate application is an AI assistant based on the latest version of ChatGPT. The malicious version of this application enables the actor to establish remote access to an Android device if exploitation is successful.

Table 1 describes the legitimate application and Table 2 shows the malicious application.

Application name SuperGPT - AI with GPT-4
Description (summarized from the official listing) A GPT-4 powered AI assistant, able to perform tasks such as:

  • writing emails,
  • answering questions,
  • and writing articles

Also comes equipped with the following capabilities:

  • speech recognition
  • language translation
Package name com.dominapp.supergpt
Version name (code) 1.2 (8)
SHA-256 hash d7ef8929b236a43917f351c39963916c1dd3a9c0580499443322750435245f9f
File size 10.85 MB (11,378,336 bytes)

Table 1. Metadata of the legitimate application.

The MainActivity class of the malware sample contains a String variable reference to the official ChatGPT URL https://chat.openai.com/chat. Package-Class named v3.v is a custom WebViewClient class implementation (WebView is Android's built-in implementation to embed web browser functionality in apps made for its operating system). As such, this Java class is able to extend or override the default functionality. It does so by adding the following redirect rules:

  1. Redirect to https://chat.openai.com/chat, if URL contains https://openai.com/blog/chatgpt/
  2. Redirect to https://chat.openai.com/chat after a 1,000 millisecond delay, if URL contains beta.openai.com/
Application icon Screenshot

Image 1 is the application icon for SuperGPT. It is the head of a blue robot using headphones attached to a voice mic.
ic_launcher.png (app icon)

Image 2 is a screenshot of the SuperGPT app. The SuperGPT logo appears on top with the header “Talk with AI” followed by the text, “You can ask any question in your language and receive a response with a human-like voice powered by GPT-3.” At the bottom there is a button that says get started.
App screenshot
Application name SuperGPT
SHA-256 hash af19ca9213a20263c30584a2bf260dcdb3b4eafa4f43af10824af781573a2314
File size 12.39 MB (12,994,395 bytes)
Programming language Kotlin
Version name (code) 1.2 (8)
Package name com.dominapp.supergpt
Main activity com.dominapp.supergpt.activities.MainActivity
Android version Minimum: API level 23 (Android 6)
Target: API level 32 (Android 12L)

Table 2. Metadata of the malicious APK sample.

According to VirusTotal (VT), this sample was first submitted through VT's web interface from Nicaragua (NI), on 2023-03-16 02:06:04 UTC, as filename 2021id.apk.

Payload Implantation

Comparing the differences between the legitimate and malicious APK samples, it is clear that the critical Trojanizing addition to the file is the following line of Smali language code (shown in Figure 1).

Image 3 is a screenshot of Smali code. The added, malicious line of code is bolded.
Figure 1. Added line of malicious Smali language code.

The core threat in this malware sample is known as "Meterpreter." It is created using the Metasploit framework.

The source code of the initial Java-based Android Meterpreter stager can be found on Rapid7's GitHub repository. The main functionality is implemented within the Payload class. The Payload class' start method is invoked by the MainService class. The MainService class, in turn, can be either:

  • Started by the MainActivity class
  • Started by the MainBroadcastReceiver class automatically upon completion of the device boot sequence

The Payload class' main method is responsible for performing the following sequence of actions:

  1. Parse the hard-coded exploit configuration stored in the configBytes byte array (shown in Figure 2).
    • Note: This is not obfuscated in any way (e.g., the TCP or HTTP remote host address and port are clearly visible)
  2. Ensure the Android device's central processing unit (CPU) remains on via the Power Manager system service's partial wake lock functionality.
  3. Hide the icon’s application if requested.
  4. Establish a socket connection to the author-managed remote host.
  5. Download a secondary payload upon successful connection, implementing the full range of capabilities (e.g., the dump_sms command).

In the case of the APK malware sample in question, the following sequence of operations triggers this Meterpreter payload:

  1. The service named com.dominapp.supergpt.eluad.Vojnd starts upon the BOOT_COMPLETED action, as declared in the AndroidManifest.xml file.
  2. The thread named com.dominapp.supergpt.eluad.C2094e spawns and runs.
  3. The main method of the package class named com.dominapp.supergpt.eluad.Dapjs is invoked.
Image 4 is a screenshot of a configuration byte array that is characteristic of a Meterpreter payload.
Figure 2. Configuration byte array, characteristic of a Meterpreter payload.

The Meterpreter payload is configured to connect to the remote endpoint tcp[://]Gwdidkfkf-47070[.]portmap[.]io:47070. Portmap.io is a service that performs port forwarding free of charge.

Certificate Attribution

The digital code-signing certificate used to sign this sample belongs to the attacker with the following characteristics:

  • Email address – lkpandey950@gmail[.]com
  • Organization Common Name (CN) – Hax4Us
  • Located in Shahdara, Delhi, India
  • The certificate is valid from 2020-07-17 11:08:41 UTC to 2047-12-02 11:08:41 UTC
  • Serial number – 1a505d53b1c75046a81acb021fdb5f99936b75db
  • SHA-1 thumbprint – 65094A64233F818AEF5A4EDE90AC1D0C5A569A8B

This certificate is attached to over a hundred other publicly shared malware samples on VT (as shown in Figure 3).

Image 5 is a screenshot of a VirusTotal search query. The columns include detections, size, and when the samples were first seen. The samples also include tags, such as android, obfuscated, reflection, telephony, and so on.
Figure 3. Snapshot of partial results for VT search query androguard:"C:IN, CN:hax4us, L:shahdara, O:hax4us, ST:delhi, email:lkpandey950@gmail[.]com."
In contrast, the legitimate application is digitally signed with a generic certificate.

SMS to Premium-Rate Numbers

We've also uncovered another cluster of APK malware samples. On the surface, the malware seems to be presenting the following webpage (shown in Figure 4) containing a description of ChatGPT. But in fact, this threat conceals a sinister intent underneath.

Image 6 as a screenshot of an article about ChatGPT on a webpage, titled ChatGPT: optimizing language models for dialogue. There is an image of a robot head with the words, ChatGPT on it, and then the article goes into details about what ChatGPT is.
Figure 4. ChatGPT: Optimizing Language Models for Dialogue. hxxps[://]apkafe[.]com/what-is-chatgpt.
Image 7 is the OpenAI logo and logotype.
Figure 5. OpenAI logo and logotype.

Moreover, all these APK samples share the OpenAI logo often associated with ChatGPT (shown in Figure 5) as their application icon, adding to the deceptive narrative that this application is related to the ChatGPT AI tool.

These APK malware samples are capable of sending SMS messages to premium-rate numbers in Thailand (TH). Premium-rate numbers cost more than calls to normal phone numbers, in exchange for rendering some sort of service (e.g., users providing information). The business behind it collects the earnings, but this can also be abused to conduct scams and fraudulent activity. For reference, the official Android Open Source Project (AOSP) codebase contains a list of premium-rate numbers by country.

The Android permission to send SMS text messages, android.permission.SEND_SMS, is requested by the application, and a reference to the "country":"thailand" is passed as a ContentValue. The samples also make use of OneSignal, a service that enables apps to send messages via push notifications, including by email, SMS and within the app itself.

For instance, the configuration obtained from the URL hxxps[://]api[.]onesignal[.]com/apps/af63b434-ec50-46a0-9374-d57a383f2e03/android_params[.]js is reproduced below:

(The OneSignal app ID is af63b434-ec50-46a0-9374-d57a383f2e03)

{
  "awl_list": {},
  "android_sender_id": "660194064544",
  "chnl_lst": [],
  "outcomes": {
    "direct": {
      "enabled": false
    },
    "indirect": {
      "notification_attribution": {
        "minutes_since_displayed": 60,
        "limit": 10
      },
      "enabled": false
    },
    "unattributed": {
      "enabled": false
    }
  },
  "receive_receipts_enable": false
}

The formatted phone number in the android_sender_id field value is +661-9406-4544.

These APK samples are digitally signed with a generic certificate. As for other key attributes, their values are depicted in Table 3 below.

Validity From 2008-02-29 01:33:46 UTC

  To 2035-07-17 01:33:46 UTC
Serial number 936eacbe07f201df
Thumbprint (SHA-1) 61ED377E85D386A8DFEE6B864BD85B0BFAA5AF81

Table 3. Code-signing certificate attributes for Type II APK samples.

This cluster of samples can be subdivided into two smaller batches, each sharing some common characteristics. APK samples in the first batch send an SMS text message to one hard-coded, premium-rate Thai number and make use of the OneSignal service. APK samples in the second batch send different SMS text messages to two other hard-coded, premium-rate Thai numbers, and they do not obtain configuration from an external OneSignal endpoint.

The APK samples belonging to the first batch have a lower version compared to those from the second. This suggests that the first batch could be an earlier iteration of malware development than the second. This theory is supported by the earlier "first submission" timestamp of these APK samples on VT: batch one (February 2023), followed by batch two (March 2023).

Batch One

These are the SHA-256 hashes of samples in this batch:

  • 2980329fa5eaed0f5625e961572f7ae8136ca7df30cca9e9c8783c827627b692
  • 391e8f394af425f1e7edff6aea1605aa89f2fb0233c44e70cff265fc60ec3b1b
  • d1844bf3865c7d2e4745baa2496297937821171d7a3ad4412b0a4e767bc32b5e
  • d1b1813f7975b7117931477571a2476decff41f124b84cc7a2074dd00b5eba7c

Table 4 below summarizes the static attributes of samples in this batch.

Package names
  • com.chatgpt.tl
  • com.gg.gptchatt
  • com.chatgpt.go
  • com.chatgpt.ogothai
Main activities
  • chatgpt.subth.MainActivity
  • tikitaka.sub.MainActivity
Version name (code) chatgpt (183)
Android version Minimum: API level 18 (Android 4.3)
Target: API level 30 (Android 11)
Tags
  • GTA_TT
  • ChatGPT
First submission timestamps on VT (UTC) Between 2023-02-02 08:37:23 and 2023-02-07 03:08:33

OneSignal configuration
App ID af63b434-ec50-46a0-9374-d57a383f2e03
Android sender ID +661-9406-4544

Table 4. Static attributes of batch one APK samples.

Batch Two

These are the SHA-256 hashes of samples in this batch:

  • b787d5ef4a0c350a9f62f55907c8ef6d92bf7699b8544fabff5a263e52a2d0d1
  • be757541584cc2dc2e7adacf7a5186be07d474f06c8698a938589f86ce56ea34
  • e9bb6d04d796eb147b9d73a7df91fb9e6a99e0be8a41a61329d600a9dfe8b1ae

Table 5 below summarizes the static attributes of samples in this batch.

File size 1.249 MB (1,309,619 bytes)
Package name com.chatgpt.ggmmtlan
Main activity ggtlan.sub.MainActivity
Version name (code) chatgpt (200)
Android version Minimum: API level 22 (Android 5.1)
Target: API level 30 (Android 11)
First submission timestamp on VT (UTC) SHA-256 hash
2023-03-08 22:16:21 be757541584cc2dc2e7adacf7a5186be07d474f06c8698a938589f86ce56ea34
2023-03-10 12:00:23 e9bb6d04d796eb147b9d73a7df91fb9e6a99e0be8a41a61329d600a9dfe8b1ae
2023-03-17 10:19:14 b787d5ef4a0c350a9f62f55907c8ef6d92bf7699b8544fabff5a263e52a2d0d1

Table 5. Static attributes of Batch 2 APK samples.

Conclusion

The emergence of ChatGPT-themed APK malware poses a severe threat to the security and privacy of mobile devices. These types of malware can potentially steal sensitive information, spy on user activities and cause significant financial losses for unsuspecting victims.

To protect themselves against this type of malware, mobile users should take proactive measures, such as installing reputable antivirus software, being cautious when downloading apps from third-party sources and keeping their devices up to date with the latest security patches.

Overall, the threat of mobile malware highlights the critical importance of mobile device security. By remaining vigilant and taking proactive steps to safeguard our devices, we can help prevent the spread of this dangerous malware and protect ourselves from potential harm.

Palo Alto Networks customers with Cortex XDR, the Next-Generation Firewall and WildFire benefit from protections against the attacks discussed in this article. Additionally, the malicious indicators (domains, URLs and hashes) can be prevented with our DNS Security and Advanced URL Filtering services.

If you think you might have been impacted or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America Toll-Free: +1.866.486.4842 (+1.866.4.UNIT42)
  • UK: +44.20.3743.3660
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Indicators of Compromise

Category SHA-256 hashes
APK malware samples Type I
  • af19ca9213a20263c30584a2bf260dcdb3b4eafa4f43af10824af781573a2314
APK malware samples Type II

Batch One

  • 2980329fa5eaed0f5625e961572f7ae8136ca7df30cca9e9c8783c827627b692
  • 391e8f394af425f1e7edff6aea1605aa89f2fb0233c44e70cff265fc60ec3b1b
  • d1844bf3865c7d2e4745baa2496297937821171d7a3ad4412b0a4e767bc32b5e
  • d1b1813f7975b7117931477571a2476decff41f124b84cc7a2074dd00b5eba7c

Batch Two

  • b787d5ef4a0c350a9f62f55907c8ef6d92bf7699b8544fabff5a263e52a2d0d1
  • be757541584cc2dc2e7adacf7a5186be07d474f06c8698a938589f86ce56ea34
  • e9bb6d04d796eb147b9d73a7df91fb9e6a99e0be8a41a61329d600a9dfe8b1ae
URL
  • hxxps[://]api[.]onesignal[.]com/apps/af63b434-ec50-46a0-9374-d57a383f2e03/android_params[.]js
  • tcp[://]Gwdidkfkf-47070[.]portmap[.]io
Certificate Thumbprint (SHA-1)
  • 65094A64233F818AEF5A4EDE90AC1D0C5A569A8B

MITRE ATT&CK TTPs

ID Technique Description
T1582 SMS Control APK malware samples are capable of sending SMS to Premium-rate Numbers in Thailand.
T1623 Command and Scripting Interpreter APK malware samples are capable of providing Meterpreter shell access.

Additional Resources

Inside Win32k Exploitation: Background on Implementations of Win32k and Exploitation Methodologies

Posted on by Samantha Stallings

Executive Summary

In late January 2022, several reports on social media indicated that a new Microsoft Windows privilege escalation vulnerability (CVE-2022-21882) was being exploited in the wild. These reports prompted us to do an analysis of CVE-2022-21882, which turned out to be a vulnerability in the Win32k.sys user-mode callback function xxxClientAllocWindowClassExtraBytes.

In 2021, a very similar vulnerability (CVE-2021-1732) was reported to – and patched by – Microsoft. We decided to take a closer look at both vulnerabilities to better understand the code involved in each. In our initial analysis we wanted to determine why the patch for CVE-2021-1732 was not sufficient to prevent CVE-2022-21882.

This is part one of a series that will cover Win32k internals and exploitation in general using these two vulnerabilities and their related proof-of-concept (PoC) exploits as examples.

Here, we cover a significant amount of background information, including years worth of background research, conducted by several excellent researchers, to get the reader up to date to the latest implementations of Win32k and its associated exploitation methodologies. For an even deeper understanding of the subject, we also recommend reading all of the linked references at the end of the post.

Both vulnerabilities discussed in this series are detected and blocked by the Cortex XDR Anti-LPE protection module. Both vulnerabilities are data-only exploits that copy the NT/Authority System privilege token to that of the current (exploit) process for privilege escalation. The XDR Anti-LPE modules monitor for this specific type of privilege escalation technique.

Related Unit 42 Topics Microsoft Windows, CVE-2021-1732, CVE-2022-21882

Table of Contents

Introduction to CVE-2022-1732 and CVE-2022-21882
Win32k – History and Background
Basic Windows GUI API Background
Creating a Window
Window Messages and Window Procedures
Window Structures
User-mode Callbacks
Conclusion
Additional Resources

Introduction to CVE-2022-1732 and CVE-2022-21882

Quite a lot has been written on Windows development via the Win32 API, and Windows internals. However, in our experience, very few security-related sources cover development via the graphical user interface (GUI) or its underlying internals. This interface is implemented within Win32k.sys, Win32kbase.sys and Win32kfull.sys.

Therefore, we decided to do some research to get better acquainted with the Windows GUI internals and associated APIs. We read a few whitepapers on Win32k exploitation written over the past 10 years or so, as well as the Microsoft Developer Network (MSDN) documentation on the Win32 API.

We don’t want to assume any level of expertise with the underlying code involved. Therefore, to ease the understanding of the two vulnerabilities being analyzed as well as other Win32k.sys vulnerabilities and exploits, in our first post we will cover some background on the relevant APIs, objects and data structures involved.

Because exploitation of these vulnerabilities and the patch bypass method was relatively easy to understand, we chose these two recent examples to walk through some of the Win32k internals to help people understand how they are commonly leveraged to obtain read/write primitives. It also provides us with a good opportunity to discuss common Win32k exploit targets (user-mode callbacks) within the Win32k.sys codebase.

Win32k – History and Background

Prior to Windows NT 4.0, Microsoft implemented the GUI functionalities of the Win32 API within a user-mode process called the Client-Server Runtime SubSystem (CSRSS.exe). However, context switches between user-mode and kernel-mode were computationally expensive and required large memory overhead.

To eliminate these issues and speed up the overall Windows operating system, Microsoft decided to move the Windows subsystem (Window Manager, GDI and graphics drivers) to the kernel. This transition started with Windows NT 4.0 in 1996.

This change was implemented through a kernel-mode driver called Win32k.sys, in what is now known as the kernel-mode Windows subsystem. The user-mode component of the Windows subsystem still resides within CSRSS.

Although the move to the kernel greatly reduced the overhead required, Microsoft had to resort to some old tricks, such as caching management data structures within the user-mode portion of the client’s address space. In fact, to further avoid context switches, some management structures have historically been stored exclusively in user-mode. However, in an effort to eliminate kernel address leaks, Microsoft has started to implement methods that use user-mode and kernel-mode copies of these structures to prevent kernel addresses from being stored in user-mode structures.

Additionally, because Win32k needed a way to access these user-mode structures and support some existing user-mode functionality such as window hooking, user-mode callbacks were implemented to facilitate these tasks.

“User-mode callbacks allow Win32k to make calls back into user-mode and perform tasks such as invoking application-defined hooks, providing event notifications, and copying data to/from user-mode,” Tarjei Mandt wrote in a detailed whitepaper. His research was also presented at Black Hat USA in 2011. In doing so, he demonstrated the challenges Microsoft faced in implementing user-mode callbacks and preserving data integrity.

Mandt demonstrated that many objects were not being properly locked before making user-mode callbacks, which allowed user-mode code to destroy these objects during the user-mode callback, resulting in Use-After-Free (UAF) vulnerabilities. Although Microsoft has addressed many of the issues Mandt pointed out in 2011, user-mode callbacks are still abused today.

Inspired by Mandt’s research, in 2019 Gil Dabah wrote a paper building upon Mandt’s research. He discovered that even if user-mode code destroys objects that are correctly locked during user-mode callbacks, the destroyed objects can have secondary effects on other objects that are not locked correctly. This activity resulted in secondary object destruction and further UAF vulnerabilities.

Basic Windows GUI API Background

Before we discuss Win32k internals, we will briefly cover a simple C program that creates and destroys a window using the Win32 API. This will allow us to begin to understand how graphics windows are programmatically created and manipulated. It will also allow us to examine the underlying structures that define each window and their menus.

We’ll be referring to the sample code in Figures 1-3 below to discuss the basics of window creation and the underlying structures used to define windows and menus. Comments have been added to the sample code to make it as understandable as possible.

As shown in Figure 1, the sample program starts off by defining a window class. A process must register a window class before it can create a window of the type defined within the WNDCLASSEX structure. First a window class object is declared WNDCLASSEX wcx = { }, then the window class structure is filled in.

Image 1 is many lines of code that define the window class. The object is declared, and then the structure follows.
Figure 1. Defining the window class.

The elements of the window class are as follows:

  • cbSize: The size, in bytes, of this structure. Set this member to sizeof(WNDCLASSEX).
  • style: The window class styles. This member can be any combination of the Class Styles.
  • lpfnWndProc: Pointer to the function that processes all messages sent to windows in the class and defines the behavior of the window. Typically, the default window procedure is used for at least some messages. However, custom window procedures are often used to create unique window experiences. For more information, see WindowProc.
  • cbClsExtra: The number of extra bytes to allocate following the window-class structure. The system initializes the bytes to zero.
  • cbWndExtra: The number of extra bytes to allocate following the window instance. The system initializes the bytes to zero. Do not confuse this with cbClsExtra, which is common to all windows of this window class. This is often 0, but when it’s not, the memory is typically used to store data that is not constant across windows. We’ll see this used in the PoC later.
  • hInstance: A handle to the instance that contains the window procedure for the class. Identifies the application or .DLL that registered the class. Assigned the hinstance argument to WinMain here.
  • hIcon: A handle to the class. LoadIcon(NULL, IDI_APPLICATION) loads the default icon.
  • hCursor: A handle to the class cursor. LoadCursor(NULL, IDC_ARROW) loads the default cursor.
  • hbrBackground: A handle to the class background brush. GetStockObject (WHITE_BRUSH) returns a handle to a white brush. The return value must be cast because GetStockObject returns a generic object.
  • lpszMenuName: Pointer to a null-terminated character string that specifies the resource name of the class menu, as the name appears in the resource file. If no menu bar is needed, this field can be NULL.
  • lpszClassName: The class name that identifies this window class structure.
  • hIconSm: A handle to the small class icon.

Now that the attributes of the window class have been defined, we need to register it with the application using RegisterClassEx(), shown in Figure 2 below. On failure, RegisterClassEX() returns 0. Otherwise, it returns a class atom that uniquely identifies the class being registered. Registering the window class defines the class and its associated structure members to Windows.

Image 2 is a few lines of code showing the registration of the window class.
Figure 2. Registering a window class.

Creating a Window

Once the window has been registered, we can create an instance of the window class by calling CreateWindowExA(), shown in Figure 3 below.

Image 3 is the many lines of code that create the main window.
Figure 3. Code for creating a window.

The arguments of CreateWindowEX are as shown in Figure 4.

Image 4 shows the arguments making up the CreateWindowExA function prototype.
Figure 4. CreateWindowExA function prototype.

A brief description of each argument is listed below:

  • dwExStyle: The extended window style of the window being created. In this case, we have set it to the default window constant of WS_EX_LEFT, which gives the window generic left-aligned properties.
  • lpClassName: The class name. Taken from wcx.lpszClassName that was declared in the call to RegisterClassEX.
  • lpWindowName: The window name.
  • dwStyle: The style of the window being created. In this case, we used WS_OVERLAPPEDWINDOW, which creates a top-level (parent) window.
  • X: The initial horizontal position of the window. For an overlapped or pop-up window, the x parameter is the initial x-coordinate of the window's upper-left corner, in screen coordinates. For a child window, x is the x-coordinate of the upper-left corner of the window relative to the upper-left corner of the parent window's client area. If x is set to CW_USEDEFAULT, the system selects the default position for the window's upper-left corner and ignores the y-parameter.
  • Y: Same as above but for the y-coordinate.
  • nWidth: The width of the window.
  • nHeight: The height of the window.
  • hWndParent: A handle to the parent or owner window of the window being created.
  • hMenu: A handle to a menu, or specifies a child-window identifier, depending on the window style. For an overlapped or pop-up window, hMenu identifies the menu to be used with the window; it can be NULL if the class menu is to be used.
  • hInstance: A handle to the instance of the module to be associated with the window.
  • lpParam: The extra information that is passed to the window's window procedure. If no extra information is to be transmitted, pass NULL.

Once the window has been created with the call to CreateWindowEx(), the window has been created internally – which is to say, memory has been allocated and its structures populated – but not shown. To display the window, we call the ShowWindow() function.

ShowWindow() takes the handle obtained from the call to CreateWindowEXW() and the state variable nCmdShow, obtained from WinMain(). The nCmdShow variable determines how the window will be displayed on screen, whether it’s normal, maximized or minimized, for example.

ShowWindow() only controls how the application window is displayed. This includes elements such as a title bar, a menu bar, the window menu, the minimize button, etc. The client area is the area where the application displays data, such as where you type text in a text editor. The client area is painted by calling the UpdateWindow() function.

If you specify the WS_VISIBLE window style as the dwStyle parameter to the CreateWindowEXW() function, you do not need to call the ShowWindow() function. This is implied, and Windows will take care of invoking this for you. On a similar note, if you do not specify the WS_VISIBLE style and you also do not call the ShowWindow() function, the window will remain hidden from view.

Window Messages and Window Procedures

After the call to UpdateWindow(), the window is fully visible and ready for use. When writing a simpler console application for Windows, the application makes explicit function calls in response to user input from the console.

In a windowed application, a user can typically interact with the application by entering text, clicking through buttons and menus, or just by moving the mouse. Each of these actions have their own special functionality. To make this work, Microsoft implemented an event driven system that relays messages from user input (e.g., keyboard, mouse or touch) to the various windows in each application. These messages are handled by a function within each window, known as the window procedure.

Windows maintains a message queue for each thread, which will relay any user input event that affects the state of the window. Windows then translates these events into messages and places them into the message queue. The application processes these messages by executing the code similar to that in Figure 5 below.

Image 5 is the window message queue loop, starting with “while”.
Figure 5. Window message queue loop.

The GetMessage() function retrieves the next message from the message queue. The MSG parameter is a structure that contains the message information required for the assigned window procedure to properly handle the message.

Among the members of the MSG structure are a handle (hwnd) to the window whose window procedure receives the message, and a message that contains an identifier that determines what request is being asked of the window procedure. For example, if the message contains a WM_PAINT message, it tells the window procedure that the window’s client area has changed and must be repainted.

The TranslateMessage() function translates virtual-key messages into character messages, but this is not important for the current discussion. The DispatchMessage() sends the message to the window, identified by the window handle in the msg structure, to be handled by the window procedure defined by that window class.

Up to this point, the example code has accomplished the overhead of defining the window class by performing the following actions:

  • Registering the window
  • Creating an instance of a window defined by the window class
  • Displaying the window on the screen
  • Entering the message loop

It’s the window procedure that determines what is displayed and how it responds to user input. Windows provides a default window procedure to handle any window messages that an application does not process, and it provides the minimal functionality for any window to function properly.

The window procedure is where all the functionality of the window is defined and, as one might guess, they can be quite involved. For our purposes we are currently only interested in Microsoft’s default window procedure, DefWindowProc().

Window Structures

As mentioned earlier, Windows now manages GUI objects such as menus, windows, etc., in the kernel via Win32k.sys. When a window object is created, its properties are tracked within a data structure known as tagWND.

Unfortunately, Microsoft removed many of the Win32k debugging symbols, making it much more difficult to gain transparency into these structures. Based on some reverse engineering, Figure 6 shows what the structure looks like in Windows 10 version 21H1.

Image 6 is many lines of code — it is the TagWND parent structure.
Figure 6. TagWND parent structure.

This is not a comprehensive list of members, but only those important to this discussion. Looking at HMAllocObject during a call to xxxCreateWindowEx, where the allocation of the structure occurs, we can confirm this structure is 0x150 (336) bytes in size.

The WinDbg output just prior to the call to HMAllocObject is shown in Figure 7. You can see the fourth argument, which represents the allocation size, is stored in the r9 register and is equal to 0x150.

Image 7 is the WinDbg output showing the input parameters to the HMAllocObject object. The fourth argument represents the allocation size and is stored in the r9 register.
Figure 7. WinDbg output showing input parameters to HMAllocObject.

The tagWND structure, shown in Figure 6, used to be referenced within the Win32ClientInfo entry of the Thread Environment Block (TEB). It has since been removed to prevent easy leaking of kernel-mode addresses.

The first entry in the kernel tagWND structure is the window handle. Each window will have a representative tagWND structure associated with it in the kernel.

During the analysis of CVE-2022-21882, this structure will be important, but for now, we’ll focus on offset 0x28. I’ve labeled it as *pWND because Microsoft no longer supplies symbols. Additionally, Microsoft no longer provides a name for this structure — however, in the past it has been referred to as state or WW. According to Microsoft, these names are deprecated and no longer used internally.

What is important to know about this pointer is that it’s a user-mode version of the tagWND data that does not include kernel addresses, and it is structured differently than its parent tagWND structure. This child structure exists both in the kernel as well as in user-mode. This is how Windows manages the data in an attempt to avoid leaking kernel addresses, because any user-mode application will work with the copy of the tagWND structure located on the user-mode desktop heap and hence will not be able to see any kernel-mode addresses.

I will continue to refer to the child structure as a tagWND structure. Be aware, it is structured differently (as shown in Figure 8, below) than the parent tagWND structure above, but is still commonly referred to as tagWND in other research blogs and papers.

The child tagWND structure is shown in Figure 8, and the elements and their offsets were confirmed through reverse engineering. The gaps were not analyzed and are not important for this discussion.

Many of the elements of the WNDCLASSEX structure discussed in the section about creating a window can be seen within the tagWND structure. Therefore, it’s pretty clear that when a window is created, the properties assigned via the WNDCLASSEX structure are passed to the kernel and stored within the tagWND structures. The properties are then propagated to the user copies in both the kernel and user-mode desktop heaps.

Image 8 is many lines of code — the child tagWND structure. The BYTE gaps were not analyzed as they are not relevant.
Figure 8. User-mode safe copy of the tagWND structure.

Figures 9 and 10 show both the parent tagWND and the kernel copy of the user-mode safe tagWND structures respectively.

Image 9 is the WinDbg memory dump of the parent tagWND structure. ff.ff8e82 ffff8e82 ff.ff8e82 ffff8e82 ff.ff8e82 ffff8e82 ff.ff8e82 ffff8e82 ffff8e82 ffff8e82 ffff8e82 kd> dq exffff8e82ee8437ee Lye eeeøøeee• eee5033e eeeoøeeøs 00038390 oeeeeeee• eeeeøeeø eøeøøeee• eøeeoøee eeeøeøøe• eeeøøeeø eeeeøeee• eeøeeeee oeeeeeøe• eeeeeeeø eøeoøeee• eoøeeeee oeeeeøøe• eeeeøeee eeeoeeees oooeeøee eeeøe15b• a4b69d8ø eø8437eø 008437fø 00843800 00843810 00843820 00843830 00843840 00843850 00843860 00843870 00843880 eeeøeøøe• eeeeøees ffffd40fS f34ea4bø eøeøøeeø eeeoøeeøs e2cceme 008437ee 0083354e 82 ffff8e82 ffff8e82 ffff8e82 01038390 ee844e70 ee83ø93e ee81887ø
Figure 9. WinDbg memory dump of the parent tagWND structure.

The Figure above is the parent tagWND, and you can see that the handle (offset 0x00) is the same as that of the copy tagWND below. You can also see that the parent structure has kernel addresses, while the user-mode safe copy only has user-mode addresses. Lastly, notice the parent tagWND+0x28 is a pointer to the child tagWND copy’s address.

Image 10 is a screenshot of the WinDbg memory dump of the child tagWND structure. ffff8e82 ffff8e82 ffff8e82 ffff8e82 ffff8e82 ffff8e82 ffff8e82 ffff8e82 ffff8e82 ffff8e82 ffff8e82 dq poi(exffff8e82ee8437eo + ox28) eøeeeeee• 0005033e eeeeeøøø• eee3839ø gøeømeø• 40020019 ecceeøøe• egeømeø eøøe7ff7& ed32eeee eeeøeøøe• eeeøøeeø eqeeøeec oeøe10de eeeøeeee• øeeeeeeø eéeoøeee• ooeeeeee eeeøeøøø• eee384eø eeeeøeeø• eeø2ad3e eeeøeeee• øeeeeeeø oøeoøe27& ooøeoe88 eeeøeel€ eeeøøee8 eeeeeel€ eeøeee8e eeeø7ffT ed321edø oeeeeøøe• eeeeøeeø eeeoøeeø• eeø38fee eeeeeeeø• eeøeeeee eeeøe15b• a4b69d8Ø eeoeeeoe- oeeeoeoo eeeeoeee- eooeooee 01e3839ø 01083aø 01e383bø 010383cø 010383dø 010383eø 01e383fø 01038400 01e3841ø 01e3842ø 01038430
Figure 10. WinDbg memory dump of the child tagWND structure.

Historically, there have been a few methods to leak the kernel mode addresses of window objects. All objects within Win32k that store properties set by user-mode code (e.g., windows, menus) are commonly referred to as user objects.

All user objects, the user-mode copy of the tagWND structure being one of many, are indexed within a per-session handle table commonly known as the UserHandleTable. (Though the tagWND structure wasn’t always a user-mode safe copy and did once contain kernel addresses.)

It used to be possible to locate tagWND objects via the UserHandleTable through an exportable structure within User32.dll, called gSharedInfo. This is no longer possible as of Windows 10 version 1703. Due to Microsoft’s continued efforts to eliminate kernel address leaks, they have removed the kernel addresses of objects within the desktop heap from the UserHandleTable.

The Window Manager validates handles with an non-exported function, HMValidateHandle, which is located in User32.dll. Prior to Windows 10 version 1803, the Window Manager returned the kernel-mode pointer to the object whose handle was to be validated and it was commonly used to leak this address. Even though the kernel address leak has been fixed, this method will be important when we look at the two vulnerabilities later.

The reason exploit writers are so interested in locating tagWND structures is because, historically, you can modify tagWND.cbExtra with a large value to allow for an arbitrary write into an adjacent tagWND structure using the SetWindowLong function. However, as of Windows 10 version 1703, any bytes written by SetWindowLong are no longer written to the kernel. That is except under a specific condition, which will be discussed later during the analysis of the exploit. This fix has effectively killed this technique for creating an arbitrary write.

User objects are stored in one of three types of memory within the kernel: the desktop heap, the shared heap or the session pool. For the purposes of this discussion, we are interested in the desktop heap because the objects we’ll be working with are stored here.

Each desktop gets its own desktop heap. Since Windows stores management structures in the desktop heap, which resides in the kernel, there needs to be a way for user-mode applications to access these structures.

Historically, Windows created a user-mode mapped copy of the desktop heap that contained kernel-mode pointers to relevant structures. Today, these pointers have been replaced with user-mode pointers, indicating that Windows has begun to create an isolated copy of the desktop heap in user-mode to eliminate the disclosure of kernel-mode pointer addresses.

Typically when you are trying to exploit a kernel vulnerability, you need a few things to enable exploitation from user-mode. One of these is a way to determine where objects of interest are located within the kernel in order to get around kernel address space layout randomization (KASLR). Therefore, knowing where the desktop heap is located, as well as the ability to find specific objects of interest within the desktop heap is highly desirable.

In fact, since Windows 10 version 1607, Microsoft started adding mitigations in an attempt to prevent exploit writers from locating the desktop heap and its associated objects in the kernel. These mitigations include removal of kernel addresses from the UserHandleTable, as discussed above, as well as removal of kernel pointer references to the desktop heap within the Win32ClientInfo structure located in each process’ Thread Environment Block (TEB). Additionally, HMValidateHandle now returns user-mode (versus kernel-mode) pointers for any object handles passed to it.

For more information on the history of Microsoft’s Win32k kernel mitigation history, see Morten Schenk’s 2017 Black Hat USA presentation.

We should note that there is an assumption that we are operating under a low-integrity process. If the process is medium-integrity or higher, it is trivial to use API functions such as EnumDeviceDrivers and NtQuerySystemInformation to obtain kernel pointers of interest.

User-mode Callbacks

The final thing that needs to be discussed in this first post discussing the background of these PoCs are user-mode callbacks.

Because the windows subsystem is primarily located within the Windows kernel, while the windows themselves operate in user-mode, Win32k must make frequent calls from the kernel into user-mode. User-mode callbacks provide a mechanism to implement items such as application defined hooks, event notifications and copying data to/from the kernel from/to user-mode.

Win32k calls KeUserModeCallback, with the associated ApiNumber of the user-mode function it wants to call, when making a user-mode callback. The ApiNumber is an index into a function table, located within User32.dll (USER32!apfnDispatch). The address of this table is copied to the process environment block (PEB) (PEB.KernelCallbackTable) during initialization of User32.dll within each process.

In the analysis of the exploits, we show how user-mode callbacks are hooked via the KernelCallback table and show what the table looks like in WinDbg (shown in Figure 21 and Figure 22). The function prototype of KeUserModeCallback and its associated parameters are shown in Figure 11 below.

Image 11 is a screenshot of the KeUserModeCallback function and its associated parameters.
Figure 11. KeUserModeCallback function prototype.

The user-mode callback input parameters are passed via the InputBuffer, while the output from the callback function is returned within the OutputBuffer. Upon invoking a system call, ntdll!KiSystemService or ntdll!KiFastCallEntry stores a trap frame (TRAP_FRAME) on the kernel thread stack to save the current thread context and enable the restoration of registers upon returning to user-mode.

To make the transition back to user-mode in a user-mode callback, KeUserModeCallback first copies the InputBuffer to the user-mode stack using the trap frame information held by the thread object. It then creates a new trap frame with EIP set to ntdll!KiUserCallbackDispatcher, replaces the thread object's TrapFrame pointer, and finally calls ntdll!KiServiceExit to return execution to the user-mode callback dispatcher.

Image 12 is a screenshot of the KiUserCallbackDispatcher function prototype.
Figure 12. KiUserCallbackDispatcher function prototype.

Once the user-mode callback has completed, NtCallbackReturn is called to resume execution in the kernel. This function copies the result of the callback back to the original kernel stack and restores the saved trap frame (PreviousTrapFrame) and kernel stack stored in the KERNEL_STACK_CONTROL structure. Before jumping to the location where it previously left off (in ntdll!KiCallUserMode), the kernel callback stack is deleted.

Image 13 is a screenshot of the NtCallbackReturn function prototype.
Figure 13. NtCallbackReturn function prototype.

The Window Manager uses the Executive Resource (ERESOURCE) synchronization primitive, as opposed to exclusive locks, when operating on Win32k management structures. The ERESOURCE primitive allows multiple threads to access a shared resource in the cases where each thread is only attempting to read the resource in question. The ERESOURCE primitive is also known as a single writer, multiple readers primitive. Once the ERESOURCE is initialized, threads can acquire an exclusive lock (for writes) using ExAcquireResourceExclusiveLite, or a shared lock (for reads) by calling ExAcquireResourceSharedLite. The thread then releases the resource by calling ExReleaseResourceLite. There is a requirement for normal kernel APCs to be disabled to use the acquire APIs discussed here, and this is done by calling KeEnterCriticalRegion, prior to the acquire call, and KeLeaveCriticalRegion after the release call.

If Win32k didn’t release the resource upon calling a user-mode callback, and that user-mode callback allowed an application to freeze the GUI subsystem, Win32k would not be able to perform other tasks while the GUI subsystem was frozen. Therefore, Win32k always releases the resource upon calling a user-mode callback. The code in Figure 14 below demonstrates how this occurs.

Image 14 is a screenshot of pseudo code. It shows how Windows enters and leaves a critical region before calling to KeUserModeCallback.
Figure 14. Pseudo code showing how Windows enters and leaves a critical region before calls to KeUserModeCallback.

This practice creates a dilemma. Because user-mode code is free to do things like modify the properties of objects and reallocate arrays, upon returning from a user-mode callback, Win32k must ensure that referenced objects are still in an untrusted state. Operating on such objects without performing the proper checks or object locking can and does create security vulnerabilities.

In fact, Tarjei Mandt’s 2011 paper, "Kernel Attacks Through User-Mode Callbacks," identified multiple instances of these types of vulnerabilities, and was the basis for research on Win32k exploitation for many years. Microsoft subsequently reviewed the Windows user-mode callback functions to ensure proper verification or locking of objects, making it significantly more difficult to exploit this class of bugs.

In 2019, Gil Dabah demonstrated that, although Microsoft had effectively eliminated Win32k bugs through operations on objects modified through direct calls to user-mode callbacks, it was still possible to create kernel-mode to user-mode states that indirectly modified objects (e.g. destroying a parent window while performing operations on a child window) in order to leverage similar bugs. The vulnerabilities identified were much more complex, making them harder to identify and likely much smaller in number.

User-mode callbacks were deemed important enough to track by Microsoft that they were given special prefixes. User-mode callback function names are preceded with either a xxx or zzz. Those preceded by an xxx leave the critical region and call the user-mode callback, just like we described above. Those that are preceded by a zzz invoke asynchronous or deferred callbacks. We’ll only be concerned with xxx type callbacks for this discussion.

Conclusion

In our first installment of this series, we’ve covered using the Win32 API to create GUI objects such as windows and menus. We covered the user-mode and kernel-mode data structures that are used to manage these objects and how they have changed over the years to help optimize and secure the transition between user-mode and kernel-mode.

In our next post, we’ll walk through a PoC for CVE-2022-21882 and explain what the code is doing. Finally, we’ll discuss the vulnerability, how it’s used to elevate privileges, and why the patch for CVE-2021-1732 wasn’t sufficient to prevent CVE-2022021882.

Both vulnerabilities discussed in this series are detected and blocked by the Cortex XDR Anti-LPE protection module. The XDR Anti-LPE modules monitor for techniques such as these that are data-only exploits, which copy the NT/Authority System privilege token to that of the current process for privilege escalation.

Additional Resources

Analyzing Web Application and API Attacks: The Cloud as a Target and a Launch Pad

Posted on by Aviv Sasson

Executive Summary

Unit 42 researchers have identified a growing trend of cyberattacks targeting web applications and application programming interfaces (APIs) hosted by cloud service providers. Based on the data from our research, 14.9% of attacks in late 2022 on web applications and APIs targeted cloud-hosted deployments.

Attackers are also operating in the cloud and using it to launch their attacks on applications and APIs, as 5.1% of the attacks originated from cloud service providers' addresses. We will discuss what web and API attacks are and why attackers are exploiting them in the cloud. We will also review possible reasons for attacks originating from the cloud, as well as the potential impact on businesses and individuals.

Palo Alto Networks customers using Prisma Cloud are protected from these threats through the WAAS module, which is designed to protect web applications and APIs in cloud environments.

Related Unit 42 Topics Cloud, API

Understanding Web Applications and APIs

APIs and web applications play a pivotal role in today's digital landscape. Web applications are software programs accessed through web browsers, providing interactive and engaging user experiences. Meanwhile, APIs act as intermediaries that facilitate communication between different software applications.

By enabling seamless interaction between applications, APIs simplify complex processes and promote a more connected digital ecosystem. Generally, both web applications and APIs are served on the HTTP protocol.

The widespread use of web applications and APIs has made them an integral part of the modern online world. Businesses, organizations and developers are increasingly adopting them to create user-friendly interfaces and automate processes, boosting efficiency and productivity.

The growing reliance on these technologies has also led to an increased focus on ensuring their security and reliability. As a result, it is essential to keep up with best practices and stay informed about potential vulnerabilities to protect valuable data and to maintain users' trust.

Web Applications and APIs on the Cloud

There has been a significant surge of organizations moving web applications and APIs to the cloud in recent years. Recognition among businesses and organizations of the numerous benefits offered by cloud solutions is driving this transformation.

Cloud applications are mainly based on microservices architecture, which is why the shift to the cloud is encouraging an evolution in software architecture. This difference is driving these organizations to embrace microservices architecture.

There are also many advantages of employing a microservices architecture, which is an approach to software development where an application is divided into small, independent services that communicate with each other through APIs.

A recent survey of nearly 400 organizations by TechTarget's Enterprise Strategy Group (ESG) Research Team, published in April 2023 and co-sponsored by Palo Alto Networks, revealed that organizations plan to double down on microservices architecture for their applications and move their production workloads into cloud providers.

Image 1 is a column graph of the percentage of public-facing web applications based on microservices for cloud native architecture. The percentage of the columns in blue is the percentage as of May 2023. The percentages in teal are what is predicted from 24 months from May 2023.
Figure 1. Public-facing web applications based on microservices. "Today” and "from now" date from the April 2023 survey. Source: "Securing the API Attack Surface," ESG and Palo Alto Networks.
Image 2 is five pie charts of the production workloads that are run on public cloud infrastructure. The percentages in blue are the percentage of production workloads run on public cloud infrastructure services today in 2023. The percentages in teal are the production workloads run on public cloud infrastructure services 24 months from May 2023. From left to right, the pie charts are: 10% to 20% of workloads, 21 to 30% of workloads, 31% to 40% of workloads, 41% to 50% of workloads, and lastly, more than 50% of workloads.
Figure 2. Production workloads run on public cloud infrastructure. “Today” and "from now" date from the April 2023 survey. Source: "Securing the API Attack Surface," ESG and Palo Alto Networks.

A wide variety of organizations are increasingly deploying their web applications and APIs in the cloud due to its compelling advantages. Cloud-based infrastructure offers scalability, flexibility and cost-effectiveness, allowing businesses to adapt to changing demands quickly and only pay for the resources they use. Moreover, the cloud enables faster development and deployment cycles, promoting innovation and agility.

Attacks on Web Applications and APIs in the Cloud

Unit 42 researchers conducted research on roughly 12 billion attacks targeting web applications and APIs to determine if attackers are targeting such instances on the cloud. Their findings revealed that attackers indeed place increased emphasis on targeting cloud-hosted web applications and APIs.

Through the analysis of this data, we discovered that 14.9% of attacks on web applications and APIs were directed at workloads hosted by the top three cloud vendors. This indicates that the cloud is not only a critical component for businesses but also an increasingly attractive target for cybercriminals.

Image 3 is a pie chart of the destination of attacks. 85.1% are from others, and 14.9% are from the cloud.
Figure 3. Destination of the attacks.

We believe attackers are increasingly targeting web applications and APIs in the cloud for several reasons.

  • Growing adoption of cloud services:
    • As more businesses and individuals migrate their workloads to the cloud for scalability, cost-effectiveness and convenience, the attack surface for cybercriminals expands, providing more opportunities.
  • Complex security landscape:
    • Cloud environments often have complex architectures and multitenant setups, leading to increased security risks. Attackers can take advantage of misconfigurations, unsecured data storage or vulnerable APIs to exploit systems.
  • Abundant resources:
    • Cloud environments offer abundant computing resources, making them attractive targets for resource-intensive attacks such as distributed denial-of-service (DDoS) attacks or cryptojacking.
  • Value and Impact:
    • Web applications and APIs often handle valuable data or provide critical services. Attackers target these systems in the cloud to gain unauthorized access to sensitive information, disrupt services or leverage compromised resources for further attacks.

Origination of Web Application and API Attacks

In the course of analyzing attacks on web applications and APIs, Unit 42 researchers placed special emphasis on determining the origins of these attacks. We discovered that 5.1% of the attacks were initiated from deployments hosted by the top three cloud service providers.

One plausible explanation for this high percentage is that attackers compromise legitimate cloud-hosted workloads and then use them as launch pads for further attacks. This tactic enables threat actors to spread their reach to other cloud environments, expanding the scope of their malicious activities.

Another potential reason is that some attackers may pose as legitimate users to gain access to cloud infrastructure. In order to do so, they could use free tiers offered by cloud vendors or use stolen credit card information to pay for cloud services. Once inside the cloud environment, these attackers can launch their attacks directly from within the cloud.

Image 4 is a pie chart showing the origin of the attacks. 94.9% are others, and 5.1% are from the cloud.
Figure 4. Origin of web application and API attacks.


Conclusion

In light of this research, organizations must be vigilant in securing their cloud environments, ensuring proper configurations, and monitoring for potential threats. By understanding the risks and implementing robust security measures, businesses can better protect their web applications and APIs from cloud-based attacks.

As more businesses shift their web applications and APIs to the cloud, attackers might perceive these environments as attractive targets, offering a wealth of valuable data and resources. This trend underscores the importance of implementing robust security measures to safeguard cloud-hosted web applications and APIs.

Palo Alto Networks customers using Prisma Cloud are protected from these threats through the WAAS module, which is designed to protect web applications and APIs in cloud environments.

Cold as Ice: Answers to Unit 42 Wireshark Quiz for IcedID

Posted on by Brad Duncan

Executive Summary

Our introductory blog Cold as Ice: Unit 42 Wireshark Quiz for IcedID provides a packet capture (pcap) from an IcedID infection in April 2023. This blog provides the answers. Also known as Bokbot, IcedID is well-established Windows-based malware that can lead to ransomware. Reviewing the pcap provides an opportunity to analyze IcedID infection traffic.

If you would like to view this quiz without answers, please see our previous blog introducing the standalone quiz.

Palo Alto Networks customers are protected from IcedID and other malware through Cortex XDR and our Next-Generation Firewall with Cloud-Delivered Security Services that include WildFire, Advanced Threat Prevention and Advanced URL Filtering.

Related Unit 42 Topics pcap, Wireshark, Wireshark Tutorial, IcedID, BokBot

Scenario, Requirements and Quiz Material

Traffic for this quiz occurred in an Active Directory (AD) environment during April 2023. The infection is similar to previous IcedID activity tweeted by Unit 42 in March 2023. Details of the Local Area Network (LAN) environment for the pcap follow.

  • LAN segment range: 10.4.19[.]0/24 (10.4.19[.]1 through 10.4.19[.]255)
  • Domain: boogienights[.]live
  • Domain controller IP address: 10.4.19[.]19
  • Domain controller hostname: WIN-GP4JHCK2JMV
  • LAN segment gateway: 10.4.19[.]1
  • LAN segment broadcast address: 10.4.19[.]255

This quiz requires Wireshark, and we recommend using the latest version of Wireshark, since it has more features, capabilities and bug fixes over previous versions.

We also recommend readers customize their Wireshark display to better analyze web traffic. A list of tutorials and videos is available. As always, we recommend using Wireshark in a non-Windows environment like BSD, Linux or macOS when analyzing malicious Windows-based traffic.

To obtain the pcap, visit our GitHub repository, download the April 2023 ZIP archive and extract the pcap. Use infected as the password to unlock the ZIP archive.

Quiz Questions

For this IcedID infection, we ask participants to answer the following questions previously described in our standalone quiz post:

  • What is the date and time in UTC the infection started?
  • What is the IP address of the infected Windows client?
  • What is the MAC address of the infected Windows client?
  • What is the hostname of the infected Windows client?
  • What is the user account name from the infected Windows host?
  • Is there any follow-up activity from other malware?

Quiz Answers

The AD environment for this pcap contains three Windows clients, but only one was infected with IcedID.

Answers for this Wireshark quiz follow.

  • Malicious traffic for this infection started on April 19, 2023, at 15:31 UTC.
  • Infected Windows client IP address: 10.4.19[.]136
  • Infected Windows client MAC address: 14:58:d0:2e:c5:ae
  • Infected Windows client hostname: DESKTOP-SFF9LJF
  • Infected Windows client user account name: csilva
  • Follow-up activity: BackConnect traffic

Pcap Analysis: IcedID Chain of Events

To understand IcedID network traffic, you should understand the chain of events for an IcedID infection. A flow chart illustrating this chain of events is shown in Figure 1.

Image 1 is a flowchart of the chain of events in the April 2023 IcedID infection. It starts with email and or web-based delivery methods, continues to the IcedID installer, HTTP traffic for the gzip binary, malware created from that binary, and then command and control traffic from the IcedID infection. The initial follow-up activity can include Cobalt sStrike, VNC traffic, and BackConnect.
Figure 1. Flowchart for chain of events in the April 2023 IcedID infection.

Most IcedID infections use a standard variant of IcedID. These infections typically use an EXE or DLL that acts as an installer. This installer generates an unencrypted HTTP GET request that retrieves a gzip-compressed binary. The installer then converts this binary into malware used for a persistent IcedID infection.

The newly created, persistent IcedID generates HTTPS traffic to communicate with command and control (C2) servers. The C2 activity can lead to BackConnect traffic, Cobalt Strike and Virtual Network Computing (VNC) activity.

If the infected host is part of a high-value environment, an IcedID infection would likely lead to ransomware.

Pcap Analysis: Infection Vector

Using Wireshark customized from our tutorials, apply a basic web filter to see if anything stands out. Review the results in your column display. Look for unencrypted HTTP traffic over TCP port 80 directly to an IP address without an associated domain. This is a common characteristic in the chain of events for various malware infections.

At 15:31:08 UTC, the host at 10.4.19[.]136 generated an HTTP GET request to hxxp://80.77.25[.]175/main.php as shown below in Figure 2.

Image 2 is a screenshot of suspicious HTTP traffic in Wireshark that goes directly to an IP address, which is highlighted with an arrow.
Figure 2. Suspicious HTTP traffic directly to an IP address shown in Wireshark.

Follow the TCP stream for this HTTP GET request, as shown in Figure 3. This should generate a window for TCP stream 32, as shown in Figure 4.

Image 3 shows the menu selection to follow the TCP stream for the suspicious HTTP GET request.
Figure 3. Following TCP stream for suspicious HTTP GET request.
Image 4 is the TCP stream window in Wireshark. Indicated with two arrows is the first line of the HTTP GET request and highlighted by the black box is the location.
Figure 4. TCP stream for the suspicious HTTP GET request and response.

Figure 4 reveals HTTP request headers that contain a User-Agent string ending with Edg/112.0.1722.48. This string indicates the traffic was likely generated by the Microsoft Edge browser. However, web traffic generated by malware can spoof different User-Agent strings, and some browser extensions also have this ability, so we cannot be certain this was actually Microsoft Edge.

The HTTP response headers in Figure 4 show a 302 code, redirecting traffic to the following URL:

hxxps://firebasestorage.googleapis[.]com/v0/b/serene-cathode-377701.appspot.com/o/XSjwp6O0pq%2FScan_Inv.zip?alt=media&token=a716bdce-1373-44ed-ae89-fdabafa31c61

This Firebase Storage URL has been reported as malicious by at least seven security vendors on VirusTotal, and it appears in URLhaus tagged as IcedID. Fortunately, Google has taken the URL offline, and it is no longer active.

To further refine our search, add the client’s IP address 10.4.19[.]136 to the basic web filter as shown below in Figure 5. This reveals HTTPS traffic to firebasestorage.googleapis[.]com shortly after traffic to the initial URL at hxxp://80.77.25[.]175/main.php.

Image 5 is a screenshot of the HTTPS traffic to firebasestorage.googleapis[.]com after the initial suspicious URL. Highlighted in green in the screenshot is the command to insert into Wireshark. Two arrows indicate the request and the suspicious URLs.
Figure 5. HTTPS traffic to firebasestorage.googleapis[.]com after the initial suspicious URL.
Follow the TCP stream for the initial frame showing fire in the Wireshark column display. The TCP stream reveals 273 KB of data sent from the server to the Windows host, as shown below in Figure 6. This indicates a file might have been sent to the Windows host.

Image 6 is the TCP stream window showing the 275 kB of data sent from firebasestorage.googleapis[.]com to the Windows host. This is highlighted by an arrow in a menu that shows the entire conversation.
Figure 6. TCP stream showing 275 KB of data sent from firebasestorage.googleapis[.]com to the Windows host.
While the Firebase Storage URL is tagged as IcedID on URLhaus, this only indicates a distribution method for the IcedID installer. Based on this pcap, the victim opened a link that led to the Firebase Storage URL, and that URL delivered a file for an IcedID installer.

The URLhaus entry for this Firebase Storage URL reveals the ZIP archive it previously hosted, as shown in Figure 7.

Image 7 is a screenshot of the URLhaus entry for the firebasestorage URL. The screenshot shows the payload delivery, when it was first seen, the file name and file type, and the signature, which is IcedID.
Figure 7. URLhaus entry for our firebasestorage URL shows it delivered a zip archive.

The ZIP archive was submitted to Malware Bazaar. The archive is password-protected with the ASCII string 1235, and it contains a file named Scan_Inv.exe. This Windows executable file is an IcedID installer.

Pcap Analysis: IcedID Traffic

An IcedID loader first generates an unencrypted HTTP GET request over TCP port 80 to a domain using GET / without any further URL. This returns a gzip binary used by the installer to create the persistent malware on the victim’s host.

To find the gzip binary, use the same basic web filter with the victim’s IP address noted earlier in Figure 5. Scroll down to an HTTP GET request to skigimeetroc[.]com at 15:35:39 UTC and follow the TCP stream as shown below, in Figure 8.

Image 8 is a screenshot of the menu selection to follow the TCP stream for IcedID installers initial HTTP GET request. Highlighted in green is the filter to enter into Wireshark.
Figure 8. Following the TCP stream for IcedID installer’s initial HTTP GET request.

This is TCP stream 53 from the pcap, as shown below in Figure 9. The HTTP request headers for traffic generated by the IcedID installer have no User-Agent string. Note the cookie sent in the request headers in Figure 9.

Image 9 is the TCP stream window in Wireshark. Highlighted with a black box is the cookie data. Highlighted with an arrow is the gzip binary.
Figure 9. HTTP GET request generated by the IcedID installer.

The cookie line follows:

Cookie: __gads=422998217:1:1808:131; _gid=A0CA96894E9D; _u=4445534B544F502D534646394C4A46:6373696C7661:46353431423635424230383346354633; __io=21_1181811818_1193560798_2439418475; _ga=1.591597.1635208534.1022; _gat=10.0.22621.64

Cookie parameters for the HTTP GET request caused by this IcedID installer follow:

  • __gads= IcedID campaign identifier and information from the infected host.
  • _gid= Value calculated using MAC address of the infected host.
  • _u= ASCII text representing hex values of the victim’s hostname, Windows user account name and another undetermined value.
  • __io= Domain identifier from the infected host’s security identifier (SID).
  • _ga= Information based on the infected host’s CPU.
  • _gat= Windows version. For example, 10.0.22621.64 is an identifier for 64-bit Windows 11 version 22H2 and 10.0.19045.64 is an identifier for 64-bit Windows 10 version 22H2.

These cookie parameters are unique to IcedID infections. You can identify this traffic as IcedID without understanding the values. However, the _u= parameter reveals the victim’s hostname and Windows user account name. This information is very useful for our investigation. These hex values translate to a hostname of DESKTOP-SFF9LJF and a Windows user account name of csilva, as shown below in Figure 10.

Image 10 shows two hex value translations. The hex value highlighted in yellow translates to DESKTOP-SFF9LJF. The hex value highlighted in blue translates to csilva.
Figure 10. Using the _u= cookie parameter to determine the victim’s hostname and Windows user account name.

After retrieving the gzip binary, an IcedID installer creates persistent IcedID malware that takes over the infection. The infected Windows host then starts generating HTTPS traffic to IcedID C2 servers.

These C2 servers use different domain names and IP addresses than the initial domain contacted by the IcedID installer. IcedID’s HTTPS C2 traffic starts within a minute or two after the installer retrieves the gzip binary, and this activity uses at least two domains with random alphabetic names.

Our pcap reveals HTTPS traffic from the infected host to two domains after skigimeetroc[.]com at 15:35:39 UTC. These HTTPS C2 servers are askamoshopsi[.]com on 104.168.53[.]18 and skansnekssky[.]com on 217.199.121[.]56.

To find these servers, use the same basic web filter with the victim’s IP address noted earlier in Figure 5. HTTPS traffic starting at 15:36:41 UTC reveals these domains, as shown below in Figure 11.

Image 11 is a screenshot of the Wireshark traffic for the command and control IcedID servers. Highlighted with a black box is the IcedID installer that retrieve the gzip binary.
Figure 11. HTTPS C2 traffic after HTTP request by the IcedID installer.

Both C2 servers at askamoshopsi[.]com and skansnekssky[.]com use self-signed certificates for their HTTPS traffic. Self-signed certificates for HTTPS traffic will generate warnings about potential security risks when the site is viewed in any modern web browser.

Why do web browsers display warnings about websites that use self signed certificates? Because these are not validated by a Certificate Authority. Criminals can generate self-signed certificates that impersonate an existing company, or they can use generic values for the certificate issuer. Without a validated certificate, web browsers cannot be sure a website is what it says it is.

Figure 12 shows what the server at askamoshopsi[.]com looked like when we attempted to view it with the Firefox web browser. This warning allows users to view the server’s self-signed certificate.

Image 12 is two screenshots of Mozilla Firefox windows, showing a warning for the potential security risk of the invalid certificate. It also shows the certificate for the localhost.
Figure 12. Attempting to view the web server at askamoshopsi[.]com using Firefox.
As shown above in Figure 12, the certificate uses values like Internet Widgits Pty Ltd for the issuer’s Organization name and Some-State for the State/Province name. Values for self-signed certificates used by IcedID C2 servers are the same default values seen when using OpenSSL to create a certificate in Xubuntu as shown below in Figures 13 and 14.

Image 13 is the Xubuntu terminal x509 certificate creation for a web server using OpenSSL.
Figure 13. Creating an x509 certificate for a web server using OpenSSL in Xubuntu.
Image 14 is the Xubuntu terminal default values for the x509 certificate creation. Highlighted with arrows are the country name two letter code, which is Australia, the state, or province, name, and the organization name, which is Internet Widgets Pty Ltd.
Figure 14. Default values when creating an x509 certificate for a web server using OpenSSL in Xubuntu.

Since Internet Widgits Pty Ltd is a default value for a self-signed certificate in HTTPS traffic, and this value is sometimes seen in C2 traffic for malware. This should be more closely examined if it’s found when investigating a suspected malware infection. We can easily check any pcap for this value using the following Wireshark filter:

x509sat.uTF8String eq "Internet Widgits Pty Ltd"

The results from our pcap reveal the same IP addresses used by IcedID C2 servers for askamoshopsi[.]com at 104.168.53[.]18 and skansnekssky[.]com at 217.199.121[.]56. Expand the frame details for any of the results to find the same certificate issuer data, as shown in Figure 15.

Image 15 is a Wireshark screenshot. Highlighted in green is the command to put into the search bar. The results, highlighted by arrows, are the transport layer security, the certificate, including size, and the issuer of the certificate. Highlighted in a black box are the IDs that showed in the Xubuntu terminal.
Figure 15. Self-signed certificate by IcedID C2 servers using Internet Widgits Pty Ltd as the Organization name shown in Wireshark.

This certificate data is not unique to IcedID. The same values for self-signed certificates are also seen in HTTPS C2 traffic by other malware families like Bumblebee.

Pcap Analysis: BackConnect Traffic

Undetected IcedID infections lead to follow-up activity like BackConnect traffic.

For the past several months, BackConnect traffic caused by IcedID was easy to detect because it occurred over TCP port 8080. However, as early as April 11, 2023, BackConnect activity for IcedID changed to TCP port 443, making it harder to find.

This BackConnect activity from IcedID Unit 42 tweeted on April 11, 2023 used an IP address of 193.149.176[.]100 over TCP port 443. Filter for that IP address in Wireshark and combine it with tcp.flags eq 0x0002 as shown below, in Figure 16. This reveals the beginning of three streams.

Image 16 is a Wireshark command, highlighted in green, showing how to filter in Wireshark for the BackConnect traffic in the packet capture.
Figure 16. Filtering in Wireshark for BackConnect traffic in our pcap.

Follow the TCP stream for the first result, which is TCP stream 950. This stream reveals encoded or otherwise encrypted TCP traffic, as shown in Figure 17.

Image 17 is a TCP stream terminal window in Wireshark showing the BackConnect activity.
Figure 17. The first TCP stream for BackConnect activity.

Go back to the Wireshark filter used to reveal the TCP streams to 193.149.176[.]100. Follow the TCP stream for the second frame in the results, which is TCP stream 951. This reveals encoded or encrypted data followed by a command to reveal all hosts under the domain controller for boogienights[.]live as shown below, in Figure 18.

Image 18 is a TCP stream terminal window in Wireshark showing the BackConnect traffic with a command to and the results enumerating the Active Directory environment.
Figure 18. BackConnect traffic with a command to and results enumerating the victim’s AD environment.

The response to this command enumerates the victim’s AD environment, showing three clients logged in to the domain:

  • DESKTOP-JAL4D68
  • DESKTOP-RETP4BU
  • DESKTOP-SFF9LJF

Go back to the Wireshark filter used to reveal the TCP streams to 193.149.176[.]100. Follow the TCP stream for the last frame in the results, which is TCP stream 953. This lists disk drives on the victim client, and it provides a directory listing for each of these drives, as shown below in Figure 19.

The C:\ drive is the victim’s system drive. Z:\ is likely a mapped drive from a server’s shared directory that does not contain any files.

"Image 19 is a TCP stream terminal window in Wireshark showing the BackConnect traffic. A highlighted black box shows where the attacker sends a DISK command. The victim returns the disk drive list. The attacker then changes the directory to the Z:\ drive and lists its contents. This drive is empty. The second black box highlights where the attacker changes the directories to the C:\ drive and lists its contents. This is the victim’s system drive. It contains files and directories normally seen on a Windows host. This screenshot also shows the entire conversation size which is 796 bytes."
Figure 19. BackConnect traffic showing contents of the victim’s system drive and mapped drive.

Previous IcedID infections reveal this threat can use BackConnect traffic to load and run Cobalt Strike. We tweeted about one such case from March 24, 2023. However, this pcap does not contain any indicators of Cobalt Strike.

Previous IcedID infections also reveal this threat can generate VNC traffic over the same IP address used by BackConnect traffic. This happened during the same IcedID infection from March 24, 2023.

Pcap Analysis: Victim Details

The common internal IP address for the malicious traffic we have reviewed is 10.4.19[.]136. This is our victim’s IP address. To find the Windows user account name, filter on that IP address and kerberos.CNameString as shown in Figure 20.

Image 20 is a Wireshark screenshot highlighting the CNameString column, and the outcome of selecting “apply as column” from the menu. Highlighted in green is the command to filter to do this. Highlighted by arrows are the Windows account user name for the infected Windows host.
Figure 20. Finding the Windows user account name for our infected Windows host.

In some cases, lightweight directory access protocol (LDAP) might also provide the full name of the user. Use the following Wireshark filter:

ldap.AttributeDescription == "givenName"

This should provide four frames in our column display. Select any of them and expand the frame details until you find the user’s full name, Cornelius Silva, as shown below in Figure 21.

Image 21 is a Wireshark screenshot showing how to filter to find the victim’s full name from LDAP traffic. Highlighted by arrows are the names.
Figure 21. Finding the victim’s full name from LDAP traffic.

Perhaps the easiest way to find a victim’s hostname in Wireshark is to combine the victim’s IP address with a search for ip contains "DESKTOP-" as shown below, in Figure 22. Several results in the info column show Host Announcement DESKTOP-SFF9LJF sent by our infected Windows host at 10.4.19[.]136.

Image 22 is a Wireshark screenshot showing how to filter to find the Windows hostname in Wireshark. Highlighted in green is the filter to use.
Figure 22. Finding the Windows hostname in Wireshark.

To find the victim’s MAC address, just correlate the IP address to the host’s MAC address in any of the frame details windows, as shown below in Figure 23.

Image 23 is a screenshot where, highlighted, shows the victim’s MAC address with its associated IP address.
Figure 23. Correlating the victim’s MAC address with its associate IP address.

Conclusion

This blog provides answers and analysis for our Unit 42 Wireshark quiz featuring an IcedID infection from April 2023. IcedID is important to identify and stop, because it is a known vector for ransomware infections.

Many organizations lack access to full packet capture in their IT environment. As a result, security professionals might lack experience reviewing IcedID and other malware traffic. Training material like this Wireshark quiz can help. Pcap analysis is a useful skill that helps us better understand malicious activity.

You can also read the original post, without answers, from our standalone quiz post.

Palo Alto Networks customers are protected from IcedID and other malware through Cortex XDR and our Next-Generation Firewall with Cloud-Delivered Security Services that include WildFire, Advanced Threat Prevention and Advanced URL Filtering.

If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

Traffic from the pcap related to the IcedID infection:

  • hxxp://80.77.24[.]175/main.php
  • hxxps://firebasestorage.googleapis[.]com/v0/b/serene-cathode-377701.appspot.com/o/XSjwp6O0pq%2FScan_Inv.zip?alt=media&token=a716bdce-1373-44ed-ae89-fdabafa31c61
  • 192.153.57[.]223:80 - hxxp://skigimeetroc[.]com/
  • 104.168.53[.]18:443 - askamoshopsi[.]com - HTTPS traffic
  • 217.199.121[.]56:443 - skansnekssky[.]com - HTTPS traffic
  • 193.149.176[.]100:443 - BackConnect traffic

Files associated with traffic from this IcedID infection:

  • SHA256 hash: fc96c893a462660e2342febab2ad125ce1ec9a90fdf7473040b3aeb814ba7901
  • File size: 262,343 bytes
  • Filename: Scan_Inv.zip
  • File description: Password-protected ZIP archive hosted on Firebase Storage URL
  • Password: 1235
  • MalwareBazaar Database sample
  • SHA256 hash: bd24b6344dcde0c84726e620818cb5795c472d9def04b259bf9bff1538e5a759
  • File size: 333,408 bytes
  • Filename: Scan_Inv.exe
  • File description: Windows executable file for IcedID installer
  • MalwareBazaar Database sample

Additional Resources

Cold as Ice: Unit 42 Wireshark Quiz for IcedID

Posted on by Brad Duncan

Executive Summary

So far in 2023, IcedID has been a relatively constant presence in our threat landscape. Also known as BokBot, IcedID is Windows-based malware that can lead to ransomware. This Wireshark quiz presents a packet capture (pcap) from an IcedID infection that occurred in April 2023, and it provides experience analyzing traffic generated by this malware.

Anyone can participate in this quiz. However, participants should have some familiarity with Wireshark. Participants should also have a basic knowledge of IPv4 traffic. Palo Alto Networks has published a series of Wireshark tutorials to help people gain knowledge helpful for these quizzes.

Palo Alto Networks customers are protected from IcedID and other malware through Cortex XDR and our Next-Generation Firewall with Cloud-Delivered Security Services that include WildFire and Advanced Threat Prevention.

Related Unit 42 Topics pcap, Wireshark, Wireshark Tutorial, IcedID, BokBot

Scenario

Traffic for the IcedID infection occurred in an Active Directory (AD) environment during April 2023. This infection is similar to previous IcedID activity from March 24, 2023, which was tweeted by Unit 42.

Details of the network and questions for the quiz follow.

Local Area Network (LAN) Details

  • LAN segment range: 10.4.19[.]0/24 (10.4.19[.]1 through 10.4.19[.]255)
  • Domain: boogienights[.]live
  • Domain controller IP address: 10.4.19[.]19
  • Domain controller hostname: WIN-GP4JHCK2JMV
  • LAN segment gateway: 10.4.19[.]1
  • LAN segment broadcast address: 10.4.19[.]255

Quiz Questions

  • What is the date and time in UTC the infection started?
  • What is the IP address of the infected Windows client?
  • What is the MAC address of the infected Windows client?
  • What is the hostname of the infected Windows client?
  • What is the user account name from the infected Windows host?
  • Is there any follow-up activity from other malware?

Requirements

Since this is a Wireshark quiz, participants should use Wireshark to review the pcap. We encourage participants to customize Wireshark when reviewing malware traffic. Participants can customize Wireshark as demonstrated in the Unit 42 series of tutorials and videos.

We recommend using the latest version of Wireshark, since it has more features, capabilities and bug fixes over previous versions. Older Wireshark versions like 1.x and 2.x are not recommended for our Wireshark quizzes.

Infection traffic often contains malicious code targeting Microsoft Windows, so we recommend using a non-Windows environment to review the pcap for this quiz. Operating systems like BSD, Linux or macOS provide an ideal environment for Wireshark when reviewing traffic from Windows-based malware like IcedID.

Accessing the Pcap

To obtain the pcap, visit our GitHub repository as shown in Figure 1 and download the ZIP archive named 2023-04-Unit42-Wireshark-quiz.pcap.zip as shown in Figure 2. Use infected as the password to unlock the ZIP archive as shown in Figure 3.

Image 1 is a screenshot of Wireshark software showing where to click to download the ZIP archive from GitHub.
Figure 1. Selecting the pcap for this quiz from our GitHub repository.
Image 2 shows how to download the .zip archive.
Figure 2. Downloading the pcap.
Image 3 shows how to enter the password and how to extract the password-protected .zip archive from the download folder.
Figure 3. Extracting the pcap from the downloaded ZIP archive.

Conclusion

IcedID is a prominent part of our current threat landscape. This Wireshark quiz can help participants better understand network traffic associated with an IcedID infection.

The answers to the Unit 42 Wireshark quiz for IcedID are published in a separate blog post.

Palo Alto Networks customers are protected from IcedID and other malware through Cortex XDR and our Next-Generation Firewall with Cloud-Delivered Security Services that include WildFire and Advanced Threat Prevention.

If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Additional Resources

Updated May 30, 2023, at 6:40 a.m. PT.

Old Wine in the New Bottle: Mirai Variant Targets Multiple IoT Devices

Posted on by Zhibin Zhang

Executive Summary

On April 10, Unit 42 researchers observed a Mirai variant called IZ1H9, which used several vulnerabilities to spread itself. The threat actors use the following vulnerabilities to target exposed servers and networking devices running Linux:

Compromised devices can be fully controlled by attackers and become a part of the botnet. Those devices can be used to conduct further attacks, such as distributed denial-of-service (DDoS) attacks.

Palo Alto Networks Next Generation Firewall customers receive protections through Cloud-Delivered Security Services such as IoT Security, Advanced Threat Prevention, WildFire and Advanced URL Filtering, which can help detect and block the exploit traffic and malware.

Related Unit 42 Topics Mirai variant, IoT

Campaign Overview

Since November 2021, Unit 42 researchers have observed multiple campaigns using the Mirai IZ1H9 variant. Based on our analysis, we believe that these campaigns were operated by the same threat actor for the following reasons:

  • The malware shell script downloaders used in both campaigns are almost identical.
  • The botnet samples use the same XOR decryption key: 0xBAADF00D
  • The botnet client samples use almost identical functions.
  • Botnet client samples among those campaigns share the same infrastructure.

On April 10, 2023, Unit 42 researchers observed some abnormal traffic from our threat hunting system. This threat group tried to download and execute a shell script downloader lb.sh from IP 163.123.143[.]126.

If executed, the shell script downloader would first delete logs to hide its tracks. Then the following bot clients would be downloaded and executed, to accommodate different Linux architectures:

  • hxxp://163.123.143[.]126/bins/dark.x86
  • hxxp://163.123.143[.]126/bins/dark.mips
  • hxxp://163.123.143[.]126/bins/dark.mpsl
  • hxxp://163.123.143[.]126/bins/dark.arm4
  • hxxp://163.123.143[.]126/bins/dark.arm5
  • hxxp://163.123.143[.]126/bins/dark.arm6
  • hxxp://163.123.143[.]126/bins/dark.arm7
  • hxxp://163.123.143[.]126/bins/dark.ppc
  • hxxp://163.123.143[.]126/bins/dark.m68k
  • hxxp://163.123.143[.]126/bins/dark.sh4
  • hxxp://163.123.143[.]126/bins/dark.86_64

In the last step, the shell script downloader would block network connection from several ports including SSH, telnet and HTTP. It did so by modifying the device’s iptable rules, so that the victim wouldn’t be able to connect and recover the compromised device remotely, as depicted in Figure 1.

Figure one is a screenshot of the modified iptable rules.
Figure 1. Iptable modification.

Threat Group Analysis

Unit 42 researchers conducted analysis on the downloaded botnet client samples and found two URLs hosting more shell script downloaders:

  • hxxp://2.56.59[.]215/i.sh
  • hxxp://212.192.241[.]72/lolol.sh

Figure 2 is a diagram illustrating the campaign overview.

Figure 2 is a campaign overview diagram. It starts with the first IP address from April 10, 2023, and leads through the hosts, Mirai samples, the hosts, a shell script, and continues through the different downloaders.
Figure 2. Campaign overview diagram.

The shell script downloader from 2.56.59[.]215 would download botnet clients from hxxp://2.56.59[.]215/bins/. Those botnet client samples would contact a command and control (C2) server at 195.133.40[.]141 where there were URLs in the malware samples that hosted two shell scripts:

  • hxxp://31.210.20[.]100/lolol[.]sh
  • hxxp://212.192.241[.]72/lolol[.]sh

The shell script downloader from 212.192.241[.]72 would download botnet clients from hxxp://212.192.241[.]87/bins/, and those botnet client samples would contact the C2 domain dotheneedfull[.]club.

Malware Analysis

Based on behavior and patterns Unit 42 researchers observed during the analysis of the downloaded samples, we believe that they are a variant of the Mirai botnet called IZ1H9.

Discovered in August 2018, IZ1H9 is one of the most active Mirai variants. Just like the original Mirai, the IZ1H9 botnet client first checks the network portion of the infected device’s IP address. The client avoids execution for a list of IP blocks, including government networks, internet providers and large tech companies.

The botnet client makes its presence visible by printing the word “Darknet” to the console. The malware also contains a function that ensures the device is running only one instance of this malware. If a botnet process already exists, the botnet client will terminate the current process and start a new one, as depicted in Figure 3.

Figure 3 is a screenshot demonstrating how the botnet client terminates a current process, and then starts a new one. Included in the code is “instance already exists, overriding current process.”
Figure 3. IZ1H9 ensures there is only a single instance of execution.

The botnet client also contains a list of process names belonging to other Mirai variants and other botnet malware families. The malware checks the running process names on the infected host to terminate them.

The IZ1H9 variant tries to connect to a hard-coded C2 address: 193.47.61[.]75, as shown in Figure 4.

Figure 4 is a screenshot of the malware variant trying to connect to the hardcoded command and control (C2) IP address.
Figure 4. IZ1H9 malware C2 address.

Botnet Client Configuration String Decryption

For botnet client configuration strings, the IZ1H9 variant will first initialize an encrypted string table. It will then retrieve the encrypted strings through an index (as shown in Figures 5 and 6).

Figure 5 is a screenshot of the encrypted string table. Highlighted in red is table_init().
Figure 5. Initializing the encrypted string table.
Figure 6 is a screenshot of the malware variant retrieving strings. Highlighted within a red box is the code val = table retrieve val (84, 0). This is Mirai retrieving strings by index.
Figure 6. IZ1H9 retrieving strings.

The IZ1H9 variant uses a table key during the string decryption process: 0xBAADF00D. For each encrypted character, the malware performs XOR decryption with the following bytewise operations:

cipher_char ^ 0xBA ^ 0xAD ^ 0xF0 ^ 0x0D = plain_char

According to the logic behind XOR operation, the configuration string key equals to

0xBA ^ 0xAD ^ 0xF0 ^ 0x0D = 0xEA

IZ1H9 Sample Spreading Through HTTP, SSH and Telnet Protocol

For SSH and telnet channels, IZ1H9 inherits the most significant feature from the original Mirai source code: a data section with embedded default login credentials for scanner and brute-force purposes.

The original Mirai and IZ1H9 also both encrypt their login credentials with a 1 byte XOR key. The keys vary in different versions, but this variant uses 0x54, as shown in Figure 7.

Figure 6. IZ1H9 retrieving strings.
Figure 7. IZ1H9 variant credentials XOR decryption.

This IZ1H9 variant initializes the table of nearly 100 pairs of telnet/SSH login credentials in the scanner function. It then spreads through brute forcing network devices’ weak username and password combinations.

For the HTTP channel, IZ1H9 uses four remote code execution vulnerabilities to get access to the vulnerable devices, and it executes the shellcode script downloader shown in Figure 8.

Figure 8 is a screenshot of the exploit scanner function. It shows the Zyxlel RCE, Blink, RCE, Netlog RCE, and the Tense RCE.
Figure 8. Exploit scanner function.

Notice that in the Tenda vulnerability exploit function, the payload downloads tenda.sh from the malware host server but executes netlog.sh, as shown in Figure 9. In this case, the exploit will not work.

Figure 9 is a screenshot of the source code for Mirai. Highlighted in red boxes is tenda.sh, which downloads, and netlog.sh, which executes.
Figure 9: Malware executes wrong downloader.

The malware will initialize all DDoS attack functions before the botnet client establishes a connection with the C2 server. According to the Mirai source code, the malware developer will define the attack method and assign a command code to represent the attack method, as depicted in Figure 10.

Figure 10 is a screenshot of the Mirai source code, with the definitions for all of the attack methods.
Figure 10. Mirai attack method definition.

In this IZ1H9 sample, the threat actor defines a set of attack methods, shown in Table 1.

Command  Attack Method Description
0 attack_method_tcpsyn TCP SYN flooding attack
1 attack_method_tcpack TCP ACK flooding attack
2 attack_method_tcpusyn TCP URG-SYN flooding attack
3 attack_method_tcpall TCP DDoS with all options set
4 attack_method_tcpfrag TCP fragmentation attack
5 attack_method_asyn TCP SYN-ACK flooding attack
6 attack_method_udpgame UDP attack targets online gaming servers
7 attack_method_udpplain UDP flooding with fewer options
8 attack_method_greip GRE IP flooding attack
9 attack_method_std STD flooding attack
10 attack_method_udpdns DNS flooding attack
11 attack_method_udpgeneric UDP flooding attack
12 attack_app_http HTTP flooding attack
13 attack_method_dnsamp DNS amplification attack

Table 1. IZ1H9 attack method.

Conclusion

IoT devices have always been a lucrative target for threat actors, and remote code execution attacks continue to be the most common and most concerning threats affecting IoT devices and linux servers. Exposed vulnerable devices could lead to serious threats.

The vulnerabilities used by this threat are less complex, but this does not decrease their impact, since they could still lead to remote code execution. Once the attacker gains control of a vulnerable device, they can include the newly compromised devices in their botnet. This allows them to conduct further attacks such as DDoS.

To combat this threat, it is highly recommended that patches and updates are applied when possible.

Palo Alto Networks customers receive protection from the vulnerabilities and malware discussed above through the following products and services:

  • Next Generation Firewall with a Threat Prevention security subscription can help block the attacks with Best Practices via Threat Prevention signatures: 93386, 93718, 93721, 93722.
  • Advanced Threat Prevention provides inline machine learning that can detect vulnerability exploits in real time.
  • WildFire can help stop the malware with static signature detections.
  • Advanced URL Filtering and DNS Security are able to block the C2 domain and malware-hosting URLs.
  • The Palo Alto Networks IoT Security platform can leverage network traffic information to identify the vendor, model and firmware version of a device, and it can identify specific devices that are vulnerable to particular CVEs.
  • In addition, IoT Security has inbuilt machine learning-based anomaly detection that can alert the customer if a device exhibits nontypical behavior such as the sudden appearance of traffic from a new source, an unusually high number of connections, or an inexplicable surge of certain attributes typically appearing in IoT application payloads.

Indicators of Compromise

Artifacts

Shell Script Downloader

  • 692a5d099e37cd94923ea2b2014d79e6e613fb061a985069736dd3d55d4330c4
  • e0b1c324298eeccd54ffc2ff48288ec51fbec44f5f82229537508785a9bda6de
  • 931800d4f84bda7c0368c915dfd27721d63ed0ce6a9bc9f13e1417d4c2fe88f3
  • 64a350a33757f6631dc375632de191967ae59c876b4718a087e299bd54f23844

Mirai Variant Sample

  • 23190d722ba3fe97d859bd9b086ff33a14ae9aecfc8a2c3427623f93de3d3b14
  • 00b151ff78a492b5eae0c8d3c769857f171f8424cf36c3b2505f7d7889109599
  • 212b1af9fd1142d86b61956ac1198623f9017153153cfc20bfeab6a9fd44004a
  • 38406b2effd9fc37ce41ee914fda798de9c9b0e239a0cc94b1464dc2a9984fe9
  • 21185d9b7344edcd8d9c4af174e468c38cb3b061e6bd6bd64a4be9bd3fa27ff5
  • 65a46cd29dad935d067a4289445d2efb2710d44d789bf1bf0efb29f94d20e531
  • 06ef6c76e481d25aa09b3b15959d702be29c22d63bd35524766397e3d36d0d2e
  • 7bfb02c563ae266e81ba94a745ea7017f12010d5491708d748296332f26f04f5
  • 1e29f364f502b313f01f28f1ae85bf27114fae5eede6550809fe5bca58f59174

Infrastructure

Malware C2

  • 193.47.61[.]75
  • 195.133.40[.]141
  • dotheneedfull[.]club

Malware Host

  • 163.123.143[.]126
  • 2.56.59[.]215
  • 212.192.241[.]72
  • 212.192.241[.]87
  • 31.210.20[.]100

Additional Resources

Appendix

Campaign-related vulnerability information is listed below:

CVE-2023-27076: Tenda G103 Command Injection Vulnerability

This malicious traffic was first detected as a part of the IZ1H9 campaign on April 10, 2023. The command injection vulnerability is due to the failure to sanitize the value of the language parameter in the cgi-bin/luci interface of Tenda G103.

Figure 11 is a screenshot of the Tenda G103 command injection vulnerability. It shows the cgi-bin.
Figure 11. CVE-2023-27076 exploit in the wild.

CVE-2023-26801: LB-Link Command Injection Vulnerability

We captured this exploit traffic on April 10, 2023. The exploit targets a command injection vulnerability in the LB-Link wireless router’s /goform/set_LimitClinet_cfg component, which does not successfully sanitize the user input in the time1, time2 and mac parameters. This leads to arbitrary command execution.

Figure 12 is a screenshot of the LB-Link command injection vulnerability, including the component that is exploited.
Figure 12. CVE-2023-26801 exploit in the wild.

CVE-2023-26802: DCN DCBI-Netlog-LAB Remote Code Execution Vulnerability

The exploit was detected on April 10, 2023. The exploit works due to the Digital China Network DCBI-Netlog-LAB nsg_masq.cgi component failing to adequately sanitize the user-supplied input data, which leads to remote command execution.

Figure 13 is a screenshot of the DCN DCBI-Netlog-LAB Remote Code execution vulnerability. It shows the nsg_masq.cgi component in the first line of a screenshot.
Figure 13. CVE-2023-26802 exploit in the wild.

Zyxel Remote Code Execution Vulnerability

We observed this exploit traffic on Dec. 16, 2022. The exploit targets the Zyxel router’s /bin/zhttpd/ component. If insufficient input validation is found, the attacker can exploit the vulnerability to launch a remote code execution attack.

Figure 14 is a screenshot of the Zyxel remote code execution vulnerability. Included is the line that is exploited in the router, /b/zhttpd/.
Figure 14. Zyxel router exploit in the wild.

Updated May 26, 2023, at 3:30 p.m. PT.

It’s All in the Name: How Unit 42 Defines and Tracks Threat Adversaries

Posted on by Unit 42

Executive Summary

Within Unit 42 Threat Intelligence, we are often asked, “How does Unit 42 define and track actor activity?” To answer this question, we’ll give you a glimpse into our day-to-day activities, specifically focusing on how Unit 42 Threat Intelligence tracks behavior-based activity clusters.

The convention that Unit 42 Threat Intelligence uses for naming formal threat actor groups has been discussed in a previous blog. In this post, we’ll step back to give you a broader view, covering how the Unit 42 team builds and tracks activity clusters, and then associates this behavior with temporary threat actor groups. We’ll also discuss how we decide when to enact our formal actor naming and definition processes.

Related Unit 42 Topics nomenclature, threat actors, threat intelligence

Threat Tracking Overview

Defining a cluster of activity or a temporary actor group is a complex and often ambiguous process that typically takes a lot of time, effort and coordination. Formal actor naming begins when our team analyzes artifacts and TTPs from a single intrusion. It then evolves when we build and track additional activity into what we call an activity cluster.

Activity clusters consist of observed threat actor behavior that we have identified and use as a basis for tracking. These behaviors are clustered into groups of tactics, techniques and procedures (TTPs). We continually review and push these TTPs through our analysis process such that the clusters grow over time, potentially becoming a temporary threat actor group.

Figure 1 is a flow chart of how a threat actor gets named. It starts with threat actor, activity mapping mapping, where a temporary actor group is monitored. Finally, the threat actor gets a formal name.
Figure 1. Logical flow of tracked activity cluster to a formal actor name.

To achieve Unit 42’s mission of protecting the digital world against cyberattacks, we need to consistently track and monitor activity clusters and temporary threat actor groups.

Activity Clusters

An activity cluster is a grouping of related threat activity that includes observable artifacts like adversary tools, infrastructure or trade craft. The intention of defining an activity cluster is to build out a corpus of knowledge on a cluster of activity over time before “graduating” that cluster to a temporarily tracked threat group.

These clusters start with data collected in a single incident or investigation, and they grow by piecing together additional data from other incidents and collection sources. While running investigations, Unit 42 researchers often discover new artifacts associated with their investigations that can grow, merge or break off clusters of activity.

The Unit 42 team defines activity clusters based on our hypothesis of the actor’s motivation, where it is possible to establish. We name clusters using the following shorthand notation:

  • CL - short for cluster
  • CRI - short for criminal motivation
  • STA - short for state-backed motivation
  • MIX - short for mixed motivation
  • UNK - short for unknown motivation

Using this shorthand, Unit 42 names clusters of activity as follows:

CL-{CRI | STA | MIX | UNK} - ####

The number assigned to the activity cluster is in consecutive order, incrementing by one from the previously classified activity cluster.

Let’s examine how this looks with an example.

Unit 42 researchers are often involved in the research of multiple incidents targeting medical facilities throughout the United States. While working on each of the incidents, we find that the different adversary tools, infrastructure and trade craft are sometimes related. This helps us form an activity cluster.

We will often find the adversary exploiting the same vulnerabilities to gain initial access, applying the same lateral movement and exfiltration tactics, and using the same infrastructure for command and control (C2) across varying medical organizations. However, in many cases, we might not know the motivation of the adversary. Based on this, Unit 42 could track this as an activity cluster named CL-UNK-0042.

Now that we’ve examined some of the core tenants of tracking activity clusters, let’s examine the next step of our definition process: creating temporary actor groups.

Temporary Actor Groups

The concept of creating temporary actor groups is a way for the Unit 42 team to graduate activity clusters to a more solidified categorization. This graduation means the researcher feels confident that a single actor is participating in the threat activity.

It is important to note that within Unit 42 Threat Intelligence, we prevent direct migration of activity clusters to formally named actor groups. The activity clusters must first go through graduation to a temporary threat actor group.

This graduation is done after establishing several correlation points over time and across activity clusters, and after mapping those overlaps to the Diamond Model of Intrusion Analysis. This model focuses on core features of intrusions such as adversary, capability, victim and infrastructure, which Unit 42 researchers leverage and examine to correlate related clusters of activity.

For temporary actor groups, we opted to keep the same naming convention, with the addition of TGR, which is short for “threat group.”

We name temporary group names as follows:

TGR-{CRI | STA | MIX | UNK} - ####

Like the numbering for activity clusters, the number assigned at the end of the name for a threat group is in consecutive order, incrementing by one from the previously classified threat group.

Let’s look at an example of how we name a temporary actor group using our defined convention, continuing with tracking CL-UNK-0042. Further tracking and analysis revealed shared usage of phishing and C2 infrastructure in addition to overlaps with another activity cluster: CL-STA-0073.

During tracking, researchers also determined that threat actors were sharing tooling and malware throughout both clusters of activity, some of which were custom created. Based on these and previous investigative findings, Unit 42 could now start tracking clusters CL-STA-0042 and CL-STA-0073 as TGR-STA-0051.

Consistent tracking and analysis over time of TGR-STA-0051 could ultimately lead to a formal Unit 42 threat actor name, after we establish higher confidence in the relationship between the temporary group and the formal group.

Final Thoughts

In this blog, we wanted to give a glimpse into a day in the life of a researcher who’s identifying, defining and tracking activity clusters and temporary threat actor groups. We hope this insight provides clarity into how some of the more nebulous aspects of threat research are performed. You can now be better informed about the meaning of these two groupings, as Unit 42 starts to leverage activity clusters and temporary actor groups in our forthcoming publications.

Threat Assessment: Royal Ransomware

Posted on by Doel Santos

Executive Summary

Royal ransomware has been involved in high-profile attacks against critical infrastructure, especially healthcare, since it was first observed in September 2022. Bucking the popular trend of hiring affiliates to promote their threat as a service, Royal ransomware operates as a private group made up of former members of Conti.

The Unit 42 team has observed this group compromising victims through a BATLOADER infection, which threat actors usually spread through search engine optimization (SEO) poisoning. This infection involves dropping a Cobalt Strike Beacon as a precursor to the ransomware execution. Unit 42 incident responders have participated in 15 cases involving Royal ransomware in the last 9 months.

Royal ransomware also expanded their arsenal by developing an ELF variant to impact Linux and ESXi environments. The ELF variant is quite similar to the Windows variant, and the sample does not contain any obfuscation. All strings, including the RSA public key and ransom note, are stored as plaintext.

Palo Alto Networks customers receive protections against ransomware used by the Royal ransomware group 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.

Related Unit 42 Topics Ransomware

Overview

The Royal ransomware group was first observed in September 2022, compromising victims and using multi-extortion to pressure victims to pay their fee. Before their first appearance, this group had been linked to a previous ransomware family named Zeon, starting in January of the same year.

Unlike major ransomware groups like LockBit 3.0, which typically operate as a ransomware-as-a-service (RaaS) by hiring affiliates and promoting their RaaS model, we have not observed this particular group using a similar approach. It is suspected that this group is made up mainly of former members of the Conti ransomware group, who operate covertly and behind closed doors. The ex-members that formed this group are known as Team One.

Because some of the people behind this threat were part of the development of Ryuk (discovered in 2018), which is the predecessor of Conti, they have many years of experience. This means they have a solid base for carrying out attacks and know what works when extorting victims. Perhaps due to this experience, the group has already impacted numerous organizations across the globe. We’ve observed them making demands up to $25 million dollars in BTC.

Royal also has frequently threatened certain critical infrastructure sectors, such as manufacturing and healthcare. In a few months in 2022, the group impacted 14 manufacturing organizations, according to their leak site, and then followed up by publicizing claims of attacking 26 additional manufacturing organizations in 2023. They have also impacted eight healthcare organizations since their inception. The U.S. Department of Health and Human Services issued a warning about the threat Royal ransomware poses to the healthcare sector in January 2023.

Royal also has been one of the ransomware groups disrupting the education industry. We observed that they impacted 14 organizations in the education sector, including school districts and universities. In fact, in just the first few days of May 2023, the group had already impacted four educational institutions.

This group has leveraged their leak site to publicly extort victims into paying the ransom, as shown in Figure 1. The Royal group will harass victims until the payment is secured, using techniques such as emailing victims and mass-printing ransom notes.

Figure 1 is a screenshot of the royal ransomware leak site. It includes a contact form as well as a revenue counter, and a link to their website.
Figure 1. Royal ransomware leak site.

The Royal ransomware threat actor has an active Twitter account that was created in October 2022, called “LockerRoyal.” Most of the account content is announcements of compromised victims, tagging the victim’s Twitter account. In some cases, the threat actor will also reply to those same announcements.

It’s not unusual to see threat actor groups create social media accounts to keep spreading their brand and announcements. It’s clear that this group is trying to get attention from multiple organizations through any means necessary.

Figure 2 is two screenshots of the royal ransomware Twitter account. The left screenshot is the account profile.There are 29 tweets total, and the username is LockerRoyal. The right screenshot is a response. The right screenshot is the account responding to a tweet with OMG! The original tweet is by FalconFeedio, and says that the royal ransomware group has added a brewery based in Germany to their victim list.
Figure 2. Royal Twitter account replying to an alert.

This particular ransomware group has been observed using multiple initial access vectors to secure access into vulnerable systems, such as the following:

Once access is secured, this group uses multiple tools to support the intrusion operation, like the TCP/UDP tunnel Chisel and the Active Directory query tool AdFind, among others.

Victimology

Royal ransomware has impacted a variety of industries, including small businesses and large corporations alike. Based on information from their leak site and public reporting outlets, we can see that Royal ransomware has impacted industries such as manufacturing, as well as wholesale and retail. Since 2022, Royal ransomware has claimed responsibility for impacting 157 organizations on their leak site.

It's important to note that the impact of Royal ransomware extends beyond just financial losses. There have been instances where the group has targeted critical infrastructure, such as healthcare organizations and agricultural facilities. Since 2022, we have observed this group impacting seven local government entities – like the recent attack on the city of Dallas – in the United States and Europe.

Unit 42 incident responders have participated in 15 cases involving Royal ransomware.

This demonstrates the potential for broader and more severe consequences, as shown in Figure 3.

Figure 3 is a column chart showing the industries distribution per Royal leak site post. The vast majority is manufacturing, followed by wholesale and retail, and then professional and legal services.
Figure 3. Industries distribution per Royal leak site post.

Most of the organizations impacted by this ransomware are located in the United States, comprising 64% of the impacted organizations. Canada is the country second most impacted by this ransomware family, making the total for North America 73.2%. The next most impacted countries include Germany, the United Kingdom, Brazil, Italy and others (shown in Figure 4).

Figure 4 is a graph of countries impacted by Royal Ransomware by number of cases, with 155 total. The United States was impacted the most at 100 cases, followed by Canada with 13, and Germany with 11. The lowest case count is Mexico and Portugal at two cases each.
Figure 4. Countries impacted distribution per Royal leak site post.

Infection Chain

There are several different infection chains that lead to Royal ransomware. In some cases, we have observed instances where SEO poisoning and malvertising were used as initial access vectors. The goal of these two methods is to trick a victim into downloading and executing a malicious file that masquerades as legitimate software.

This kicks off a complex infection chain with multiple stages, including PowerShell scripts and MSI files. In certain cases, this leads to infection with BATLOADER.

BATLOADER will then attempt to download further payloads to the infected machine, such as VidarStealer, Ursnif/ISFB and Redline Stealer, as well as legitimate tooling such as the system management tool NSudo and the Syncro remote monitoring and management (RMM) tool. Most importantly, BATLOADER has been seen loading Cobalt Strike, which is often a precursor to ransomware distribution.

In one particular case where we saw Royal ransomware deployed, a snippet of C# code was identified that was originally pulled down from Pastebin. This code, when compiled, would decrypt and load shellcode. The shellcode appeared to be a simple Meterpreter stager that would reach out to an IP address and execute the final Meterpreter beacon. The IP address also hosted a Cobalt Strike server, from which we were able to retrieve the Cobalt Strike configuration.

The configuration contained fairly standard values, although the watermark appeared to be somewhat unique and not randomly generated: 12345. Querying for live Cobalt Strike servers on Shodan with the same watermark returned just over 50 results.

While this unique watermark could indicate a cracked version of Cobalt Strike, examining the domain names for these C2s revealed commonalities across the board. Almost every domain was named to resemble a security company.

For example, the following servers hosted Cobalt Strike beacons with the watermark 12345:

  • altocloudzone[.]live
  • cloudmane[.]online
  • palaltocloud[.]online
  • kasperslkyupdate[.]com
  • palalto[.]live
  • altocdn[.]online
  • paloaltokey[.]store
  • kasperskyupdates[.]com
  • Rapidfinact[.]com

Note that the names above are the work of a threat actor attempting to impersonate legitimate organizations and do not represent actual affiliations with that organization. The threat actor’s impersonation does not imply a vulnerability in the legitimate organizations’ products or services.

Defense Evasion

Unit 42 researchers observed Royal ransomware operators using PowerTool. This is a piece of software that has access to the kernel and is ideal for removing endpoint security software. They also executed batch scripts to disable security-related services, and deleted shadow file copies and logs after successful exfiltration.

Lateral Movement

Unit 42 researchers observed Royal threat actors using the network discovery software NetScan to identify and map out various connected computer resources such as other user targets and shares. In addition to using NetScan, we also observed them using PsExec for conducting lateral movement within the infected environments.

Command and Control (C2)

Unit 42 researchers observed threat actors using various popular legitimate remote management software also used heavily by other ransomware operations to maintain access to the infected environment. The use of Cobalt Strike and related beacons were also observed for C2. An interesting observation of a tool used for maintaining access was the use of Chisel, a TCP/UDP tunneling tool written in Golang.

Exfiltration

Unit 42 researchers observed Royal threat actors using Rclone, a legitimate tool to manage files between two systems, for exfiltrating stolen data before the deployment of ransomware. We found Rclone deployed in folders such as ProgramData, or renamed and masquerading in other folders. One popular filename used was svchost.exe.

Ransomware Functionality

Windows Variant

It is important to note that, while many ransomware families employ various forms of anti-analysis, as of late April, Royal ransomware does not employ anti-analysis tricks or string encryption.

There are five possible arguments for the Windows variant of Royal ransomware:

Argument Purpose
-path Path to be used for targeting encryption
-id 32-character ID for running sample
-ep Encryption percentage - indicates the percentage of each file to be encrypted
-localonly Encrypt only the local system
-networkonly Encrypt file shares connected to system

In Figure 5 below, the decompiled view contains the various command-line arguments to be evaluated at the start of the binary being executed.

Figure 5 is a screenshot of many lines of code. Five areas highlighted in red are the command line arguments that royal Ransomeware excepts as inputs. They are L-path, id, ep, localonly, and networkonly.
Figure 5. Command-line arguments Royal accepts as inputs.

Upon evaluating the command-line arguments provided, the ransomware then will create a cmd.exe process with the parameter to execute vssadmin delete shadows /all /quiet. The command is part of the standard ransomware playbook for impacting restoration services.

For the encryption process, Royal ransomware has a hard-coded RSA public key within the binary and uses AES for encryption. The AES encryption is set up using a 32-byte key and a 16-byte initialization vector (IV). The encrypted files are encrypted with the extension .royal_w.

During file enumeration and encryption, the sample avoids files with the following extensions and filenames (also shown in Figure 6):

Extensions:

  • .exe
  • .dll
  • .bat
  • .lnk
  • .royal_w
  • .royal_u

Files and folders:

  • README.TXT
  • Windows
  • Royal
  • Recycle.bin
  • Google
  • Perflogs
  • Mozilla
  • Tor browser
  • Boot
  • $Windows.~ws
  • $Windows.~bt
  • Windows.old

During the encryption process, if a file is encountered which is actively being used by the computer system, the ransomware can use the RestartManager API functionality to close a file. As shown in Figure 6, the strings related to skipped extensions and folder paths are shown in the .rdata section of the binary.

Figure 6 is a screenshot of the extensions and folders that are excluded in the .rdata section of the binary.
Figure 6. Extensions and folders excluded.

The ransom note dropped as a README.txt is shown in Figure 7 below.

Figure 7 is a screenshot of a royal ransomware ransom note. It is a read me a text and gives an exclamation explanation of what you expect, and how to contact the group.
Figure 7. Royal ransomware ransom note.

Royal also contains functionality to encrypt network shares connected to the victim machine. The decompiled view of the code path responsible for enumerating shares is shown in Figure 8 below.

Figure 8 is a screenshot of many lines of code. It is the decompiled view of the code path responsible for enumerating shares.
Figure 8. Enumerates network shares and excludes ADMIN and IPC shares.

For supporting cryptographic operations used in the ransomware, the code is statically compiled with OpenSSL. The cryptographic references can be seen in Figure 9 below and can be cross-referenced by examining the library on GitHub.

Figure 9 is a screenshot of the open SSLibrary statically compiled with the ransomware binary. Highlighted in the string column is the word crypto.
Figure 9. OpenSSL library statically compiled with ransomware binary.

Linux Variant

During development of this post, a Linux variant of Royal ransomware was identified by @BushidoToken on Feb. 1, 2023. This is the first known version not targeting Windows systems. However, considering many ransomware families have an ESXi/Linux focused variant, this isn’t unusual. It only makes sense that this group would expand their arsenal to impact other environments.

There are minimal differences between the Linux and Windows variants in terms of encryption. AES-256 is used for symmetric encryption, while RSA-4096 is used for asymmetric encryption within the sample.

Additionally, there is a lack of obfuscation within the Linux sample. All strings are stored as plaintext, including the RSA public key and the ransom note.

There are five possible arguments for the Linux variant of Royal ransomware:

Argument Purpose
-id 32-character ID for running sample
-ep Encryption percentage – indicates the percentage of each file that will be encrypted
-stopv Indicates to the sample whether to stop VM-linked processes or not
-fork Forks the current process for encryption
-logs Informs the sample to log information to a file

During file enumeration and encryption, the sample avoids files with the following extensions and filenames:

Extensions:

  • .v00
  • .b00
  • .sf
  • .royal_u
  • .royal_w
  • .royal_log_
  • .readme

The variant is also compiled with the OpenSSL library, resulting in a large number of unreferenced crypto-linked strings.

Figure 10 is a screenshot of the open SSL string was seen within the Linux ransomeware binary.
Figure 10. OpenSSL strings seen within Linux ransomware binary.

Conclusion

Royal ransomware has been more active this year, using a wide variety of tools and more aggressively targeting critical infrastructure organizations. Organizations should implement security best practices and be wary of the ongoing threat of ransomware. This is true not only for Royal ransomware but for other opportunistic criminal groups as well.

The Unit 42 team recommends that defenders have advanced logging capabilities deployed and configured properly. This includes tools such as Sysmon, Windows command-line logging and PowerShell logging.

Ideally, you should be forwarding these logs to a security information and event management tool (SIEM) to create queries and detection opportunities. Keep computer systems patched and up to date wherever possible to reduce the attack surface related to exploitation techniques.

Deploy an XDR/EDR solution to perform in-memory inspection and detect process injection techniques. Perform threat hunting looking for signs of unusual behavior related to security product defense evasion, service accounts for lateral movement and domain administrator-related user behavior.

Protections and Mitigations

Palo Alto Networks customers receive protections from the threats discussed above through the following products.

  • WildFire: All known samples are identified as malware.
  • Cortex XDR with:
    • Indicators for Royal
    • Anti-Ransomware module to detect Royal encryption behaviors on Windows
    • Local Analysis detection for Royal binaries on Windows
  • Behavioral Threat Protection (BTP) rule helps prevent ransomware activity on Linux
  • Next-Generation Firewalls (NGFW): DNS signatures detect the known command and control (C2) domains, which are also categorized as malware in URL Filtering.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

Hashes

595c869f8ec7eaf71fef44bad331d81bb934c886cdff99e1f013eec7acdaf8c9 Royal Windows Variant
b57e5f0c857e807a03770feb4d3aa254d2c4c8c8d9e08687796be30e2093286c Royal Linux Variant
b64acb7dcc968b9a3a4909e3fddc2e116408c50079bba7678e85fee82995b0f4 Royal Linux Variant
b64acb7dcc968b9a3a4909e3fddc2e116408c50079bba7678e85fee82995b0f4 Royal Linux Variant
12a6d61b309171b41347d6795002247c8e2137522a756d35bb8ece5a82fc3774 Royal Linux Variant

Infrastructure

  • royal2xthig3ou5hd7zsliqagy6yygk2cdelaxtni2fyad6dpmpxedid[.]onion

Additional Resources

Teasing the Secrets From Threat Actors: Malware Configuration Parsing at Scale

Posted on by Mark Lim

Executive Summary

Configuration data that changes across each instance of deployed malware can be a gold mine of information about what the bad guys are up to. The problem is that configuration data in malware is usually difficult to parse statically from the file, by design. Malware authors know the intelligence value as they provide directives for how the malware should behave.

Malware is like most complex software systems in that there are many advantages for code reuse and abstraction. Therefore, it is not surprising to see that the concept of software configuration is pervasive across the various malware families we analyze. After all, it’s pretty hard to imagine a stereotypical cybercriminal wanting to bother with recompiling their code to change an IP address or whatever else, when going after different targets.

But the good news is that statically armored configuration data can often easily be found and parsed directly from memory. We will cover a nice example of an IcedID (information stealer) configuration, how it was obfuscated and how we’ve extracted it.

Palo Alto Networks customers receive improved detection for the evasions discussed in this blog through Advanced WildFire. As we continue to parse and extract this information from malware families at scale, we hope to build out a pool of threat intelligence that will better help us understand the campaigns and tactics of the various threat actors who are targeting various organizations.

Related Unit 42 Topics Memory Detection

What Are Malware Configurations?

So what exactly do we mean by the term “configuration” when talking about malware? Outside the context of malware, we think of configuration in terms of defining how systems should behave. For example, we would consider the rules used to define which networking routes for a firewall are allowed, or which font size your web browser uses while you read this, as configurable information.

For malware, this is no different. Malware configurations are just collections of elements that define how a malware operates, such as the following:

  • Command-and-control (C2) network addresses
  • Passwords for remote administrators
  • File paths in which to drop persistent payloads

The way these elements are embedded in malware components tends to be specific to each malware family. Also, they might evolve over time as malware undergoes development, or when malware authors change their build process.

Generally speaking, malware configuration elements tend to be the properties of malware that the authors want to make easily editable between campaigns and deployments without requiring manual code edits for each one. Malware configuration elements can also expose latent behaviors and malware infrastructure that are not typically observable under routine dynamic analysis.

Malware configurations have intelligence value for security practitioners because they provide insights into campaigns over time. In some cases, defenders could use them as actionable artifacts for network detection, or for identifying infected hosts. The successful extraction and validation of a malware configuration can also be used to reinforce our confidence when identifying a file as malicious.

Because malware configurations have value to security systems and defenders alike, it is state-of-practice for modern malware authors to protect their configuration elements using different techniques. These protections often include a blend of encryption, obfuscation and compression. They might also be layered with evasive techniques.

This protection poses a significant challenge for malware configuration extractors that operate solely by using static analysis, because all of these protections must be detected and bypassed before extraction can be performed. Using an advanced dynamic analysis sandbox combined with intelligent runtime memory analysis makes it possible to bypass many of these protections and pinpoint the best opportunities to perform extraction.

When we represent and store these configurations using standardized schemas, it enables us to extract maximum value through automation, machine learning and interactive analysis. The DC3-MWCP library defines a schema for many of the most common configuration element types, and it provides a simple library for serialization to JSON.

The MITRE MAEC and STIX projects also provide us with a more general vocabulary for representing malware configuration elements. This also allows us to correlate the elements with observable objects collected during dynamic analysis.

IcedID Analysis

Let’s look at one IcedID binary and how its configurations are encrypted.

Hash 05a3a84096bcdc2a5cf87d07ede96aff7fd5037679f9585fee9a227c0d9cbf51

This particular attack chain, shown in Figure 1, was discovered in early November 2022. It delivered IcedID, an information stealer also known as Bokbot, as the final payload. This threat is well-known malware that has been attacking people since 2019.

The following diagram shows the infection chain.

Image 1 is a graphic showing the IcedID infection chain. It starts with malicious spam executed by the user, and it ends with a scheduled task created to persist IcedID stage two.
Figure 1. IcedID infection chain.

Authors of IcedID took pains to hide their configurations. Recent samples of IcedID stage two would only be downloaded if the victim’s machine matched the requirements of the threat actor.

The configurations of IcedID consisted of C2 URLs and their campaign IDs. The C2 URLs included some that might not be revealed during the execution of the IcedID binaries. The campaign ID links IcedID samples back to specific threat actors.

We will go through the following steps to extract the configurations found in the IcedID stage one and two binaries:

  1. Unpack the IcedID binary
  2. Locate the encrypted configuration data blob
  3. Extract the encryption key
  4. Decrypt the configuration data blob with the encryption key

Unpacking IcedID Stage One

IcedID stage one unpacks itself by first allocating memory using the VirtualAlloc function. This is followed by erasing the allocated memory using the Memset function, as shown in Figure 2. Finally, it copies the unpacked data to the allocated memory using the Memmove function.

To dump the unpacked data, we set a breakpoint at Memmove. The second argument of Memmove contains the address of the unpacked data. Figure 2 also shows the DOS MZ header of the unpacked IcedID stage one in the right-hand side of the hex dump.

Image 2 is a screenshot of iced ID stage one as it is unpacked image two is a screenshot of unpacking iced ID, stage one. This is done by using the VirtualAlloc function.
Figure 2. Unpacking IcedID stage one.

Locating the Encrypted Configuration Data Blob

Next, we located the encrypted configuration data blob using the unpacked stage one IcedID. While debugging the unpacked IcedID stage one file, we set a breakpoint at the address that called WinHttpConnect, as shown in Figure 3. The address pointed to by register RDI contains the string of the C2 URL.

Image 3 is a screenshot of IcedID stage one being debugged.
Figure 3. Debugging IcedID stage one.

By backtracing the code, we located a function that used the decrypted configuration as shown in Figure 4.

Image 4 is a screenshot of IcedID stage one code being backtraced.
Figure 4. Tracing code in IcedID stage one.

Tracing the code flow back, we found the loop that decrypted the configuration, as shown in Figure 5.

Image 5 is a screenshot of the configuration decryption loop for IcedID stage one.
Figure 5. Configuration decryption loop for IcedID stage one.

The instruction at 0x7FEF33339CD loaded the address of the encrypted configuration data blob (Encrypted_Config) into register RDX.

Extracting the Encryption Key

The instruction at 0x7FEF33339D4 reads the encryption key. The key is 0x40 bytes offset from the address of Encrypted_Config. We also learned the configuration is 0x20 bytes long. An XOR loop was used to decrypt the configuration.

Decrypting the Configuration Data Blob With the Encryption Key

After gathering the encryption key, the encrypted data blob and the decryption routine, we can now decrypt the configuration using the following script shown in Figure 6.

Image 6 is a screenshot of the configuration decryption script for IcedID stage one.
Figure 6. Configuration decryption script for IcedID stage one.

The decrypted IcedID stage 1 configuration has the following format, as shown in Figure 7.

Image 7 is a screenshot of the IcedID stage one configuration format.
Figure 7. IcedID stage one configuration format.

From the decrypted configuration, we can extract the following IoCs:

C2 URL bayernbadabum[.]com
Campaign ID 1139942657

Now, we will decrypt the configuration for the IcedID stage two binary.

Unpacking the IcedID Stage Two Binary

As the IcedID stage two binary uses the same packer as stage one, we will not repeat the unpacking steps here.

Locating the Encrypted Configuration Data Blob

We set a breakpoint at the address that calls Winhttpconnect, as shown in Figure 8.

Image 8 is a screenshot of IcedID stage two being debugged. Highlighted is row 14, were the breakpoint is set.
Figure 8. Debugging IcedID stage two.

After tracing the code, we located the function that used the decrypted configuration, as shown in Figure 9.

Image 9 is a screenshot of the traced code of IcedID stage two, showing the location of the function that used the description configuration.
Figure 9. Tracing code in IcedID stage two.

Extracting the Encryption Key

Tracing the code flow even further back, we found the function that decrypts the configuration. The first few instructions located the encrypted configuration blob. The encrypted blob is 0x25c bytes long. The encryption key is the last 0x10 bytes of the encrypted configuration blob, as shown in Figure 10.

Image 10 is a screenshot of the encryption key for IcedID stage two. Highlighted is the address of the encryption key, which is below the line offset to encryption key.
Figure 10. Loading the encryption key for IcedID stage two.

After retrieving the encryption key, the next step is the loop to decrypt the encrypted blob, as shown in Figure 11.

Image 11 is a screenshot of the configuration decryption loop for IcedID stage two. This is the next step after retrieving the encryption key.
Figure 11. Configuration decryption loop for IcedID stage two.

Decrypting the Configuration Data Blob With the Encryption Key

We replicated the instructions in the decryption loop using Python. After gathering the encryption key, encrypted data blob and the decryption routine, we can now decrypt the configuration using the following script (shown in Figure 12).

Image 12 is a screenshot of the configuration decryption script for IcedID stage two.
Figure 12. Configuration decryption script for IcedID stage two. Note: Jquinn147 and myrtus0x0 published a similar configuration decryption script for IcedID in May 2021, called IcedDecrypt (GitHub).

The decrypted IcedID stage two configuration has the following format, shown in Figure 13.

Image 13 is a screenshot that shows the configuration format for the decrypted IcedID stage two.
Figure 13. Configuration format for IcedID stage two.

From the decrypted configuration, we can extract the following indicators of compromise (IoCs):

C2 URLs newscommercde[.]com

spkdeutshnewsupp[.]com

germanysupportspk[.]com

nrwmarkettoys[.]com
C2 URI news
Campaign ID 1139942657

We have manually decrypted the configuration for both the IcedID stage one and two binaries.

Scaling Up

Now that we’ve discussed the work of figuring out how to target the configuration data in memory, the next challenge is to figure out how to perform this at scale. The massive scale of most malware processing systems means that most practitioners looking to build out a configuration extraction system will need to be careful about adding additional overhead. This means that we will need a mechanism to intelligently identify only the samples of interest for each parser, so we’re not unnecessarily running dozens of parsers across millions of samples.

We think a reasonable approach to this problem involves using intelligent runtime memory analysis, as it provides us with excellent visibility into the secrets malware authors want to protect. A typical workflow for our malware configuration extractors includes the following activities:

  • Scanning memory and/or other dynamic analysis artifacts
  • Applying a noise filter on the results to identify the best candidates for extraction
  • Performing extraction using the best fitting module and storing the results for reporting and indexing

Generalizing this common workflow presented us with the opportunity to make the following improvements:

  • Optimizing the search phase by only scanning analysis data once in most cases
  • Applying abstractions and reusable code for many common tasks
  • Limiting the impact of modules with problematic inputs or other bugs
  • Giving our security researchers visibility into the performance of their modules

The following example shows some of the IoCs from a recent IcedID extractor after being deployed at scale. Having a nice framework for deploying configuration extractors means that once you are finished crafting a configuration extraction script, it’s time to kick your feet up and relax while hundreds of configurations flow into your malware configuration database.

Image 14 is a screenshot of IoCs from IcedID samples. It starts at line 34 and continues to line 59.
Figure 14. IoCs from IcedID samples.

Conclusion

Thank you for joining us in this overview of malware configurations and why we are working hard to parse this information at scale in Advanced WildFire. Reverse engineering variants of each malware family allow us to build out parsers to extract meaningful and relevant data for all of them at scale.

There is a staggering amount of diversity among payloads in the malware landscape, which makes the task of supporting them all more or less impossible. Where possible, we use metrics-based approaches to prioritize focus on the malware families and variants most relevant to our customers. In this ongoing area of research, our team will continue to expand support for new malware families and variants.

Palo Alto Networks customers receive protections from threats such as those discussed in this post with Advanced WildFire.

Indicators of Compromise

05a3a84096bcdc2a5cf87d07ede96aff7fd5037679f9585fee9a227c0d9cbf51

Additional Resources

Updated May 17, 2023, at 6:00 a.m. PT.

Network Security Trends: November 2022-January 2023

Posted on by Samantha Stallings

Executive Summary

Recent observations of exploits used in the wild November 2022-January 2023 reveal that attackers have been using newly published remote code execution vulnerabilities in the following three products:

  • Roxy-WI, a web interface for managing and monitoring RoxyDNS
  • CWP, a free web hosting control panel (aka Control Web Panel or CentOS Web Panel)
  • Cacti, an open-source network monitoring and graphing tool used to track the performance of various network devices, servers and applications

Additionally, attackers have also been taking advantage of a traversal and information disclosure vulnerability in ThoughtWorks GoCD to read sensitive files stored on servers.

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 6,169 newly published vulnerabilities, a large portion (almost 11%) involves cross-site scripting.
  • Lists of major vulnerabilities identified by evaluating more than 276 million attack sessions including code execution, 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 November 2022-January 2023.
  • 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, Cloud-Delivered Security Services and Prisma Cloud WAAS, including Threat Prevention, WildFire, Advanced URL Filtering and Cortex XDR.

CVEs Discussed CVE-2022-27924, CVE-2022-31137, CVE-2022-44877, CVE-2022-46169, CVE-2021-43287, CVE-2021-31602, CVE-2021-22005, CVE-2021-33035, CVE-2022-30136. CVE-2022-1118
Types of Attacks and Vulnerabilities Covered Cross-site scripting, information disclosure, buffer overflow, code execution, SQL injection, traversal, command injection, improper authentication, security feature bypass
Related Unit 42 Topics Network Security Trends, exploits in the wild, attack analysis

Analysis of Published Vulnerabilities, November 2022-January 2023

From November 2022-January 2023, a total of 6,169 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 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 1,100 17.8% -1.1% 3% +0.1%
High 2,339 37.9% -4.2% 3.1% +0.9%
Medium 2,730 44.3% +5.3% 2.2% -0.1%

Table 1. Severity distribution for CVEs registered November 2022-January 2023, including only those rated Medium-Critical.

Image 1 is a pie chart measuring the distribution of critical, high, and medium CVEs registered through August and September of 2022. The largest percent is “high” at 37.9%.
Figure 1. Severity distribution for CVEs registered November 2022-January 2023, 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.

Vulnerability Category Distribution

It is crucial to understand each type of vulnerability and its consequences. Out of the newly published CVEs that were analyzed, 22.6% are classified as local vulnerabilities, requiring prior access to compromised systems, while the remaining 77.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.

Image 2 is a stacked bar chart showing the vulnerability category distribution for CVEs registered through November 2022 to January 2023. Medium has the largest portion in yellow for cross-site scripting.
Figure 2. Vulnerability category distribution for CVEs registered November 2022-January 2023.

Cross-site scripting remains the most reported vulnerability from November 2022-January 2023. We also saw that the prevalence of cross-site scripting vulnerabilities increased during this time, and the majority of the vulnerabilities in this category are ranked Medium. Code execution and information disclosure vulnerabilities decreased. Most of the recently published cross-site scripting and information disclosure vulnerabilities are at Medium severity (rather than Critical).

Figure 3. Vulnerability category distribution compared with the previous quarter.

This quarter, we have observed an increase in cross-site scripting vulnerabilities compared to last quarter. Cross-site scripting is a classic attack vector that is still very popular today. We have also observed a slight increase in denial-of-service vulnerabilities, while code execution vulnerabilities have decreased slightly.

Network Security Trends: Analysis of Exploits in the Wild, November 2022-January 2023

Data Collection

By leveraging Palo Alto Networks Next-Generation Firewalls as sensors on the perimeter, Unit 42 researchers observed malicious activities from November 2022-January 2023. 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 276 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 276 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.

Image 4 is a pie chart measuring attack severity distribution of critical, high, and medium CVEs registered through November 2022 to January 2023. The largest percent is “Critical” at 42.5%.
Figure 4. Attack severity distribution, November 2022-January 2023, including only Medium through Critical vulnerabilities.

Figure 4 shows the session count and ratio of attacks grouped by the severity of each vulnerability. Compared with the previous quarters' severity distribution, this quarter shows a decrease in Critical attacks, because attacks against CVE-2021-35394 decreased.

We focus more on Critical-severity attacks because of their greater potential impact. Although there has been a decline, the vulnerabilities rated as Critical are still exploited the most, because attackers typically leverage more severe vulnerabilities for exploits. Defenders should prioritize preventing and mitigating High-severity and Critical-severity network attacks.

Image 5 is a column chart showing the vulnerability severity distribution for CVEs registered through November 2022 to January 2023 compared to the previous quarter, showing a decrease in Critical and a rise in High and Medium.
Figure 5. Vulnerability severity distribution compared with the previous quarter.

When Did the Network Attacks Occur?

Image 6 is a column chart comparing the net work attacks occurred across critical hot, high, medium, and then showing the total, by week.
Figure 6. Severity of exploits in the wild measured weekly from November 2022-January 2023.

During November 2022-January 2023, attackers increased their exploitation of Critical-severity vulnerabilities starting in January, and the number of attacks against High-severity and Medium-severity vulnerabilities gradually increased. Note, 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-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.

Image 7 is a bar chart showing by month and week the observed attacks in which the exploited CVE was disclosed. Included CVEs are CVEs from 2021 to 2022, yellow, 2019 to 2020, solid red, 2016 to 2018, dashed blue, 2010 to 2016, dotted green and before 2010, orange.
Figure 7. Observed attacks broken down by the year in which the exploited CVE was disclosed, measured weekly from November 2022-January 2023.

Exploits in the Wild, November 2022-January 2023: A Detailed View

Among the latest published attacks, the following exploits stood out due to their PoC availability, severity and ease of exploitation. We have provided snippets showing how attackers used open-source tools to compromise the different targets, allowing defenders to better understand how the exploit operates.

CVE-2022-27924

This is a vulnerability that allows attackers to inject malicious commands and sniff sensitive information. This is accomplished by poisoning the IMAP route cache entries in the memcached server. This server is used to query Zimbra users and push their HTTP requests to the appropriate backend service.

Figure 8 is a screenshot of a code snippet detailing the Zimbra remote code execution. I
Figure 8. CVE-2022-27924.

CVE-2022-31137

Roxy-WI is a web interface used to manage HAProxy, NGINX and Keepalived servers. This vulnerability allows attackers to construct malicious requests, execute arbitrary commands without logging in and control the server.

Figure 9 is a screenshot of a code snippet detailing the Roxy-WI web interface vulnerability.
Figure 9. CVE-2022-31137.

CVE-2022-44877

Control Web Panel (CWP) is a popular web hosting platform. This vulnerability exists in the /login/index.php component, allowing an unauthenticated attacker to execute arbitrary system commands through crafted HTTP requests.

Figure 10 is a screenshot of a code snippet detailing the Control Web Panel web who platform vulnerability. The vulnerability is part of the login index.php component.
Figure 10. CVE-2022-44877.

CVE-2022-46169

Cacti is an open-source platform for operational monitoring and a fault management framework. Due to a verification flaw in the remote_agent.php file, an unauthenticated attacker can bypass authentication by setting the variable at the beginning of HTTP_ to the host name of the Cacti server, to achieve command execution.

Figure 11 is a screenshot of vulnerability in Cacti, an open source platform. There is a verification flaw in the remote_agent.php file.
Figure 11. CVE-2022-46169.

CVE-2021-43287

ThoughtWorks GoCD is an open source build and release tool. An unauthenticated attacker could exploit this vulnerability to obtain all secrets known to the GoCD server.

Figure 13 is a screenshot of a code snippet detailing the ThoughtWorks GoCD vulnerability.
Figure 13. CVE-2021-43287.

CVE-2021-31602

Pentaho is business intelligence software that provides data-related services. An attacker could exploit a vulnerability where the default configuration allows them to extract pieces of information without valid credentials.

Figure 14 is a screenshot of a code snippet detailing the Pentaho vulnerability of of the default configuration.
Figure 14. CVE-2021-31602.

CVE-2021-22005

vCenter is virtual server management software by VMware. An unauthenticated remote attacker could exploit this vulnerability by uploading a crafted forged file to an affected vCenter Server deployment to transform commands and software. The whole attack process is very simple and does not require any user interaction.

Figure 15 is a screenshot of a code snippet detailing the vCenter exploit.
Figure 15. CVE-2021-22005.

CVE-2021-33035

This is a vulnerability in Apache OpenOffice, an open-source office software suite. The vulnerability opens dBase/DBF documents and displays the contents as a spreadsheet. When the DBF (a database file where data is organized by fields) data is read, the size of some fields is not checked. The data is copied into local variables. This vulnerability could be exploited by a malicious file opened by the software, executing malware on the machine.

Figure 16 is a screenshot of a code snippet detailing the Apache OpenOffice code.
Figure 16. CVE-2021-33035.

CVE-2022-30136

This is a remote code execution vulnerability in Windows Network File System due to improper handling of NFSv4 requests. An unauthenticated attacker could exploit this bug to execute arbitrary code in the context of SYSTEM1.

Figure 17 is a screenshot of a code snippet detailing the Windows Network File System remote code execution vulnerability.
Figure 17. CVE-2022-30136.

CVE-2022-1118

This vulnerability exists in Connected Components Workbench, ISaGRAF Workbench, and Safety Instrumented System Workstation because there is no restriction on the objects that can be deserialized.

Figure 18 is a screenshot of a code snippet detailing the vulnerability in Connected Components Workbench, ISaGRAF Workbench, and Safety Instrumented System Workstation.
Figure 18. CVE-2022-1118.

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 highest. Traversal and information disclosure vulnerabilities were the second and third most popular attacks of the quarter. Both of these types of vulnerabilities can be exploited by attackers to obtain sensitive information. Attackers typically aim to gain maximum information from and control over the systems they target.

Figure 19 a stacked bar chart showing the attack category and severity of critical, high, and medium CVEs from November 2022 to January 2023. Remote code execution far outranks any other at 127 million.
Figure 19. Attack category and severity, November 2022-January 2023.

Compared with the previous quarter, most categories of attacks have increased. The number of remote code execution attacks has decreased, possibly due to a decrease in attacks against CVE-2021-35394. However, we have observed an increase in traversal, information disclosure and SQL injection vulnerabilities. These four types of vulnerabilities are frequently exploited by attackers.

We have also observed an increase in the use of hack tools, especially FFuF (often used for identifying security vulnerabilities in web applications by fuzzing them with a large number of test cases) and Nmap (often used for network exploration and discovery by scanning hosts and services on a network and creating a map of the network topology).

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 France and then Germany. Attacks from Vietnam decreased significantly this quarter. That may be because almost all attacks from Vietnam last quarter were against CVE-2021-35394, and the attacker stopped or changed attack source location this quarter.

We recognize that attackers might leverage proxy servers and VPNs located in those countries to hide their actual physical locations.

Figure 20 is a chart showing the percentage by country of attack origins from November 2022 to January 2023. The highest is the United States at 74.4%. The second highest is others at 8.9%.
Figure 20. Locations ranked in terms of how frequently they were the origin of observed attacks from November 2022-January 2023.
Figure 21 is a column chart showing the CVE attack origin distribution compared to the previous quarter, where the United States has increased by 22.66%.
Figure 21. Attack origination comparison between August 2022-October 2022 and November 2022-January 2023.

It is worth noting that Luxembourg and Switzerland, where there were not many attacks last quarter, saw a lot of attacks in this quarter. Let’s look more closely at the attacks from these two places.

There were about 31,000 attacks originating from Luxembourg in November 2022, which is a relatively high level. From December 2022-January 2023, the number of attacks from Luxembourg rose from about 2.2 million to 5.8 million, showing a rapid growth rate.

Unlike Luxembourg, attacks originating from Switzerland were at about 2.1 million and 1.2 million in November and December 2022, respectively, and then they dropped sharply to about 730,000 in January 2023.

We also observed that in this quarter, among all the attacks from Luxembourg, the number of attacks targeting CVE-2021-35394 reached 7.77 million. This accounted for 96% of the total number of attacks from Luxembourg.

About 1.9 million attacks from Switzerland were aimed at the Code Execution of Netis/Netcore Router vulnerability. This accounted for 45% of their total attacks.

From this evidence, we can conclude that the current attacks on hardware devices, especially network devices, are very active.

Figure 22 is a heat map of the attack geolocation distraction from November 2022 to January 2023. The darkest area of the map is the United States.
Figure 22. Attack geolocation distribution from November 2022-January 2023.

Conclusion

The vulnerabilities disclosed from November 2022-January 2023 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.

While cybercriminals will never cease their malicious activities, Palo Alto Networks customers receive protections from the attacks discussed in this blog through the Next-Generation Firewall and Cloud-Delivered Security Services, including Threat Prevention, WildFire and Advanced URL Filtering, as well as through Cortex XDR. Prisma Cloud customers using WAAS are protected from such threats through the App Firewall feature, which detects attacks such as cross-site scripting, SQL injection, directory traversals and more.

To further mitigate any risks to your network:

  • Run a Best Practice Assessment 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 8686 and above).

Additional Resources

 

Get the latest news, invites to events, and threat alerts

Default Heading

Read the article Right Arrow