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.
Unit 42 researchers identified FabricScape (CVE-2022-30137), a vulnerability of important severity in Microsoft’s Service Fabric – commonly used with Azure – that allows Linux containers to escalate their privileges in order to gain root privileges on the node, and then compromise all of the nodes in the cluster. The vulnerability could be exploited on containers that are configured to have runtime access, which is granted by default to every container.
Using a container under our control to simulate a compromised workload, we were able to exploit the vulnerability on Azure Service Fabric, which is an Azure offering that deploys private Service Fabric clusters in the cloud. A few other exploitation attempts on Azure's offerings that are powered by managed multi tenant Service Fabric clusters have failed as Microsoft disables runtime access on containers of those offerings.
We worked closely with Microsoft (MSRC) to remediate the issue, which was fully fixed on June 14, 2022. Microsoft released a patch to Azure Service Fabric that has already mitigated the issue in Linux clusters, and also updated internal production environments of offerings and products that are powered by Service Fabric.
We advise customers running Azure Service Fabric without automatic updates enabled to upgrade their Linux clusters to the most recent Service Fabric release. Customers whose Linux clusters are automatically updated do not need to take further action.
Both Microsoft and Palo Alto Networks recommend avoiding execution of untrusted applications in Service Fabric. See Service Fabric documentation for more information.
While we're not aware of any attacks in the wild that have successfully exploited this vulnerability, we want to urge organizations to take immediate action to identify whether their environments are vulnerable and quickly implement patches if they are.
Service Fabric is an application hosting platform that supports different forms of packaging and managing services, including, but not limited to containers.
Microsoft had previously published documentation that Service Fabric is being used in many core Azure services:
Figure 1. A partial list of services powered by Service Fabric (as of 2019).
In 2016, in light of Service Fabric's success in internal environments, Microsoft released Azure Service Fabric as a platform as a service, allowing customers to create and manage their own dedicated Service Fabric clusters in Azure Cloud. It’s widely used by enterprises across a variety of sectors including government, media, automotive, fashion, transportation and multinational conglomerates.
Service Fabric Architecture
A general understanding of the basic architecture of Service Fabric is required in order to understand the full impact of FabricScape, so we’ll start with a quick overview of Service Fabric architecture.
A Service Fabric cluster consists of many nodes as each one runs a container engine that executes the desired containerized applications, just like Kubernetes. It supports Linux and Windows nodes and uses Docker on both while supporting Hyper-V isolation mode in Windows nodes for maximum isolation. When deploying an application into a Service Fabric cluster, Service Fabric will deploy the application as containers according to the application manifest.
Under the hood every node runs multiple components, allowing multiple nodes to work in synergy and form a reliable and distributed cluster. There is almost no public documentation about these components, but Microsoft released Service Fabric version 6.4 source code in 2018, and that allowed the public to read the code and understand the components' purposes and operations.
Figure 2. Service Fabric Linux node example.
The Vulnerability
Service Fabric supports deploying applications as containers, and during each container initialization, a new log directory is created and mounted into each container with read and write permission. All of those directories are centralized in one path on every node. For example, in Azure Service Fabric offering, those directories are at /mnt/sfroot/log/Containers.
One of Service Fabric's components is the Data Collection Agent (DCA). Among other things, it is responsible for collecting the logs from those directories to be processed later. In order to access the directories, it needs high privileges and therefore runs as root on every node.
At the same time, it handles files that could be modified by containers. Thus, exploiting a vulnerability in the agent's mechanism that handles these files could result in a container escape and gaining root on the node. This could happen, for example, if the user runs a malicious container or package, or if a container is taken over by an attacker.
By digging into DCA's old source code, we noticed a potential race-conditioned arbitrary write in the function GetIndex (PersistedIndex.cs:48).
This function reads a file, checks that the content is in the expected format, modifies some of the content and overwrites the file with the new content.
In order to do so, it uses two sub-functions:
LoadFromFile – reads the file.
SaveToFile – writes the new data to the file.
Figure 3. GetIndex function.
This functionality results in a symlink race. An attacker in a compromised container could place malicious content in the file that LoadFromFile reads. While it continues to parse the file, the attacker could overwrite the file with a symlink to a desirable path so that later SaveToFile will follow the symlink and write the malicious content to that path.
As DCA runs as root on the node file system, it will follow the symlink and overwrite files in the node file system.
Exploitation of CVE-2022-30137
In order to exploit the issue, an attacker needs to trigger DCA to run the vulnerable function on a file that it controls. DCA monitors the creation of specific filenames in the log directories we mentioned above, and executes different functionality for each file. One of those files is ProcessContainerLog.txt.
Figure 4. ProcessContainerLog documentation in the code.
When DCA identifies that this file was created, it executes a function that eventually runs GetIndex numerous times on paths inside the log directory, which the container can modify.
Figure 5. Monitoring ProcessContainerLog.
This means that a malicious container could trigger the execution of GetIndex on a file that it controls and try to beat the race condition in order to overwrite any path on the node filesystem.
In order to beat it consistently, we changed the malicious file to weigh 10 MB, so that it will take LoadFromFile a considerable amount of time to parse it, giving us sufficient time to overwrite it with a symlink and beat the race every single time.
At this point, we were able to exploit GetIndex from the context of the container and overwrite any file on the node.
While this behavior can be observed on both Linux containers and Windows containers, it is only exploitable in Linux containers because in Windows containers unprivileged actors cannot create symlinks in that environment.
From now on, we will focus on the exploitation of a Linux node (Ubuntu 18.04) in order to gain code execution on the node.
None of these techniques is applicable in this case since the write primitive to the node filesystem is weak because of two reasons:
GetIndex modifies internal Service Fabric files and therefore verifies that the file (payload content) is in the right internal format before continuing to SaveToFile.
The overwritten file on the node file system doesn't have execution permissions.
Figure 6. Example of the internal format.
After some digging, we figured out that the format is very similar to the format of files that contain environment variables.
Figure 7. Malicious file example.
We choose to use /etc/environment for the exploitation as it contains environment variables specifying the basic environment variables for new shells but can be used by other programs. After some research, we found out that every executed job in the Linux task scheduler (cron) imports this file, and luckily, there is a job that is executed every minute by root on every node, meaning we could inject malicious environment variables into new processes that run as root on the node.
After digging deeper, we found that having jobs on the scheduler is not necessary for exploitation since cron executes an internal hourly job as root, which could be exploited.
Figure 8. The cron job that is executed every minute.
In order to gain code execution, we used a technique called dynamic linker hijacking. We abused the LD_PRELOAD environment variable. During the initialization of a new process, the linker loads the shared object that this variable points to, and with that, we inject shared objects to the privileged cron jobs on the node.
We wrote a dummy shared object with a function that initiates a reverse shell and added a construction attribute so that when the shared object is loaded, it will initiate a reverse shell automatically. We compiled the shared object and copied it to the log directory in the container so that we could point LD_PRELOAD to the object path.
One minute after exploitation, we got a reverse shell in the context of root on the node.
Figure 9. Exploitation flow.
We tested this exploitation successfully on the Azure Service Fabric offering using the latest version available at that time (8.2.1124.1), on both Ubuntu 16.04 and 18.04. We were able to beat the race condition consistently and successfully break out and execute code on the node every single time.
Cluster Takeover
Microsoft provides users an easy way to manage and interact with their Service Fabric clusters by using the sfctl CLI tool.
Figure 10. Sfctl subcommands.
In order to interact and manage a cluster, users need to provide sfctl two arguments:
The cluster endpoint address.
A private certificate.
When executing a command, sfctl sends requests to a REST API in the cluster and uses the certificate for authentication. This API can perform many functionalities and provides a way to manage the cluster remotely. It listens on port 19080 by default in the Azure Service Fabric offering and is open to the internet so that users would be able to access it.
Figure 11. Selecting a cluster using sfctl.
Besides the API, this endpoint has a graphical interface that can be accessed by browsers if the private certificate is applied. This interface is called Service Fabric Explorer, and it is used as a graphical way to manage and analyze the cluster.
Figure 12. Service Fabric Explorer index page.
After gaining root privileges on the node by exploiting CVE-2022-30137, we explored the file system and found the directory /var/lib/waagent/ contains sensitive files, including the certificate that controls the whole cluster.
By applying the compromised certificate, we were able to authenticate to any of the REST API endpoints (and the load balancer) and send requests to trigger functionalities in the cluster.
We were able to use the certificate to run sfctl and manage the cluster, or even browse to the Service Fabric Explorer.
Figure 13. Testing the compromised certificate.
Broader Impact of FabricScape
Microsoft does not publicly disclose what offerings are powered by Service Fabric but does provide a partial list as shown in Figure 1.
This means that if a malicious actor gains control over a container in Service Fabric, it would be possible to compromise the whole cluster as demonstrated above.
Limitations
A Service Fabric cluster is single-tenant by design, and hosted applications are considered trusted. They are therefore able to access the Service Fabric runtime data by default. This access allows the applications to read data regarding their Service Fabric environment and write logs to specific locations. In order to exploit FabricScape, the compromised container must have runtime access because that is necessary for the logs directory to be accessible. If developers consider their applications as untrusted or if the cluster is multitenant, this access can be disabled for each application on the cluster separately by modifying each application manifest and setting RemoveServiceFabricRuntimeAccess to true.
Other than our successful exploitation in Azure Service Fabric, we tested Azure Container Instances, Azure PostgreSQL and Azure Functions. All of these services can be deployed in a serverless plan and are powered by multitenant Service Fabric clusters.
We could not exploit FabricScape over those services since Azure disabled the runtime access on those services.
Disclosure and Mitigations
We disclosed the vulnerability, including a full operational exploit, to Microsoft on Jan. 30, 2022.
Microsoft released a fix for the issue on June 14, 2022.
We advise that customers running Azure Service Fabric without automatic updates enabled should upgrade their Linux clusters to the most recent Service Fabric release. Customers whose Linux clusters are automatically updated do not need to take further action.
Customers that use other Azure offerings that are based on managed Service Fabric clusters are safe as Microsoft has updated its software.
Conclusion
As the trend of migrating to the cloud grows exponentially, the cloud ecosystem adapts and reinvents itself constantly to keep up with demand by developing new technologies.
As part of a Palo Alto Networks commitment to improving public cloud security, we actively invest in researching such technologies and report issues to the vendors in order to keep customers and users safe.
Unit 42 has discovered Zloader and BazarLoader samples that had interesting implementations of a sandbox evasion technique. This blog post will go into details of the unique implementations of API Hammering in these types of malware. API Hammering involves the use of a massive number of calls to Windows APIs as a form of extended sleep to evade detection in sandbox environments.
Sandboxing is a popular technique used to detect if a sample is malicious. A sandbox analyzes the behaviors of the binary as it executes inside a controlled environment. Sandboxes have to deal with many challenges while analyzing a large number of binaries with limited computing resources. Malware sometimes abuses these challenges by “sleeping” in the sandbox before carrying out malicious procedures to hide its real intentions.
Palo Alto Networks customers receive protections from malware families using evasion techniques through Cortex XDR or the Next-Generation Firewall with WildFire and Threat Prevention security subscriptions.
The most common way for malware to sleep is to simply call the Windows API function Sleep. A sneakier way that we often see is the Ping Sleep technique where the malware constantly sends ICMP network packets to an IP address (ping) in a loop. To send and receive such useless ping messages takes a certain amount of time, thus the malware indirectly sleeps. However, all these methods are easily detected by many sandboxes.
What Is API Hammering?
API Hammering has been a known sandbox bypass technique that is sometimes used by malware authors to evade sandboxes. We’ve recently observed Zloader – a dropper for multiple types of malware – and the backdoor BazarLoader using new and unique implementations of API Hammering to remain stealthy.
API Hammering consists of a large number of garbage Windows API function calls. The execution time of these calls delays the execution of the real malicious routines of the malware. This allows the malware to indirectly sleep during the sandbox analysis process.
API Hammering in BazarLoader
An older variant of BazarLoader made use of a fixed number (1550) of printf function calls to time out malware analysis. While analyzing a newer version of BazarLoader, we found a new and more complex implementation of API Hammering.
The following decompiled procedure shows how this new variant is implemented in the BazarLoader sample we analyzed. It makes use of a huge loop with a random count that repeatedly accesses a list of random registry keys in Windows.
Figure 1. API Hammering loop in BazarLoader.
To generate the random loop count and list of registry keys, the sample reads the first file from the System32 directory that matches a defined size. This file is then encoded (see Figure 2) to remove most of its null bytes. The random count is then computed based on the offset of the first null byte in that file. The list of random registry keys are generated from fixed length chunks from the encoded file.
Figure 2. Encoding the selected file in BazarLoader.
With a different Windows version (Windows 7, 8, etc.) and a different set of applied updates, there is also a different set of files in the System32 directory. This results in a varying loop count and list registry keys used by BazarLoader when executed in different machines.
The API Hammering function is located in the packer of the BazarLoader sample (see Figure 3). It delays the payload unpacking process to evade detection of the aforementioned. Without completing the unpacking process, the BazarLoader sample would appear to be just accessing random registry keys, a behavior that can be also seen in many legitimate types of software.
Figure 3. API Hammering delaying unpacking process in BazarLoader.
API Hammering in Zloader
While the BazarLoader sample relied on a loop to carry out API Hammering, Zloader uses a different approach. It does not require a huge loop, but instead consists of 4 large functions which contain nested calls to multiple other smaller functions (see Figure 4).
Figure 4. One of the large functions responsible for API Hammering in ZLoader.
Inside each of these small procedures are four API function calls related to file I/O. The functions are GetFileAttributesW, ReadFile, CreateFileW and WriteFile (see Figure 5).
Figure 5. One of the small functions responsible for API Hammering in ZLoader.
By using a debugger, we could figure out the number of calls made to four file I/O functions (see Figure 6). The large and smaller functions together generate more than a million function calls in total, without the use of a single large loop as seen in BazarLoader.
Figure 6. Debugger log for APIs responsible for API Hammering in ZLoader.
The following table shows the API function call counts made during our analysis process:
I/O API function
Total Call Count
ReadFile
278,850
WriteFile
280,921
GetFileAttributesW
113,389
CreateFileW
559,771
Table 1. API function call counts.
The execution time of the four large functions delays the injection of the Zloader payload. Without complete execution of these functions, the sample would appear to be a benign sample just carrying out file I/O operations.
The following disassembled code shows the four API hammering procedures followed by the injection procedures:
Figure 6. API Hammering before payload injection in ZLoader.
Conclusion: WildFire vs API Hammering
Results from analyzing various implementations of API Hammering enabled the detection of malware samples using API Hammering for sandbox evasion in WildFire. WildFire detects the use of API Hammering by BazarLoader, Zloader, and other malware families.
The following excerpt from the WildFire report of our BazarLoader sample shows the detected entry for API Hammering.
Figure 7. WildFire detected API Hammering along with other behaviors in a Bazarloader sample.
Palo Alto Networks customers receive further protections against other malware families using similar sandbox evasion techniques through Cortex XDR or our Next-Generation Firewall with WildFire and Threat Prevention security subscriptions.
In recent years, one of the most common classes of elevation-of-privilege vulnerabilities is file system redirection attacks. This class abuses the fact that a privileged component, such as a Windows service, operates on files or directories that are writable by unprivileged users. By using different types of file system links, such as hard links or junctions, attackers can trick the privileged component into operating on files it didn’t intend to. The end goal for such attacks is usually to write an attacker-supplied executable (such as a DLL or a script) to disk, and to get it executed with system permissions.
This piece explains junctions and how threat actors use them in file system redirection attacks, then explores a developing mitigation.
Palo Alto Networks customers receive protections from Cortex XDR against exploits for different types of file system redirection attacks.
What Are Junctions?
Junctions are a feature of the NT file system (NTFS) that make it possible to link one directory into another. They are used by default, linking some directories such as C:\Documents and Settings.
Figure 1. Example of junction in use.
In 2019, Microsoft introduced a mitigation that requires the creator of hard links to have write access to those links’ targets. Since then, junctions became the way to go for attackers when exploiting file system redirection attacks.
A common vulnerable pattern is usually as follows:
A privileged service exposes functionality that can be triggered through some interprocess communication (IPC) mechanism, such as remote procedure call (RPC). That functionality can be triggered by users running at lower privilege levels.
That functionality operates on a file (e.g. writing data into that file) that is located under a globally writable directory. The operation is done without impersonation, meaning it occurs with the permissions of that system service.
To exploit such bugs, the attacker first creates a junction between that directory and their target, which is usually C:\Windows or one of its subdirectories. Next, the attacker triggers the RPC call, which follows the junction to overwrite a system DLL file. Finally, that malicious DLL is loaded by some service, and the attacker’s supplied code gets executed with system permissions.
Figure 2. Example of a file system redirection attack.
Redirection Trust Mitigation
Microsoft announced they are going to ship a mitigation for this bug class in David Weston’s talk at BlueHat IL 2020 – “Keeping Windows Secure.” However, this mitigation only appeared on recent Windows 10 builds, so I decided to reverse engineer it and explore how it works.
Figure 3. Screenshot from a presentation called “Keeping Windows Secure,” given at BlueHat IL 2020.
How Redirection Trust Works
The mitigation is fairly simple and follows the guidelines presented at Microsoft’s BlueHat talk. Its goal is to mark junctions created by unprivileged, medium-integrity actors, and prevent privileged processes from following them.
Every time a junction is created, ntfs.sys calls nt!IoComputeRedirectionTrustLevel to compute the caller’s trust level. The level is determined based on the caller’s token – either the impersonation token (if present) or the primary token. Later, it sets that value into that junction file control block’s standard information.
Figure 4. ntoskrnl.exe 10.0.19041[.]1645Currently, there are only two trust levels:
Level 1 – Indicating the junction was created by a medium-integrity actor.
Level 2 – Indicating the junction was created by a privileged actor (administrator, system or kernel).
To complete the mitigation, the trust level is verified before following junctions. This is done only if the mitigation is enabled, which is controlled by a new process mitigation policy – ProcessRedirectionTrustPolicy. That policy has two modes: audit or enforce.
Figure 5. New struct added to winnt.h header.
When SetProcessMitigationPolicy is called with the relevant arguments, it ends up calling nt!PspSetRedirectionTrustPolicy. This enables the mitigation on the process’s primary token.
Figure 6. Enabling the mitigation.
Finally, when ntfs.sys goes through a junction redirection, it verifies it against the caller’s token using nt!IoCheckRedirectionTrustLevel. This means that when a privileged service operates with its own system privileges, untrusted junctions are not followed. Failed redirects end up with error 0xc00004be – “The path cannot be traversed because it contains an untrusted mount point.”
Is the Mitigation Enabled?
After reverse engineering the mitigation, I wanted to check whether it is enabled on the current Windows build, and in which mode. I created a sample app that queries the state of all running processes (using GetProcessMitigationPolicy), and found out that the mitigation is currently only enabled in audit mode for several services. Hopefully, in the near future, Microsoft will enable it in enforce mode.
Figure 7. Redirection trust policy enablement.
Conclusion
In the last few years, Microsoft has pushed numerous mitigations to address file system redirection attacks. It is important to explore them and assess their effectiveness, trying to identify gaps and conditions where bugs can still be exploitable.
Palo Alto Networks Cortex XDR already has many protections in place to prevent exploits for different types of file system redirection attacks, and was proven to prevent such attacks in the wild.
Unit 42 recently identified a new, difficult-to-detect remote access trojan named PingPull being used by GALLIUM, an advanced persistent threat (APT) group.
Unit 42 actively monitors infrastructure associated with several APT groups. One group in particular, GALLIUM (also known as Softcell), established its reputation by targeting telecommunications companies operating in Southeast Asia, Europe and Africa. The group’s geographic targeting, sector-specific focus and technical proficiency, combined with their use of known Chinese threat actor malware and tactics, techniques and procedures (TTPs), has resulted in industry assessments that GALLIUM is likely a Chinese state-sponsored group.
Over the past year, this group has extended its targeting beyond telecommunication companies to also include financial institutions and government entities. During this period, we have identified several connections between GALLIUM infrastructure and targeted entities across Afghanistan, Australia, Belgium, Cambodia, Malaysia, Mozambique, the Philippines, Russia and Vietnam. Most importantly, we have also identified the group’s use of a new remote access trojan named PingPull.
PingPull has the capability to leverage three protocols (ICMP, HTTP(S) and raw TCP) for command and control (C2). While the use of ICMP tunneling is not a new technique, PingPull uses ICMP to make it more difficult to detect its C2 communications, as few organizations implement inspection of ICMP traffic on their networks. This blog provides a detailed breakdown of this new tool as well as the GALLIUM group's recent infrastructure.
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.
PingPull was written in Visual C++ and provides a threat actor the ability to run commands and access a reverse shell on a compromised host. There are three variants of PingPull that are all functionally the same but use different protocols for communications with their C2: ICMP, HTTP(S) and raw TCP. In each of the variants, PingPull will create a custom string with the following structure that it will send to the C2 in all interactions, which we believe the C2 server will use to uniquely identify the compromised system:
PROJECT_[uppercase executable name]_[uppercase computer name]_[uppercase hexadecimal IP address]
Regardless of the variant, PingPull is capable of installing itself as a service with the following description:
Provides tunnel connectivity using IPv6 transition technologies (6to4, ISATAP, Port Proxy, and Teredo), and IP-HTTPS. If this service is stopped, the computer will not have the enhanced connectivity benefits that these technologies offer.
The description is the exact same as the legitimate iphlpsvc service, which PingPull purposefully attempts to mimic using Iph1psvc for the service name and IP He1per instead of IP Helper for the display name. We have also seen a PingPull sample use this same service description but with a service name of Onedrive.
The three variants of PingPull have the same commands available within their command handlers. The commands seen in Table 1 show that PingPull has the ability to perform a variety of activities on the file system, as well as the ability to run commands on cmd.exe that acts as a reverse shell for the actor.
Command
Description
A
Enumerate storage volumes (A: through Z:)
B
List folder contents
C
Read File
D
Write File
E
Delete File
F
Read file, convert to hexadecimal form
G
Write file, convert from hexadecimal form
H
Copy file, sets the creation, write, and access times to match original files
I
Move file, sets the creation, write, and access times to match original files
J
Create directory
K
Timestomp file
M
Run command via cmd.exe
Table 1. Commands available in PingPull’s command handler.
To run a command listed in Table 1, the actor would have the C2 server respond to a PingPull beacon with the command and arguments that it encrypts using AES in cipher block chaining (CBC) mode and encodes with base64. We have seen two unique AES keys between the known PingPull samples, specifically P29456789A1234sS and dC@133321Ikd!D^i.
PingPull would decrypt the received data and would parse the cleartext for the command and additional arguments in the following structure:
We are not sure of the purpose of the z0 parameter in the command string, as we observed PingPull parsing for this parameter but do not see the value being used. To confirm the structure of the command string, we used the following string when issuing commands in our analysis environment, which would instruct PingPull to read the contents of a file at C:\test.txt:
&P29456789A1234sS=C&z0=2&z1=c:\\test.txt&z2=none
During our analysis, PingPull would respond to the command string above with ya1JF03nUKLg9TkhDgwvx5MSFIoMPllw1zLMC0h4IwM=, which decodes to and decrypts (AES key P29456789A1234sS) to some text in a test file.\x07\x07\x07\x07\x07\x07\x07, which is the content (PKCS5_PADDING-padded) of the file C:\test.txt on our analysis system.
ICMP Variant
PingPull samples that use ICMP for C2 communications issue ICMP Echo Request (ping) packets to the C2 server. The C2 server will reply to these Echo requests with an Echo Reply packet to issue commands to the system. Both the Echo Request and Echo Reply packets used by PingPull and its C2 server will have the same structure as follows:
[8-byte value]R[sequence number].[unique identifier string beginning with “PROJECT”]\r\ntotal=[length of total message]\r\ncurrent=[length of current message]\r\n[base64 encoded and AES encrypted data]
When issuing a beacon to its C2, PingPull will send an Echo Request packet to the C2 server with total and current set to 0 and will include no encoded and encrypted data, as seen in Figure 1.
Figure 1. PingPull ICMP beacon example with hardcoded 8-byte value.
The data section in the ICMP packet in Figure 1 begins with an 8-byte value of 0x702437047E404103 (\x03\x41\x40\x7E\x04\x37\x24\x70) that PingPull has hardcoded in its code, which is immediately followed by a hardcoded R. However, another PingPull sample that used ICMP for its C2 communications omitted this 8-byte value, as seen in Figure 2.
Figure 2. PingPull ICMP beacon example without hardcoded 8-byte value.
After the R is a sequence number that increments when sending or receiving data that exceeds the maximum size of the ICMP data section. The sequence number is immediately followed by a period “.” and then the unique identifier string generated by PingPull that begins with PROJECT. The ICMP data section then includes total=[integer] and current=[integer], which are used by both PingPull and its C2 to determine the total length of the data transmitted and the length of the chunk of data transmitted in the current packet. The data transmitted in each ICMP packet comes in the form of a base64-encoded string of ciphertext generated using AES and the key specific to the sample. This encoded and encrypted data comes after the new line that immediately follows the “current” value. For instance, when responding to our test command, PingPull sent the ICMP Echo Request packet seen in Figure 3 to the C2 server, which has the expected base64-encoded string of ya1JF03nUKLg9TkhDgwvx5MSFIoMPllw1zLMC0h4IwM= for the results of the command.
Figure 3. PingPull responding to command over ICMP.
HTTPS Variant
Another variant of PingPull uses HTTPS requests to communicate with its C2 server instead of ICMP. The initial beacon uses a POST request over this HTTPS channel, using the unique identifier string generated by PingPull as the URL. Figure 4 is an example POST request sent by PingPull as a beacon, where samp.exe was the filename, DESKTOP-U9SM1U2 was the hostname of the analysis system and 172.16.189[.]130 (0xAC10BD82) was the system's IP address.
Figure 4. PingPull HTTPS beacon example.The initial beacon is a POST request that did not have any data, which resulted in the Content-Length of 0 within the HTTP headers. When responding with the results to commands, PingPull will issue a second POST request using the same URL structure with the results in the data section in base64-encoded and encrypted form using the AES key. Figure 5 shows PingPull responding to our test command to read the contents of C:\test.txt with ya1JF03nUKLg9TkhDgwvx5MSFIoMPllw1zLMC0h4IwM= in the data section of the POST request, which decodes and decrypts to some text in a test file.\x07\x07\x07\x07\x07\x07\x07.
Figure 5. PingPull responding with results of a command over HTTPS.
TCP Variant
This variant of PingPull does not use ICMP or HTTPS for C2 communication, rather it uses raw TCP for its C2 communication. Much like the other C2 channels, the data sent in this beacon includes the unique identifier string generated by PingPull that begins with PROJECT. However, the TCP C2 channel begins with a 4-byte value for the length of data that follows, as seen in the following beacon structure:
[DWORD length of data that follows]PROJECT_[uppercase executable name]_[uppercase computer name]_[uppercase hexadecimal IP address]
Figure 6 shows an example of the entire TCP communications channel:
The beacon sent by PingPull in the first red text.
The C2 issuing a command in the blue text.
PingPull responding to the command in the second red text at the bottom of the image.
The beacon seen in Figure 6 begins with a data length of 44-bytes (0x2c), with the unique identifier string generated where samp_f86ebe.exe was the filename, DESKTOP-U9SM1U2 was the hostname of the analysis system and 172.16.189[.]130 (0xAC10BD82) was the system's IP address. The C2 response to the beacon begins with the data length of 64 bytes (0x40) followed by the base64-encoded string that represents the ciphertext of the command. PingPull ran the command supplied by the C2 and sent the results in a packet that begins with a data length of 44 bytes (0x2c), followed by the expected base64-encoded string of ya1JF03nUKLg9TkhDgwvx5MSFIoMPllw1zLMC0h4IwM= for the results of the command.
Infrastructure
On Sept. 9, 2021, a sample of PingPull named ServerMannger.exe (SHA256: de14f22c88e552b61c62ab28d27a617fb8c0737350ca7c631de5680850282761) was shared with the cybersecurity community by an organization in Vietnam. Analysis of this sample revealed that it was configured to call home to t1.hinitial[.]com. Pivoting on the C2, we identified several subdomains hosted under the hinitial[.]com domain that exhibited a similar naming pattern:
Digging deeper into these domains, we began to identify overlaps in certificate use between the various IP infrastructure associated with each of the subdomains. One certificate that stood out in particular was an oddly configured certificate with a SHA1 of 76efd8ef3f64059820d937fa87acf9369775ecd5. This certificate was created with a 10-year expiration window, a common name of bbb, and no other details, which immediately raised the question of legitimacy.
Figure 7. X.509 certificate associated with hinitial[.]com infrastructure.First seen in September 2020, this certificate was linked to six different IP addresses all hosting a variant of the hinitial[.]com subdomains as well as an additional pivot to a dynamic DNS host (goodjob36.publicvm[.]com). Continuing this method of pivoting across all of the PingPull samples and their associated C2 domains has resulted in the identification of over 170 IP addresses associated with this group dating back to late 2020. The most recent IP infrastructure is provided below for defensive purposes.
Protections and Mitigations
We recommend that telecommunications, finance and government organizations located across Southeast Asia, Europe and Africa leverage the indicators of compromise (IoCs) below to identify any impacts to your organizations.
For Palo Alto Networks customers, our products and services provide the following coverage associated with this group:
Cortex XDR detects and protects endpoints from the PingPull malware.
WildFire cloud-based threat analysis service accurately identifies PingPull malware as malicious.
Threat Prevention provides protection against PingPull malware. The “Pingpull Command and Control Traffic Detection” signature (threat IDs 86625, 86626 and 86627) provides coverage for the ICMP, HTTP(S) and raw TCP C2 traffic.
Users of the AutoFocus contextual threat intelligence service can view malware associated with these attacks using the PingPull tag.
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
Conclusion
GALLIUM remains an active threat to telecommunications, finance and government organizations across Southeast Asia, Europe and Africa. Over the past year, we have identified targeted attacks impacting nine nations. This group has deployed a new capability called PingPull in support of its espionage activities, and we encourage all organizations to leverage our findings to inform the deployment of protective measures to defend against this threat group.
Special thanks to the NSA Cybersecurity Collaboration Center, the Australian Cyber Security Centre and other government partners for their collaboration and insights offered in support of 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.
HelloXD is a ransomware family performing double extortion attacks that surfaced in November 2021. During our research we observed multiple variants impacting Windows and Linux systems. Unlike other ransomware groups, this ransomware family doesn’t have an active leak site; instead it prefers to direct the impacted victim to negotiations through TOX chat and onion-based messenger instances.
Unit 42 performed an in-depth analysis of the ransomware samples, the obfuscation and execution from this ransomware family, which contains very similar core functionality to the leaked Babuk/Babyk source code. It was also observed that one of the samples deployed MicroBackdoor, an open-source backdoor allowing an attacker to browse the file system, upload and download files, execute commands, and remove itself from the system. We believe this was likely done to monitor the progress of the ransomware and maintain an additional foothold in compromised systems.
During the analysis of the MicroBackdoor sample, Unit 42 observed the configuration and found an embedded IP address, belonging to a threat actor we believe is potentially the developer: x4k, also known as L4ckyguy, unKn0wn, unk0w, _unkn0wn and x4kme.
Unit 42 has observed x4k in various hacking and non-hacking forums, which has linked the threat actor to additional malicious activity such as:
Cobalt Strike Beacon deployment.
Selling proof-of-concept (PoC) exploits.
Crypter services.
Developing custom Kali Linux distros.
Hosting and distributing malware.
Deployment of malicious infrastructure.
Palo Alto Networks detects and prevents HelloXD and adjacent x4k activity with the following products and services: Cortex XDR and Next-Generation Firewalls (including cloud-delivered security subscriptions such as WildFire).
Due to the surge of this malicious activity, we’ve created this threat assessment for overall awareness.
HelloXD is a ransomware family first observed in the wild on Nov. 30, 2021. This ransomware family uses a modified ClamAV logo in their executables. ClamAV is an open-source antivirus engine used to detect malware. We also have observed additional samples with different versions of the logo, which led us to believe the ransomware developer may like using the ClamAV branding for their ransomware. Additionally, some of the observed samples include properties information that can be observed in Figure 1.
Figure 1. Ransomware sample properties details.
The file description included the entry VlahmAV, a play on words on ClamAV, and the developer named the ransomware HelloXD and used another potential alias, uKnow, as the developer of HelloXD in the copyright section.
When executed, HelloXD tries to disable shadow copies to inhibit system recovery before encrypting files using the following commands embedded in the sample:
Additionally the ransomware does a ping to 1.1.1[.]1 and asks to wait a timeout of 3000 milliseconds between each reply, quickly followed with a delete command to delete the initial payload.
Two of the initial set of samples identified create a unique mutex containing the following message:
mutex: With best wishes And good intentions...
After those commands are executed, the ransomware finishes by appending the file extension .hello, alongside a ransom note titled Hello.txt (Figure 2).
Figure 2. Encrypted files and ransom note.
The ransom note was modified between the observed samples. In the first sample we encountered (Figure 3, left), the ransom note only linked to a TOX ID, whereas a later observed sample (Figure 3, right) links to an onion domain as well as a TOX ID (different from the one in the first version). At the time of writing, this site is down.
Figure 3. Ransomware note comparison between the two observed variants.
The ransomware creates an ID for the victim which has to be sent to the threat actor to make it possible to identify the victim and provide a decryptor. The ransom note also instructs victims to download Tox and provides a Tox Chat ID to reach the threat actor. Tox is a peer-to-peer instant messaging protocol that offers end-to-end encryption and has been observed being used by other ransomware groups for negotiations. For example, LockBit 2.0 leverages Tox Chat for threat actor communications.
When observing both variants executing on virtual environments, we noted that the more recent variants changed the background to a ghost – a theme we’ve noticed in this threat actor’s work since our earliest observations of it. However, the previous version didn’t change the background at all – it simply left the ransom note we observed previously (Figure 4).
Figure 4. Desktop wallpaper change – none for older variant (left), ghost for newer variants (right).
Packer Analyses
During analysis and threat intel gathering, we discovered two main packers used for HelloXD ransomware binaries, as well as for other malware samples linked to the potential author (Figure 5).
The first type of packer is a modified version of UPX. The code is extremely similar between UPX-packed binaries and the custom packer, however the custom packer avoids using identifiable section names such as .UPX0 and .UPX1, and leaves the default .text, .data, and .rsrc names unchanged. There are also no magic bytes within the packed payload, unlike UPX-packed binaries, which contain the magic bytes UPX!.
However, a dead giveaway that the sample is packed is the raw size of the .text section, which is zeroed out, while the virtual size is much larger, as expected; this is identical to a .UPX0 section. As there is no data within the .text section on disk, the entry point of the unpacking stub is within the .data section, which will unpack the malicious code into the .text section on runtime.
All of these details point toward the threat actor having modified or copied certain elements from the UPX packer, which can be further confirmed by comparing a UPX-packed binary with a custom-packed HelloXD binary.
Figure 5. Similarities between custom packed sample (left) and sample packed with original UPX (right).
The second packer we discovered consists of two layers, with the second being the custom UPX packer discussed above. This particular packer seems to be more common on x64 binaries and involves decrypting embedded blobs using a seemingly custom algorithm containing unconventional instructions such as XLAT (Figure 6).
Figure 6. Decryption with XLAT and ROR8 instructions inside packer.
Aside from storing the encrypted second layer, there is little to no obfuscation within the packer; API calls such as VirtualAlloc and VirtualProtect are clearly visible, and there is no control flow obfuscation.
Ransomware Internals
We have observed two different samples of the HelloXD ransomware publicly available, indicating it is still under development by the author(s). The first sample is fairly rudimentary, with minimal obfuscation and typically paired with an obfuscated loader responsible for decrypting it through the use of the WinCrypt API before injecting it into memory. The second sample, on the other hand, is far more obfuscated, and is executed in memory by a packer rather than a full-scale loader.
While the obfuscation and execution may differ between the two, both samples contain very similar core functionality, due to the author copying the leaked Babuk/Babyk source code in order to develop the HelloXD ransomware (Figure 7). As a result, a lot of the function structure overlaps with Babuk, after getting past the obfuscation.
Sample 1 - Windows
Sample 2 - Windows
Hashes
4a2ee1666e2e9c40d372853e2203a7f2336b6e03
1758a8db8485f7e70432c07a9e3d5c0bb5743889
Execution
Obfuscated Loader
Packer
Algorithms
Modified HC-128, Curve25519-Donna
Rabbit Cipher, Curve25519-Donna
Obfuscation
Minimal
Control Flow
Files
Generic Files
Generic Files, MBR, Boot Files
Table 1. Ransomware sample comparison summary.
Figure 7. Side-by-side of encryption function in Babuk (left) and HelloXD (right).
While there is a lot of overlap between HelloXD and Babuk, there are some small but crucial differences to take note of between Babuk and the two different variants.
HelloXD version 1 is the least modified, utilizing Curve25519-Donna and a modified HC-128 algorithm to encrypt file data, while also containing the same CRC hashing routine incorporating the string dong, possibly referencing Chuong Dong, who had previously analyzed and reported on the first version of Babuk (Figure 8).
Figure 8. HelloXD checksum calculation.
The HelloXD author(s) did modify the infamous file marker and mutex however, opting for dxunmgqehhehyrhtxywuhwrvzxqrcblo as the file marker and With best wishes And good intentions… as the mutex (Figure 9).
Figure 9. Original HelloXD mutex.
With HelloXD version 2, the author(s) opted to alter the encryption routine, swapping out the modified HC-128 algorithm with the Rabbit symmetric cipher. Additionally, the file marker changed again, this time to what seems to be random bytes rather than a coherent string. The mutex is also modified, set to nqldslhumipyuzjnatqucmuycqkxjon in one of the samples (Figure 10).
Figure 10. Rabbit cipher.
Both versions have been compiled with the same compiler (believed to be GCC 3.x and above based on the mangling of export names), resulting in very similar exports between not only the ransomware variants, but also other malware that we have linked to the potential author (Figure 11).
Figure 11. Export tables revealing similar export naming conventions.
The biggest difference between the versions is the interesting addition of a secondary payload embedded within version 2. This payload is encrypted using the WinCrypt API, in the same fashion as the obfuscated loader discussed above. Once decrypted, the payload is dropped to System32 with the name userlogin.exe before a service is created that points to it. userlogin.exe is then executed (Figure 12).
Figure 12. HelloXD decrypts and drops MicroBackdoor to userlogin.exe
What is peculiar about this file is it is a variant of the open-source MicroBackdoor, a backdoor allowing an attacker to browse the file system, upload and download files, execute commands and remove itself from the system (Figure 13). As the threat actor would normally have a foothold into the network prior to ransomware deployment, it raises the question of why this backdoor is part of the ransomware execution. One possibility is that it is used to monitor ransomed systems for blue team and incident response (IR) activity, though even in that case it is unusual to see offensive tools dropped at this point in the infection.
Figure 13. MicroBackdoor configuration.
WTFBBQ Pivots
While analyzing the ransomware binaries, we discovered a unique string prevalent in almost all of the samples: :wtfbbq (stored as UTF-16LE). Querying VirusTotal with this string led to the discovery of eight files, six of which could be directly attributed to x4k through their own VirusTotal graph mapping out their infrastructure. The discovered samples are primarily Cobalt Strike Beacons, utilizing heavy control flow obfuscation – unlike the HelloXD ransomware samples we had previously seen.
Unfortunately, this specific string is not completely unique to x4k, and is instead found on several GitHub repositories as part of a technique to allow a running executable to delete itself from disk through renaming primary data streams within the file to :wtfbbq. Running a search for the non-UTF-16LE string results in multiple files, and filtering for executables yields 10 results, the majority of which are NIM-based binaries – potentially linked to this GitHub repository.
While the :wtfbbq string is not unique to x4k, by searching for the UTF-16LE version found inside the analyzed HelloXD ransomware samples, we only came across binaries linked to x4k’s infrastructure, providing a fairly strong link between HelloXD and x4k.
Hunting for Ransomware Attribution
The backdoor provided extremely useful insight into the potential threat actor behind the ransomware, as it had the following hardcoded IP address to use as the command and control (C2): 193[.]242[.]145[.]158. Upon navigating to this IP address, we observed an email address – tebya@poime[.]li – on the page title, the first link in the chain of attribution (Figure 14).
Figure 14. Site contents with the email address on the page title.
Using the email address as a pivot, we identified additional domains that were linked to tebya@poime[.]li.
Some of them historically resolved to some malicious IPs, which led us to discover additional infrastructure and malware being hosted in other domains (Table 3). Many of these also use the x4k name in the domain.
Domain
IP
First Seen
Last Seen
1q.is
164[.]68[.]114[.]29
2021-06-15
2022-03-24
x4k.sh
164[.]68[.]114[.]29
2021-01-14
2022-03-22
mundo-telenovelas.x4k.dev
164[.]68[.]114[.]29
2021-11-02
2021-11-02
acp.x4k.dev
164[.]68[.]114[.]29
2021-11-02
2021-11-02
relay1.l4cky.com
164[.]68[.]114[.]29
2021-03-25
2021-04-28
oelwein-ia.x4k.dev
164[.]68[.]114[.]29
2021-11-02
2021-11-02
mallik.x4k.dev
164[.]68[.]114[.]29
2022-03-19
2022-03-19
mamba77.red
164[.]68[.]114[.]29
2021-09-19
2021-09-24
xn--90a5ai.com
164[.]68[.]114[.]29
2021-09-29
2021-09-29
x4k.dev
164[.]68[.]114[.]29
2020-09-17
2021-10-28
oxoo.cc
167[.]86[.]87[.]27
2020-08-16
2020-09-15
bw.x4k.me
167[.]86[.]87[.]27
2020-09-24
2021-04-24
ldap.l4cky.men
167[.]86[.]87[.]27
2020-08-08
2020-12-15
www.y24.co
167[.]86[.]87[.]27
2019-03-11
2019-03-25
smtp1.l4cky.com
167[.]86[.]87[.]27
2020-12-26
2020-12-26
vmi606037.contaboserver.net
167[.]86[.]87[.]27
2021-10-15
2021-10-30
x4k.us
167[.]86[.]87[.]27
2020-07-29T
2020-07-29
Table 3. PDNS of 164[.]68[.]114[.]29 and 167[.]86[.]87[.]27
When looking at this infrastructure on VirusTotal, we observed that some of the domains we found were part of a VirusTotal graph called a.y.e/ created by the user x4k on June 30, 2021. On this graph, we found his infrastructure mapped out and malicious files that were also linked to the domains. This, however, was not the only graph we observed x4k creating. We also encountered additional graphs, mapping different things such as “Russian Hosts,” “DDoS Guard” and others, dating back to August 10, 2020 (Figure 15).
Figure 15. x4k VirusTotal Graph created by x4k.
Additionally, we observed the initial email being linked to a GitHub account (Figure 16), as well as various forums including XSS, a known Russian-speaking hacking forum created to share knowledge about exploits, vulnerabilities, malware and network penetration.
Figure 16. x4k GitHub account.
From the GitHub page, we also observed a URL to a site – xn--90a5ai[.]com(фсб[.]com) – resolving to the previously mentioned IP 164[.]68[.]114[.]29, which at this point in time only shows an animation of interconnecting points. That being said, when looking at the HTML source code of the site, we discovered a couple of references to the user observed before – x4kme – and other aliases such as uKn0wn, which was observed in the HelloXD ransomware samples.
Figure 17. Snippet of Script in HTML Source Code xn--90a5ai[.]comFrom the list of aliases used by the threat actor, we were able to observe another GitHub account with the name l4ckyguy, sharing the profile picture, location and URL in the description, with a link to the previously observed account (x4kme), and a name, Ivan Topor, which we believe may be another alias for this threat actor. A further account, l4cky-control, was also discovered. This repository contained a Python script that would decrypt a secondary Python script which reached out to the IP 167[.]86[.]87[.]27 to download and execute another Python script. This particular IP was linked to a Contabo server that x4k had also included within their VirusTotal graph discussed above.
We also found a YouTube account linked to the actor through the initial email tebya@poime[.]li, using another alias, Vanya Topor. It’s worth pointing out that “Vanya” is a diminutive for Ivan.
Figure 18. GitHub account for l4ckyguy (left) and YouTube account for Vanya Topor (right).
The YouTube account has no public videos, but we observed this threat actor sharing unlisted links in various hacking forums. The content of the videos were tutorials and walkthroughs, where the threat actor showed his methodology of performing certain actions, depending on the video. The videos had no sound, but the threat actor would type commentary on a terminal to address something the viewer was observing on screen.
The videos found gave us insight into x4k operations before moving into ransomware activity specifically. We learned how this threat actor leverages Cobalt Strike for his operations, including how to set up Beacons as well as how to send files to compromised systems. In one of the videos, we actually observed the threat actor performing a DNS leak test on his Android phone. We also got to observe how the domain фсб[.]com used to look in October 2020 – a blog of sorts titled “Ghost in the Wire.” Where the threat actor keeps alluding to his “Ghost” theme, a similar theme was observed in the HelloXD ransomware samples (Figure 19).
Figure 19. Screenshots of unlisted x4k YouTube videos.
In another video instance, we observed the threat actor submit a LockBit 2.0 sample on Cuckoo sandbox and compare the results with another presumably LockBit 2.0 sample prior to the one submitted in the video. At the time of writing, we don’t believe x4k is related to LockBit 2.0 activity, but we did find the choice of this particular ransomware family interesting (Figure 20). We also noticed this threat actor leveraging the use of other sandboxes besides Cuckoo – such as ANY.RUN and Hybrid Analysis – to test out verdicts and tooling, alongside the use of various virtual machines.
Figure 20a. LockBit 2.0 samples executed on X4K YouTube video.Figure 20b. LockBit 2.0 samples executed on X4K YouTube video.
Additionally, this threat actor not only leverages open-source tooling, but also develops his own tools and scripts. We were able to see this threat actor demonstrating some of his tools performing automated actions in his videos, such as obfuscating files, creating executables and code signing (Figure 21).
Figure 21. Custom scripts used by x4k
Taking a closer look at x4k’s main OS, we believe it to be a customized Kali Linux instance, tailored to his needs. Most of his videos, comments, configurations and tutorials are written in Russian – and when combined with knowledge gained from a few OPSEC mistakes – Russia is also where we believe x4k originates from. Additionally, we encountered the ClamAV logo during one of the threat actor walkthrough videos – the same logo used on the HelloXD ransomware samples (Figure 22). This time around, x4k is using the logo as the start menu for his OS enviorment.
Figure 22. ClamAV logo used in the threat actor’s personal environment.
On the same taskbar, we also noticed the Telegram icon, which is a very popular messaging app for chatting – but is also used by threat actors such as LAPSUS$ to post news into specific channels. Using his username and alias and pivot, we were able to identify two Telegram accounts sharing the same picture as observed before, and descriptions pointing to the threat actor’s main site фсб[.]com. We noticed that the x4k Telegram account is used actively versus the old account – which, according to Telegram, hasn’t been active in a while (Figure 23).
Figure 23. Telegram accounts.
x4k has a very solid online presence, which has enabled us to uncover much of his activity in these last two years. This threat actor has done little to hide malicious activity, and is probably going to continue this behavior.
Conclusion
Unit 42 research encountered HelloXD, a ransomware family in its initial stages – but already intending to impact organizations. While the ransomware functionality is nothing new, during our research, following the lines, we found out the ransomware is most likely developed by a threat actor named x4k. This threat actor is well known on various hacking forums, and seems to be of Russian origin. Unit 42 was able to uncover additional x4k activity being linked to malicious infrastructure, and additional malware besides the initial ransomware sample, going back to 2020.
Ransomware is a lucrative operation if done correctly. Unit 42 has observed ransom demands and average payments going up in the latest Ransomware Threat Report. Unit 42 believes that x4k, this threat actor, is now expanding into the ransomware business to capitalize on some of the gains other ransomware groups are making.
Palo Alto Networks detects and prevents HelloXD and x4k activity in the following ways:
WildFire: All known samples are identified as malware.
Anti-Ransomware Module to detect HelloXD encryption behaviors on Windows.
Local Analysis detection for HelloXD binaries on Windows.
Behavioral Threat Protection rule prevents Ransomware activity on Linux.
Next-Generation Firewalls: DNS Signatures detect the known C2 domains, which are also categorized as malware in the Advanced URL Filtering database.
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.
LockBit 2.0 is ransomware as a service (RaaS) that first emerged in June 2021 as an upgrade to its predecessor LockBit (aka ABCD Ransomware), which was first observed in September 2019.
Since its inception, the LockBit 2.0 RaaS attracted affiliates via recruitment campaigns in underground forums, and thus became particularly prolific during the third quarter of calendar year 2021. The LockBit 2.0 operators claimed to have the fastest encryption software of any active ransomware strain as of June 2021, claiming accordingly that this added to its effectiveness and ability to disrupt the ransomware landscape.
While several top-tier RaaS affiliate programs, such as Babuk, DarkSide and REvil (aka Sodinokibi) disappeared from the underground in 2021, LockBit 2.0 continued to operate and gradually became one of the most active ransomware operations. While Conti was recognized as being the most prolific ransomware deployed in 2021 per our 2022 Unit 42 Ransomware Threat Report, LockBit 2.0 is the most impactful and widely deployed ransomware variant we have observed in all ransomware breaches during the first quarter of 2022, considering both leak site data and data from cases handled by Unit 42 incident responders.
According to data analysis of ransomware groups’ dark web leak sites, LockBit 2.0 was the most impactful RaaS for five consecutive months. As of May 25, LockBit 2.0 accounted for 46% of all ransomware-related breach events for 2022. And the LockBit 2.0 RaaS leak site has the most significant number of published victims, with over 850 in total.
Additionally, LockBit 2.0 has affected many companies globally, with top victims based in the U.S., Italy and Germany. Its most highly targeted industry verticals include professional services, construction, wholesale and retail, and manufacturing.
Palo Alto Networks customers receive protections against LockBit 2.0 attacks from Cortex XDR, as well as from the WildFire cloud-delivered security subscription for the Next-Generation Firewall. (Please see the Conclusion section for more detail.)
LockBit 2.0 is another example of RaaS that leverages double extortion techniques as part of the attack to pressure victims into paying the ransom.
In some cases, LockBit 2.0 operators have performed DDoS attacks on the victims' infrastructure as well as using a leak site. This practice is known as triple extortion, a tactic observed in groups like BlackCat, Avaddon and SunCrypt in the past.
Like other ransomware families such as BlackByte, LockBit 2.0 avoids systems that use Eastern European languages, including many written with Cyrillic alphabets.
Unlike other RaaS programs that don't require the affiliates to be super technical or savvy, LockBit 2.0 operators allegedly only work with experienced penetration testers, especially those experienced with tools like Metasploit and Cobalt Strike. Affiliates are tasked with gaining initial access to the victim network, allowing LockBit 2.0 to conduct the rest of the attack.
LockBit 2.0 has been observed changing infected computers’ backgrounds to a ransomware note. The ransomware note was also used to recruit insiders from victim organizations. The notes claimed the threat actors would pay “millions of dollars” to insiders who provided access to corporate networks or facilitated a ransomware infection by opening a phishing email and/or launching a payload manually. The threat actors also expressed interest in other access methods such as RDP, VPN and corporate email credentials. In exchange, they offer a cut of the paid ransom.
Victimology
LockBit 2.0 targets organizations opportunistically. The operators work with initial access brokers to save time and allow for a larger profit potential. While typically seeking victims of opportunity, LockBit 2.0 does appear to have victim limitations. The group announced that they would not target healthcare facilities, social services, educational institutions, charitable organizations and other organizations that “contribute to the survival of the human race”. However, despite these claims, there have been instances of affiliates undermining these guidelines by still opting to attack industry verticals such as healthcare and education.
Organizations in Europe and the U.S. are hit more often by LockBit 2.0 than those in other countries, likely due to the high profitability and insurance payouts.
Leak Site Data
During the first calendar year quarter of 2022, LockBit 2.0 persisted as the most impactful and the most deployed ransomware variant we observed in all ransomware breaches shared on leak sites.
Figure 1. Ransomware leak site data from the first calendar year quarter of 2022.
According to leak site data analysis, LockBit 2.0 was the most impactful RaaS for five consecutive months. As of May 25, LockBit 2.0 accounted for 46% of all ransomware-related breach events for 2022 shared on leak sites.
Additionally, the LockBit 2.0 RaaS leak site has the most significant number of published victims, with over 850 in total. The site itself typically features information such as victim domains, a time tracker and measures of how much data was compromised.
Figure 2. LockBit 2.0 leak site extortion site.
LockBit 2.0 claims that they have demanded ransom from at least 12,125 companies, as shown in the figure below.
Figure 3. Source: VX-underground.
According to leak site data for LockBit 2.0, since its inception in June 2021, the RaaS has affected many companies globally, with top victims based in the U.S., Italy and Germany.
Figure 4. LockBit 2.0 geographical impact chart.
LockBit 2.0 has also impacted various victims across multiple industry verticals. Its most highly targeted industry verticals include professional services, construction, wholesale and retail and manufacturing.
Figure 5. LockBit 2.0 impacted industry vertical chart.
When looking at leak site data across all ransomware families, we’ve observed LockBit 2.0 targeting the highest number of organizations in the following regions: JAPAC, EMEA, and LATAM.
Unit 42 Incident Response Data on LockBit 2.0
Cases handled by Unit 42 security consultants involving LockBit 2.0 since its appearance in June 2021 demonstrate shorter dwell times and less flexibility in negotiation in the beginning of FY 2022 (measured October-September) in comparison to the end of FY 2021. The following data is broken into fiscal years and quarters based on when the threat actor breached the network, not when the activity was noticed by a client.
LockBit 2.0 has shown a decrease in dwell time in FY 2022. From the last two quarters of FY 2021 to the first two quarters of FY 2022, there has been an average 37-day difference.
Figure 6. LockBit 2.0 average dwell time by fiscal quarter.
The difference in initial and final ransom demands over the past fiscal year has been converted to percentages and then averaged. The graph below demonstrates that at the end of FY 2021, threat actors using LockBit 2.0 were much more open to negotiations of ransom amounts; during that time the ransom was dropped approximately 83% from the initial ask on average. In comparison, we see less flexibility in FY 2022 Q1 and Q3 – threat actors only offered an average of about 30% as a price drop. FY 2022 Q2 is not included due to lack of sufficient information.
Figure 7. LockBit 2.0 average difference in initial vs final ransom amount, shown as percentages.
LockBit 2.0 Tactics, Techniques and Procedures
Technically speaking, we have observed LockBit 2.0 affiliates leveraging the following tactics, techniques and procedures:
TA0001 Initial Access
T1078 Valid Accounts
Credentials that have either been reused across multiple platforms or have previously been exposed. Additionally, this includes VPN accounts – not just domain and local accounts.
T1133 External Remote Services
Affiliates have been seen brute forcing exposed RDP services and compromising accounts with weak passwords.
T1190 Exploit Public-Facing Applications
Vulnerabilities such as ProxyShell (CVE-2021-34473) and improper SQL sanitization (CVE-2021-20028) have been observed being utilized as footholds into the environment.
TA0002 Execution
T1053.005 Scheduled Task/Job
Scheduled Task. LockBit 2.0 can be executed via scheduled tasks.
T1059 Command and Scripting Interpreter
LockBit 2.0 is typically executed via command line arguments via a hidden window.
Windows SysInternals PsExec has been utilized for both persistence and execution purposes. Its ability to execute processes on other systems spread the ransomware and assisted in reconnaissance activities.
TA0003 Persistence
T1053.005 Scheduled Task/Job
Scheduled Task. It was quite common to see scheduled tasks used to create persistence for the ransomware executable, PsExec, and occasionally some defense evasion batch scripts.
T1078 Valid Accounts
Compromised accounts may be used to maintain access to the network.
T1136.001 Create Account
In rare cases, LockBit 2.0 has been observed to create accounts for persistence with simple names, such as “a.”
T1505.003 Server Software Component
With the upsurgence of ProxyShell, webshells have become more common entry points.
TA0004 Privilege Escalation
T1068 Exploitation for Privilege Escalation
The ProxyShell elevation of privilege on the Exchange PowerShell Backend (CVE-2021-34523), Windows Background Intelligent Transfer Service (BITS) improperly handling symbolic links (CVE-2020-0787), and abusing the CMSTPLUA COM interface have all been seen as methods of privilege escalation.
T1548.002 Abuse Elevation Control Mechanism: Bypass User Account Control
LockBit 2.0 has utilized a UAC bypass tool.
TA0005 Defense Evasion
T1070 Indicator Removal on Host
Indicators, such as logs in Windows Event Logs or malicious files, are typically removed using wevtutil, a batch script, or CCleaner.
T1140 Deobfuscate/Decode Files or Information
Most PowerShell scripts involved in LockBit 2.0 cases are Base64 encoded.
T1484.001 Domain Policy Modification: Group Policy Modification
LockBit 2.0 has been seen using the PowerShell module InvokeGPUpdate to update the group policy.
T1562.001 Impair Defenses: Disable or Modify Tools
Windows Defender, other anti-malware solutions and monitoring tools are disabled utilizing a process explorer tool, a batch script or a specially crafted command line script.
T1564.003 Hide Artifacts: Hidden Window
Affiliates use hidden windows to hide malicious activity from plain sight.
TA0006 Credential Access
T1003 OS Credential Dumping
As seen with other ransomware cases, Mimikatz is a key player in dumping credentials but LockBit 2.0 has been occasionally seen utilizing MiniDump as well.
T1555 Credentials from Password Stores
LockBit 2.0 has been seen utilizing numerous tools to dump passwords from password stores and Chrome using GrabChrome and GrabRFF.
TA0007 Discovery
T1046 Network Service Discovery
Both Advanced Port Scanner and NetScan have been used to discover local network infrastructure devices and services running on remote hosts. Active Directory queries for remote systems have been performed by ADFind.
T1057 Process Discovery
Process Explorer, Process Monitor and PCHunter have been utilized to discover any anti-malware or monitoring software and terminate it.
T1082 System Information Discovery
LockBit 2.0 enumerates system information such as hostname, shares, and domain information.
T1614 System Location Discovery
Attempts to check the language settings.
TA00008 Lateral Movement
T1021 Remote Services
Although Cobalt Strike has many capabilities beneficial to threat actors in ransomware attacks, it was mainly seen in LockBit 2.0 investigations acting as a command and control beacon, a method of lateral movement and a tool for downloading/executing files.
LockBit 2.0 has been known to self-propagate via SMB.
TA0010 Exfiltration
T1030 Data Transfer Size Limits
In some cases, LockBit 2.0 will limit the data transfer sizes to fly under the radar of any monitoring services a client may have set up.
T1041 Exfiltration over C2 Channel
MEGASync is the leading way for LockBit 2.0 affiliates to exfiltrate data from clients with it being occasionally replaced by RClone.
TA0011 Command and Control
T1219 Remote Access Software
AnyDesk has been the most common legitimate desktop software used to establish an interactive command and control channel, with ConnectWise seen slightly less frequently.
TA0040 Impact
T1486 Data Encrypted for Impact
LockBit 2.0 is known for its extortion tactics, encrypting devices and demanding a ransom.
T1489 Service Stop
During the defense evasion phase, anti-malware and monitoring software is often disabled. Firewall rules have occasionally been seen being disabled as well.
LockBit 2.0 Technical Details
LockBit 2.0 was developed using the Assembly and Origin C programming languages and leverages advanced encryption standard (AES) and elliptic-curve cryptography (ECC) algorithms to encrypt victim data. It can affect both Windows and Linux OS, as the operator released a Linux version of LockBit 2.0 to target VMware ESXi hypervisor systems in October 2021, coded exclusively in the C programming language.
The LockBit group claimed that LockBit 2.0 is “the fastest encryption software all over the world” and provided a comparative table showing the encryption speed of various ransomware samples.
LockBit 2.0 also contains a self-spreading feature, clears logs and can print the ransom note on network printers until the paper runs out.
A management panel that affiliates can use to manage victims and affiliate accounts, generate new ransomware builds and generate the decryptor if the demanded ransom is paid also exists.
LockBit 2.0 operators also released an information-stealer dubbed StealBit, which was developed to support affiliates of the LockBit 2.0 RaaS when exfiltrating data from breached companies.
StealBit contains the following capabilities:
Operates as a file grabber and dumps/uploads victim data to the LockBit victim-shaming site.
No reliance on third-party cloud file-sharing services, where data can be easily removed if the victim submitted a complaint.
The download speed is limited only by internet connection bandwidth, so it is possible to clone folders from corporate networks and upload them to the LockBit victim shaming blog quickly.
The operator of LockBit 2.0 has provided a comparative table speed showing the information stealer compared to other tools.
Figure 10. LockBit 2.0 download speed, according to LockBit 2.0 operator.
LockBit 3.0
There was a bug that existed in LockBit 2.0 that allowed researchers to revert the encryption process on an MSSQL database. After the bug’s disclosure, LockBit forum members discussed how the bug will not exist in LockBit’s next iteration. Moreover, on March 17, LockBit forum members mentioned the release of LockBit’s next version in one or two weeks. On March 25, VX underground posted a tweet with details of this new version, dubbed LockBit Black.
Figure 11. LockBit Black post-infection desktop wallpaper (Source: VX-underground).
Courses of Action
Several adversarial techniques were observed in this activity and the following measures are suggested within Palo Alto Networks products and services to ensure mitigation of threats related to LockBit 2.0 ransomware, as well as other malware using similar techniques:
The courses of action below mitigate the following techniques:
Exploit Public-Facing Application [T1190], Command and Scripting Interpreter [T1059], Local Account [T1136.001], Web Shell [T1505.003], Exploitation for Privilege Escalation [T1068], Indicator Removal on Host [T1070], Deobfuscate/Decode Files or Information [T1140], Disable or Modify Tools [T1562.001], Hidden Window [T1564.003], Valid Accounts [T1078], External Remote Services [T1133], Scheduled Task [T1053.005], Bypass User Account Control [T1548.002], Group Policy Modification [T1484.001]
THREAT PREVENTION
Ensure a secure Vulnerability Protection Profile is applied to all security rules allowing traffic
Ensure a Vulnerability Protection Profile is set to block attacks against critical and high vulnerabilities, and set to default on medium, low, and informational vulnerabilities
Ensure DNS sinkholing is configured on all anti-spyware profiles in use
Ensure an anti-spyware profile is configured to block on all spyware severity levels, categories, and threats
Ensure a secure anti-spyware profile is applied to all security policies permitting traffic to the internet
Ensure passive DNS monitoring is set to enabled on all anti-spyware profiles in use
Ensure that the Certificate used for Decryption is Trusted
Ensure application security policies exist when allowing traffic from an untrusted zone to a more trusted zone
Ensure 'Security Policy' denying any/all traffic to/from IP addresses on Trusted Threat Intelligence Sources Exists
Ensure 'SSL Forward Proxy Policy' for traffic destined to the internet is configured
Ensure 'SSL Inbound Inspection' is required for all untrusted traffic destined for servers using SSL or TLS
Ensure 'Service setting of ANY' in a security policy allowing traffic does not exist
THREAT PREVENTION
Ensure DNS sinkholing is configured on all anti-spyware profiles in use
Ensure passive DNS monitoring is set to enabled on all anti-spyware profiles in use
Ensure a secure anti-spyware profile is applied to all security policies permitting traffic to the Internet
Ensure that antivirus profiles are set to block on all decoders except 'imap' and 'pop3'
Ensure an anti-spyware profile is configured to block on all spyware severity levels, categories, and threats
Ensure a secure antivirus profile is applied to all relevant security policies
URL FILTERING
Ensure secure URL filtering is enabled for all security policies allowing traffic to the internet
Ensure all HTTP Header Logging options are enabled
Ensure that PAN-DB URL Filtering is used
Ensure that URL Filtering uses the action of ‘block’ or ‘override’ on the URL categories
Ensure that access to every URL is logged
CORTEX XSOAR
Deploy XSOAR Playbook - PAN-OS Query Logs for Indicators
Exfiltration
The courses of action below mitigate the following techniques:
Data Transfer Size Limits [T1030], Exfiltration Over C2 Channel [T1041]
THREAT PREVENTION
Ensure DNS sinkholing is configured on all anti-spyware profiles in use
Ensure that antivirus profiles are set to block on all decoders except 'imap' and 'pop3'
Ensure an anti-spyware profile is configured to block on all spyware severity levels, categories, and threats
Ensure passive DNS monitoring is set to enabled on all anti-spyware profiles in use
Ensure a secure anti-spyware profile is applied to all security policies permitting traffic to the Internet
Ensure a secure antivirus profile is applied to all relevant security policies
URL FILTERING
Ensure that PAN-DB URL Filtering is used
Ensure that access to every URL is logged
Ensure that URL Filtering uses the action of ‘block’ or ‘override’ on the URL categories
Ensure secure URL filtering is enabled for all security policies allowing traffic to the internet
Ensure all HTTP Header Logging options are enabled
CORTEX XSOAR
Deploy XSOAR Playbook - Block URL
Deploy XSOAR Playbook - PAN-OS Query Logs for Indicators
Deploy XSOAR Playbook - Block IP
DNS SECURITY
Enable DNS Security in Anti-Spyware profile
NEXT-GENERATION FIREWALLS
Setup NetFlow Monitoring
Ensure application security policies exist when allowing traffic from an untrusted zone to a more trusted zone
Ensure 'Service setting of ANY' in a security policy allowing traffic does not exist
Ensure 'Security Policy' denying any/all traffic to/from IP addresses on Trusted Threat Intelligence Sources Exists
Impact
The courses of action below mitigate the following techniques:
Data Encrypted for Impact [T1486], Service Stop [T1489]
CORTEX XSOAR
Deploy XSOAR Playbook - Ransomware Manual for incident response.
†These capabilities are part of the NGFW security subscriptions service
Note: This is not an all-inclusive list of the protections provided by Palo Alto Networks. This is a subset of our current Courses of Action initiative and will be updated as the project progresses.
Conclusion
LockBit 2.0 and its evolution over time is a perfect example to illustrate the persistence, increasing complexity and impact brought by the ransomware landscape as a whole. With claims of this RaaS offering the fastest encryption on the ransomware market, coupled with the fact that it has been delivered in high volume by experienced affiliates, this RaaS poses a significant threat. LockBit’s continuation with operations and its next iteration coming up on the horizon means that organizations and their security teams need to stay vigilant in the ever-evolving threat landscape.
Palo Alto Networks detects and prevents LockBit 2.0 ransomware in the following ways:
WildFire: All known samples are identified as malware.
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.
Appendix A
In August 2021, a Russian blogger published a 22-minute interview with an alleged representative of the group behind LockBit 2.0 called “LockBitSupp” on a YouTube channel called “Russian-language open source intelligence (OSINT).” The same Russian blogger previously published interviews with a representative of the group behind the REvil ransomware-as-a-service (RaaS), hackers and security experts.
Some key takeaways from the claims made in the interview were:
The LockBit 2.0 threat actor claimed the group’s RaaS was unlikely to be rebranded since the team allegedly was a business that was honest with their customers – suggesting a supposed contrast between LockBit 2.0 and Avaddon, DarkSide and REvil affiliates.
The LockBit 2.0 ransomware disregarded keyboard layout, but it allegedly would not run on a host where the system language was set to any of the languages spoken in the Commonwealth of Independent States region.
The group did not devise attacks on companies of their choice; they simply worked with initial access to any corporate network they obtained elsewhere, since this was more profitable and saved time. The team selected targets for ransomware attacks based on the company’s finances — the bigger, the better. The location also did not matter. However, team members allegedly did not attack healthcare facilities, social services, educational institutions and charitable organizations or any other organization that “contributed to the survival of the human race.” [Note that Unit 42 case data does include indications that threat actors using LockBit 2.0 have targeted healthcare organizations at times.]
The threat actor claimed that the largest number of victims who paid ransom were company representatives who did not care about creating backup copies and did not protect their sensitive data. According to the threat actor’s claims, companies that violated regulations about collecting and handling customer or user personal information were among those eager to pay. The threat actor claimed that there generally were only a few companies who refused to pay ransom on principle, while most of the victims evaluated profit and loss to decide whether or not to pay a ransom.
LockBit 2.0 operators allegedly almost always offered discounts to their victims since the goal was to streamline attacks.
The threat actor claimed that the COVID-19 pandemic facilitated ransomware attacks significantly, saying it was easy to compromise home computers of employees who work remotely and use them as a springboard to access other networked systems.
Companies in Europe and the U.S. were hit with ransomware much more often than companies based in other countries allegedly because of high profit and insurance and not because of language barriers.
Ransomware operators usually recruit negotiators, who coerce victims to pay ransom, since professional penetration testers allegedly lack the time for chatter.
On June 2, Volexity reported that over Memorial Day weekend, they identified suspicious activity on two internet-facing servers running Atlassian’s Confluence Server application. After analysis of the compromise, Volexity determined the initial foothold was the result of a remote code execution vulnerability in Confluence Server and Data Center. The details were reported to Atlassian on May 31, and Atlassian has since assigned the issue to CVE-2022-26134.
Based on the security advisory issued by Atlassian, it appears that the exploit is indeed an unauthenticated, remote code execution vulnerability. If the vulnerability is exploited, threat actors could bypass authentication and run arbitrary code on unpatched systems. At the time of publication, the Palo Alto Networks attack surface management solution Cortex Xpanse identified 19,707 instances of Confluence Servers that are potentially affected by this CVE.
A patch resolving the issue has been posted by Atlassian. Palo Alto Networks strongly advises organizations to patch immediately.
Updated June 7 to add additional in-the-wild observations.
Vulnerabilities Discussed
CVE-2022-26134
Vulnerable Systems
The Palo Alto Networks attack surface management solution Cortex Xpanse found 19,707 instances of Confluence Servers that are potentially affected by this CVE. The majority of these instances were discovered to reside within the United States, Germany, China and Russia.
Figure 1. On June 3, 2022, Cortex Xpanse found potentially vulnerable Confluence Servers distributed as shown throughout the globe. (The 29.2% shown in gray indicates potentially vulnerable servers in the rest of the world.)
Additionally, the Xpanse research team also found 1,251 end-of-life versions of the Confluence Server exposed on the public internet. Assets running end-of-life software should never be internet-facing. If an asset cannot be updated to secure versions of software, it should be isolated or decommissioned altogether. To learn more about the ubiquitous problem of end-of-life software, please refer to the 2022 Cortex Xpanse Attack Surface Threat Report.
CVE-2022-26134 in the Wild
Thus far, Unit 42 has noted historical scans being performed by the IP addresses publicly shared by Volexity. These scans date back as early as May 26, 2022, and target organizations in various industries.
Additionally, a purported proof of concept (PoC) has reached the public domain, increasing the threat this particular vulnerability poses.
Cortex Managed Threat Hunting Detections of CVE-2022-26134
The Cortex Managed Threat Hunting team has detected several exploitation attempts. Among the attempts, we found successful exploitation, which resulted in the Cerber Ransomware attack.
The ransomware was blocked by the Cortex XDR agent. The Managed Threat Hunting team immediately reported this incident to the customer and continues to monitor our customers using the XQL queries in the following section. Cortex XDR also includes multiple detections for post-exploitation activities.
Below are details of what was seen in the attempt.
In this case, the process tomcat.exe spawned multiple reconnaissance commands such as: whoami, systeminfo, arp, ipconfig, etc. On top of that, a Base64-encoded PowerShell command was executed and retrieved a ransomware binary.
Figure 3. Decoded Base64 PowerShell command.
In order to confirm the assumption that the above activity is related toCVE-2022-26134, we looked into the Confluence Apache access logs (atlassian-confluence.log) and found the PowerShell execution.
Figure 4. atlassian-confluence.log file.
Hunting Queries
The Cortex Managed Threat Hunting team continues to track any attempts to exploit CVE-2022-26134 across our customers, using Cortex XDR and the XQL queries below.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
// Description: Detect child processes of Atlassian JIRA/Confluence server processes
Palo Alto Networks provides protection against the exploitation of this vulnerability in the following ways:
Next-Generation Firewalls (PA-Series, VM-Series and CN-Series) or Prisma Access with a Threat Prevention security subscription can automatically block sessions related to this vulnerability using Threat ID 92632 (Application and Threat content update 8577).
Cortex XDR for Linux helps block CVE-2022-26134 attacks out of the box. Cortex XDR helps protect against post-exploitation activities on all OSes.
Prisma Cloud Web Application and API Security (WAAS) customers can use the OGNL Evaluation Injectioncustom rule in order to detect and block exploitation attempts.
Additionally, Xpanse has the ability to identify and detect Atlassian Confluence Servers that may be a part of your attack surface or the attack surface of third-party partners connected to your organization. Xpanse is even able to classify those servers which have not been upgraded to the most recent version. These abilities will be updated to detect additional instances or versions that are insecure against this CVE.
Existing Xpanse customers can log into Expander and identify their enumerated Atlassian Confluence devices by filtering by “Atlassian Confluence Server” in the Services tab.
As further information emerges or additional detections and protections are put into place, Palo Alto Networks will update this publication accordingly.
Indicators of Compromise
During the hunting process, we encountered exploitation attempts that originated from the following IP addresses:
IoC Type
IoC
Ipv4
172.104.31.117
Ipv4
191.37.248.120
Ipv4
84.17.48.94
Ipv4
193.106.191.71
Ipv4
18.216.140.250
Ipv4
18.221.234.103
Ipv4
89.187.170.129
Ipv4
2.56.11.65
Ipv4
87.249.135.167
Ipv4
192.99.152.200
Ipv4
31.13.191.157
Ipv4
27.1.1.34
Ipv4
167.99.57.116
(Table updated Sept. 22, 2022, to remove an IP address that is being used in legitimate scanning.)
REvil has emerged as one of the world’s most notorious ransomware operators. In summer 2021, it extracted an $11 million payment from the U.S. subsidiary of the world’s largest meatpacking company based in Brazil, demanded $5 million from a Brazilian medical diagnostics company and launched a large-scale attack on dozens, perhaps hundreds, of companies that use IT management software from Kaseya VSA.
While REvil (which is also known as Sodinokibi) may seem like a new player in the world of cybercrime, Unit 42 has been monitoring the threat actors tied to this group for three years. We first encountered them in 2018 when they were working with a group known as GandCrab. At the time, they were mostly focused on distributing ransomware through malvertising and exploit kits, which are malicious advertisements and malware tools that hackers use to infect victims through drive-by downloads when they visit a malicious website.
That group morphed into REvil, grew and earned a reputation for exfiltrating massive data sets and demanding multimillion dollar ransoms. It is now among an elite group of cyber extortion gangs that are responsible for the surge in debilitating attacks that have made ransomware among the most pressing security threats to businesses and nations around the globe.
Updated June 3, 2022: In October 2021, REvil went offline at least in part due to major multi-government entities pursuing the group. The absence, however, was apparently short lived. On April 20, 2022, REvil’s old leak site came back online. We’ve updated our original report on REvil’s activity to include insights on the most recent samples and attacks – though we note that it is not yet clear whether the threat actors behind this activity are actually members of the original group or if this is REvil under a new administration. The new information is included under the header “REvil in 2022.”
REvil in 2022: New Observations of Ransom Notes, Leak Site, Payment Site and More
REvil, one of the most prolific ransomware groups of 2021, went offline in October 2021. The dissolution of REvil was due to major multi-government entities pursuing the group’s operations, with arrests occurring, infrastructure seized, the disappearance of ransomware-as-a-service (RaaS) leadership and general mistrust between members of the group
On April 20, 2022, REvil’s old leak site came back online and started redirecting visitors to a new Onion address, listing new and previous victims. Of particular note, the new site also looks a bit different from the original “Happy Blog” led by the original REvil group – for example, the new site includes an RSS 2.0 feed and a “Join Us” section for active affiliate recruiting. Additionally, the proof of concept links are offline or removed for old victims, leading Unit 42 to believe that the website was revived from a backup and it didn’t update any of the content inside the posts. It is also possible that the blog is being recreated by another group – not necessarily the same threat actors who claimed the work of REvil before.
During early May, we noticed new alleged victim organizations being listed and then removed from the site numerous times. Typically, when an organization is removed from the site, it’s because they have paid the ransom, but this does not appear to be the case here. Instead, the same potential victims were added and then removed several times. The organizations were an India-based oil organization, a U.S.-based education organization and a France-based sign manufacturer. We observed the site being unstable at times – in some instances showing a blank page with no victims listed.
Figure 1. “New“ REvil leak site.
The recruiting section on the revived leak site at first directed victims to RuTOR, a known Russian-speaking forum marketplace typically selling illicit goods, leveraging the platform's automated escrow service. An affiliate interested in joining this iteration of REvil was asked to deposit money as part of an automated escrow agreement with an REvil member. Once this process was complete, the affiliate would then get an invite to the group.
Figure 2. Recruitment section of leak site.
We find the use of RuTOR interesting, since it’s not particularly known for ransomware operators, unlike other forums such as RAMP, Exploit or XSS – where posts seeking “security services” such as pentesters often turn out to be ransomware-related.
On April 22, we observed a post on RuTOR titled, “REvil’s TOR Sites are suddenly up and running again,”which prompted a response from WD, one of the RuTOR administrators, declaring that REvil is not welcome on the forum (Figure 3).
It’s worth noting that shortly after this post was made public, the threat actor behind the REvil leak site removed mentions of RuTOR from the leak site – from then on only leveraging TOX Chat for communication. The account useransom that was being used on RuTOR got suspended.
Figure 3. Post from RuTOR adminstrator, WD. Translation: “I officially declare: we are not working with these gentlemen, If this is really you, then I’m sorry. Wrong time, wrong place.”
On April 29, a REvil/Sodinokibi variant emerged in VirusTotal, initially reported by a researcher at AVAST. The observed sample (SHA256: 0c10cf1b1640c9c845080f460ee69392bfaac981a4407b607e8e30d2ddf903e8) was compiled on April 26, three days before the researchers encountered the sample in the wild. This is believed to be a new version of the REvil sample. This sample includes various updates compared to previous REvil samples, including adding pointers to the new leak site and payment site. (The payment site appears similar to previous versions.)
The sample also has a new field embedded in its JSON configuration, named accs. This field had accounts associated with two different organizations – one in Taiwan and one in Israel. At the time, those two organizations hadn’t been observed on the new REvil leak site, which could indicate they were perhaps victims being actively targeted.
The “ransomware” sample in fact only seems to behave like ransomware – it appears to encrypt files but doesn’t actually do so. The analyzed sample only renames existing files with a random extension – removing the extension will restore the file back to its original state (Figure 4).
Figure 4. Changing extensions on renamed files.
The ransom note is almost identical to the original used by this group; notable differences include:
Removal of the clearnet site that was previously included – decoder[.]re
New updated domains added, pointing to new infrastructure
Additional comments from the threat actors, such as a “Sensitive Data'' section that is identical to the one seen in the BlackCat ransom note.
The similarity to the BlackCat ransom note isn’t surprising – ransomware groups are known to copy each other's ransom notes from time to time (See Figure 5 for the full REvil note).
Figure 5. New REvil ransom note.
Their new payment site also seems to be similar to what REvil used in the past.
In the case of the April 29 sample, the requested ransom is $1.5 million. As seen in previous REvil cases, the ransom request doubles if payment is not performed within the established time frame. We looked for transactions on the BTC wallet address posted on the payment site. As of the writing of this updated report, there haven’t been any transactions made to that wallet address.
Figure 6. REvil payment site.
It’s still too early to say whether the threat actors behind this activity are actually members of the original group or if this is REvil under a new administration.
The “return” of the REvil/Sodinokibi name is not surprising; REvil had quite a reputation, built from three years of active ransomware activity. That being said, the REvil brand also has been tarnished. The group has gone offline multiple times due to high-profile attacks that led to law enforcement pursuit – and lost the trust of affiliates in the process. With the sudden disappearance of prominent leaders – Unknown(aka UNKN) in July and 0_neday shortly after in October 2021 – REvil leadership wasn’t able to restore confidence.
Figure 7. REvil representative 0_neday announcing compromise of REvil servers.
Even with the apparent return of REvil, other cybercriminals are skeptical, and some suspect law enforcement is behind it. Recruiting with such a reputation may be a bit difficult, and this is one of the main reasons why ransomware groups rebrand.
Regardless of who is behind the reemergence of this group, we continue to recommend that organizations prepare themselves to combat any ransomware that emerges. As always, the best time to prepare for a ransomware incident is before it happens.
Ransomware as a Service
REvil is one of the most prominent providers of ransomware as a service (RaaS). This criminal group provides adaptable encryptors and decryptors, infrastructure and services for negotiation communications, and a leak site for publishing stolen data when victims don’t pay the ransom demand. For these services, REvil takes a percentage of the negotiated ransom price as their fee. Affiliates of REvil often use two approaches to persuade victims into paying up: They encrypt data so that organizations cannot access information, use critical computer systems or restore from backups, and they also steal data and threaten to post it on a leak site (a tactic known as double extortion).
Threat actors behind REvil operations often stage and exfiltrate data followed by encryption of the environment as part of their double extortion scheme. If the victim organization does not pay, REvil threat actors typically publish the exfiltrated information. We have observed threat actors who are clients of REvil focus on attacking large organizations, which has enabled them to obtain increasingly large ransoms. REvil and its affiliates pulled in an average payment of about $2.25 million during the first six months of 2021 in the cases that we observed. The size of specific ransoms depends on the size of the organization and type of data stolen. Further, when victims fail to meet deadlines for making payments via bitcoin, the attackers often double the demand. Eventually, they post stolen data on the leak site if the victim doesn’t pay up or enter into negotiations.
2021 Trends – Something Old, Something New
Unit 42 has worked over a dozen REvil ransomware cases so far this year. While some of the tactics cited in our 2021 Unit 42 Ransomware Threat Report have remained the same, we have seen a few deviations from REvil’s standard attack lifecycle. For a quick reference, we have generated Actionable Threat Objects and Mitigations (ATOMs) to display REvil’s tactics, techniques, procedures and other indicators of compromise (IOCs).
How REvil Threat Actors Gain Access
REvil threat actors continue to use previously compromised credentials to remotely access externally facing assets through Remote Desktop Protocol (RDP). Another commonly observed tactic is phishing leading to a secondary payload. However, we also observed a few unique vectors that relate to the recent Microsoft Exchange Server CVEs, as well as a case that involved a SonicWall compromise. Below are the five unique entry vectors observed thus far in 2021.
A user downloads a malicious email attachment that, when opened, initiates a payload that downloads and installs a QakBot variant of malware. In at least one case, the version of QakBot we observed collected emails stored on the local system, archived them and exfiltrated them to an attacker controlled server.
In one instance, a malicious ZIP file attachment containing a macro-embedded Excel file that led to an Ursnif infection was used to initially compromise the victim network.
Several actors utilized compromised credentials to access internet-facing systems via RDP. It’s unclear how the actors gained access to the credentials in these instances.
An actor exploited a vulnerability in a client SonicWall appliance categorized as CVE-2021-20016 to gain access to credentials needed to access the environment.
An actor utilized the Exchange CVE-2021-27065 and CVE-2021-26855 vulnerabilities to gain access to an internet-facing Exchange server, which ultimately allowed the actor to create a local administrator account named “admin” that was added to the “Remote Desktop Users” group.
How REvil Threat Actors Establish Their Presence Within an Environment
Once access is obtained, REvil threat actors typically utilize Cobalt Strike BEACON to establish their presence within an environment. In several instances we observed, they used the remote connection software ScreenConnect and AnyDesk. In other cases, they chose to create their own local and domain accounts, which they added to the “Remote Desktop Users” group. Further, the threat actors often disabled antivirus, security services and processes that would interfere with or otherwise detect their presence within the environment.
Below are specific techniques we observed thus far in 2021:
Once the actor had access to the environment, they utilized different toolsets to establish and maintain their access, including the use of Cobalt Strike BEACON as well as local and domain account creation. In one instance, the REvil group utilized a BITS job to connect to a remote IP, download and then execute a Cobalt Strike BEACON.
In several incidents, Unit 42 identified the use of “Total Deployment Software” by REvil threat actors to deploy ScreenConnect and AnyDesk software to maintain access within the environment.
In many instances, the REvil actor(s) created local and domain level accounts through BEACON and NET commands even if they had access to domain-level administrative credentials.
Unit 42 observed common evasion techniques across all engagements in which REvil threat actors used [1-3] alphanumeric batch and PowerShell scripts that stopped and disabled antivirus products, services related to Exchange, VEAAM, SQL and EDR vendors, as well as enabled terminal server connections.
How REvil Threat Actors Expand Access and Gather Intelligence
In most cases, REvil actors need to gain access to additional accounts that have a wider set of privileges in order to move further within the victim environment and carry out their mission. They often use Mimikatz to access cached credentials on the local host. However, Unit 42 also observed the SysInternals tool procdump as a means to dump the LSASS process. Unit 42 also found it common for this threat actor to access files with the name “password” within the filename. In one instance, we observed an attempt to gain access to a KeePass Password Safe.
During the reconnaissance phase of attacks, REvil threat actors often utilize various open source tools to gather intelligence on a victim environment and in some cases resort to utilizing administrative commands NETSTAT and IPCONFIG to gather information.
Below are specific observations of REvil’s behavior in 2021.
Network reconnaissance tools netscan, Advanced Port Scanner, TCP View and KPort Scanner were observed in over half the engagements Unit 42 responded to.
The threat actors often use Bloodhound and AdFind to map out networks and gather other active directory information.
In two engagements, Unit 42 observed the use of ProcessHacker and PCHunter in what appeared to be an attempt to gain insight into processes and services running on hosts within the environment.
How REvil Threat Actors Move Laterally Throughout Compromised Environments
In general, REvil threat actors utilize Cobalt Strike BEACON and RDP with previously compromised credentials to laterally move throughout compromised environments. Additionally, Unit 42 observed use of the ScreenConnect and AnyDesk software as methods of lateral movement. While we have seen other ransomware groups employ these tactics, we observed REvil threat actors retrieving these binaries from file sharing sites such as MEGASync and PixelDrain.
How REvil Threat Actors Complete Their Objectives
Finally, we observed REvil threat actors moving to the final stage of their attack, encrypting networks, staging and exfiltrating data, and destroying data to prevent recovery and hinder analysis.
Ransomware Deployment
REvil threat actors typically deployed ransomware encryptors using the legitimate administrative tool PsExec with a text file list of computer names or IP addresses of the victim network obtained during the reconnaissance phase.
In one instance, a REvil threat actor utilized BITS jobs to retrieve the ransomware from their infrastructure. In a separate instance, the REvil threat actor hosted their malware on MEGASync.
REvil threat actors also logged into hosts individually using domain accounts and executed the ransomware manually.
In two instances, the REvil threat actor utilized the program dontsleep.exe in order to keep hosts on during ransomware deployment.
REvil threat actors often encrypted the environment within seven days of the initial compromise. However, in some instances, the threat actor(s) waited up to 23 days.
Exfil
Threat actors often used MEGASync software or navigated to the MEGASync website to exfiltrate archived data.
In one instance, the threat actor used RCLONE to exfiltrate data.
Defense Maneuvers
During the encryption phase of these attacks, the REvil threat actors utilized batch scripts and wevtutil.exe to clear 103 different event logs. Additionally, while not an uncommon tactic these days, REvil threat actors deleted Volume Shadow Copies in an apparent attempt to further prevent recovery of forensic evidence.
Conclusion: Evolve
While the REvil operational group may target large organizations, all are potentially susceptible to attack. As we draw closer to a post COVID-19 environment, IT and other defenders of networks should take time to learn what’s normal in their environments and notice and question abnormalities. Investigate them. Question your defenses. Do all users need to be able to open macro-enabled documents? Do you have endpoint visibility and protections to, at minimum, alert you to secondary infections such as QakBot? If you absolutely need RDP, are you using tokenized MFA? And don’t question just once – question routinely. Think like the attacker. You might be able to stop your organization from being the next victim and escape being in the headlines for the wrong reasons.
Palo Alto Networks customers are protected by:
WildFire: All known samples are identified as malware.
To better detect attacks that affect the actions of signed applications – such as supply-chain attacks, dynamic-link libraries (DLL) hijacking, exploitation and malicious thread injection – we have devised a suite of analytics detectors that are able to detect global statistical anomalies.
Using these new detectors, we found what seems to be an industrial espionage attack. The observed activity includes performing a specially crafted DLL hijacking attack used by a previously unknown piece of malware that we dubbed "Popping Eagle" due to several artifacts found in the samples. It also includes a second stage malicious tool written in Go dubbed "Going Eagle." In this particular case, we observed the attacker following this by performing several network scans and lateral movement steps.
Discovering Popping Eagle using this new suite of analytics detectors underscores the following key points:
These analytical and statistical methods have capabilities that allow for the identification of malware that might otherwise have been missed.
Though the malware loaded itself into a signed process with the goal of remaining undetected, these detectors found it due to the attempted obfuscation.
In this blog post, we discuss the hunting method, analyze the tools used in the attack and detail the actions performed by the attacker in the victim’s environment.
Palo Alto Networks customers are protected from this kind of attack by Cortex XDR, as well as the WildFire cloud-delivered security subscription for the Next-Generation Firewall. (Please see the Conclusion section for more detail.)
Malware Discussed
Popping Eagle, Going Eagle
Hunting for Statistical Irregularities in Signed Applications
Motivation
Over the last couple of years, the number of supply-chain attacks has increased dramatically. Examples include SolarStorm, NotPetya, Kaseya, KeRanger and others.
From previous events, we learned that even though threat actors leveraging supply-chain attacks usually run code on a large number of organizations, they tend to focus the attack’s "second stage" on a small number of high-value targets.
Leveraging a large Cortex XDR dataset, we built a global baseline of "normal" application behavior and hunted for anomalies.
Identifying these anomalies detects several kinds of techniques – examples include supply chain attacks, DLL side-loading or malicious thread injections – and any attack that may cause a legitimate signed application to behave differently.
In addition, some actions are unique to each organization, even when performed by the same application (for example, connecting to the domain of the organization itself). Recognizing this, we also build a local baseline for each organization and for each application.
Using these baselines, we compare actions performed by each application and flag anomalous activities.
Once we have a set of suspicious cases, we further analyze them to validate if these are actual attacks.
Finding Popping Eagle
After filtering out cases with known malicious indicators of compromise (IoCs), we came across the following case:
The application clicksharelauncher.exe, signed by "Barco N.V.," had been seen in a few hundred different environments, indicating we have a good baseline on its behavior, but it performed unique domain resolutions in only one environment. Furthermore, the domain it contacted, dnszonetransfer[.]com, was only seen in that environment, and only on three unique agents out of thousands.
In the course of the research, we found two types of tools left on the hosts that sparked our curiosity as they were unknown not only by hash but also by all other IoCs found during the research (see “Searching for Related IoCs” for further elaboration).
Analyzing Popping Eagle’s First Stage
Loading Method – DLL Proxy
Looking into the causality chain of clicksharelauncher.exe, we saw that before it contacted the dnszonetransfer[.]com domain, it loaded an unsigned DLL from the same directory as the executable named uxtheme.dll.
This DLL name also belongs to a known Microsoft signed DLL that's usually located at %windir%\SysWOW64\UxTheme.dll, and the DLL name is also in the import table of clicksharelauncher.exe.
Figure 1. Partial import table of clicksharelauncher.exe
This is a classic example of DLL Search Order Hijacking; clicksharelauncher.exe tries to load uxtheme.dll from the current directory before %windir%\SysWOW64\, so it loads the attacker’s DLL instead of Microsoft’s DLL.
Comparing the export table of the unsigned uxtheme.dll with the original one also shows the same functions, with the addition of one additional exported function: popo.
Figure 2. Partial export table of the malicious proxied DLL (left) and original DLL (right).
Analyzing the uxtheme.dll Sample
This executable was written as a 32-bit DLL in C++. The original compiled name from the DLL metadata is CoL_Final_Lib.dll, and its compile timestamp records the same day we first saw it. In conjunction with the fact that each of the three hosts we saw it on had a different SHA256 hash, this may indicate that it was compiled "on the spot."
The use of the Barco software as a loader also indicates that the sample was tailor-made to this victim’s environment – its use as a loader is rather unique.
Checking the memory locations of its entry point and exports shows mostly strings, while only one is an actual function. This further indicates that this DLL doesn't implement actual logic for these functions and they only exist to better mimic the proxied DLL.
To run its functionality right away on load (avoiding the need to wait to be called explicitly), the malware runs its main code on the main DLL entry point and in a new thread (to not block the rest of the DLL load flow).
Figure 3. The malware's main function in the DLL. This function is also called from the popo entry point.
This main function decodes the C2 URL (using a simple one-byte XOR) and connects to it using a Win32API function. From strings found in the code, it seems that the malware authors used the open-source C++ project WinHttpClient to perform the network logic. The malware then enters its main event loop, which performs these actions:
Sends a POST request to the URL with a hardcoded old Linux user agent and message.
Verifies that the response starts with Unicode 726563697074 – "recipt" (may suggest a non-native English-speaking author).
Parses a struct with several different commands including:
Saving files on the remote host.
Loading and running DLLs from a specific folder.
Sleeps for one hour + a randomly generated timeframe.
Figure 4. The first request sent to the server by the malware.
Going Eagle Second Stage Analysis
Most of the time this DLL was observed, it didn't seem to receive any commands from the malicious actor. But on one occasion the IP resolved by dnszonetransfer[.]com temporarily changed to 51.38.89[.]53 for a few days when the attacker was active. This is a common tactic attempting to avoid detection where the C2 domain only points to the attacker’s infrastructure when the malware needs to be controlled. This attacker-controlled IP used the first-stage malware to load a second stage DLL that we call “Going Eagle.”
Analyzing ClickRuntime-amd86.dll
This executable was written as a 32-bit DLL in Go. The original "compiled name" from the DLL metadata is iphlpapi.dll. Somewhat interestingly, this DLL proxies a different Microsoft DLL by the same name (and mimics all the relevant named export functions). This isn’t necessary as the first stage loads it with LoadLibrary and not by the DLL-hijacking technique.
Figure 5. Partial export table of the malicious proxied DLL (left) and original DLL (right).
There are more similarities between the DLLs although they were written in different languages (C++, Go)
Compile timestamp – created and dropped on the same day.
Created as a proxy DLL.
Has an export function named popo
The DllMain and popo functions call a function that invokes the malware’s inner logic in another thread (so the malware logic will run right on the DLL load or on another popo invocation).
This tool was created for one task only – to create a reverse SOCKS proxy to get the attacker control over the machine (as described in the “Lateral Movement” section later on).
Since the malware is written in Go, we can extract extra data from its plaintext strings:
Original package name Eagle2.5-Client-Dll (outlined in red in Figure 6).
Original function names (like main.StartEagle).
Packages from Go standard and extended library (like bufio, log, x/net).
Packages from other resources like GitHub repositories (outlined in yellow and green in Figure 6).
Figure 6. Strings found in the malware sample.Figure 7. popo inner call to StartEagle function with the C2 as a parameter.Figure 8. Illustration of the attack flow.
Lateral Movement
Using the second-stage SOCKS binary, Going Eagle, the attackers tunneled their machine to perform several network-based attacks.
At first, they scanned multiple hosts for open Remote Desktop Protocol (RDP) and Server Message Block (SMB) ports, in order to find targets toward which to move laterally. Leveraging password reuse of the local administrator account on several different hosts, the attackers used Impacket's wmiexec to run discovery commands on multiple machines.
This caused the following detectors to be raised:
Table 1. Detectors raised in Cortex XDR by the activity of Going Eagle.Figure 9. Cortex XDR grouped several lateral-movement related alerts into an Incident.
In addition to wmiexec, the attackers used RDP to move laterally through the network. They uploaded PsExec and used it to run taskmgr.exe as SYSTEM to gather credentials by dumping lsass memory.
This was blocked by the Cortex XDR agent as well and raised several other alerts from Cortex XDR Analytics and Cortex XDR BIOCs:
Table 2. Alerts raised from Cortex XDR Analytics and Cortex XDR BIOCs.
At a certain point, the attackers managed to acquire a privileged domain account and tried using it to steal secrets from the domain controller using Impacket's secretsdump. But their attempts were blocked by the Cortex XDR agent.
Table 3. Table showing how the Cortex XDR Agent blocked an attempt to steal secrets from the domain controller.
It seems that the attacker failed to reach their goals and stopped trying to move laterally due to the multiple protections in place.
The attacker changed dnszonetransfer[.]com IP resolution to a benign IP
Table 4. Timeline of activities, attack techniques and detections involved in the Popping Eagle attack.
Searching for Related IoCs
After we finished analyzing the malware's behavior, we set our goals to find related samples by the same actor.
Hypothesis
Observing the facts:
The first stage downloads and loads the second stage DLL and invokes the function popo from it. Both DLLs export the popo function.
The second stage unnecessarily proxies the DLL.
Also, both of the DLLs contain possible indicator strings for a version or a development ready status
CoL_Final_Lib.dll
Eagle2.5-Client-Dll
This data can sum up to a possible modus operandi of an adversary:
Create and use multiple small-effort tools written using known public projects and libraries.
It is feasible to assume that they have a framework to easily create proxy DLLs with a single export function (in our case: popo).
Developer(s) knowledgeable in several programming languages (C++, Go, Python).
Hunting and Searching Methodology
At first we searched for the initial indicators (hash, domain, IP, URL) on AutoFocus and common public threat intel platforms, but nothing new was found.
Additionally, while analyzing the malware, we created generic "hunting" and specific "adversary" Yara rules to search for related samples. The generic rules yielded surprisingly good results by finding additional "Go socks" samples unrelated to this actor, most of which are malware.
The specific adversary rules did not find any additional samples.
Conclusion
As seen in the case above, attackers are using open-source code to develop custom malware that's designed to evade security detection. In order to combat more advanced actors, we must leverage more sophisticated detection techniques. Hunting for anomalous actions done by signed applications has proven itself successful in finding previously unknown attacks and "dormant" backdoors.
Due to the malware's apparently being tailor-made for the attacked network and the use of common attack tools, we couldn't attribute it to a specific actor.
Palo Alto Networks customers are protected from this kind of attack by the following:
1. Cortex XDR's Global Analytics BIOC alerts, implementing, among many things, the statistical techniques described earlier.
Table 5. Cortex XDR Global Analytics BIOC alerts that can help protect against Popping Eagle.
2. Cortex XDR Agent Behavioral Threat Protection blocks the DLL hijacking attack on the vulnerable application, preventing future malware from using the same loading method.
3. WildFire, a cloud-delivered security subscription for the Next-Generation Firewall, and Cortex XDR identify and block all IoCs mentioned as well as all future IoCs identified by the Yara rules
On May 27, 2022, details began to emerge of malicious Word documents leveraging remote templates to execute PowerShell via the ms-msdt Office URL protocol. The use of this technique appeared to allow attackers to bypass local Office macro policies to execute code within the context of Word. Microsoft has since released protection guidance and assigned CVE-2022-30190 to this vulnerability.
Due to the amount of publicly available information, ease of use, and the extreme effectiveness of this exploit, Palo Alto Networks is providing this threat brief to make our customers aware of this critical vulnerability and the options available to ensure proper protections are put into place until a patch can be issued by Microsoft.
The vulnerability enables remote code execution with the same privileges as the calling application and there are proof-of-concept examples of zero-click variants. Therefore, exploits for this vulnerability have potential to be of high impact.
We highly recommend following Microsoft’s guidance to protect your enterprise until a patch is issued to fix the problem.
All known samples and URLs associated with this attack have been flagged in the Palo Alto Networks product suite so customers can receive protections.
Vulnerability Discussed
CVE-2022-30190 aka Follina
Attack Details for CVE-2022-30190
On May 27, 2022, a cybersecurity research team out of Tokyo, Japan, nao_sec, uncovered a malicious Word document uploaded to VirusTotal from an IP in Belarus. The document was abusing the Microsoft Word remote template feature to retrieve a malicious HTML file that subsequently used the ms-msdt Office URI scheme to execute PowerShell within the context of Word.
On May 30, Keven Beaumont wrote an article detailing the specifics of the initial incident. The important thing to note here is that the decoy Word document had nothing inherently malicious outside of the link to the template hosted at hxxp://xmlformats[.]com, allowing it to bypass EDR solutions. The HTML code from the remote template is shown in Figure 1 below.
Figure 1. Remote template HTML code.
The JavaScript embedded within the HTML uses the ms-msdt schema to invoke the PCWDiagnostic pack, to reference the IT_BrowseForFile to execute the base64-encoded PowerShell Invoke-Expression command.
The base64-decoded text within the PowerShell Invoke-Expression is shown in Figure 2 below.
Figure 2. Base64-decoded PowerShell contents.
This code does a few things. First it kills the msdt.exe process. Then the code loops through the files within a .rar archive looking for a CAB file (TVNDRgAAAA base64 decodes to MSCF, which is the magic header of a CAB file). It then stores it in a file called 1.t. 1.t, which gets base64 decoded to 1.c, expanded to rgb.exe and then finally executed.
None of the reports we’ve seen have recovered the final payload. Therefore, the contents are unknown.
The use of remote templates to deliver malicious documents is not new, however, historically they’ve been used to host .docm or dotm (macro-enabled Word documents), which would still be affected by the local systems’s Word macro policy. Therefore, the vulnerability of particular note in this attack lies in calling the Microsoft Support Diagnostic Tool (MSDT) using the ms-msdt URL Protocol within Word via the remotely loaded template file. This allows execution of code within the context of Microsoft Word, even if macros are disabled.
Protected View was triggered during execution of the nao_sec example, however, John Hammond demonstrated you can bypass Protected View by using an RTF file instead. This allows the attack to succeed even if the user simply views the file in the preview pane – with no clicks on the document necessary – making the attack much more dangerous.
Microsoft has since released protection guidance and assigned CVE-2022-30190 to this vulnerability. They provided a workaround to disable the MSDT URL protocol, however, this may break other diagnostic tools that rely on the MSDT URL protocol to operate. They also recommend ensuring cloud-delivered protections and automatic sample submission for Microsoft Defender are enabled. Microsoft recommends that customers of Microsoft Defender for Endpoint enable the attack surface reduction rule BlockOfficeCreateProcessRule.
CVE-2022-30190 in the Wild
So far, Palo Alto Networks is only seeing indications of testing within our customer telemetry indicated by final payload execution of benign executables such as calc.exe and notepad.exe. Palo Alto Networks and Unit 42 will continue to monitor for evidence of exploitation and further novel use cases.
Conclusion
Based on the amount of publicly available information, the ease of use and the extreme effectiveness of this exploit, Palo Alto Networks highly recommends following Microsoft’s guidance to protect your enterprise until a patch is issued to fix the problem.
Next-Generation Firewalls (PA-Series, VM-Series and CN-Series) or Prisma Access with a Threat Prevention security subscription can automatically block sessions related to this vulnerability using Threat ID 92623 (Application and Threat content update 8575).
WildFire and Cortex XDR categorize all known samples we’ve come across as malware.
Cortex XDR Agent 7.5 and higher (with content version 540-92526) prevents attempts to exploit this vulnerability with the Behavioral Threat Protection module. The Cortex XSOAR “CVE-2022-30190 - MSDT RCE” playbook helps speed up the discovery and remediation of compromised hosts within the network. The playbook can be found on the XSOAR marketplace.
Additionally, all encountered URLs have been flagged as malware within PAN-DB, the Advanced URL Filtering URL database. Customers can leverage this service with best practice configuration for further protection.
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
As further information or detections are put into place, Palo Alto Networks will update this publication accordingly.
Unit 42 researchers continually observe network attacks and search for insights that can assist defenders. Here, we summarize key trends from November 2021 to January 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, for example, cross-site scripting or denial of service.
Cross-site scripting stood out as a commonly used technique. Among around 6,443 newly published vulnerabilities, we found that a large portion (almost 10.6%) still involve this technique. However, by evaluating around 167 million attack sessions and focusing on the latest exploits in the wild, we conclude that remote code execution is still a great concern, while information disclosure and traversal is ranking high when we categorize those attacks. Defenders should pay attention to the trends and adjust mitigation methodology accordingly.
Additionally, we provide insight into how the vulnerabilities are actively exploited in the wild based on real-world data collected from Palo Alto Networks Next-Generation Firewalls. For example, we chart a timeframe showing 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 the attackers are using, as well as the severity, category and origin of each attack.
Analysis of Published Vulnerabilities, November 2021 to January 2022
From November 2021 to January 2022, a total of 6,443 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 proof-of-concept (PoCs) which attackers can feasibly launch exploits that are available. Some of the public sources we use to find PoCs are Exploit-DB, GitHub and Metasploit. Distribution for the 5,427 CVEs that have an assigned severity score of medium or higher can be seen in the following table:
Severity
Count
Ratio
PoC Availability
Critical
797
14.7%
7.2%
High
2299
42.5%
3.0%
Medium
2331
43.0%
3.5%
Table 1. Severity distribution for CVEs registered in November 2021 to January 2022.
Figure 1. Severity distribution for CVEs registered in November 2021 to January 2022.
Vulnerabilities classified as critical are the least common, but they 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 discussed quarter, the critical severity PoC ratios increased while high severity and medium severity PoC ratios decreased slightly. This could be influenced by the Apache Log4j vulnerabilities disclosed in December and the amount of attention a vulnerability receives when it is more severe, as it is more interesting to both security researchers and attackers. Palo Alto Networks continues to leverage threat intelligence information on the latest vulnerabilities and real-time monitoring of exploits in the wild to provide protections for our customers.
Vulnerability Category Distribution, including Cross-Site Scripting
The type of vulnerability is also crucial to understanding its consequences. Out of the newly published CVEs that were analyzed, 31.3% are classified as local vulnerabilities, requiring prior access to compromised systems, while the remaining 68.7% are remote vulnerabilities, which can be exploited over a network. This means that the majority of newly published vulnerabilities introduce the potential for threat actors to attack vulnerable organizations anywhere in the world.
The most common vulnerability types are shown below, ranked by how prevalent they were among the most recent set of published vulnerabilities:
Figure 2. Vulnerability category distribution for CVEs registered in November 2021 to January 2022.
Cross-site scripting remains ranked first and more denial-of-service vulnerabilities were published this quarter than last quarter. However, most cross-site scripting and denial-of-service attacks are at medium or high severity. At the same time, the prevalence of buffer overflow vulnerabilities increased in November 2021 to January 2022.
Network Security Trends: Analysis of Exploits in the Wild, November 2021 to January 2022
Data Collection
By leveraging Palo Alto Networks Next-Generation Firewalls as sensors on the perimeter, Unit 42 researchers observed malicious activities from November 2021 to January 2022. We analyzed more than 200 million sessions in total for this quarter. The malicious traffic we identify is further processed based on metrics like IP addresses, port numbers and timestamps. This ensures the uniqueness of each attack session and thus eliminates potential data skews. We filtered out 167.34 million valid malicious sessions. Our researchers 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 167.34 million valid malicious sessions, we exclude from the original set of low severity signature triggers that are used to detect scanning and brute-force attacks. 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 in November 2021 to January 2022.
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 a noticeable increase in the prevalence of high severity attacks and a decrease in medium severity attacks. High severity attacks represent more than half of the observed attacks for the first time. However, we still focus more on critical severity attacks because of their greater potential impact. Even though many published vulnerabilities are scored medium severity, attackers 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?
For this installment of our network security trends analysis, we collected data from November 2021 to January 2022. Attackers steadily leveraged high severity exploits throughout this period. From the week of December 6th, we observed large amounts of traffic on critical vulnerabilities related to the Apache log4j remote code execution vulnerability.
Figure 4. Attack severity distribution measured weekly from November 2021 to January 2022.
Vulnerabilities that are frequently exploited seem relatively similar to the last quarter, where attempts of exploiting recently disclosed and high severity vulnerabilities remain the majority of threats we’ve observed. As we addressed before, prompt and proper application of patches is very important. And software and systems should be updated to date once patches are publicly available.
Figure 5. Observed attacks broken down by the year in which the exploited CVE was disclosed, measured weekly from November 2021 to January 2022.
Exploits in the Wild, November 2021 to January 2022: A Detailed View
With the generic attacks trend and statistics shown above, we detail attacks below that were widely used due to high severity and ease of exploitation, according to our observation. Snippets and details showing how attackers utilized open-source tools to compromise targets are also presented in this section so researchers can have more tools to defend against known threats and their variations.
Apache Log4j Remote Code Vulnerability is the leading cause of the sharp increase in traffic beginning the week of December 6, 2021. Unit 42 researchers have already posted a blog on this attack.
Microsoft OMI has a remote code execution vulnerability. An unauthenticated, remote attacker can exploit this flaw by sending a specially crafted request to a vulnerable user over a publicly accessible remote management port. The specially crafted request needs to be sent without an authorization header. As a result, this vulnerability is the most severe out of the four flaws encompassing OMIGOD.
Figure 6. Microsoft Open Management Infrastructure Remote Code Execution Vulnerability.
An issue has been discovered in GitLab CE/EE. GitLab was not properly validating image files that were passed to a file parser which resulted in remote code execution.
Sitecore Experience Platform is vulnerable to an insecure deserialization attack where it can achieve remote command execution on the machine. No authentication or special configuration is required to exploit this vulnerability.
Metabase, an open source data analytics platform, is affected by a potential local file inclusion vulnerability. URLs were not validated prior to being loaded. This issue is fixed in a new maintenance release. Alternatively, you can mitigate this by including rules in your reverse proxy or load balancer or WAF to provide a validation filter before the application.
Figure 11. Metabase Information Disclosure Vulnerability.
Applications using both spring-cloud-netflix-hystrix-dashboard and spring-boot-starter-thymeleaf expose a way to execute code submitted within the HTTP request URI path during the resolution of view templates. When a request is made, the path elements following hystrix are evaluated as SpringEL expressions, which can lead to code execution.
In the Druid ingestion system, the InputSource is used for reading data from a certain data source. However, the HTTP InputSource allows authenticated users to read data from other sources than intended, such as the local file system, with the privileges of the Druid server process.
Barcode is a GLPI plugin for printing barcodes and QR codes. GLPI instances with the barcode plugin installed are vulnerable to a path traversal vulnerability.
The vSphere Web Client (FLEX/Flash) contains an unauthorized arbitrary file read vulnerability. A malicious actor with network access on vCenter Server may exploit this issue to gain access to sensitive information.
Figure 15. VMware vCenter Server Information Leak Vulnerability.
The WordPress Visitor Statistics plugin does not properly sanitize and escape the refUrl in the refDetails AJAX action available to any authenticated user, which could allow users with a role as low as subscriber to perform SQL injection attacks.
The Modern Events Calendar Lite WordPress plugin does not sanitize and escape the time parameter before using it in a SQL statement in the mec_load_single_page AJAX action, available to unauthenticated users, leading to an unauthenticated SQL injection issue.
Figure 17. WordPress Modern Events Calendar Plugin SQL Injection Vulnerability.
We classified each network attack by category and in order of prevalence. Remote code execution ranks first in this quarter, followed by information disclosure. Attackers typically want to gain as much information as they can and as much control as possible over the systems they target. Traversal attacks increased this quarter – mature attack services and tools make it relatively simple for attackers to succeed with these types of exploits.
Figure 18. Attack category distribution, November 2021 to January 2022.
Where Did the Attacks Originate?
After identifying the region from which each network attack originated, we discovered that the largest number of them seem to originate from the United States, followed by 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 19. Locations ranked in terms of how frequently they were the origin of observed attacks from November 2021 to January 2022.Figure 20. Attack geolocation distribution from November 2021 to January 2022.
Conclusion
Due to the huge impact of the Log4j vulnerability (CVE-2021-44228, CVE-2021-45046) and its publicly available proof of concept, we observed an unprecedented amount of attacks during this quarter, where most attacks started right after the details of exploitation were disclosed. This kind of proactivity on the part of cybercriminals suggests that more attention should be paid to severe vulnerability incidents. Corresponding patches should be applied promptly with best security practices implemented.
While cybercriminals will never cease their malicious activities, Palo Alto Networks customers are fully protected from the attacks discussed here by Next-Generation Firewalls. Additional mitigations include:
Run a Best Practice Assessment to identify where your configuration could be altered to improve your security posture.
Continuously update your Next-Generation Firewalls with the latest Palo Alto Networks Threat Prevention content (e.g. versions 8572 and above).
Today, INTERPOL and The Nigeria Police Force announced the arrest of a prominent business email compromise (BEC) actor who has been active since 2015. His apprehension marks the latest success for Operation Delilah - a counter-BEC operation that began in May 2021 and has involved international law enforcement and industry cooperation across four continents.
BEC remains the most common and most costly threat facing organizations globally. This threat held the top spot for the sixth year in a row on the 2021 FBI Internet Crime Complaint Center (IC3) report. Over half a decade, global losses have ballooned from $360 million in 2016 to a staggering $2.3 billion in 2021. Despite these massive loss amounts, industry and global law enforcement continue to make considerable strides toward thwarting this activity.
Unit 42 tracks Nigerian BEC actors under the name SilverTerrier. Following the arrest of 11 BEC actors as part of Operation Falcon II in December 2021, this recent operation is significant in that it demonstrates the resolve of global law enforcement to hold BEC actors accountable despite temporary setbacks. Specifically, in this case, the SilverTerrier actor fled Nigeria in 2021 when authorities initially attempted to apprehend him. Months later, in March 2022, he attempted to return home and was quickly identified and detained as he attempted to re-enter Nigeria. This level of international cooperation, tracking of actors as they travel internationally and subsequent apprehension of actors upon returning to their home countries represents a laudable advancement in the ability of global law enforcement organizations to combat these types of crimes.
Palo Alto Networks Unit 42 was thanked for its collaboration with INTERPOL in Operation Delilah. The team provided telemetry and other insights about BEC actors.
This blog provides a brief overview of the actor’s activities and provides recommendations to help organizations protect against these threats.
Figure 1. Photo of threat actor from social media.
Domains: We have identified over 240 domains that were registered using this actor's aliases. Of that number, over 50 were used to provide command and control for malware. Most notably, this actor falsely provided a street address in New York city associated with a major financial institution when registering his malicious domains. Examples of domains registered by this actor include: goldmedal-inlt[.]com,gulfmedlcal[.]com, magen-ecoenregy[.]com, nauticelegal[.]com, sanof1[.]com and scbc-uk[.]com.
Malware: ISRStealer, Pony, LokiBot
Oldest Activity: 2015
Departing Nigeria: Upon fleeing Nigeria in June 2021, this actor was observed attempting to sell his Autobiography Special Edition Range Rover for 5.8 million Naira.
Figure 2. Attempting to sell Range Rover on social media.
Interesting Notes: This actor shares social media connections with Onuegbu Ifeanyi Ephraim, Darlington Ndukwu, and Onukwubiri Ifeanyi Kingsley, all of whom were arrested in 2021 as part of Operation Falcon II. He is also considered to be well connected with other known BEC actors.
Protections and Mitigations
The best defense against BEC campaigns is a security posture that favors prevention. Please see our full list of recommendations for a prevention-focused approach to BEC.
Finally, for Palo Alto Networks customers, our products and services provide several capabilities designed to thwart BEC attempts, including:
Cortex XDR protects endpoints from all malware, exploits and fileless attacks associated with SilverTerrier actors.
WildFire® cloud-based threat analysis service accurately identifies samples associated with information stealers, RATs and document packaging techniques used by these actors.
Threat Prevention provides protection against the known client and server-side vulnerability exploits, malware and command and control infrastructure used by these actors.
Advanced URL Filtering identifies all phishing and malware domains associated with these actors and proactively flags new infrastructure associated with these actors before it is weaponized.
Users of AutoFocus™ contextual threat intelligence service can view malware associated with these attacks using theSilverTerrier tag.
Conclusion
While BEC schemes remain the most profitable and widespread form of cybercrime on the internet, private/public collaborative efforts continue to make tremendous strides in combating these threats on a global scale. The success of this most recent joint operation highlights the expanding capability of global law enforcement to coordinate and track actors as they travel abroad, ultimately leading to apprehension of BEC actors when they return to their home countries.
Palo Alto Networks was the first cybersecurity company to sign a partnership agreement with INTERPOL in 2017. This agreement served as the foundation for our collaborative efforts in combating criminal trends in cyberspace and other cyberthreats globally. Since then the partnership has continued to evolve, and today Palo Alto Networks remains a proud contributing member of INTERPOL's Gateway program.
![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)
Palo Alto Networks customers receive further protections against other malware families using similar sandbox evasion techniques through Cortex XDR or our Next-Generation Firewall with WildFire and Threat Prevention security subscriptions.
![This is an example POST request sent by PingPull as a beacon, where samp.exe was the filename, DESKTOP-U9SM1U2 was the hostname of the analysis system and 172.16.189[.]130 was the system's IP address.](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/06/word-image-77.png)
The ransomware creates an ID for the victim which has to be sent to the threat actor to make it possible to identify the victim and provide a decryptor. The ransom note also instructs victims to download 
![Figure 17. Snippet of Script in HTML Source Code xn--90a5ai[.]com](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/06/word-image-66.png)
![From clicksharelauncher.exe to DLL search order hijacking, to uxtheme.dll (proxy), to write and load DLL, to ClickRuntime-amd86.dll. Uxtheme.dll communicates with dnszonetransfer[.]com, which leads to the first C2, 51.38.89[.]53. ClickRuntime communicates with reporterror[.]net, which leads to the second C2, 51.75.57[.]245](https://unit42.paloaltonetworks.com/wp-content/uploads/2022/06/word-image-7.png)
Get updates from Unit 42 