Wireshark Tutorial: Decrypting RDP Traffic

Posted on by Brad Duncan

Executive Summary

In recent years, Remote Desktop Protocol (RDP) has been exploited by attackers to access unsecured servers and enterprise networks. Since 2017, RDP has become a significant vector in malware attacks using ransomware. Security professionals have increasingly focused their attention on this protocol by writing signatures to detect RDP vulnerabilities and prevent attacks.

As a proprietary protocol from Microsoft, RDP supports several operating modes that encrypt network traffic. Unfortunately, this encryption makes writing RDP signatures difficult because RDP content is hidden.

Fortunately, we can establish a test environment that provides a key file, and we can use that key to decrypt a packet capture (pcap) of the RDP traffic in Wireshark.

This blog demonstrates how to prepare the environment, obtain a decryption key and use it to decrypt RDP traffic.

Requirements

The following are necessary to get the most value from this tutorial:

  • A virtual environment to run two Windows hosts like VirtualBox or VMware.
  • An understanding of how to set up and use RDP.
  • An RDP client. We use a host running Windows 10 Professional for this tutorial.
  • An RDP server. This can be another Windows host with RDP enabled, or it can be a non-Windows host running FreeRDP.
  • A way to record the network traffic between these two hosts. This is most easily done within a virtual environment.
  • Wireshark version 3.0 or better.
  • A basic knowledge of network traffic fundamentals.

Overall Process

The overall process follows seven general steps:

Step 1: Set up a virtual environment with two hosts, one acting as an RDP client and one acting as an RDP server.

Step 2: Remove forward secrecy ciphers from the RDP client.

Step 3: Obtain the RDP server's private encryption key.

Step 4: Capture RDP traffic between the RDP server and Windows client.

Step 5: Open the pcap in Wireshark.

Step 6: Load the key in Wireshark.

Step 7: Examine RDP data.

Step 1: Set Up Virtual Environment

The two most common virtual environments for this type of analysis are VirtualBox or VMware Workstation for Windows and Linux. VMWare Fusion is used for macOS. VirtualBox is free, while VMware is a commercial product.

This tutorial does not cover setting up virtual machines (VMs) in a virtual environment. The basic structure of our lab used for this tutorial is shown below in Figure 1.

The lab setup used for this tutorial on decrypting RDP traffic includes a physical host running a virtualization environment, a virtual LAN, a Windows VM acting as an RDP client and a Windows VM acting as an RDP server.
Figure 1. Lab setup used for this tutorial.

Our lab environment contained two Windows 10 hosts. One of the hosts acted as an RDP client, and the other acted as an RDP server. We recorded network traffic from an RDP session between these two hosts from the virtual LAN.

Step 2: Remove Forward Secrecy Ciphers From RDP Client

Some encryption ciphers provide forward secrecy, which is also known as perfect forward secrecy. These types of ciphers create multiple session keys for an SSL/TLS connection. With forward secrecy, we cannot decrypt SSL/TLS traffic using a single private encryption key from the RDP server. Therefore, we had to remove configuration options that support forward secrecy on the RDP client.

For this tutorial, our RDP client was a host running Windows 10 Pro. This host has a built-in RDP client.

Microsoft has published details on removing configuration options that support forward secrecy in the articles, “Manage Transport Layer Security (TLS)” and “Prioritizing Schannel Cipher Suites.” Below is a step-by-step process that we used.

Open the Group Policy Management Console gpedit.msc as an administrator as shown below in Figure 2.

Open the Group Policy Management Console gpedit.msc as an administrator by clicking "Run as administrator," as shown here.
Figure 2. Running the Group Policy Editor in Windows 10 Pro as an administrator.

From the console, use the following menu path:

  • Computer Configuration.
  • Administrative Templates.
  • Network.
  • SSL Configuration Settings.

Below, Figure 3 shows how to find SSL Configuration Settings.

The large black arrow in the screenshot indicates the location of the SSL Configuration Settings in the file system.
Figure 3. Getting to the SSL Configuration Settings.

Under SSL Configuration Settings, double-click the entry for SSL Cipher Suite Order as shown below in Figure 4.

Figure 4. Getting to the SSL Cipher Suite Order.
Figure 4. Getting to the SSL Cipher Suite Order.

Under the SSL Cipher Suite Order, click the Enabled option as shown below in Figure 5.

The large black arrow indicates where to click to enable SSL Cipher Suite Order. An explanation in the screenshot states, "This policy setting determines the cipher suites used by the Secure Socket Layer. If you enable this policy setting, SSL cipher suites are prioritized in the order specifiied."
Figure 5. Enabling the SSL Cipher Suite Order.

Next, double-click the list of ciphers and select the entire list as shown below in Figure 6.

The next step is to select the entire list of ciphers as shown in the screenshot.
Figure 6. Selecting the list of ciphers.

Once the list has been selected, copy it as shown below in Figure 7.

Copy the list of ciphers as shown.
Figure 7. Copying the list of ciphers.

Copy this list of ciphers into a text editor such as Notepad. Remove any ciphers that support Elliptic Curve cryptography using Diffie-Hellman Ephemeral (ECDHE) or Digital Signature Algorithm (ECDSA) encryption. These should be any entries with ECDHE and/or ECDSA in the name. In the example shown below in Figure 8, these ciphers were all located sequentially, so they were easy to delete from the text.

Delete ciphers that support Elliptic Curve cryptography by removing any entries with ECDHE and/or ECDHA in the name. In our example, the ciphers were located sequentially and were therefore easy to delete.
Figure 8. Deleting entries for ECDHE and ECDSA.

Our updated list of ciphers from Figure 8 is listed below in Table 1.

TLS_AES_256_GCM_SHA384,TLS_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_NULL_SHA256,TLS_RSA_WITH_NULL_SHA,TLS_PSK_WITH_AES_256_GCM_SHA384,TLS_PSK_WITH_AES_128_GCM_SHA256,TLS_PSK_WITH_AES_256_CBC_SHA384,TLS_PSK_WITH_AES_128_CBC_SHA256,TLS_PSK_WITH_NULL_SHA384,TLS_PSK_WITH_NULL_SHA256

Table 1. Updated list after removing forward secrecy ciphers.

Paste the updated cipher list back into the SSL Cipher Suites Field, making sure to overwrite the original list. Click the Apply button, then click OK to close the window. You have now updated the list and can close the Group Policy Editor.

After we accomplished this step, we had to obtain the RDP server’s private key.

Step 3: Obtain RDP Server's Private Key

FreeRDP is one option to use as an RDP server. You can get FreeRDP from this GitHub repository, as well as build instructions. Make sure to set the WITH_SERVER=ON flag when creating the server. Once the server is built, you must provide it with a private key, or use one that comes with FreeRDP.

For our RDP server in this tutorial, we used another host running Windows 10 Pro. Then we extracted the private key from the host’s operating system.

To ensure our second Windows host acted as an RDP server, we enabled RDP. To enable RDP on a host running Windows 10 Pro, go to Windows Settings from the Start Menu, then select the System icon as shown below in Figure 9.

To ensure our second Windows host acted as an RDP server, we enabled RDP by selecting the System icon as shown here.
Figure 9. Getting to the Windows System settings.

Under the system settings, select Remote Desktop and click the switch for Enable Remote Desktop as shown below in Figure 10.

The large black arrows show where to select Remote Desktop and where to click the switch for Enable Remote Desktop.
Figure 10. Enabling RDP in WIndows 10.

After setting up our second Windows host as an RDP server, we extracted the private key from its operating system.

To extract the server key, we could either use either Jailbreak or Mimikatz. We chose Jailbreak.

Jailbreak is a tool by iSECPartners that can export the server's RDP certificate. From the exported certificate, we could extract the private key.

To use Jailbreak, we downloaded the following Jailbreak binaires from this GitHub repository on our newly established RDP server:

  • EasyHook64.dll
  • jailbreak64.exe
  • jailbreakhook64.dll
  • jbstore2_64.exe

Note: The above files were used on a Windows 10 Pro 64-bit host downloaded on March 4, 2021. A screenshot of the GitHub page is shown below in Figure 11.

A screenshot of the Jailbreak GitHub page taken on March 4 shows the Jailbreak binaries we downloaded.
Figure 11. GitHub page for Jailbreak binaries.

After we downloaded the Jailbreak binaries, we opened a Command prompt with administrator privileges as shown below in Figure 12.

The large black arrow indicates how to open a Command prompt with administrator privileges.
Figure 12. Opening a command prompt as an administrator.

In the command prompt, we went to the directory with the downloaded Jailbreak binaries. We ran the following command from this directory:

  • jailbreak64.exe %WINDIR%\system32\mmc.exe %WINDIR%\system32\certlm.msc -64

If we were running a 32-bit version of Windows, we would use:

  • jailbreak32.exe %WINDIR%\system32\mmc.exe %WINDIR%\system32\certlm.msc -32

See Figure 13 below for an example of running the 64-bit command on our Windows host acting as the RDP server.

The screenshot shows an example of running the 64-bit command on our Windows host acting as the RDP server.
Figure 13. Running Jailbreak from the command prompt.

This command opened the certificate manager for our local machine. From the left column, we expanded Remote Desktop and went to the Certificates folder. This showed one certificate. If there had been more than one certificate, we would have selected the one with the most recent expiration date. We right-clicked on the certificate, selected All Tasks then used Export as shown below in Figure 14.

We right-clicked on the certificate, selected All Tasks then used Export as shown.
Figure 14. Exporting the RDP certificate.

When exporting the certificate, we made sure to select the option to export the private key as shown below in Figure 15.

The screenshot reads: "Export Private Key: You can choose to export the private key with the certificate. Private keys are password protected. If you want to export the private key with the certificate, you must type a password on a later page. Do you want to export the private key with the certificate?" The large black arrow shows what to select to ensure the private key is exported with the certificate.
Figure 15. Ensuring the private key is exported with the certificate.

For our host, we could only export the certificate as a PKCS #12 (.PFX) file as shown below in Figure 16.

For the host used in this tutorial on decrypting RDP traffic in Wireshark, we could only export the certificate as a PKCS #12 (.PFX) file, as shown.
Figure 16. Could only export the certificate as a .pfx file.

As shown below in Figure 17, the certificate had to have a password. Fortunately, we had no complexity requirements, so we used a single letter as the password.

As shown, the certificate had to have a password. Because we had not complexity requirements, we used a single letter as the password.
Figure 17. The export process required a password for the certificate.

Finally, we exported our certificate with the private key as shown below in Figure 18.

We exported our certificate with the private key as shown.
Figure 18. Completing our certificate export.

As an alternative, we could have extracted the server’s certificate using Mimikatz instead of Jailbreak. The instructions for using Mimikatz to get the RDP server certificate are listed on GitHub.

Since our certificate was obtained using Jailbreak, we moved it to a Linux host and used OpenSSL to extract the key. First, we used the following OpenSSL command to extract the key in PEM format:

  • openssl pkcs12 -in server_certificate.pfx -nocerts -out server_key.pem -nodes

To remove the passphrase form the key, we also used the following command:

  • openssl rsa -in server_key.pem -out server.key

This provided us with the RDP server’s private key as shown below in Figure 19.

The black arrow and label "private key" indicate where the private server key was extracted from the certificate.
Figure 19. Private server key extracted from the certificate.

Before we could use the private server key, we needed to record an RDP session between our two Windows hosts and save it as a pcap.

Step 4: Capture RDP Traffic

With our two Windows hosts in the same virtual environment, we could use a tool like dumpcap, tcpdump or Wireshark itself to record network traffic in the VLAN using promiscuous mode. Once the recording started, our WIndows client used RDP to log in to the other Windows host acting as an RDP server. The host name of the server was DESKTOP-USER1PC.

The screenshot shows how our Windows client used RDP to log in to the other Windows host acting as an RDP server.
Figure 20. Using the Remote Desktop Connection tool to log into our RDP server.

While the pcap was being recorded, we logged into DESKTOP-USER1PC and performed some basic tasks like opening documents and web browsing.

While the pcap was being recorded, we logged in to DESKTOP-USER1PC and performed some basic tasks, such as opening documents and web browsing.
Figure 21. Performing some common desktop tasks through RDP.

After a minute or so, we logged off RDP and stopped recording network traffic from our VLAN.

Step 5: Open the pcap in Wireshark

We opened the pcap of our RDP session in Wireshark. When filtering on rdp in our Wireshark display filter, we saw no results because the RDP traffic was encrypted. Figure 22 shows the blank column display we saw when filtering for RDP in our pcap.

Because RDP traffic was encrypted, we see a blank column display, as shown, when filtering for RDP in our pcap.
Figure 22. Filtering for RDP information, but no results, due to encrypted RDP traffic.

However, when we used our private server key to decrypt RDP traffic in Wireshark, the results looked much different.

Step 6: Load the Key in Wireshark

In the pcaps we recorded, the RDP server DESKTOP-USER1PC was at IP address 10.3.4.138, and RDP traffic took place over TCP port 3389. We needed this information to properly decrypt RDP traffic in Wireshark.

In Wireshark, we used the Preferences window and expanded the Protocols section as shown below in Figure 23.

For decrypting RDP traffic in Wireshark, we need IP address and port information. In Wireshark, we used the Preferences window and expanded the Protocols section as shown.
Figure 23. Getting to the Protocols section of Wireshark’s preferences menu.

With Wireshark 3.x, use the TLS entry. If you are using Wireshark 2.x, use the SSL entry. For this section, there should be a button to edit the RSA keys list. We clicked the button and added the IP address of the RDP server, the RDP port (3389) and the location of the private key file. Our example is shown below in Figure 24.

We clicked the button and added the IP address of the RDP server, the RDP port (3389) and the location of the private key file.
Figure 24. Go to the TLS section and add the private key to the RSA keys list.

After Wireshark was set up to decrypt RDP traffic, we had much better results when reviewing the pcap.

Step 7: Examine RDP Data

After our key was loaded, our column display was no longer blank when filtering for RDP. We had several results as shown below in Figure 25.

After our key was loaded, decrypting RDP traffic became possible. The screenshot shows that our column display was no longer blank when filtering for RDP.
Figure 25. Viewing the same RDP activity after the private key was loaded in Wireshark.

For security professionals who write signatures to find RDP vulnerabilities and attacks, the type of information revealed above in Figure 25 is critical to their work.

Conclusion

This blog reviewed how to establish an environment to decrypt traffic from an RDP session. This is easiest to do in a virtual LAN with two hosts running Windows 10 Professional. After ensuring the client did not use any forward secrecy ciphers, we extracted the private key from our Windows host acting as the RDP server. Then we easily recorded a pcap of network traffic. After the session finished, we were able to decrypt RDP traffic using the server’s private key.

This type of environment can help security professionals when writing signatures to detect RDP vulnerabilities and attacks.

For more help with Wireshark, see our previous tutorials:

Threat Assessment: Matrix Ransomware

Posted on by Unit 42

Executive Summary

Matrix is a ransomware family that was first identified publicly in December 2016. Over the years since its inception, it has primarily targeted small- to medium-sized organizations. As of 2019, it had been observed across geographic locations such as the U.S., Belgium, Taiwan, Singapore, Germany, Brazil, Chile, South Africa, Canada and the UK. While initially leveraging tactics such as spam email campaigns, propagation via Windows shortcuts and the RIG exploit kit for distribution, the primary attack vector for the Matrix ransomware family shifted in 2018 to brute forcing weak Remote Desktop Protocol (RDP) credentials. The shift to this attack methodology appears to be a recurring trend in similar targeted ransomware families such as Dharma, Ryuk and BitPaymer.

Matrix Ransomware Overview

This screenshot of a note produced by the Matrix ransomware family begins, "All your valuable data has been encrypted!" A key paragraph of interest reads, "We can prove that we can decrypt all your data. Please just send us 3-5 small encrypted files which are randomly stored on your server. We will decrypt these files and send them to you as proof. Please note that files for free test decryption should not contain valuable information." This paragraph describes a technique that appears relatively unique to Matrix.
Figure 1. Screenshot of Matrix ransom note

When executed, Matrix encrypts user files and network shares, as well as deleting volume shadow copies and disabling recovery options on the affected device. Like with many other ransomware variants, the ransom note delivered by Matrix demands payment in Bitcoin. Instead of spreading through an organization, past Matrix infections appear to have been more targeted in nature.

Matrix is unique in that instead of delivering a more conventional ransom note that demands a fixed ransom amount, the threat actors behind it ask victims to contact them directly and submit a small sample of about three to five files for decryption. This is done so the threat actors can determine a variable ransom based on factors such as the predicted value of the victim’s files or the current dollar value of Bitcoin.

As of 2020, Matrix ransomware has been seen appending the following file extensions on files:
.MTXLOCK, .CORE, .ANN, .FOX, .KOK8, .KOK08, .NEWRAR, .FASTBOB, .FASTB, .EMAN, .THDA, .RAD, .EMAN50, .GMPF, .ATOM, .NOBAD, .TRU8, .FASTA, .JNSS, .FBK, .ITLOCK, .SPCT, .PRCP, .CHRB, .AL8G, .DEUS, .FG69, .JB88, .J91D, .S996, .[barboza40@yahoo.com], .[Linersmik@naver.com][Jinnyg@tutanota.com], .[poluz@tutanota.com], .[Yourencrypt@tutanota.com], .[Files4463@tuta.io], .[RestorFile@tutanota.com], .[RestoreFile@qq.com], .[oken@tutanota.com], .[Vfemacry@mail-on.us], .[d3336666@tutanota.com], and .[Bitmine8@tutanota.com]

In addition, Matrix has other variants, including one dubbed “Fox Ransomware,” which adds the “.FOX” extension to encrypted files.

More information on prominent ransomware families can be found in the 2021 Unit 42 Ransomware Threat Report.

Courses of Action

This section documents relevant tactics, techniques and procedures (TTPs) used with Matrix and maps them directly to Palo Alto Networks product(s) and service(s). It also further instructs customers on how to ensure their devices are configured correctly.

Product / Service Course of Action

Initial Access, Persistence, Lateral Movement

The below courses of action mitigate the following techniques:
Spearphishing Attachment [T1566.001], Valid Accounts [T1078], Replication Through Removable Media [T1091], Remote Desktop Protocol [T1021.001]
NGFW Set up File Blocking
Ensure that security policies restrict User-ID Agent traffic from crossing into untrusted zones
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
Ensure that User-ID is only enabled for internal trusted interfaces
Ensure that 'Include/Exclude Networks' is used if User-ID is enabled
Ensure that the User-ID Agent has minimal permissions if User-ID is enabled
Ensure that the User-ID service account does not have interactive logon rights
Ensure remote access capabilities for the User-ID service account are forbidden
Threat Prevention† Ensure that antivirus profiles are set to block on all decoders except 'imap' and 'pop3'
Ensure a secure antivirus profile is applied to all relevant security policies
Ensure that all zones have Zone Protection Profiles with all Reconnaissance Protection settings enabled, tuned and set to appropriate actions
WildFire† Ensure that WildFire file size upload limits are maximized
Ensure forwarding is enabled for all applications and file types in WildFire file blocking profiles
Ensure a WildFire Analysis profile is enabled for all security policies
Ensure forwarding of decrypted content to WildFire is enabled
Ensure all WildFire session information settings are enabled
Ensure alerts are enabled for malicious files detected by WildFire
Ensure 'WildFire Update Schedule' is set to download and install updates every minute
Cortex XDR Configure Host Firewall Profile
Configure Malware Security Profile
Enable Device Control
Cortex XSOAR Deploy XSOAR Playbook - Block Account Generic
Deploy XSOAR Playbook - Access Investigation Playbook
Deploy XSOAR Playbook - Impossible Traveler
Deploy XSOAR Playbook - Phishing Investigation - Generic V2
Deploy XSOAR Playbook - Endpoint Malware Investigation
Credential Access
The below courses of action mitigate the following techniques:
Brute Force [T1110]
NGFW Customize the Action and Trigger Conditions for a Brute Force Signature
Cortex XSOAR Deploy XSOAR Playbook - Brute Force Investigation Playbook
Execution, Defense Evasion, Persistence, Privilege Escalation, Impact
The below courses of action mitigate the following techniques:
Windows Command Shell [T1059.003], Match Legitimate Name or Location [T1036.005], Services File Permissions Weakness [T1574.010], Disable or Modify Tools [T1562.001], Service Stop [T1489], Modify Registry [T1112], Data Encrypted for Impact [T1486], Inhibit System Recovery [T1490]
Cortex XDR Enable Anti-Exploit Protection
Enable Anti-Malware Protection
Configure Restrictions Security Profile
Configure Behavioral Threat Protection under the Malware Security Profile
Cortex XSOAR Deploy XSOAR Playbook - Ransomware Manual for incident response.
Deploy XSOAR Playbook - Palo Alto Networks Endpoint Malware Investigation

Table 1. Courses of Action for Matrix ransomware.
†These capabilities are part of the NGFW security subscriptions service.

Conclusion

While targeted ransomware attacks are not new, Matrix is a prime example of how threat actors can enter into the pool of existing ransomware and cash out quickly by targeting low-hanging fruit. The ransom negotiation tactics used by the Matrix threat actors further amplifyies the dangerous impact that such an attack can have on its victims, especially given the volatile state of cryptocurrency value today. Furthermore, this malware family’s shift in tactics to RDP exploitation, following a similar shift seen in other ransomware groups, serves to emphasize the need for businesses to stay vigilant on current ransomware trends.

Palo Alto Networks detects and prevents Matrix in the following ways:

  • WildFire: All known samples are identified as malware.
  • Cortex XDR with:
    • Iindicators for Matrix.
    • Anti-Ransomware Module to detect Matrix encryption behaviors.
    • Local Analysis detection to detect Matrix binaries.
  • Next-Generation Firewalls: DNS Signatures detect the known command and control (C2) domains, which are also categorized as malware in URL Filtering.
  • AutoFocus: Tracking related activity using the MatrixRansomware tag.

Additionally, Indicators of Compromise (IoCs) associated with Matrix are available on GitHub here, and have been published to the Unit 42 TAXII feed.

Additional Resources

 

20 Million Miners: Finding Malicious Cryptojacking Images in Docker Hub

Posted on by Aviv Sasson

Executive Summary

As a cybercriminal, there are many ways to make a profit. One of the easiest ways is cryptojacking – the illegal use of someone else’s computing resources to mine cryptocurrencies. Container images are known as a simple way to distribute software, yet malicious cryptojacking images are also a simple way for attackers to distribute their cryptominers.

I decided to take an extensive look into Docker Hub and discovered 30 malicious images with a total number of 20 million pulls (which means the images were downloaded 20 million times), together accounting for cryptojacking operations worth US$200,000. In this post, I will elaborate on my findings and why it is reasonable to assume that there are many other undiscovered malicious images on Docker Hub and other public registries.

Palo Alto Networks Prisma Cloud customers are protected from these threats through the Cryptominers Runtime Detection feature and the Trusted Images feature. In addition, Palo Alto Networks Next-Generation Firewall customers with the Threat Prevention security subscription are protected against the delivery of these images.

Finding Malicious Cryptojacking Images

In the last several years, Unit 42 researchers have been witnessing cloud-based cryptojacking attacks in which miners are deployed using an image in Docker Hub.

The cloud is popular for cryptojacking attacks due to two main reasons:

  • The cloud consists of many instances for each target (e.g. lots of CPUs, lots of containers, lots of virtual machines), which can translate to big mining profits.
  • The cloud is hard to monitor. Miners can run undetected for a long time, and without any detection mechanisms in place, they may run until the user finds an inflated cloud usage bill and realizes that something is wrong.

Modern cloud technology is largely based on containers, and in some environments, Docker Hub is the default container registry. Attackers can take advantage of it to deploy miners on compromised clouds.

Because of all of the facts mentioned above, I wanted to see if I could find malicious cryptojacking images in Docker Hub. In my research, I found 30 images from 10 different Docker Hub accounts that account for over 20 million pulls.

Individuals improve their mining efficiency by using mining pools, and so do adversaries.

It is possible to check how many cryptocurrencies were mined to a mining pool account by inspecting the mining pool. Half of the images I found used a mining pool that shares this information, and by extrapolating from that half I estimated that, in total, in all of the attacks, US$200,000 worth of cryptocurrencies were mined.

In the research discussed here, 30 malicious cryptojacking images were found in Docker Hub, spread across 10 accounts and accounting for 20 million pulls. The estimated mining worth is US$200,000.
Figure 1. Research findings.

In order to better understand the findings, I began classifying the results. With the help of public mining pools, I checked which cryptocurrency is mined, which cryptominer is used and how many coins have been mined.

Coin Distribution

My first discovery, perhaps not surprising to our returning readers, is that the most popular cryptocurrency for attackers to mine is Monero, just as we saw with Pro-Ocean, Cetus and many more.

Attackers favor Monero for three reasons:

  • Monero provides maximum anonymity. One of its features is that, unlike for other coins, Monero transitions are hidden. This privacy is perfect for cybercriminals because it means their activity is hidden. Hence, they won’t get banned from exchanges and it is easier for them to evade attempts to track their funds.
  • The Monero mining algorithm favors CPU mining, unlike many other cryptos that require ASICs or GPU for mining. This is convenient because all computers have CPUs. Thus, the miner can run effectively on any machine. This is even more suitable for containers, of which the vast majority run without a GPU.
  • Monero is a popular coin, and its exchange volume is around US$100 million a day, making it easy for the attackers to sell their coins.

The figure below demonstrates the cryptocurrency distribution of the cryptojacking images found on Docker Hub.

The cryptocurrency distribution of the malicious cryptojacking images discussed in this research is shown here. Monero is 90.3%, represented in blue. Grin is 6.5%, represented in red. Arionum is 3.2%, represented in yellow.
Figure 2. Cryptocurrency distribution.

Cryptominer Distribution

In most attacks that mine Monero, the attackers used XMRig, just as we saw with Hildegard and Graboid. XMRig is a popular Monero miner and is preferred by attackers because it’s easy to use, efficient and, most importantly, open source. Hence, attackers can modify its code.

For example, most Monero cryptominers forcibly donate some percentage of their mining time to the miner’s developers. One common modification attackers make is to change the donation percentage to 0.

90.0% of the attacks studied here use XMRig, represented on the pie chart in blue. The remaining 10.0% use Xmr-stack, represented in red.
Figure 3. Cryptominer distribution.

Image Tags

Container registries allow users to upgrade their images and in that process upload a new tag to the registry. Tags are a way to reference different versions of the same image.

When examining the tags of the images, I found that some images have different tags for different CPU architectures or operating systems. It seems like some attackers are versatile and add these tags in order to fit a broad range of potential victims that includes a number of operating systems (OS) and CPU architectures.

In some images, there are even tags with different types of cryptominers. This way, the attacker can choose the best cryptominer for the victim’s hardware.

The only thing that is common for all the tags in a certain image is the wallet address or the mining pool credentials. With the help of these identifiers, I could classify each campaign. After digging deeper, in some cases, I could see that there are numerous Docker Hub accounts that belong to the same campaign. For example, in previous research, Unit 42 found the malicious account azurenql. Now, we discovered that the campaign is broader and includes the accounts 021982, dockerxmrig, ggcloud1 and ggcloud2.

In my research, I was able to find additional images mining Monero for the same campaign described in recent Unit 42 findings on azurenql, adding over 10 million more pulls under the attacker’s name.

Conclusion

The cloud presents big opportunities for cryptojacking attacks. In my research, I used a cryptomining scanner that only detects simple cryptomining payloads. I also made sure any identified image was malicious by correlating the wallet address to previous attacks. Even with these simple tools, I was able to discover tens of images with millions of pulls. I suspect that this phenomenon may be bigger than what I found, with many instances in which the payload is not easily detectable.

Palo Alto Networks Prisma Cloud customers are protected from these threats through the Cryptominers Runtime Detection feature and the Trusted Images feature. In addition, Palo Alto Networks Next-Generation Firewall customers with the Threat Prevention security subscription are protected against the delivery of these images.

The screenshot shows a Prisma Cloud container incident notification. The text says, "This incident type shows detection of a crypto miner, which is software used to generate new coins in cryptocurrencies such as Bitcoin and Monero. These can be used legitimately by individuals; however, they are often executed by attackers as a means of monetizing compromised systems.
Figure 4. Prisma Cloud container incident notification.

Indicators of Compromise

Docker Images

021982/155_138

021982/66_42_53_57

021982/66_42_93_164

021982/xmrig

021982/xmrig1

021982/xmrig2

021982/xmrig3

021982/xmrig4

021982/xmrig5

021982/xmrig6

021982/xmrig7

avfinder/gmdr

avfinder/mdadmd

docheck/ax

docheck/health

dockerxmrig/proxy1

dockerxmrig/proxy2

ggcloud1/ggcloud

ggcloud2/ggcloud

kblockdkblockd/kblockd

osekugatty/picture124

osekugatty/picture128

tempsbro/tempsbro

tempsbro/tempsbro1

toradmanfrom/toradmanfrom

toradmanfrom/toradmanfrom1

xmrigdocker/docker2

xmrigdocker/docker3

xmrigdocker/xmrig

xmrigdocker/xmrig

zenidine/nizadam

 

Fake Websites Used in COVID-19 Themed Phishing Attacks, Impersonating Brands Like Pfizer and BioNTech

Posted on by Erica Naone

Executive Summary

In April 2020, we reported on a large influx of COVID-19 themed phishing attacks starting in February 2020. With March 2021 marking the one-year anniversary that the World Health Organization declared COVID-19 a pandemic, we revisited the phishing trends we observed in the past year to gain deeper insight into the various COVID-related topics that attackers might try to exploit.

Starting with the set of all phishing URLs detected globally between January 2020 and February 2021, we generated sets of specific keywords (or phrases) that served as indicators for each COVID-related topic, and applied keyword matching to determine which phishing URLs were related to each topic. (To ensure that the matched URLs were indeed COVID-related, we iteratively spot-checked the resulting URLs and refined these keywords/phrases to minimize the incidence of false positives.)

We found that at each step along the way, attackers have continued to change their chosen tactics to adapt to the latest pandemic trends, in hopes that maintaining a timely sense of urgency will make it more likely for victims to give up their credentials.

We found phishing attacks largely centered around Personal Protective Equipment (PPE) and testing kits in March 2020, government stimulus programs from April through the summer 2020 (including a fake U.S. Trading Commission website that posed as the U.S. Federal Trade Commission in order to steal user credentials) and vaccines from late fall 2020 onward (including a fake Pfizer and BioNTech website also stealing user credentials). Of note, we found that vaccine-related phishing attacks rose by 530% from December 2020 to February 2021, and that phishing attacks relating to and/or targeting pharmacies and hospitals rose by 189% during that same timeframe.

We found no evidence that any of these efforts were successful, but are highlighting these cases to make healthcare organizations around the globe aware of this heightened activity targeting their sector, so they can alert employees to be on guard for malicious credential-phishing sites.

We predict that as the vaccine rollout continues, phishing attacks related to vaccine distribution – including attacks targeting the healthcare and life sciences industries – will continue to rise worldwide.

Palo Alto Networks Next-Generation Firewall customers are protected from phishing attacks with a variety of security services, including URL Filtering, DNS Security, Threat Prevention and GlobalProtect.

In addition to these security services, best practices to protect yourself and your organization from phishing attacks include:

For individuals:

  • Exercising caution when clicking on any links or attachments contained in suspicious emails, especially those relating to one’s account settings or personal information, or otherwise trying to convey a sense of urgency.
  • Verifying the sender address for any suspicious emails in your inbox.
  • Double-checking the URL and security certificate of each website before inputting your login credentials.
  • Reporting suspected phishing attempts.

For organizations:

  • Implementing security awareness training to improve employees’ ability to identify fraudulent emails
  • Regularly backing up your organization’s data as a defense against ransomware attacks initiated via phishing emails.
  • Enforcing multi-factor authentication on all business-related logins as an added layer of security.

Phishing Trends

Since January 2020, we have observed 69,950 phishing URLs linked to COVID-related topics, of which 33,447 are directly linked to COVID-19 itself. In Figure 1, we plot the relative popularity of these different topics over time, normalized so that each topic has a peak popularity of 100%. Looking at how the heights of each colored section differs over time, we can see that certain topics have remained steady targets of phishing attacks, while others have experienced more noticeable spikes at various points in time. Pharmaceutical drugs and gathering virtually (e.g. Zoom), for example, have been a relatively steady target of phishing attacks since the start of the pandemic; vaccines and testing, on the other hand, have experienced more defined peaks in popularity.

Covering topics observed in COVID-19 themed phishing attacks. Colored lines represent topics such as gathering remotely, economy and government programs, PPE, pharmacies and hospitals, vaccines, drugs, testing and COVID-19. The graph charts URLs observed from January 2020-February 2021. The y-axis represents the number of new phishing URLs, normalized.
Figure 1. Trends in COVID-themed phishing attacks from January 2020-February 2021 (global).

For the COVID-19 themed phishing pages that were found to be targeting known brands, we determined that the majority of these pages were attempting to steal users’ business credentials: e.g. Microsoft, Webmail, Outlook, etc. Each bar in Figure 2 represents the percentage of phishing URLs that were attempting to steal users’ login credentials for that particular website. (For example, about 23% of COVID-themed phishing URLs were fake Microsoft login pages.) With the pandemic forcing many employees to shift to remote work, these business-related phishing attempts have become an increasingly important attack vector for cybercriminals.

Covering popular targets in COVID-19 themed phishing attacks. The chart orders targets by popularity. Top targets include Microsoft, Yahoo, Webmail, Outlook, PayPal, Google Accounts, LinkedIn, Facebook, USAA, DHL, WeTransfer, SFExpress, Chase, OneDrive, Wells Fargo, Netflix, Excel, AOL, Apple ID and Square.
Figure 2. Top phishing targets in COVID-related URLs (global). Each bar represents the percentage of phishing URLs attempting to steal users’ login credentials for that particular website. (Note that in this figure, we only include URLs that target identifiable brands.)

Furthermore, we notice that with these COVID-19 themed phishing attacks, attackers are constantly creating new websites to host their phishing campaigns. In Figure 3, which shows the age for each website that we found to host a COVID-related phishing page, we can see that many COVID-related phishing pages are hosted on newly created sites (we define this as sites that were first observed fewer than 32 days ago), suggesting that attackers purposefully set up these sites just days before their intended attacks. This gives the attackers the opportunity to craft the message surrounding the attack – as well as the website URL itself – to fit the latest pandemic trends.

Website age (at detection time) for URLs targeted in COVID-19 themed phishing attacks. the x-axis tracks website age at detection time in days, while the y-axis tracks the relative frequency that age was observed.
Figure 3. Age of websites that host COVID-related phishing pages at time of detection (global).

January-March 2020: Initial Surge, Testing Kits and PPE

Between January and February 2020, as COVID-19 began its spread throughout the world, cybercriminals had already begun trying to use the soon-to-be pandemic to their advantage. During this timeframe, we observed a 313% increase in phishing attacks directly related to COVID-19.

In Figure 4, we see an example of a COVID-19 themed phishing attack. The fake Google Form first asks the user to input his or her email address and password in order to participate in a supposed company COVID-19 screening program. In the subsequent pages, the form asks a series of legitimate-sounding health-related questions, e.g. “Since your last day of work, have you had two or more of the following? Chills, Repeated shaking with chills, Headache, Muscle pain, Sore throat, New loss of taste or smell,” to give the impression that the form itself is legitimate. The final question before submission asks the employee to “digitally sign” the form by entering his or her full name.

This fake Google Form first asks the user to input his or her email address and password in order to participate in a fabricated company COVID-19 screening program. The form combines legitimate-sounding health-related questions with questions aimed at stealing the user's credentials.
Figure 4. https://docs[.]google[.]com/forms/d/e/1FAIpQLSdiQL-IcnGqRIKzTVmpeQSBVRrD06c4NolWvgWcdRH-NgBx-A/viewform?vc=0&c=0&w=1&flr=0 (Credential stealing form related to COVID-19 screening.)
From February-March 2020, concern about COVID-19 spreading to the U.S. quickly became prominent. In response to people’s desire to protect themselves and their families, interest in testing kits, PPE such as hand sanitizer and N95 masks, and even essential goods like toilet paper began to rise rapidly.

This chart tracks COVID test kit online interest vs. phishing prevalence. The x-axis represents year and month and ranges from 4/1/2020 to 1/1/2021. The y-axis tracks normalized popularity. The blue line represents COVID test kit interest according to Google Trends, and the red line indicates testing-related phishing.
Figure 5. Online interest in “COVID Test Kit” vs. COVID testing-related phishing prevalence (global data via Google Trends).

These trends are observable in our historical phishing data as well. In February 2020, we observed a 136% increase in PPE-related phishing attacks worldwide, many of which took the form of online shopping scams (see Figure 6 for an example). During the month of March, we observed a 750% increase in phishing attacks related to testing kits, just as The New York Times reported on a shortage of COVID tests across the U.S.

This is an example of a scam website, translated from German to English. The website purportedly offers PPE.
Figure 6. https://atemmaske-kn95-de[.]com (Scam website, translated from German to English).
In addition to these scam sites, we also observed seemingly legitimate testing kit vendors whose websites had become compromised for credential stealing purposes. In Figure 8, we see a fake Microsoft Sharepoint login page that a user would be taken to via a link in a phishing email. The phishing page would ask for the user’s email and Microsoft password in order to view a time-sensitive invoice that had been “shared” with him or her.

This website belonging to a UK-based wholesaler of COVID-19 test kits presents an example of the type of legitimate website that could be compromised for credential stealing purposes in COVID-19 themed phishing attacks.
Figure 7. covid-testkit[.]co[.]uk (A UK-based wholesaler of COVID-19 test kits)
A fake Microsoft Sharepoint login page that a user would reach via a link in a phishing email.
Figure 8. covid-testkit[.]co[.]uk/wp-includes/images/i/Newfilesviewc7c782c3b7c54f958e7eb2efff3a49b28866b4fc22dd46cfbad9e6ac9d0cd18cca873584897b48c88d82ecf5cd62783dServices (Credential stealing page on a compromised COVID-related website)

April-July 2020: Government Stimulus and Relief Programs

In April 2020, the IRS began distributing $1,200 stimulus checks to individuals as a part of the CARES Act. Around the same time, the Paycheck Protection Program (PPP) was put into action, promising to provide relief to small businesses across the U.S. Many business owners scrambled to get a piece of the funds, causing online interest in COVID stimulus and relief programs to surge, and funds to quickly run out.

This chart tracks COVID relief/stimulus online interest vs. phishing prevalence. The x-axis represents year and month and ranges from 4/1/2020 to 1/1/2021. The y-axis tracks normalized popularity. The blue line represents COVID relief interest according to Google Trends, the green line tracks "COVID stimulus" interest, and the red line indicates phishing related to these government programs.
Figure 9. Stimulus programs online interest vs. COVID government stimulus and relief-related phishing prevalence (global data via Google Trends).

Subsequently, we noticed that phishing attacks related to government relief programs increased by 600% in April 2020. In Figures 10-11, we show an example of a phishing page pretending to represent the “U.S. Trading Commission,” a fake branch of the U.S. federal government that the FTC warned about. The website promises up to $5,800 in “Temporary Relief Fund” grants for each individual. Fake statistics are displayed on the right-hand side of the page, giving the user the illusion that there are still billions of dollars left to distribute.

The "U.S. Trading Commission" is a fake branch of the U.S. federal government that the FTC warned about. Pictured here is a screenshot of the website supposedly belonging to the fake government agency.
Figure 10. ungodsirealnighchis[.]gq/us/protecting-americas-consumers-covid/ (Fake website pretending to represent the “U.S. Trading Commission.”)
Upon clicking a button saying “Start Verification Procedure,” the user is redirected to a form asking for their Social Security Number (SSN) and driver’s license number in order to receive these emergency COVID relief funds.

This shows the "data validation form" used for credential stealing in a COVID-19 themed phishing attack related to the fake government agency, the "U.S. Trading Commission."
Figure 11. ungodsirealnighchis[.]gq/us/protecting-americas-consumers-covid/verification.php (Credential stealing form related to COVID government aid.)
After completing the form, the confirmation page simply states: “Your response has been recorded. We will contact you as soon as possible. You may always contact us directly at 213-746-7272 for faster service.” (Note that this phone number is likely fake, since once the user has filled out the form, the attacker would already have the credentials they wanted.)

After the legitimate stimulus and relief programs were put in place, these economic relief-related phishing attacks stayed relatively popular for the months to come (see Figure 9), as many people were still in need of financial support. In Figure 12, we see another credential stealing page asking the user to input personal and corporate information, driver’s license photo and bank account details in order to receive additional relief funds from a “COVID-19 giveaway.” We see a similar example in Figure 13, which promises to send the user a free lockdown fund package of 3000 Indian rupees after inputting their bank account information.

Credential stealing page related to a supposed COVID relief giveaway.
Figure 12. covid-19-benefit[.]cabanova[.]com (Credential stealing page related to a supposed COVID relief giveaway.)
COVID-19 themed phishing attacks occurred globally. This screenshot shows a scam website that promises to send the user a free lockdown fund package of 3000 Indian rupees after inputting their bank account information.
Figure 13. fund4-covid19[.]com (Credential stealing site asking the user to input his or her bank account information in order to receive a limited-time “lockdown fund package.”)

November 2020-February 2021: Vaccine Approval and Rollout

For the next several months, various states settled into a state of on-and-off lockdowns, while people awaited news of a potential vaccine.

In November 2020, after months of anticipation, Pfizer and BioNTech released a promising set of initial results, showing over 90% vaccine effectiveness based on a subset of 94 participants in their real-world trial. In December, the U.S. Food and Drug Administration (FDA) granted emergency use authorization for Pfizer’s mRNA vaccine, after which the vaccine rollout began.

With many Americans now looking for a way to sign themselves and their family members up for immunization, it should be no surprise that cybercriminals would try to use this trend to their advantage. From December 2020 to February 2021, we observed a 530% increase in vaccine-related phishing attacks (see Figure 14).

This chart tracks COVID vaccine online interest vs. phishing prevalence. The x-axis represents year and month and ranges from 4/1/2020 to 1/1/2021. The y-axis tracks normalized popularity. The blue line represents COVID vaccine interest according to Google Trends and the red line indicates phishing related to the vaccines.
Figure 14. “COVID Vaccine” online interest vs. COVID vaccine-related phishing prevalence (global data via Google Trends).

In Figures 15-16, we show an example of a fake website that claims to represent Pfizer and BioNTech, the makers of the mRNA vaccine. The phishing page asks the user to log in with his or her Office 365 credentials, supposedly in order to sign up for the vaccine.

Also note that this phishing website employs an increasingly common technique known as “client-side cloaking.” Rather than revealing the credential stealing form immediately, the website first asks the user to click the “Login” button, in an effort to evade automated, crawler-based phishing detectors.

This is an example of a fake website that claims to represent Pfizer and BioNTech, the makers of the mRNA vaccine. The phishing page asks the user to log in with his or her Office 365 credentials, supposedly in order to sign up for the vaccine.
Figure 15. pfizer-vaccine[.]online (Fake Pfizer website with client-side phishing cloaking.)
Rather than revealing the credential stealing form immediately, the website first asks the user to click the “Login” button, in an effort to evade automated, crawler-based phishing detectors.
Figure 16. pfizer-vaccine[.]online (Credential stealing form revealed after user clicks the “Login” button.)
At the same time as attackers have started to capitalize on the vaccine registration process, they have also increased their targeting of hospitals and pharmacies – organizations that play a significant role in distributing the vaccine. According to a national survey conducted by the American Medical Association (AMA), 83% of physician practices have already been affected by cyberattacks at some point in the past. Now more than ever, we suspect that organizations involved in the production and distribution of the vaccine — a process involving high amounts of time-sensitive and confidential data that could be held for ransom — may be viewed as high-value targets for cybercrime.

From December 2020 to February 2021, we observed a 189% increase in attacks related to pharmacies and hospitals. Many of these attacks are part of larger clusters of phishing campaigns, where several different URLs are sent to different employees of the same organization, in the hopes that at least one of the employees will mistakenly input his or her credentials into the fake login page.

Perhaps unsurprisingly, given the global nature of COVID-19, these phishing campaigns targeting pharmaceutical and healthcare companies seem to be prevalent worldwide, not just in the U.S.

In certain cases, we also observe legitimate pharmaceutical companies whose websites have been compromised and used for phishing purposes. In Figure 17, we can see that a website belonging to a global life sciences technology marketplace company which had been compromised and used to host a phishing page for stealing users’ business credentials. These sorts of attacks can be particularly dangerous, as the legitimacy of the original website may trick users into incorrectly thinking that the phishing page is also legitimate.

 

pharmalicensing[.]com, a website belonging to a company that helps connect businesses across the life sciences industry, had been compromised and used to host a phishing page for stealing users’ business credentials.
Figure 17. A compromised website from a global life sciences technology marketplace being used for credential stealing.
With the global vaccine rollout still very much in-progress, we expect that attacks related to the vaccine – and attacks targeting corresponding industries – will continue to rise as vaccine production and distribution continue to scale up over the coming months.

Conclusion

At various points during the COVID-19 pandemic, we have seen attackers shift their focus from one topic to another depending on the current state of events. In the early stages of the pandemic, testing kits and PPE were a significant area of focus for attackers. The focus then shifted to government stimulus and relief programs, before pivoting again to the vaccine rollout. As we have seen, attackers continually adapt to the newest trends. As a result, cybersecurity defenses must adapt as well.

Individuals should continue to exercise caution when viewing any emails or websites claiming to sell any goods or services or provide any benefits related to COVID-19. If it seems too good to be true, it most likely is. Employees in the healthcare industry in particular should view links contained in any incoming emails with suspicion, especially from emails trying to convey a sense of urgency.

General best practices to protect yourself and your organization from phishing attacks include:

For individuals:

  • Exercising caution when clicking on any links or attachments contained in suspicious emails, especially those relating to one’s account settings or personal information, or otherwise trying to convey a sense of urgency.
  • Verifying the sender address for any suspicious emails in your inbox.
  • Double-checking the URL and security certificate of each website before inputting your login credentials.
  • Reporting suspected phishing attempts.

For organizations:

  • Implementing security awareness training to improve employees’ ability to identify fraudulent emails
  • Regularly backing up your organization’s data as a defense against ransomware attacks initiated via phishing emails.
  • Enforcing multi-factor authentication on all business-related logins as an added layer of security.

For more specific suggestions that individuals and organizations can use to protect themselves, see “COVID-19: The Cybercrime Gold Rush of 2020.”

In addition to these general best practices, Palo Alto Networks Next-Generation Firewall customers are protected from these threats in multiple ways:

To learn more about how Palo Alto Networks can help protect your organization during the pandemic, please see our response to COVID-19.

Acknowledgements

The author would like to thank Wei Wang, Wayne Xin, Jingwei Fan, Yu Zhang, and Seokkyung Chung for providing several data sources that were used in the analyses, and Jun Javier Wang, Kelvin Kwan, Vicky Ray, Laura Novak, Jen Miller-Osborn, Eddy Rivera and Erica Naone for their help with improving the blog.

Indicators of Compromise

COVID-19

covid-19-benefit[.]cabanova[.]com
abccoronavirus[.]online
cpvqapyxmr[.]covid19coronaca[.]net
sign-amazonsnews-alert[.]peduli-covid19.com

Vaccines

vaccine-sarscov2[.]online
sarscov2vaccine[.]online
universalvirusvaccine[.]com
pittsburgh-coronavirus-vaccine[.]online
nhs-vaccination.com
pfizersupply.eu
covid-19vaccine[.]uscis-gov[.]online

Testing

covid-testkit[.]co[.]uk/wp-includes/images/i/Newfilesviewc7c782c3b7c54f958e7eb2efff3a49b28866b4fc22dd46cfbad9e6ac9d0cd18cca873584897b48c88d82ecf5cd62783dServices
sarscov2-test[.]online
y2down[.]xyz/unreadmessages/testkits

PPE

maskacoronavirus[.]online
maskakoronawirus[.]online
malibumasks[.]com/.offce365/?
cloroxus[.]com
www[.]lysolmz9[.]top
atemmaske-kn95-de[.]com

Drugs and Pharmaceuticals

veklury-covid19[.]online
covid19-veklury[.]top
remdesivir-covid19[.]online
covid19-veklury[.]online
covispharmac[.]com

Pharmacies and Hospitals

jyhhospitaljp[.]com
neelkantcollegeofpharmacy[.]com/images/icon/invntce/shoffpro/sharepoint/verification.php
www[.]afbiohavenpharma.com.dailyoffercode.com
www[.]afamagpharma.com.dulcerialamejor.com
www[.]afbiohavenpharma.com[.]diasahabatku[.]com
www[.]afbiohavenpharma.com[.]besttodaymart[.]com

Economy and Government Programs

disvey[.]ir/authcovid-19reliefgov
covid-stimulus-payment[.]gov[.]free-inhabitant[.]com

hellos[.]tcp4[.]me/Standard-Bank-Online-Relief-Funds-UCount-onlinebanking.standardbank.co.za-direct-login/Standard%20Bank%20Online%20Banking.htm
hmrc[.]covid[.]19-support-grant[.]com
fund4-covid19[.]com
furlough-grant[.]com
covid19emergencyfinancialrelief[.]com

Gathering Remotely

zoominceinvite[.]s3[.]amazonaws[.]com/invitezoom08.html
bit[.]ly/zoomtroubleshoot
us02web[.]zoom[.]us[].]coremailxt5mainjsp[.]com
incoming[.]zoomcallrequest[.]org
zoom-free1[.]com
zoommeetinactivation[.]web[.]app

 

Unit 42 Discovers 15 New Vulnerabilities Across Microsoft, Adobe and Apple Products

Posted on by Bo Qu

Executive Summary

Unit 42 researchers have been credited with discovering 15 new vulnerabilities addressed by the Microsoft Security Response Center (MSRC), Adobe Security Bulletin and Apple Security Updates, as part of the last quarter of security update releases.

Vulnerabilities

Of the 15 new vulnerabilities credited to Unit 42 researchers, 10 come from Microsoft with severity ratings from low to important. The four Adobe Reader DC vulnerabilities are all critical bugs that allow remote code execution (RCE). Lastly, there is an Apple cross site scripting (XSS) vulnerability that could also lead to arbitrary RCE in the context of the currently logged in user.

The Unit 42 researchers credited are Tao Yan, Zhibin Zhang, Bo Qu, Ronen Haber and Ken Hsu.

The recently discovered vulnerabilities are listed in Table 1 below:

Vendor CVE Description Type Researcher(s)
Microsoft CVE-2020-16876 Windows Application Compatibility Client Library Elevation of Privilege Vulnerability Privilege Escalation Tao Yan
Microsoft CVE-2020-16895 Windows Error Reporting Manager Elevation of Privilege Vulnerability Privilege Escalation Tao Yan
Microsoft CVE-2020-16924 Jet Database Engine Remote Code Execution Vulnerability Remote Code Execution Zhibin Zhang
Microsoft CVE-2020-17007 Windows Error Reporting Elevation of Privilege Vulnerability Privilege Escalation Tao Yan
Microsoft CVE-2020-17046 Windows Error Reporting Denial of Service Vulnerability Denial of Service Tao Yan
Microsoft CVE-2020-17062 Microsoft Office Access Connectivity Engine Remote Code Execution Vulnerability Remote Code Execution Zhibin Zhang
Microsoft CVE-2020-17094 Windows Error Reporting Information Disclosure Vulnerability Information Disclosure Tao Yan, Bo Qu
Microsoft CVE-2020-17138 Windows Error Reporting Information Disclosure Vulnerability Information Disclosure Tao Yan
Apple CVE-2020-10012 Quick Look Cross Site Scripting Vulnerability Cross Site Script Bo Qu
Microsoft CVE-2021-1703 Windows Event Logging Service Elevation of Privilege Vulnerability Privilege Escalation Ronen Haber
Microsoft CVE-2021-1711 Microsoft Office Remote Code Execution Vulnerability Remote Code Execution Tao Yan, Bo Qu
Adobe CVE-2021-21058 Adobe Reader DC Memory Corruption Vulnerability Remote Code Execution Ken Hsu
Adobe CVE-2021-21059 Adobe Reader DC Memory Corruption Vulnerability Remote Code Execution Ken Hsu
Adobe CVE-2021-21062 Adobe Reader DC Memory Corruption Vulnerability Remote Code Execution Ken Hsu, Bo Qu
Adobe CVE-2021-21063 Adobe Reader DC Memory Corruption Vulnerability Remote Code Execution Ken Hsu, Zhibin Zhang

Table 1. List of vulnerabilities.

Specifically, the patch of CVE-2021-1711 addresses a new type of security issue that Unit 42 researchers discovered. Tao Yan, Qi Deng and Bo Qu will share more technical details at Black Hat Asia 2021.

Conclusion

Palo Alto Networks Next-Generation Firewall customers deploying a Threat Prevention security subscription, which includes capabilities such as vulnerability protection with an intrusion prevention system (IPS), are protected from zero-day vulnerabilities such as these. The WildFire security subscription provides our customers with comprehensive protection and automatic updates against previously unknown threats.

Weaponized exploits for these vulnerabilities are prevented by Cortex XDR’s multi-layered exploit prevention capabilities.

Palo Alto Networks is a regular contributor to vulnerability research in Microsoft, Adobe, Apple, Google Android and other ecosystems, with more than 300 critical vulnerabilities discovered. Our researchers give regular talks at security conferences such as Black Hat, Blue Hat and REcon.

By proactively identifying these vulnerabilities, developing protections for our customers and sharing the information with the security community, we are removing weapons used by attackers to threaten users and compromise enterprise, government and service provider networks.

 

Satori: Mirai Botnet Variant Targeting Vantage Velocity Field Unit RCE Vulnerability

Posted on by Haozhe Zhang

Executive Summary

On Feb. 20, 2021, Unit 42 researchers observed attempts to exploit CVE-2020-9020, which is a Remote Command Execution (RCE) vulnerability in Iteris’ Vantage Velocity field unit version 2.3.1, 2.4.2 and 3.0. As a travel data measurement system, Vantage Velocity captures travel data with a large number of vehicles. If a device is compromised, it will be under control of attackers, who can then leak sensitive data or conduct further attacks, such as Distributed Denial-of-Service (DDoS) attacks. The vulnerability has a critical rating (i.e., CVSS 3.1 score of 9.8) due to its low attack complexity, but critical security impact. The exploit captured by Unit 42 researchers utilized the vulnerability to spread Satori, a Mirai botnet variant.

Palo Alto Networks Next-Generation Firewall customers with security subscriptions such as Threat Prevention, WildFire, URL Filtering and IoT Security are able to detect and prevent the exploit traffic and the malware.

Vulnerability Analysis

The vulnerable devices lack a check on the htmlNtpServer parameter of /cgi-bin/timeconfig.py, allowing attackers to inject commands via crafted HTTP requests and have them executed on victim’s devices. This vulnerability was disclosed in early 2020, but the National Vulnerability Database (NVD) published it recently, not long before the exploit attempts.

Exploit in the Wild

On Feb. 20, 2021, Palo Alto Networks Next-Generation Firewall caught the first exploit attempt. As shown in Figure 1, the exploit attempted to download the file arm7 from the server 198[.]23[.]238[.]203 with the system command wget and then change the access permissions of the downloaded file to ensure it can be executed with the current user privileges.

Figure 1. Exploit request in the wild.
Figure 1. Exploit request in the wild.

The server 198[.]23[.]238[.]203 was first noticed (serving a malicious shell script) by the security community on Feb. 17, 2021, according to VirusTotal. At the time of this writing, the server is still accessible. It provides an HTTP service on port 80, based on Apache2 HTTP server, that provides a malware downloading service. It also has port 5684 opened, which is believed to serve as the command and control (C2).

According to our investigation, nine samples with similar functions but different platform compatibility were found on the server. They are able to run and compromise devices across multiple mainstream architectures. Thus, these malware can be easily utilized again when the attacker changes the exploit against other target systems.

The information for all nine samples are listed in the Indicators of Compromise (IoCs) section.

Mirai Botnet Variant (Satori)

Based on our in-depth investigation into the behaviors and patterns, we believe that the malware samples hosted on the server 198[.]23[.]238[.]203 are highly likely to be a variant of the Mirai botnet, Satori.

When executed, it prints the message “hello friend :)” to the console. Then, four child processes are spawned and detached from the main process.

The malware was observed to scan port 23 of random hosts (as shown in Figure 2) and tries to login with its embedded password dictionary when port 23 is open.

Satori Port Scanning
Figure 2. Satori port scanning.
Figure 3. Passwords encrypted with XOR algorithm and key 0x07.
Figure 3. Passwords encrypted with XOR algorithm and key 0x07.

The passwords are encrypted using the XOR algorithm with a single byte key of 0x07, as shown in Figure 3.

The encrypted C2 traffic over SSL was also observed between the victim and 198[.]23[.]238[.]203:5684, as shown in Figure 4.

Figure 4. Traffic to C2 server.
Figure 4. Traffic to C2 server.

The malware also contains multiple predefined operating system (OS) commands, as shown in Figure 5. Those commands are used to download and execute malicious payload from remote C2 servers to deploy bots on new victim devices.

Figure 5. Predefined OS commands.
Figure 5. Predefined OS commands.

Conclusion

CVE-2020-9020 is easy to exploit and can lead to RCE. After gaining control, attackers can take advantage and include the compromised devices in their botnet. Therefore, we strongly advise to apply patches and upgrade when possible.

Palo Alto Networks customers are protected from the vulnerability by the following products and services:

  • Next-Generation Firewalls with a Threat Prevention security subscription can block the attacks with Best Practices via Threat Prevention signature 90769.
  • WildFire can stop the malware with static signature detections.
  • URL Filtering can block malicious malware domains.
  • IoT Security can provide coverage on legacy IoT sensors.

Indicators of Compromise (IoCs)

51[.]81[.]24[.]157
198[.]23[.]238[.]203

Filename URL SHA256
arm http://198[.]23[.]238[.]203/arm 0d74227dbc3bdd74a3854d81e47cf6048da2d95c3010b953de407e5989beb066
arm7 http://198[.]23[.]238[.]203/arm7 fe8e5e7041dfda470f9e2ad9abe9e0da3e43ddb5b24209e42ce0e3ebee1a7bfe
mips http://198[.]23[.]238[.]203/mips 320d7067d60f9ed7e7f3e9408a5d3b0a6fdccddde494c0a2a4f4e77aecb80814
mips http://198[.]23[.]238[.]203/mipsel fbe314dc3b284ce2db1f37478338fdba8130bf44e484f5028ca92eb9326417e4
powerpc  http://198[.]23[.]238[.]203/powerpc 3c62d16451db32f72464a854d6aceb7c7ba2f07c38850f6a247a5243c0f473cb
sh4 http://198[.]23[.]238[.]203/sh4 13ce782d393f2b4ce797747d12f377afad9d6e56c10f52948034a234654a9d30
sparc http://198[.]23[.]238[.]203/sparc 985127ed1610cfca49f6dba273bb0783f20adf763e1d553c38e5a0f9f89328c3
m68k http://198[.]23[.]238[.]203/m68k e458dca7ddceae3412e815e5c70e365f6cc918be2d512e69b5746ed885e80268
x86_64  http://198[.]23[.]238[.]203/x86_64 989e49f9aaff3645c40a2c40b8959e28e4ff0a645e169bb81907055a34f84dfb
x86_32 http://198[.]23[.]238[.]203/x86_32 22818ae75823ee5807d5d220500eb9d5829927d57e10ce87312d1c22843fb407

Ransomware Threat Assessments: A Companion to the 2021 Unit 42 Ransomware Threat Report

Posted on by Unit 42

To evaluate the scope of ransomware attacks and provide actionable steps to mitigate risk, the Unit 42 threat intelligence team and the Crypsis incident response team collaborated to analyze the ransomware threat landscape in 2020. With global data from Unit 42 as well as data from the U.S., Canada and Europe from Crypsis, the 2021 Unit 42 Ransomware Threat Report details key ransomware trends, variants and predictions, including:

  • 2020 ransomware landscape observations, including how ransomware has tried to take advantage of the COVID-19 pandemic, shifts in threat actor approach and information on targeted platforms.
  • Average ransomware payments from organizations across the U.S., Canada and Europe.
  • Predictions for the future of ransomware, including our ideas of how the use of variants could increase and ransom demands could get higher. We also detail how we expect threat actors to leverage the ransomware-as-a-service model.
  • Actionable guidance on how to minimize risk and keep your organization safe from attacks.

To learn more about the current state of ransomware and how to keep your organization safe, download the 2021 Unit 42 Ransomware Threat Report and join our webinar on April 27.

To learn more specifics about major ransomware families, please see our previously published ransomware threat assessments on Maze, Ryuk, WastedLocker and Egregor.

On the pages that follow, you’ll find detailed ransomware threat assessments for several ransomware families covered in the report, including:

Continue Reading: NetWalker

Back to Top

Pages: 1 2 3 4 5 6 7 8

Highlights from the 2021 Unit 42 Ransomware Threat Report

Posted on by Unit 42

Introduction

Ransomware is one of the top threats in cybersecurity and a focus area for Palo Alto Networks. The global threat intelligence team (Unit 42) and incident response team (The Crypsis Group) have partnered to create the 2021 Unit 42 Ransomware Threat Report to provide the latest insights on the top ransomware variants, ransomware payment trends and security best practices so we can understand and manage the threat.

To evaluate the current state of the ransomware threat landscape, the Unit 42 threat intelligence team and the Crypsis incident response team collaborated to analyze the ransomware threat landscape in 2020, with global data from Unit 42 as well as data from the U.S., Canada and Europe from Crypsis.

Key Findings

Cybercriminals Are Making, and Demanding, More Money Than Ever

Note: The following data is from the U.S., Canada and Europe.

The average ransom paid for organizations increased from US$115,123 in 2019 to $312,493 in 2020, a 171% year-over-year increase. Additionally, the highest ransom paid by an organization doubled from 2019 to 2020, from $5 million to $10 million. Meanwhile, cybercriminals are getting greedy. From 2015 to 2019, the highest ransomware demand was $15 million. In 2020, the highest ransomware demand grew to $30 million.

Of note, Maze ransom demands in 2020 averaged $4.8 million, a significant increase compared to the average of $847,344 across all ransomware families in 2020. Cybercriminals know they can make money with ransomware and are continuing to get bolder with their demands.

Healthcare Organizations in the Crosshairs

The world changed with COVID-19, and ransomware operators took advantage of the pandemic to prey on organizations – particularly the healthcare sector, which was the most targeted vertical for ransomware in 2020. Ransomware operators were brazen in their attacks in an attempt to make as much money as possible, knowing that healthcare organizations – which needed to continue operating to treat COVID-19 patients and help save lives – couldn't afford to have their systems locked out and would be more likely to pay a ransom.

Ryuk ransomware stood out from the pack. In October 2020, a joint cybersecurity advisory was issued by the Cybersecurity and Infrastructure Security Agency (CISA), the Federal Bureau of Investigation (FBI) and the Department of Health and Human Services (HHS), warning healthcare organizations against Ryuk attacks.

The Rise of Double Extortion

A common ransomware attack consists of the ransomware operator encrypting data and forcing the victim to pay a ransom to unlock it. In a case of double extortion, ransomware operators encrypt and steal data to further coerce a victim into paying a ransom. If the victim doesn’t pay the ransom, the ransomware operators then leak the data on a leak site or dark web domain, with the majority of leak sites hosted on the dark web. These hosting locations are created and managed by the ransomware operators. At least 16 different ransomware variants are now threatening to expose data or utilizing leak sites, and more variants will likely continue this trend.

The ransomware family that leveraged this tactic the most was NetWalker. From January 2020 to January 2021, NetWalker leaked data from 113 victim organizations globally, far surpassing other ransomware families. RagnarLocker was second, leaking data from 26 victims globally. It’s worth noting that the US Department of Justice announced in January 2021 that it had coordinated international law enforcement action to disrupt the NetWalker ransomware gang. The dark web domain managed by the NetWalker operators, which hosted leaked data, is no longer accessible.

Steps to Reduce Ransomware Exposure

Defending against ransomware attacks is similar to protecting against other malware. However, it represents a much higher risk to the organization.

Initial Access

Initial access is relatively consistent across all ransomware variants. Organizations should maintain user awareness and training for email security as well as consider ways to identify and remediate malicious email as soon as it enters an employee’s mailbox. Organizations should also ensure they conduct proper patch management and review which services may be exposed to the internet. Remote desktop services should be correctly configured and secured, using the principle of least privilege wherever possible, with a policy in place to detect patterns associated with brute-force attacks.

Backup and Recovery Process

Organizations should continue to back up their data and keep an appropriate recovery process in place. Ransomware operators will target on-site backups for encryption, so organizations should ensure that all backups are maintained securely offline. Recovery processes must be implemented and rehearsed with critical stakeholders to minimize downtime and cost to the organization in the event of a ransomware attack.

Security Controls

The most effective forms of protection from ransomware are endpoint security, URL filtering or web protection, advanced threat prevention (unknown threats/sandboxing) and anti-phishing solutions deployed to all enterprise environments and devices. While these will not outright guarantee prevention, they will drastically reduce the risk of infection from common variants and provide stopgap measures, allowing one technology to offer a line of enforcement when another may not be effective.

Get the full 2021 Unit 42 Ransomware Threat Report for more research and best practices to implement in your organization.

Additional Resources

 

New Mirai Variant Targeting Network Security Devices

Posted on by Asher Davila

Executive Summary

On Feb. 16, 2021, Unit 42 researchers discovered attacks leveraging a number of vulnerabilities, including:

  • VisualDoor (a SonicWall SSL-VPN exploit).
  • CVE-2020-25506 (a D-Link DNS-320 firewall exploit).
  • CVE-2020-26919 (a Netgear ProSAFE Plus exploit).
  • Possibly CVE-2019-19356 (a Netis WF2419 wireless router exploit).
  • Three other IoT vulnerabilities yet to be identified.

On Feb. 23, 2021, one of the IPs involved in the attack was updated to serve a Mirai variant leveraging CVE-2021-27561 and CVE-2021-27562, mere hours after vulnerability details were published. On March 3, 2021, the same samples were served from a third IP address, with the addition of an exploit leveraging CVE-2021-22502. Furthermore, on March 13, an exploit targeting CVE-2020-26919 was also incorporated into the samples.

The attacks are still ongoing at the time of this writing. Upon successful exploitation, the attackers try to download a malicious shell script, which contains further infection behaviors such as downloading and executing Mirai variants and brute-forcers.

Palo Alto Networks Next-Generation Firewall customers with Threat Prevention, WildFire and URL Filtering security subscriptions, as well as AutoFocus can detect and block all the exploit attempts from this kind of malware family.

Vulnerabilities Being Exploited

Five known vulnerabilities and three unknown vulnerabilities were exploited in this attack. Upon successful exploitation, the wget utility is invoked to download a shell script from the malware infrastructure. The shell script then downloads several Mirai binaries compiled for different architectures and executes these downloaded binaries one by one. Vulnerability information is shown in Table 1, below.

ID Vulnerability Description Severity
1 VisualDoor SonicWall SSL-VPN Remote Command Injection Vulnerability Critical
2 CVE-2020-25506 D-Link DNS-320 Firewall Remote Command Execution Vulnerability Critical
3 CVE-2021-27561 and CVE-2021-27562 Yealink Device Management Pre-Auth ‘root’ Level Remote Code Execution Vulnerability Critical
4 CVE-2021-22502 Remote Code Execution Vulnerability in Micro Focus Operation Bridge Reporter (OBR), affecting version 10.40 Critical
5 CVE-2019-19356 Resembles the Netis WF2419 Wireless Router Remote Code Execution Vulnerability High
6 CVE-2020-26919 Netgear ProSAFE Plus Unauthenticated Remote Code Execution Vulnerability Critical
7 Unidentified Remote Command Execution Vulnerability Against an Unknown Target Unknown
8 Unidentified Remote Command Execution Vulnerability Against an Unknown Target Unknown
9 Unknown Vulnerability Vulnerability Used by Moobot in the Past, Although the Exact Target is Still Unknown Unknown

Table 1. List of vulnerabilities.

Exploit Payloads

1. VisualDoor: SonicWall SSL-VPN Remote Command Injection Vulnerability

VisualDoor SonicWall SSL-VPN exploit payload.
Figure 1. VisualDoor SonicWall SSL-VPN exploit payload.

The exploit of SonicWall SSL-VPN targets an old version of Bash, which is vulnerable to ShellShock. An attacker can send a crafted Common Gateway Interface (CGI) request to a particular shell script leading to an unauthenticated remote code execution (RCE) vulnerability.

2. CVE-2020-25506: D-Link DNS-320 Firewall Remote Command Execution Vulnerability

D-Link DNS-320 exploit payload.
Figure 2. D-Link DNS-320 exploit payload.

The exploit targets a command injection vulnerability in a system_mgr.cgi component. The component does not successfully sanitize the value of the HTTP parameters f_ntp_server, which in turn leads to arbitrary command execution.

3. CVE-2021-27561 and CVE-2021-27562: Yealink Device Management Pre-Auth ‘root’ Level Remote Code Execution Vulnerability

Yealink Device exploit payload - we observed one of the IPs involved in the attack leveraging CVE-2021-27561 and CVE-2021-27562 to serve a Mirai variant
Figure 3. Yealink Device exploit payload

The exploit works by chaining a pre-auth Server-Side Request Forgery (SSRF) vulnerability and a command injection vulnerability, making it possible to execute commands as root without authentication, simply by sending an HTTPS request to the remote target.

4. CVE-2021-22502: Micro Focus Operation Bridge Reporter (OBR) Remote Code Execution

"Micro Focus Operation Bridge Reporter exploit payload. "
Figure 4. Micro Focus Operation Bridge Reporter exploit payload.

The exploit works due to the unsanitized use of the “username” and “password” parameters in requests made to the LogonResource API. The vulnerability can be exploited to allow unauthenticated RCE as root on the OBR server.

5. CVE-2019-19356: Netis WF2419 Wireless Router Remote Code Execution Vulnerability

Netis WF2419 exploit payload.
Figure 5. Netis WF2419 exploit payload.

The exploit targets an RCE vulnerability in a diagnostic tool utility. An authenticated attacker can perform command execution via multiple vulnerable parameters such as IP address or domain name.

6. CVE-2020-26919: Netgear ProSAFE Plus Unauthenticated Remote Code Execution Vulnerability

Netgear ProSAFE exploit payload.
Figure 6. Netgear ProSAFE exploit payload.

The exploit targets debug web sections and an attacker can execute system commands through it. This is due to lack of proper checks on access controls leading to RCE with administrator privileges.

7. Unidentified vulnerability (lang parameter command injection)

Unidentified vulnerability exploit payload, found in connection with our observations around the delivery of a new Mirai variant.
Figure 7. Unidentified vulnerability exploit payload.

The exploit of an unidentified vulnerability targets a command injection vulnerability in certain components. The component does not successfully sanitize the value of the HTTP parameter lang, which in turn leads to arbitrary command execution.

8. Unidentified vulnerability (key parameter command injection)

Unidentified vulnerability exploit payload, found in connection with our observations around the delivery of a new Mirai variant.
Figure 8. Unidentified vulnerability exploit payload.

The unknown exploit targets the login CGI script, where a key parameter is not properly sanitized leading to a command injection.

9. Unknown vulnerability (op_type parameter command injection)

Unidentified vulnerability exploit payload, found in connection with our observations around the delivery of a new Mirai variant.
Figure 9. Unidentified vulnerability exploit payload.

This exploit targets the op_type parameter, which is not properly sanitized leading to a command injection. It has been observed in the past being used by Moobot, however the exact target is unknown.

Malware Behaviors

Binary Functionality
lolol.sh After deleting some key folders from the target machine (such as ones containing the existing scheduled jobs, as well as startup scripts), this script downloads the “dark” binaries explained below, saves them to a misleadingly named file “nginx” and tries to run each one. Since the “dark” binaries downloaded are each compiled for a different architecture, only the one compatible with the target machine would actually execute.

Following that, it schedules a job that would (supposedly) run every hour to rerun the lolol.sh script. However, the cron configuration is incorrect. This would have been an attempt to ensure the process is re-launched in case it crashes or is killed for some other reason.

Finally, several packet filter rules are created to block incoming traffic directed at commonly used ports like the standard SSH, HTTP and telnet ports, among others. This is probably to make maintenance of and remote access to the affected system more challenging for an administrator.

In one of the two observed versions of the script, it also downloads and runs the “install.sh” script described below.
install.sh This script downloads GoLang v1.9.4 onto the target system and adds it to the system path. In addition, it also installs the GoLang standard SSH package and zmap (a common network-scanning package).

It also downloads the “nbrute” binaries and the “combo.txt” file described below. As was the case for the previous script, the “nbrute” binaries downloaded are each compiled for a different architecture, increasing the probability of compatibility with the target machine.

Finally, zmap is run to scan port 22, and IPs found with port 22 open are sent as input to the nbrute binary.
nbrute.[arch] These binaries are written in GoLang and mainly serve the purpose of brute-forcing the various credentials found in “combo.txt” while initiating an SSH connection with a certain IP.
combo.txt Plain text file containing numerous combinations of credentials (often default credentials on devices).
dark.[arch] These binaries are based on the Mirai codebase, and mainly serve the purpose of propagation – either using the exploits described in the section above, or by brute-forcing SSH connections using some hard-coded credentials in the binary.

The key used for the standard Mirai byte-wise XOR encryption routine is 0xbaadf00d.

Table 2. Malware behaviors.

Conclusion

The IoT realm remains an easily accessible target for attackers. Many vulnerabilities are very easy to exploit and could, in some cases, have catastrophic consequences. We strongly advise customers to apply patches whenever possible.

Palo Alto Networks customers are protected from the aforementioned vulnerabilities by the following products and services:

Indicators of Compromise

Samples

First Seen URL SHA256
Mar 13, 2021 02:43 UTC 203[.]159.80.241/bins/dark.arm5 60135a7817a0a1734c2e211a8613873548f4611fddc8666890f6a69860c43e61
Mar 13, 2021 02:43 UTC 203[.]159.80.241/bins/dark.arm6 087fc3206ddb94e80118e7e7f0215c88409a0071b657d21071e15b7917f7cc4e
Mar 13, 2021 02:43 UTC 203[.]159.80.241/bins/dark.arm7 33f75999a3b4c354b6281399e541b97fd6463c5cd2ab13a538522d72a8870f30
Mar 13, 2021 02:43 UTC 203[.]159.80.241/bins/dark.m68k 02d48570f1089e2e7f4f9256bb033136c773834af31054e477e094e48cba110e
Mar 13, 2021 02:43 UTC 203[.]159.80.241/bins/dark.mips 45ff08b1de872379f965d423a0f4e1f2e82f0ea8d101220b83d3aed3b2e7f1c9
Mar 13, 2021 02:43 UTC 203[.]159.80.241/bins/dark.mpsl 85acead88180809d47524aac87d6f76799e7c0a1729d9614446be73aa8e7d871
Mar 13, 2021 02:43 UTC 203[.]159.80.241/bins/dark.ppc 0bbdb062ecfae7e1b59084a5e5fe052908ecfdea7db0777a9c318e9e55fdb5ff
Mar 13, 2021 02:43 UTC 203[.]159.80.241/bins/dark.sh4 77a1f62dc76cc9ee2d924008a0fdcc329396021f027ebe1cfa468f9625c2455b
Mar 13, 2021 02:43 UTC 203[.]159.80.241/bins/dark.x86 8d11635019b077d36ce7de2a3ca9261f126e0ff5808f722fcb967e7cd000be23
Mar 11, 2021 19:22 UTC 203[.]159.80.241/bins/dark.arm7 519b2d04e80c2cb7c000a3c00cb30098df363bd825281b2b7384d964b832df3b
Mar 11, 2021 19:22 UTC 203[.]159.80.241/bins/dark.arm6 7a571f666c8f272cce1ee7ad75520a013bbed800e7d0c80a17804500a3474a13
Mar 11, 2021 19:22 UTC 203[.]159.80.241/bins/dark.arm5 5d7487a5d6febb015a21a98eddffc617cfc06453fe2a7dacac6e1719f56c56fb
Mar 11, 2021 19:22 UTC 203[.]159.80.241/bins/dark.mpsl e9d056afe12210ddf98967e3291127ef9d0d24cbd36862ebc8b0726a565eefb8
Mar 11, 2021 19:22 UTC 203[.]159.80.241/bins/dark.mips 73aaf3ce3e5ea7a598f01d727e8278ff64ff0067fc2f2b22387b09de64c2ff4f
Mar 11, 2021 13:12 UTC 203[.]159.80.241/bins/dark.x86 64f9bc6e925fd2f538c89fd8a8c25d11521b9fcc51c8c5308e9850c990bea04b
Mar 11, 2021 12:59 UTC 203[.]159.80.241/bins/dark.ppc 0c4ec06f32d5f15846239d224d68086cbeaf513b63f0fcafa4eddd8e18a3d372
Mar 11, 2021 12:30 UTC 203[.]159.80.241/bins/dark.sh4 2f590f5af68dd30cdd51de85cb55dd16160ffce16dd326b2ac4c85e0007fca51
Mar 11, 2021 12:30 UTC 203[.]159.80.241/bins/dark.m68k cd59c912b9af910db1880d6fb86cd6cb656477552cf2c2fc82e372bafbe004b8
Mar 5, 2021 14:13 UTC 45[.]133.1.133/bins/dark.ppc 63e66d6f0ddf5fea5b1f71643bdb30f3fff4531c364b6fd1b0e0e0cfe5da833f
Mar 4, 2021 10:19 UTC 45[.]133.1.133/bins/dark.m68k 0a664a74fcc00910170edcd5f548569b40c2c5d58fc5ced1f475dbe938684e17
Mar 4, 2021 10:19 UTC 45[.]133.1.133/bins/dark.mips 05102e5abb23c761426c2c0f19f70f650938ea9e9295ccbb92349513c1d26c63
Mar 4, 2021 10:19 UTC 45[.]133.1.133/bins/dark.mpsl cc996d19c3e9b732b5f61fb7a2ad20a4f9e1fd7e62f484f15c7cc984a32dec01
Mar 4, 2021 10:19 UTC 45[.]133.1.133/bins/dark.sh4 f05225fec1fda7c6405e6961207ee12e198272d352144f516e970829a74093e2
Mar 4, 2021 10:19 UTC 45[.]133.1.133/bins/dark.x86 9aa0ded21b8c21075a6ad24180befc47dbfeb3985a433f1baa6181ec945a19b9
Mar 3, 2021 14:24 UTC 45[.]133.1.133/lolol.sh ecae298b18493bf2366f6081e8215a474cce4554e07a7b2380a7f8e8a3a9a37d
Mar 3, 2021 14:24 UTC 45[.]133.1.133/bins/dark.arm5 fb940b1049e0e95c03adb7a2750347108cadf6b19ef4149a5103f7625c07c8ec
Mar 3, 2021 14:24 UTC 45[.]133.1.133/bins/dark.arm6 515dc2fd8819c7fc82395acc4c7fb5b2903982a5f48bc26bc8d0235bc0664d1f
Mar 3, 2021 14:24 UTC 45[.]133.1.133/bins/dark.arm7 a9c4ea40b08ce4281c2dc9776355186dfc5649f9ec2b36c32fa5540f8d2aef2d
Mar 3, 2021 14:24 UTC 45[.]133.1.133/bins/dark.m68k ac75cb71c2f052141a238b8f7215d5a0956f7034cf90f231d228ce58254d23ba
Mar 3, 2021 14:24 UTC 45[.]133.1.133/bins/dark.mips 1e56f8ca44f84eff212805fa061ecb0f6fb8bc9499ff2e541ad3c43fb2f4420a
Mar 3, 2021 14:24 UTC 45[.]133.1.133/bins/dark.mpsl 1d9496814d35d9e302d7e99339e9730fc81c022bc085c0711b73ebad962cbc2b
Mar 3, 2021 14:24 UTC 45[.]133.1.133/bins/dark.ppc 971b5a96d84ca0d7dd906b639cd97a04835013be32356d09037cff64516c73bf
Mar 3, 2021 14:24 UTC 45[.]133.1.133/bins/dark.sh4 e2a6ac516ec8b5dcc76becc26cf992434882d490d8f2c9d7071298dba7a641a2
Mar 3, 2021 14:24 UTC 45[.]133.1.133/bins/dark.x86 a5ca43106a713c4a8e978575b8685889c244501288b9fa7c7dc7f1e8c5ef1291
Feb 26, 2021 13:14 UTC iotlmao[.]xyz/bins/dark.m68k a6cb6356432ca83467f6da2168be2aabbabe5d2f2dd4c01d6c4a93d01a57df53
Feb 26, 2021 13:14 UTC iotlmao[.]xyz/bins/dark.sh4 c686712f9be64e3d2957754ce181e5b4680b205cb6773b85b35df57983ed31cf
Feb 24, 2021 15:59 UTC 185[.]239.242.63/bins/dark.arm5 8cc6375f2eabe865e8400f27381a513a69e4100748458c3d2c706f3d4002bf1e
Feb 24, 2021 15:59 UTC 185[.]239.242.63/bins/dark.arm6 4414bf4f41663a6458372bcc4743d6e50bbb2d40c26d71bcb945926c98cd5537
Feb 24, 2021 15:59 UTC 185[.]239.242.63/bins/dark.arm7 8d0beb4b143dc4a9543b4bc5d7f44a6771a973709aaf8c3a4754d120b99d0afd
Feb 24, 2021 15:59 UTC 185[.]239.242.63/bins/dark.m68k f9770197d2254e6d5d4cb872b07dc25feb2994d4d5f0b3c854a98f9dfa3c6854
Feb 24, 2021 15:59 UTC 185[.]239.242.63/bins/dark.mips 74ab77e1069c6fb32925e89563c57f09c842cad0de6ab6b7c9ec2fa44d2641b1
Feb 24, 2021 15:59 UTC 185[.]239.242.63/bins/dark.mpsl 0039231b2fd5e5a3d86ae3b626d35b8fed7f2887a58e32b480ac82cd82150f7c
Feb 24, 2021 15:59 UTC 185[.]239.242.63/bins/dark.ppc 9d55aa1d9841be74cdc0c9d0a9fe2f20e0704ea30c721a7b2dcae02675416629
Feb 24, 2021 15:59 UTC 185[.]239.242.63/bins/dark.sh4 7aa437a562f3a956cf60fce652e6a0fb2d3c7cda0e5312c1a7fa62e177c45906
Feb 24, 2021 15:59 UTC 185[.]239.242.63/bins/dark.x86 8e65d7b16939834e1cd86b36b495924d34f10a8c477b53c9c8e648c804b97c2d
Feb 24, 2021 15:59 UTC 185[.]239.242.63/lolol.sh 5715d9c632c646c856f2775de8e98c00cade29f7bfb6fbe33a5741b01e897521
Feb 23, 2021 09:03 UTC 185[.]239.242.63/bins/dark.arm 5525b282df49206e76e884ca0f86806ddc97ec08343bab1d9a98f029a2697b08
Feb 23, 2021 09:03 UTC 185[.]239.242.63/bins/dark.arm5 b82b8957a4397eae1061a74fb7a8014cbbcbe7064d4edf2e0b15233fd2ce8cca
Feb 23, 2021 09:03 UTC 185[.]239.242.63/bins/dark.arm6 ec9dc19758ba74fb254c69d2b60ae1012b1bd65390e936990e4bd8573bcb83aa
Feb 23, 2021 09:03 UTC 185[.]239.242.63/bins/dark.arm7 38d8f2d17b3b676f5258a28b6b4093a1c3cdfa0d34d97c80d86686a3cff7ed55
Feb 23, 2021 09:03 UTC 185[.]239.242.63/bins/dark.m68k b066b1c1d019fc97e3649b99ad10294783b13a12b67d34b9c8500e762c37b7e7
Feb 23, 2021 09:03 UTC 185[.]239.242.63/bins/dark.mips 904b086dbf3e8f4dd1711d758d54675ce2d6002ff607a72d72d7e3aea612ba7d
Feb 23, 2021 09:03 UTC 185[.]239.242.63/bins/dark.mpsl 4f6a9d2c775e0ba38189390aa7975973209f8e703d6f974c2ab67c97ad263204
Feb 23, 2021 09:03 UTC 185[.]239.242.63/bins/dark.ppc c26401490ab9343b023f1f89b39d8d32835a795117ef7d7a129871bc05010dd6
Feb 23, 2021 09:03 UTC 185[.]239.242.63/bins/dark.sh4 73b35ddbf9784a6f6ebad7f5a1f4965daedc2f92cbb45a9cb76e61c0104bf553
Feb 23, 2021 09:03 UTC 185[.]239.242.63/bins/dark.x86 a925f0486b33f3f05d610d33c5a4b6bb2d5531c89e804e001ec01c4f5c25975e
Feb 23, 2021 09:03 UTC 185[.]239.242.63/lolol.sh 4fe20e73217d0bde39616ebf6f50f0f27882f939537561849f7b17968c5b8e30
Feb 22, 2021 16:30 UTC 37[.]46.150.102/bins/dark.mpsl 6b1bea5f17eb2c16815b8cb87d6e24e707248e5384fc4dd33c86c189657c73ff
Feb 22, 2021 16:30 UTC 37[.]46.150.102/bins/dark.ppc 918395bac079ab747736246b9d84e66921774d3eb95bb47045704624646b1287
Feb 22, 2021 16:30 UTC 37[.]46.150.102/bins/dark.sh4 528179f34ed9a6e69f582c23b3cbb50343164bf0e5995624a8d16f8b0df202e8
Feb 22, 2021 16:30 UTC 37[.]46.150.102/bins/dark.x86 f05d21a5b4b72a761c1540f1400dff7e39f10ac1c8b843ec8986d2e780a7807a
Feb 22, 2021 16:30 UTC 37[.]46.150.102/lolol.sh b3a20c8dfa5adaa8247c4d2097f3cc8423b4e270c9735f616628bf9bde583cbe
Feb 22, 2021, 12:32 UTC 185[.]239.242.63/bins/dark.arm5 2102b6a9f4b6745b0963ac3040945fb351c3d7df5b8e75dbc4ebf587c921998f
Feb 22, 2021, 12:32 UTC 185[.]239.242.63/bins/dark.arm6 bfd14a2f5c26501efb5d4010839b7d0bbc9a639d86ab5d12af663de598f15427
Feb 22, 2021, 12:32 UTC 185[.]239.242.63/bins/dark.arm7 d9f7504b3fe81f5264da5f23bdb7529f6d1dd713e28a92828180787729872a8d
Feb 22, 2021, 12:32 UTC 185[.]239.242.63/bins/dark.m68k 40808fb06796aeb740368b9bc322c12193d1bebb8e5eeddc420a98db6ac82689
Feb 22, 2021, 12:32 UTC 185[.]239.242.63/bins/dark.mips 3c47dceb9b8fbb0d40c3f1efa8ebc8d7dcf82aa0af46c4486ec3fc8ca29a83b2
Feb 22, 2021, 12:32 UTC 185[.]239.242.63/bins/dark.mpsl d31f1fecde01cc37950dc5b5330cd72e8ab1943f251bdfa5990f0d9d3a0a8e8f
Feb 22, 2021, 12:32 UTC 185[.]239.242.63/bins/dark.ppc 5446350c771766589e6d79e8185e10fcc0a6681eb76723b7f26dfef03c9080a5
Feb 22, 2021, 12:32 UTC 185[.]239.242.63/bins/dark.sh4 02f08ccc4a4136c89276135664267e08f1bb6795842a84c06c15478d3c3101e6
Feb 22, 2021, 12:32 UTC 185[.]239.242.63/bins/dark.x86 f467e6335a4a0250a17d61b3d138b31998f3e6669e1fcd1c3648db1b44b55ffa
Feb 22, 2021, 12:32 UTC 185[.]239.242.63/lolol.sh 4fe20e73217d0bde39616ebf6f50f0f27882f939537561849f7b17968c5b8e30
Feb 16, 2021, 11:01 UTC 37[.]46.150.102/brute/combo.txt 6a68acd757fab908b2455c9b5882c25ab4a550121c2badb960b0a514a04a8d3d
Feb 16, 2021, 11:01 UTC 37[.]46.150.102/brute/nbrute.386 baedd59eba62c289dcb722588895eb165f4a1570b3c012efc3dcc60d3bdea521
Feb 16, 2021, 11:01 UTC 37[.]46.150.102/brute/nbrute.amd64 8524826a687491c6bfd161df3e4fb2f537f50ea32834d7710dcf3b788a5ddfc2
Feb 16, 2021, 11:01 UTC 37[.]46.150.102/brute/nbrute.arm 4f69555ab71b49c2c1067f0907eb73b185327b57c566a8311ba9f9e58f4e85a5
Feb 16, 2021, 11:01 UTC 37[.]46.150.102/brute/nbrute.mips a5c2b758da21d7895c7945de8684c9b27370af6c5bf48ce3d94626261982659f
Feb 16, 2021, 11:01 UTC 37[.]46.150.102/brute/nbrute.mipsle b37da8e6afa2b3223b1f8f73e6801cf3fed3c0f114cfb9c134b5f06322a337ca
Feb 16, 2021, 11:01 UTC 37[.]46.150.102/bins/dark.arm5 a447bb67be310702807ff148f53f2b4c64ddba0c37f92caf6acabdfaa9ad6603
Feb 16, 2021, 11:01 UTC 37[.]46.150.102/bins/dark.arm6 b2122c5a9c738d964fa770760db40d6708de377e2e671feccb836054ceda2f47
Feb 16, 2021, 11:01 UTC 37[.]46.150.102/bins/dark.arm7 80cd13bfcc2fc29096abf18525d17766700a6d25a9806e55c7b7de776cba0302
Feb 16, 2021, 11:01 UTC 37[.]46.150.102/bins/dark.m68k 66ea76a427b69f153486f962baff29d4a68393e985c7d88c94d773b25ad4964a
Feb 16, 2021, 11:01 UTC 37[.]46.150.102/bins/dark.mips def1959fae2d8a3dfe606126ceb9d5403deae97a4b4e216dc8e60354980eeac4
Feb 16, 2021, 11:01 UTC 37[.]46.150.102/bins/dark.mpsl 667640d293e4ce2287546fc2e0056ee14f414868bf5b77f72078096c516a9fb0
Feb 16, 2021, 11:01 UTC 37[.]46.150.102/bins/dark.ppc beb0b7178b242f2dba21c3d91abf80e8738847b8086d2a42e9352738c83542b5
Feb 16, 2021, 11:01 UTC 37[.]46.150.102/bins/dark.sh4 554bee9f896a7a013804485894875348ff760b08ff7b0ae14c210e2b37da75f6
Feb 16, 2021, 11:01 UTC 37[.]46.150.102/bins/dark.x86 2a09719254934fe8ee8f200a0a7537d35a293fe1f8d0e396e23374e9b209f273

 

Threat Assessment: DearCry Ransomware

Posted on by Unit 42

Executive Summary

Last week, Microsoft reported that attackers compromised Exchange Mail Servers with the use of four zero-day vulnerabilities. While patches have been released by Microsoft, adversaries are still attacking vulnerable versions of Microsoft Exchange Servers with malicious tools, malware and data exfiltration. Further, Microsoft has confirmed the existence of a ransomware variant leveraging these vulnerabilities, which has been dubbed “DearCry.” It is reasonable to suspect that the ransomware authors were paying homage to an unrelated yet infamous ransomware family, “WannaCry,” which was used as a payload within an orchestrated attack campaign leveraging known Microsoft vulnerabilities to infect victims en masse.

Due to the surge of this malicious activity, we’ve created this threat assessment for overall threat awareness. Full visualization of the techniques observed and their relevant Courses of Action (CoA) can be viewed in the Unit 42 ATOM Viewer.

If you think you may have been impacted, please email crypsis-investigations@paloaltonetworks.com or call (855) 875-4631 to get in touch with the Crypsis Incident Response team.

DearCry Ransomware Overview

DearCry is a new ransomware variant that has been observed exploiting Microsoft Exchange Servers’ ProxyLogon vulnerabilities for initial access. Early reports of the appearance of DearCry ransom notes in tandem with associated Microsoft Exchange Server compromises via ProxyLogon vulnerabilities began to surface on March 9, 2021, and victims in the U.S., Canada and Australia are suspected, according to security researcher Michael Gillespie.

When executed, DearCry ransomware uses AES-256 and RSA-2048 to encrypt victim files, while also modifying file headers to include the string ‘DEARCRY!’ (see Figure 1).

When executed, DearCry ransomware uses AES-256 and RSA-2048 to encrypt victime files, while also modifying file headers to include the string "DearCry!" as shown here.
Figure 1. DearCry file header.

As with a majority of ransomware variants, DearCry deploys a ransom note to the victim’s desktop. However, instead of demanding a fixed ransom amount and including a Bitcoin wallet address, DearCry’s note includes two email addresses that the victim is asked to contact, as well as a request for a provided hash to be sent (see Figure 2).

DearCry ransom note: "Your file has been encrypted! If you want to decrypt, please contact us." What follows are two email addresses and a request for a provided hash.
Figure 2. DearCry ransom note.

During its execution, DearCry also runs a service named “msupdate” that is not native to the Windows operating system. This service is later removed when the ransomware finishes its encryption process. Furthermore, all logical drives on the Windows operating system, except for CD-ROM drives, are enumerated on the victim’s system so that the ransomware can begin to encrypt files using an RSA public key.

As of March 2021, DearCry ransomware has been seen targeting files with the following file extensions:
.TIF, .TIFF, .PDF, .XLS, .XLSX, .XLTM, .PS, .PPS, .PPT, .PPTX, .DOC, .DOCX, .LOG, .MSG, .RTF, .TEX, .TXT, .CAD, .WPS, .EML, .INI, .CSS, .HTM, .HTML, .XHTML, .JS, .JSP, .PHP, .KEYCHAIN, .PEM, .SQL, .APK, .APP, .BAT, .CGI, .ASPX, .CER, .CFM, .C, .CPP, .GO, .CONFIG, .PL, .PY, .DWG, .XML, .JPG, .BMP, .PNG, .EXE, .DLL, .CAD, .AVI, .H, .CSV, .DAT, .ISO, .PST, .PGD, .7Z, .RAR, .ZIP, .ZIPX, .TAR, .PDB, .BIN, .DB, .MDB, .MDF, .BAK, .LOG, .EDB, .STM, .DBF, .ORA, .GPG, .EDB, .MFS

At the time of this writing, all attributed samples leverage the .CRYPT extension for infected files.

DearCry encrypted files leverage the .CRYPT extension, as shown in this screenshot.
Figure 3. DearCry encrypted files.

Courses of Action

This section documents the relevant tactics, techniques and procedures ( TTPs) used by DearCry and maps them directly to Palo Alto Networks product(s) and service(s). It also further instructs customers how to ensure their devices are configured correctly.

Product / Service Course of Action

Initial Access

Exploit Public-Facing Application [T1190]
NGFW 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
Threat Prevention† 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 a secure Vulnerability Protection Profile is applied to all security rules allowing traffic
Deploy Content Pack 8380, which detects the four Microsoft Exchange zero-day vulnerabilities
WildFire† Ensure that WildFire file size upload limits are maximized
Ensure forwarding is enabled for all applications and file types in WildFire file blocking profiles
Ensure a WildFire Analysis profile is enabled for all security policies
Ensure forwarding of decrypted content to WildFire is enabled
Ensure all WildFire session information settings are enabled
Ensure alerts are enabled for malicious files detected by WildFire
Ensure 'WildFire Update Schedule' is set to download and install updates every minute
Cortex XSOAR Deploy XSOAR Playbook - Isolate Endpoint

Defense Evasion, Discovery, Impact

Disable or Modify Tools [T1562.001], File and Directory Discovery [T1083], Data Encrypted for Impact [T1486], Service Stop [T1489]
Cortex XDR Enable Anti-Exploit Protection
Enable Anti-Malware Protection
Look for the following BIOCs alerts to detect activity*:

Cortex XDR Agent - Behavioral Threat Detected

Cortex XDR Analytics - Multiple Discovery Commands
Cortex XSOAR Deploy XSOAR Playbook - Ransomware Manual

Table 1. Courses of Action for DearCry.
†These capabilities are part of the NGFW security subscriptions service.
* These analytic detectors will trigger automatically for Cortex XDR Pro customers.

Conclusion

DearCry is a new ransomware leveraging ProxyLogon vulnerabilities from Microsoft Exchange Servers. Furthermore, it is a perfect example of how threat actors can impact the threat landscape by taking advantage of newly disclosed vulnerabilities to make a quick profit. We strongly advise immediately updating all Microsoft Exchange Servers to the latest available patched versions released by Microsoft.

Palo Alto Networks customers are protected across our product ecosystem, with protections deployed in the following products and subscriptions:

It is imperative for customers to employ best practices in order to ensure Palo Alto Networks products are configured in a manner best suited for your protection.

Indicators associated with this Threat Assessment are available on GitHub, have been published to the Unit 42 TAXII feed and are viewable via the ATOM Viewer.

In addition to the above courses of action, AutoFocus customers can review additional activity by using the tag: DearCry.

Additional Resources

Palo Alto Networks has shared our findings, including file samples and indicators of compromise, in this report 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. For more information on the Cyber Threat Alliance, visit www.cyberthreatalliance.org.

Microsoft Exchange Server Attack Timeline

Posted on by Unit 42

Executive Summary

On March 2, the world was introduced to four critical zero-day vulnerabilities impacting multiple versions of Microsoft Exchange Server (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858 and CVE-2021-27065). Alongside revealing these vulnerabilities, Microsoft published security updates and technical guidance that stressed the importance of patching immediately, while concurrently noting active and ongoing exploitation by an Advanced Persistent Threat (APT) they call HAFNIUM. Since the initial attacks, Unit 42 and a number of other threat intelligence teams have seen multiple threat groups now exploiting these zero-day vulnerabilities in the wild. Both the vulnerabilities themselves and the access that can be achieved by exploiting them are significant. It is therefore unsurprising that multiple attackers sought and continue to seek to compromise vulnerable systems before they are patched by network administrators. This has been going on at an unprecedented scale – as of March 8, based on telemetry collected from the Palo Alto Networks Expanse platform, we estimated there remained over 125,000 unpatched Exchange Servers in the world.

Based on the reconstructed timeline, it’s now clear that there were at least 58 days between the first known exploitation of this vulnerability on Jan. 3 and when Microsoft released the patch on March 2. Applying the patch is a necessary first step, but insufficient given the amount of time the exploit was in the wild. The act of patching will not remediate any access that attackers may have already gained to vulnerable systems. Organizations can look to our remediation guide for steps they can take to ensure they have properly secured their Exchange Servers.

As we enter the second week since the vulnerabilities became public, initial estimates place the number of compromised organizations in the tens of thousands, thereby dwarfing the impact of the recent SolarStorm supply chain attack in terms of victims and estimated remediation costs globally. Given the importance of this event, we are publishing a timeline of the attack based on our extensive research into the information currently available to us and our direct experience defending against these attacks. As the situation continues to unfold, we urge others to also share what they uncover so that we as a cybersecurity community get a complete picture as quickly as possible.

Microsoft Exchange Server Attack Timeline Summary

This story begins over six months ago when DevCore, a Taiwan-based security consulting firm, first initiated a project to explore the security of Microsoft Exchange Server products. In the two-month window between October and December 2020, DevCore researchers made considerable progress that ultimately led to the discovery of a pre-authentication proxy vulnerability on Dec. 10, 2020. This vulnerability was given the name ProxyLogon by DevCore and is now known publicly as CVE-2021-26855.

Following this initial discovery, on Dec. 27, 2020, DevCore researchers demonstrated that this vulnerability could be leveraged to perform authentication bypass, thereby granting its users administrator-level permissions on vulnerable Exchange Servers. Shortly after this discovery, on Dec. 30, 2020, DevCore also discovered a second post-authentication file write bug that could be chained together with the first vulnerability to gain privileged access to Exchange Servers and write files of an attacker’s choosing to any directory. This second vulnerability is now known publicly as CVE-2021-27065.

Given the time of year and the existence of a long New Year’s holiday weekend, DevCore reached out and notified Microsoft of the vulnerabilities on the following Tuesday (Jan. 5, 2021). At the time, the researcher credited with the discovery of the vulnerabilities tweeted publicly.

The Microsoft Exchange Server attack timeline kicks off with a Twitter post from user Orange Tsai (@orange_8361): Just report a pre-auth RCE chain to the vendor. This might be the most serious RCE I have ever reported! Hope there is no bug collision or duplicate XD

At that point, attacks were already appearing in the wild. Volexity, a US-based security firm, reported attacks involving the ProxyLogon vulnerability as early as Jan. 3. On Feb. 2, the firm also reported to Microsoft information about attacks that occurred on Jan. 6.

Concurrently, it is now believed that Dubex, a Denmark-based security firm, first noted active exploitation of the Microsoft Exchange UMWorkerProcess on Jan. 18, 2021. This vulnerability is now known as CVE-2021-26857. It was used by an adversary to install webshells on vulnerable servers consistent with the attacks noted by Volexity. It has been reported that Dubex notified Microsoft of its findings on Jan. 27, less than 10 days after initial discovery.

Twitter post from User Dubex (@Dubex): In January 2021 the #Dubex Incident Response Team discovered a vulnerability on the Microsoft Exchange servers caused by the Chinese group Hafnium. Today @Microsoft has released patches for these vulnerabilities. The post is followed by a link and two hashtags: #HAFNIUM, #incidentresponse

With two cybersecurity vendors providing evidence of active exploitation, DevCore followed up with Microsoft on Feb. 18, 2021. During the exchange, DevCore provided a draft advisory notice and requested details concerning the patch release timeline. At the time, Microsoft shared that they planned to release the patches on March 9.

On Feb. 27, 2021 Microsoft notified DevCore that they were almost ready to release the security patches. That same day, the cybersecurity community observed an uptick in unusual webshell activity, and over the following two days, evidence suggests multiple threat groups began active exploitation activities. ESET reported three separate groups (Tick, LuckyMouse and Calypso) and our own analysis of webshells deployed in this window has identified six unique passwords and clusters of activity that further support the claim of multiple threat groups. It is also worth noting that one of the passwords observed on Feb. 28, 2021 was the name “orange,” which may serve as a reference to the researcher who originally discovered the vulnerability.

On March 2, 2021, a week earlier than initially planned, Microsoft published security updates for the four vulnerabilities. In doing so, they also warned of active exploitation of these vulnerabilities by a group they named HAFNIUM and further described as a state-sponsored APT operating out of China.

In the days following the publication of the CVEs, the cybersecurity community has witnessed a surge of attacks as malicious actors seek to capitalize on the vulnerabilities before network defenders deploy patches. Over the past week, we have also identified the emergence of several new webshell passwords and clusters of activity that have overlapping victim populations. Thus, we currently assess that several additional threat actors with varying motives have launched efforts to exploit these vulnerabilities as well.

Finally, in terms of the timeline, it is important to consider that while the Microsoft security updates were released on March 2, 2021, applying these updates only protects organizations from continued or future exploitation of these vulnerabilities. The security updates do not provide any protection from previous exploitation that may have resulted in compromise prior to the publication of the updates.

As documented above, there is definitive evidence that these exploits were in active use as far back as early January, thus resulting in at least a two-month window of vulnerability. However, a lack of evidence of exploitation prior to January should not be misinterpreted as a lack of adversary activity.

Key events in the Microsoft Exchange Server attack timeline are represented here. This tracks incidents beginning Dec. 10, 2020 (DevCore's discovery of a pre-authentication proxy vulnerability known as ProxyLogon) up through the current ongoing exploitation of the vulnerabilities.
Figure 1. High-level timeline of activity

Conclusion

Ongoing research illustrates that these vulnerabilities are being used by multiple threat groups. While it is not new for highly skilled attackers to leverage new vulnerabilities across varying product ecosystems, the ways in which these attacks are conducted to bypass authentication -- thereby providing unauthorized access to emails and enabling remote code execution (RCE) -- is particularly nefarious.

Unit 42 fully expects attacks leveraging these vulnerabilities to not only continue, but to increase in scope, likely including more varied attacks with different motivations, such as ransomware infection and/or distribution. Due to the fact that active attacks from various threat groups leveraging these vulnerabilities is ongoing, it’s imperative to not only patch affected systems, but also follow the guidance outlined from Unit 42’s previous remediation blog.

Additional Resources

 

Remediation Steps for the Microsoft Exchange Server Vulnerabilities

Posted on by Unit 42

Background

On March 2, the security community became aware of four critical zero-day Microsoft Exchange Server vulnerabilities (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858 and CVE-2021-27065).

These vulnerabilities let adversaries access Exchange Servers and potentially gain long-term access to victims’ environments. While the Microsoft Threat Intelligence Center (MSTIC) attributes the initial campaign with high confidence to HAFNIUM, a group they assess to be state-sponsored and operating out of China, multiple threat intelligence teams, including MSTIC and Unit 42, are also seeing multiple threat actors now exploiting these zero-day vulnerabilities in the wild. Estimated number of potentially compromised organizations is in the tens of thousands globally – and very importantly, these vulnerabilities were being actively exploited for at least two months before the security patches were available. As a result, even if you patched immediately, your Exchange Servers could still be compromised. Further, based on telemetry collected from the Palo Alto Networks Expanse platform, we estimate there remain over 125,000 unpatched Exchange Servers in the world.

Below you will find a concise playbook that enterprises can follow to respond to this potential threat in their environments.

1) Locate all Exchange Servers and determine whether they need to be patched.

Exchange Online is not affected.

Vulnerable Exchange Server versions include 2013, 2016, and 2019. While Exchange 2010 is not vulnerable to the same attack chain as Exchange 2013/2016/2019, Microsoft has released a patch for CVE-2021-26857 for this version of the software. Microsoft has recently released additional guidance for older, unsupported versions of Exchange.

Microsoft is recommending to install updates on all Exchange Servers, prioritising those that are externally/internet facing. Even if Exchange Servers are not internet facing, the vulnerabilities can still be exploited if access to the network has been achieved through other methods.

Microsoft has published information about the updates for the following specific versions of Exchange Server:

Exchange Server 2019 (update requires Cumulative Update (CU) 8 or CU 7).

Exchange Server 2016 (update requires CU 19 or CU 18).

Exchange Server 2013 (update requires CU 23).

Exchange Server 2010 (update requires SP 3 or any SP 3 RU – this is a Defense in Depth update).

2) Patch and secure all Exchange Servers.

Install the out-of-band security updates for your version of Exchange Server.

If you cannot update and/or patch an Exchange Server immediately, there are some mitigations and workarounds that may reduce the chances of an attacker exploiting an Exchange Server; these mitigations should only be temporary until patching can be completed. Palo Alto Networks Next-Generation Firewalls (NGFWs) updated to Threat Prevention Content Pack 8380 or later protect against these vulnerabilities if SSL decryption is enabled for inbound traffic to the Exchange Server. Cortex XDR running on your Exchange Server will detect and prevent webshell activity commonly used in these attacks.

The initial attack requires the ability to make an untrusted connection to Exchange Server port 443. You can protect against this by restricting access to the system from untrusted users. This can be achieved by only allowing access to the system from users who have already authenticated through a VPN, or by using a firewall to limit access to specific hosts or IP ranges. Using this mitigation will only protect against the initial portion of the attack. Other portions of the chain can still be triggered if an attacker already has access to the network or can convince an administrator to open a malicious file.

More information about using Palo Alto Networks products, including firewalls with security subscriptions, Cortex XSOAR for automation and Cortex XDR for endpoint protection, can be found in our Threat Assessment.

3) Determine whether an Exchange Server has already been compromised.

These vulnerabilities have been in the wild and actively exploited for over a month, with the earliest indications of exploitation leading back to Jan. 3. Any organization running the vulnerable software must evaluate if their server has been compromised. Patching the system will not remove any malware already deployed on the system. It would be prudent to assume Exchange Servers that exposed Outlook Web Access or Exchange Web Services to the internet are compromised until proven otherwise.

Check for suspicious process and system behavior, especially in the context of Internet Information Service (IIS) and Exchange application processes, such as PowerShell, Command shells (cmd.exe) and other programs executed in the applications’ address space. We describe how to use Palo Alto Networks Cortex XDR Pro endpoint protection to hunt for this attack in your environment in “Hunting for the Recent Attacks Targeting Microsoft Exchange.”

Microsoft has released PowerShell and Nmap scripts for checking your Exchange Server for indicators of compromise of these exploits. They have also released another script, available at the same link, that highlights differences in files from the virtual directories of your Exchange Server against those expected for your specific Exchange version. The Cybersecurity and Infrastructure Security Agency (CISA) has also published a list of tactics, techniques and procedures (TTPs).

As documented in the Unit 42 Threat Assessment Courses of Action table, the post-intrusion TTPs used by the initial actors conducting the Exchange attacks included the following:

  • Using Procdump to dump the LSASS process memory.
  • Using 7-Zip to compress stolen data into ZIP files for exfiltration.
  • Adding and using Exchange PowerShell snap-ins to export mailbox data.
  • Using the Nishang Invoke-PowerShellTcpOneLine reverse shell.
  • Downloading PowerCat from GitHub, then using it to open a connection to a remote server.

Since the initial attacks, we believe that other actors are trying to capitalize on the Exchange vulnerabilities, but their motivations and objectives may differ vastly, and so could their TTPs.

4) Engage an Incident Response team if you think you have been compromised.

If, at any point, you think your Exchange Server has been compromised, you should still take action to secure it against the vulnerabilities as described above. This will prevent additional adversaries from further compromising the system. Installing the out-of-band security updates for your version of Exchange Server is very important, but this will not remove any malware already installed on systems and will not evict any threat actors present in the network.

The potential impact of this situation is critical due to the ongoing activity described, the vulnerabilities exploited to deliver the attack and the adversaries who could be behind compromises. While exploits of these vulnerabilities may not halt business operations, access to sensitive information and systems is certainly possible, and should be assumed to have occurred. Access to corporate emails could also lead to followup phishing attacks.

If you believe you have been compromised, you should enact your incident response plan. If you need such services, our Palo Alto Networks Crypsis incident response team is available to help: crypsis-investigations@paloaltonetworks.com.

Additional Resources:

  1. Analyzing Attacks Against Microsoft Exchange Server With China Chopper Webshells
  2. Threat Assessment: Active Exploitation of Four Zero-Day Vulnerabilities in Microsoft Exchange Server
  3. Hunting for the Recent Attacks Targeting Microsoft Exchange
  4. HAFNIUM targeting Exchange Servers with 0-day exploits
  5. Operation Exchange Marauder: Active Exploitation of Multiple Zero-Day Microsoft Exchange Vulnerabilities
  6. Mass Exploitation of Exchange Server Zero-Day CVEs: What You Need to Know
  7. Multiple Security Updates Released for Exchange Server

 

Analyzing Attacks Against Microsoft Exchange Server With China Chopper Webshells

Posted on by Jeff White

Executive Summary

Microsoft recently released patches for a number of zero-day Microsoft Exchange Server vulnerabilities that are actively being exploited in the wild by HAFNIUM, a suspected state-sponsored group operating out of China. We provide an overview of the China Chopper webshell, a backdoor which has been observed being dropped in these attacks. We also analyze incidental artifacts, such as metadata, created by the attacks themselves, which allow us to collect information and better understand the nature and methodology of the attackers.

For information on how Palo Alto Networks protects its customers from these threats, please refer to our Threat Assessment: Active Exploitation of Four Zero-Day Vulnerabilities in Microsoft Exchange Server.

The Role of the China Chopper Webshell

By leveraging CVE-2021-27065, a post-authentication arbitrary file write vulnerability, an attacker is able to effectively inject code into an ASPX page for Exchange Offline Address Book (OAB). When this page is compiled with the injected webshell, the attacker can send other code and gain further access. The China Chopper webshell is a lightweight, one-line script that is observed being dropped in these attacks by the use of the PowerShell Set-OabVirtualDirectory cmdlet. This one-line webshell is relatively simple from the server perspective and has been observed in attacks since at least 2013, when FireEye reported on it.

The key detail here is that the China Chopper webshell is injected into a pre-existing OAB ASPX page that contains configuration information unrelated to the webshell. It’s been reported that there are thousands of compromises, and any on-premises Exchange Server that is exposed to the internet should assume it’s been scanned numerous times. Knowing this, and knowing that thousands of companies this week have begun the laborious chore of responding to these attacks within their infrastructure, it didn’t take long before these OAB files started popping up on VirusTotal (VT).

To identify the specific OAB configuration files we’re interested in, I created a small YARA rule to identify some of the observed templates for the China Chopper webshell as they exist within OAB configurations.

For reference, this is how the China Chopper webshell typically manifests itself within the OAB configurations – specifically in the ExternalUrl field.

ExternalURL

Additional variants will be discussed throughout the document, but this is the most prevalent.

As of March 4, 2021, there are 81 unique matching samples uploaded to VT.

As FireEye documented in their 2013 analysis of this webshell, China Chopper is technically split into two parts: a client and a server. When the client engages with the server, in most variants, it provides a “key” to act as authentication before executing whatever code the attacker supplies.

In the above China Chopper example, the key is " NO9BxmCXw0JE ". This provides us with a relatively unique identifier to compare to the other files. But why stop there?

OAB Artifacts

The OAB configuration contains a wealth of information such as when the file was created, when it was last modified, the Exchange version and numerous other server-specific related data points. These allow us to take a deeper look at the attacks from a new perspective and gain a better understanding of the attack campaigns involved.

On March 2, 2021, Volexity published their blog, “Operation Exchange Marauder: Active Exploitation of Multiple Zero-Day Microsoft Exchange Vulnerabilities,” which provided the first in-depth look at the attacks on Exchange Servers. However, we know that on Jan. 5, 2021, Twitter user @orange_8361 (Orange Tsai) tweeted that they had reported a pre-authenticated remote code execution (RCE) chain to a vendor. Microsoft credited this user in the slew of CVEs released to address the vulnerabilities. These two dates give us a frame of reference for analysis, as they mark the time from when Microsoft was notified to the first public disclosure of the attacks observed in the wild.

Looking at the keys used overall in the China Chopper webshells, the list below provides a count of each unique value. Of note is a C# variant of this webshell that does not have a similar key, two variants that do not include a webshell at all but include a possible key and one that is a Base64 encoded string of non-ASCII bytes.

As noted, two “keys” did not contain a webshell at all, “ f34fji34r209ur29ur92ru ” and “ dsfg ”. Instead, we observed an injection of a value, which appears similar in nature to a key, but is missing the actual webshell code required to carry out further code execution. An example can be seen below and compared to the webshell above.

ExternalURL2

When looking at some of the temporal data points, specifically the DateModified time of the OAB files, you will see that the usage of these “keys” predates all the other key usage by almost a full day. Since there is no webshell, these may have been test runs. In fact, they show overlap with other keys that later compromise the same server with full webshells.

DateModified WebShellKey OriginatingServer
2/27/2021 13:45:30 f34fji34r209ur29ur92ru NS1[...]net
2/27/2021 16:20:49 f34fji34r209ur29ur92ru DC1[...]LOC
2/27/2021 19:11:07 f34fji34r209ur29ur92ru FIT[...]cal
2/28/2021 0:04:23 f34fji34r209ur29ur92ru V-T[...]com
2/28/2021 1:41:07 f34fji34r209ur29ur92ru DC-[...]net
2/28/2021 3:51:56 f34fji34r209ur29ur92ru MBD[...]org
2/28/2021 10:15:00 NO9BxmCXw0JE DC[...]net
2/28/2021 10:33:14 NO9BxmCXw0JE FIT[...]cal
2/28/2021 10:36:44 orange JTA[...]cal

The NO9* key from above is the most prevalent thus far, judging by what’s currently available on VT. It has also been displayed in most of the research that has come out on this topic. This key shares a pattern with five other keys in the list. These are considered related due to their timing and unique usage of an exactly 12-character randomized alphanumeric string with mixed capitalization.

Within this grouping, only the NO9* and EiH* keys were observed in the OAB files with dates prior to the March 2 Volexity blog. It is also interesting to observe the clustering of dates and times when these unique OAB files documented their modification times, as highlighted in the table below.

DateModified WebShellKey OriginatingServer
2/28/2021 10:15:00 NO9BxmCXw0JE DC-[...]net
2/28/2021 10:33:14 NO9BxmCXw0JE FIT[...]cal
2/28/2021 10:44:24 NO9BxmCXw0JE NS1[...]net
2/28/2021 11:01:52 NO9BxmCXw0JE DC2[...]LOC
2/28/2021 11:03:12 EiH4yV2WGYgc DFC[...]com
2/28/2021 12:44:40 NO9BxmCXw0JE WP-[...]cal
2/28/2021 16:46:21 NO9BxmCXw0JE tcs[...]cal
3/1/2021 6:29:17 NO9BxmCXw0JE mar[...]cal
3/1/2021 7:40:44 NO9BxmCXw0JE cow[...]cal
3/1/2021 12:01:14 NO9BxmCXw0JE MM1[...]pvt
3/1/2021 12:16:38 NO9BxmCXw0JE NCR[...]cal
3/1/2021 13:46:04 NO9BxmCXw0JE a-p[...]com
3/1/2021 3:39:49 PM NO9BxmCXw0JE grr[...]cal
3/1/2021 16:25:57 NO9BxmCXw0JE DC2[...]LOC
3/1/2021 16:42:10 NO9BxmCXw0JE VCC[...]org
3/1/2021 19:28:28 NO9BxmCXw0JE NS1[...]net
3/1/2021 21:32:42 NO9BxmCXw0JE DC0[...]cal
3/1/2021 21:53:34 NO9BxmCXw0JE thi[...]cal

On Feb. 28, 2021, and March 1, 2021, there are two distinct clusters of events – before public news about the vulnerabilities is released. Looking at the UTC timing of the events shows some compromises happening just minutes apart using both the NO9* and EiH* keys, further corroborating their relation to each other. The timing is also noteworthy because it shows very rapid deployment of these webshells throughout the day and night, indicating an automated approach to targeting. As more samples appear, a better picture of the timeline will emerge.

Continuing to dig down into the data points for the six keys, we can extrapolate the targets based on their OriginatingServer values and deduce a wide range of businesses from investment banking, small car dealerships, water conservatories, industrial automation, law firms, hospitality and so on. The apparent randomness of targeted industries supports the idea that this is automated scanning that took advantage of opportunistic targets versus a coordinated effort to target specific industries or businesses.

One last piece of evidence in support of the idea of automated scanning: There are multiple OAB files with the same configurations but different modification times, thus creating unique hashes. Looking at two servers from the OriginatingServer data points, it can be noted below how they are compromised again at a later date with the exact same webshell and key, implying that systems the attackers have compromised already are not checked during their scanning and exploitation process.

DateModified WebShellKey OriginatingServer
3/1/2021 21:32:42 NO9BxmCXw0JE DC0[...]cal
3/2/2021 16:57:12 NO9BxmCXw0JE DC0[...]cal
2/28/2021 11:01:52 NO9BxmCXw0JE DC2[...]LOC
3/1/2021 16:25:57 NO9BxmCXw0JE DC2[...]LOC

Pivoting to the keys, which did not match the previously discussed pattern, we can see they start compromising the same servers as the other group of keys – but only after all of the research, CVEs, and proofs-of-concept (PoCs) started to pop up, leading us to believe these are different clusters of actors behind the attacks.

DateModified WebShellKey OriginatingServer
3/1/2021 6:29:17 NO9BxmCXw0JE mar[...]cal
3/2/2021 7:03:15 NO9BxmCXw0JE mar[...]cal
3/3/2021 15:19:46 Ananas mar[...]cal
2/28/2021 10:44:24 NO9BxmCXw0JE NS1[...]net
3/1/2021 19:28:28 NO9BxmCXw0JE NS1[...]net
3/3/2021 6:46:16 Q4IDLjknOZJr NS1[...]net
3/3/2021 6:52:08 klk123456 NS1[...]net

Before moving on to the next section, let’s turn our attention to three curious keys that were observed prior to the Volexity publication that do not match the pattern observed for the NO9* key but have very similar timing. This, along with other data points, seems to indicate these were used as testing or non-automated manual attacks.

The first is the key “orange”. The first compromise observed with it in these publicly available OAB files is minutes before and after two surrounding compromises by the NO9* key on Feb. 28. This key also falls into the cluster of events on March 1, two hours before the previously discussed attacks.

28FEB2021

DateModified WebShellKey OriginatingServer
2/28/2021 10:33:14 NO9BxmCXw0JE FIT[...]cal
2/28/2021 10:36:44 orange JTA[...]cal
2/28/2021 10:44:24 NO9BxmCXw0JE NS1[...]net

01MAR2021

DateModified WebShellKey OriginatingServer
3/1/2021 4:25:25 orange Exc[...]CAL
3/1/2021 6:29:17 NO9BxmCXw0JE mar[...]cal
3/1/2021 7:40:44 NO9BxmCXw0JE cow[...]cal

The second and third keys are simply “o” and “p”. Besides standing out due to their shortness, they also use a different structure in their webshell and appear to have targeted a medical facility and something related to the Vietnamese government, both prior to any publication about the vulnerabilities.

The Microsoft blog on HAFNIUM displays a webshell dropped by HAFNIUM that also uses a parameter value of “p”, although it is a different structure. A screenshot of the webshell displayed there is transcribed below, along with an example of the one observed in an OAB file.

Notable similarities exist in the Request.Form parameter value, “p”, and the usage of a single-letter character for the other values; however, this in and of itself does not necessarily confirm a HAFNIUM connection.

Looking at the “o” and “p” keys found in the OAB files, they can be seen targeting the same systems days apart.

DateModified WebShellKey OriginatingServer
2/28/2021 11:57:01 o ad2[...].vn
3/3/2021 7:58:20 p ad2[...].vn

Furthermore, we can observe compromises by the cluster of six patterned keys and “o” key happening fairly close in time to one another, alluding to a possible connection between them.

DateModified WebShellKey OriginatingServer
2/28/2021 11:03:12 AM EiH4yV2WGYgc DFC[...]com
2/28/2021 11:57:01 AM o ad2[...].vn
2/28/2021 12:44:40 PM NO9BxmCXw0JE WP-[...]cal

Two more keys stand out in terms of volume. Like the other keys that have been discussed, both “klk123456” and “Ananas” were observed in overlapping compromises, indicating automated scanning or using some type of list that has already been correlated from a scanning service.

DateModified WebShellKey OriginatingServer
3/3/2021 4:34:20 klk123456 Bed[...]com
3/3/2021 6:52:08 klk123456 NS1[...]net
3/3/2021 6:55:34 klk123456 Fil[...]cal
3/3/2021 7:26:29 klk123456 mna[...]com
3/3/2021 7:35:48 Ananas ric[...]org
3/3/2021 7:45:40 Ananas ADA[...]cal
3/3/2021 7:47:15 klk123456 PSL[...]cal
3/3/2021 10:43:51 klk123456 CHG[...]SYS
3/3/2021 11:02:09 klk123456 TRD[...]com
3/3/2021 14:35:40 Ananas jus[...].nl
3/3/2021 14:50:18 Ananas asi[...]com
3/3/2021 14:51:13 Ananas Bed[...]com
3/3/2021 15:19:46 Ananas mar[...]cal
3/3/2021 16:16:21 Ananas V-T[...]com
3/3/2021 16:40:03 Ananas FHM[...]org

These clusters of events are likely related to threat actors who were able to weaponize the public information extremely quickly and get a head start on attacking Exchange Servers before other actors could.

All the compromises with the other keys appear unrelated and occur after the patches, research and PoC code had become easily accessible.

Variations in the China Chopper Webshell

Recall the most prevalent China Chopper shell as observed in the OAB file.

ExternalURL 5

A Twitter user, @mickeyftnt, notified me that they found a variant using a different pattern from the “http://f/” that I had been watching stream into VT. This variant used “http://g/” and contained a space after the eval method call. Microsoft states the ExternalUrl parameter “specifies the URL that’s used to connect to the virtual directory from outside the firewall,” so we can assume that, in a legitimate file, this is a resolvable domain but may require the “http” precursor to be accepted as a value for the injection to work. While this piece of the URL is moot and does not affect the operation, the use of “http://f/” is observed across the board in almost every one of the attacks. As such, the “http://g/” variable piqued my interest as another likely artifact worth taking note of, even though no additional patterns have been noticed outside what’s been discussed here already.

ExternalURL 6

Another Twitter user, @krausedw, brought some samples to my attention that included breaking up the “unsafe” word in an attempt to bypass certain security measures and a C# sample that calls out the script language explicitly.

JScript unsafe

ExternalURL 7

C#

Ext

Finally, there are variants that use Base64 strings as the key.

Base64

E

Conclusion

By leveraging the artifacts found within the OAB configurations, we are able to piece together a narrative around the activity based on analysis from just a small set of samples. It seems clear that there are numerous clusters of groups leveraging these vulnerabilities, the groups are using mass scanning or services that allow them to independently target the same systems, and finally there are multiple variations of the code being dropped, which may be indicative of iterations to the attack. As more information and files become available, this analysis may have to be revisited, but for now, there are a sufficient number of connections that allow us to understand the how, the when and the frequency of attacks, along with clustering of events.

Additional Resources

Overview of dnsmasq Vulnerabilities: The Dangers of DNS Cache Poisoning

Posted on by Daniel Prizmant

Executive Summary

DNS masquerade (dnsmasq) is a widely used open source DNS resolver. While one might not be familiar with dnsmasq by name, it is used by many projects and hardware firmwares around the world, from Kubernetes to routers and other products.

Over the years, multiple critical vulnerabilities have been found in dnsmasq. Recently, security researchers discovered new issues that continue to make dnsmasq vulnerable. These vulnerabilities can lead to DNS cache poisoning, denial of service (DoS) and possibly remote code execution (RCE). In this blog, I will review these vulnerabilities in dnsmasq, with a deep dive on DNS cache poisoning. I will also cover the effect such issues have on cloud products such as Kubernetes.

Palo Alto Networks customers are protected from the attacks outlined in this blog with Next-Generation Firewall with DNS Security, and Prisma Cloud.

Background on DNS Vulnerabilities

As covered in detail in my previous blog, “The History of DNS Vulnerabilities,” port and transaction ID randomization is one of the key methods a modern DNS resolver uses to protect against cache poisoning.

Cache poisoning is an attack in which one poisons the DNS resolver’s cache by sending malicious responses. The attack happens after a DNS resolver sends a request to an upstream server. At this point, the attacker sends fake responses that appear to come from the server the victim organization contacted. The DNS resolver receives the malicious responses and caches them. From then on, when a victim organization asks the DNS resolver for this domain, it will answer with the IP address of an attacker controlled server. This results in redirections that can be very hard to detect. For example, a user might browse to a bank’s website, having typed the URL correctly – but instead of returning the IP address of the bank, a cache poisoning attack could cause the DNS resolver to send the user to an attacker’s IP address instead. Because of the serious implications of this possibility, DNS vulnerabilities are often critical.

One of the mitigations against this attack is to randomize the transaction ID and source port of the request from the resolver to the upstream server. By randomizing those two values, each is 16 bits long, and each request has a 32 bit key that an attacker has to match in order to make malicious responses get accepted by the DNS resolver.

Figure 1. Recap of a DNS cache poisoning attack.
Figure 1. Recap of a DNS cache poisoning attack.

CVEs

Two types of vulnerabilities were recently discovered in dnsmasq:

A bug in the implementation of the DNS protocol, such as validation issues, that can be leveraged for DNS cache poisoning attacks:

And buffer overflow bugs that can lead to DoS attacks:

So far, the implications of the buffer overflow vulnerabilities seem limited to DOS attacks.

The first group of vulnerabilities, however, can be exploited to perform devastating cache poisoning attacks, and I will be focusing on them in this blog.

There are a few key design implementations special to dnsmasq, and knowing how they work helps provide a good understanding of the recent vulnerabilities.

CVE-2020-25684: Transaction ID and Port Randomization Done Incorrectly

dnsmasq implements transaction ID and port randomization. By default, it supports up to 64 ports at the same time. This means that dnsmasq can hold open sockets of 64 ports simultaneously and wait for responses on each of those port sockets. An attacker has to guess the source port (any of the 64 that are open) correctly. Otherwise, malicious packets will simply be dropped on the dnsmasq server.

That sounds like a good mitigation, but the problem lies in the fact that dnsmasq didn’t match transaction ID to source port. Instead of having to guess the exact transaction ID and the exact source port, an attacker needs to guess just the transaction ID and any of the 64 ports. This weakens the port randomization mitigation by 64 times.

What this means is that because dnsmasq doesn’t match a transaction ID to a specific port, it increases the chances of hitting an open request by 64 times – an attacker can succeed by hitting any of the 64 open ports.

How Does dnsmasq Match Responses to Requests?

A frec, or a forward record, is a record that is received at dnsmasq but isn’t in the cache, so dnsmasq has to forward the request to an upstream server. As long as the request isn’t fulfilled, meaning the dnsmasq hasn’t received a response yet for the associated request, it is called a frec. An attacker that wants to poison dnsmasq needs to send it a fake response for a frec. frecs are removed once fulfilled or a certain amount of time has passed (timed out).

But how does dnsmasq match each response to the correct frec? dnsmasq saves only the hash of the question section in the DNS query and discards the rest. Each DNS query has a “questions” section. It is where the query holds the actual question, for example: where is www.example.com.

It can do that because each DNS response also contains the question it is answering, so both the request and the response have this section. This section is completely identical on both sides, which makes it great to use as a key. dnsmasq hashes the question before it sends the request and then hashes the question in the received response and matches it to a question it asked, meaning a frec.

This is a simplified version of dnsmasq’s algorithm for matching a frec when it is received from the upstream server:

1.0 check if response’s destination port matches any of the open ports

1.1 if not: drop the response

2.0 set key = (hash of the response’s question, transaction ID)

3.0 search for matching frec by key

3.1 if not found: drop the response

4.0 process the response

By default, dnsmasq supports up to 150 frecs at the same time. This means that it is possible that in a given time there will be 150 open frecs. Each of those frecs uses one of the 64 randomized ports that we covered earlier.

There are two ways to abuse this behavior, which both result in the same outcome and I will cover them both in the next section.

CVE-2020-25685: Weak Hashing Algorithm

dnsmasq uses a custom CRC32 function as its hashing function for the key. Unfortunately, CRC32 is not a cryptographically secure hash function. In other words, it is possible for different inputs to have the same output. In this case, different question sections can result in the same output. An attacker can abuse that to craft a special list of domains that all result in the same Custom-CRC32 hash and then send 150 queries to dnsmasq using that list.

CVE-2020-25686: Pending Queries Are Not Checked

dnsmasq allows multiple queries for the same domain. It means that an attacker can just query www.example.com 150 times before dnsmasq is able to receive results for any of the requests, and there will be a timeframe in which there are 150 open frecs for those 150 queries.

Note that if an attacker issues an attack from a web browser, most modern web browsers will block further requests to the same domain and this method will not work. In such a case, the attacker would have to use the previous method, which is a bit more complicated.

Outcome

Both of those problems can result in the same thing. An attacker who wants to send fake responses can choose to do that in a time frame in which dnsmasq holds 150 frecs, with the exact same hashed question key, with 150 different transaction IDs and with 64 different ports.

An attacker needs to time this correctly and send fake responses in that tiny time frame when all open 150 frecs are of the same domain. The attacker’s fake responses will also be for that domain. In such a case, the attacker's chances of hitting any of the open frecs are 150 times greater than in a regular attack.

No Response Verification

When dnsmasq receives a response from an upstream DNS server, it does not verify it. In order to understand the problem here, one needs to be familiar with CNAME records.

A Canonical Name or CNAME record is a type of DNS record that maps an alias name to a true or canonical domain name. CNAME records are typically used to map a subdomain such as www or mail to the address hosting that subdomain’s content. For example, a CNAME record can map the domain mail.example.com to the mail server of the domain example.com.

In dnsmasq, however, one can send any A record after the CNAME record and dnsmasq will simply trust the response without verifying it. No one asked about those A records, so dnsmasq will not forward those records to the client. Instead, it simply caches all the A records that it is given. Not only that, dnsmasq will also overwrite any already cached addresses. For example:

www.example[.]com  CNAME  www.bank[.]com

www.bank[.]com     A      13.37.13[.]37

In the above example, if dnsmasq received such a response for an open request for www.example[.]com and the attacker got the correct transaction ID and source port, dnsmasq will overwrite the cached address of www.bank[.]com regardless of the TTL (Time to Live) of previously cached addresses. From now on, any organization that tries to access their bank’s website will end up accessing an attacker-controlled website.

This sounds crazy, but it isn’t. If dnsmasq had to verify every line after the CNAME, that would reduce its performance dramatically. It would have to contact each domain in the CNAME response and make sure the A record given is indeed its address, which will make the entire idea of CNAME redundant.

So instead, dnsmasq trusts the source of the response, on the assumption that it is nearly impossible to beat the transaction ID and source port randomization mitigation.

Attack Scenario Explained

Theory

In order to craft a successful DNS cache poisoning attack, one must correctly guess the transaction ID and source port. Usually this means guessing a 32-bit key – 16 bits for the port and 16 bits for the transaction ID.

In our case, as I demonstrated so far, CVE-2020-25684 helps the attacker by increasing the chances of hitting the correct port by 64 times, so the port part of the key is reduced to 16-log264=10 bits long. Combined with the transaction ID key, our key is still 26 bits long. The chances of hitting a successful frec so far are 1 to 226 = 67,108,864 with a single response.

With either CVE-2020-25685 or CVE-2020-25686, we concluded that using 150 requests with the same question’s hash, either with the same domain or with a special list, increases the chances of hitting the correct frec by 150 times. Combining that with CVE-2020-25684 increases the chances of hitting a successful frec by 64 * 150 = 9,600 times. The chances of hitting a successful frec so far is 1 to 232/9600 = 447,392 times.

Another thing is that usually an attacker would have to wait for a DNS entry Time to Live value to be expired (to be removed from cache) in order to poison it – otherwise the DNS resolver would simply give the results from cache right away and no poisoning will take place. In our case, however, an attacker can abuse the CNAME record in order to poison any entry desired.

Attack Scenario

An attacker wants to poison www.bank[.]com. Usually, this would require waiting for www.bank[.]com to be out of cache, guessing the port correctly and guessing the transaction ID correctly. Only then would the attacker have a chance of actually succeeding.

If the DNS resolver is dnsmasq, the attacker can skip the first part and just query any domain that would not be in the cache. Instead of responding with a regular A record response, the attacker would respond with a CNAME, as described earlier.

The attacker still needs to guess the port and the transaction ID, which is a 32 bit long key.

Figure 2. Cache poisoning attack on dnsmasq.
Figure 2. Cache poisoning attack on dnsmasq.

Using the above vulnerabilities, an attacker can issue 150 requests, either for the same domain or with a list of domains with the same custom-CRC32 hashes. This way, they will have 150 possible transaction IDs to guess and need to hit only one of them. As calculated above, using this method, the attacker will have a 9,600 times greater chance of succeeding with each response.

If the attacker manages to hit with one of the fake responses, dnsmasq will receive the CNAME response and will cache all the A records in it.

Chances for a Successful Attack

In my last blog about DNS, I dived into the probability calculation needed to understand what is the likelihood of succeeding in a DNS cache poisoning attack with different amounts of mitigations. The calculations are the same as last time, but with a key size of 232 / 9600 = 447,392.

An attacker needs to hit any of the 150 transaction IDs and any of the 64 open ports to succeed in the attack.

I managed to create a reliable proof of concept (PoC) in a simulated network, which could poison a dnsmasq resolver from inside an internal network in less than five minutes in the worst case, and under 10 seconds on average for a successful attack.

Kubernetes and OpenShift

dnsmasq is part of kube-dns which is the DNS service of Kubernetes. The kube-dns service is made up of three containers running in a kube-dns pod in the kube-system namespace.

The three containers are:

  • kube-dns: A container that runs SkyDNS, which performs DNS query resolution.
  • dnsmasq: Caches responses from SkyDNS.
  • sidecar: A sidecar container that handles metrics reporting and responds to health checks for the service.

In the past, Kubernetes and OpenShift used kube-dns for DNS services.

As of Kubernetes v1.12, CoreDNS is the recommended DNS Server, replacing kube-dns. If your cluster originally used kube-dns, you may still have kube-dns deployed rather than CoreDNS. kube-dns uses dnsmasq, which is potentially dangerous as discussed in this article. However, CoreDNS doesn’t use dnsmasq, so newer versions of Kubernetes are not affected.

Applications

A Kubernetes or OpenShift cluster that uses dnsmasq will be vulnerable to the attacks described above. It is enough for a single deployment to be breached in order to poison the entire cluster. Another possible situation involves a dnsmasq machine that was misconfigured and is open to the internet, instead of just the internal network. That scenario is even worse, as DNS resolvers open to the internet are easy to find by bots scanning public IPs.

Conclusion

These vulnerabilities show once again why DNS cache poisoning is relevant to this day, despite all the mitigations that have been added over the years.

Having said that, with secure browsing and certificates usage nowadays, even if an attacker manages to poison a DNS server for a domain, it is most likely that the victim organization’s browser won’t load the page because the certificates won’t match. But the technique can still be used for enormous DoS attacks by poisoning an ISP’s DNS resolver and forwarding requests to a nonexistent IP address.

In the cloud, however, the problem is much bigger. As discussed earlier, Kuberenetes used to use dnsmasq as its default DNS resolver until not so long ago. Even today, users can still choose to use dnsmasq instead of CoreDNS. In such a scenario, an attacker who manages to poison a cluster’s DNS resolver can cause an enormous amount of damage because, unlike browsers, cloud applications usually don’t do certificates verification.

An attacker who breaches a single container can easily use this attack to spread further into the entire cluster, even without a container escape vulnerability.

Palo Alto Networks customers are protected from the attacks outlined in this blog in a variety of ways. Palo Alto Networks Next-Generation Firewalls can block DNS attacks by detecting suspicious DNS queries and anomalous DNS responses. Attacks related to exhaustion or high quantities of traffic are handled with DoS or zone protection profiles that are built into the firewall. These protections are in addition to coverage of DNS threats and indicators through DNS Security.

Furthermore, Prisma Cloud customers are protected from this threat through the Prisma Cloud Compute Host and Container Vulnerability Scanner, which alerts on vulnerable software components. The attack described in this blog requires one of the following, in addition to an old and vulnerable dnsmasq deployment:

  • A breach in the internal network of the cluster to be able to send malicious packets to the DNS server from the inside.
  • A misconfigured DNS resolver that is open to the internet.

Such scenarios almost always happen by attackers exploiting outdated and misconfigured applications, which are monitored by the Prisma Cloud Compute Compliance Protection.

Attack Chain Overview: Emotet in December 2020 and January 2021

Posted on by Chris Navarrete

Executive Summary

Unit 42 researchers have identified and analyzed a new update of Emotet, the notorious banking Trojan, that has been active in the wild since December 2020. Emotet has long been a thorn in the side of defenders with a reputation for its tenacity, longevity and resilient evasion techniques.

Recent actions by international law enforcement have disrupted the Emotet threat actors and their infrastructure. However, the tactics, techniques and procedures (TTPs) employed in this Emotet update present an opportunity to expose the inner workings of an active, prominent threat against all industries.

In this blog, we will detail the end-to-end attack chain of this Emotet update, including its first-stage malicious document lure, the deobfuscation of its payload into a second-stage PowerShell loader and the downloading of the third-stage binary R43H.dll.

We will also detail the persistence mechanisms used by this Emotet update, as well as the command and control (C2) channel and its indicators of compromise (IOCs). Lastly, we will demonstrate the difficulties that security solutions face against Emotet’s evasion techniques.

Palo Alto Networks Next-Generation Firewall customers are protected from Emotet with Threat Prevention and WildFire security subscriptions. Customers are also protected with Cortex XDR.

Attack Chain Analysis

Emotet is commonly distributed with a Word document attached in phishing emails. Below are the steps in an Emotet attack chain:

  1. Word doc distributed and opened with macros enabled.
  2. VBScript macro(s) runs to generate the malicious PowerShell script.
  3. The malicious PowerShell script downloads the initial DLL binary as a loader.
  4. The initial loader drops a follow-up DLL binary that updates itself.
  5. The final DLL steals victims’ sensitive data or conducts further attacks by communicating with C2 servers.

Emotet attack chain analysis details

First-Stage Malware – Word Macro Launcher

(Sha256: 2cb81a1a59df4a4fd222fbcb946db3d653185c2e79cf4d3365b430b1988d485f)

The analyzed sample is a Microsoft Office OLE2 Compound File Binary Word file. As with many spear-phishing attacks, this one also social-engineers the user to enable macro support to start the delivery of malicious Visual Basic for Applications (VBA) code.

Figure 1. This malicious Word document contains an embedded macro that initiates an Emotet attack chain.
Figure 1. This malicious Word document contains an embedded macro that initiates an Emotet attack chain.

The embedded VBA macro code is executed when the user opens the lure document in Microsoft Word with macros enabled, spawning a Document_Open() event.

Figure 2. The embedded VBA macro code is obfuscated to impede analysis efforts.
Figure 2. The embedded VBA macro code is obfuscated to impede analysis efforts.

The next call is to a function named Jotxu6biv0471oy0(). The behavior of this function and further execution of the first-stage malware is described below:

1. Retrieve a single StoryRange of the wdMainTextStory type from the document’s StoryRanges.Item() method and store it in the variable mKbjhqs. The content of that variable is the obfuscated payload data that will be deobfuscated later in the attack chain. A StoryRange in the VBA world is used to find or replace text inside a document.

Figure 3. The obfuscated payload is extracted from the malicious document and stored.
Figure 3. The obfuscated payload is extracted from the malicious document and stored.

2. Collect obfuscated data through a series of GoTo calls, which stores data across several variables. The data is then concatenated and assigned to variable C_tmpi32le9.

Figure 4. The obfuscated payload is extracted from the malicious document and stored.
Figure 4. The obfuscated payload is extracted from the malicious document and stored.

3. The string stored in C_tmpi32le9 is deobfuscated and substituted in a series of function calls displayed in Figure 4.

Figure 5. Replace function and data before and after obfuscation.
Figure 5. Replace function and data before and after obfuscation.

The text payload stored in C_tmpi32le9 is deobfuscated with a call to function Lehj73snaqzhyepdw9(). This function works as a wrapper for function Jumkzxvtzz2s(), which implements a simple string substitution routine. The function also calls the built-in function Replace(), which is passed the string ]b2[s as the delimiter to search and replace in the payload string. The resulting payload is the WMI moniker winmgmts:win32_process, which is stored in variable H4qcty67722xqmrmn.

4. Generate a new object by making a call to the CreateObject() function and passing as parameter the winmgmts:win32_process string. The resulting object value is stored in the Fcqv6woostm0 variable, which is an object of the Win32_Process WMI Class. This variable is a handle to an object capable of spawning new processes.

Figure 6. Call to CreateObject(“winmgmts:win32_process”) constructor.
Figure 6. Call to CreateObject(“winmgmts:win32_process”) constructor.

5. Perform a length correction routine and store the resulting data in variable Ma9hdg7q365lpb. A call to function Lehj73snaqzhyepdw9() is made with Ma9hdg7q365lpb as a parameter.

Figure 7. Deobfuscated final payload.
Figure 7. Deobfuscated final payload.

6. A call to method Win32_Process.Create() is made by referencing the previously instantiated object and passing as first parameter the returning value of the previously executed Lehj73snaqzhyepdw9() function. The returning value contains the deobfuscated final payload (operating system and PowerShell commands).

Figure 8. Create() function call with parameters.
Figure 8. Create() function call with parameters.

The first stage of this Emotet attack chain ends with the execution of the deobfuscated payload originally embedded in the malicious document. The payload contains a series of calls to cmd.exe nested around an obfuscated call to PowerShell with base64 data passed as an argument.

Figure 9. Deobfuscated OS and PowerShell commands.
Figure 9. Deobfuscated OS and PowerShell commands.

Second-Stage Malware – PowerShell Downloader

The second stage of the attack chain begins with nested cmd.exe calls, the first of which invokes msg.exe. This displays a message window to the victim containing a decoy Word error, “Word experienced an error trying to open the file.”

Next, PowerShell is invoked with base64 encoded data as a parameter, and cmd.exe takes the string P^Ow^er^she^L^L as an argument. This argument is crafted using the caret escape character (^) to avoid static detection. The -w option sets the PowerShell.exe process to start in the background. The -ENCOD option tells PowerShell to decode the base64 argument on the fly.

Figure 10. Execution of msg.exe and powershell.exe.
Figure 10. Execution of msg.exe and powershell.exe.

PowerShell - Base64 Analysis

Figure 11. Decoded base64 PowerShell data.
Figure 11. Decoded base64 PowerShell data.

The purpose of this obfuscated code is as follows:

1. Set the security protocol used by the ServicePoint Manager to TLS 1.2.

2. Set the absolute path of a randomly generated file.

3. Generate an array of a total of seven Uniform Resource Identifiers (URIs).

Figure 12. Deobfuscated URIs list.
Figure 12. Deobfuscated URIs list.

4. Instantiate a new object of the WebClient .NET Class, which leverages the DownloadFile() method to retrieve files from each item (URI) contained in the array generated in the previous step. The downloaded file will be saved into a fixed absolute path and filename %USERPROFILE%\Ygyhlqt\Bx5jfmo\R43H.dll.

It’s worth mentioning that the folder names used at this step are matched with the ones generated during macro execution in the first stage of the attack chain.

5. Perform a length check to equal 37652 bytes. This specific check is presumably made to ensure the binary content was transferred successfully.

6. Execute the downloaded DLL file by executing the rundll32.exe command and providing the Control_RunDLL as an entrypoint function. The following picture shows the deobfuscated version of the entire command.

Figure 13. Execution of rundll32.exe in PowerShell.
Figure 13. Execution of rundll32.exe in PowerShell.

As described above, the PowerShell script performs several HTTP requests to different URIs. The response from the server shows that a DLL file has been downloaded. The name of the file is set to NK05DJ2yiA.dll.

Figure 14. HTTP download request - First DLL (NK05DJ2yiA.dll).
Figure 14. HTTP download request - First DLL (NK05DJ2yiA.dll).

Third-Stage Malware – DLL Analysis

(Sha256: bbb9c1b98ec307a5e84095cf491f7475964a698c90b48a9d43490a05b6ba0a79)

KEY： "k1>@dY0V<o)afFNz7v68r^Kn6)h)OGcSc"

Figure 15 shows the process tree having a parent process powershell.exe and the consecutive runs of rundll32.exe.

Figure 15. PowerShell.exe and rundll32.exe processes execution.
Figure 15. PowerShell.exe and rundll32.exe processes execution.

The first process is given the absolute path to R43H.dll as an argument, and the second process is given a path to a file with a random path and filename. However, both processes begin with the same entrypoint function called Control_RunDLL. The following describes the inner workings of this DLL and its participation in the infection chain.

Once the downloader code receives the second-stage DLL file, it will be saved in the path %USERPROFILE%\Ygyhlqt\Bx5jfmo\ and will be renamed to R43H.dll. According to the detection generated by the ExeInfoPE tool, it shows that this is a Microsoft Visual C++ ver. ~6.0~7.10 executable file.

Figure 16. ExeInfoPE file identification on downloaded DLL file.
Figure 16. ExeInfoPE file identification on downloaded DLL file.

During the third-stage malware execution, a new absolute path will be randomly generated. A call to the MoveFileExW() function will move the file from its original location to this new one. The absolute path format is as follows:

  • %SYSTEMROOT%\system32\<random_folder_name>\<random_filename>.<random_ext>

Next, as shown in Figure 17, a call to the CreateProcessW() function sets the value of the lpCommandLine parameter, which includes the absolute path of the recently moved DLL file, and the aforementioned entrypoint function Control-RunDLL.

Figure 17. Execution of the second DLL file.
Figure 17. Execution of the second DLL file.

The actions performed by the second rundll32.exe execution will be described in the Fourth-Stage Malware section.

Locate and Load Resource Encrypted Data

The Emotet malware performs several actions, and one of those is the use of Resource Win32 API functions with the objective of loading binary data from the executable resource section, decrypting it and dropping a newly crafted malware.

First, at offset 0x10002119, a call to the VirtualAlloc() function is made. This will allocate 0x1B000 (110592d) bytes, a MEM_COMMIT allocation type and memory protection option as PAGE_EXECUTE_READWRITE.

Figure 18. VirtualAlloc() and byte-copying (call 100045c0) function.
Figure 18. VirtualAlloc() and byte-copying (call 100045c0) function.

At offset 0x10002128, the function call 100045C0 copies the bytes from the resource section into the newly generated memory allocation from the previous step (see Figure 18). The following picture (Figure 19) shows a comparison between the byte contents of the resources taken directly from the Resource Hacker tool and the contents in memory taken directly from the running process.

Figure 19. Encrypted binary resources data displayed in the Resource Hacker tool.
Figure 19. Encrypted binary resources data displayed in the Resource Hacker tool.

During the execution of subsequent instructions, a call to the 0x10001D9A function is made. This function has a loop located at offset 0x10001E4D and performs several operations. One of these operations is a 1-byte XOR instruction (xor byte ptr [esi+ecx], al) located at offset 0x10001E4D. Its purpose is to decrypt a total of 110591 bytes of the executable’s resource data where the PE binary data is stored. The final result is an in-memory reconstructed executable file. In Figure 19, the encrypted and decrypted data in the process’s memory can be seen.

Figure 19. Encrypted data in PE and decryption of data in memory.
Figure 19. Encrypted data in PE and decryption of data in memory.

At offset 0x10002167, an indirect function pointer call is made to the address pointed to by the EAX register, which is the entrypoint of the Control_RunDLL function of the in-memory (dropped) executable file. Figure 20 shows this in a graphical manner for reference.

Figure 20. Indirect call – transferring control to in-memory data.
Figure 20. Indirect call – transferring control to in-memory data.

Once the call EAX instruction is executed, the execution control is transferred to the new executable file.

Persistency Mechanism

The Emotet malware installs a new service by calling the CreateServiceW() function, which starts the copy of the malware in an automated manner by the operating system. Figure 21 shows this new service already installed.

Figure 21. Installation of a new Windows service.
Figure 21. Installation of a new Windows service.

The service name is generated randomly and the below list contains different names used throughout several test runs.

  • Provides Disk Defragmentation capabilities.
  • Windows Media Center Service for TV and FM broadcast reception.
  • Processes application compatibility cache requests for applications as they are launched.
  • Starts and stops recording of TV programs within Windows Media Center.
  • Transfers files in the background using idle network bandwidth. If the service is disabled, then any applications that depend on BITS, such as Windows Update or MSN Explorer, will be unable to automatically download programs and other information.

Fourth-Stage Malware – DLL Analysis

(Sha256:bd1e56637bd0fe213c2c58d6bd4e6e3693416ec2f90ea29f0c68a0b91815d91a)

At this stage, the final payload is preparing the environment to submit information to the C2 server. To do so, it executes function calls to retrieve the required data to finally perform the HTTP request.

The following steps assume a base address of 0x2E1000 and describe the details and sequences followed by the Emotet malware until the delivery of the payload.

Figure 22. Function calls that collect and prepare data for exfiltration.
Figure 22. Function calls that collect and prepare data for exfiltration.

Fifth-Stage Malware – C2 Traffic

As can be seen in the function call list, the HttpSendRequestW() API function is used to send the data to the server. This function allows the sender to exceed the amount of data that is being sent normally by HTTP clients.

Figure 23. HTTP data in memory before being sent to the C2 server.
Figure 23. HTTP data in memory before being sent to the C2 server.

Figure 24 shows the data after being sent and captured by Wireshark.

Figure 24. Data being sent to the C2 server captured by Wireshark.
Figure 24. Data being sent to the C2 server captured by Wireshark.

Evasion Technology

  1. Uses multiple download links to download the first-stage loader. As long as one download link is not blocked or captured by a security product, the loader download will be successful.
  2. Uses multiple C2 server IP addresses to communicate with C2 servers. As long as one IP address is not blocked, the communication will be successful.
  3. The C2 communication uses standard HTTP with sensitive information encrypted with custom algorithms. From the perspective of security mitigations, it is difficult to differentiate this strain of C2 from benign traffic.

Conclusion

Emotet was a potent adversary before coordinated law enforcement action shut down its infrastructure in late January 2021. The attack chain detailed above is elaborate and is designed to evade security detections. A single security appliance is not equipped to prevent an Emotet attack. Only a combination of security solutions – firewalls, sandboxes, endpoints and software to integrate all these components can help prevent an Emotet attack.

At the time of this writing, the samples listed in the IOCs section below were not publicly available. However, we have created detections and coverage against their behavior and communication.

Palo Alto Networks customers are protected from this kind of attack by the following:

  1. Next-Generation Firewalls with Threat Prevention signatures 21201, 21185 and 21167 identify HTTP C2 requests attempting to download the new payload and post sensitive information.
  2. WildFire, an NGFW security subscription, and Cortex XDR identify and block Emotet and its droppers.

Indicators of Compromise

Samples

209a975429304f771ef8a619553ffd9b8fc525a254157cbba47f8e64ec30df79

2a8dcfc8f1262e1c6b5f65c52cdccdbcd40ff6218f4f25f82bd3eb025593dbc0

2cb81a1a59df4a4fd222fbcb946db3d653185c2e79cf4d3365b430b1988d485f

36df660c8e323435d2bc7a5516adcadfbd0b220279f634725e407da9f2b9d4f5

3788c8a783fbbd61fa60d41b78568c095a8587db728a61bff67c3ffebfad82a4

704759a244e3f27481f6ad225a0e1c30ae46e411e01612d68ca76fe2fd8cee54

7a18e87591637a8e962386b9c72aed584037a953ce7fe5ae51edba7a0ca57c1a

96a1fea9853e6f77d4449da325dfdb1545b905bdb7ba227d24e6a1a5f8cb3bd4

a9668efdb68bf251dae8623cb4f3dc8b9b7f42d77927d287633af94a72e9d1dc

fc3c1ce6491bca2b028ae8806ca84d4b9dcb577fb2551aa871ca23eca19b10f5

Droppers

0a0bf0cab20ec7fb530738c4e08f8cd5062ea44c5da3d8a3e6ce0768286d4c51

2a0a1e12a8a948083abe2a0dcbf9128b8ec7f711251f399e730af6645e86d5c8

3b3a9517b61d2af8758e60d067c08edd397ad76b25efe1cbd393229088567002

3bbda08f5e15c5cb4472c6e610f2063eb68f54c0234a2197bc4633f4344ab27f

3e2fd3a5d790a0d4efe1100af08e3e2011f26416154ec11f1315db2ca6ca71bd

4eb1928c08d16a9407dbf89ad1279886379a0415bdd7760a3b2d0697f7d287c6

95bc30b35aa2d2baa80b50e970707197a26bd19d7772cbf65ff3d0300fe8e789

97c395e1bd0c35e9b8e6f9d97b470abdfdacec25e0e4e3b987e3813fb902de9f

bbb9c1b98ec307a5e84095cf491f7475964a698c90b48a9d43490a05b6ba0a79

bd1e56637bd0fe213c2c58d6bd4e6e3693416ec2f90ea29f0c68a0b91815d91a

URLs

http://abrillofurniture[.]com/bph-nclex-wygq4/a7nBfhs/

http://allcannabismeds[.]com/unraid-map/ZZm6/

http://ezi-pos[.]com/categoryl/x/

http://giannaspsychicstudio[.]com/cgi-bin/PP/

http://ienglishabc[.]com/cow/JH/

https://etkindedektiflik[.]com/pcie-speed/U/

https://vstsample[.]com/wp-includes/7eXeI/

IPs

5.2.136[.]90

37.46.129[.]215

70.32.89[.]105

110.172.180[.]180

132.248.38[.]158

138.197.99[.]250

152.170.79[.]100

157.245.145[.]87

161.49.84[.]2

190.55.186[.]229

190.247.139[.]101

203.157.152[.]9

Get the latest news, invites to events, and threat alerts

Default Heading

Read the article Right Arrow