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.
On April 6, 2022, VMware published a security advisory mentioning eight vulnerabilities, including CVE-2022-22954 and CVE-2022-22960 impacting their products VMware Workspace ONE Access, Identity Manager and vRealize Automation. On April 13, they updated their advisory with information that CVE-2022-22954 is being exploited in the wild.
Multiplewriteups detailing exploitation scenarios for the aforementioned two vulnerabilities were published in the last week of April, finally followed by a CISA Alert on May 18. The CISA Alert also calls out CVE-2022-22972 and CVE-2022-22973 – published on the same day and affecting the same products – as being highly likely to be exploited.
Unit 42 has observed numerous instances of CVE-2022-22954 being exploited in the wild. In this blog post, we share context around this observed activity, along with how the Palo Alto Networks product suite can be leveraged to protect against it.
2022-04-11: Proofs of concept available on GitHub. This is also the earliest date at which Unit 42 observed exploitation attempts and scanning activity.
2022-04-13:
VMware advisory updated with knowledge of active exploitation of CVE-2022-22954 in the wild.
2022-05-18:
Publication of VMware advisory VMSA-2022-0014 regarding CVE-2022-22972, CVE-2022-22973. Publication of CISA Alert.
As of this writing, no proofs of concept for exploitation of CVE-22972 or CVE-2022-22973 are known. This post will be updated with new findings as they are discovered.
CVE-2022-22954 in the Wild
CVE-2022-22954, a remote code execution (RCE) vulnerability due to server-side template injection in VMware Workspace ONE Access and Identity Manager, is trivial to exploit with a single HTTP request to a vulnerable device.
The list below details the exploits Unit 42 observed targeting this vulnerability that we deemed worth highlighting.
Direct Downloads
The injected commands worth mentioning that intended to further download payloads to a vulnerable machine can be categorized into the following broad categories:
Mirai/Gafgyt dropper scripts or variants
Webshells
Perl Shellbot
Coinminers
Scanning/Callbacks
Mirai/Gafgyt Dropper Scripts or Variants
We observed several instances of CVE-2022-22954 being exploited to drop variants of the Mirai malware. In most cases, the exploit was only used to drop the payload, however the payloads themself did not contain CVE-2022-22954 exploits for further propagation. Instead, they were either non-specific Mirai variants or contained previously known exploits such as CVE-2017-17215.
The exception to this is Enemybot, a currently prevalent botnet built with bits of code from both Gafgyt and Mirai source code. The exploits involving Enemybot eventually download Enemybot samples that themselves embed CVE-2022-22954 exploits for further exploitation and propagation.
Webshells
We observed the vulnerability exploited to download webshells, including:
A basic implementation that read a GET parameter value, Base64 decoded it, and used a ClassLoader to load the result.
The Godzilla Webshell that has also been used in previous campaigns exploiting other vulnerabilities.
Perl Shellbot
Certain injected commands result in the download of obfuscated Perl scripts. Deobfuscating these scripts reveals they are versions of the known bot family “Stealth Shellbot” that reaches out to an IRC server to listen for commands to perform. It has the ability to further make HTTP requests based on commands received. This would mean infected machines could then be directed to further perform scanning and exploitation activity, in addition to directly executing shell commands received from the command and control (C2) server on the target machine.
Figure 1. An example of Base64 injection observed in the wild.Figure 2. An example of Base64 injection observed in the wild.Figure 3. An example of Base64 injection observed in the wild.
This last command downloads a shell script that ultimately downloads and executes an XMRig coinminer.
SSH Key Targeting
We also observed some instances of injected payloads that were either trying to read authorized keys on vulnerable machines or were writing into the authorized_keys file to add to the machine’s list of accepted keys. Following is an example of such an attempt.
Figure 4. An example of an injected payload trying to affect authorized keys.
CVE-2022-22960 in the Wild
CVE-2022-22960 is a privilege escalation vulnerability in VMware Workspace ONE Access, Identity Manager and vRealize Automation instances, due to improper permissions in support scripts. The vulnerability can be leveraged to run commands as a root user on a vulnerable instance.
More specifically, this flaw exists since the default user for these VMware products, horizon, has access to several sudo commands, some of which involve paths that can be overwritten as well.
Attackers can, therefore, leverage CVE-2022-22954 to remotely execute commands to overwrite specific paths. If successful, CVE-2022-22960 can then be leveraged to execute these overwritten paths with root permissions using the sudo command.
Our research so far has shown one publicly known sample demonstrating exploitation of CVE-2022-22960 by overwriting the /usr/local/horizon/scripts/publishCaCert.hzn file.
The content of this exploit file can be observed below.
Figure 5. An example of an attempt to exploit CVE-2022-22960 observed in the wild.
Another proof of concept code sample is additionally available targeting the following 2 filepaths: /opt/vmware/certproxy/bin/certproxyService.sh /usr/local/horizon/scripts/diagnostic/getPasswordExpiry.hzn
Conclusion
Palo Alto Networks is still actively investigating a number of the aforementioned vulnerabilities, many of which do not have publicly available exploit code. Presently, customers may leverage the following to block or detect the threats communicated throughout this publication:
Palo Alto Networks Next Generation Firewall Threat Prevention blocks CVE-2022-22954 exploits with Signature 92483.
Cortex Xpanse was able to identify ~800 instances of VMware Workspace ONE Access connected to the public internet, and can be leveraged to enumerate potentially vulnerable instances within customer networks.
WildFire and Cortex XDR categorize all samples of supported file types as malware.
Additionally, all encountered URLs have been flagged as malware within PAN-DB, the Advanced URL Filtering URL 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
As further information or detections are put into place, Palo Alto Networks will update this publication accordingly.
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.
In Part 1 of this two-part blog series, we discussed briefly how XLL files are exploited to deploy Agent Tesla. During December 2021, we continued to observe Dridex and Agent Tesla exploiting XLL in different ways for initial payload delivery. A more in-depth look at the Dridex infection chain follows.
Threat actors behind Dridex have been using various delivery mechanisms over the years. In early 2017, we observed plain VBScript and JavaScript were being used. In later years, we observed many variations, including Microsoft Office files (DOC, XLS) compressed in zip. In 2020, we found the malware using Discord and other legitimate services to download the final payload. More recently, during December 2021, we received various Dridex samples, which were exploiting XLL and XLM 4.0 in combination with Discord and OneDrive to download the final payload.
In our previous blog focused on XLL files and Agent Tesla, we saw the abuse of the legitimate Excel-DNA framework. In this blog post, we will look into other infection chains. We will discuss different stages of the XLL and Excel 4 (XLM) droppers that deliver Dridex samples. We will also briefly look at the Dridex Loader.
Palo Alto Networks customers receive protections against the attacks discussed here through Cortex XDR or the WildFire cloud-delivered security subscription for the Next-Generation Firewall.
While XLM 4.0 is not new, there has been a lot of evolution in how malware has abused it since early 2020 Threat actors have gone from using simple, non-obfuscated macro formulas to creating complex hidden variants which finally utilize native services such as rundll32 to run a payload.
As the malicious usage of XLM 4.0 macros is quite new, vendors are striving hard to provide coverage in such cases.
The XLM document in this case comprises two spreadsheets – one contains formulae and the other simply contains some random data. See Figures 1-2 below.
Figure 1. The red “1” in the right side of the screenshot shows the macro 4.0 responsible for dumping an HTML application file (HTA). The red “2” at the top shows the output of highlighted formulae.Figure 2. The red box indicated by the number 1 shows an HTA script stored in ASCII values.
It can be seen that one of the formulae in the spreadsheet shown in Figure 1 tries to run with Mshta, so we can assume it is not really an RTF. Upon further analysis, we found that indeed it is an HTA. XLM 4.0 code in Sheet1 is responsible for reading ASCII values from Sheet2 (Figure 2) and generating the HTA file that downloads Dridex from Discord.
Figure 3. VBScript to download Dridex from Discord.Figure 4. Encoded Discord URL in HTA file.
It is difficult to say anything about the XLS itself until it finally downloads a malicious payload. Furthermore, the HTA is being dropped as RTF. This might confuse some security products because they could analyze the HTA as an RTF file and might lose detection. Additionally, the usage of Discord URLs makes the samples more evasive. (Though the examples given here involve Discord URLs, we have also observed similar usage of OneDrive URLs. See the GitHub link in the Indicators of Compromise section for specific examples of OneDrive URLs.)
XLL Dropper
In comparison to the malicious XLL files that we discussed in Part 1 of this blog series, this dropper is rather simple. An XLL file is just a DLL, but it must be executed using Excel. The proper detonation is important for detection.
Figure 5. Discord URLs found in XLL.Figure 6. XLL running Dridex Loader.
Active Directory Check
We think that both the XLL and VBScript downloaders are associated with the same actor because, as we can see, both perform a check to see whether the LOGONSERVER and USERDOMAIN environment variables are set. This would mean a system is on Active Directory.
Figure 7. HTA dropper checking for the environment variables LOGONSERVER and USERDOMAIN.Figure 8. XLL dropper checking for the environment variables LOGONSERVER and USERDOMAIN.
Discord URLs
We extracted around 1,400 URLs (see Indicators of Compromise section at the end of this post) from XLM and XLL files, however, at the time of analysis, only a few of them were still up and were found downloading only Dridex. An interesting thing to note is that DLL files are being downloaded as MKV. We saw that at the start of the infection chain that HTA was being dropped as RTF.
Brief Loader Analysis
As can be seen in Figure 6, the downloaded payload is being run with the command
rundll32.exe * DirSyncScheduleDialog. However, as we opened the file for further analysis, the method DirSyncScheduleDialog is not found in the export directory. It is interesting to note that that function name belongs to a legitimate Windows DLL.
Figure 9. The missing method(left) is shown, compared to the legitimate Windows loghours.dll with exported function DirSyncScheduleDialog (right).
Unpacking Stages
Decrypt and Load second-stage DLL from rdata section.
Second DLL further unpacks the final Dridex Loader.
Jumps to DirSyncScheduleDialog.
First Stage
The first stage is fairly simple in terms of functionality; its only job is to decrypt a small DLL from the rdata section and move it to allocated memory and run it.
However, there are a few anti-analysis tricks.
Usage of junk code.
A Large Loop with INT3 instructions.
Usage of undocumented functions such as ldrgetprocedureaddress and LdrLoadDll to avoid common hooks.
While junk code might hinder manual analysis, large loops containing INT3 breakpoints might delay the execution in some cases.
The first stage has a handful of functions. We renamed them to reflect trivial loader behavior.
Figure 10. Renamed functions (left); jump to allocated memory (center); anti-VM function, CC bytes replaced with NOP (right).
Second Stage
Once the first stage passes control to the in-memory DLL (Figure 8), it further unpacks the final payload and transfers control to it. The second stage is also trivial. However, the stage does include a few interesting anti-analysis tricks to note.
Calls Disablethreadlibrarycalls to increase invisibility of final DLL.
Checks LdrLoadDll for hooks.
Figure 11. Renamed functions (left), check for LdrLoadDll hook (center), disableThreadLibraryCalls in imports (right).
Final Dridex Loader
Finally, we are able to see a call to DirSyncScheduleDialog. It is interesting to note that Dridex Loader is not performing DLL side loading. However, the final payload is loaded as loghours.dll, a legitimate windows DLL.
Figure 12. A side-by-side comparison of the Export table from the Dridex Loader (left) and the legitimate loghours.dll (right).Figure 13. Dridex Loader EP; anti-VM loop can be noticed in start.
Micro VM
Dridex implements a micro VM, which adds an exception handler using AddVectoredExceptionHandler to emulate the call eax instruction.
Figure 14. Call to get_proc_address_by_hash function and CC CC bytes (call eax).Figure 15. Exception handler emulating call eax.
As can be seen in Figure 15, in the case of EXCEPTION_BREAKPOINT, the call eax instruction is being emulated. For the sandbox, this should not be a problem; however, it can hinder manual analysis. As can be seen, the exception handler only emulates one instruction. Patching these two INT3 instructions with call eax should not be a big deal. A simple IDA script to patch all CC CC instructions with FF D0 should do the trick.
Figure 16. Patched INT3 instruction with “call eax”.
API Hashing
API Hashing is trivial, however, we observed a few obfuscations and variations in this Dridex Loader.
Multiple hashing functions.
Masqueraded Prolog for hashing function.
We observed that, in order to hinder analysis further, this Dridex Loader is using multiple hashing functions. We observed at least two hashing functions and one masqueraded Prolog function, as can be seen below.
Figure 17. API hashing function sub_744102D4Figure 18. Masqueraded Prolog function.
It can be seen that the Prolog of the get_proc_address_1 function is not normal. The registers eax and edx are being used to pass module hash and API hash to the get_proc_address_1_mas function. It is possible to call get_proc_address_1 to set eax and edx. Alternatively, they can be set before calling get_proc_address_1_mas. If a researcher is writing an automation for resolving APIs – such as using AppCall – it is important to watch out for this trick.
We used the IDA AppCall feature to extract all APIs used in the loader. Based on extracted APIs, this Dridex Loader is not different from the Dridex Loader that was observed in early 2021.
Key functions of the Dridex Loader:
Check process privileges.
AdjustToken privileges.
GetSystemInfo
Uses the “Atomic Bombing” injection technique to load core payload downloaded from command and control server.
The Dridex Loader has been extensively analyzed. Here, we focused mainly on small tricks used across the infection chain to avoid detection and slow down analysis.
Conclusion
We observed a continued evolution of the infection chain. We saw how malware authors can evade detection engines using legitimate services such as Discord and OneDrive. We analyzed how malware authors continue to add more stages in the infection chain.
Lastly, we briefly looked into the Dridex payload. Although the final payload was similar to the previous Dridex version in terms of behaviour, we noticed an additional unpacking stage and a couple of new changes in the API hashing function. These simple yet powerful tricks that can be challenging for malware analysts, helping the malware avoid detection and slow down analysis.
Palo Alto Networks customers receive protections against the attacks discussed here through Cortex XDR or the WildFire cloud-delivered security subscription for the Next-Generation Firewall.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200
Indicators of Compromise
Indicators of compromise related to the malware discussed here can be found on GitHub.
Emotet is one of the most prolific email-distributed malware families in our current threat landscape. Although a coordinated law enforcement effort shut down this malware in January 2021, Emotet resumed operations in November 2021. Since then, Emotet has returned to its status as a prominent threat.
This blog provides a background on Emotet, and it reviews activity from this malware family since its return in November 2021. The information covers changes in Emotet operations from its revival through the end of January 2022. These examples will provide a more comprehensive picture and better indicate the worldwide threat Emotet currently poses.
Sometimes referred to as Geodo or Feodo, Emotet is Windows-based malware that first appeared in 2014 as a banking Trojan. Since then, Emotet has evolved into modular malware that performs various functions, including information stealing, spambot activity and loading other malware.
The threat actor behind Emotet is known through different designators, like Mealybug, MUMMY SPIDER or TA542.
Emotet’s primary method of distribution is through email.
Emotet is a prolific spammer. Emotet-infected computers often act as spambots, sending a dozen or more emails every minute that push more Emotet. This means thousands of Emotet emails can be sent by a single host every day. If hundreds of Emotet-infected hosts are active at any given time, this means hundreds of thousands of Emotet emails can be generated each day Emotet is actively spamming.
Emotet is evasive. Through a technique called hashbusting, Emotet generates different file hashes for malware distributed through its botnets. This ensures a malware sample’s SHA256 hash is different on each infected system. Emotet also uses obfuscated code in scripts used during its initial infection process.
Emotet is nimble. Its botnets frequently update IP addresses and TCP ports used for command and control (C2) communications. Emotet also frequently changes URLs hosting its malware, sometimes using dozens of different URLs each day.
Emails distributing Emotet contain malicious attachments, or they contain links to malicious files. These messages most often contain Microsoft Office files like Word documents or Excel spreadsheets. These Office documents contain malicious macro code. The code is designed to infect a vulnerable Windows host after a victim enables macros.
As it rose to prominence, Emotet began distributing other malware like Gootkit, IcedID, Qakbot and Trickbot.
By September 2019, Emotet's infrastructure was running on three separate botnets. These botnets were designated by the security research team Cryptolaemus as epoch 1, epoch 2 and epoch 3. The epoch designators are often abbreviated as E1, E2 and E3.
By 2020, a significant portion of malicious spam pushing Emotet used thread hijacking. Thread hijacking is a technique that utilizes legitimate messages stolen from infected computers' email clients. Emotet emails have frequently spoofed legitimate users and impersonated replies to these stolen emails.
Emotet occasionally takes a break from delivering malicious emails. Emotet's longest absence from the threat landscape occurred in early February 2020 and lasted more than five months. Emotet resumed operations in mid-July 2020, and it quickly surpassed other threats in sheer volume of malicious spam.
In January 2021, a collaborative effort by law enforcement agencies and other authorities disrupted Emotet operations. This effectively stopped the threat actor, and Emotet disappeared from our threat landscape.
Approximately 10 months later, Emotet resumed operations in mid-November 2021.
Visual Timeline
Figure 1 presents a timeline of Emotet operations from its return in mid-November 2021 through January 2022. The timeline highlights notable Emotet activity during the three month period covered in this blog.
Figure 1. Timeline of Emotet operations from November 2021 through January 2022.
The new Emotet infrastructure is running on two separate botnets designated as epoch 4 and epoch 5. These designators are often abbreviated as E4 and E5.
On Nov. 15, malicious spam for Emotet had one of three types of attachments: a password-protected ZIP archive, a Word document or an Excel spreadsheet. This follows the same method we had typically seen with previous Emotet infections. Examples and more details can be found in my post, “Emotet Returns.” See Figure 2 for a flow chart documenting the chain of events.
Figure 2. Chain of events for Emotet infections seen on Monday, Nov. 15, 2021.
Appendix A lists indicators of compromise from an infection on Wednesday, Nov. 18.
By Monday, Nov. 23, a batch file was added to the infection process as shown below in Figure 3.
Figure 3. Chain of events for Emotet infections seen on Monday, Nov. 23, 2021.
Emotet targets include various areas around the world. But even if victims are non-English speakers, templates for the Office documents are still in English as shown below in Figures 4 and 5 from an email targeting Italy.
Figure 4. Screenshot of Emotet email targeting Italy on Nov. 23, 2021.Figure 5. Attachment from Italian email contained Excel spreadsheet for Emotet with an English template.
At this time, enabling macros did not directly download and run the Emotet DLL. Instead, the macro code dropped a batch file shown in Figure 6 and ran it with the following command:
Figure 6. Batch file dropped after enabling macros for an Emotet infection on Nov. 23, 2021.
As an evasion technique, obfuscated script in the batch file generates a PowerShell command to retrieve an Emotet DLL and run it on the victim’s host. The PowerShell command uses a base64-encoded string as shown below in Figure 7.
Figure 7. PowerShell command using base64 encoded string.
Converting the base64 string to ASCII text reveals the script shown below in Figure 8. This script is designed to retrieve an Emotet DLL from one of seven URLs and save it to the C:\ProgramData\ directory. The Emotet DLL is run with rundll32.exe using a random string of characters as the entry point.
Figure 8. Deobfuscated script from the base64 string in Figure 4.
The new Emotet DLL is similar to Emotet DLLs before the January 2021 takedown. Emotet is made persistent under a randomly named folder under the infected user’s AppData\Local\Temp directory. The modified date of the persistent DLL is backdated exactly one week prior to the infection. Emotet is made persistent through a Windows Registry update. Figure 9 shows an example from Nov. 23.
Figure 9. Registry update to keep Emotet persistent after a reboot.
Since Emotet reappeared in November 2021, post-infection C2 activity consists of encrypted HTTPS traffic. Certificate issuer data for Emotet C2 HTTPS traffic uses generic values often seen with other malware families. Figure 10 shows an example of Emotet C2 activity filtered in Wireshark to reveal the certificate issuer data.
Figure 10. Reviewing certificate issuer data of Emotet HTTPS C2 traffic in Wireshark.
As shown above in Figure 10, certificate issuer data for Emotet C2 HTTPS traffic is:
id-at-countryName=GB id-at-statOrProvinceName=London id-at-localityName=London id-at-organizationName=Global Security id-at-organizationalUnitName=IT Department id-at-commonName=example.com
Of note, other malware families have used similar certificate issuer data, so this is not necessarily unique to Emotet.
Now disabled by Microsoft, App Installer is a protocol for Windows 10 used to install software directly from a web server, and it used XML-based app installer files with the extension .appinstaller. This protocol had been previously abused for BazarLoader malware attacks in November 2021. Figure 11 shows the flow chart for this type of Emotet infection.
The attack technique starts with complaint report-themed emails with links to malicious pages. These malicious pages are hosted on compromised websites, and they spoof Google Drive by using the same style of Google Drive pages, including a Google Drive icon that appears in the browser tab. The pages have links to supposedly preview a PDF-based complaint report. The link actually leads to a malicious .appinstaller file designed to infect a vulnerable Windows 10 host with Emotet.
Below, Figure 12 shows a thread-hijacked email from Nov. 30 with the malicious link, and Figure 13 shows the associated complaint page with a link to the malicious .appinstaller file.
Figure 12. Thread-hijacked email from Nov. 30 with link to page for malicious app installer.Figure 13. Fake complaint report page with link to .appinstaller file for Emotet.
As shown above in Figure 13, the .appinstaller file pretends to be an Adobe PDF component. In this case, criminals were abusing Microsoft Azure to host the malicious files. Below, Figure 14 shows a malicious .appinstaller file opened in a text editor.
Figure 14. Malicious .appinstaller file used for Emotet on Nov. 30.
The malicious .appinstaller file shown above in Figure 14 retrieves a malicious ZIP archive appended with an .appxbundle file extension from the same server. Below, Figure 15 shows contents of the malicious .appxbundle.
Figure 15. Malicious .appxbundle used for Emotet infection on Nov. 30.
The malicious .appxbundle impersonating an Adobe program contains various files including ZIP archives with an .appx file extension. Together, the entire .appxbundle is designed to retrieve an Emotet DLL and run it on a vulnerable Windows host.
Indicators and further details from the Nov. 30 activity can be found at Malware Traffic Analysis. Due to the nature of these app installer files, this infection method was initially difficult to detect. Fortunately, Microsoft quickly shut down Azure file servers hosting the app installer files. Microsoft has also disabled the app installer protocol, so this no longer remains an avenue of attack for Emotet or other malware.
Appendix B lists indicators of compromise from an Emotet infection abusing Microsoft’s App Installer on Nov. 30.
Emotet in December 2021
Throughout November 2021, examples of Emotet infections revealed data exfiltration and spambot activity. No indicators of followup malware were publicly reported until December 2021. By Dec. 7, the Cryptolaemus research team confirmed Cobalt Strike had been deployed to Emotet-infected Windows hosts.
December 2021 saw at least one more wave of emails from Emotet attempting to abuse Microsoft’s App Installer protocol. However, Emotet quickly moved on to other infection patterns and used different templates for Office documents, mostly Excel spreadsheets.
In the week leading to Christmas day, Emotet emails contained links to web pages on various compromised websites. These pages also pretended to be from Google Drive, and they had links to download malicious Excel files. In this case, Emotet started using a new infection pattern as shown in Figure 16.
Figure 16. Emotet infection pattern seen from Dec. 21-Dec. 24.
Above, Figure 16 reveals a process Emotet occasionally used through at least February 2022. We previously reported details on one such variation from January. Appendix C lists indicators of compromise from an Emotet infection using this method on Dec. 21.
Below, Figure 17 shows an email from Dec. 23 pushing Emotet, Figure 18 displays the website from the email link, and Figure 19 reveals the downloaded Excel spreadsheet.
Figure 17. Example of email from Dec. 23 pushing Emotet.Figure 18. Web page delivering malicious Excel spreadsheet leading to Emotet on Dec. 23.Figure 19. Malicious Excel spreadsheet downloaded from page shown in Figure 17.
On Thursday, Dec. 24, we saw similar emails with Christmas-themed subject lines and holiday wishes in the message text. This wave of emails delivered the same style of Excel spreadsheet shown above in Figure 19.
Below, Figure 20 shows one of these Christmas-themed emails, and Figure 21 displays the associated web page that delivered an Excel spreadsheet.
Figure 20. Example of Christmas-themed email from Dec. 24 pushing Emotet.Figure 21. Web page delivering malicious Excel spreadsheet leading to Emotet on Dec. 24.
After Dec. 24, Emotet stopped spamming until after the new year.
Emotet in January 2022
On Tuesday, Jan. 11, 2022, Emotet resumed spamming after its holiday break. The emails continued with links to fake complaint pages, and the pages were sometimes customized to include the recipient’s name. This method was prevalent until Jan. 20.
Figures 22-24 show one such example from Jan. 20. In this example, the recipient’s name has been sanitized to read as “Solomon Grundy” with an AOL email address, and the spoofed sender has been sanitized to read as alan.scott@thegreenlantern[.]net.
Figure 22. Emotet email from Jan. 20.Figure 23. Fake complaint report page with recipient’s name sending Excel spreadsheet for Emotet.Figure 24. Excel spreadsheet for Emotet downloaded from fake complaint report web page.
Appendix D lists indicators of compromise from an Emotet infection using this method on Jan. 11.
By Friday, Jan. 21, Emotet emails went back to using attached Excel spreadsheets or password-protected ZIP archives containing Excel spreadsheets. Throughout the rest of the month, Excel spreadsheets for Emotet alternated between the template shown above in Figure 24 and the template shown below in Figure 25.
Figure 25. Excel spreadsheet template seen during the last full week of January 2022.
In January, we continued to see reports of Emotet pushing Cobalt Strike. During our lab tests, we routinely saw Emotet-infected hosts generate spambot activity starting from 35-45 minutes after the initial infection.
Conclusion
Since its return in November 2021, Emotet has once again become one of the most prolific malware families in our current threat landscape. Hundreds of thousands of emails can be generated each day Emotet is actively spamming. Hashbusting, code obfuscation and other evasion techniques make Emotet a significant threat.
Windows users can lower their risk from Emotet through spam filtering, proper system administration and ensuring their software is patched and up to date. Palo Alto Networks customers are further protected from Emotet through Cortex XDR and our Next-Generation Firewall with WildFire and Threat Prevention subscriptions.
Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Indicators of Compromise
Due to hashbusting, daily changes in malware URLs and frequent changes for infection patterns, we can see hundreds of new indicators for Emotet every day. These indicators are too numerous and changes are too frequent to be useful in any single list. However, abuse.ch is a research project that provides free trackers for Emotet botnet command and control servers, URLs hosting Emotet malware and Emotet malware samples.
Appendices A, B, C and D provide a small selection of indicators referenced in this blog post.
Appendix A: Emotet epoch 4 activity on Nov. 18, 2021
SHA256 hashes for seven examples of password-protected ZIP archives:
SHA256 hash: 555dff455242a5f82f79eecb66539bfd1daa842481168f1f1df911ac05a1cfba File size: 485,376 bytes File location:hxxp://jamaateislami[.]com/wp-admin/FKyNiHeRz1/ File location:C:\ProgramData\1245045870.dll File location:C:\Users\[username]\AppData\Local\Tzbklmcf\ljkklzcncxkf.pgk Run method from Windows Registry update: rundll32.exe [filename],truHNmRuL Note 1: This was generated using 1811.doc Note 2: The entry point used with rundll32.exe can be any alpha-numeric value
HTTPS Emotet C2 traffic from an infected Windows host:
51.178.61[.]60port 443 103.161.172[.]108 port 443 122.129.203[.]163 port 443
Traditional ransomware mainly targets on-premises IT infrastructure but doesn't work well in cloud environments, which is one reason we haven't heard much about ransomware in public clouds. However, ransomware actors could adapt their tactics, techniques and procedures (TTPs) to be more cloud native, and now is a good time for organizations to get ahead of this possibility.
Ransomware incidents have severely disrupted business operations across all industries. In 2021, the average ransom demand was $2.2 million, and the average payment was $541,010. Since 2020, researchers have detected at least 130 different ransomware families. There is still no sign of a decrease in the frequency and severity of ransomware attacks.
While there are many known ransomware families, there is no known ransomware actor targeting cloud environments. With the increasing demands of the remote workforce, many organizations are migrating on-premises data centers to the public clouds. Cloud-native infrastructure is also the de facto way that startups can quickly build their business.
Here, we explore how ransomware threat actors might operate in cloud environments – what approaches they might use to attack and impact resources in public clouds. We ask questions including:
Are cloud-hosted resources more resilient to ransomware attacks?
What types of cloud resources are more vulnerable to ransomware?
How might adversaries attack cloud resources?
Our goal is to help organizations prepare for this threat while it is still largely theoretical. The discussed scenarios are intended to be broad and not specific to any cloud service provider.
Knowing that threat actors such as Rocke and TeamTNT target unsecured cloud environments, it is sensible that ransomware actors will also turn to the cloud sooner or later. Due to the fundamental difference between cloud-native and on-premises IT infrastructure, existing ransomware will not be effective in attacking cloud environments. Ransomware actors will need new TTPs in order to target cloud workloads.
However, we have seen threat actors evolve in this way to target cloud workloads before. In our latest Cloud Threat Report, “IAM The First Line of Defense,” we designated cloud threat actors as a new type of threat, defining a cloud threat actor as “an individual or group posing a threat to organizations through directed and sustained access to cloud platform resources, services or embedded metadata.”
Ransomware actors may also find ways to adapt to the cloud – especially if they begin to see the rewards as worth the effort. Unit 42 researchers identified the possible infection vectors, vertical/lateral movements, targeted resources and impact of such attacks. We incorporated our knowledge of existing ransomware groups and known security incidents in public clouds to derive possible TTPs of cloud-targeted ransomware attacks.
Overall, we believe that cloud environments are more resilient to ransomware. The shared responsibility model significantly reduces users' burden in securing the infrastructure, platform and software in the cloud. API-driven cloud services make monitoring, automation and centralized access control easier. Cloud-native backup services provide reliable ways to back up cloud resources. Nevertheless, it is the user's responsibility to securely configure, operate and monitor cloud workloads. As IT infrastructure grows with the business, securing thousands of dynamic workloads in a multi-cloud and hybrid cloud environment can become challenging.
Palo Alto Networks customers can get ahead of potential cloud-based ransomware through Prisma Cloud’s threat detection capability, which can identify anomalies and zero-day attacks. Unit 42 offers a ransomware readiness assessment that organizations can use to enhance the ability to quickly and effectively respond to a ransomware attack. Cloud incident response services can help address and mitigate cloud security incidents if they do happen.
Phishing, exposed remote desktop protocol (RDP), compromised credentials and unpatched vulnerabilities are the most common attack vectors that ransomware actors exploit to gain initial access, as detailed in the Unit 42 Ransomware Threat Report. These techniques are simple but effective and can be carried out against any individual or organization. Some ransomware combines multiple techniques and utilizes commodity malware such as Emotet and TrickBot to breach a victim's environment. We believe attackers can also use the same techniques to gain initial access to cloud environments.
As with on-premises IT infrastructure, where hundreds of employees may work in the same network, hundreds of engineers may share and work in the same cloud infrastructure. If an attacker can compromise one engineer's laptop, that attacker can then potentially pivot from the laptop to the cloud infrastructure. This helps explain why attackers often see credentials as a prime target.
Another common attacker vector is unpatched vulnerabilities exposed to the public internet. Our previous research on exposed vulnerabilities found that 24% of exposed VM instances in public clouds have known vulnerabilities. If an attacker could find and compromise a vulnerable VM instance on the internet, the instance could serve as a gateway into the victim's cloud infrastructure.
Below are two hypothetical examples showing how an attacker could use these techniques to gain an initial foothold in a victim's cloud environment.
Example 1: Compromised Laptop via Phishing Emails
If a developer's laptop is compromised – for example, by phishing emails – cloud credentials stored on the laptop could give attackers initial access to an organization’s cloud infrastructure. Cloud Service Providers’ (CSPs) command-line tools commonly store credentials in specific directories on the host. Malware that targets cloud environments often enumerates these directories.
If the developer also uses CSPs’ web consoles, attackers may also find passwords in the password manager or active access tokens in the browsers. Any retrieved credential could be used to impersonate the developer and gain initial access to the victim's cloud infrastructure.
Example 2: Compromised Server via Unpatched Vulnerabilities
Any remote code execution (RCE) vulnerability exposed to the internet may allow attackers to gain initial access. For example, an attacker can remotely exploit an RDP server with the BlueKeep vulnerability and gain full control of the server. Since the server is in the victim's cloud environment, the attacker may find cloud credentials on the server and use the credentials to pivot into the cloud.
Another way that attackers can harvest cloud credentials is through metadata services. Metadata services listen on a special IP address that applications on a VM instance can query to obtain the instance's information such as tags, region and cloud access tokens. All CSPs support metadata services. Any exposed vulnerability that allows attackers to reach this special IP address may allow the attacker to steal cloud access tokens. Vulnerabilities like server-side request forgery (SSRF) are commonly exploited to access metadata services.
Best Practices to Limit Initial Access
These hypothetical examples both illustrate the value of using best practices to limit the potential for initial access. In particular, organizations can reduce the likelihood of cloud incidents – ransomware or otherwise – by educating employees about phishing, improving identity and access management policies and limiting what is exposed to the public internet. If possible, use the latest version of the metadata service to prevent attacks like SSRF.
Execution
After an attacker gains the initial foothold, their next step is to plan and execute the attack.
The two most probable avenues for executing an attack in cloud environments are through control plane APIs or data plane APIs.
In an on-premises IT infrastructure, administrators typically directly connect to each endpoint – such as a router, a firewall or network-attached storage – to manage each device. In contrast, users rarely directly connect to resources in a cloud environment. Instead, they authenticate with a CSP's API gateway and call a set of control plane APIs to manage cloud resources. This centralized access control is a double-edged sword. It simplifies the access control management, but a leaked credential with high privilege can also be devastating, as every cloud resource may be accessed with the same key.
Control plane APIs are used for resource management, such as creating/configuring networks, creating/deleting VM instances and reading/writing resource policies. Data plane APIs are used for accessing data inside individual resources – for example, reading/writing files on a virtual machine instance or querying data from a database table.
Using the hypothetical examples in the Initial Access section, an attacker could gain access to the control plane if cloud credentials are found on a compromised laptop or RDP server. Once the attacker is in possession of a cloud credential with sufficient privileges, the attacker can authenticate with the API gateway and access cloud resources.
The attacker may also compromise cloud resources through the data plane. On a compromised laptop, the attacker may find data plane credentials such as VMs’ SSH keys or database passwords. From a compromised RDS server exposed to the internet, the attacker may use data plane APIs to search for other vulnerable servers in the same private network or harvest credentials in the environment variables or memory.
Attackers can move from the data plane to the control plane or vice versa. For example, an attacker who compromises a virtual machine instance through the data plane APIs may find control plane credentials in the instance's metadata. On the other hand, an attacker who can access virtual machine service through control plane APIs may use features like code execution[1][2] and remote access control to gain access into a VM instance and attack other hosts from the VM instance through the data plane APIs. In the next section, we will show it is common for attackers to move between the control plane and the data plane to escalate their privileges.
Figure 1. Control plane (red) and data plane (blue) in a cloud infrastructure.
Best Practices to Limit Execution
Modern cloud-native infrastructure is built with layers of security boundaries, e.g., containers, namespaces, virtual machines, virtual private clouds and account isolation. When possible, create a boundary for each logically separated resource and workload to reduce the impact in case of security accidents.
Privilege Escalation and Lateral Movement
The objective of a ransomware attack is to extort for ransom by disrupting a victim's business operations and causing loss of business revenue. Attackers accomplish this through privilege escalation and lateral movement – techniques that can allow them to gain access to valuable resources.
Traditional lateral movement techniques such as remote service hijacking or alternation bypass can still allow attackers to move laterally in the data plane. For example, attackers may use tools like mimikatz to dump credentials in the compromised VM instance, identify reachable endpoints in the same network and pivot to another VM instance in the same virtual private clouds (VPC). The vulnerabilities that ransomware routinely exploits can allow attackers to escalate privileges or perform remote code execution on the compromised VM instances.
However, the cloud has some additional protections against these vulnerabilities – such as CSPs’ hypervisors or VPC perimeters, which virtually isolate a group of cloud resources. At the time of writing, no known malware exploits vulnerabilities in CSPs’ infrastructure to break out of the security boundary. CSPs are also more diligent in patching and securing their infrastructure than many individual organizations. This means that after attackers compromise a VM instance, they for the most part can’t gain access to other cloud resources outside the security boundaries, unless they find ways into the control plane and pivot using control plane APIs.
As a result, the more concerning way of achieving privilege escalation and lateral movement is through control plane APIs. Attackers could potentially bypass all the security boundaries if they obtained the right credentials. The defense mechanism for securing control-plane APIs is identity and access management (IAM). Every request sent to the control plane needs to be first examined by IAM. Any unauthenticated or unauthorized request will be dropped immediately.
Why Organizations Should Use Strong IAM Policies
IAM is the most critical component that governs the authentication and authorization of every resource in a cloud environment. Put simply: IAM is the first line of defense in most cloud environments. Therefore, a more "cloud native" way of performing privilege escalation and lateral movement in the cloud is through IAM misconfigurations.
Due to cloud infrastructure's complexity and dynamic nature, cloud identities are often overly permissive, meaning that they are granted more permissions than they actually need. We recently analyzed cloud accounts from 200 different organizations and found that nearly all lacked the proper IAM management policy controls to remain secure.
For example, a user who only needs to access one storage bucket may be granted permission to access all the buckets in the same account/subscription. Similarly, a container that only needs to write to a database may also be granted read and delete permissions. Our previous Cloud Threat Report described how misconfigured IAM controls allowed Unit 42 researchers to gain access to source code repositories and many private keys of a multi-million dollar SaaS company.
It is common that combining a set of permissions enables another unintended permission, leading to privilege escalation. For example, suppose a user has permission to:
Access a VM instance.
Modify the identity associated with the instance using actions that can update or impersonate the role associated with the VM.
In that case, the user may associate the VM instance with a more privileged identity and use this instance to gain more privileged permission.
Prior research such as IAM-Vulnerable, GCP Privilege Escalation, and Azure Privilege Escalation identified many vulnerable paths to achieve privilege escalation. Tools like pacu and skyArk can help identify privilege escalation vulnerabilities in IAM – and show organizations where to focus to improve security posture.
This blog focuses on the potential TTPs of ransomware actors in the cloud. The hypothetical attacks demonstrated in the next section assume that the attacker already performed various lateral movement and privilege escalation to gain access to the targeted resources.
Impacts
Ransomware impacts the availability or confidentiality of a targeted system. Attacks like data encryption and system lockout affect availability, and attacks like eavesdropping and data exfiltration affect confidentiality. In a double extortion attack, both availability and confidentiality are impacted. 60% of the top ransomware in 2021 attempted to both encrypt the data and exfiltrate the data.
Figure 2. Impacts of ransomware attacks.
Traditional Ransomware
We consider ransomware that targets Windows or Linux systems in on-premises infrastructure as traditional ransomware, e.g., Ryuk, Maze (ChaCha), Defray777. This type of ransomware attempts to infect many hosts within an organization and then encrypts files on the disk. Traditional ransomware uses file I/O operations to read and write files in the file systems. Any files that can be accessed through file I/O operations are vulnerable to traditional ransomware, including cloud-based file systems remotely mounted to a host such as Network File System (NFS) and Ceph File System (CephFS).
Fortunately, due to the differences in file access methods and architectural design, traditional ransomware is less effective in cloud environments.
Most Cloud Storage Is Accessed Through APIs, Not File Systems
More and more cloud-native applications rely on CSPs’ APIs to access storage resources. Clients and servers can access the storage resources using the same APIs regardless of operating systems or platforms. Applications running on mobile devices, browsers or IoT devices can download/upload any size and type of data. These API-based cloud storage systems are not vulnerable to traditional ransomware because they are not exposed to file systems.
Most Compute Resources Are Immutable and Ephemeral
The design and architecture of cloud-native workloads make them more resilient to traditional ransomware. Compute resources such as VM instances and containers are usually dedicated to running applications, not storing data. Ransomware can still infect these compute resources, but there is no valuable data to encrypt or steal. Furthermore, compute resources are designed to be immutable and ephemeral, meaning that these resources do not change after deployment, and they only “live” for a short time. They are automatically created and deleted by the orchestrator based on the demands of the situation. If an application in a compute resource needs to be updated, a new VM instance or container is deployed to replace the old one. These characteristics make establishing persistence or exfiltrating data from these computer resources difficult for attackers, which contributes to why cloud environments have so far been more resilient against ransomware than on-premises environments.
Cloud-Native Ransomware
Threat actors, however, may develop new TTPs to make it easier for them to launch ransomware attacks in cloud environments. By thinking ahead to what those TTPs might entail, organizations can better prepare to defend against them – and can identify key best practices for improving cloud security posture.
TTPs for cloud ransomware actors would likely focus on finding the cloud resources that contain persistent data such as object storage, block storage and databases, and then on using cloud APIs to access and encrypt that data.
Because the APIs for accessing every cloud service are very different, threat actors might choose to focus on specific services, or they might develop a different payload for each targeted service (as some traditional ransomware actors today have developed payloads targeting different operating systems).
For example, ransomware targeting one CSP’s storage service will be different from ransomware targeting another CSP’s storage service. Ransomware targeting an object storage service will be different from ransomware targeting a database service. Considering the number of different data storage services in each CSP, the good news for organizations is that threat actors would likely need more effort in order to launch a successful ransomware attack in the cloud.
Hypothetical Attack
In this section, we hypothesize a high-level attack scenario. The attack scenario can help us understand the possible TTPs ransomware actors would use in the cloud and create protection strategies against these attacks. The next section will cover several protection and mitigation practices.
For this hypothetical attack, we assume that the attacker gains initial access from a leaked credential and executes the attack using the control plane APIs. Through lateral movement and privilege escalation, the attacker eventually gains access to the targeted data. The attacker then attempts to encrypt the storage resources using the CSP’s data-at-rest encryption capabilities. The data-at-rest encryption is usually managed by the CSPs and transparent to the users, but if the attacker can control the encryption key, they may lock others out of accessing the resources. The attack scenario contains three stages: Create Master Key, Modify Targeted Resource and Hide Master Key, as shown in Figure 3.
Figure 3. Hypothetical attack scenario.
Create Master Key: As data encryption in public clouds is often done by cloud-native key management services, an attacker might start by creating an attacker-controlled master key using the CSP’s key management services. The key can be created in the victim's cloud environment or in the attacker’s cloud environment. In the second case, the attacker must also have the “cross-account” permission to access cloud resources in one account from another account.
Modify Targeted Resource: In the second step, the attacker attempts to use the attacker-controlled key to encrypt the victim's cloud resources. Some cloud resources allow the data-at-rest encryption keys to be changed after the resources have been created, and the existing data will be automatically re-encrypted with the new keys. Some cloud resources do not allow data-at-rest encryption keys to be changed after the resources have been created. The attacker in this case would then create a decrypted data dump (e.g., snapshots), encrypt the data with the attacker-controlled key, and overwrite the original resource.
Hide Master Key: The last step is to hide the attacker-controlled keys from the victims or CSPs. An attacker might remove the keys from the cloud environments and locally store the raw key material that can be used to reconstruct the encryption key.
Protection and Remediation
The root causes of the hypothetical attack scenario were a credential leak and an overly permissive identity. If the victim did not use long-lived credentials, or if the permissions granted to the credential had been more restricted, the attack would not be possible. Most cloud workloads do not need full access to the key management service, nor do they need to update the storage service's data-at-rest keys. As a result, securing identities is the most important step to start securing a cloud environment.
While a comprehensive protection strategy against ransomware attacks is out of the scope of this research, major CSPs have all published guidelines to protect their customers (for example, see guidelines from Azure and GCP). Below is a list of best practices that are CSP-agnostic.
Enforce multi-factor authentication (MFA) for APIs that modify business-critical resources such as database deletion, snapshot deletion and encryption key update.
Use Federated Identity Management (FIM) to centrally manage access control.
Grant each user and identity only the necessary permissions for their jobs. (In other words, follow the principle of least privilege). Tools such as AirIAM and IAM analyzer can help generate least-privilege permissions.
Create backups for business-critical data regularly and automatically.
Create cross-region and cross-account backups to prevent having a single point of failure.
Test and verify the backups regularly.
Shift-left security:
Adopt shift-left security to identify vulnerabilities and misconfigurations as early as possible.
Integrate vulnerability scanner and IaC scanner into every CI/CD pipeline.
Tools such as Checkov can identify insecure configurations in infrastructure as code (IaC) across all major CSPs.
Conclusion
Public clouds offer agile, reliable and scalable storage services that on-premises data centers would find almost impossible to keep up with. As cloud adoption is getting faster and more prevalent, cybercriminals will also find new ways to go after valuable data.
Although we have not seen ransomware groups targeting cloud environments, ransomware attacks are probable and concerning, and the time to consider and prepare for the possibility of ransomware in the cloud is now. Our hypothetical attack demonstrates that control plane APIs could be abused to encrypt data in cloud storage and database.
Overall, we think public clouds are more secure and resilient against ransomware attacks than traditional environments. Centralized APIs, immutable workloads and cloud native-backup services all make protecting cloud resources easier. In a shared responsibility model, users can focus more on the applications, and the CSPs take care of the infrastructure, platform or software, which significantly reduces the attack surface compared to an on-premises data center. With the assistance of Cloud Security Posture Management (CSPM), Cloud Workload Protection Platform (CWPP) or Cloud Infrastructure Entitlement Management (CIEM) solutions, this also makes managing thousands of dynamic cloud workloads feasible.
Unit 42 offers a ransomware readiness assessment that organizations can use to enhance the ability to quickly and effectively respond to a ransomware attack. Cloud incident response services can help address and mitigate cloud security incidents if they do happen.
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)
This blog describes an attack that Unit 42 observed utilizing malicious compiled HTML help files for the initial delivery. We will show how to analyze the malicious compiled HTML help file. We will then follow the chain of attack through JavaScript and multiple stages of PowerShell and show how to analyze them up to the final payload.
The attack is interesting because attackers are often looking for creative ways to deliver their payloads. Their purpose in doing so is twofold:
An attempt to bypass security products.
An attempt to bypass security training.
Potential victims may have been trained to avoid documents, scripts and executables from unknown senders, but it is important to be careful of almost any filetype.
This particular attack chain delivered Agent Tesla as the final payload. Agent Tesla is well-known malware that has been around for a while. Agent Tesla focuses on stealing sensitive information from a victim’s computer and sending that information to the attacker over FTP, SMTP or HTTP. It does this primarily via keystroke logging, screen capturing, camera recording and accessing sensitive data.
Palo Alto Networks customers are protected from malware families using similar anti-analysis techniques with Cortex XDR or the Next-Generation Firewall with WildFire and Threat Prevention security subscriptions.
The initial attack sent a 7zip compressed file named ORDER OF CONTRACT-pdf.7z, which contained the single malicious compiled HTML help file ORDER OF CONTRACT-pdf.chm (SHA256: 081fd54d8d4731bbea9a2588ca53672feef0b835dc9fa9855b020a352819feaa). When the victim opens the help file, this apparently innocuous window displays.
Figure 1. Decoy HTML help window.
The help file can be extracted using 7zip to view the contents. The interesting file is the kkjhk.htm file, which displays the decoy window and executes the code.
Figure 2. The help file contents.
The file contains obfuscated JavaScript that is executed when the file is opened.
Figure 3. Obfuscated JavaScript code in kkjhk.htm.
We can deobfuscate this code by opening the file in Chrome and using the Chrome Developer Tools. The code above shows that the result that is returned is stored in the r variable. We can use the JavaScript debugger in Chrome Developer Tools to break on the return statement. After we have halted execution on our breakpoint we can then view the contents of the r variable and copy that for further analysis.
Figure 4. Debugging kkjhk.htm in Chrome Developer Tools.
The contents of the r variable show the HTML code to display the decoy message and a command to execute PowerShell.
Figure 5. Deobfuscated contents of kkjhk.htm.
Initial PowerShell
The obfuscated PowerShell code is executed in the background when the file is opened.
Figure 6. Initial obfuscated PowerShell.
We can deobfuscate this code so that we can read it more easily by removing the final obfuscated Invoke-Expression cmdlet (IEX()). Attackers often insert backticks into sensitive commands like this to avoid simple string recognition because PowerShell ignores these characters. We can then see that the sample utilizes the PowerShell Test-Connection cmdlet to ping Google to verify connectivity before continuing. The sample then downloads and executes code from http://pk-consult[.]hr/N2.jpg.
Figure 7. Deobfuscated initial PowerShell.
Second Stage
The downloaded content is not actually a jpeg, but rather further PowerShell code that is executed. We can see below that it decompresses and loads several byte arrays in memory.
Figure 8. Second stage.
We can modify the sample simply to output the byte arrays to files by commenting out the execution and writing them to files.
Figure 9. Writing byte arrays to files.
Final Agent Tesla Payload
We are left with a loader DLL in $decompressedByteArray (SHA256: 0fd2e47d373e07488748ac63d9229fdef4fd83d51cf6da79a10628765956de7a) and a gzip compressed Agent Tesla in $vhRo (SHA256: c684f1a6ec49214eba61175303bcaacb91dc0eba75abd0bd0e2407f3e65bce2a). The loader DLL loads Agent Tesla into the RegAsm.exe process to execute.
This Agent Tesla sample uses FTP and connects to ftp.videoalliance[.]ru for data exfiltration.
Conclusion
Malicious actors are often looking for creative or different ways to deliver their malicious payloads. Microsoft Compiled HTML files are another file format that can be abused by malicious actors in addition to the more common document or script delivery methods used. It is important to make sure that users are trained to be careful of any attachments, especially from unknown senders.
3446ec621506d87d372c596e1d384d9fd2c1637b3655d7ccadf5d9f64678681e ORDER OF CONTRACT-pdf.7z 081fd54d8d4731bbea9a2588ca53672feef0b835dc9fa9855b020a352819feaa ORDER OF CONTRACT-pdf.chm 9ba024231d4aed094757324d8c65c35d605a51cdc1e18ae570f1b059085c2454 N2.jpg 0fd2e47d373e07488748ac63d9229fdef4fd83d51cf6da79a10628765956de7a GC.dll c684f1a6ec49214eba61175303bcaacb91dc0eba75abd0bd0e2407f3e65bce2a Agent Tesla dotNet executable
![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 