BlackCat Climbs the Summit With a New Tactic

Posted on by Unit 42

Executive Summary

BlackCat operators recently announced new updates to their tooling, including a utility called Munchkin that allows attackers to propagate the BlackCat payload to remote machines and shares on a victim organization network. For the past two years, the BlackCat ransomware operators have continued to evolve and iterate their tooling as part of their ransomware-as-a-service (RaaS) business model.

As part of a recent investigation, Unit 42 researchers have acquired an instance of Munchkin that is unique, in that it is loaded in a customized Alpine virtual machine (VM). This new tactic of leveraging a customized VM to deploy malware has been gaining traction in recent months, allowing ransomware threat actors to use VMs to circumvent security solutions in deploying their malware payloads.

This publication details how this new utility works and sheds further light on the continued tactics used by BlackCat threat actors. In doing so, it is our sincere hope to motivate further effort by the information security industry to better defend against this evolving threat.

Palo Alto Networks customers receive protections against this specific threat through appropriate identification of the provided indicators as malicious.

Related Unit 42 Topics BlackCat Ransomware

Overview of BlackCat

The BlackCat ransomware threat was first made public when it surfaced in November 2021. This threat gained notoriety due to the sophistication employed within their malware, along with unique approaches such as the use of the Rust programming language.

BlackCat, similar to other ransomware threat actors, employs a RaaS business model. This model allows affiliates to leverage their tooling, in turn providing a portion of the profits to the operators. Based on historical reports, affiliates keep roughly 80-90% of the ransom payment, with the remainder being sent to the operators.

The BlackCat organization, including its affiliates, has historically focused on targeting victims in the United States. However, this focus has greatly broadened over time with increased popularity, and BlackCat has more recently been observed targeting victims worldwide across numerous industries and verticals.

The BlackCat tool set has continued to evolve over the years. Original versions provided an embedded JSON configuration with no obfuscation or encryption applied.

Over time, threat operators updated the malware family to obfuscate this underlying configuration. They also required a unique command-line parameter to execute the malware. In doing so, BlackCat prevented those within the security community from gaining insight into the underlying payloads in the event this command-line parameter was unavailable.

The malware family has continued to evolve, with threat operators employing further capabilities and obfuscation mechanisms. In recent months, BlackCat has released a new tool named “Munchkin.”

This tooling provided a Linux-based operating system (OS) running Sphynx (the latest BlackCat variant). Threat operators can use this utility to run BlackCat on remote machines, or to deploy it to encrypt remote Server Message Block (SMB)/Common Internet File Shares (CIFS).

Image 1 is a diagram of how the Munchkin utility works. Virtualbox is installed on the victim host, and loads the custom ISO/virtual machine. From that point, the remote SMB shares are encrypted, and copies of BlackCat ransomware are also pushed to remote machines.
Figure 1. Diagram of Munchkin tool process.

 

The use of virtual machines to run malware is a growing trend within the ransomware community. Other ransomware organizations have been reported to leverage this new tactic as well.

The benefits of this approach include circumventing any security controls or protections set on the host OS, such as antivirus software. As these solutions often do not have the introspection within the embedded virtualized OS, malware will frequently bypass any checks that are present.

As part of a recent investigation, Unit 42 researchers were able to acquire a copy of this VM utility. As such, we can provide insights into how it works.

Climbing the Summit

The Munchkin utility is delivered as an ISO file, which is loaded in a newly installed instance of the VirtualBox virtualization product. This ISO file represents a customized implementation of the Alpine OS, which threat operators likely chose due to its small footprint. Upon running the operating system, the following commands are executed at boot:

In doing so, the malware initially changes the root password of the VM to one chosen by the threat actors. It subsequently generates a new terminal session via the built-in tmux utility, which is used to execute the malware binary named controller. After the malware completes execution, it powers the VM off.

The controller malware is hosted within the /app directory, along with other related files. In addition, other related and notable files are included within the VM OS, as noted in Table 1 below.

File Path Description
/app/controller Munchkin malware utility.
/app/config Serialized configuration file used by Munchkin.
/app/payload Template BlackCat malware sample, which is customized by Munchkin at runtime.
/scripts/smb_common.py Python helper utility for SMB-related operations.
/scripts/smb_copy_and_exec.py Python script used to copy a file via SMB and subsequently run it.
/scripts/smb_exec.py Python script used to execute a remote file.

Table 1. File path and description of the files included within the VM OS.

In addition to the files noted above, a large number of Python scripts are present within the /usr/bin directly, which the BlackCat operators can use in subsequent updates within the VM.

  • DumpNTLMInfo.py
  • Get-GPPPassword.py
  • GetADUsers.py
  • GetNPUsers.py
  • GetUserSPNs.py
  • addcomputer.py
  • atexec.py
  • changepasswd.py
  • dcomexec.py
  • dpapi.py
  • esentutl.py
  • exchanger.py
  • findDelegation.py
  • flask
  • futurize
  • getArch.py
  • getPac.py
  • getST.py
  • getTGT.py
  • goldenPac.py
  • karmaSMB.py
  • keylistattack.py
  • kintercept.py
  • ldapdomaindump
  • ldd2bloodhound
  • ldd2pretty
  • lookupsid.py
  • machine_role.py
  • mimikatz.py
  • mqtt_check.py
  • mssqlclient.py
  • mssqlinstance.py
  • net.py
  • netview.py
  • nmapAnswerMachine.py
  • normalizer
  • ntfs-read.py
  • ntlmrelayx.py
  • pasteurize
  • ping.py
  • ping6.py
  • pip
  • pip3
  • pip3.11
  • psexec.py
  • raiseChild.py
  • rbcd.py
  • rdp_check.py
  • reg.py
  • registry-read.py
  • rpcdump.py
  • rpcmap.py
  • sambaPipe.py
  • samrdump.py
  • secretsdump.py
  • services.py
  • smbclient.py
  • smbexec.py
  • smbpasswd.py
  • smbrelayx.py
  • smbserver.py
  • sniff.py
  • sniffer.py
  • split.py
  • ticketConverter.py
  • ticketer.py
  • tstool.py
  • wmiexec.py
  • wmipersist.py
  • wmiquery.py

Attackers can use many of the Python scripts above for lateral movement, password dumping and further execution of malware on the victim network.

The controller malware is written in the Rust programming language in a manner very similar to the BlackCat malware family. Upon execution, the controller will initially decrypt numerous strings using a unique single-byte XOR operation.

Image 2 is a comparison of two screenshots of code. The screenshot on the left is the original. The screenshot on the right is the runtime code that is decrypted.
Figure 2. String decryption at runtime.

After the strings are decrypted, the threat will perform basic checks to ensure that the expected configuration and payload files reside within the /app directory. The threat will then deserialize and parse the /app/config file. In the event any of these files are not present or if they are unable to be parsed, the malware will exit with an error message.

The /app/config file contains a wealth of information including the following, which the controller malware sample subsequently uses:

  • Access Token
  • Task identifiers
  • Victim credentials (including usernames, passwords and domains)
  • BlackCat victim URLs
  • Blocklisted file types and paths
  • Hosts and shares to target for encryption

After the configuration is parsed, the controller creates and mounts the /payloads/ directory, which it uses to host subsequently created instances of BlackCat. The controller uses the previously noted /app/payload as a template for creating customized BlackCat samples. Within the template file, there are specific markers that the controller looks for and uses when it modifies this file.

Image 3 is a comparison of two BlackCat samples. On the left is the BlackCat template file. many of the lines are highlighted in blue. On the right is the sample after modification. Many of the lines are highlighted in red.
Figure 3. Creation of a new BlackCat sample based on template and configuration.

The created files are based on the provided configuration. However, they are named as follows, with incremental values:

  • /payloads/0
  • /payloads/1

After these payloads have been created, the malware proceeds to iterate through the provided configuration with the intent of infecting any SMB/CIFS drives that are specified. These attempts are outlined in various outputs written to STDOUT, an example of which is shown below.

(Note: The actual IP addresses and share names have been redacted in the output below.)

After the malware executes fully, the VM powers off and performs no further actions.

We found the following message embedded within the malware sample itself. It is not used; it was presumably included at a certain stage of development but was later removed from use.

This message appears to be a message from the BlackCat creators to their affiliates urging them to remove this file from a compromised environment. It would seem that the affiliate in question failed to heed this advice.

Conclusion

Malware authors, especially those behind the BlackCat ransomware threat, continue to iterate and evolve their techniques and tactics. This is fully apparent in their recent release of Munchkin, which they’ve developed and provided to their affiliates.

This tool follows a continued trend of leveraging VMs in an attempt to thwart security controls present on a host and to stay ahead of the security community in defending against these threats.

Palo Alto Networks customers receive protection from the threats discussed above through the following products:

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

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

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

Indicators of Compromise

/app/controller - Munchkin Binary

  • 1a4082c161eafde7e367e0ea2c98543c06dce667b547881455d1984037a90e7d

/app/payload - BlackCat Stub

  • b4dd6e689b80cfcdd74b0995250d63d76ab789f1315af7fe326122540cddfad2

/scripts/smb_common.py - Python SMB Classes

  • 41c0b2258c632ee122fb52bf2f644c7fb595a5beaec71527e2ebce7183644db2

/scripts/smb_copy_and_exec.py - Python SMB Copy/Exec Script

  • 2e808fc1b2bd960909385575fa9227928ca25c8665d3ce5ad986b03679dace90

/app/payload - BlackCat Stub

  • b4dd6e689b80cfcdd74b0995250d63d76ab789f1315af7fe326122540cddfad2

YARA Rules

Additional Resources

 

Blocking Dedicated Attacking Hosts Is Not Enough: In-Depth Analysis of a Worldwide Linux XorDDoS Campaign

Posted on by Zhanhao Chen

Executive Summary

We recently detected a new campaign from the XorDDoS Trojan that led us to conduct an in-depth investigation that unveiled concealed network infrastructure that carries a large amount of command and control (C2) traffic. When we compared the most recent wave of XorDDoS attacks with a campaign from 2022, we found the only difference between the campaigns was in the configuration of the C2 hosts. While the attacking domains remain unchanged, the attackers have migrated their offensive infrastructure to hosts running on legitimate public hosting services.

Even though numerous security vendors have already classified the C2 domains as malicious and barred them, we still detect active malware traffic directed to these new underlying IPs. This underscores the necessity of extending protection beyond the mere blocking of dedicated attacking hosts.

We provide a comprehensive analysis of the XorDDoS Trojan's attacking behaviors. Subsequently, we unveil the intricate network infrastructure orchestrating the campaign's botnet. Lastly, we introduce the advanced signatures derived from the key attacking hotspots, including hostnames, URLs and IP addresses. These signatures effectively identified over 1,000 XorDDoS C2 traffic sessions in August 2023 alone.

Palo Alto Networks customers receive protection from the XorDDoS campaign through our Next-Generation Firewall with Cloud-Delivered Security Services, including Advanced WildFire, DNS Security and Advanced URL Filtering.

Related Unit 42 Topics Linux, Trojan

Linux XorDDoS Trojan

The XorDDoS Trojan infects Linux devices and transforms them into zombies, which the perpetrators can control to execute malicious tasks remotely. Attackers then manipulate the compromised devices to carry out distributed denial of service (DDoS) attacks.

The campaign discussed here started in earnest on July 28, 2023, and became yet more active from July 31 to Aug. 5. Following several days of dormancy, the campaign surged and delivered 30 unique malware variants on Aug. 12.

Figure 1 presents the distribution of the campaign’s malware delivery attempts.

Image 1 is a trend graph of the 2023 XorDDoS trojan, starting on July 28, 2023 and ending on August 15, 2023. The highest count is August 12, 2023 at 30.
Figure 1. Trend of the XorDDoS Trojan.

Victim Scanning and Initial Access

Before malware successfully infiltrated a device, the attackers initiated a scanning process, employing HTTP requests to identify potential vulnerabilities in their targets. Specifically, they probed whether a prospective victim's machine hosted an HTTP service susceptible to directory traversal, a vulnerability that enables the attackers to access arbitrary files in the server.

Several victim machines received scanning traffic intended to access the /etc/passwd file under their respective IP addresses. These actions occurred before the eventual compromise of the victim machines, followed by the initiation of C2 requests.

Figure 2 shows the scanning requests directed at a victim device in blue, and the subsequent C2 traffic it generated in red. During the initial three days, this particular device encountered a flood of over 1,000 probing vulnerability scans every day. Following this surge, the scanning volume experienced a sharp decline, eventually vanishing. After that, the victim device generated a steady stream of C2 traffic, as shown.

Image 2 is a trend graph of scanning traffic compared to command and control traffic for a victim device. The timeline starts on July 6, 2023 and ends on July 23, 2023.
Figure 2. Scanning and C2 traffic for a victim device.

The threat actor identified vulnerable devices and obtained the usernames from the leaked file, but because the passwords in /etc/passwd are encrypted, they gained initial access through SSH brute-force attack. This type of attack involves systematically trying all possible combinations of passwords until the correct one is found. They then downloaded malware from remote servers and deployed it on the victim machines.

Malware Behavior Analysis

As implied by its name, the XorDDoS Trojan uses an XOR encryption key (BB2FA36AAA9541F0) to encrypt all the data related to its execution. Figure 3 shows that the threat invokes a decryption function to retrieve the hard-coded strings.

Image 3 is a screenshot of many lines of code. It is the decryption function to retrieve hard-coded strings. The lines of code on the left are blue, and the lines on the right are green.
Figure 3. XorDDoS string decryption.

Once activated on a victim machine, the Trojan first collects essential information, including a magic string. This string is a 32 bytes long identifier that represents the compromised device while connecting with the C2 server. The stolen information includes data from /var/run/gcc.pid, the OS version, malware version, memory status and CPU information.

The threat then calculates the cyclic redundancy check (CRC) code of the metadata and encrypts that data using an XOR key, as shown in Figure 4. The C2 server uses the CRC code to detect errors during network communication.

Image 4 is a screenshot of many lines of code. This is the host information data structure in CRC code.
Figure 4. Host information data structure.

Figure 5 shows the C2 traffic exfiltrating the stolen data.

Image 5 is a screenshot of command and control traffic. Traffic is color-coded as follows. Purple is the CRC header. Red is the uname string release. Green is the name string machine. Blue is a magic string, and orange is a hard-coded string.
Figure 5. C2 traffic with encrypted metadata.

The C2 domains are embedded in the malware executable. Figure 6 illustrates how XorDDoS decrypts those domains by calling the decrypt_remotestr() function and appends them to a list. In the sample we analyzed, this list contains the following C2 endpoints:

  • ppp.gggatat456[.]com:53
  • ppp.xxxatat456[.]com:53
  • p5.dddgata789[.]com:53
  • P5.lpjulidny7[.]com:53
Image 6 is a screenshot of many lines of code. There is an inset window that explains the code in further detail. Highlighted in red is the line encrypt_code(&remotestr, 512).
Figure 6. Domain decryption.

Figure 7 illustrates the threat leveraging DNS servers 8.8.8[.]8 and 8.8.4[.]4 to resolve the IP address of the C2 domain names. Then, the threat establishes contact with these IP addresses and awaits commands from the attackers.

Image 7 is a screenshot of Wireshark. A red box highlights the destination column. Two red arrows point to the IP addresses in the destination column to the IP addresses in the domain decryption code.
Figure 7. C2 domain resolve.

Once a connection is established with the C2 server, the threat actor gains the capability to send commands to the client. Table 1 lists the C2 commands.

Command Case Description
2 Stop
3 Launch DDoS attack
6 Download file from remote server
7 Upload local file to remote server
8 Send system information to the C2 server
9 Get configuration file

Table 1. XorDDoS commands.

Persistence and Self-Replication

The XorDDoS malware uses multiple persistence mechanisms. It creates scheduled autorun tasks that trigger malware execution every three minutes and configures an autorun service to launch the threat during system startup.

To evade detection, the threat turns its process into a background service that runs independently of the current user session. It does this to avoid process termination signals from users and to disguise itself as a legitimate process.

During the dynamic analysis by our sandbox, we found that the XorDDoS malware dropped ELF executables with a little variance to its original file for its persistence on the victim's system. Such self-replication behavior generated a huge number of malware executables during the active periods of XorDDoS campaigns. Despite their high degree of similarity, the replicas could confuse some file hash-based detection systems.

Between December 2022 and August 2023, we identified over 26,000 such replicated malware samples within the victims’ systems, which the threat generated from approximately 800 initial samples. Throughout the various campaigns in this timeframe, we have observed these malware samples infiltrating networks across various organizations on a global scale, including in the following industries:

  • Semiconductor
  • Telecom
  • Transportation
  • Finance
  • Insurance
  • Retail

XorDDoS C2 Network Infrastructure

After successfully infecting victims' devices, the attackers monitored and coordinated the botnet via C2 commands. Our investigation started with the associated C2 domains. When we cross-checked the WHOIS information of these domains and their related malicious traffic, we found that the attackers had registered and used them to carry malicious traffic for several years.

In addition to the most recent attack, the owners of these domains orchestrated another substantial campaign in 2022. We plot the distribution of malware delivery from the previous campaign in Figure 8.

The attackers propagated the majority of their malware in this campaign during February, March and August 2022. A comparative analysis between last year's campaign and the current one reveals a remarkable similarity in the threat employed, accompanied by minor variations in network infrastructure.

Image 8 is a column graph of the timeline for the 2022 XorDDoS campaign. It starts in January 2022 and ends in August 2022. The highest number of trojans was in February 2022.
Figure 8. Trend of the 2022 XorDDoS campaign.

When we analyzed the passive DNS traffic requesting the C2 domains, we found the attackers changed IP addresses for these domains in preparation for this year's campaign. Figure 9 illustrates the trend of the DNS resolutions for the domains to the newly assigned IPs.

Image 9 is a trend graph of DNS requests for the command and control domains. It begins on July 30, 2023 and ends on August 20, 2023. The largest spike in requests is in August.
Figure 9. Trend of C2 domains’ DNS traffic.

The new resolutions began on July 28. Before Aug. 8, the daily traffic volume remained relatively low. Between Aug. 8 and Aug. 18, there was a noticeable surge in malware activity marked by approximately 24,000 malicious DNS requests daily.

From Aug. 19-22, the campaign entered an intense attacking phase, generating over 22 times more traffic every day. A particularly notable spike occurred on Aug. 20, when we recorded 961,438 DNS requests for the C2 domains.

Table 2 lists the new DNS resolutions involved in the recent attacking traffic. Among the four unique C2 root domains, the threat establishes communication with 16 distinct subdomains. One of the domains (dddgata789[.]com) is unresolvable, while the remaining hostnames correspond to a total of 13 IP addresses sourced from two legitimate public hosting providers.

C2 Domains Name Server C2 Subdomains IP Addresses Autonomous System
xxxatat456[.]com name-services[.]com aaa.xxxatat456[.]com

b12.xxxatat456[.]com

ppp.xxxatat456[.]com

www.ppp.xxxatat456[.]com

www.xxxatat456[.]com

 142.0.138[.]41

142.0.138[.]42

142.0.138[.]43

142.0.138[.]44

142.4.106[.]73

142.4.106[.]75

192.74.236[.]33

192.74.236[.]34

192.74.236[.]35

 54600
gggatat456[.]com name-services[.]com aaa.gggatat456[.]com

ppp.gggatat456[.]com

www1.gggatat456[.]com

www.ppp.gggatat456[.]com

 142.0.138[.]41

142.0.138[.]42

142.0.138[.]43

142.4.106[.]73

142.4.106[.]74

142.4.106[.]75

142.4.106[.]76

192.74.236[.]33

192.74.236[.]34

192.74.236[.]35

192.74.236[.]36

 54600 
lpjulidny7[.]com domaincontrol[.]com p0.lpjulidny7[.]com

p2.lpjulidny7[.]com

p3.lpjulidny7[.]com

p4.lpjulidny7[.]com

p5.lpjulidny7[.]com

 34.98.99[.]30 396982
dddgata789[.]com domaincontrol[.]com ddd.dddgata789[.]com

p5.dddgata789[.]com

 N/A N/A

Table 2. Network infrastructure of the latest XorDDoS campaign.

Although many security vendors have designated the C2 hostnames as dedicated attacking endpoints and subsequently blocked them, a challenge arises regarding the associated IP addresses. Given that these IP addresses also facilitate legitimate domains, a simplistic blocking approach becomes impracticable. Consequently, the attacker can retain these IP addresses for future operations even if the C2 domains are blocked. This underscores the importance of extending the scope of protection beyond the dedicated malicious hosts.

Figure 10 visualizes the network infrastructures of XorDDoS attacks. The left part of the image displays the structure of the recent campaign. All malware instances establish connections with C2 IP addresses in the United States.

The right side depicts the 2022 campaign, during which attackers distributed C2 servers across various European countries, including France, Germany and Italy. Despite the change in IP addresses, they remain tethered to the same set of C2 hostnames illustrated in the middle of Figure 10.

Image 10 is a graph of the network infrastructure of the XorDDoS campaign. The red file icon is for malware. The red globe icon is for the dedicated command and control host name. The black file icon is the IP for the public hosting service. The malware is distributed to contact points, then from the command and control IP in the United States resolves to the command and control hostnames. From there the malware resolves to the 2022 command and control IP in the European Union.
Figure 10. Network infrastructure of XorDDoS campaign.

This insight leads us to a crucial discovery. These C2 IP addresses can be used as signatures for identifying XorDDoS Trojans. Specifically, any samples communicating with more than three of these C2 IP addresses can be deemed malicious.

Advanced Malware Traffic Detection

Given that the C2 IP addresses used in the XorDDoS campaign are shared web hosting infrastructure, definitively classifying isolated connections as malicious or benign becomes challenging. Therefore, we propose that multiple connections to these IP addresses within a brief time frame can serve as a better indicator of C2 traffic.

This behavior strongly suggests C2 activity rather than legitimate network traffic. To enhance our detection capabilities, we leverage these attacking network endpoints to generate advanced signatures for detecting malware activities. These signatures incorporate multiple network entities, enabling us to effectively identify and mitigate malware communication sessions that might otherwise evade detection based solely on single-entity analysis.

Conclusion

The XorDDoS Trojan spread around the world during July and August 2023. This threat infects Linux devices and transforms them into zombies for launching DDoS attacks. The attackers coordinate the botnet with C2 domains that they have abused before. However, they have recently relocated their C2 servers to new IP addresses from public hosting services.

We conducted a comprehensive investigation to unveil the underlying attacking network infrastructure. Leveraging this insight, we craft advanced signatures to detect malware activities involving nondedicated attacking hosts.

Palo Alto Networks customers receive protection against the ongoing attacks through the following cloud-delivered security services:

Protection With Cloud-Delivered Security Services

As we labeled all C2 hostnames as malicious prior to the inception of the recent campaign, DNS Security and Advanced URL Filtering thwarted all DNS and web requests directed toward them. Since July 2023, we have consistently observed a sustained level of malicious traffic attempting to visit these hostnames.

Figure 11 depicts this trend, illustrating that DNS Security prevented an average of 3,903 daily DNS requests, while Advanced URL Filtering effectively blocked 246 daily web requests targeted at the C2 hostnames.

Image 11 is a trend graph of the command and control traffic as it was blocked by Advanced URL Filtering and DNS Security. The blue is the blocked command and control DNS traffic. The red is the number of blocked command and control web traffic.
Figure 11. Trend of C2 traffic blocked by Advanced URL Filtering and DNS security.

Figure 12 provides the geographical distribution of the attacking traffic. Between July and August 2023, the attackers successfully infiltrated victims' systems operating in 21 different countries. This widespread reach underscores the global impact of the campaign. A substantial proportion of the attacking traffic is concentrated in Africa, South Asia and Southeast Asia, where we recorded over 77% of total attacks.

Image 12 is a heat map of the geological distributions of attacking traffic volume.
Figure 12. Geological Distribution of Attacking Traffic Volume.

Acknowledgments

Special thanks to Shireen Hsu and Wanjin Li for their help with improving this article. Additional IoCs provided by William Gamazo.

Indicators of Compromise

Command and Control Infrastructure

IPs

  • 23.252.167[.]35
  • 34.98.99[.]30
  • 66.102.253[.]30
  • 98.126.8[.]114
  • 103.25.9[.]245
  • 103.233.83[.]245
  • 103.240.141[.]50
  • 104.247.217[.]167
  • 113.10.246[.]145
  • 119.147.145[.]198
  • 142.0.138[.]41
  • 142.0.138[.]42
  • 142.0.138[.]43
  • 142.0.138[.]44
  • 142.4.106[.]73
  • 142.4.106[.]74
  • 142.4.106[.]75
  • 142.4.106[.]76
  • 162.251.95[.]209
  • 174.139.217[.]145
  • 183.56.173[.]144
  • 183.56.173[.]156
  • 183.60.202[.]2
  • 183.136.213[.]96
  • 192.74.236[.]33
  • 192.74.236[.]34
  • 192.74.236[.]35
  • 192.74.236[.]36
  • 203.12.202[.]137

Domains

  • 0o557[.]com
  • 604418589[.]xyz
  • www.98syn[.]com
  • aldz[.]xyz
  • syn.aldz[.]xyz
  • p.assword[.]xyz
  • linux.bc5j[.]com
  • cdn.netflix2cdn[.]com
  • dddgata789[.]com
  • b12.dddgata789[.]com
  • d14.dddgata789[.]com
  • ddd.dddgata789[.]com
  • p5.dddgata789[.]com
  • ww.dnstells[.]com
  • ndns.dsaj2a[.]com
  • ndns.dsaj2a[.]org
  • gh.dsaj2a1[.]org
  • ndns.dsaj2a1[.]org
  • www.enoan2107[.]com
  • a381422.f3322[.]net
  • 1107791273.f3322[.]org
  • aa369369.f3322[.]org
  • shaoqian.f3322[.]org
  • xlxl.f3322[.]org
  • cdn.finance1num[.]com
  • baidu.gddos[.]com
  • soft8.gddos[.]com
  • gggatat456[.]com
  • aaa.gggatat456[.]com
  • b12.gggatat456[.]com
  • g14.gggatat456[.]com
  • ppp.gggatat456[.]com
  • www.ppp.gggatat456[.]com
  • www1.gggatat456[.]com
  • 8uc.gwd58[.]com
  • ww.gzcfr5axf6[.]com
  • www.gzcfr5axf6[.]com
  • ww.gzcfr5axf7[.]com
  • ndns.hcxiaoao[.]com
  • ns1.hostasa[.]org
  • ns2.hostasa[.]org
  • ns3.hostasa[.]org
  • ns4.hostasa[.]org
  • linux.jum2[.]com
  • lpjulidny7[.]com
  • p0.lpjulidny7[.]com
  • p2.lpjulidny7[.]com
  • p3.lpjulidny7[.]com
  • p4.lpjulidny7[.]com
  • p5.lpjulidny7[.]com
  • 2w5.mc150[.]cn
  • ww.myserv012[.]com
  • nishabud[.]com
  • aaaaaaaaaa.re67das[.]com
  • ww.s9xk32a[.]com
  • ww.s9xk32b[.]com
  • ww.s9xk32c[.]com
  • ww.search2c[.]com
  • ssh.upx[.]wang
  • www.wangzongfacai[.]com
  • bb.wordpressau[.]com
  • bbb.wordpressau[.]com
  • xran[.]xyz
  • xxxatat456[.]com
  • aaa.xxxatat456[.]com
  • b12.xxxatat456[.]com
  • ppp.xxxatat456[.]com
  • www.ppp.xxxatat456[.]com
  • www.xxxatat456[.]com
  • x14.xxxatat456[.]com
  • zryl[.]online

XorDDoS Binaries

  • b8c4d68755d09e9ad47e0fa14737b3d2d5ad1246de5ef1b3c794b1339d8fe9f8
  • 265a38c6dee58f912ff82a4e7ce3a32b2a3216bffd8c971a7414432c5f66ef11
  • 1e823ae1e8d2689f1090b09dc15dc1953fa0d3f703aec682214750b9ef8795f1
  • 989a371948b2c50b1d45dac9b3375cbbf832623b30e41d2e04d13d2bcf76e56b
  • 20f202d4a42096588c6a498ddb1e92f5b7531cb108fca45498ac7cd9d46b6448
  • 9c5fc75a453276dcd479601d13593420fc53c80ad6bd911aaeb57d8da693da43
  • ce0268e14b9095e186d5d4fe0b3d7ced0c1cc5bd9c4823b3dfa89853ba83c94f
  • aeb29dc28699b899a89c990eab32c7697679f764f9f33de7d2e2dc28ea8300f5

 

Understanding DNS Tunneling Traffic in the Wild

Posted on by Ruian Duan

Executive Summary

We present a study on why and how domain name system (DNS) tunneling techniques are used in the wild. Motivated by our findings, we present a system to automatically attribute tunneling domains to tools and campaigns.

Attackers adopt DNS tunneling techniques to bypass security policies in enterprise networks because most enterprises implement relatively permissive policies for DNS traffic. Previous research has shown that malware campaigns such as SUNBURST and OilRig use DNS tunneling for command and control (C2).

However, many aspects of how attackers use DNS tunneling in the wild remain unknown. For example, do they use DNS tunneling techniques exclusively for C2? How do they implement and host these techniques? Can we further analyze and provide actionable insights on DNS tunneling traffic?

We answer the above questions through over four years of experience in DNS tunneling traffic investigations and in-the-wild tunneling domain detections. We find that apart from threat actors using DNS tunneling techniques for C2 communication, enterprise employees are using them for censorship circumvention and vehicle passengers are using them to bypass network service charges.

Different tunneling domains share characteristics that can reveal the tools used to embed data onto DNS queries and responses – and the associated malware campaign name.

Therefore, we have built an attribution system called DNS Security System, which can gather information about the DNS tunneling traffic and provide details about the tools and the associated campaigns in real time.

Palo Alto Networks Next-Generation Firewall customers can access the tunneling tool and campaign information with DNS Security subscriptions.

Palo Alto Networks Next-Generation Firewall customers receive protections against malicious indicators (domain, IP) mentioned in this article via Advanced URL Filtering and our DNS Security subscription services.

Palo Alto Networks Cortex XDR analytics customers receive protection against DNS tunneling techniques mentioned in this article via the DNS tunneling analytics detector.

Related Unit 42 Topics DNS Tunneling, Cobalt Strike

DNS Tunneling Basics

What is DNS tunneling? DNS tunneling is a technique to encode data of non-DNS programs and protocols within DNS queries and responses. This enables various types of communication over the DNS protocol, including file transfer, C2 and web browsing.

Why perform DNS tunneling? DNS normally uses UDP port 53, which is usually open on clients, systems, servers and firewalls to transmit DNS queries. DNS is a fundamental component of the internet. It serves many applications, from well-known services like web browsing and email, to lesser-known services like auto-discover, load balancing, censorship and security monitoring.

Due to its criticality, most enterprises implement relatively permissive policies for DNS traffic. Therefore, attackers are abusing the DNS protocol to tunnel C2 communications and retrieve malware payloads.

Well-known attack campaigns such as SUNBURST, OilRig, xHunt and DarkHydrus have employed DNS tunneling techniques. Permissive policies on DNS traffic allow attackers to reach the internet. The large amount of benign DNS traffic becomes a natural disguise for attackers to hide their footprint.

How DNS tunneling is performed: Two main components are needed to perform DNS tunneling: a client and a server. The client sends DNS packets to the internet, encodes content through DNS queries and decodes content from DNS responses. The server receives DNS queries from recursive resolvers, decodes content from DNS queries and encodes content as DNS responses.

Figure 1 illustrates this process at a high level. In this example, the client first encodes a secret value as the subdomain $secret and sends out the DNS query $secret.badsite[.]com. The resolver then iteratively queries nameservers of different domain levels until it gets a valid response. Figure 1 shows the server receiving and decoding the encoded value $secret. Optionally, the server component (domain nameservers) encodes a malicious payload as the subdomain $payload and sends out the DNS response: $secret.badsite[.]com CNAME $payload.bs[.]com.

The client component receives and decodes the encoded message $payload. If the secret value or the malicious payload exceeds the size of a single DNS packet, the client and server break them down and send them as multiple queries and responses.

Image 1 is a diagram of DNS tunneling queries and responses. From the client system, the bad site and the payload of the bad site travel to the DNS resolver. From there the queries and responses are exchanged between the DNS resolver and the root nameservers, TLD nameservers, and the domain nameservers.
Figure 1. An illustrative example of DNS tunneling queries and responses.

Instead of sending raw data, an encoding algorithm is often used to encode and fragment the data. Virtually anyone can come up with an algorithm to perform the fragmentation.

Meanwhile, there are ready-to-use DNS tunneling tools, including open-source applications such as iodine, DNSStager, dnscat2 and sliver, as well as proprietary ones such as Cobalt Strike. These tools support encoding generic messages as subdomains of DNS queries and as various types of DNS responses, such as A (IPv4 address), AAAA (IPv6 address), TXT, CNAME and MX. Please see our previous post for a more detailed description of DNS tunneling.

Case Studies

The Palo Alto Networks DNS Security service has supported detecting DNS tunneling traffic since 2019. DNS tunneling detection uses machine learning to analyze the behavioral qualities of DNS queries, DNS responses and how domains are hosted.

We have accumulated four years of data in our efforts to detect in-the-wild DNS tunneling traffic. Our previous research shows that malware campaigns like SUNBURST, OilRig, xHunt and DarkHydrus have used DNS tunneling for C2 communications.

Our data also reveals other uses for DNS tunneling. To circumvent censorship measures in an enterprise environment, employees have employed virtual private network (VPN) services that utilize DNS tunneling techniques.

Individuals have also used DNS tunneling to bypass charges by internet providers for commercial transportation services like airplanes or cruise ships. Our research indicates that different tunneling domains share characteristics that can reveal the tools used to embed data onto DNS queries and responses and the associated malware campaign name.

Note that people can also use DNS tunneling for legitimate purposes – such as security monitoring. Cybersecurity vendors can leverage the permissive policies of DNS traffic and use DNS tunneling techniques to build easy-to-deploy communication channels. We can use these communication channels to perform real-time checks for files and domains, as well as monitoring honeypots residing in internal networks.

The following anonymized record is an example of such communications:

Because enterprises usually approve such use cases, and because they can be identified and allowed on a per-case basis, we will not discuss them in detail. Meanwhile, it’s important to note that we obtained all the DNS queries and responses described in this article from third-party, passive DNS rather than from customers.

DNS Tunneling as C2

C2 is the most well-known use case for DNS tunneling. The same campaign can share characteristics such as common nameservers as C2 for communication or a common tunneling tool for encoding and decoding. We introduce examples from three campaigns: two we have identified, and one identified by the community.

Our first example is a campaign that has targeted one of our customers from the financial industry. We observed communications between 22 tunneling domains and the same customer.

These domains share seven nameserver IPs and use the same underlying encoding tool. The attackers also used domain names that imitate popular security or cloud vendors, hoping to evade detection.

A subset of these domains are as follows:

  • panos[.]ltd
  • ciscocloud[.]space
  • ubrella[.]online
  • msft[.]center
  • mscd[.]store
  • awsl[.]site

We list these domains together with their sample queries, nameserver domains and nameserver IPs in Table 1. Since this campaign targets a customer from the financial industry and uses the same underlying encoding tool that uses queries starting with a counter, we named this campaign FinCounter.

Domain Sample Query Nameserver Domain Nameserver IP
panos[.]ltd 10.eff89fcf44a13186ad3765f35860ce19c722c4bcda6bbbae6b7bab6025b36d0.d036b5a3fd8b67e55ee35feff7d014fdb8d32afe93d5d6f05f1dda3a096e8fa.2e10d53e935549b3a081982724c3e6f806.oak.panos[.]ltd bur.panos[.]ltd 34.92.43[.]140
ciscocloud[.]space 10.a6674ae5d37cab7263074adef14925ef28698896b8491276097a470beca325a.669f12d4b31e9a6707ce2ee5b595cb723f40ea6d8e5f406b8fba874c8bec632.3299de58f43c3e4be80a7d7db2a2ed5aee9e13bac9cb.habit.ciscocloud[.]space bram.ciscocloud[.]space 34.92.43[.]140
ubrella[.]online 8.d4fee8aa63e4ee6435452f86e84464168e96e314eb1a19c45e0e76f3ca71b2a.e9476062765ba0aeaeea97333805f09470ff3bd103e3ce8bd3ffefa3dfea90f.369cd352a204e9662db180407f1d1b8fa87be97c81d1.feign.ubrella[.]online rumor.ubrella[.]online 34.92.43[.]140
mscd[.]store 4.a6gpmbnqbjewgwnqnlivwhleux4vnnyiuduyqgjkyn9jcihsttpdbdenf7lx8jx.jqhdulrejthsyipzvoleyvhv5s99nydtj5um8bzdmdms9gwdqnq46yis5hvbryo.dernuvjw7a6p6ndq4c8lwomsl7zq5lncgsutndxfpaufefhr7xxeuhfpk8hs.sny7htmpdpqdcumtgrmeptytbe9p78skry64.17328.fish.mscd[.]store rug.mscd[.]store 35.194.255[.]111
awsl[.]site 1.758fcd0ac2301084ef82efb047050ff5e7d45b4cd636b46e4292b67acac5ab0.a1644dfde400b8d41e7b6ec37338c45d34a8e9ed81173e8dffdf57ebb3c9e30.9fc12877d608dfca610d50a121acbd30b2450391c13a.mud.awsl[.]site lkas.awsl[.]site 35.194.255[.]111
msft[.]center 10.c5f310abb43603a3af324ee92bea16c8132ec2909fbca8d1036fe409d33af9b.c8c30e936bffb9f93bcba2c27682dcca1ab79aced6d1cf015a11d56a9c2f9f5.c49d8757a19b693d78d1772977cbf164e2748b57bb9f.ud.msft[.]center 08e099da.msft[.]center 34.81.65[.]4

Table 1. A subset of the domains used in the FinCounter campaign.

Our second example is a campaign targeting another financial industry customer. We have observed three tunneling domains targeting the same customer and using the same underlying tunneling-capable tool, Cobalt Strike. Representative characteristics of Cobalt Strike include using common prefixes such as www, post and api.

We have listed the three domains, identity-mgmt[.]com, internalsupport[.]info, cloud-enrollment[.]com, along with sample queries, nameserver domains and IPs in Table 2. Since the attackers try to evade detection by adopting domain names that look like supporting services, we named this campaign FinSupport.

Domain Sample Query Nameserver Domain Nameserver IP
cloud-enrollment[.]com api.12abc2cb5.446f35fa.dns.cloud-enrollment[.]com ns1.cloud-enrollment[.]com 3.238.113[.]212
identity-mgmt[.]com intact.md.180.02d8f18d2.7e8986be.int.identity-mgmt[.]com ns1.cloud-enrollment[.]com 3.238.113[.]212
internalsupport[.]info icr.0325e18d8.16ae9fb2.pl.internalsupport[.]info dn.internalsupport[.]info 3.238.244[.]129

Table 2. The list of the domains used in the FinSupport campaign.

Our third example is the Decoy Dog campaign, which was reported by Infoblox in April 2023. We have detected tunneling activities using the same publicly reported domains, including the following:

  • claudfront[.]net
  • allowlisted[.]net
  • hsdps[.]cc

These Decoy Dog domains share the same underlying tunneling tool Pupy, which uses the character 9 as padding when encoding data. Table 3 provides a subset of the domains used by the Decoy Dog campaign, along with sample queries, nameserver domains and nameserver IPs.

Domain Sample Query Nameserver Domain Nameserver IP
claudfront[.]net fstz1yibfqnaw6mxpen3nknghh2q9999.1112umplhvbbzf2udr2rpuq9.claudfront[.]net ns1.claudfront[.]net, ns2.claudfront[.]net 5.252.176[.]63
allowlisted[.]net hs1t4lt2lb2ispy5ho4vmr5okvua9999.111b52v2e3ktuuyrn6j4xrq9.allowlisted[.]net ns1.allowlisted[.]net, ns2.allowlisted[.]net 83.166.240[.]52,

5.252.176[.]22
hsdps[.]cc gc2qagfacoq1zutfr61dko5mdjqa9999.1111suhsamuohkj4o4wn5qa9.hsdps[.]cc ns1.hsdps.ns1[.]name, ns2.hsdps.ns1[.]name 194.31.55[.]85

Table 3. A subset of the domains used in the Decoy Dog campaign.

DNS Tunneling as VPN Service

VPN service is a previously under-studied use case for DNS tunneling. Some VPN services utilize DNS tunneling to bypass firewall restrictions against VPNs in an enterprise environment. This type of DNS tunneling can also help users bypass service charges for internet access provided by commercial transportation services like airlines, buses or cruise ships.

These types of VPN services share characteristics with DNS tunneling for malicious C2 communications. These characteristics include a common nameserver for communication, or a common tunneling tool for encoding and decoding. To illustrate this, let's examine two popular VPN services and one tunneling tool adopted by multiple VPN services.

Astrill VPN is a popular VPN service that tunnels traffic using IPv6 (AAAA) queries and responses, and it uses a corpus of 49 tunneling domains to avoid being blocked. These domains are registered under different TLDs, including the following

  • .com
  • .net
  • .pw
  • .tech
  • .top
  • .space

Still, they all share the same nameserver IP addresses: 209.133.209[.]197 and 104.156.49[.]110. These are also pointed to by in01.astrill[.]com and in02.astrill[.]com, the official nameservers for Astrill VPN.

We have listed a subset of the domains used by Astrill VPN in Table 4, along with sample records, nameserver domains and nameserver IPs. The sample record is different from the sample query. A sample query only contains one field (i.e., the query), whereas a sample record contains three fields (the query, the response type and the response).

We frequently observe tunneling traffic from Astrill VPN in customers’ networks, indicating its wide adoption and potential abuse by employees to bypass corporate firewall restrictions on using VPN services. However, the real intentions of users can vary from unawareness of the underlying technology to active adoption of a DNS tunneling-based VPN service. An IT department can only identify and handle this on a per-case basis.

Domain Sample Record Nameserver Domain Nameserver IP
nanogardens[.]tech 0g87sbvrbb8f79ee.s2bbv747ck53wp7k.s.nanogardens[.]tech AAAA 1327:fb85:793c:bda6:d571:841f:b240[:]1cb2 s01.nanogardens[.]tech, s02.nanogardens[.]tech 209.133.209[.]197, 104.156.49[.]110
openair[.]pw nq482xfw1zyq0vg5.ehadgy6qeq015w47.s.openair[.]pw AAAA aca9:8998:5018:1b61:fa26:b64f:77fb[:]a325 s01.openair[.]pw, s02.openair[.]pw 209.133.209[.]197, 104.156.49[.]110
radiantsands[.]com nq482xfw1zyq0vg5.ehadgy6qeq015w47.s.radiantsands[.]com AAAA a646:622:d647:539b:a780:21c9:eabe[:]1162 s01.radiantsands[.]com, s02.radiantsands[.]com 209.133.209[.]197, 104.156.49[.]110

Table 4. A subset of the domains used by Astrill VPN.

Similarly, HA Tunnel Plus is a popular VPN service that tunnels traffic using TXT queries and responses, and it uses only one tunneling domain (hat53[.]com). We frequently observe tunneling traffic under this domain from customers’ networks, including cruise lines, which indicates that passengers use VPN services to bypass network service charges.

The following is a sample TXT tunneling record:

To optimize its performance, HA Tunnel Plus uses multiple nameservers to serve tunneling traffic from different regions. For example, tunneling queries that are subdomains of ns-ca1.hat53[.]com are redirected to a Canadian nameserver a-ca1.hat53[.]com with IP 138.197.156[.]58. Tunneling queries that are subdomains of ns-de1.hat53[.]com are redirected to a German nameserver a-de1.hat53[.]com with IP 104.248.27[.]88.

We list more service countries in Table 5.

Service Country Subdomain Nameserver Domain Nameserver IP
Canada ns-ca1.hat53[.]com a-ca1.hat53[.]com 138.197.156[.]58
Germany ns-de1.hat53[.]com a-de1.hat53[.]com 104.248.27[.]88
Singapore ns-sg1.hat53[.]com a-sg1.hat53[.]com 159.223.37[.]124
United States ns-us1.hat53[.]com a-us1.hat53[.]com 147.182.186[.]204

Table 5. A subset of the service countries of HA Tunnel Plus.

While VPN services can be individually identified and verified, different services can use the same underlying tunneling encoding and decoding tool. An example is dnstt, an open-source DNS tunneling tool used by several VPN services, such as the following:

Dnstt implements a protocol on top of DNS queries and responses, and it has security features such as encryption and authentication. Dnstt uses TXT record exclusively to encode data into DNS responses. In addition to the standard UDP, dnstt can also use DoH (DNS-over-HTTPS) and DoT (DNS-over-TLS) to provide privacy and evade detection.

Note that DNS Security Service can identify DoH and DoT resolvers and use the decryption feature to decrypt the payloads, allowing DNS tunneling detection to work seamlessly.

Table 6 includes example VPN services using the dnstt tool and their sample domain setups. Similar to HA Tunnel Plus, the listed services use multiple nameservers to serve tunneling traffic from different regions to optimize performance.

VPN Service Sample Domain Sample Record Nameserver Domains Nameserver IPs
MinaProNet VPN minapronetvpn[.]com 6rpaviehgxyvpyy4ocbbxkiyv2zvcacaad4iw3qaxa3acahhuyaaaayaaaabo3z.2.dnstt-server.minapronetvpn[.]com TXT \\000\\024\\169\\024\\174\\179r\\000@\\000\\248\\139n\\000\\1866\\001\\000\\1846\\001\\000\\000\\000\\000\\000  nl-server.minapronetvpn[.]com 146.190.20[.]243
ajph3r4dpholdyywl7fbxrsv4cofcacaab62iayaeynqaac2e4aaaayaaaahx6a.2.dnstt2-server.minapronetvpn[.]com TXT \\000\\024\\198u\\224\\156r\\000@\\000u\\164\\003\\000\\022\\027\\000\\000\\020\\027\\000\\000\\000\\000\\000\\000 ws2-server.minapronetvpn[.]com 104.248.142[.]17
Edoztunnel VPN dozapp[.]xyz khvsoyur5pwo5yyz6wzeikuydeivcacaabgxiaaa74bqaad4amaaalaaaaagi4s.idfsuez5dmik2iuoywuf57fozubc2vw2e7jd4ioufzyvaumnhuceo5gznotvueq.ez4u.newca.dozapp[.]xyz TXT \\000\\024*\\152\\025\\017r\\000@\\000dt\\000\\000\\251\\003\\000\\000\\253\\003\\000\\000\\000\\000\\000\\000 newcan.dozapp[.]xyz 144.217.81[.]86 
2no7jtyrhvomd2b6qdao4fkdb7ra.dnsau.dozapp[.]xyz TXT \\000\\024\\017a\\163\\209r\\000@\\000\\005\\000\\000\\000\\000\\000\\000\\000\\002\\000\\000\\000\\000\\000\\000\\000 au.dozapp[.]xyz 104.21.69[.]17
TunnelCat VPN tcat[.]site n6s7qzzxy43m5y6qu6tibfphtc3vcabaacvfsaia2ibqaabcaaaaa2aaaaaoimg.e2w6epiijkqs73eyxui3w4vxxpvemn5zy5ikh5med7gisk35c6lnwgjjcoquoer.igvoe2ysqytgj4jfonfbkteyrkowecqtkoskugqgomq56vxvpsmmdm4j4fk2tuo.223tigunynencz4ak6743i5z7jyyrxgazv7m4.dns.de3-dnstt.tcat[.]site TXT \\000\\024\\149\\231\\152\\183r\\000@\\000\\169y\\001\\000\\208\\003\\000\\000\\209\\003\\000\\000\\000\\000\\000\\000 de3-dnstt.tcat[.]site 64.225.106[.]232
hknjypabcykw3yznc4sb7ehanbufcabaactvsaaatebaaaheaaaaabyaaaaoo4n.22vtyimy.dns.dnstt-fast-de.tcat[.]site TXT \\000\\024\\144\\224hhr\\000@\\000\\167y\\000\\000\\152\\002\\000\\000\\153\\002\\000\\000\\000\\000\\000\\000 dnstt-fast-de.tcat[.]site 3.67.83[.]152

Table 6. Example VPN services using the dnstt tool.

Attribution of Tools and Campaigns

Since various tools use tunneling domains for different purposes, IT departments need more information on these domains to decide if they need to block them. For example, if an IT department encounters tunneling traffic from TunnelCat VPN in its enterprise network, this could be caused by an employee trying to circumvent firewall restrictions. They can warn the employee, or leadership can reinforce the organization's policy on best security practices.

If the VPN traffic is found within a cruise ship’s network, this is potentially because a passenger is trying to bypass service access charges, and the traffic should be blocked. However, if tunneling traffic matches the FinCounter campaign, enterprise IT departments can choose to isolate the compromised hosts and conduct a thorough investigation to understand the impact of the attack.

Tunneling traffic toward VPN services and C2 domains is different not only because of the implied intentions, but also because of the implied capabilities. First, VPN services require users to install an app that is vetted by marketplace maintainers, and which will authenticate that they’re using the right VPN server. While it’s possible to proxy malicious traffic through VPN servers, it does incur a higher engineering and financial overhead. Second, C2 domains don’t have such overhead and are highly customizable.

To this end, based on our insights into tunneling domains, we have implemented an attribution system that analyzes tunneling domains in real time to detect corresponding tools and campaigns.

The key idea is to extract characteristics unique to different tools and campaigns from tunneling domains including the following:

  • How tunneling domains are hosted
  • How data is encoded into queries and responses
  • How and when data is transmitted
  • Auxiliary information, such as who is being targeted and third-party verdicts about these domains

We have created a labeled dataset containing over 50 tunneling tools and campaigns and over 1,000 tunneling domains. Our system compares newly detected tunneling domains against the labeled ones using the aforementioned characteristics to automatically predict if a newly encountered domain belongs to an existing campaign or uses a known tunneling tool.

Table 7 lists examples of attributed tunneling tools and campaigns by the system. Rcsmf100[.]net is attributed to the Decoy Dog campaign mainly because it uses the same nameserver IP 83.166.240[.]52 as the domain allowlisted[.]net. On the other hand, hammercdntech[.]com and todoreal[.]cf are attributed to Cobalt Strike and dnstt respectively, because they reused the encoding tool.

Domain Sample Query Nameserver Domain Nameserver IP Attribution
rcsmf100[.]net tjkrwmhdoj5ctmtatfsvfnnwfeva9999.1125de632ujq9999.rcsmf100[.]net ns1.rcsmf100[.]net, ns2.rcsmf100[.]net 83.166.240[.]52 Decoy Dog
hammercdntech[.]com d-1ox.2cd649aed1f5ab311b08dce2066589388e395e9f0c0e85c940b37f209.b24afc9b030682dac90e4f83acc913711b68b056601e00e8778c4040.17f1d6e11.370935f6.ns1.hammercdntech[.]com cdn7ad6a01b.hammercdntech[.]com 65.20.73[.]176 Cobalt Strike
todoreal[.]cf bcm74mohxicvfy77u2zte2whzjjveacaadnj5nb6hubaaaceaiaaaaaaaaagvr6.kkniqaqaa2nlqeahpaiaaaracaaaaeaaaaaazy.slowdns.todoreal[.]cf TXT \\000\\024j\\199\\202sr\\000 \\000\\211w\\002\\000\\239\\002\\000\\000d\\004\\000\\000\\000\\000\\000\\000 dns.todoreal[.]cf 172.67.136[.]96 dnstt

Table 7. Examples of attributed tunneling tools and campaigns.

Conclusion

People are actively using DNS tunneling for various purposes, including well-known C2 servers and less-known VPN services. Detecting and understanding DNS tunneling can help protect Palo Alto Networks customers. Therefore, we have built a real-time attribution system to identify the underlying tools and associated campaigns for tunneling domains to provide more insights, allow fine-grained analysis and fast incident response.

Palo Alto Networks Next-Generation Firewall customers receive protections against malicious indicators (domain, IP) mentioned in this article via Advanced URL Filtering and our DNS Security subscription services.

Palo Alto Networks Cortex XDR analytics customers receive protection against DNS tunneling techniques mentioned in this article via the DNS tunneling analytics detector.

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

Indicators of Compromise

Domains

  • panos[.]ltd
  • ciscocloud[.]space
  • ubrella[.]online
  • mscd[.]store
  • awsl[.]site
  • msft[.]center
  • cloud-enrollment[.]com
  • identity-mgmt[.]com
  • internalsupport[.]info
  • claudfront[.]net
  • allowlisted[.]net
  • hsdps[.]cc
  • rcsmf100[.]net
  • hammercdntech[.]com

IPs

  • 34.92.43[.]140
  • 35.194.255[.]111
  • 34.81.65[.]4
  • 3.238.113[.]212
  • 3.238.244[.]129
  • 5.252.176[.]63
  • 83.166.240[.]52
  • 5.252.176[.]22
  • 194.31.55[.]85
  • 65.20.73[.]176

Additional Resources

Wireshark Tutorial: Identifying Hosts and Users

Posted on by Brad Duncan

Executive Summary

When a host within an organization's network is infected or otherwise compromised, responders need to quickly identify the affected host and user. In some organizations, this could involve reviewing a packet capture (pcap) of network traffic generated by the affected host.

This tutorial uses Wireshark to identify host and user data in pcaps. This is the third in a series of tutorials that provide tips and tricks to help security professionals more effectively use Wireshark. This article was first published in March 2019 and is being updated for 2023.

Related Unit 42 Topics pcap, Wireshark, Wireshark Tutorial

Requirements and Supporting Material

To fully understand this tutorial, readers should have reviewed the material in our previous tutorials on customizing Wireshark’s column display and using display filter expressions. Requirements also include a recent version of Wireshark, at least version 3.6.2 or later.

This tutorial features Wireshark version 4.0.8 with a customized column display from our previous tutorials. We strongly recommend using the most recent version of Wireshark available for your operating system (OS).

To follow this tutorial, readers should have a basic understanding of network traffic.

The pcaps used for this tutorial are in a password-protected ZIP archive located at our GitHub repository. Download the file named Wireshark-tutorial-identifying-hosts-and-users-5-pcaps.zip. Use infected as the password and extract the five pcaps, as shown below in Figure 1.

Image 1 is a screenshot of the Palo Alto Networks Unit 42 Wireshark tutorials GitHub. A black arrow indicates to hit the download button on the page. A second black arrow points to the “password required” popup after selecting the zip file in the downloads folder. The password is entered. A final black arrow points to the contents of the zip file.
Figure 1. Acquiring the pcaps for this tutorial.

The five extracted pcaps are:

  • Wireshark-tutorial-identifying-hosts-and-users-1-of-5.pcap
  • Wireshark-tutorial-identifying-hosts-and-users-2-of-5.pcap
  • Wireshark-tutorial-identifying-hosts-and-users-3-of-5.pcap
  • Wireshark-tutorial-identifying-hosts-and-users-4-of-5.pcap
  • Wireshark-tutorial-identifying-hosts-and-users-5-of-5.pcap

Host Information from Dynamic Host Configuration Protocol (DHCP) Traffic

Any host generating traffic within a network should have three identifiers: a MAC address, an IP address and a hostname.

Our first pcap for this tutorial is Wireshark-tutorial-identifying-hosts-and-users-1-of-5.pcap. This pcap is based on traffic to and from an Ethernet address at f8:ff:c2:04:a5:7b.

Using our basic web filter, we can correlate the IP address at 172.16.1[.]38 with its associated MAC address at f8:ff:c2:04:a5:7b, as shown below in Figure 2.

Image 2 is a Wireshark screenshot where the Src column is highlighted by a black rectangle. An arrow highlights the source MAC address in the lower pane. Another arrow highlights the source IP address.
Figure 2. Correlating an IP address with a MAC address.

DHCP traffic might reveal the hostname using this IP address. First, type dhcp in the Wireshark filter bar to filter for DHCP traffic, as shown below in Figure 3.

Image 3 is a Wireshark screenshot of the dhcp filter traffic.
Figure 3. Filtering on DHCP traffic in Wireshark.

Select the first frame in the results, the one that displays DHCP Request in the Info column. Then go to the frame details section and expand the line for Dynamic Host Configuration Protocol (Request), as shown below in Figure 4.

Image 4 is a Wireshark screenshot. The filter is dhcp. A certain row is selected (dark blue) in the top pane as indicated by an arrow. This expands the information in the bottom pane to show the Dynamic Host Configuration Protocol line.
Figure 4. Expanding the Dynamic Host Configuration Protocol line from a DHCP request.

Scroll down the frame details section, then expand the lines for Option: (50) Requested IP Address and Option: (12) Host Name as indicated below in Figure 5. This reveals the client’s MAC address at f8:ff:c2:04:a5:7b with hostname jeremiahs-MBP and a requested IP address of 172.16.1[.]38.

Image 5 is a Wireshark screenshot of dhcp traffic. Highlighted in red from top to bottom is: the client MAC address, the requested IP address, and the host name which is Jeremiahs-MBP.
Figure 5. Correlating the MAC address, IP address and hostname from DHCP traffic.

By default, Wireshark attempts to resolve the first 3 bytes of a MAC address to a vendor identification. In Figure 5, the vendor identification of the MAC address shows Apple_. That and the hostname ending with MBP indicate this might be an Apple MacBook Pro. This pcap also contains traffic to various Apple domains, further indicating this is an Apple host.

However, mobile devices often anonymize MAC addresses and users can easily change these to spoof different vendors. Due to anonymization and spoofing, we should never base host identification solely on a MAC address.

Host Information from NetBIOS Name Service (NBNS) Traffic

Depending on how frequently a DHCP lease is renewed, we might not have DHCP traffic in our pcap. Fortunately, we can use NBNS traffic to identify hostnames for computers running Microsoft Windows or Apple hosts running macOS.

Filter on nbns for our first pcap and review details under the Info column. This should reveal the same hostname we previously found in the DHCP traffic, displaying JEREMIAHS-MBP, as noted below in Figure 6.

Image 6 is a Wireshark screenshot. The filter is set to nbns. Black arrows indicate how to find the host name from the traffic, Jeremiahs-MBP.
Figure 6. Finding the hostname from NBNS traffic in our first pcap.

To examine NBNS traffic from a Windows host, open our second pcap Wireshark-tutorial-identifying-hosts-and-users-2-of-5.pcap and filter on nbns.

This pcap is from a MAC address at 78:c2:3b:b8:93:e8 using an internal IP address of 172.16.1[.]101. The Windows hostname is DESKTOP-HVKYP4S as shown below in Figure 7.

Image 7 is a Wireshark screenshot. The source column is highlight with a black retable. The MAC address is indicated in the lower pane starting with the line Ethernet II. The IP address is indicated in both the Src column and in the lower pane. The host are is also dettifiable under Additional records in the lower pane.
Figure 7. Correlating the MAC address, IP address and hostname filtering on NBNS traffic.

Device Models and Operating System (OS) from HTTP Traffic

Unencrypted HTTP traffic to a web browser can reveal the OS. This information is contained in the User-Agent line from the HTTP request headers.

However, use this method with caution. Certain browser extensions or a tool like cURL can easily change or spoof the User-Agent line in HTTP traffic. Various malware samples over the past several years have also spoofed the User-Agent line in their command and control traffic.

In 2023, this method has become unreliable because browser developers are reducing information contained in the User-Agent line, so most up-to-date web browsers no longer report the actual OS version used by the host.

While increasingly unreliable, this method can still help identify the platform type (Windows, Apple device, Linux or Android) from browser-generated unencrypted HTTP traffic.

Open our third pcap Wireshark-tutorial-identifying-hosts-and-users-3-of-5.pcap in Wireshark. A Windows host generated this traffic in an environment with both IPv4 and IPv6 enabled.

We can find unencrypted web traffic to a web browser by filtering on http.accept_language. This reveals all HTTP requests with an Accept-Language header line commonly generated by web browsers.

This filter avoids web traffic generated by the OS and other applications, so we can focus on any unencrypted HTTP traffic generated by a browser. The results reveal several unencrypted HTTP GET requests to outdoornebraska[.]gov over TCP port 80 as shown below in Figure 8.

Image 8 is a Wireshark screenshot. The traffic filter is http.accept_language. This shows unencrypted traffic to a web browser.
Figure 8. Filtering on our third pcap for unencrypted HTTP traffic to a web browser.

Select any of the HTTP GET requests to outdoornebraska[.]gov and follow the TCP stream, as shown below in Figure 9.

Image 9 is a Wireshark screenshot. he traffic filter is http.accept_language. By selecting a row (dark blue) from the menu the end user can select Follow and then TCP stream.
Figure 9. Following the TCP stream for an HTTP GET request to outdoornebraska[.]gov.
This TCP stream has HTTP request headers with a User-Agent line shown in Figure 10. This User-Agent line was generated by the Microsoft Edge web browser version 110.0.1587.69 from a Windows 11 host on March 10, 2023.

Image 10 is a screenshot of the Wireshark TCP stream window. Highlighted by a black rectangle and an arrow is the User-Agent string.
Figure 10. TCP stream with the User-Agent line generated by Microsoft Edge.

Note the following string in the User-Agent line above in Figure 10:

(Windows NT 10.0; Win64; x64)

Windows NT 10.0 represents either Windows 10 or Windows 11. For User-Agent lines, these Windows NT strings represent different versions of Microsoft Windows noted below in Table 1.

Windows NT version Windows OS Version
Windows NT 5.1 Windows XP
Windows NT 6.0 Windows Vista
Windows NT 6.1 Windows 7
Windows NT 6.2 Windows 8
Windows NT 6.3 Windows 8.1
Windows NT 10.0 Windows 10 or Windows 11

Table 1. “Windows NT” lines and the associated versions of Microsoft Windows.

Why does Windows NT 10.0 represent either Windows 10 or Windows 11 in Table 1? As part of a User-Agent reduction effort, developers for web browsers like Chrome, Edge and Firefox have frozen the Windows version number in their User-Agent lines at Windows NT 10.0. Starting sometime in 2023, the most current versions of Google’s Chrome browser will now report any version of Windows as Windows NT 10.0 in the User-Agent line.

This has also happened with Apple’s macOS, where User-Agent lines generated by web browsers in current versions of macOS have been frozen to report macOS as Catalina (version 10.15.7) in the HTTP request headers.

As noted earlier, unencrypted HTTP traffic from our third pcap was generated using the Microsoft Edge web browser version 110.0.1587.69. From the same TCP stream shown earlier in Figure 9, the final characters of the User-Agent line are Edg/110.0.1587.69 as indicated below in Figure 11. The Chromium-based version of Microsoft Edge uses the truncated term Edg as an identifier.

Image 11 is a screenshot of the Wireshark TCP stream window. Highlighted by a black rectangle and an arrow is the User-Agent string. The final characters identify the web browser (Edg/110.0.1587.69) which in this case is Microsoft Edge.
Figure 11. TCP stream with the User-Agent line and its final characters that identify the web browser.

User-Agent lines generated by Google Chrome or Chromium-based web browsers like Microsoft Edge include strings for Safari and AppleWebKit. This is most likely to ensure compatibility when viewing pages optimized for Apple’s Safari web browser.

Unencrypted HTTP web traffic generated by Android devices might also reveal the brand name and model of the device.

Open our fourth pcap Wireshark-tutorial-identifying-hosts-and-users-4-of-5.pcap in Wireshark. Use our basic web filter, select the first HTTP GET request for www.pcapworkshop[.]net and follow the TCP stream as illustrated below in Figure 12.

Image 12 is a Wireshark screenshot. The filter is set to (http.request or tls.handshael.type eq 1) and !(ssdp). The filter selection is “Basic.” One of the rows in the traffic is selected. Follow > TCP Stream is selected from the menu.
Figure 12. Our fourth pcap filtered Wireshark, where we follow a TCP stream.

This activity was captured from a Google Pixel Android phone, and the web traffic to www.pcapworkshop[.]net was generated using Google’s Chrome browser for Android phones and tablets. The TCP stream for this web traffic is shown below in Figure 13, highlighting the User-Agent line that identifies the device and browser.

Image 13 is a screenshot of the Wireshark TCP stream window. Highlighted by a black rectangle and an arrow is the User-Agent string. Identified in the string is Linux; Android 13; Pixel 4a (5G).
Figure 13. TCP stream with the User-Agent line generated by Chrome running on a Pixel phone.

Collected on May 14, 2023, this traffic reveals (Linux; Android 13; Pixel 4a (5G)) in the User-Agent line. Current versions of Chrome will now report this same device as (Linux; Android 10; K) because of Google’s User-Agent reduction effort.

While User-Agent reduction applies to Android devices running Chrome or Chromium-based browsers, we did not notice any reduction when using the Safari browser on an Apple mobile device.

Open our fifth pcap Wireshark-tutorial-identifying-hosts-and-users-5-of-5.pcap in Wireshark. Use our basic web filter, select the first HTTP GET request for www.pcapworkshop[.]net and follow the TCP stream as shown below in Figure 14.

Image 14 is a Wireshark screenshot. The filter is set to (hhtp.request or tls.handshael.type eq 1) and !(ssdp). The filter selection is “Basic.” The pcapworkshop[.]net row in the traffic is selected. Follow > TCP Stream is selected from the menu.
Figure 14. Our fifth pcap filtered Wireshark, where we follow a TCP stream.
This activity was captured from an Apple iPhone running iOS 16.4.1, and the web traffic to www.pcapworkshop[.]net was generated using Apple’s Safari mobile web browser on April 10, 2023. The TCP stream for this web traffic is shown below in Figure 15, highlighting the User-Agent line that identifies the device and OS version.

Image 15 is a screenshot of the Wireshark TCP stream window. Highlighted by a black rectangle and an arrow is the User-Agent string. Identified in the string is iPhone; CPU iPhone OS 16_4_1 like Mac OS X.
Figure 15. TCP stream with the User-Agent line generated by Safari running on an iPhone.

Since more websites are using HTTPS, this method of host identification has become increasingly difficult, because HTTP headers and content are not visible in encrypted HTTPS traffic. However, for those who find unencrypted HTTP web traffic during their investigation, this method can provide more information to help identify a host.

Identifying Users in an Active Directory (AD) Environment

Perhaps the most important information when resolving an incident is determining the user associated with an infected host. For Windows clients in an AD environment, we can determine the user from user account names in Kerberos traffic.

Let’s return to our third pcap Wireshark-tutorial-identifying-hosts-and-users-3-of-5.pcap and open it in Wireshark.

This pcap is from a Windows host in the following AD environment:

  • Domain: www.pcapworkshop[.]net
  • Network segment: 172.16.1[.]0/24 (172.16.1[.]0 - 172.16.1[.]255)
  • Domain controller IP: 172.16.1[.]16
  • Domain controller hostname: PCAPWORKSHOP-DC
  • Segment gateway: 172.16.1[.]1
  • Broadcast address: 172.16.1[.]255
  • Windows client: 172.16.1[.]141

While this is an environment with both IPv4 and IPv6 enabled, the Kerberos traffic is IPv4 only.

Open the pcap in Wireshark and filter on kerberos.CNameString. Select the first frame. Go to the frame details section and expand the lines, as shown in Figure 16. Select the line with CNameString: desktop-hsjd5r8$ and apply it as a column.

Image 16 is a Wireshark screenshot. The filter is set to kerberos.CNameString. In the lower pane, Kerberos is indicated by a black arrow as well as other information. The CNameString is selected and the option Apply as Column is selected.
Figure 16. Finding the CNameString value and applying it as a column.

This will create a new column titled CNameString. Scroll down to the last frames in the column display. The CNameString column reveals a user account name for rene.mccollum in traffic between the domain controller at 172.16.1[.]16 and the Windows client at 172.16.1[.]141, as noted below in Figure 17.

Image 17 is a Wireshark screenshot. The filter is set to kerberos.CNameString. The new column CNameString is highlighted by a black rectangle.
Figure 17. Finding the Windows user account name in our newly created CNameString column.

Besides Kerberos traffic, we might find a first and last name or other identifiers of the user in Lightweight Directory Access Protocol (LDAP) traffic. Use the following Wireshark filter:

ldap contains "CN=Users"

This should reveal the string "CN=Rene McCollum, under the Info column, as shown below in Figure 18.

Image 18 is a Wireshark screenshot. The filter is set to ldap contains “CN=Users”. These filtered users are highlighted within a black rectangle.
Figure 18. Finding the first and last name in LDAP traffic.

Default Windows Hostnames

The default hostname for Windows 10 and Windows 11 computers is a 15-character string that starts with DESKTOP- and ends with seven random alpha-numeric characters.

Search for this identifier in our third pcap using ip contains "DESKTOP-" in the Wireshark filter. This finds the plaintext ASCII string DESKTOP- in any traffic at the IP layer or higher. For example, this search would find if the string appears in TCP from SMB or Kerberos activity, but it also includes traffic that uses UDP like DNS or DHCP.

After applying this filter, review the Info column, as shown below in Figure 19.

Image 19 is a Wireshark screenshot where the filter is set to ip contains “DESKTOP-“. Black arrows highlight the rows where ANY DESKTOP can be spotted in the traffic.
Figure 19. Searching for a default Windows 10 or Windows 11 hostname.

This search is case sensitive, and this identifier also appears as a lower-case string in our pcap.

An even better way to find the DESKTOP- string is to clear the Wireshark filter and use the Find Packet function under Wireshark’s Edit menu, as shown below in Figure 20.

Image 20 is a screenshot of the Wireshark Edit menu. Find Packet has been selected.
Figure 20. Using the Find Packet feature in Wireshark.

This brings up Wireshark’s search panel immediately under the search filter bar. Select “Packet Details” and “String” as our search options before typing desktop- as the search string. See Figure 21 for an example.

Image 21 is a Wireshark screenshot of packet details. Red arrows point to the Packet details dropdown menu, the String dropdown menu and the Find button. The filter used is desktop-. In the lower pane, a red arrow points to the Queries dropdown that indulges the DESKTOP line in the packet details.
Figure 21. Finding the string “desktop-” in the packet details.

Each time we click the Find button in our search panel, the string is highlighted in the frame details section, as noted above in Figure 21.

Conclusion

Properly identifying hosts and users from network traffic is essential when investigating an infected host. Following the methods from this tutorial, we can better utilize Wireshark to help identify affected hosts and users.

Our next tutorial in this series reviews how to export objects from a pcap.

Additional Resources

Leveraging a Hooking Framework to Expand Malware Detection Coverage on the Android Platform

Posted on by Yang Ji

Executive Summary

One of the biggest challenges we face in analyzing Android application package (APK) samples at scale is the diversity of Android platform versions that malware authors use. When trying to utilize static and dynamic analysis techniques in the malware detection space, the sheer variety of platform versions can feel overwhelming.

In this article, we will discuss this issue of how malware authors use obfuscation to make analyzing their Android malware more challenging. We will review two such case studies to illustrate those obfuscation techniques in action. Finally, we’ll cover some overall techniques researchers can use to address these obstacles.

The Advanced WildFire (AWF) cloud-delivered malware analysis service accurately identifies samples discussed in this blog as malicious. Palo Alto Networks customers with an active AWF subscription automatically receive protection from these threats.

Related Unit 42 Topics Sandbox, Android

Hooking-Based Sandbox

Malware researchers frequently use both static and dynamic analysis techniques. The former involves examining characteristics of a malware sample on disk. The latter involves watching the sample in action, such as in a sandbox. Putting these two techniques together helps us form a complete picture of a threat’s behavior.

On the Android platform, dynamic analysis traces an APK sample's execution and extracts runtime information for malware detection and analysis. One sandboxing technique we can use for dynamic analysis is to build up a hooking framework.

Hooking is a technique that intercepts Android Framework API calls made by the sample during its analysis run, especially capturing and/or manipulating the functions’ arguments and return value, where present. This is not at all peculiar to the Android platform. The same basic theory applies to native and managed code on all major operating systems today.

Hooking is accomplished by inserting a redirection to the user-specified "hook" function at runtime, as shown below in Figure 1. Modern sandboxes rely on the hooking technique to provide versatile deobfuscation of code, data (strings) and embedded payloads at runtime.

Instead of being fixed to a certain Android platform version, the hooking framework flexibly supports a wide range of Android API levels by dynamically adding tracing logic to the sample's runtime. This allows the tracing development to be focused on triggering and extraction of the malicious behavior.

A limitation of this framework is that it cannot instrument every line of code within the executed Android Framework API function. This is because the instrumentation patches bytes at the function prologue (i.e., at the beginning of the function) to jump to the hook function, rather than at each instruction level. However, in practice, this is often a "good enough " tradeoff for a researcher to accept.

 

Before Hooking (Original)

After Hooking (Modified)
Image 1 is a comparison of the original script before hooking versus after. The image on the left is the original code. The image on the right is modified. the code now includes red text: jump (to hook) with a red arrow pointing to more code with the hook. Image 1 is a comparison of the original script before hooking versus after. The image on the left is the original code. The image on the right is modified. the code now includes red text: jump (to hook) with a red arrow pointing to more code with the hook.

Figure 1. Hooking code flow modification.

Besides hooking, another way to implement an Android sandbox is to add instrumentation at specific points of interest into the Android Open Source Project (AOSP) codebase. Creating a custom build of the Android codebase for dynamic analysis purposes is possible due to the open-source nature of the Android ecosystem.

Researchers capture values by inserting instrumentation code at certain strategic points. Sensitive Android Framework API functions related to the reading of Short Message Service (SMS) text messages are an example of a suitable candidate for instrumentation because these are commonly abused by malware authors. Doing so allows the researcher to get a better understanding of the sample's behavior.

An advantage of this approach over hooking is that it has guaranteed comprehensive coverage of the entire Android Framework API. Researchers can instrument every line of code simply by inserting the extra instrumentation code at the line of interest and then recompiling the AOSP codebase, though recompilation can be a rather non-trivial task.

This method is also transparent to the sample being analyzed, meaning the sample is likely to be unable to distinguish that it is running within an instrumented AOSP environment. Instrumentation also accelerates the analysis process, as researchers must otherwise unpack the actual deobfuscated malicious payloads (likely in memory, or with dropped files) before detonation.

Unfortunately, this method comes with the high cost of regularly maintaining a repeatable build of the heavily modified AOSP image as the Android platform evolves. This is particularly problematic after major upgrades or changes to the API, because we must update our tracing modules to support these new versions. One example was when Google changed from using the old Dalvik runtime to the current Android runtime (ART). This is intrinsically an arduous undertaking of maintenance.

Extending API Level Coverage

Google evolves the Android platform over time and, in so doing, produces different versions. This creates different API levels that are tied to these versions. Figure 2 shows the different Android versions as of May 2023.

Each of these API levels may deprecate outdated functions or functions that pose a security risk to the device owner, while also introducing new features. This can be problematic for dynamically instrumenting APK samples because developers will need to regularly maintain existing hooks, following changes in Android Framework API function specifications.

This is where hooking shines, because it is extensible by default. This refers to its ability to support multiple Android Framework API levels on-demand.

Image 2 is a distribution of Android APIs. The first is Android 4.4. which is KitKat with the least amount at 0.5%. The most is Android 11 (R) at 23.1%.
Figure 2. API level distribution chart (source: Android Distribution Chart – Composables)

We searched VirusTotal (VT) and found 12,394 malicious APK samples in the 12-day period from August 27 through Sept. 7, 2023. The minimum API level runtime requirements of these APK malware samples varied from API level 19 to API level 30. Figure 3 is a chart summarizing these results.

Image 3 is a column graph of APK malware samples in VirusTotal. The highest frequency is 21 at over 5,000. The next highest is 19 at almost 3,00 and then there isa severe drop to 23 with 592.
Figure 3. APK malware samples (VirusTotal).

Note: According to the Android API Levels website, minSdkVersion refers to "the minimum SDK version your app will support, defined in build.gradle." For example, if your minSdk is 26, this SDK version corresponds to API Level 26, i.e., Android 8. This means your app will only run on devices with Android 8 or higher.

Based on our internal telemetry in the same time range, we observe similar results in Figure 4 below.

Image 4 is a pie chart comparing internal APK samples. The largest amount is non-malware at 91.1%.
Figure 4. APK samples (internal).

For such samples, there is also a spread across a wide range of recent minimum API level runtime requirements. This ranges from API level 19 all the way to the latest API level 34, shown in Figure 5.

Image 5 is a column chart of the amount of internal APK malware samples. The highest is for 21 at almost 10,000. The second highest is 19 at 6,043. The third highest is 23 with a large drop to 1,172.
Figure 5. APK malware samples (internal).

Google most recently announced its enforcement of target API level requirements for Google Play apps on Aug. 31, 2023, and enforced annually thereafter. With such an announcement, we can expect a continual spread across the range of available API levels of APK samples. This is because there will always be a grace period for upgrading, and alternatives, like distributing through a third-party App Store.

Based on Google's current detection, no apps containing the malware samples discussed in this article are found on Google Play. Google Play Protect protects users from apps known to contain malware on Android devices with Google Play Services, even when those apps come from other sources.

Consequently, this means that our WildFire sandbox would need to keep up with this trend of supporting newer API levels over time, as Google releases them. A hooking-based sandbox would simplify this task of maintenance, as hooks can be added or removed on-demand.

Deobfuscation at Runtime

Obfuscation employed by APK samples on the Android platform exists because it aims to hinder traditional static analysis efforts, like what occurs on all other platforms. Both threat actors and vendors have a wealth of options available to them for easily switching between various obfuscation strategies. These options range from readily available commercial off-the-shelf solutions, to free and open-source software.

The same sort of challenges do not adversely affect dynamic analysis approaches the way they do classic static analysis. Dynamic analysis excels at capturing and extracting fully deobfuscated and unpacked core artifacts.

APK/Dalvik bytecode (DEX) payloads and URL strings are some examples of such artifacts. APK refers to the Android Application, DEX means the core programming code that powers the Android application and URL strings are server addresses to contact remote endpoints via the web (e.g., https://paloaltonetworks.com).

Researchers need these artifacts for identification and detection purposes, as well as for performing further analysis. Although deeper analysis does incur a longer runtime because it’s reporting its activities to us, it is still necessary since we need time to fully observe the interactions of the APK sample upon its detonation within an instrumented environment.

Researchers need to be aware that there is a significant associated investment of research and development for the malware author as they apply each evasion technique to their APK sample before distribution. Threat actors generally pick the least complex mechanism that would allow them to pass through defenses before they would consider upgrading their techniques.

Adopting a dynamic analysis approach would be more effective for tackling the challenge of obfuscation than traditional static analysis. A sandbox can overcome such evasive techniques, uncovering useful artifacts available in cleartext at runtime.

These artifacts would otherwise require us to invest some effort into tracing the flow of the DEX in the APK sample. It would also require us to dedicate resources to manually resolve tricky values, such as the database decryption key. Through reverse engineering efforts, we discovered the key to be derived from the code-signing digital signature attached to the APK sample.

Case Studies

Cerberus Banking Trojan

Cerberus is a banking Trojan that steals valuable information off Android mobile devices. Attackers can also use it to gain access to and take control over the device, impersonating its owner to perform actions on their behalf.

Image 6 is two mobile phone screenshots side by side. On the left is a screen of basic applications. Highlighted in a red box is the Google Play store button. On the right is a list of all apps. The Google Play store button is highlighted in red. It has no description and is 360 kb in size.
Figure 6. Android Launcher menu screen and application listing.

A Cerberus sample (SHA-256 1249c4d3a4b499dc8a9a2b3591614966145daac808d440e5202335d9a4226ff8), is digitally code-signed with a generic Android certificate. It masquerades as a Google Play Store Android application by using the same icon. However, the author programmed it such that it blanks out its own application name, with a contiguous sequence of five whitespace (\x20) characters (see Figure 6).

This APK sample also achieves obfuscation by applying Base64 encoding on top of RC4 encryption to all of its configuration strings. The APK sample stores these as variable values within a single, monolithic String Pool class. The APK sample stores the responsible method named a inside the package named com.fky.lblabjglab, class a, shown in Table 1.

No Variable name Configuration key (obfuscated) Configuration key (deobfuscated)
1 b wssmnpdmydteY2Y3NGY4MzNmNg== idbot
2 c ujvsdjiocsqfMzg2Njg5ODcyZmExNzRkMzgxMjZkZjIyZTBhMw== initialization
3 d ysknmuiqllmjODRiMDRhNmJmZTQ4MDg1OTE2MDM4YTRiNGI= urlAdminPanel
4 e wdhinzpyayjvNDdlMzFkN2Q2MjU5MWZkMTVkZWZmMjE4Mjg5Mg== starterService
5 f vbylpyugkbfjYjZiMjgyNTY2ZmViZjA2YWM2ZTk1NTQyYTA= statusInstall

This sample obfuscates strings, according to the following scheme shown in Figure 7.

 

Image 7 is a diagram of how the obfuscation works. Idbot > RC4 encryption (key wssmnpdmydte) > Base64 encoding > Y2Y3NGY4MzNmNg==.
Figure 7. Configuration string obfuscation scheme.

As an example, given the input string idbot with a randomly chosen lowercase alphabetic cipher key of length 12 (wssmnpdmydte), the Android application process applies RC4 encryption using this key onto the input string. The resulting bytes are then Base64 encoded to form printable ASCII characters (Y2Y3NGY4MzNmNg==), for lossless storage and transmission. Finally, the Android application process prepends the selected key to this result to produce the final obfuscated string, so that the reverse (i.e., decryption process) is possible.

It is common to encounter basic Base64 encoding (perhaps with a custom character set) or XOR encryption with a fixed single-byte key applied to strings in obfuscated APK samples. Alternatively, it would usually be stronger, more secure encryption – for example, a stream cipher like Rivest Cipher 4 (RC4). This is also the case here, but with a slight twist. They use key-as-prefix, symmetric key algorithms like Data Encryption Standard (DES) and Advanced Encryption Standard (AES).

Deobfuscating Configuration Keys

Useful heuristics for identifying string obfuscation routines are to watch out for the most highly cross-referenced methods. Such methods should often take at least a string parameter input, producing a string output return value. They are often standalone methods containing loops (e.g., character-by-character iteration) and bear almost no dependency on Android Framework API functions.

By controlling the execution to restore program states and side effects at runtime, the sandbox can extract the deobfuscated configuration file named settings.xml. The Android application process stores this file in the Android application's runtime folder, under "Shared Preferences". During its initialization phase, the Android application process repeatedly rewrites this file, while it is deobfuscating its hardcoded configuration parameters with fixed values. We include an excerpt below for reference, in Figure 8.

Image 8 is a screenshot of many lines of code. This is the deobfuscated XML.
Figure 8. Deobfuscated configuration XML.

We can quickly scale up the ability to parse and extract such information from samples belonging to this family. This will facilitate do the following:

  • Building out a collection of actionable threat intelligence to perform attribution
  • Gaining better insights into adversary tactics, techniques, and procedures (TTPs)
  • Tracking these threat actor groups as they evolve over time

HiddenAd Adware

HiddenAd is adware that aggressively displays advertisements to Android users and generates revenue for the adware author. Its functionality is mostly hidden by disguising as benign Android applications. Attackers can also use some variants of this family to deliver other packaged exploit kits, credential stealers or other malicious tools.

In this case study, we focus on a cluster of samples from this family, which perform the following activities:

  • Hiding its application icon from the Android Launcher menu screen
  • Protecting its critical secondary payloads via SQLCipher database encryption

Faking "Bloons TD 6"

To demonstrate these capabilities, we analyze the Android APK sample that has the SHA-256 hash 73dee5433d560c072ea42b2288f826b16250da6f07543b3e3387ace31a13bd7c.

Attackers consider hiding the threat’s application icon a tactically advantageous move. This is because the Android Launcher menu screen (shown in Figure 9) is where an Android user would commonly look to determine what applications they’ve installed on their device.

Image 9 is a screenshot of the Android launcher menu and applications. A red field highlights the Bloons TD 6 application. A red arrow points to the list of applications.
Figure 9. Android Launcher menu screen and application listing.

If one were to dig deeper, the sample entry is still evident in the application listing. Notice the "Bloons TD 6" row highlighted in red, which is the application name of this sample.

The application name originates from the android:label attribute of the <application> node in the manifest file AndroidManifest.xml. This sample is trying to masquerade as a legitimate Android game. According to the Wikipedia description of this game, "Bloons TD 6 is a 2018 tower defense game developed and published by Ninja Kiwi."

The sample encapsulates its next-stage APK and DEX payloads within an encrypted SQLite database file, embedded inside the original sample's assets/ directory. The author enabled the popular SQLCipher cryptographic extension in this SQLite database file. This automatically provides government-standard AES encryption (256-bit), operating in Cipher block chaining (CBC) mode.

The sample uses this encryption with SQLCipher 3(.5.9) default settings. A good indicator of this is the presence of the Android native library libsqlcipher.so under the original sample's lib/ directory.

In this case, the sample contains the database file muzikmp3mustafasandal.db. The cryptographic key is the hashCode of the code-signing digital signature attached to the sample. In this case, the key is the string -923130181.

This database file contains the core payloads, namely the APK sample muzikmp3mustafasandal.dat.jar, and DEX bytecode ZnWjqpRHi.dex. The table named iFqBWMAzy in the database stores these as its rows, where:

  • The table column EQSnKGDYR stores the filename
  • The table column bANpZqhWm stores the raw file contents

An additional feature of this sample not featured across the rest of the cluster is the way it conceals its URL string. The parts of the URL are separated to make static analysis (exact URL string pattern matching) more likely to fail. Joining the parts of the URL recovers the complete URL.

For this sample, the original URL is hxxp[://]madhavaapps[.]science/dwarkadhish/alternate148275android[.]php as shown in Figure 10 below.

Image 10 is a code snippet containing the original URL. The URL is bolded.
Figure 10. Code snippet containing the URL string.

Hiding Under U+FFF8

Unlike the previous "Bloons TD 6" sample, another similar APK sample (SHA-256 hash 833d9669dd64a2aa009a3741c8f16612cfafc3104b1f2113ac69255b6fcabf8e) does not mimic a legitimate benign Android application. Instead, it appends itself at the end of the application listing using a blank white icon with an "empty," nonprintable Unicode (UTF-8) character U+FFF8 (\xef\xbf\xb8) label shown in Figure 11.

Image 11 is a screenshot of all the applications on an Android phone. Highlighted inside a red rectangle is an app with a blank white icon. The title of the app is missing. The size of the blank app is 14.01 MB.
Figure 11. Android Application listing.

This sample uses SQLCipher 4(.3.0) default settings instead of SQLCipher 3(.5.9), which the previous sample we discussed used. The same method derives the cryptographic key, but because a different certificate is attached to the sample, the key changes to the String -1463079363.

The database file is named com.db, and it contains the core payloads, namely APK sample com.dat.jar, and DEX bytecode viVfyboRT.dex. They are stored as rows in a table named abaQwumOc in the database. This table consists of two columns:

  • The table column DvaIEsASI stores the filename
  • The table column RsKesUrHq stores the raw file contents

We can obtain the SQLCipher database decryption key by placing a hook on the method getWritableDatabase in package net.sqlcipher.database, class SQLiteOpenHelper, to capture the String parameter (i.e., the decryption key).

Whether we’re using SQLCipher version 3 or 4, it collectively determines its associated cryptographic parameters. These cryptographic parameters are:

  • Page size
  • Key derivation function (KDF)
  • Number of iterations of the KDF
  • Hash-based message authentication code (HMAC) algorithm

To gather these parameters, we can place a hook on the constructor of the package net.sqlcipher.database, class SQLiteDatabase. Placing a hook on the constructor will obtain the value of the static String field named SQLCIPHER_ANDROID_VERSION.

Deobfuscating secondary APK/DEX payloads provides the researcher with a greater depth of knowledge into the inner workings of these samples. It is common to find threat actors authoring samples in layers so that defenders cannot easily uncover their true, malicious intent. This allows them a better chance at evading security defenses, especially at the perimeter.

Adopting a strategy of layering grants attackers versatility, since they can swap in or out the modular components when the security defense measure detects them. The attacker is also able to mix-and-match components, producing a wide variety of combinations. This makes specifying and maintaining detection rules a chore for defenders.

Conclusion

With the fast advancement of the Android platform, threat actors are targeting a wider range of Android system versions, especially the more recent ones. To provide consistent protection for our customers, Advanced WildFire (AWF) has been using a hooking framework with related techniques to extend the supported range of Android API versions in the dynamic analysis sandbox.

We have shown that by relying on a hooking framework, a sandbox is able to expose malicious behaviors that are difficult to uncover using a static analysis approach. Identifying these malicious behaviors is critical in contributing to excellent detection quality.

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

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

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

Indicators of Compromise

Category Values
APK samples Cerberus

  • 1249c4d3a4b499dc8a9a2b3591614966145daac808d440e5202335d9a4226ff8

HiddenAd

  • 73dee5433d560c072ea42b2288f826b16250da6f07543b3e3387ace31a13bd7c
  • 833d9669dd64a2aa009a3741c8f16612cfafc3104b1f2113ac69255b6fcabf8e
URLs
  • hxxp[://]20[.]49[.]203[.]83/gate[.]php
  • hxxp[://]madhavaapps[.]science/dwarkadhish/alternate148275android[.]php
Certificate Thumbprints (SHA-1)
  • 83659BA7B2DEC9E5C21A7E6DEEB8B0F8674D0620
  • C85070B16749D25747E040A9FB6910D6351D1F88

MITRE TTPs

ID Technique Description
T1628.001 Hide Artifacts: Suppress Application Icon APK samples suppress their icon from displaying to the user in the application launcher.

This hides the fact that the sample has been installed, and can make it more difficult for the user to uninstall the application.
T1406 Obfuscated Files or Information APK samples make a payload difficult to discover or analyze by encrypting or otherwise obfuscating (splitting and concatenating) its contents on the device or in transit.

This is a common behavior that attackers can use across different platforms and the network to evade defenses. Payloads may be encrypted or obfuscated to avoid detection.

 

Threat Brief - MOVEit Transfer SQL Injection Vulnerabilities: CVE-2023-34362, CVE-2023-35036 and CVE-2023-35708 (Updated Oct 4)

Posted on by Unit 42

Update October 4: We have added additional information using data gathered from Advanced Threat Prevention.

Update July 7: We cover the most recently disclosed vulnerabilities in MOVEit Transfer, as well as the July 2023 service pack.

Executive Summary

On May 31, Progress Software posted a notification alerting customers of a critical Structured Query Language injection (SQLi) vulnerability (CVE-2023-34362) in their MOVEit Transfer product. MOVEit Transfer is a managed file transfer (MFT) application intended to provide secure collaboration and automated file transfers of sensitive data.

Update: On June 9 and June 15, Progress Software alerted customers of additional SQL Injection vulnerabilities (also rated critical by Progress and got assigned CVE-2023-35036 and CVE-2023-35708, respectively).

Update:  On July 7, Progress Software released a service pack addressing three additional vulnerabilities, one rated critical and two rated high.

CVE-2023-36934 is an SQLi vulnerability that could allow an unauthenticated attacker to gain unauthorized access to the MOVEit Transfer database. CVE-2023-36932 refers to multiple SQLi vulnerabilities that could allow an authenticated attacker to gain unauthorized access to the MOVEit Transfer database. Lastly, CVE-2023-36933 refers to a vulnerability that potentially allows an attacker to invoke a method that results in an unhandled exception that may cause the MOVEit Transfer application to terminate unexpectedly.

All three vulnerabilities were identified by security researchers and there is no evidence any of the vulnerabilities are currently being exploited in the wild. 

Progress recommends that all customers apply the July 2023 service pack as it contains fixes for all three vulnerabilities.

In all cases, the original vulnerability was being exploited to upload a web shell onto the MOVEit Transfer server. The web shell also allowed threat actors to enumerate files and folders on the MOVEit Transfer server, read configuration information, download files, and create or delete MOVEit server user accounts. 

Unit 42 Incident Response has assisted organizations through multiple previous and ongoing investigations where the initial point of compromise was the exploitation of MOVEit Transfer. The earliest evidence of compromise throughout our investigations is May 27 and tactics, techniques and procedures (TTPs) have so far been consistent with those reported by other organizations in their initial blogs.

Palo Alto Networks Xpanse indicates there are at least 2,674 MOVEit servers exposing HTTP/HTTPs traffic. This does not include MOVEit Cloud servers. Progress has indicated that all MOVEit Cloud servers have been “patched and fully restored.” 

Progress Software has provided mitigation guidance that all MOVEit Transfer customers should seriously consider following.

Palo Alto Networks customers receive protections from and mitigations for CVE-2023-34362 in the following ways:

  • Next-Generation Firewall with the Advanced Threat Prevention security subscription can help block the associated web shell.
  • Next Generation Firewall with a Threat Prevention security subscription can help block the attacks with Best Practices via Threat Prevention signatures.
  • Advanced URL Filtering can block known IoCs.
  • A Cortex XSOAR response pack and playbook can automate the mitigation process.
  • Cortex XDR and XSIAM agents help protect against post-exploitation activities described in this blog using Behavioral Threat Protection, Anti-Webshell Protection and multiple additional security modules.
  • Cortex Analytics has multiple detection models that help detect post-exploitation activities, with other relevant coverage by the Identity Analytics and ITDR modules.
  • Cortex Xpanse customers can identify external facing instances of the application through the “MOVEit Transfer” attack surface rule.
  • XQL queries provided below can be used with Cortex XDR to help track attempts to exploit this CVE.
  • Organizations can engage the Unit 42 Incident Response team for specific assistance with this threat and others.
  • Prisma Cloud WAAS customers are protected from this threat through the App Firewall SQL Injection protection
  • Next-Generation Firewall with the Advanced Threat Prevention security subscription can help block the associated web shell.
  • Next-Generation Firewall with the Advanced Threat Prevention security subscription can help detect and block the exploit traffic.
Vulnerabilities Discussed CVE-2023-34362, CVE-2023-35036, CVE-2023-35708, CVE-2023-36934

Details of the Vulnerability

On May 31, Progress Software posted a notification alerting customers of a critical vulnerability (CVE-2023-34362) in their MOVEit Transfer product. CVE-2023-34362 is a SQLi vulnerability that enables threat actors the ability to potentially elevate privileges, view and download data from the database server, and potentially enable the theft of Azure system settings and the associated key and containers.

Both Huntress and Mandiant have written blogs in the days preceding the CVE assignment, detailing their observations of the ongoing campaign to exploit this vulnerability. Mandiant has identified “multiple cases where large volumes of files have been stolen from victims' MOVEit transfer systems.” So far our internal investigation findings are consistent with both those of Huntress and Mandiant.

Unit 42 researchers have seen the web shell in the D:\MOVEitDMZ\wwwroot\human2.aspx directory, which differs slightly from the directory reported by Huntress. We’ve also seen the precompiled .NET DLLs in the C:\Windows\Temp directory.

For example, we’ve observed the file path C:\Windows\Temp\erymbsqv\erymbsqv.dll, where the random characters of the folder and file names are dynamically generated and different across compromised hosts. Additional indicators of compromise (IoCs) not mentioned in the Progress, Huntress or Mandiant blogs are included below.

Note: The IoCs below do contain IP addresses mentioned in the Progress, Huntress and Mandiant blogs because we think it’s important to highlight the reuse of infrastructure across victim organizations.

Current Scope of the Attack

Unit 42 Incident Response has several ongoing investigations where the initial point of compromise appears to be the exploitation of CVE-2023-34362. Although details are still being uncovered, the earliest evidence of exploitation is May 27.

Mandiant has also reported they have several ongoing investigations where exploitation of CVE-2023-34362 was responsible for the initial compromise and deployment of web shells as early as May 27. Huntress reported in their blog that they had one client affected.

Mandiant and Microsoft have both reported they believe there is a likelihood that the attacks are attributed to the Cl0p ransomware gang. Organizations that have been compromised can likely expect extortion communications to follow in the near future.

Palo Alto Networks Xpanse indicates there are at least 2,674 MOVEit servers exposing HTTP/HTTPs traffic. This does not include MOVEit Cloud servers. Progress has indicated that all MOVEit Cloud servers have been “patched and fully restored.”

Exploit in the Wild

MOVEit is managed file transfer software that encrypts files and uses file transfer protocols such as FTP or SFTP to transfer data. It also provides automation services, analytics and failover options.

In MOVEit, packages are used to ensure the secure and controlled exchange of sensitive information. A package refers to a container or envelope that holds files and data to be securely transferred between parties.

For guest users, MOVEit provides one-time use scenarios. Guest users can send, view, download, replay and receive packages.

A guest user must register as a guest by making a request to the /human.aspx component and providing their email address along with the email addresses of the data package receivers. This request will eventually be redirected to the /guestaccess.aspx component, automatically creating an email template with the sender and recipients' email addresses. Then the guest user can use this email template to send data packages.

The SQL injection happens due to the failure to sanitize the input data in the component /moveitsapi/moveitisapi.dll, which provides file transfer functions related to the MOVEit API.

Figure 2 depicts how a guest user can update the value of the session variable by sending a request to /moveitisapi/moveitisapi.dll endpoint with the following criteria:

  • HTTP parameter action=m2,
  • HTTP request header x-silock-transaction: folder_add_by_path and x-silock-transaction: session_setrvars

The updated session variables will allow an attacker to update the recipient's email address with SQL injection characters.

Image 1 is a screenshot of many lines of code. It is the MOVEit SQL injection exploit as found in the wild. Some information has been redacted.
Figure 1. MOVEit SQL injection exploit in the wild.

Attack Traffic Trend (June-September 2023)

Progress Community released a patch for CVE-2023-34362 on June 16, 2023, and the patch for CVE-2023-36934 on July 6, 2023.

Technical analysis of the patch diff, which is a file recording changes between two versions of a file, became public around July 11, 2023. After that point, the attack numbers started increasing, with the peak value of 1,639 on July 29. Figure 3 shows the attack traffic from June through September.

Image 2 is a trend graph of the MOVEit vulnerability exploit. It shows the attack count and begins June 25, 2023 and continues to September 3, 2023. The peak amount is in July.
Figure 2. MOVEit vulnerability exploit trend.

Interim Guidance

Below is a summary of the mitigations that Progress Software recommends. Please refer to the linked blog for a detailed list and explanation of the mitigation process.

  1. Disable all HTTP and HTTPs traffic to the MOVEit Transfer host.
  2. Review, delete and reset any unauthorized files and user accounts.
  3. Apply the relevant patch.
  4. Verify all malicious files and user accounts have been deleted/reset.
    1. Reset the service account credentials again.
  5. Re-enable all HTTP and HTTPs traffic to the MOVEit Transfer environment
  6. Continually monitor network, endpoints and logs for IoCs reported in relation to the current campaign.

The Unit 42 team also recommends that any organization that did have the MOVEit Transfer web interface exposed should assume it has been potentially compromised. We strongly recommend that affected organizations perform a forensic analysis of the server to ensure it was not compromised.

Update: On June 15, in response to a newly reported SQLi vulnerability, Progress Software updated their guidance to say, “We took HTTPs traffic down for MOVEit Cloud in light of the newly published vulnerability and asked all MOVEit Transfer customers to take down their HTTP and HTTPs traffic to safeguard their environments while a patch was created and tested.”

Unit 42 Managed Threat Hunting Queries

The Unit 42 Managed Threat Hunting team continues to track any attempts to exploit this CVE across our customers, using Cortex XDR and the XQL queries below. Cortex XDR customers can also use these XQL queries to search for signs of exploitation.

Conclusion

Although the number of exposed servers is relatively small, Unit 42 recommends organizations using MOVEit Transfer follow Progress Software’s mitigation guidance immediately. There are already reports of CVE-2023-34362 being exploited in the wild and there will likely be reports of more organizations who are affected in the near future.

The additional disclosures of CVE-2023-35036 and CVE-2023-35708 should also be monitored by organizations. 

Unit 42 continues to track the vulnerabilities in MOVEit Transfer and will update this brief as more information becomes available.

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

Palo Alto Networks Product Protections for MOVEit Transfer Vulnerabilities

Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat.

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

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

Next-Generation Firewalls and Prisma Access With Advanced Threat Prevention

  • Next-Generation Firewall with the Advanced Threat Prevention security subscription can help block the associated web shell via the following Threat Prevention signature: 81868, 83243
  • Next-Generation Firewall with the Advanced Threat Prevention security subscription can help block the attacks with Best Practices via Threat Prevention signatures: 93976, 93977

Advanced Threat Prevention for SQL Injection

Inline Cloud Analysis included in Advanced Threat Prevention's Vulnerability Prevention possesses the capability to detect SQL/command injection attack patterns within HTTP traffic, including HTTP URI header and body. Instead of manually crafting signatures for every individual SQL injection syntax variant, Advanced Threat Prevention extracts the crucial elements from SQL injection syntax and assembles a machine-learning model of the detection.

Figure 4 depicts the data flow of the Advanced Threat Prevention SQL injection detection model.

Image 3 is a diagram of the data flow when using SQL injection detection in Advanced Threat Prevention. The cloud contains machine learning detection modules. Suspicious traffic and verdicts flow through the ML modules. The Next-Generation Firewall blocks malicious verdicts as HTTP traffic and outbound traffic flow through the firewall itself.
Figure 3. Advanced Threat Prevention overview.

Cloud-Delivered Security Services for the Next-Generation Firewall

Known IoCs are marked as malicious by Advanced URL Filtering.

Cortex XSOAR

Cortex XSOAR has released a response pack and playbook for CVE-2023-34362 to help automate and speed the mitigation process.

This playbook automates the following tasks:

  • Collection of all relevant IoCs and detection signatures
  • Running investigation queries to detect possible exploitation attempts
  • Blocking IoCs
  • Following the mitigation published for this vulnerability

Cortex XDR and XSIAM

Cortex XDR and XSIAM agents help protect against post-exploitation activities described in this blog using Behavioral Threat Protection, Anti-Webshell Protection and multiple additional security modules. Additionally, Cortex Analytics has multiple detection models that help detect post-exploitation activities, with other relevant coverage by the Identity Analytics and Identity Threat Detection and Response (ITDR) modules.

Cortex Xpanse

Cortex Xpanse customers can identify external facing instances of the application through the “MOVEit Transfer” attack surface rule. The rule is available to all customers with a default state of “On.” Prisma Cloud WAAS customers are protected from this threat through the App Firewall SQL Injection protection.

Image 4 is a screenshot of Attack Surface Rules in Cortex Expanse. The columns are status, name, severity, description, remediation guidance, among others. Highlighted is MOVEit Transfer in the name column, description column and rendition guidance column.
Figure 4. A screenshot of the Cortex Xpanse interface, showing the MOVEit Transfer rule enabled.

Indicators of Compromise

Paths:

  • D:\MOVEitDMZ\wwwroot\human2.aspx
  • E:\MOVEitTransfer\wwwroot\human2.aspx
  • C:\Windows\Temp\erymbsqv\erymbsqv.dll

human2.aspx

  • c82059564d6e7a6f56d3b1597cdfe98dfc4e30a2050024bd744f12a3ef237bb5
  • 24c7fae1b7c02ebd84cc3c78553fb3a68d0466575abea4c92b2f792b47c41ef3
  • de4ad0052c273649e0aca573e30c55576f5c1de7d144d1d27b5d4808b99619cd
  • 7a8f53c4143bacd2104ccd07a6be68d76cda1a6985b8573b7735858a542178bb
  • 87ebfaf36fc7031bec477c70a86cb746811264f530d8af419767b9755e2b43e3
  • 3ff0719da7991a38f508e72e32412a1ee498241bf84f65e973d6e93dc8fd1f66
  • f994063b9fea6e4b401ee542f6b6d8d6d3b9e5082b5313adbd02c55dc6b4feb7
  • bd45234763ef62f05d14b78c6497ed90706a271fad3b16a4ee6d99d178beedf3
  • 3ff0719da7991a38f508e72e32412a1ee498241bf84f65e973d6e93dc8fd1f66
  • f994063b9fea6e4b401ee542f6b6d8d6d3b9e5082b5313adbd02c55dc6b4feb7
  • ba2cf96fc5884cd69ecfe5d73f872958159a12b02ca610223f089ee0b6c3d25d
  • 6e1d3b5fcb4de48e1e06a68686817d13533f9740e315f4378bb5b9ef1fd1c7a9
  • 2931994f3bde59c3d9da53e0062e4d993dc6fc655a1bd325e90af6dc494ed1fa
  • f3543cd16de13214124bd7c91033c3cd3bbcf6587871257e699fd89df96fd86f

VirusTotal Livehunt human2.aspx and h2.aspx

  • e8012a15b6f6b404a33f293205b602ece486d01337b8b3ec331cd99ccadb562e
  • 2413b5d0750c23b07999ec33a5b4930be224b661aaf290a0118db803f31acbc5
  • d477ec94e522b8d741f46b2c00291da05c72d21c359244ccb1c211c12b635899
  • 929bf317a41b187cf17f6958c5364f9c5352003edca78a75ee33b43894876c62
  • b9a0baf82feb08e42fa6ca53e9ec379e79fbe8362a7dac6150eb39c2d33d94ad
  • 4359aead416b1b2df8ad9e53c497806403a2253b7e13c03317fc08ad3b0b95bf
  • ea433739fb708f5d25c937925e499c8d2228bf245653ee89a6f3d26a5fd00b7a
  • d49cf23d83b2743c573ba383bf6f3c28da41ac5f745cde41ef8cd1344528c195
  • 387cee566aedbafa8c114ed1c6b98d8b9b65e9f178cf2f6ae2f5ac441082747a
  • a1269294254e958e0e58fc0fe887ebbc4201d5c266557f09c3f37542bd6d53d7
  • cf23ea0d63b4c4c348865cefd70c35727ea8c82ba86d56635e488d816e60ea45
  • f0d85b65b9f6942c75271209138ab24a73da29a06bc6cc4faeddcb825058c09d
  • c77438e8657518221613fbce451c664a75f05beea2184a3ae67f30ea71d34f37
  • daaa102d82550f97642887514093c98ccd51735e025995c2cc14718330a856f4
  • 3ab73ea9aebf271e5f3ed701286701d0be688bf7ad4fb276cb4fbe35c8af8409
  • 93137272f3654d56b9ce63bec2e40dd816c82fb6bad9985bed477f17999a47db
  • 5b566de1aa4b2f79f579cdac6283b33e98fdc8c1cfa6211a787f8156848d67ff
  • 3a977446ed70b02864ef8cfa3135d8b134c93ef868a4cc0aa5d3c2a74545725b
  • 348e435196dd795e1ec31169bd111c7ec964e5a6ab525a562b17f10de0ab031d
  • 0ea05169d111415903a1098110c34cdbbd390c23016cd4e179dd9ef507104495
  • 9d1723777de67bc7e11678db800d2a32de3bcd6c40a629cd165e3f7bbace8ead
  • b1c299a9fe6076f370178de7b808f36135df16c4e438ef6453a39565ff2ec272
  • 9e89d9f045664996067a05610ea2b0ad4f7f502f73d84321fb07861348fdc24a
  • 6015fed13c5510bbb89b0a5302c8b95a5b811982ff6de9930725c4630ec4011d
  • fe5f8388ccea7c548d587d1e2843921c038a9f4ddad3cb03f3aa8a45c29c6a2f
  • 702421bcee1785d93271d311f0203da34cc936317e299575b06503945a6ea1e0
  • c56bcb513248885673645ff1df44d3661a75cfacdce485535da898aa9ba320d4
  • 3c0dbda8a5500367c22ca224919bfc87d725d890756222c8066933286f26494c
  • bdd4fa8e97e5e6eaaac8d6178f1cf4c324b9c59fc276fd6b368e811b327ccf8b

IPs:

  • 5.252.191[.]241
  • 5.252.191[.]103
  • 5.252.189[.]210
  • 5.252.189[.]130
  • 5.252.190[.]119
  • 5.252.190[.]100
  • 5.252.190[.]117
  • 5.252.191[.]31
  • 5.252.190[.]244
  • 165.227.147[.]215
  • 209.97.137[.]33

User Agents:

  • Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/113.0.0.0+Safari/537.36
  • Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64;+rv:109.0)+Gecko/20100101+Firefox/114.0
  • Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/105.0.5195.54+Safari/537.36

Updated June 15, 2023, at 2:42 p.m. PT to add preliminary details of the newly reported SQLi vulnerability.

Updated June 16, 2023, at 5:24 a.m. PT to add additional details on Unit 42 Incident Response cases, as well as details of Progress Software's recommended mitigations. 

Updated June 16, 2023, at 11:33 a.m. PT to add additional CVE information for CVE-2023-35036 and CVE-2023-35708, as well as updated protections for Next-Generation Firewall. New data from Cortex Xpanse was added.

Updated July 7, 2023, at 2:20 p.m. PT to add additional information regarding CVE-2023-36934, CVE-2023-36932 and CVE-2023-36933. 

Updated July 7, 2023, at 2:20 p.m. PT to add additional information regarding CVE-2023-36934, CVE-2023-36932 and CVE-2023-36933. 

Updated October 4, 2023, at 6:00 a.m. PT to add additional information on Advanced Threat Prevention for SQL injection as well as new data. 

CL0P Seeds ^_- Gotta Catch Em All!

Posted on by Jeff White

Executive Summary

The CL0P ransomware group recently began using torrents to distribute victim data after a successful campaign stealing data from thousands of companies. We’ll cover the reason for this shift in methodology and what this means for visibility to the outside world.

CL0P has been one of the ransomware groups most actively posting data about their victims on leak sites tracked by Unit 42 (second only to LockBit in 2023). Unit 42 consultants have recently observed CL0P in about 10 incident response cases.

CL0P’s torrent seed infrastructure provides a unique opportunity for us to peer into the direct workings of a notorious ransomware group and provide insights into their trade craft. By analyzing the existing torrent seed infrastructure that hosts the stolen data, we can get a better view into what the implications of this change are.

To protect the victims of this attack, and to have a little fun with one of our favorite fandoms, we’ve swapped the organizations’ names for those of Pokémon.

Palo Alto Networks customers receive protection from CL0P ransomware and other malware through Cortex XDR. Palo Alto Networks customers receive protections from and mitigations for the recent MOVEit vulnerabilities in the following ways:

  • Cortex XDR and XSIAM agents help protect against post-exploitation activities associated with the MOVEit vulnerabilities using Behavioral Threat Protection, Anti-Webshell Protection and multiple additional security modules.
  • Cortex Xpanse customers can identify external facing instances of the application through the “MOVEit Transfer” attack surface rule.
  • Organizations can engage the Unit 42 Incident Response team for specific assistance with this threat and others.

Related Unit 42 Topics Ransomware, CL0P, Linux

History of CL0P and the MOVEit Transfer Vulnerability

At the end of May 2023, a software product by Progress called MOVEit was the target of a zero-day vulnerability leveraged by the CL0P ransomware group.

CL0P has taken credit for exploiting the MOVEit transfer vulnerability. The U.S. Cybersecurity and Infrastructure Agency (CISA) estimated TA505, a group known for leveraging Cl0p ransomware, has more than 3,000 U.S.-based organizations and 8,000 global organizations victims.

This is old news, but what happened next was quite interesting. To give a little background, CL0P emerged in early 2019 and quickly became notorious for employing extortion tactics against victims to increase the pressure to pay the ransom. They steal the data and release snippets of it. The idea here is that the victim would rather pay than risk having their data exposed globally, which could be more damaging than any traditional ransomware activity.

This data is then posted on a “leak site,” as shown in Figure 1, which is served via the Onion router (Tor) network. Doing so allows CL0P to remain relatively anonymous behind this service. (Note that not all the suspected victims of mass exploitation are listed on the leak site.)

Image 1 is a screenshot of the CL0P ransomware group leak site’s archives. Most of the information on the page is redacted. Included in the menu are buttons for Home, How to download? Archive, archive 2, archive 4, archive 5, archive 3.
Figure 1. CL0P leak site (archives).

If you’ve ever done anything with the Tor browser in the past, you likely noticed almost immediately just how slow everything was. You’re effectively sacrificing latency and throughput for anonymity. While this has improved significantly in recent years, attempting to download data from the leak sites can still prove to be a challenge simply because of the transfer speeds.

But what happens to download speeds when you’ve stolen data from literally thousands of companies? All of a sudden you go from trying to offer up comparatively smaller amounts of data to offering an amount of data that probably forced the individuals behind CL0P to run out and load up on hard drives like they were going out of style.

Threat actors have stolen and leaked terabytes upon terabytes of data already, and a dizzying amount of data is expected to continue to drop. It’s an amount of data that hasn’t been seen before with this type of activity. Unexpectedly, this almost benefits the victims, because it can be impractical to acquire some of the leaks over the Onion network. Why pay a ransom when no one will even be able to download the stolen data?

Thus, CL0P changed their tactics to address this new data access problem. They posted on their leak site (as shown in Figure 2) that as of Aug. 15, 2023, they will begin publishing the stolen data through a number of new methods, including torrents. This method leverages peer-to-peer file exchange, significantly speeding up the download process.

Image 2 is a screenshot of an announcement. In red text: Now we post many company name and proof we have their secrets and data. Some company do not speed to us and decide to stay quiet. We are very reasonable operators and when right situation we offer deep discount to block you data from being sold and publish. Advice you to contact us and begin discussion on how to block publicate of data. On 15 August we start publishing of every company on list that do not contact. You data is going to publishing on clearweb and Tor and for large company we also create clearweb URL to help Google index you data. Also all data go on torrent and speed of download very quick. You not hiding more. In green text: Dear users, now it has become available how to download data via torrent network, in detail on the site. There is an onion link.
Figure 2. Announcement of the change to data publication.

To that end, the threat actors made good on their claim and created a new leak site (shown in Figure 3) that had magnet links, which are hyperlinks that include a hash of the file. Most torrent clients could use these links to download the data.

Each day threat actors have steadily released a new set of victims’ data via this method when the victims have refused to pay their extortion amount.

Image 3 is a screenshot of the CL0P leak site. Some information has been redacted. It gives instructions on how to download leak data via torrenting. Step 1: download and install free utorrent client (if you don't already have it) [link to utorrent download page] or any other torrent client that you prefer. Step two : run utorrent and select file > add a torrent from URL. Utorrent file menu is displayed. Highlighted in red is add torrent from URL. Paste magnet URI to the Add torrent from URL dialog box and click OK button. Screenshot of add torrent from URL popup from utorrent. Please enter the location of the .torrent you want to open. OK button. Cancel button.
Figure 3. CL0P leak site (magnet).
Instead of trying to download a 128 GB ZIP file over the Onion network that could take days or even weeks to obtain, people can now download them at much more reasonable speeds. Thus the pressure is back on the victims to pay.

There is a problem with torrents though, which is that the data has to be seeded initially, so that you can bootstrap the download speeds for everyone else. This gives us a unique opportunity to get some insight into CL0P operations by identifying and analyzing the initial seeds for these torrents. This identification process will be the primary focus of this blog.

The Torrents

Before diving into the analysis aspect, it would be helpful to review some concepts of torrenting and how it functions.

There are two types of “torrents” you should know about. There is the usual torrent file itself, which most people are familiar with, and the magnet links. A torrent file will include a piece of information about a tracker, and when you join the torrent, you will announce yourself to the tracker.

This tracker then will share peering information to the clients, so they can periodically receive updates about other peers who might have pieces of the data they are trying to download. This allows the peers to rapidly connect to multiple other peers and begin exchanging the data at a higher rate.

Trackers are great for normal exchanges, but they may not be the best for operational security because they provide a list of the peers.

Magnet links are similar to a torrent file, but they typically do not have any tracker-related information. Instead, when a client loads a magnet link, it will contain a hash calculated from a number of facets of the file, which is used to uniquely identify the data the torrent represents.

This trackerless torrent works by connecting to one of the distributed hash table (DHT) nodes and effectively asking that node what peers it knows about, so you have someone to begin exchanging information with. This process is shown below in Figure 4.

Image 4 is a diagram of the tormenting process comparing the use of trackers to magnet links. Though both begin via separate methods, the two result in exchanging data at a higher rate.
Figure 4. The torrenting process, comparing the use of trackers to magnet links.

These peers can then exchange information about other peers they know about, and they can begin building out the web of connections that will eventually speed up the download process.

This decentralized approach is what CL0P has chosen for their data distribution.

The Plan

Of course, this trackability is not news to anyone who has ever used BitTorrent before. Authorities, law firms and others have used this mechanism to track peers connecting to torrents for piracy-related activities for years.

You might remember in the late 1990s when the Recording Industry Association of America (RIAA) took legal action against Napster. What followed was years of individuals being sued for participating in these peering exchanges because these organizations could identify the IP addresses of the connected peers.

So what makes this any different? The main differentiating factor here is that we’re not dealing with one torrent for one stolen movie, but hundreds of individual torrents. These torrents each require an initial seed for peers to connect to, to begin downloading and exchanging the data. This creates a window of opportunity wherein only one peer will have 100% of the file while the rest of the peers are downloading the pieces of it.

The name of the game with identification is speed, and two factors play into this. First, the speed in which you can join this decentralized swarm. Second, the speed in which you peer with the initial 100% seeder.

Neither of these factors are terribly reliable when dealing with just one torrent. However, it paints a much different picture when you look at things from a 10,000 foot view with all the torrent data combined.

Admittedly, I was a little late to start this research and missed the first days of their announcements before I took an interest in it. This means that I joined the torrents later in their lifecycle and the resulting 100% peers are not as reliable as the original seeders. To counteract this effect, I looked at all the peers across the torrents as the threat actors released them and cross-referenced with the older torrents. This allowed me to see which ones are likely “real” seeders vs. other people who have downloaded the data.

Before moving on, I need to include just one quick caveat here. Many people download these data leaks for various reasons. Sometimes it’s for nefarious reasons such as credential harvesting, IP theft or further exploitation of the victim.

However, there are a number of other entities that download this data with good intentions. They use it to further help the victim or other organizations, or for research. While I cannot infer intent, I can at least compare the behavior of both groups of entities to understand what a “seeder” looks like versus someone downloading it for other reasons.

The Approach

Like I mentioned before, speed is essential. There is a small window of time to join a torrent and with each passing second the likelihood of finding the original seeder diminishes. To address this problem, I need to constantly monitor their leak sites for new announcements and then use the magnet link to begin the peering process.

Once connected to the torrent, I can sit in the swarm and monitor for peers until I find the first one displaying a 100% complete status. At this point, I log the information and remove myself from the swarm.

In an effort to protect the innocent, I have changed all the victim organization names to Pokémon, which also happens to align with the theme of trying to capture and collect all the seeders! Standard legal disclaimer: The listed organizations are not associated with Nintendo – we’re just big fans and enjoy a fun analogy.

When I’m connected to a torrent, this is what the ideal output will look like.

$ cat pikachu.out
Address Flags Done Down Up Client
81.19.135.21 DEHI 100.0 0.0 0.0
Transmission 3.00

This output should include the following:

  • IP address of the connected peer
  • Flags for the peer status
  • Percentage complete
  • Up/down speeds
  • Torrent client

In this case, the flags DEHI mean that:

  • I am (D)ownloading from the peer
  • Using an (E)ncrypted connection
  • I learned of the peer via a D(H)T node as opposed to peer exchange
  • The peer is an (I)ncoming connection

All this data is useful for analysis.

In this case, I was connected to a single peer that had 100% completion right after the announcement was made and thus I can reliably assume this is an original seeder. I’ll come back to this later and discuss this particular IP address at length.

These next two are examples of when I was late to the party and did not get enough reliable information to make any determinations with this data alone.

 

$ cat squirtle.out
Address Flags Done Down Up Client
5.62.43[.]184 D?EHI 0.0 0.0 0.0 µTorrent 3.6.0
85.12.61[.]195 TDHI 0.0 0.0 0.0 qBittorrent 4.5.4
96.241.165[.]117 TDHI 0.0 0.0 0.0 BitWombat 1.3.0.2
113.30.151[.]125 TD?EHI 0.0 0.0 0.0 BitTorrent 7.0.0
151.20.161[.]85 DEHI 100.0 0.0 0.0 Transmission 2.93
178.62.25[.]161 TDHI 0.0 0.0 0.0 qBittorrent 4.4.1
183.60.144[.]94 TDHI 0.0 0.0 0.0 libtorrent (Rasterbar) 2.0.7
187.170.4[.]251 DEHI 100.0 0.0 0.0 Transmission 2.93
192.142.226[.]133 D?EHI 0.0 0.0 0.0 µTorrent 3.6.0
195.94.15[.]255 D?EHI 0.0 0.0 0.0 µTorrent 3.6.0
223.109.147[.]211 TDHI 0.0 0.0 0.0 libtorrent (Rasterbar) 2.0.7
$ cat charmander.out
Address Flags Done Down Up Client
2003:ec:9711:2000:6576:cf7d:d597:cb42 TDEI 100.0 0.0 0.0 Transmission 4.03
2800:40:1a:7a1:cb7:dc6c:b8d1:9593 TDEH 100.0 0.0 0.0 qBittorrent 4.6.0
2a01:e0a:aa4:7b30:c87b:ad9b:7a44:2692 TDEH 0.0 0.0 0.0 qBittorrent 4.5.4
93.209.109[.]154 DEI 100.0 0.0 0.0 Transmission 4.03
162.120.136[.]148 TD?EH 0.0 0.0 0.0 µTorrent 3.6.0
190.210.32[.]85 DEHI 100.0 0.0 0.0 qBittorrent 4.6.0
198.44.136[.]216 TDEHI 100.0 0.0 0.0 qBittorrent 4.5.4

In both of these instances, there are multiple peers with 100% completion and so, on the surface, this information is useless. However, it becomes considerably less useless when you begin mapping out all the peers from hundreds of torrents.

Mapping Peers and Pokémon

What you end up with after linking some of these data points is a web of connections that we can visualize for better analysis.

Figure 5 is a diagram with many nodes. The blue nodes are the domain. The light yellow nodes are the IPv4 address. The green nodes are the string. The dark yellow nodes are the IPv6 address.
Figure 5. Peer mapping.

Figure 5 focuses on three different data points:

  • The address of the peer
  • The victim
  • The client observed as in use

From there, I connected each node based on the amount of observed data the peer had at the time of logging. Then I color-coded the links as shown in Figure 5, so the 100% links stand out. This allows for quick inspection to identify addresses, which fall into one of three categories:

  • A confirmed original seeder
  • A potential original seeder
  • Nonoriginal seeders

Looking at Charmander again you’ll note two gray lines pointing toward it. These are sub-100% links (I coded all the 100% links red). The blue links connect a peer to their observed client string, seen in Figure 6.

Image 6 is a diagram with many nodes. Red, blue and grey arrows connect the nodes from IP addresses to Pokemon. These include Weedle, Bulbasaur, Magikarp, Zubat, Snorlax, Drowzee, Caterpie, Jigglypuff and others.
Figure 6. Charmander peering.

By going through the process of adding each host, when we switch from looking at the victim to the peers, patterns start to appear that draw immediate attention and make me feel like Charlie from Always Sunny in Philadelphia conspiratorially drawing connections!

If a host has all 100% links but a low volume, such as only 2-4, then I consider them a potential seeder. If a host has all 100% links but a high volume, then I consider them just a potential original seeder. Any host who has any sub-100% links, I consider them a nonoriginal seeder.

Circling back to the previous IP address 81.19.135[.]21 (shown in Figure 7) we can see what a highly probable original seeder looks like.

Image 7 is a diagram with many nodes. From one central yellow node, many red arrows point outward to blue nodes. These are named after Pokemon and include Muk, Mew, Meowth, Snorlax among others.
Figure 7. An original seeder.

A highly probable original seed is characterized not only by having a high volume of 100% seeds, but also by being the only logged peer for a number of victims. Furthermore, patterns start to emerge between the clusters of peers.

For example, the majority of hosts that I believe are original seeders all use the Transmission 3.00 client string, further binding their activity together. Whereas a host with a relatively unique client string that isn’t observed much (like the one in Figure 8) makes me lean more toward them being an entity that is just downloading all the data for other reasons, and that they have completed their downloads.

Image 8 is a diagram with many nodes. Red arrows point from one IP address to blue nodes. These are named after Pokemon and include Nidorina, Voltorb, Paras, Abra and others.
Figure 8. Unlikely original seeder.

All this is to say that these data points allow me to then filter and weed out the less interesting peers quickly so that I can focus my attention on the ones that matter.

This individual shown in Figure 9 even changes their client string with every torrent. This adds weight to the supposition that they are not an original seeder, even though they were seeding a lot of the data by the time I peered with them.

Image 9 is a diagram with many nodes. Red arrows point from one IP address to blue nodes as well as yellow message-shaped icons. The blue nodes are named after Pokemon and include Abra, Mankey, Venonat and others.
Figure 9. Nonoriginal seeder.

By looking at the data and applying the above logic, I’m able to overcome some of the previous issues we discussed, where I hadn’t started collecting data until after they started releasing the torrents.

In total, I was able to identify five hosts that I believe have a high likelihood of being original seeders in this dataset, along with two that will likely become future seeders. This warranted a deeper dive.

Gotta Catch Em All!

Seed Group 1

One pattern that stood out almost immediately was that three of the IP addresses are seemingly on the same network.

  • 81.19.135[.]21
  • 81.19.135[.]25
  • 81.19.135[.]31

All three of these IP addresses exist within the same subnet on AS 209588 owned by FlyServers, which is a VPS hosting company. The IPs are geolocated to Moscow, Russia. Each exhibits interesting characteristics that further connect them together making a strong case for them being actor controlled.

For example, note the pattern shown in Figures 10 and 11, as it relates to SSH availability and FTP availability for the first two IP addresses:

Image 10 is a timeline comparing open ports 21 and 22 from March through August 2023. This is a service scan of an IP address. Port 21 is red. Port 22 is blue. Another port is purple.
Figure 10. 81.19.135[.]21 services scan.
Image 11 is the timeline of the open ports 21, 22, and 8423. The timeline goes from March through August 2023. Port 21 is red. Port 8423 is blue. Port 22 is purple.
Figure 11. 81.19.135[.]25 services scan.
For the IP ending in 21, SSH ports stopped responding on Aug. 6, 2023, and FTP ports started responding on Aug. 7, 2023. For the IP ending in 25, we see SSH stop on Aug. 6, 2023, and FTP open on the same day.

Similarly, for the IP ending in 31 shown in Figure 12, while we did not have visibility of SSH, we can see the FTP also opened up on August 6.

Image 12 is the timeline of open port 21. It is indicated by red. The timeline goes from March to August 2023.
Figure 12. 81.19.135[.]31 services scan.
The servers are running vsFTPd 3.0.3 and OpenSSH_8.4p1. The brief visibility on TCP/8423 for the IP ending in 25 reveals it transitioned to running SSH on a nonstandard port.

To confirm the seeding servers were different entities, as opposed to being the same box behind some sort of load-balancing service, I looked at the TLS certificates in use by vsFTPd. They were all self-signed:

  • 81.19.135[.]21 = 44102.example.ru, valid from Aug 06 2023 22:49:51 GMT-0400
  • 81.19.135[.]25 = 14868.example.ru, valid from Aug 05 2023 23:48:55 GMT-0400
  • 81.19.135[.]31 = 33916.example.ru, valid from Aug 05 2023 23:48:08 GMT-0400

I included the initial date for the certificate. As you can see, they are roughly an hour apart from each other. This implies that CL0P was prestaging these boxes about 10 days before they planned to release their first magnet links and five days before they publicly announced their intention to shift to this distribution method.

Using these patterns, I extended my search for certificates with an example.ru in their Common Name (CN) value that were observed to have FTP. I identified another host on this same subnet (shown in Figure 13) that exhibits similar features but has not yet shown up in the peering information.

Image 13 is a screenshot of IP addresses.
Figure 13. Wider net identifying new host ending with 11.

You can see the same behavior where visibility is lost on the SSH port on Aug. 6, 2023, and the FTP port becomes active on Aug. 7, 2023. This aligns with the rest of what we’ve observed.

  • 81.19.135[.]11 = 43577.example.ru, valid from Aug 06 2023 23:03:31 GMT-0400

Also notable on this host is the presence of Windows services two months earlier, as shown in Figure 14. This implies that the VPS was repurposed from Windows to a *nix-based machine within that time frame.

Image 14 is a timeline of open ports. Port 21 is red. Port 22 is blue. Port 137 is purple. Port 3389 is orange. Port 5985 is yellow. The longest a port was open was blue from March through August 2023. The other ports were open partially through May through July.
Figure 14. 81.19.135[.]11 services scan.
There is a lot of orchestration required to effectively host as much data as they’ve stolen. It might be that the IP address ending in 11 is being prepped to host further victim files.

The two IP addresses ending in 25 and 31 have victims that were announced early in the release process, either on August 15 or a few days after. Whereas the IP address ending with 21 started to get usage on victim announcements beginning on August 24, and it has almost four times the number of observed victims as the others. This could just be a result of my ability to observe them, but it could also imply something is different about this box.

Seed Group 2

Another IP that stands out was also mentioned by Gary Warner on LinkedIn, who was looking at the same type of information regarding CL0P seeds. Below is a snippet from his post:

After Cl0p decided that no one was able to download their stolen data via .onion servers, they migrated to using bitTorrent.

Of course the problem with using bitTorrent, is that it becomes painfully obvious where the bad guys are hosting the stolen data. If one accesses the TORRENT and there is only one IP address offering 100% of the data, for the LARGER data sets, that is almost certainly hosting that the criminal acquired to serve the file from. (Not true for the tiny data sets -- for those the criminal can wait a short time for others to have 100% of the file and then disconnect their original location.)

Currently the main locations for "100%" sets are:

95.215.0[.]76 = AS34665 Petersburg Internet, St. Petersburg Russia

(hosting company offerings at pindc[.]ru)

I believe Highlander rules apply here and we might have to battle in a Pokémon gym later!

This IP address 95.215.0[.]76, shown in Figure 15, shares some similarities with the previous cluster. Specifically the usage of a BitTorrent client with the string Transmission 3.00 was in use, and the hosting provider is another Russian company.

Image 15 is a diagram with many nodes. Red arrows and blue arrows leading from IP addresses point to other nodes or yellow messenger icons. The blue nodes are named after Pokemon and include Hitmonlee, Machop, Kadabra and more.
Figure 15. Another confirmed original seeding server.

Sure enough, this seeding server (shown in Figure 16) exhibits behavior akin to the other cluster as it relates to services as well. However, the activity occurs almost a month before the other cluster. SSH services were observed up until July 17 and FTP services began appearing on July 18.

Image 16 is a timeline of open ports from March to August of 2023. Port 21 is indicated by red. Port 123 is indicated by blue. Port 22 is indicated by purple.
Figure 16. 95.215.0[.]76 services scan.
This is presumably an older box, and it also uses a different set of services to host FTP, leveraging ProFTPD. Likewise, the VPS is hosted in Saint Petersburg, Russia and it is announced from AS 34665 for Petersburg Internet Network (PIN) Datacenter.

This IP shares the below SSH Key with the IP address 95.215.1[.]221.

ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNos5CNsQHUKlXJSFDJKtPB/4FlkqW6R0crEQaONn3TJ2TICxQRUTh8DgITlLcidJf0pnn0zVMWwE6PsWDI3eZU=

While I have not yet observed this IP address as a peer in my collection, I don’t know whether this is due to a visibility issue or that the box has yet to be used for hosting. It does share the same notable behavior with SSH and FTP, as shown in Figure 17.

Image 17 is a timeline of open ports from March to August of 2023. Port 21 is indicated by red. Port 123 is indicated by blue. Port 22 is indicated by purple.
Figure 17. 95.215.1[.]221 services scan.

Seed Group 3

Applying these patterns to the other peers I’ve collected, the IP address 92.118.36[.]111 shown in Figure 18 stands out.

Image 18 is a closeup of a diagram showing a single seed host. From the center yellow icon, a red arrow points to the blue icon of Articuno. A blue arrow points to transmission 3.00.
Figure 18. Single seed host.

In this case, I’ve only observed it seeding a single torrent for Articuno at 100%. It’s located in Amsterdam, announced from AS 209132 for StreamHost.

Where this torrent aligns is that it uses the Transmission 3.00 client string, and it has similar FTP access beginning on August 9 (as shown in Figure 19).

Image 19 is a timeline of open ports from March to August of 2023. Port 21 is indicated by red. Port 123 is indicated by blue.
Figure 19. 92.118.36[.]111 services scan.
One last note I’ll make is that while searching for this IP address, I stumbled across an AbuseIPDB report for the next IP ending in 112, shown in Figure 20. It showed a report of this address scanning for the MOVEit vulnerability in early June 2023, which is the vulnerability CL0P leveraged to steal all this data.

Image 20 is a screenshot of abuse reports for IP address 92.118.36[.]112. This IP address has been reported a total of 203 times from 5 distinct sources. 92.118.36[.]112 was first reported on November 15, 2022, and the most recent report was two months ago. Old reports: the most recent abuse report for this IP addresses from two months ago. It is possible that this IP address is no longer involved in abusive activities. There's a table that includes the reporter, the date, the comment, and the categories. These the reporter is from America and their username is AdamCySec, the date is 06 June 2023, the comment is MOVEit vulnerability scanning, and the category is hacking.
Figure 20. AbuseIPDB report on 92.118.36[.]112.
Whether this is related or not is unknown, but it’s an interesting coincidence if not.

Conclusion

By tracking and analyzing these types of shifts in leak site methodology, it gives us a unique insight into what a threat actor's mindset could be. By understanding the problem they face and how they are trying to solve it, it provides us with an opportunity for further analysis and research.

In this case, the result of this research is a handful of hosting servers out of Russia that hold enormous amounts of stolen victim data. We can expect much more to come in the following weeks.

Seed boxes are always worth keeping an eye on. When the adversary's mind is focused elsewhere, it’s a ripe environment for mistakes that lead to leaving us vital clues.

As for their trade craft, we know these threat actors are likely leveraging FTP to transfer the stolen files to the seed boxes. We also know that general visibility of SSH access shuts off immediately prior to the FTP services going live. This could mean multiple things, but top of mind is that they are likely prestaging the stolen data on the servers for quite some time before they make the announcement of the magnet link.

Likewise, the distribution of victim data across the seed boxes does not align with their announcement schedule. This would add weight to the theory that the data has persisted on the box for a while prior to the torrent’s creation. This could potentially be a technique they use to avoid seed tracking by having different victims announced at the same time yet seeded from different boxes.

Before I sign off, I want to provide some additional observations of the collected data as it stands on Aug. 30, 15 days after this activity began.

The total number of original seeders is five.

  • 81.19.135[.]21 (20 observed victims)
  • 81.19.135[.]25 (5 observed victims)
  • 81.19.135[.]31 (6 observed victims)
  • 95.215.0[.]76 (9 observed victims)
  • 92.118.36[.]111 (1 observed victim)

The total number of unobserved but likely seeders is two.

  • 81.19.135[.]11
  • 95.215.1[.]221

The total number of magnet links (each a victim): 192

The total number of successful 100% peering logs: 146

The total number of peers I connected with: 115

The top five peering clients for seeders are as follows:

  • qBittorrent 4.5.4 (9)
  • Transmission 3.00 (7)
  • qBittorrent 4.4.1 (4)
  • Transmission 2.9.3 (4)
  • µTorrent 3.6.0 (4)

Figure 21 shows the distribution of peers, which is fairly global.

Image 21 is a map of the peer distribution. Green dots represent activity location. Locations include Europe, the United States, Melbourne Australia, and some locations across Asia and Southeast Asia, among others.
Figure 21. Geographic peer distribution.

While I was not able to obtain all the file meta data before identifying a 100% seed and disconnecting, I did collect stats on what I observed.

In total, I received file data of just 41 of the victims (less than one-third of what I observed) totaling over 1.1 TB of data. The highest total file size I observed for any one victim was 127 GB with the low end being 2.8 MB and an average of 31 GB per victim.

There are many more victims to be released, and CL0P has remained relatively consistent in their release of their data, making good on all their threats. Additionally, some torrents for “well-known Pokémon” (in this analogy) were much more popular than others. Companies need to be aware that even if they do not pay the ransom, their data is a hot commodity for numerous reasons. None of those reasons are likely to be in their best interest.

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

Protections and Mitigations

Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat.

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

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

Cortex XDR and XSIAM

Palo Alto Networks customers receive protection from CL0P ransomware and other malware through Cortex XDR. Cortex XDR and XSIAM agents also help protect against post-exploitation activities associated with the MOVEit vulnerability using Behavioral Threat Protection, Anti-Webshell Protection and multiple additional security modules.

Additionally, Cortex Analytics has multiple detection models that help detect post-exploitation activities, with other relevant coverage by the Identity Analytics and Identity Threat Detection and Response (ITDR) modules.

Cortex Xpanse

Cortex Xpanse customers can identify external facing instances of the application through the “MOVEit Transfer” attack surface rule. The rule is available to all customers with a default state of “On.”

Cortex Xpanse has also released a new event in our Threat Response Center focused on the management of MOVEit exposures and additional remediation guidance and threat details related to MOVEit Transfer.

All Cortex Xpanse detection capabilities are also available for XSIAM customers who also have the ASM module.

Updated Jan. 11, 2024, at 11:34 a.m. PT.

Rare Backdoors Suspected to be Tied to Gelsemium APT Found in Targeted Attack in Southeast Asian Government

Posted on by Robert Falcone

Executive Summary

A cluster of threat actor activity that Unit 42 observed attacking a Southeast Asian government target could provide insight into a rarely seen, stealthy APT group known as Gelsemium.

We found this activity as part of an investigation into compromised environments within a Southeast Asian government. We identified the cluster as CL-STA-0046.

This unique cluster had activity spanning over six months between 2022-2023. It featured a combination of rare tools and techniques that the threat actor leveraged to gain a clandestine foothold and collect intelligence from sensitive IIS servers belonging to a government entity in Southeast Asia.

In addition to an array of web shells, the main backdoors used by the threat actor were OwlProxy and SessionManager. This combination, which was publicly documented once before in 2020, is rare and was previously used to target several entities in Laos.

Based on our analysis and available threat intelligence, we attribute CL-STA-0046 to the Gelsemium APT group, with a moderate level of confidence. The observations we describe here could provide a view into a threat group about which only a handful of public reports have been published to date.

According to research published by ESET, the Gelsemium APT group has been operational since at least 2014. It is recognized for its tendency to target a diverse range of entities, including governments, universities, electronics manufacturers and religious organizations, predominantly in East Asia and the Middle East.

Despite Gelsemium's long-standing presence in the threat landscape, limited information has been available about their tactics, techniques, and procedures (TTPs). Our analysis and description of this cluster of activities provides deep technical insights into the tools and strategies that this APT group might employ.

Additionally, we provide a documented timeline of the operations we observed, presenting a repository of indicators for defenders.

Palo Alto Networks customers receive protections against the threats discussed in this article through Advanced WildFire, Advanced URL Filtering, DNS Security, Cortex XDR and Cortex XSIAM, as detailed in the conclusion.

Organizations can engage the Unit 42 Incident Response team for specific assistance with this threat and others.

Related Unit 42 Topics Government, APTs

Timeline of Activity

Image 1 is a timeline of the activity of CL-STA-0046. The first wave starts in quarter three of 2022. The second and final wave starts in quarter four of 2022.
Figure 1. Timeline of CL-STA-0046.

CL-STA-0046 Details

Infection Vector

The threat actor behind CL-STA-0046 gained access to the environment after installing several web shells on a compromised web server. Among the types of web shells observed are the following:

  • reGeorg
  • China Chopper
  • AspxSpy web shell

One of the AspxSpy web shells that we saw the threat actor behind CL-STA-0046 use was reportedly used by Iron Taurus (aka APT 27) for operation Iron Tiger in 2015 (according to Trend Micro). However, this particular web shell is publicly available and could be used by any threat actor (and was therefore not included in our attribution consideration).

The attackers conducted additional activities using the web shells. They moved laterally via SMB and downloaded additional tools. Initially, the attackers performed basic reconnaissance commands such as ipconfig and whoami. Later, they used netscan and nbtscan to gather further information about the victim.

In some instances, we observed that the attackers started to deliver tools to the compromised server. The attackers used a “shell-like” tool named demo.exe to run additional commands, and they used the Potato Suite (JuicyPotato – j.exe, BadPotato and SweetPotato – ev.exe) to try to perform privilege escalation.

Installing Additional Tools and Malware

To gain a foothold in the environment, the attackers behind CL-STA-0046 downloaded several different tools. Some of these tools attackers rarely use, and when other researchers have observed attackers using them in the past, it was sophisticated APT groups.

We will describe the following tools we observed in further sections:

  • OwlProxy
  • SessionManager
  • Cobalt Strike
  • SpoolFool
  • EarthWorm

The attackers checked connectivity to the internet, as shown in Figure 2, by pinging www.qq[.]com. This site is a well-known Chinese web portal.

Image 2 is a tree diagram in Cortex XDR that splits into six branches. There are several alerts marking blocked actions for .exe files.
Figure 2. Process tree of Cobalt Strike, the Potato Suite, SpoolFool and EarthWorm.

SessionManager

During our investigation, there were several unsuccessful attempts to install a variant of the SessionManger IIS backdoor on a compromised web server. Cortex XDR blocked these attempts automatically.

SessionManager is a unique custom backdoor that allows its operators to run commands, as well as uploading files to and downloading them from the web server. This threat also allows attackers to use the web server as a proxy to communicate with additional systems on the network.

According to a Kaspersky blog published in June 2022, the Gelsemium APT group used SessionManager in compromises dating back to at least March 2021. Attackers specifically used it in government, nongovernment, military and industrial organizations.

The SessionManager sample we observed in CL-STA-0046 was designed to inspect all inbound HTTP requests and look for requests containing a specifically crafted Cookie field within the HTTP request.

The Cookie field would contain the actor’s desired command. SessionManager supports the following commands:

  • Uploading files to the server
  • Downloading files from the server
  • Running commands and applications
  • Proxying connections to additional systems

The proxy functionality offered by SessionManager suggests the actors wanted to use the server as an ingress point to communicate with other systems on the network.

OwlProxy Malware

Another unique and custom tool that attackers used was OwlProxy. OwlProxy is an HTTP proxy with backdoor functionality that was first discovered in April 2020 in an attack targeting the Taiwanese government. The attack, which was part of a campaign targeting governmental entities in East Asia and the Middle East, was attributed to Gelsemium.

The threat actor deployed an executable that saved an embedded DLL to c:\windows\system32\wmipd.dll and created a service named WMI Provider to run the DLL.

The wmipd.dll DLL is a variant of OwlProxy that differs slightly from those discussed in the April 2020 attacks in Taiwan. This variant of OwlProxy creates an HTTP service that will handle inbound HTTP requests to URLs based on the following UrlPrefix formats:

  • HTTPS://+:443/topics/
  • HTTPS://+:443/topics/pp/

The DLL checks incoming requests that match these URLs for s?pa= and s?pp= to run commands or to set up a proxy, respectively. Like the SessionManager tool, the proxy functionality within OwlProxy furthers the theme of the actors planning to use the server as a gateway to other systems on the network.

As part of CL-STA-0046 activities, the attackers tried to execute the OwProxy malware (named client.exe) but Cortex XDR prevented the execution. After being thwarted, the attackers tried using a replacement for the tool that is not necessarily malicious on its own, called EarthWorm.

Cobalt Strike

The attackers attempted to execute Artifactd.exe, as shown in Figure 2 above, which is a Cobalt Strike beacon configured to communicate with the command and control (C2) 27.124.26[.]83.

EarthWorm

EarthWorm is a publicly available SOCKS tunneler that, although initially created for research purposes, gained popularity among Chinese-speaking actors. For example, Kaspersky reported that APT 27 used EarthWorm in a campaign targeting Asian government entities.

The use of EarthWorm by the threat actor behind CL-STA-0046 occurred after the attackers failed to execute OwlProxy, and we assess that they delivered EarthWorm as a replacement.

As shown in Figure 2 above, the attackers used EarthWorm (ew.exe) to create a tunnel to their C2 traffic that was hosted on 27.124.26[.]86. This tunnel allowed the attackers to connect the local area network (LAN) of the infected network to their external C2. Figure 3 shows a screenshot of the EarthWorm website.

Page 3 is a screenshot of a portion of the EarthWorm website. ./ Earthworm. Link to English pages. Chinese characters. A link to the binary files on GitHub. A picture of an earthworm wearing a hat.
Figure 3. Screenshot from the EarthWorm website.

Using EarthWorm, the attackers sent and received data to and from their C2 server.

SpoolFool

In addition to using the Potato Suite mentioned above, the attackers also used another local privilege escalation (LPE) proof of concept (PoC) published on GitHub called SpoolFool, as shown in Figure 2 above. This tool exploits CVE-2022-21999 (Windows Print Spooler Elevation of Privilege Vulnerability).

The attackers used this tool to attempt to create a local administrator user (username admin with the default password Passw0rd!) using the following command.

Code snippet of command to add user.

Attribution

Unit 42 assesses with moderate confidence that the activity observed in CL-STA-0046 is associated with the Gelsemium APT group.

This assessment is based on the unique combination of malware that attackers used in CL-STA-0046, namely the SessionManager IIS backdoor and OwlProxy. At the time of writing this report, the only publicly available report about attackers using SessionManager and OwlProxy in conjunction is a report about the Gelsemium APT group.

In addition, there is a victimology overlap between CL-STA-0046 and Gelsemium. Researchers from ESET have reported that this threat group has targeted the government sector in Southeast Asia in the past.

Gelsemium has been in operation since 2014. Publicly available research reports that this group targets governments, and that they have been operating in Southeast Asia in the past. Although the researchers who first discovered Gelsemium did not attribute it to any specific state, the security firm Telsy and the Thai CERT consider this group to be operating from China. At the time of writing this report, Unit 42 cannot confirm these attribution claims.

Conclusion

CL-STA-0046 is one of three clusters that we observed targeting the government sector in a country in Southeast Asia. Unit 42 associates the activity observed by the threat actor behind CL-STA-0046 to the Gelsemium APT group with a moderate level of confidence.

As part of the activity we observed, the threat actor received access through the use of several web shells, following the attempted installation of multiple types of proxy malware and an IIS backdoor. As some of the threat actor's attempts to install malware were unsuccessful, they kept delivering new tools, showing their ability to adapt to the mitigation process.

The findings of this investigation highlight the urgent need for enhanced security measures, vigilant monitoring and proactive threat intelligence sharing among government entities and affected industries in Southeast Asia. By adopting a multilayered defense approach and staying informed about emerging threats, organizations can better protect themselves against the persistent and evolving tactics employed by threat actors such as Gelsemium.

Protections and Mitigations

For Palo Alto Networks customers, our products and services provide the following coverage associated with the threats described above:

  • WildFire cloud-based threat analysis service accurately identifies the known samples as malicious.
  • Advanced URL Filtering and DNS Security identify domains associated with this group as malicious.
  • Cortex XDR and XSIAM
    • Prevents the execution of known malicious malware
    • Prevents the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module
    • Protects against credential gathering tools and techniques using the new Credential Gathering Protection available from Cortex XDR 3.4
    • Protects from threat actors dropping and executing commands from web shells using Anti-Webshell Protection, newly released in Cortex XDR 3.4
    • Protects against exploitation of different vulnerabilities including ProxyShell and ProxyLogon using the Anti-Exploitation modules as well as Behavioral Threat Protection
    • Cortex XDR Pro detects postexploit activity, including credential-based attacks, with behavioral analytics

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

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

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

Indicators of Compromise

Web Shells

  • 24eb9c77448dda2d7cfecc60c804a378e89cbd450fbf7f4db875eb131cd4510a
  • 4dcdce3fd7f0ab80bc34b924ecaa640165ee49aa1a22179b3f580b2f74705dd9
  • 96bc4853d5a0c976fb7a02d747cd268fb2dfc8c2361d68bb4ffcc16adec5ea19
  • ac115bfa8d36cf31046b8ccce30e9ebcede899395d56400955f95e242d5c9c75
  • 17392669a04f17fda068d18ae5850d135f3912d08b4e2eee81fce915849887b3
  • 3be95477e1d9f3877b4355cff3fbcdd3589bb7f6349fd4ba6451e1e9d32b7fa6
  • 181feef51991b162bdff5d49bb7fd368d9ec2b535475b88bc197d70d73eef886
  • 61de79db5ed022ee9376e86a2094a51cf3b31fa6bce126cbcdacad33469c752f

The Potato Suite

  • c7bd78b9a68198b8787d28ba5094827eb99a0798719bcb140f3afb695925566c
  • fd0b9f09770685ed6f40ecabcd31bc467fa22801164b52fdc638334009b7c06f
  • 77e82c3d5fea369f6598339dcd97b73f670ff0ad373bf7fc3a2d8586f58d9d32
  • f0761ad307781bdf8da94765abd1a2041ac12a52c7fdde85f00b2b2cab6d6ce8
  • 29cc79a451f73bac43dbe9455d2184770beae69f4e6bc2d824abd2cfbedf53f1
  • 3268f269371a81dbdce8c4eedffd8817c1ec2eadec9ba4ab043cb779c2f8a5d2

Demo.exe

  • 527063cb9da5eec2e4b290019eaac5edd47ff3807fec74efa0f1b7ddf5a1b271

OwlProxy

  • 2f3abc59739b248ee26a575700eef93b18bd2029eb9f8123598ffdd81fa54d8b

SessionManager

  • b9a9e43e3d10cf6b5548b8be78e01dc0a034955b149a20e212a79a2cf7bee956

Cobalt Strike

  • ff7485d30279f78aba29326d9150b8c302294351e716ece77f4a3b890008e5fe

SpoolFool

  • c0a7a797f39b509fd2d895b5731e79b57b350b85b20be5a51c0a1bda19321bd0

EarthWorm

  • c254dc53b3cf9c7d81d92f4e060a5c44a4f51a228049fd1e2d90fafa9c0a44ee

Infrastructure

  • 27.124.26[.]83
  • 27.124.26[.]86

Additional Resources

Cyberespionage Attacks Against Southeast Asian Government Linked to Stately Taurus, Aka Mustang Panda

Posted on by Robert Falcone

Executive Summary

An advanced persistent threat (APT) group suspected with moderate-high confidence to be Stately Taurus engaged in a number of cyberespionage intrusions targeting a government in Southeast Asia. The intrusions took place from at least the second quarter of 2021 to the third quarter of 2023. Based on our observations and analysis, the attackers gathered and exfiltrated sensitive documents and other types of files from compromised networks.

We found this activity as part of an investigation into compromised environments within a Southeast Asian government. We identified this cluster of activity as CL-STA-0044.

Our analysis of this cluster of activity revealed attempts to establish a robust and enduring foothold within compromised networks and steal sensitive information related to individuals of interest working for the government.

With moderate-high confidence, we conclude that this activity is linked to the Chinese cyberespionage group Stately Taurus. This group is also known by several aliases, including Mustang Panda, BRONZE PRESIDENT, TA416, RedDelta and Earth Preta. Over the years, Unit 42 has observed the group gathering information on targets in and around the Southeast Asia region.

This attribution is underpinned by the utilization of distinctive, rare tools such as the ToneShell backdoor that have not been publicly documented in association with any other known threat actor.

Our description of this cluster of activity provides deep technical insights into the tools and approaches used by the APT. It also includes a timeline of activity that can help defenders obtain crucial information, which you can use to hunt for nation-state advanced persistent threats.

Palo Alto Networks customers receive protections against the threats discussed in this article through Advanced WildFire, Advanced URL Filtering, DNS Security, Cortex XDR and Cortex XSIAM, as detailed in the conclusion.

Organizations can engage the Unit 42 Incident Response team for specific assistance with this threat and others.

Related Unit 42 Topics Government, APTs
Stately Taurus akas Mustang Panda, BRONZE PRESIDENT, TA416, RedDelta and Earth Preta

Timeline of Activity

Image 1 is a timeline of the activity of CL-STA-0044. It starts in quarter 1 of 2021 and continues through quarters two, three and four of 2022, and quarters one through three of 2023.
Figure 1. Timeline of CL-STA-0044.

CL-STA-0044 Details

Reconnaissance

To better understand the breached networks, the threat actor behind CL-STA-0044 scanned infected environments to find live hosts and open ports, as well as existing domain users and domain groups.

We observed the adversary using several different tools to reach these goals:

  • LadonGo: LadonGo is an open-source scanning framework that Chinese-speaking developers created. The threat actor used LadonGo to scan for live hosts and open ports using commands like smbscan, pingscan and sshscan.
  • NBTScan: NBTScan is a program for scanning IP networks for NetBIOS name information.
  • AdFind: AdFind is a command-line query tool that can gather information from Active Directory. The threat actor renamed the tool a.logs.As shown in Figure 2, the threat actor saved the results of AdFind to the following filenames:
    • Domain_users_light.txt
    • Domain_computers_light.txt
    • Domain_groups_light.txt

These filenames have only been mentioned in a GitHub page about “Penetration Testing Methodology References.”

Image 2 is a screenshot of the Cortex XDR program. It is a diagram showing the prevention of AdFind attempts. Some information has been redacted.
Figure 2. Prevention of AdFind attempts to dump domain users’ details.
  • Impacket: The Impacket collection includes many tools with functions related to remote execution, Kerberos attacks, credential dumping and more. Figure 3 illustrates these commands. The threat actor used Impacket to gather information about the network, discover machines and users, and query directories on remote machines for interesting files to exfiltrate.
Image 3 is a screenshot of reconnaissance commands that were run via Impacket (Python modules). There are six commands in total and some of the information has been redacted.
Figure 3. Reconnaissance commands run via Impacket.

Credential Stealing

Unit 42 researchers observed the threat actor behind the CL-STA-0044 activity attempting to use several techniques for credential stealing to dump passwords from different hosts and the Active Directory:

  • Hdump: The threat actor deployed and used Hdump.exe (renamed h64.exe), which is a credential stealing utility that researchers have observed Chinese threat actors using. Threat actors used Hdump to dump credentials from memory using the -a (dump all) flag.

Figure 4 shows the help menu of Hdump:

Image 4 is a screenshot of Hdump commands. These options include items such as print, dump user hashes, dump cache hashes and the like.
Figure 4. Hdump help menu.
  • MimiKatz: The threat actor attempted to dump the memory of lssas.exe several times, using the credential harvesting tool MimiKatz (named l.doc) to extract users’ credentials.
  • DCSync: The threat actor attempted to use MimiKatz’s DCSync feature, which enables attackers to simulate a domain controller (DC), in the victim’s network to retrieve user credentials from the legitimate DC. They then saved the collected information to a file named log.txt.
Image 5 is a screenshot of the DCSync command. Some of the information has been redacted.
Figure 5. DCSync command.
  • Stealing the Ntds.dit File: To steal Active Directory data, the threat actor used the Vssadmin tool to create a volume shadow copy of the C:\ drive on the DC. They then retrieved the Ntds.dit file from the shadow copy, as shown in Figure 6.

The Ntds.dit file is a database that stores Active Directory data, including information about user objects, groups, group membership and (most importantly) password hashes.

The threat actor also stole the SYSTEM file containing the boot key. This key is necessary to decrypt the Ntds.dit file.

Image 6 is a screenshot of commands used to steal the Ntds.dit file. There are four lines in total and some of the information has been redacted.
Figure 6. Stealing the Ntds.dit file.

Abusing Existing Antivirus Software

We observed the threat actor behind the CL-STA-0044 activity abusing existing antivirus software in compromised environments. We spotted threat actors abusing ESET’s Remote Administrator Agent to execute commands on remote hosts and to install backdoors.

They used the process ERAAgent.exe to execute BAT files with a naming pattern of C:\Windows\Temp\ra-run-command-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.bat (where xxx is replaced with random numbers and characters).

These .bat files executed reconnaissance commands and wrote additional backdoors to the disk, as shown in Figure 7. The files appear to be responsible for executing commands initiated by ESET’s Run Command task.

 

Image 7 is a screenshot of a tree diagram in Cortex XDR. Suspicious activity has been blocked. Some of the information has been redacted.
Figure 7. Blocked suspicious behavior performed by ERAAgent.exe.

Maintaining Access: Web Shells and Backdoors

During this campaign, the threat actor behind CL-STA-0044 used several methods to maintain a foothold in compromised environments. These methods include using multiple backdoors and web shells.

ToneShell Undocumented Variant

One of the popular backdoors the threat actor behind CL-STA-0044 used in this campaign is an undocumented variant of a piece of malware dubbed ToneShell. Trend Micro reported that Stately Taurus has used this malware.

Unlike the previously reported version of ToneShell, which uses shellcode as the payload of the malware, the new variant’s full functionality is built from three DLL components working in tandem.

Each DLL component has a different purpose:

  • Persistence component: in charge of persistence for the backdoor and dropping the other components to disk.
  • Networking component: in charge of command and control (C2) communication.
  • Functionality component: in charge of executing the different commands of the backdoor.

Furthermore, each component of ToneShell is loaded into a different legitimate process via DLL sideloading. Internal communication between the components is done via the use of pipes.

Comparing the undocumented variant with the previously reported shellcode variant as shown in Figure 8, there is a clear indication of overlap in the codebase and functionality, as well as in the strings. These strings are saved as stack strings in the shellcode variant.

Image 8 is a screenshot of many lines of code. The code is color-coded with light blue, blue and green portions. The different code sections starting from the top are the ToneShell ShellCode variant, and the ToneShell DLL variant. It demonstrates there there is overlap.
Figure 8. ToneShell strings overlap.
The Persistence Component

The persistence component (nw.dll, nw_elf.dll) is sideloaded into PwmTower.exe, a component of Trend Micro’s Password Manager, which is a known security tool.

The persistence component will create a different type of persistence depending on the process’ privileges. If it has sufficient rights, the persistence component will create two types of persistence:

  • Service named DISMsrv (Dism Images Servicing Utility Service)
  • Scheduled task named TabletPCInputServices or TabletInputServices

If it does not have sufficient rights, the persistence component will create another two types of persistence:

  • Registry run key named TabletPCInputServices or TabletInputServices
  • Scheduled task named TabletPCInputServices or TabletInputServices

Once the persistence component is executed as a service, it drops the other components to disk and executes the networking component.

The Networking Component

The networking component (rw32core.dll) is sideloaded into Brcc32.exe, the resource compiler of Embarcadero, an app development tool.

The networking component uses the domain www.uvfr4ep[.]com for C2 communication. Then, through the use of pipes, it communicates with the functionality component to execute commands from the C2.

The Functionality Component

The functionality component (secur32.dll) is sideloaded to Consent.exe, which is a Windows binary that the file metadata identifies as “Consent UI for administrative applications.”

Functionality component capabilities include the following:

  • Executing commands
  • File system interaction
  • Downloading and uploading files
  • Keylogging
  • Screen capturing

Figure 9 illustrates the process tree for the ToneShell backdoor.

Image 9 is a diagram of the ToneShell process tree. The process goes from persistence to networking to functionality.
Figure 9. ToneShell process tree.

Web Shells

In addition to maintaining access to victim environments via various backdoors, in some instances, the threat actor also maintained their access via China Chopper web shells. In one instance, one of the backdoors appeared to malfunction and crash on an infected host. To overcome that, the threat actor used their web shell access to troubleshoot the malfunctioning backdoors.

Cobalt Strike

On top of using their web shell access, the threat actor also delivered a Cobalt Strike agent to the infected host that had malfunctioning backdoors. They deployed the Cobalt Strike agent under the name libcurl.dll.

The threat actor used DLL sideloading to abuse the legitimate process GUP.exe, which is a component of Notepad++, to execute the malicious agent.

After deployment, the threat actor deleted the Cobalt Strike agent fairly quickly. This could imply that they only deployed the agent to gain additional functionality momentarily, to allow them to troubleshoot the malfunctioning backdoors.

ShadowPad

On several occasions, the threat actor behind CL-STA-0044 deployed the ShadowPad backdoor. ShadowPad is a modular malware that has been in use by multiple Chinese threat actors since at least 2015. ShadowPad is considered to be the successor of PlugX, another example of modular malware popular with Chinese threat actors.

The threat actor abused DLL sideloading to load the ShadowPad module (log.dll) into a legitimate executable (BDReinit.exe), which is a component of Bitdefender Crash Handler (renamed as net.exe) security tool. When log.dll is loaded into memory, it searches for a file named log.dll.dat that is saved in the same directory to decrypt shellcode and execute the payload.

As shown in Figure 10, ShadowPad then spawns and injects code into wmplayer.exe, which in turn spawns and injects code into dllhost.exe. Researchers from Elastic Security Labs have described this behavior in the past.

ShadowPad creates persistence using the service DataCollectionPublisingService (DapSvc) for the renamed BDReinit.exe (net.exe). Figure 10 illustrates the process tree for ShadowPad.

Image 10 is a screenshot of a diagram from Cortex XDR. The ShadowPad process tree shows the product (BitDefender), the description (BitDefender Crash Handler) and the original name (BDReinit.exe). Some information has been redacted.
Figure 10. ShadowPad process tree.

Highly Targeted and Intelligence-Driven Operation

Targeting Specific Individuals

Analysis of the threat actor’s actions suggests that the threat actor behind CL-STA-0044 has performed considerable intelligence work on their victims. In several instances, Unit 42 researchers observed threat actors using the known Lolbin utility wevtutil to gather information about specific usernames belonging to individuals who work at the victim organizations.

The threat actor searched for Windows Security Log Event ID 4624, which is an event that documents successful login attempts. They also searched for Windows Security Log Event ID 4672, which is an event that documents assignments of sensitive privileges to new login sessions.

The threat actor used these log events to find out which machines specific users of interest logged in to, to pinpoint hostnames of interest. The threat actor would later compromise these machines and gather sensitive data from them for exfiltration. Figure 11 shows wevtutil used to search for successful login attempts.

Image 11 is a screenshot of code. This is wevtutil searching for successful login attempts.
Figure 11. Wevtutil used to search for successful login attempts.

Exfiltration

Throughout this attack, the threat actor attempted to exfiltrate many documents and other sensitive information from the compromised machines. Before exfiltration, the threat actor used rar.exe to archive the files of interest.

Figure 12 shows that, on some occasions, the threat actor searched for specific file extensions. On other occasions, they archived full directories.

Image 12 is a screenshot of a diagram in Cortex XDR. It is their archive of specific file extensions. Some information has been redacted.
Figure 12. Archiving specific file extensions.

The threat actor used a variety of tools to initiate their exfiltration. On already compromised hosts, they used the ToneShell backdoor to execute rar.exe. To access other uncompromised hosts, they used tools like Impacket and RemCom to execute rar.exe remotely. RemCom is a remote shell or telnet replacement that lets you execute processes on remote Windows systems.

On hosts of interest, the threat actor created persistence for a script that is in charge of archiving files (autorun.vbs), as shown in Figure 13. To do this, they saved the VBS script in the startup directory, which causes it to run every time the machine is turned on. This behavior could indicate the threat actor’s goal of getting a continuous flow of intelligence from the victims instead of just being a one and done operation.

Image 13 is a screenshot of a diagram in Cortex XDR. It is their archive of script persistence. Some information has been redacted.
Figure 13. Archiving script persistence.

After archiving the files, we observed the threat actor using two exfiltration methods. The first method is uploading the files using curl and ftp to a cloud storage site named ftp.1fichier[.]com.

The second method observed is uploading the archived files to Dropbox, a file hosting service as shown in Figure 14. This method of exfiltration is popular with threat actors because Dropbox the service is one people often use legitimately, making malicious activity harder to detect.

Image 14 is a screenshot of many lines of code. This is how the threat actor uses data exfiltration, uploading archived files to Dropbox.
Figure 14. Data exfiltration using Dropbox.

Threat actors often abuse, take advantage of or subvert legitimate products for malicious purposes. This does not necessarily imply a flaw or malicious quality to the legitimate product being abused.

Attribution

Based on the analysis of the information available to us, we assess with moderate-high confidence that the activity observed as part of CL-STA-0044 is associated with the APT group Stately Taurus. This group is also known as Mustang Panda, BRONZE PRESIDENT, TA416, RedDelta and Earth Preta.

The first axis of attribution is the backdoors used in the cluster. The main backdoor used by the threat actor behind CL-STA-0044 is an undocumented variant of the ToneShell backdoor, a backdoor that Trend Micro previously reported Stately Taurus has used. ToneShell appears to be a tool unique to the group. At the time of writing this article, no other known APT groups have been publicly documented as using the ToneShell backdoor.

In addition, the threat actor behind CL-STA-0044 deployed the ShadowPad backdoor. ShadowPad is a complex and modular piece of malware that has been used exclusively by Chinese-sponsored threat actors since at least 2015. Furthermore, the filenames and behavior of ShadowPad observed during this campaign overlap with behavior that researchers from Elastic Security Labs have described in the past. This activity resembles the TTPs of threat actors that are believed to operate on behalf of the Chinese nexus.

The second axis of attribution is victimology. We observed the activity associated with CL-STA-0044 targeting the government sector in a country in Southeast Asia. Stately Taurus was previously reported to target the government sector in that region.

The combination of unique tools and activities we observed raise strong suspicion that the threat actor behind CL-STA-0044 is likely the Stately Taurus APT group. This includes the ToneShell backdoor commonly used by Stately Taurus, along with the deployment of the Chinese state sponsored and APT-affiliated backdoor ShadowPad, as well as their victimology.

Conclusion

This article describes the activities of CL-STA-0044, one of three clusters that we observed targeting the government sector in a Southeast Asian country. We associate the activity of the threat actor behind CL-STA-0044 with Stately Taurus with moderate-high confidence.

During the operation, the threat actor slowly took control of the victims' environments, focusing on maintaining control for a long-term operation. The purpose of the threat actor’s efforts appear to be the continuous gathering and exfiltration of sensitive documents and intelligence.

We encourage all organizations to leverage our findings to inform the deployment of protective measures to defend against this threat group.

Protections and Mitigations

For Palo Alto Networks customers, our products and services provide the following coverage associated with the threats described above:

  • WildFire cloud-delivered malware analysis service accurately identifies the known samples as malicious.
  • Advanced URL Filtering and DNS Security identify known domains associated with this group as malicious.
  • Cortex XDR and XSIAM
    • Prevents the execution of known malicious malware, and also prevents the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.
    • Protects against credential gathering tools and techniques using the new Credential Gathering Protection available from Cortex XDR 3.4.
    • Protects from threat actors dropping and executing commands from web shells using Anti-Webshell Protection, newly released in Cortex XDR 3.4.
    • Protects against exploitation of different vulnerabilities including ProxyShell and ProxyLogon using the Anti-Exploitation modules as well as Behavioral Threat Protection.
    • Cortex XDR Pro detects postexploit activity, including credential-based attacks, with behavioral analytics.

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

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

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

Indicators of Compromise

CL-STA-0044

LadonGo

  • 4a8b7cfb2e33aa079ba51166591c7a210ad8b3c7c7f242fccf8cb2e71e8e40d5
  • 12534f7014b3338d8f9f86ff1bbeacf8c80ad03f1d0d19077ff0e406c58b5133
  • 6868f5ce836034557e05c7ddea006a91d6fc59de7e235c9b08787bd6dbd2b837

NBTScan

  • 541bac89b3a414e06b45d778f86b245675922e8b11f866c8b6a827c5d418e598

AdFind

  • 8445aa54adf4d666e65084909a7b989a190ec6eca2844546c2e99a8cfb832fad

Impacket

  • b000a0095a8fda38227103f253b6d79134b862a83df50315d7d9c5b537fd994b

Hdump

  • 64ab1c1b19682026900d060b969ab3c3ab860988733b7e7bf3ba78a4ea0340b9

MimiKatz

  • 31eb1de7e840a342fd468e558e5ab627bcb4c542a8fe01aec4d5ba01d539a0fc
  • 2254e3242943c0afe038baeafe8381bbff136e6d8f681f0f446bf0e458900643

ToneShell Persistence Component

  • 2f5cf595ac4d6a59be78a781c5ba126c2ff6d6e5956dc0a7602e6ba8e6665694
  • 0f2f0458d2f1ac4233883e96fe1f4cc6db1551cdcfdd49c43311429af03a1cd5
  • 011fe9974f07cb12ba30e69e7a84e5cb489ce14a81bced59a11031fc0c3681b7
  • 3fc4d023d96f339945683f6dc7d9e19a9a62b901bef6dc26c5918ce9508be273
  • 3a429b8457ad611b7c3528e4b41e8923dd2aee32ccd2cc5cf5ff83e69c1253c2
  • f58d3d376c8e26b4ae3c2bbaa4ae76ca183f32823276e6432a945bcbc63266d9
  • 46c6ee9195f3bd30f51eb6611623aad1ba17f5e0cde0b5523ab51e0c5b641dbf
  • 86140e6770fbd0cc6988f025d52bb4f59c0d78213c75451b42c9f812fe1a9354

ToneShell Networking Component

  • a08e0d1839b86d0d56a52d07123719211a3c3d43a6aa05aa34531a72ed1207dc
  • 19d07dbc58b8e076cafd98c25cae5d7ac6f007db1c8ec0fae4ce6c7254b8f073
  • 8e801d3a36decc5e4ce6fd3e8e45b098966aef8cbe7535ed0a789575775a68b6
  • df4ba449f30f3ed31a344931dc77233b27e06623355ece23855ee4fe8a75c267
  • 345ef3fb73aa75538fdcf780d2136642755a9f20dbd22d93bee26e93fb6ab8fd
  • 3a5e69786ac1c458e27d38a966425abb6fb493a41110393a4878c811557a3b5b

ToneShell Functionality Component

  • 66b7983831cbb952ceeb1ffff608880f1805f1df0b062cef4c17b258b7f478ce
  • f2a6a326fb8937bbc32868965f7475f4af0f42f3792e80156cc57108fc09c034
  • dafa952aacf18beeb1ebf47620589639223a2e99fb2fa5ce2de1e7ef7a56caa0
  • 52cd066f498a66823107aed7eaa4635eee6b7914acded926864f1aae59571991

Cobalt Strike

  • 8129bd45466c2676b248c08bb0efcd9ccc8b684abf3435e290fcf4739c0a439f

ShadowPad

  • 1874b20e3e802406c594341699c5863a2c07c4c79cf762888ee28142af83547f

RemCom

  • 3c2fe308c0a563e06263bbacf793bbe9b2259d795fcc36b953793a7e499e7f71

Infrastructure

  • www.uvfr4ep[.]com
  • Feed-5613.coderformylife[.]info
  • 45.64.184[.]189
  • 43.254.132[.]242
  • 103.27.202[.]68
  • 67.53.148[.]77
  • 207.246.89[.]250

File Paths

  • C:\Users\Public\Videos\
  • C:\Users\Public\Pictures\
  • C:\Users\Public\Music\
  • C:\Windows\Help\Help\
  • C:\Windows\Vss\
  • C:\Windows\Help\mui\
  • C:\Windows\Help\en-US\
  • C:\Windows\Logs\logs\
  • C:\Windows\Logs\files\
  • C:\Windows\Help\Corporate\
  • C:\PerfLogs\
  • C:\Recovery\

Additional Resources

Persistent Attempts at Cyberespionage Against Southeast Asian Government Target Have Links to Alloy Taurus

Posted on by Robert Falcone

Executive Summary

We observed a series of intrusions directed at a Southeast Asian government target, a cluster of activity that we attribute with a moderate level of confidence to Alloy Taurus, a group believed to be operating on behalf of Chinese state interests. The multiwave intrusions, which started in early 2022 and persisted throughout 2023, capitalized on vulnerabilities in Exchange Servers to deploy a large number of web shells.

These web shells served as gateways for the introduction of additional tools and malware, some specially crafted for the target environments. These incursions were consistent with techniques used for long-term espionage operations and appeared to be attempts to establish a resilient foothold within the compromised networks.

We found this activity as part of an investigation into compromised environments within a Southeast Asian government. We identified this cluster of activity as CL-STA-0045.

Drawing upon available telemetry and threat intelligence, we attribute this cluster of activity with a moderate level of confidence to the Alloy Taurus group, also known as GALLIUM. This group is widely believed to operate on behalf of Chinese state interests and has been observed in multiple espionage campaigns targeting telecommunication companies and government entities across Southeast Asia, Europe and Africa.

Our description of this cluster of activity provides deep technical insights into the tools and approaches used by the APT and a timeline of activity, providing a rich set of indicators for use by defenders.

Palo Alto Networks customers receive protections against the threats discussed in this article through Advanced WildFire, Advanced URL Filtering, DNS Security, Cortex XDR and Cortex XSIAM, as detailed in the conclusion.

Organizations can engage the Unit 42 Incident Response team for specific assistance with this threat and others.

Related Unit 42 Topics Government, APTs
Alloy Taurus akas GALLIUM, Softcell

Timeline of Activity

Image 1 is a timeline of CLA-STA-0045. There are six waves of activity in total. The first wave start in quarter 1 of 2022 and continues through quarters two, three and four of 2022, and quarters one through three of 2023.
Figure 1. Timeline of CL-STA-0045.

CL-STA-0045 Details

From Web Shell to Interactive Attack

Each wave of CL-STA-0045 activity started after the attackers gained access to the network and installed several web shells, including China Chopper, on several internet-facing web servers. Using the web shells, the attackers were able to perform an interactive attack that included running reconnaissance commands and tools (e.g., whoami, ipconfig, dir, arp and net, NBTScan) and creating several administrative accounts (named Admin$, Back$, infoma$ and testuser).

The attackers used these accounts to perform additional activities, as shown in Figure 2.

Image 2 is a screenshot of an alert in Cortex XDR. Alert Description: [Redacted] performed 268 new administrative actions in the last twelve hours. This is an uncharacteristically high number of new administrative actions for [redacted].
Figure 2. Suspicious administrative actions alert.
The attackers also used two scanners. The first was Fscan, which is an open-source internal network scanner written by a Mandarin speaker called “shadow1ng.” Various research organizations have reported multiple Chinese APT groups using this tool. The second scanner was WebScan, a browser-based network IP scanner and local IP detector.

Undocumented .NET Backdoors

Following the creation of the users and the reconnaissance activity, the attackers attempted to execute a previously undocumented .NET backdoor, which they named windows.exe. We named this threat Reshell based on its program database (PDB) path.

The attackers configured the backdoor, which is relatively straightforward and simple, to communicate with the IP 23.106.122[.]46. This gave the attackers an easy way to execute arbitrary commands remotely.

Image 3 is a screenshot of six lines of code. This is the embedded command and control in the Reshell binary.
Figure 3. Embedded C2 in the Reshell binary.

After Cortex XDR prevented execution of the Reshell backdoor, the attackers likely suspected something was not right and tried to check for the connection using the netstat command. They searched for IP addresses in the range of 23.106* and they made a connectivity check, as shown in Figure 4.

Image 4 is a screenshot of a tree diagram in Cortex XDR. The tree begins with httpd.exe. Some information is redacted. Included are two commands as well as the action Cortex XDR took (blocking).
Figure 4. Reshell execution and connectivity check.

The attackers tried to execute another undocumented .NET backdoor, which we call Zapoa. This backdoor opens an HTTP listener, specifically looking for inbound requests to the server that match the following UrlPrefix, which contains a wildcard to match all hostnames within the URL: https://*:443/256509101/.

This backdoor uses the string P88smzTpVBDjwiUv within the HTTP POST data to authenticate its C2. It provides the operator a wide range of capabilities, including:

  • Extracting system information
  • Running the supplied shell code in a new thread
  • Running processes
  • Manipulating the file system
  • Timestamping files with a supplied date
  • Loading additional .NET assembly to enhance its capabilities

Preparing the Ground

The attackers continued to perform additional activities to maintain a foothold in the environment. To prepare the ground, bypass security mitigation efforts and hide from the security team, the attackers installed SoftEther VPN software.

The attacker renamed the SoftEther VPN file to Taskllst.exe, as shown in Figure 5. In other instances, they renamed it to fonts.exe and vmtools.exe.

Using this software, the attackers connected to different hosts inside and outside the network such as GitHub (as observed in Figure 5). They also downloaded additional tools such as Kerbrute, LsassUnhooker and GoDumpLsass, which they used in the next phase of the attack.

Image 5 is a screenshot of a table in Cortex XDR. The column are, from left to right, Source Process Name, Source Signer, and Destination Host. Two .exe files are listed. The signer for both is the SoftEther corporation. The destination host is GitHub.
Figure 5. Connection to GitHub by SoftEther VPN - taskllst.exe.

Stealing Credentials

Since the attackers had already gained a local administrator account, the next step was to gain domain credentials to move laterally inside the network. To do so, the attackers tried different techniques and tools.

  • Brute Forcing Credentials: As shown in Figure 6, the attackers tried to brute force different usernames and passwords using Kerbrute. They used this tool to quickly brute force and enumerate valid Active Directory accounts through Kerberos pre-authentication.
Image 6 is a screenshot of a tree diagram in Cortex XDR. The tree begins with httpd.exe. Some information is redacted. Included are two commands as well as the action Cortex XDR took (blocking).
Figure 6. Detection and prevention of Kerbrute and GoDumpLsass execution.
  • Save SAM Key Hive: The attackers created a scheduled task named updatevmtoolss, which they set to run a .bat file that executes a command to steal credentials from the Security Account Manager (SAM) registry key hive. Figure 7 shows the execution for this activity.
  • Locally Stored Passwords: The attackers tried to steal stored passwords. To do so, they ran the cmdkey /l command that lists the stored usernames and passwords. They then tried to access the login data folders of Chrome and searched within configuration files for password=.

A string of code that allows an attacker to search for passwords within configuration files.

  • Dumping Lsass: The attackers tried to dump the Lsass process using the procdump tool.

A string of code to dump the Lsass process.

The attackers also tried other tools to dump the Lsass process, including the following:

  • LsassUnhooker
  • TaskManager
  • GoDumpLsass (named 123.exe)
  • Mimikatz: The attackers tried using the credential harvesting tool Mimikatz.
  • LaZagne: The attackers tried using the open source local password extractor tool named LaZagne.
  • NTLM Downgrade Attack: Finally, the attackers tried a less common method of stealing credentials, which was to downgrade the Windows New Technology LAN Manager (NTLM) version to extract the NTLM hashes. To do so, the attackers used the tool InternalMonologue.exe and changed related registry values, as shown in Figure 7.
Image 7 is a screenshot of a tree diagram in Cortex XDR. Some information is redacted. The tree splits once and has four branches. Included are the commands used by the threat actor. The main action prevented is InternalMonologue.exe.
Figure 7. Detection and prevention of NTLM downgrade attack and credential theft.

Targeting Critical Assets

After obtaining credentials, the attackers attempted to move laterally inside the network, aiming specifically at web servers and domain controllers.

The attackers first tried using the SoftEther VPN, attempting to create connections to the targets on SMB (port 445). Later in the attack, the attackers changed their tactic and moved laterally by abusing the remote administration tool AnyDesk. This tool was already present in the compromised environment.

The attackers set the password for AnyDesk to be J9kzQ2Y0qO, which is the same password reported multiple times as being used in Conti ransomware attacks.

Command line to set password

We observed no attempt to execute ransomware.

Installing Additional Tools

In addition to the already installed tools mentioned above, the attackers attempted to install other tools and malware to help perform malicious activities and maintain a foothold in the environment. Among these tools were the following:

  • Cobalt Strike
  • PuTTY's Plink
  • HTran
  • Quasar remote access Trojan (RAT)

Cobalt Strike

The attackers attempted to create a connection to the domain images.cdn-sina[.]tw to download a file named scvhost.txt. This file was a Cobalt Strike beacon, which Figure 8 shows Cortex XDR prevented from executing.

Image 8 is a screenshot of a tree diagram in Cortex XDR. The tree splits once and has four branches. Included are the commands used by the threat actor. Two actions are prevented: scvhost.text and result.txt.
Figure 8. Blocked execution of payloads from images.cdn-sina[.]tw.
In another attempt to execute Cobalt Strike, the attackers created services to run the beacon (Reset.cpl, help.exe) using the living-off-the-land binaries and scripts (LOLBAS) method of abusing the Windows Shell Common DLL (Shell32.dll), as highlighted in the below code snippet and shown in full in Figure 9.

A string of code that abuses Shell32.dll.

Image 9 is a screenshot of a tree diagram in Cortex XDR. The tree splits once and has three branches. Included are the commands used by the threat actor. The execution of Cobalt Strike is blocked.
Figure 9. Blocked execution of Cobalt Strike by abusing the Windows Shell Common DLL.

Reverse SSH Tunneling

Attackers established a reverse Secure Shell (SSH) tunnel that allowed direct Remote Desktop Protocol (RDP) connection to the compromised host so they could interact with AnyDesk remotely. To do this, the attackers tried to use HTran (lcx.111) to tunnel RDP connections to its C2 (154.55.128[.]129, as shown in Figure 10).

In an attempt to overcome the mitigation efforts, the attackers also tried using another tool to perform this SSH tunneling called PuTTY. The attackers downloaded a file named result.txt from the same domain mentioned above (images.cdn-sina[.]tw), which is the PuTTY binary.

Using the PuTTY binary in one compromised environment, the attackers attempted to create an SSH tunnel to 159.223.85[.]37. In another compromised environment, the attackers tried to tunnel to both that IP and 156.251.162[.]29.

The attackers kept using those tools, sometimes with the same naming convention and the same infrastructure, across multiple victims in the government sector in the Southeast Asian country.

Image 10 is a screenshot of a tree diagram with two branches in Cortex XDR. This demonstrates the program detection and then preventing the execution of HTran and Plink. Some information has been redacted.
Figure 10. Detection and prevention of HTran and Plink execution.

Downloading Additional Tools via PowerShell

In addition to Cobalt Strike and PuTTY, which the attackers downloaded from images.cdn-sina[.]tw, they also used another subdomain (Shell.cdn-sina[.]tw, resolved to 78.142.246[.]117). Attackers used it to store additional tools including victim-specific scripts.

To access those tools, the attackers used Windows Management Instrumentation (WMI) and PowerShell with the following command line.

A string of code used to access stored additional tools.

Attackers tried to bypass some antivirus detection of download string operations (i.e., searching for certain keywords, such as DownloadString).

The attackers also downloaded PowerCat (the PowerShell version of the networking utility netcat) from the same domain, using the IP this time. They then ran this utility with the same IP previously used by the attackers as a parameter for Plink.

A string of code to run the utility netcat.

Quasar RAT

Another type of malware that the attackers attempted to use is Quasar RAT. Different threat actors around the world use this off-the-shelf tool. The malware provides its operator with a wide set of capabilities, including the following:

  • Capturing screenshots
  • Recording the victim’s webcam
  • Keylogging
  • Stealing passwords

As observed in Figure 11, the actor put the Quasar RAT dropper (l.exe) in the C:/Recovery folder, which dropped the Quasar RAT loader (loader.any) and tried to execute it.

Image 11 is a screenshot of a tree diagram in Cortex XDR. The tree splits once and has two branches. Two actions are prevented (blocked). These are l.exe and regsvr32.exe Loader.any.
Figure 11. Prevention of Quasar RAT execution.

HDoor

The attacker also used a customized version of the Chinese backdoor HDoor. HDoor has been publicly available in Chinese forums since at least 2008. Various research organizations have reported that multiple Chinese APT groups have used this threat, such as Growing Taurus (aka Naikon) and Parched Taurus (aka Goblin Panda).

HDoor is equipped with full backdoor capabilities, allowing the operator to perform a variety of tasks, including the following:

  • Keylogging
  • File and process manipulation
  • Scanning
  • Acting as a proxy client
  • Connecting to other endpoints in the network
  • Stealing credentials in various methods
  • Exfiltrating data

HDoor was executed using the following command line arguments:

A string of code to execute Hdoor.

Gh0stCringe RAT

Another piece of malware that the attackers tried to use is Gh0stCringe, which is based on the source code of Gh0st RAT. The attackers tried to execute this tool twice, with a gap of over 10 days between executions.

In the first execution, the attackers attempted to execute the malware dropper, which was named Cssrs.exe. This dropped the Gh0stCringe binary, named moon.exe, and executed it. Figure 12 shows this activity.

Image 12 is a screenshot of a diagram in Cortex XDR. The execution of moon.exe is blocked.
Figure 12. Gh0stCringe process tree.

The second time, the attackers tried to execute Gh0stCringe by the name conhost.exe as shown in Figure 13. They created the malware under the ESET folder C:\ProgramData\ESET\RemoteAdministrator\Agent\conhost.exe.

Although this folder is legitimate and contains ESET-related files that were legitimately installed in the victim’s environment, the use of this folder to store malicious payloads is not common.

However, we note that in the same environment, we saw the threat actors behind a different cluster, CL-STA-0044 abusing ERAAgent.exe to execute the ToneShell malware.

Image 13 is a screenshot of a tree diagram in Cortex XDR. The tree splits once and has two branches. Included are the commands used by the threat actor. The commands used by the attackers are included. The execution of conhost.exe is blocked. Some information is redacted.
Figure 13. Executing Gh0stCringe from the ESET folder.

A Variant of the Winnti Malware

In January 2023, we observed the actors attempting to install a variant of the Winnti malware family. According to an April 11, 2013, blog written by Kaspersky, Winnti is a prominent malware family used by multiple Chinese threat groups since at least 2011.

To install this particular variant of Winnti, the actor saved two files (rs.exe and s.dll) to the system within the folder D:\HPEOneView\<redacted>\admin\.!\.dump. The rs.exe executable is a loader that copies the s.dll payload to the location %SYSTEM%\lscsrv.dll and creates a service named Lscsrv with it.

This beacon leads us to believe this is a variant of the Winnti malware. This beacon has several overlaps compared to the beacon created by the Winnti malware discussed in Kaspersky’s blog:

  • The first four bytes within the beacon data are hard-coded as 0xDF1F1ED3.
  • The beacon data is 1,360 bytes in length before compression.
  • The beacon data is compressed using zlib with a compression level of 8.
  • The packet structure is the same including:
    • the compressed data length
    • a hard-coded null value
    • a random byte
    • the compressed data
  • The structure of the beacon data itself is identical, with the field types at the same offsets

At a high level, this Winnti variant has the following capabilities available for the actor to use:

  • File system modifications
  • Registry modifications
  • Service modifications
  • Uploading and downloading of files
  • Creating and acting as a proxy
  • Reverse shell
  • Keylogging
  • Screen control functionality, including key typing and mouse movement
  • Enumerating network resources and file shares

Attribution

We identified CL-STA-0045 activity on multiple entities of the same government in Southeast Asia around the same time frame. The clustering of the activity was based on the use of the same tools, malware, similar techniques and tactics, and in some cases shared infrastructure.

Analysis of activity of the threat actor behind CL-STA-0045, in combination with third-party reporting, presents noteworthy overlaps with the reported modus operandi of Alloy Taurus (aka GALLIUM).

The threat actor used a combination of tools and malware during its operation that, when grouped together in a single operation, presents a rather unique playbook.

As part of this cluster of activity, some of the main tools used together include the following:

  • The renamed SoftEther VPN using a similar naming convention with files and/or folders
  • China Chopper web shell being installed after web server exploitation
  • HTran being used for RDP tunneling
  • NBTScan
  • A Gh0st RAT variant being used to establish a foothold

The combination of these tools in a single operation has only been previously reported as part of Alloy Taurus operations.

In addition, our analysis of the activity showed a repetitive style of attack, in which the threat actor attacked in waves. Each wave started with web server exploitation as well as installation of web shells and reconnaissance. This was then followed by the deployment of additional tools. This manner of operation, with the tools listed above, overlaps with the behavior reported in Operation SoftCell.

Furthermore, the Unit 42 internal telemetry we’ve presented included an infrastructure overlap with the activity described in CL-STA-0045, and it was observed on one of the compromised entities belonging to the same government. The threat actor behind this cluster used a renamed SoftEther VPN to hide their connection to its C2 server.

In one instance of this activity cluster, the communication we observed was to an infrastructure that overlaps with the IP address 196.216.136[.]139 that we mentioned in our post Chinese Alloy Taurus Updates PingPull Malware. Our telemetry also suggests that Alloy Taurus was active in the same environment in Q3 and Q4 of 2022, which aligns with CL-STA-0045 activity from a timeline perspective.

We observed the activity specifically associated with CL-STA-0045 targeting the government sector in Southeast Asia. Alloy Taurus was previously reported to target the government sector in that region.

The combination of tools used in CL-STA-0045, the analysis of the threat actor’s modus operandi, the victimology of this cluster and overlaps with Unit 42 internal telemetry led us to estimate with a moderate level of confidence that the threat actor behind CL-STA-0045 is likely the Alloy Taurus APT group.

Conclusion

CL-STA-0045 activity represents a significant threat to government entities in South East Asia. The threat actor behind this cluster employed a mature approach, utilizing multiwave intrusions and exploiting vulnerabilities in Exchange Servers as their main penetration vector. We estimate that the main goal behind the activity was to facilitate long-term espionage operations.

Based on the available telemetry, we attribute this cluster of activity with a moderate level of confidence to the Alloy Taurus group. This threat actor poses a significant threat to regional security and warrants heightened attention from affected organizations and governments in the region.

The findings of this investigation underscore the urgent need for enhanced security measures, vigilant monitoring and proactive threat intelligence sharing among government entities and affected industries in Southeast Asia. By adopting a multilayered defense approach and staying informed about emerging threats, organizations can better protect themselves against the persistent and evolving tactics employed by threat actors such as Alloy Taurus.

Protections and Mitigations

For Palo Alto Networks customers, our products and services provide the following coverage associated with the threats described above:

  • WildFire cloud-delivered malware analysis service accurately identifies the known samples as malicious.
  • Advanced URL Filtering and DNS Security identify domains associated with this group as malicious.
  • Cortex XDR and XSIAM
    • Prevents the execution of known malicious malware, and also prevents the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.
    • Protects against credential gathering tools and techniques using the new Credential Gathering Protection available from Cortex XDR 3.4.
    • Protects from threat actors dropping and executing commands from web shells using Anti-Webshell Protection, newly released in Cortex XDR 3.4.
    • Protects against exploitation of different vulnerabilities including ProxyShell and ProxyLogon using the Anti-Exploitation modules as well as Behavioral Threat Protection.
    • Cortex XDR Pro detects post exploit activity, including credential-based attacks, with behavioral analytics.

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

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

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

Indicators of Compromise

Web Shells

  • b87c125c8c3bf43096690bf74df960e2c0120654635c4ea715039fbe9115ecef
  • 009a9d1609592abe039324da2a8a69c4a305ca999920bf6bbef839273516783a
  • C1f43b7cf46ba12cfc1357b17e4f5af408740af7ae70572c9cf988ac50260ce1
  • 36e661edc1ad4e44ba38d8f7a6bd00c2b4bc32e9fae8b955b1b4c6355aa6abed
  • 6455bb361d1a1246d1df39b0785fc0f370eb54dd7d5b64d70457e4f9881f6c3c

Reshell Backdoor

  • 4cb020a66fdbc99b0bce2ae24d5684685e2b1e9219fbdfda56b3aace4e8d5f66

Zapoa Backdoor

  • 128bc34ee9d907d017f2e6f8fbbba24c3e51ed5a2fdba417ba893b496c8c18a7

Cobalt Strike

  • Fec2d328462c944e85dd112e61c97d3e67a39f3c83c59e07410d228c7222d153
  • 99d0764248491f44709bd000104f6f99e53c9de8d55649b45112320d7bc4deed
  • 9242846351a65655e93ed2aeaf36b535ff5b79ddf76c33d54089d9005a66265b

Quasar RAT

  • 244cb0f526c2c99be0bf822463cd338630afa12ab32cc9b6cfd6e85fa315a478
  • 3e5c992b2be98efd3de5b13969900f207665116063a889b1c763371d4104f7f9

HDoor

  • bd5dcf5911f959dd79de046d151e8a4aed3b854a322135acc37e3edb3643d0e2

Gh0stCringe RAT

  • f602bd56d6b4bf040956b86ed030643523a8b6611a21b5aafeaa82478820c395
  • d3b8f10f25545bed7d661b6a80be53356c00947800c7e53f050cb15b1f9b953b

Winnti-Related Backdoor

  • a6b33cf73dd85c18577f58a75802ea0820f11aba88fac23ee3794fac1f4bacfa
  • 0d0dd41677ff0d7d648f8563db3a4b4844d86d70562d844bad1983333ae5633d

Fscan

  • c27f0e68bc7f2ec2eede8a8e08fa341d41d5d2d0fb2b74260679a5504115947e

WebScan

  • dbdd0f4bf1f217d794738b7d4f83483a5b3579be8791a7e2f2a62ec3e839be3c

Kerbrute

  • 5aa035ebc3359ee8517d99569c8881fcb7f48ab7e9a2f101f7e7ec23e636c79b

LsassUnhooker

  • 225e5818dc7e7b23110f64fbb718c1792ad93ba7eb893bfbee96cdb13180fbf7

InternalMonologue.exe

  • c74897b1e986e2876873abb3b5069bf1b103667f7f0e6b4581fbda3fd647a74a

Infrastructure

  • 159.223.85[.]37
  • 156.251.162[.]29
  • Shell.cdn-sina[.]tw
  • images.cdn-sina[.]tw
  • 78.142.246[.]117
  • 154.55.128[.]129
  • 34.81.11[.]157
  • 45.117.103[.]86
  • 23.106.122[.]46
  • 202.53.148[.]3

Reshell URI Pattern

  • /sbName/
  • /Sleep/hostname=

Additional Resources

 

Unit 42 Researchers Discover Multiple Espionage Operations Targeting Southeast Asian Government

Posted on by Robert Falcone

Executive Summary

In early 2023, Unit 42 researchers began investigating a series of espionage attacks that targeted a government in Southeast Asia. These attacks focused on different governmental entities in the same country, including critical infrastructure, public healthcare institutions, public financial administrators and ministries.

This appeared at first glance to be the activity of a single threat actor. Careful analysis, however, revealed the attacks to have been carried out by separate threat actors whose activities group into three distinct clusters. While this activity occurred around the same time and in some instances even simultaneously on the same victims’ machines, each cluster is characterized by distinct tools, modus operandi and infrastructure.

The techniques and tools observed during the attacks, along with the persistent long-term surveillance efforts made by the different attackers, suggest the work of advanced persistent threats (APTs). In our analysis, we were able to attribute the three clusters to known APT groups with different levels of confidence.

The Unit 42 system for defining and tracking threat adversaries provides a framework for grouping similar behaviors, tools, infrastructure and tradecraft, and then assigning names to the resulting clusters. When we applied this framework to the attacks we observed, we broke the clusters down as follows:

This research offers a glimpse into the intricate and clandestine world of nation-state cyberespionage, in which multiple critical government entities of one country were compromised.

Palo Alto Networks Cortex XDR and XSIAM customers receive protections through WildFire, Behavioral Threat Protection, Local Analysis, Analytics and multiple other security modules that can help detect and block various threats including targeted APT attacks.

Organizations can engage the Unit 42 Incident Response team for specific assistance with this threat and others.

Related Unit 42 Topics Government, APTs

Background

While conducting threat hunting operations in late 2022, Unit 42 researchers discovered activity targeting a government in Southeast Asia. Initially, we found malicious activities in one compromised environment that belonged to a government entity. Through careful examination of the forensic evidence, including the tactics, techniques and procedures (TTPs) as well as infrastructure, we were able to identify three distinct clusters of activity.

You can find the descriptions for the individual clusters in the following reports:

The diagram in Figure 1 provides a comprehensive visual overview of the overall observed activities, prior to the breakdown by clusters of activity. It includes the TTPs employed by the threat actors and the affected machines within the environment.

Image 1 is a diagram of the TTPs used by the threat actors, grouped by activity cluster.
Figure 1. Maltego graph of the artifacts observed in the initial compromised environment.

Each cluster had its own unique characteristics, which allowed us to define each one separately. The clustering and attribution process we used was based on the Diamond model of attribution, allowing for a comprehensive understanding of the threat landscape.

Image 2 is the same activity cluster as Figure 2. Here the activity clusters have been colored by cluster as in the Venn diagram in Figure 1. Cluster A is red and is the largest area. Cluster B is green and is the next largest. Cluster C is blue and is the smallest. They overlap at one specific area on the lower right.
Figure 2. Maltego graph of the three clusters identified in the initial compromised environment.

As the investigation progressed, we found further overlapping activity in additional environments. All of these environments were determined to belong to governmental entities for the same government in Southeast Asia.

Bird’s Eye View of Each Cluster’s Activity

The following section provides an overview of the main findings in each of the clusters.

CL-STA-0044 (Approximately Q1 2021-Q3 2023)

The activity observed in this cluster is attributed with moderate-high confidence to the APT group Stately Taurus. Analysis of the activity suggests that the attackers conducted a cyberespionage operation that focused on gathering intelligence as well as stealing sensitive documents and information, while maintaining a persistent and clandestine foothold.

The attackers used two main backdoors. The first one was an undocumented variant of the ToneShell backdoor. The second backdoor was ShadowPad, a complex and modular backdoor known to be exclusively used by Chinese APT groups.

The attackers also used a range of known hacking tools, such as the following:

  • LadonGo
  • Impacket
  • China Chopper web shells
  • Scanning and credential dumping tools

A full analysis of CL-STA-0044 activity, TTPs and IoCs can be found in “Cyberespionage Attacks Against Southeast Asian Government Linked to Stately Taurus, Aka Mustang Panda.”

CL-STA-0045 (Q1 2022-Q3 2023)

The activity observed in this cluster is attributed with a moderate level of confidence to the Alloy Taurus APT group. Analysis of the activity shows that the attackers were mainly focused on the following activities:

  • Establishing long-term persistence
  • Reconnaissance missions
  • Obtaining and maintaining access through a variety of activities
    • Various backdoors
    • Web shells
    • Prolific credential-gathering activities

The attackers attempted to remain under the radar by using uncommon techniques and by circumventing several security products.

The main tools observed in this cluster included two previously unknown backdoors, Zapoa and ReShell, first identified by Unit 42 researchers. Moreover, the attackers also used known malware and hacking tools such as the following:

  • GhostCringe remote access Trojan (RAT)
  • Quasar RAT
  • Cobalt Strike
  • Kerbrute brute forcing tool
  • China Chopper web shell

A full analysis of CL-STA-0045 activity, TTPs and IoCs can be found in “Persistent Attempts at Cyberespionage Against Southeast Asian Government Target Have Links to Alloy Taurus.”

CL-STA-0046 (Q3 2022-Q4 2022)

The activity observed in this cluster is attributed with a moderate level of confidence to the Gelsemium APT group. Analysis of the activity shows that the attackers mainly focused on reconnaissance and maintaining access activities, specifically targeting vulnerable IIS servers.

The two main, unique types of malware used in this cluster were OwlProxy and SessionManager. The combination of these distinct tools has only been observed in past attacks that other researchers have attributed to Gelsemium.

In addition, the attackers used more common tools such as the following:

  • Cobalt Strike
  • Meterpreter
  • Earthworm
  • Spoolfool

A full analysis of CL-STA-0046 activity, TTPs and IoCs can be found in “Rare Backdoors Suspected to be Tied to Gelsemium APT Found in Targeted Attack in Southeast Asian Government.”

Conclusion

The investigation we conducted revealed that what initially appeared as a single attack orchestrated by a solitary threat actor was not so simple. It unfolded into a complex operation of multiple infiltrations carried out across three distinct clusters of activity.

Distinguishing one activity from another is a complicated task and can, in many cases, lead to wrong clustering and misattributions. This investigation highlights the importance of paying attention to details and carefully examining artifacts and data.

The revelation of these clusters dating back to the beginning of 2021 and spanning into the present year, provides a glimpse into the relentlessness of advanced persistent threats. By attributing each cluster to previously known APT groups — Stately Taurus, Alloy Taurus and Gelsemium — our investigation underlines the importance of vigilance in safeguarding the digital landscape against these experienced adversaries whose techniques are always evolving.

It’s clear that our ability to overcome challenges posed by these threat actors relies on the foundations of proactive defense and multilayer protection systems being constantly updated for new techniques.

Palo Alto Networks Cortex XDR and XSIAM customers receive protections through WildFire, Behavioral Threat Protection, Local Analysis, Analytics and multiple other security modules that can help detect and block various threats including targeted APT attacks.

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

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

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

Fake CVE-2023-40477 Proof of Concept Leads to VenomRAT

Posted on by Robert Falcone

Executive Summary

Researchers should be aware of threat actors repurposing older proof of concept (PoC) code to quickly craft a fake PoC for a newly released vulnerability. On Aug. 17, 2023, the Zero Day Initiative publicly reported a remote code execution (RCE) vulnerability in WinRAR tracked as CVE-2023-40477. They had disclosed it to the vendor on June 8, 2023. Four days after the public reporting of CVE-2023-40477, an actor using an alias of whalersplonk committed a fake PoC script to their GitHub repository.

The fake PoC meant to exploit this WinRAR vulnerability was based on a publicly available PoC script that exploited a SQL injection vulnerability in an application called GeoServer, which is tracked as CVE-2023-25157. We analyzed the fake PoC script and all the links in the infection chain, which ultimately installed a VenomRAT payload.

We do not think the threat actor created this fake PoC script to specifically target researchers. Rather, it is likely the actors are opportunistic and looking to compromise other miscreants trying to adopt new vulnerabilities into their operations.

Based on a timeline of events, we believe the threat actor had created the infrastructure and payload independently from the fake PoC. Once the vulnerability was publicly released, the actors acted quickly to capitalize on the severity of an RCE in a popular application. WinRAR states they have over 500 million users worldwide.

We would like to thank fellow Cyber Threat Alliance (CTA) member Broadcom/Symantec (@threatintel) for sharing the initial sample on this CVE.

Palo Alto Networks customers received protection from this infection chain prior to the fake PoC code’s creation with WildFire and Advanced URL Filtering. The domain checkblacklistwords[.]eu used to host the various files needed for infection and the VenomRAT payload were automatically categorized as malware before the PoC was committed to GitHub.

Related Unit 42 Topics Vulnerability, Remote Access Trojan

Fake It Until You Make It

An unknown actor using the alias whalersplonk released a fake PoC script for an RCE vulnerability in WinRAR tracked by CVE-2023-40477. This PoC is fake, as it does not exploit the intended vulnerability. Rather, it is based on publicly available PoC code for a vulnerability in GeoServer tracked by CVE-2023-25157. Instead of exploiting the WinRAR vulnerability as it claims, the PoC script sets off an infection chain that (after several steps) will install a VenomRAT payload.

The CVE-2023-40477 vulnerability in WinRAR allows an attacker to execute code on a system that opens a malicious file. According to the vendor’s announcement on Aug. 24, 2023, the Zero Day Initiative initially reported the CVE-2023-40477 vulnerability on June 8, 2023, and publicly reported it on Aug. 17, 2023. The timestamps within the ZIP archive suggest that the actor committed the files to GitHub on Aug. 21, 2023, four days after the vulnerability was publicly announced.

According to a Tweet by @AabyssZG seen in Figure 1, this fake PoC archive was hosted at a GitHub repository for a user named whalersplonk. Visiting this repository now results in a 404 error, as the repository was removed.

Image 1 is a screenshot of a Twitter post. The user name is @AabyssZG. Their profile picture is of a short-haired person sitting at a computer and looking behind them. Mixed with Chinese characters are: CVE-2023-40477, Pic, Github, Poc and a final sentence that says “Please do not attempt to run this Poc!” The date is 11:02 PM on August 21, 2023 and the tweet has 13.1k views at the time the screenshot was taken. It has eight reposts, three quotes, 33 like and six bookmarks.
Figure 1. Tweet showing the fake PoC code hosted at a GitHub repository owned by whalersplonk.

The fake PoC is a Python script that was uploaded to VirusTotal in a ZIP archive named CVE-2023-40477-main.zip, specifically poc.py. The code snippet below shows the contents of the CVE-2023-40477-main.zip archive in 7-Zip. We believe the CVE-2023-40477-main.zip file itself was generated by downloading the entire repository by clicking the “Download ZIP” button in GitHub.

Social Engineering

Figure 2 shows that the README.md file within the ZIP archive attempts to further trick the user into compromising their system by providing a summary of the CVE-2023-40477 vulnerability and usage instructions for the poc.py script. The instructions also include a link to a video hosted on streamable[.]com. The video is no longer hosted at the URL within the README.md file, as it was set to expire on Aug. 25, 2023 5:35:00 AM UTC.

Image 2 is a screenshot of a README in Wordpad. CVE-2023-40477. POC WinRAR vulnerable to remote code execution, A widely used Windows-only utility, WinRAR can create an extract file archives in various compression formats. CVE-2023-40477 is the remote code execution vulnerability that could allow remote threat actors to execute arbitrary code on an affected WinRAR installation. Usage. Create “test.rar” and place in the same directory as poc.py. Put any files you want inside test.rar. Execute command: poc.py -c CMD command to execute. Done! Now after someone open any file inside .rar file will execute that command hiddenly. Video: streamable dot com forward slash nx20wk.
Figure 2. README.md within the ZIP archive that provides information about the CVE-2023-40477 vulnerability and usage instructions.

We discovered interesting information regarding the video via the metadata provided by Streamable. Table 1 shows key pieces of information about the video hosted at Streamable, including the date the video was uploaded, which aligns with our timeline. The number of plays suggests that over 100 individual views of the video took place.

Metadata Field Value
date_added 1692656432.078 (Aug. 21, 2023 10:20:32 PM UTC)
original_name 22.08.2023_00.17.56_REC.mp4
duration 20.303278 seconds
plays 121 (as of 2023-08-22 05:38:32)

Table 1. Metadata fields and values for the video.

We also obtained two screenshots associated with the 22.08.2023_00.17.56_REC.mp4 uploaded to Streamable, which were used as thumbnails to display parts of the video. The first image, which Streamable displays before the user clicks the play button on the video, shows the threat actor’s desktop and their task manager.

Figure 3 depicts the task manager showing a process named Windows.Gaming.Preview, which is the same executable name as the VenomRAT payload discussed later in this article. We suspect the threat actor used the same system to test their payload and make this demonstration video.

Image 3 is a screenshot of a desktop. Task manager is open. Windows.Gaming.Preview is the executable name of the VenomRAT payload.
Figure 3. First thumbnail of 22.08.2023_00.17.56_REC.mp4 displayed before the video plays, shows the VenomRAT process running on the actor’s system.

The second screenshot shown in Figure 4, which we believe Streamable captures halfway through the video, displays the actor showing an archive of Burp Suite, a password of 311138, and the PuTTY client. We believe the actor was pretending to show how to craft a malicious archive and use the script to exploit the CVE-2023-40477 vulnerability in WinRAR.

More importantly, the screenshot also depicts the Windows clock showing 8/21/2023 3:17 PM. We can use this information in our timeline to determine where it fits, and to speculate the time zone the actor is in based on other activities.

Image 4 is a screenshot of a desktop. Task manager is open. A trial version of Burp Suite is also open. An open file in Notepad has pass: 311138 as its contents. PuTTY Configuration is open.
Figure 4. Second thumbnail of 22.08.2023_00.17.56_REC.mp4 showing a Burp Suite archive.

We believe the burpsuite_pro_v2023.2.2.zip archive seen in the video above was obtained from a Telegram post, as seen in Figure 5. We did not analyze the Burp Suite application provided by the Telegram post to determine if it was a legitimate version, as available from the PortSwigger website.

Image 5 is a screenshot of a Telegram post. Burpsuite (not official). Burpsuite_pro_v2023.2.2.zip. Pass: 311138. README inside, plz read it before run BS. Happy hacking! Party emoji. Telegram link is t.me/burpsuite/390. At the time of the screenshot, the post had been viewed 33.2 thousand times. It was posted on March 6 at 10:58.
Figure 5. Telegram post showing the burpsuite_pro_v2023.2.2.zip archive used by the actor in the demonstration video.

Fake Proof of Concept

The fake PoC Python script within the ZIP archive was named poc.py, which was based on the open-source CVE-2023-25157 PoC with some changes shown in Figure 6. The changes to the CVE-2023-25157 PoC code included the following:

  • Removal of comments regarding details about the CVE-2023-25157 vulnerability
  • Removal of lines of code that would suggest it’s a network-related vulnerability, such as the setting of variables named PROXY and PROXY_ENABLED
  • Modified strings from geoserver to exploit
  • Inclusion of additional code that downloads and executes a batch script with a comment of “Check dependency”
Image 6 is is two screenshots side by side. On the left is the genuine PoC for CVE-2023-25157. On the right is the fake CVE-2023-40477 PoC. Both are written in Python. The comparison includes code that is removed, changed or added.
Figure 6. Comparison between the CVE-2023-25157 PoC on the left and the fake CVE-2023-40477 PoC on the right.

The poc.py script no longer runs correctly due to the removal of several lines of code. However, the malicious code added to the script does run properly before the script ends in an exception, as seen in Figure 7.

Image 7 is a screenshot of the poc.py script in the Command Prompt. Some of the information has been redacted. This script closes after malicious code is ran.
Figure 7. The poc.py script closes due to an exception, but after malicious code runs.

The code added to the CVE-2023-25157 PoC shown in the green lines of code on the right side of Figure 6 above creates a batch script in %TEMP%/bat.bat. This script will reach out to the following URL and run the response:

  • http://checkblacklistwords[.]eu/check-u/robot?963421355?Ihead=true

The batch script hosted at the URL above runs an encoded PowerShell script that will download another PowerShell script from checkblacklistwords[.]eu/c.txt. The script then saves this file to %TEMP%\c.ps1 and runs it, as seen in the following code block:

Script that downloads and runs the saved PowerShell script.

The downloaded PowerShell script downloads an executable from checkblacklistwords[.]eu/words.txt and saves it to %APPDATA%\Drivers\Windows.Gaming.Preview.exe. The PowerShell script not only runs the executable, but it also creates a scheduled task named Windows.Gaming.Preview that runs the executable every three minutes to persistently run the payload.

The Windows.Gaming.Preview.exe executable is a variant of VenomRAT, which is the same name as the running process seen in the task manager displayed during the video in the README.md file shown in Figure 3 above. This suggests that the threat actor may have been running the VenomRAT payload on their system when they made the video.

This particular variant of VenomRAT has the following configuration:

The configuration field Paste_bin has a value of http://checkblacklistwords[.]eu/list.txt, which the executable will communicate with to obtain the command and control (C2) location. This URL suggests the C2 is at the following IP address:

  • 94.156.253[.]109:4449

This particular VenomRAT client starts a key logger functionality that logs keystrokes to %APPDATA%\MyData\DataLogs_keylog_offline.txt. The client then begins communicating with its C2 server and will process the server's response for the commands shown in Table 2.

Command Description
plu_gin Invokes a plugin by name that is saved to a key in the registry via the save_Plugin command
HVNCStop Gets a process by name cvtres and kills it.
loadofflinelog Uploads the offline key logger file from %APPDATA%\MyData\DataLogs_keylog_offline.txt
save_Plugin Saves a plugin to the registry for loading via the plu_gin command. Plugins saved to a specified subkey in Software\\<hardware id>
runningapp Gets the running processes
keylogsetting Provides a new key log configuration file that will save to %APPDATA%\MyData\DataLogs.conf
init_reg Deletes subkeys in Software\\<hardware id>
Po_ng Sends the interval between the last PING message sent to the C2 server and the receipt of the Po_ng command
filterinfo Gets installed applications list from the registry (SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall) and the running processes.

Table 2. Commands and their description for the VenomRAT variant.

According to the VenomRAT sample’s portable executable (PE) header, the executable was compiled on Feb. 8, 2023, at 22:10:28 UTC. We found over 700 VenomRAT samples that had this same compilation time. This suggests that this particular sample was likely created with a standard VenomRAT builder that used a base executable and modified it with updated configuration settings. We have made the full list of SHAs and IoCs available on GitHub.

Timeline of Events

Unit 42 researchers built a timeline of events surrounding this incident seen in Figure 8 using the timestamps previously mentioned above as well as those seen within our internal products. These timestamps are those specifically associated with the following:

  • The public release of the CVE-2023-40477 vulnerability
  • The threat actor’s activities, including the setup of infrastructure and the deployment of the fake PoC
  • Palo Alto Networks product coverage
Image 8 is a timeline of events associated with the fake PoC for CVE-2023-40477. It starts on July 16, 2023 with the last modified field HTTP response to checkblacklistwords dot eu. It ends with WinRAR announcing the vulnerability as part of their release notes on August 27, 2023.
Figure 8. Timeline of events associated with the fake PoC for the CVE-2023-40477 vulnerability.

The timeline shows that the threat actor created the checkblacklistwords[.]eu domain used in the infection chain at least 10 days prior to the public release of CVE-2023-40477. This was 14 days before they committed the fake PoC code to GitHub. However, the HTTP response to the URL hxxp://checkblacklistwords[.]eu/ has a Last-Modified field that is set to Sun, 16 Jul 2023 18:43:54 GMT, which suggests that the actor could have initially set up the server over a month before the public release of the vulnerability.

According to Palo Alto Networks product coverage, both WildFire and Advanced URL Filtering processed and provided malware verdicts to the following:

  • VenomRAT payload
  • checkblacklistwords[.]eu domain
  • Two of the URLs seen in the infection chain

Advanced URL Filtering automatically processed and provided a malicious verdict to the remaining URL seen in the infection chain a day after the actor released the fake PoC.

Based on this timeline, we believe the threat actor had created the infrastructure and payload separately from the fake PoC. Once the vulnerability was publicly released, the actors quickly created the fake PoC to use the severity of an RCE in a popular application like WinRAR to lure in potential victims.

Conclusion

An unknown threat actor attempted to compromise individuals by releasing a fake PoC after the vulnerability’s public announcement, to exploit an RCE vulnerability in a well-known application. This PoC is fake and does not exploit the WinRAR vulnerability, suggesting the actor tried to take advantage of a highly sought after RCE in WinRAR to compromise others. The fake PoC is based on publicly available code for a vulnerability in GeoServer that sets off an infection chain that installs VenomRAT.

While we cannot provide accurate figures on the impact or number of compromises, we saw that the instructional video provided by the actor along with the fake exploit script had 121 views.

Palo Alto Networks customers received protection from this fake PoC as the checkblacklistwords[.]eu domain and VenomRAT sample had malicious verdicts prior to the creation of the fake exploit script.

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

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

Palo Alto Networks would like to thank fellow Cyber Threat Alliance (CTA) member Broadcom/Symantec (@threatintel) for sharing the initial sample on this CVE. In addition, we have shared our findings, including file samples and indicators of compromise, with our fellow CTA members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

A full list of IoCs is available on our GitHub.

Indicator Type Description
7fc8d002b89fcfeb1c1e6b0ca710d7603e7152f693a14d8c0b7514d911d04234 File CVE-2023-40477-main.zip 
ecf96e8a52d0b7a9ac33a37ac8b2779f4c52a3d7e0cf8da09d562ba0de6b30ff File poc.py
c2a2678f6bb0ff5805f0c3d95514ac6eeaeacd8a4b62bcc32a716639f7e62cc4 File bat.bat
b99161d933f023795afd287915c50a92df244e5041715c3381733e30b666fd3b File c.ps1
b77e4af833185c72590d344fd8f555b95de97ae7ca5c6ff5109a2d204a0d2b8e File Windows.Gaming.Preview.exe - VenomRAT
94.156.253[.]109 IPv4 VenomRAT C2
checkblacklistwords[.]eu Domain Hosted files in infection chain
http://checkblacklistwords[.]eu/check-u/robot?963421355?Ihead=true URL Hosted bat.bat
http://checkblacklistwords[.]eu/c.txt URL Hosted c.ps1
http://checkblacklistwords[.]eu/words.txt URL Hosted Windows.Gaming.Preview.exe

Threat Group Assessment: Turla (aka Pensive Ursa)

Posted on by Unit 42

Executive Summary

Turla (aka Pensive Ursa, Uroburos, Snake) is a Russian-based threat group operating since at least 2004, which is linked to the Russian Federal Security Service (FSB). In this article, we will cover the top 10 most recently active types of malware in Pensive Ursa’s arsenal: Capibar, Kazuar, Snake, Kopiluwak, QUIETCANARY/Tunnus, Crutch, ComRAT, Carbon, HyperStack and TinyTurla.

Pensive Ursa was chosen to be the main focus for the 2023 MITRE ATT&CK evaluation. MITRE has described Turla as being “known for their targeted intrusions and innovative stealth.” The results of this evaluation, including Palo Alto Networks scoring, will be published in late September 2023.

In addition to describing each type of malware’s functionality and history, we will present their execution through the lens of the Palo Alto Networks Cortex XDR product. We will show how Cortex protects against such malware, and the MITRE ATT&CK mapping of such threats as shown in the Cortex XDR platform.

Palo Alto Networks customers receive protections from Pensive Ursa’s arsenal and the techniques discussed in this blog through Cortex XDR, which provides a multilayer defense that includes behavioral threat protection and exploit protection.

The Advanced WildFire cloud-delivered malware analysis service accurately identifies samples related to Pensive Ursa as malicious. Cloud-Delivered Security Services, including Advanced URL Filtering and DNS Security, identify domains associated with this group as malicious.

Related Unit 42 Topics APT, Malware
Pensive Ursa Alternative names: Turla, Snake, Uroburos, Venomous Bear, Waterbug, Iron Hunter
Malware discussed Capibar, Kazuar, Snake, QUIETCANARY, Kopiluwak, Crutch, ComRAT, Carbon, HyperStack, TinyTurla

Pensive Ursa (aka Turla) Overview

Over the years, Pensive Ursa has become known as an advanced and elusive adversary. The group has demonstrated a high level of technical expertise, while orchestrating targeted and stealthy attacks.

As described by MITRE, Pensive Ursa targeted victims in over 45 countries as well as a wide range of sectors, including government entities, embassies, and military organizations, as well as education, research and pharmaceutical companies. In addition, this threat group had an active part in the Russian-Ukraine conflict that started in February 2022. According to the Ukraine CERT, Pensive Ursa leveraged espionage attacks against Ukrainian targets, specifically against their defense sector.

While Pensive Ursa mainly used their espionage arsenal to target Windows machines, the group also has tools that can attack macOS and Linux machines.

MITRE ATT&CK Evaluation

For the 2023 MITRE ATT&CK evaluation, Pensive Ursa was chosen to be the main focus. According to MITRE, this threat group is particularly relevant as their actions have global impact.

Below are the top 10 most recently active types of malware in the team’s arsenal. For each type of malware, we provided a short description and analysis, as well as how Cortex XDR detects and prevents the threat.

Recent Pensive Ursa Arsenal Technical Analysis

Malware: Capibar

Aliases: DeliveryCheck, GAMEDAY

Malware Type: Backdoor

First Seen: 2022

Description: Capibar (aka DeliveryCheck, GAMEDAY) is a Pensive Ursa backdoor that was first observed in 2022, and used for the purpose of espionage against defense forces in Ukraine. They distributed it via email as documents with malicious macros.

Capibar persists via a scheduled task that downloads and launches the payload in memory. The threat group installed Capibar on compromised MS Exchange servers as a Managed Object Format (MOF) file, granting the attacker full control of the server. Figure 1a below shows a snippet of the code responsible for loading XML received from its command and control (C2), and Figure 1b shows the alert triggered.

Image 1a is a screenshot of many lines of code. It is responsible for loading an XML from the command and control. It loads Capibar.
Figure 1a. Capibar code snippet loading XML received from its C2.
Image 1b is a screenshot of text from the Cortex XDR application. WildFire malware. Source: XDR agent. Suspicious DLL detected.
Figure 1b. The alert triggered in Cortex XDR.

Malware: Kazuar

Malware Type: Backdoor

First Seen:  2017

Description: Kazuar is a .NET backdoor that was discovered in 2017. Kazuar provides full access to the compromised systems targeted by its operator. Kazuar comes with a powerful command set that includes the ability to remotely load additional plugins to enhance the backdoor’s capabilities.

In 2021, researchers found interesting code overlaps and similarities between Kazuar and the notorious SUNBURST backdoor that a Russian threat group used in the SolarWinds Operation. In July 2023, the Ukrainian CERT uncovered an espionage operation where Pensive Ursa used Kazuar as one of the main backdoors. Figure 2 shows Cortex XDR preventing a Kazuar DLL from being injected into the explorer.exe process, and Figure 3 shows an alert being triggered for Kazuar prevention.

Image 2 is a screenshot of the Cortex XDR application. Within a blue circle is a generic icon of an application window. Below it is the number 34. A red warning shield appears above it. Explorer.exe is listed below the 34. To the right of the icon is a description box that says a suspicious DLL has been detected.
Figure 2. Kazuar injected into explorer.exe and prevented by Cortex XDR.
Image 3 is a screenshot of the Cortex XDR application. Within a blue circle is a generic icon of an application window. Below it is the number 34. A red warning shield appears above it. Explorer.exe is listed below the 34. To the right of the icon is a description box that says a suspicious DLL has been detected.
Figure 3. Kazuar execution prevention alert by Cortex XDR.

Malware: Snake

Malware Type: Modular backdoor

First Seen: 2003

Description: The infamous Snake malware is the most complex tool in Pensive Ursa’s tool set, as described by CISA in May 2023. The primary purpose of this tool is to achieve persistence for considerable periods of time and exfiltrate data from dedicated targets. It was in active development for 20 years, since 2003.

Snake was detected operating in more than 50 countries worldwide. The United States Department of Justice published a statement in which they announced Operation MEDUSA, where they disrupted the Snake malware activity and peer to peer (P2P) network. They did so by using a tool developed by the FBI dubbed PERSEUS, which they used as a kill switch for the Snake malware.

Based on previous analysis, the Snake malware implemented a maintainable code design, which showed that its authors had a high level of software development capability.

Snake implements features such as the following:

  • A custom implementation of communication protocols over HTTP and TCP
  • A kernel module for stealth
  • Key logger functionality

More recent variants of Snake include an infection chain similar to the one depicted below.

Example of Snake Malware Delivery

Upon execution, Snake loads and executes Pensive Ursa’s PNG Dropper malware from its resources and creates a hard-coded mutex {E9B1E207-B513-4cfc-86BE-6D6004E5CB9C, as shown in Figure 4.

Image 4 is a screenshot of the program Resource Hacker. It lists Snake loaders resources. On the left is a menu of the binary. The view in the screenshot is the binary view, and the user can also select an editor view.
Figure 4. Snake loader’s resources.

The PNG dropper then decodes and loads a vulnerable VM driver that is used for privilege escalation in order to write the main Snake payload to disk, and register it as a service.

The Snake loader variant shown in Figure 5 detects the multiple stages in the infection chain that lead to the deployment, service registration and execution of the main Snake payload. Figure 6 shows the execution prevention alert pop-up in Cortex XDR.

Image 5 is a screenshot of a tree diagram in Cortex XDR. The tree has two branches. Various alert symbols shoe on the tree. There are two descriptions of separate commands that have been detected.
Figure 5. Snake execution detection shown in Cortex XDR in detect mode.
Image 6 is a screenshot of the Cortex XDR Prevention Alert window. Cortex XDR has blocked a malicious activity! Application name: snake.exe. Application publisher: Unknown. Prevention description: Suspicious executable detected. There are two buttons: Show details and OK.
Figure 6. Snake execution prevention alert shown in Cortex XDR.

Malware: QUIETCANARY

Aliases: Tunnus

Malware Type: Backdoor

First Seen: 2017

Description: Pensive Ursa has been observed using QUIETCANARY since 2019, and the Tomiris group has used this backdoor even earlier. Pensive Ursa deployed QUIETCANARY against targets in Ukraine in September 2022, together with the Kopiluwak malware. QUIETCANARY is a lightweight backdoor written in .NET, which is capable of executing various commands received from its C2 server, including downloading additional payloads and executing arbitrary commands. It also implements RC4 encryption to protect its C2 communication. Figure 7 shows QUIETCANARY’s different classes that reveal its backdoor capabilities.

Image 7 is a screenshot of many lines of code. These are the different classes in QUIETCANARY’s code. They include BrowserTelemetry and CommandDescriptor, CommandFactory, Executor, Processor, ClearCommand, DownloadCommand, KillCommand, and many others.
Figure 7. Code snippet of the different classes in QUIETCANARY’s code.

Figure 8 shows the Cortex XDR multilayered protection-based alerts that QUIETCANARY triggered. Figure 9 shows the execution prevention alert.

Image 8 is a screenshot of Cortex XDR’s alerts for QUIETCANARY. The column on the left is for alerts and lists malware, execution, execution. The column on the right is for the alert name. These are WildFire Malware, identity analytics and identity analytics. The details include that the first analytics is a rare process execution in organization. The second analytics is a rare process execution by user.
Figure 8. QUIETCANARY’s alerts shown in Cortex XDR.
Image 9 is a screenshot of the Cortex XDR Prevention Alert window. Cortex XDR has blocked a malicious activity! Application name: BrowserTelemetry. Application publisher: Unknown. Prevention description: Suspicious executable detected. There are two buttons: Show details and OK.
Figure 9. QUIETCANARY/Tunnus execution prevention alert shown in Cortex XDR.

Malware: Kopiluwak

Malware Type: Spreader/Downloader

First Seen: 2016

Description: Kopiluwak malware was discovered in late 2016, and it was delivered as a multilayered JavaScript payload by various types of droppers.

Pensive Ursa dropped the Kopiluwak malware using an MSIL dropper in 2017 in a G20-themed attack, and as an SFX executable in late 2022.

Kopiluwak’s JavaScript file is depicted in Figure 10 and the code snippet below, dropped under the C:\Windows\Temp\ path. Its purpose is gathering valuable initial profiling information on the infected machine, such as the following:

  • Listing files in strategic locations
  • Retrieving the current running processes
  • Displaying active network connections

The threat actor accomplished this activity by running reconnaissance commands such as systeminfo, tasklist, net, ipconfig, and dir. The results are saved in a file named result2.dat.

Image 10 is a screenshot of a diagram in Cortex XDR. It demonstrates the Kopiluwak execution detection. Several icons within red or blue circles show the separate stages. Two have alerts. From left to right they are fopiluwak.exe, wsscropt.exe, and cmd.exe.
Figure 10. Kopiluwak execution detection as shown in Cortex XDR in detect mode.

Listed in Figure 11 are the reconnaissance commands executed by Kopiluwak, and detected by Cortex XDR.

Image 11 is a screenshot of many lines of code. These are the reconnaissance commands for Kopiluwak.
Figure 11. Kopiluwak’s reconnaissance commands.

Figure 12 shows Cortex XDR raising an execution prevention alert for Kopiluwak.

Image 12 is a screenshot of the Cortex XDR Prevention Alert window. Cortex XDR has blocked a malicious activity! Application name: Kopiluwak.exe. Application publisher: Unknown. Prevention description: Suspicious executable detected. There are two buttons: Show details and OK.
Figure 12. Kopiluwak execution prevention alert as shown in Cortex XDR.

In 2019, Pensive Ursa began to deliver Kopiluwak using the Topinambour dropper. The group bundled Topinambour into a legitimate software installer.

Upon installation, Topinambour is dropped as a small .NET file in the %localappdata% folder and written as a scheduled task, as shown in Figure 13. The malware then communicates with its hard-coded C2 virtual private server (VPS) to deliver the Kopiluwak malware.

Image 13 is a screenshot of a tree diagram in Cortex XDR. It demonstrates the Topinambour execution detection. Several icons within red or blue circles show the separate stages. Two have alerts. There is an inset description that includes a breakdown of the different commands and the file path.
Figure 13. Topinambour execution detection shown in Cortex XDR in detect mode.

Figure 14 shows the prevention alert pop-up raised by Cortex XDR.

Image 14 is a screenshot of the Cortex XDR Prevention Alert window. Cortex XDR has blocked a malicious activity! Application name: topinambour.exe. Application publisher: Unknown. Prevention description: Suspicious executable detected. There are two buttons: Show details and OK.
Figure 14. Topinambour execution prevention alert shown in Cortex XDR.

Malware: Crutch

Malware Type: Backdoor

First Seen: 2015

Description: In December 2020, ESET researchers discovered the Crutch backdoor. In line with Pensive Ursa’s tactics, techniques and procedures (TTPs), the threat actor used the backdoor to attack a handful of targets in Europe, including the Ministry of Foreign Affairs of an EU member.

The main purpose of this backdoor was to eventually steal sensitive files and exfiltrate the data to a Dropbox account controlled by Pensive Ursa operators. Using commercial services such as Dropbox for C2 communication is a known (yet effective) technique due to it being a legitimate service, and blending in with other network communication.

This backdoor was attributed to Pensive Ursa due to strong similarities in code and TTPs with another backdoor from Pensive Ursa’s arsenal called Gazer. Crutch is considered to be a second-stage backdoor, and its persistence is achieved using DLL hijacking.

Figures 15 and 16 show the detection and prevention of Crutch respectively, in Cortex XDR.

Image 15 is a screenshot of a diagram in Cortex XDR. It demonstrates the Crutch execution detection. Several icons within blue circles show the separate stages. Two have alerts. There is an inset description that includes a breakdown of the different commands and the file path.
Figure 15. Crutch execution detection shown in Cortex XDR in detect mode.
Image 16 is a screenshot of the Cortex XDR Prevention Alert window. Cortex XDR has blocked a malicious activity! Application name: Windows host process (Rundll32). Application publisher: Microsoft Corporation. Prevention description: Suspicious DLL detected. Show details has been selected and the information included is: application name, application version, application publisher, process ID, application location, command line and file origin.
Figure 16. Crutch execution prevention alert shown in Cortex XDR.

Malware: ComRAT

Aliases: Agent.btz

Malware Type: Backdoor

First Seen: 2007

Image 17 is a screenshot of a diagram in Cortex XDR. It demonstrates the PowerShell dropper as it drops ComRAT. Several icons within blue circles show the separate stages. Three have alerts. There are inset descriptions that includes a breakdown of the different commands and the file path.
Figure 17. PowerShell dropper drops ComRAT to disk shown in Cortex XDR in detect mode.

Description: ComRAT is one of Pensive Ursa’s oldest backdoors, which they named Agent.btz in earlier iterations of the malware. ComRAT was reportedly first discovered in 2007. Since then it has had many upgrades. As of 2020, the latest iteration of ComRAT is version 4. This threat is developed in C++ and the threat actor has deployed it using PowerShell implants, such as PowerStallion. Figure 17 shows the PowerShell dropper mechanism. The threat actor’s main purpose of operations when using ComRAT was to steal and exfiltrate confidential documents from high value targets.

Image 18a is a screenshot of the Cortex XDR Prevention Alert window. Cortex XDR has blocked a malicious activity! Application name: Windows PowerShell. Application publisher: Microsoft Corporation. Prevention description: Behavioral threat detected. Show details has been selected and the information included is: application name, application version, application publisher, process ID, application location, command line, file origin and user name.
Figure 18a. ComRAT PowerShell dropper execution prevention alert shown in Cortex XDR.

Figures 18a and 18b depict the PowerShell and DLL executions preventions respectively, in Cortex XDR.

Image 18b is a screenshot of the Cortex XDR Prevention Alert window. Cortex XDR has blocked a malicious activity! Application name: Windows host process (Rundll32). Application publisher: Microsoft Corporation. Prevention description: Suspicious DLL detected. Also listed is the application version, process ID, application location, the command line and the file origin.
Figure 18b. ComRAT DLL execution prevention alerts shown in Cortex XDR.

Malware: Carbon

Malware Type: Backdoor

First Seen: 2014

Description: Carbon is a modular backdoor framework that has been used by Pensive Ursa for several years. The Carbon framework includes an installer, an orchestrator component, a communication module and a configuration file.

Carbon also has P2P communication capabilities, which the threat actor uses to send commands to other infected machines on an affected network. Carbon receives commands from the C2 through the use of legitimate web services providers like Pastebin.

Figure 19 and Figure 20 show Carbon’s execution detection and prevention in Cortex XDR.

Image 19 is a screenshot of a diagram in Cortex XDR. It demonstrates Carbon creating a service that loads additional components. Several icons within blue and red circles show the separate stages. Two have alerts. Some information is redacted.
Figure 19. Carbon creates a service that loads the additional components, which is shown in Cortex XDR in detect mode.
Image 20 is a screenshot of the Cortex XDR Prevention Alert window. Cortex XDR has blocked a malicious activity! Application name: carbon.exe. Application publisher: Unknown. Prevention description: Suspicious executable detected.
Figure 20. Carbon execution prevention alert shown in Cortex XDR.

Malware: HyperStack

Malware Type: Backdoor

First Seen: 2018

Description: HyperStack (aka SilentMoo, BigBoss) is an RPC backdoor that was first observed in 2018, which the threat actor used in operations targeting government entities in Europe. HyperStack operates with a controller that uses named pipes to communicate over RPC with other machines in a compromised environment that are infected with HyperStack. This communication method enables the attacker to control machines on a local network.

HyperStack shows several similarities with Pensive Ursa’s Carbon backdoor, such as the encryption scheme, configuration file format and logging convention.

Figure 21 and Figure 22 show HyperStack’s detection and prevention respectively, in Cortex XDR.

Image 21 is a screenshot of a diagram in Cortex XDR. It demonstrates HyperStack creating a service for persistence. Several icons within blue and red circles show the separate stages. Three have alerts. Some information is redacted.
Figure 21. HyperStack creates a service for persistence shown in Cortex XDR in detect mode.
Image 22 is a screenshot of the Cortex XDR Prevention Alert window. Cortex XDR has blocked a malicious activity! Application name: HyperStack. Application publisher: Unknown. Prevention description: Suspicious executable detected.
Figure 22. HyperStack execution prevention alert shown in Cortex XDR.

Malware: TinyTurla

Malware Type: Backdoor

First Seen: 2021

Description: The TinyTurla malware was first discovered by Talos in 2021. They assumed it was a second stage backdoor, and it has been seen on targets in the US, EU and later in Asia.

TinyTurla’s main features include the following:

  • Downloading additional payloads
  • Uploading files to the attacker's C2 server
  • Executing other processes

As shown in Figure 23, threat actors install the backdoor via a batch script as a service called Windows Time Service. The batch script is also in charge of writing the C2 server’s data to the registry. Once the backdoor is executed, it reads these values to communicate with its C2. It masquerades as a DLL called w64time.dll, under the system32 folder.

Figure 23 is a screenshot of 10 lines of code. It is the badge script that writes the command and control server’s data to the registry.
Figure 23. Content of the batch script described above.

Although w32time.dll is a legitimate DLL, and other legitimate DLLs do have both 32- and 64-bit variants, a legitimate w64time.dll does not exist. This naming convention is intended to further distract victims from suspecting anything is amiss.

Figure 24 and Figure 25 show Cortex XDR detecting the writing and execution of the batch script, the W64Time service and the TinyTurla DLL execution.

Image 24 is a screenshot of a diagram in Cortex XDR. It demonstrates TinyTurla prevention. Several icons within blue circles show the separate stages. One has an alert. Two inset descriptions implied the CMD and the information that a Suspicious DLL was detected. Some information is redacted.
Figure 24. TinyTurla prevention shown in Cortex XDR in detect mode.
Image 25 is a screenshot of the Cortex XDR Prevention Alert window. Cortex XDR has blocked a malicious activity! Application name: Windows host process (Rundll32). Application publisher: Microsoft Corporation. Prevention description: Suspicious DLL detected.
Figure 25. TinyTurla execution prevention alert shown in Cortex XDR.

Tactics, Techniques and Procedures (TTPs)

Cortex XDR alerts are mapped to the MITRE ATT&CK framework and present information about the tactic and the technique associated with the threat, as shown in Figure 26 below.

A screenshot of what MITRE ATT&CK mapping looks like in Cortex XDR.
Figure 26. Mitre ATT&CK mapping in Cortex XDR.

Pensive Ursa-related activities and arsenal raised multiple alerts in Cortex XDR, which were mapped to the MITRE ATT&CK tactics and techniques referenced in Table 1.

MITRE ATT&CK tactic MITRE ATT&CK technique
Resource Development Acquire Infrastructure, Compromise Infrastructure, Develop Capabilities, Obtain Capabilities
Execution Command and Scripting Interpreter, Native API, User Execution
Initial Access Drive-by Compromise, Phishing, Valid Accounts
Persistence Boot or Logon Autostart Execution, Event Triggered Execution, Valid Accounts
Privilege Escalation Access Token Manipulation, Boot or Logon Autostart Execution, Event Triggered Execution, Exploitation for Privilege Escalation, Process Injection, Valid Accounts
Defense Evasion Access Token Manipulation, Deobfuscate/Decode Files or Information, Impair Defenses, Modify Registry, Obfuscated Files or Information, Process Injection, Subvert Trust Controls, Valid Accounts
Credential Access Brute Force, Credentials from Password Stores
Discovery Account Discovery, File and Directory Discovery, Group Policy Discovery, Password Policy Discovery, Peripheral Device Discovery, Permission Groups Discovery, Process Discovery, Query Registry, Remote System Discovery, Software Discovery, System Information Discovery, System Network Configuration Discovery, System Network Connections Discovery, System Service Discovery
Lateral Movement Lateral Tool Transfer, Remote Services
Collection Archive Collected Data, Data from Information Repositories, Data from Local System, Data from Removable Media
Command and Control Application Layer Protocol, Ingress Tool Transfer, Proxy, Web Service
Exfiltration Exfiltration Over Web Service

Table 1. MITRE ATT&CK tactics and techniques.

Conclusion

The Pensive Ursa advanced persistent threat (APT) group is known to be a significant and persistent adversary. With their advanced techniques, this Russian-FSB operated group has demonstrated an evasive modus operandi while targeting a wide range of sectors across the globe.

We explored the top 10 types of malware in Pensive Ursa’s arsenal and witnessed their execution through the lens of Palo Alto Networks Cortex XDR product. This demonstrated the importance of using a multilayered protection model against an advanced threat.

The potential damage of falling victim to a Pensive Ursa APT attack can be significant. The consequences extend beyond financial losses and data breaches to the possibility of them reaching critical infrastructure, which could have national security and geopolitical ramifications. Thus, every organization, regardless of its size or industry, must prioritize comprehensive security strategies and invest in multilayer security measurements to safeguard against the growing threat of APT groups like Pensive Ursa.

Protections and Mitigations

Palo Alto Networks Cortex XDR and XSIAM customers receive protections against Pensive Ursa’s arsenal of malware described in this blog post.

Prevention and detection alerts were raised for each malware: Capibar, Kazua, Snake, Kopiluwak, QUIETCANARY/Tunnus, Crutch, ComRAT, Carbon, HyperStack and TinyTurla.

SmartScore is a unique ML-driven scoring engine that translates security investigation methods and their associated data into a hybrid scoring system. It scored an incident involving a combination of known Pensive Ursa tools and techniques a 91 score, which is a very high level of risk, as shown below in Figure 26.

Image 26 is a screenshot of the program SmartScore. It lists incident information with a rating and why the incident was rated the severity it was.
Figure 27. SmartScore information about the incident.

For Palo Alto Networks customers, our products and services provide the following coverage associated with this group:

Cortex XDR detects user and credential-based threats by analyzing user activity from multiple data sources including the following:

  • Endpoints
  • Network firewalls
  • Active Directory
  • Identity and access management solutions
  • Cloud workloads

Cortex XDR builds behavioral profiles of user activity over time with machine learning. By comparing new activity to past activity, peer activity and the expected behavior of the entity, Cortex XDR detects anomalous activity indicative of credential-based attacks.

It also offers the following protections related to the attacks discussed in this post:

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

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

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

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

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

Indicators of Compromise

Capibar

Hashes (SHA-256):

  • ba2c8df04bcba5c3cfd343a59d8b59b76779e6c27eb27b7ac73ded97e08f0f39
  • 64e8744b39e15b76311733014327311acd77330f8a135132f020eac78199ac8a

Domains:

  • hxxps://mail.numina[.]md/owa/scripts/logon.aspx
  • hxxps://mail.aet.in[.]ua/outlook/api/logoff.aspx
  • hxxps://mail.arlingtonhousing[.]us/outlook/api/logoff.aspx
  • hxxps://mail.kzp[.]bg/outlook/api/logoff.aspx
  • hxxps://mail.lechateaudelatour[.]fr/MICROSOFT.EXCHANGE.MAILBOXREPLICATIONSERVICE.PROXYSERVICE/RPCWITCHERT/SYNC
  • hxxps://mail.lebsack[.]de/MICROSOFT.EXCHANGE.MAILBOXREPLICATIONSERVICE.PROXYSERVICE/RPCWITCHERT/SYNC

Kazuar

Hashes (SHA-256):

  • 8490daab736aa638b500b27c962a8250bbb8615ae1c68ef77494875ac9d2ada2
  • b51105c56d1bf8f98b7e924aa5caded8322d037745a128781fa0bc23841d1e70
  • Bf6f30673cf771d52d589865675a293dc5c3668a956d0c2fc0d9403424d429b2
  • cd4c2e85213c96f79ddda564242efec3b970eded8c59f1f6f4d9a420eb8f1858

Domains:

  • Gaismustudija[.]lv
  • Hcdh-tunisie[.]org
  • www.gallen[.]fi
  • hxxps://www.bombheros[.]com/wp-content/languages/index[.]php
  • hxxps://www.simplifiedhomesales[.]com/wp-includes/images/index.php
  • hxxp://mtsoft.hol[.]es/wp-content/gallery/
  • hxxp://www.polishpod101[.]com/forum/language/en/sign/
  • hxxps://www.pierreagencement[.]fr/wp-content/languages/index.php
  • hxxps://sansaispa[.]com/wp-includes/images/gallery/
  • hxxps://octoberoctopus.co[.]za/wp-includes/sitemaps/web/

Snake

Hashes (SHA-256):

  • fc68026b83392aa227e9adf9c71289cb51ba03427f6de67a73ae872e19ef6ff9
  • 1950d2e706fbc6263d376c0c4f16bd5acfd543248ee072657ba3dd62da8427eb
  • cf3a7d4285d65bf8688215407bce1b51d7c6b22497f09021f0fce31cbeb78986
  • b262292e049ee75d235164df98fa8ed09a9e2a30c5432623856bafd4bd44d801

Kopiluwak

Hashes (SHA-256):

  • 6536b6b50aa1f6899ffa90aaf4b1b67c0ae0f6c0441016f5308b37c12141c61d
  • 8d9bb878a18b2b7ef558504e78a59eb644f83a63679658533ff8accf0b85fda3

Domains:

  • manager.surro[.]am

IPs:

  • 194.67.209[.]186

Topinambour

Hashes (SHA-256):

  • 009406c1c7c0b289a25d44dfaa8364633d9b71df5f3c7a65deec1ef00a8c2ebb
  • 7a7d11adbcb740323eb52b097f535cfa5c281bf07a4d5c4afb0c5182fa4ffd1b
  • d4ba16db7c26622d2d402cb9714331abfee891b6276d16e6c2f2132e8944cc71
  • 046f11a6c561e46e6bf199ab7f50e74a4d2aaead68cdbd6ce44b37b5b4964758

IPs:

  • 197.168.0[.]247

QUIETCANARY/Tunnus

Hashes (SHA-256):

  • 0fc624aa9656a8bc21731bfc47fd7780da38a7e8ad7baf1529ccd70a5bb07852
  • 3f94b20cb7f4ff55207660649ebbb02679c991fe03efbcb0bd3840fc7f0bd527
  • 29314f3cd73b81eda7bd90c66f659235e6bb900e499c9cc7057d10a9083a0b94
  • 87663affd147065d08d4fe76d9a18b0d7d85fab68cf9f5ac96cfdfff3f27ffd2

Domains:

  • lakihelppi[.]com

IPs:

  • 46.101.209[.]249
  • 210.48.231[.]182

Crutch

Hashes (SHA-256):

  • 0010ccb822538d1881c61be874af49382c44b6c9cb665081cf0f672cbed5b6a5
  • 29b1da7b17a7ba3e730e6927058d0554a8bc81bdef88e364097fab0bb1950edc
  • 16860fc685ea0dee91e65e253062153ac6c886fdd73a3020c266601f58038a61
  • 10c0e2afb37a24ac7732a402a4c9d854b35a382f1651d4aa2ece429b154aecb2

ComRAT

Hashes (SHA-256):

  • 00352afc7e7863530e4d68be35ae8b60261fc57560167645697b7bfc0ac0e93d
  • 134919151466c9292bdcb7c24c32c841a5183d880072b0ad5e8b3a3a830afef8
  • 166b1fb3d34b32f1807c710aaa435d181aedbded1e7b4539ffa931c2b2cdd405
  • 44d6d67b5328a4d73f72d8a0f9d39fe4bb6539609f90f169483936a8b3b88316
  • A3170c32c09fc85cdda778a5c20a3dab144b6d1dd9996ba8340866e0081c7642
  • 187bf95439da038c1bc291619507ff5e426d250709fa5e3eda7fda99e1c9854c
  • b93484683014aca8e909c9b5648d8f0ac21a45d0c193f6ca40f0b01d2464c1c4

Domains:

  • branter[.]tk
  • wekanda[.]tk
  • sanitar[.]ml
  • duke6[.]tk
  • bronerg[.]tk
  • Crusider[.]tk

Carbon

Hashes (SHA-256):

  • 493e5fae191950b901764868b065ddddffa4f4c9b497022ee2f998b4a94f0fc2
  • f3aaa091fdbc8772fb7bd3a81665f4d33c3b62bf98caad6fee4424654ba26429
  • 2b969111dd1968d47b02d6390c92fb622cd03570b02ecf9215031ff03611a2b7
  • 7d5794ad91351c7c5d7fbad8e83e3b71a09baac65fb09ca75d8d18339d24a46f

Domains:

  • www.berlinguas[.]com
  • www.balletmaniacs[.]com

HyperStack

Hashes (SHA-256):

  • 6ca0b4efe077fe05b2ae871bf50133c706c7090a54d2c3536a6c86ff454caa9a
  • 20691ff3c9474cfd7bf6fa3f8720eb7326e6f87f64a1f190861589c1e7397fa5
  • e33580ae3df9d27d7cfb7b8f518a2704e55c92dd74cbbab8ef58ddfd36524cc8

TinyTurla

Hashes (SHA-256):

  • 030cbd1a51f8583ccfc3fa38a28a5550dc1c84c05d6c0f5eb887d13dedf1da01

Additional References

Unit 42 Attack Surface Threat Research: Constant Change in Cloud Contributes to 45% of New High/Critical Exposures Per Month

Posted on by Unit 42

Introduction

It’s challenging to ensure proper protection for your organization in an ever-changing, vulnerable environment. In our survey of over 250 organizations, we found that 80% of security exposures are found in cloud environments and 20% of cloud services change every month. Trying to get a handle on this sort of volatility is not easy, but it is vitally important.

Our 2023 Unit 42 Attack Surface Threat Report explores the global attack surface landscape based on observable data on exposures that are publicly accessible over the internet. It also offers recommendations on how organizations should approach active attack surface management.

Key Findings From the 2023 Unit 42 Attack Surface Threat Report

Constant Change in the Cloud Creates New Risk

Unit 42 studied the composition of new and existing services running in different cloud providers used by organizations over a period of six months. Cloud-based IT infrastructure is always in a state of flux. On average, over 20% of externally accessible cloud services change monthly across the 250 organizations. Figure 1 shows how this breaks down across different industries.

Image 1 is a graph of the median proportion of changed services introduced by a typical company. It lists 12 different industries, with the top five being transportation and logistics at 27%, insurance at 24%, financial services at 24%, high technology at 23% and the federal government at 22%.
Figure 1. Median proportion of changed services introduced by a typical company in a certain industry during a given month.

Consequently, Unit 42 investigated the impact on the number of new security risks introduced within an organization, which is illustrated in Figure 2. Over 45% of most organizations’ high-risk, cloud-hosted exposures in a given month were observed on new services that hadn’t been present on their organization's attack surface in the month prior. Thus, the creation of new, publicly accessible cloud services (both intended and unauthorized) is a risk factor related to nearly half of all high-criticality exposures at a given time.

Image 2 is a graph of the median proportion of high-risk cloud-hosted exposures on a typical company’s attack surface in a given month. It lists 12 different industries, with the top five being transportation and logistics at 85%, insurance at 64%, financial services at 60%, high technology at 50% and the federal government at 49%.
Figure 2. Median proportion of high-risk cloud-hosted exposures observed on a typical company’s attack surface in each industry during a given month.

Cloud Exposures Dominate Most Organizations’ Security Risks

According to our analysis, 80% of security exposures were observed in cloud environments, as shown in Figure 3 below. This higher distribution of exposures in the cloud can be attributed to the following causes:

  • Frequent misconfigurations
  • Shared responsibilities
  • Shadow IT
  • Inherent connection to the internet
  • Lack of visibility into cloud assets
Image 3 as a pie chart that compares the proportion of cloud versus on prime security exposures. Cloud is 80.3%, and on-prem is 19.7%.
Figure 3. Proportion of cloud vs. on-premises security exposures.

Three Causes Account for 60% of All Exposure on the Global Attack Surface

Figure 4 shows that across the more than 250 organizations we analyzed, web framework takeover exposures like insecure versions of Apache web servers, insecure versions of PHP and insecure versions of jQuery account for over 22% of the exposures. Poorly configured remote access services like Remote Desktop Protocol (RDP), Secure Shell (SSH), or virtual network computing (VNC) make up 20% of the exposures.

Image 4 is a pie chart of the exposures of the global attack surface. The largest percentage is web framework takeover at 22.8%, followed by: remote access services, 20.1%, IT security and networking infrastructure, 17.1%, file sharing, 12.1%, and databases, 9.5%.
Figure 4. Exposures of the global attack surface.

Unit 42 also observed that IT security and networking infrastructure exposures make up nearly 17% of all the exposures of the global attack surface. The exposures in this category consisted of internet-accessible administrative login pages of the following assets:

  • Routers
  • Firewalls
  • Virtual private networks (VPNs)
  • Other core networking and security appliances

Compromise of these assets can have substantial consequences for organizations, including the compromise of core business functions and applications, and the data they contain.

Recommendations to Actively Manage Your Attack Surface

Most organizations are unprepared for an attack through an unknown or unmanaged exposure. We found eight of the nine organizations we studied had internet-accessible RDP vulnerable to brute-force attacks for at least 25% of the month.

To protect against these types of attack surface vulnerabilities, organizations should:

  • Achieve continuous visibility
    Maintain a comprehensive, real-time understanding of all internet-accessible assets, including cloud-based systems and services. This helps to actively discover, learn and respond to risks more quickly.
  • Address cloud misconfigurations
    Regularly review and update cloud configurations, aligning with best practices to mitigate security risks. Foster collaboration between security and DevOps teams to secure cloud-native application development and deployment.
  • Prioritize remediation
    Focus on addressing the most critical vulnerabilities and exposures, such as those with a high Common Vulnerability Scoring System (CVSS) score – which accounts for severity – and an Exploit Prediction Scoring System (EPSS) score – which accounts for likelihood – to reduce the chance of successful cyberattacks.

Organizations should consider an attack surface management program to continuously discover, prioritize and remediate exposures on their attack surface. This ensures that opportunistic attackers cannot exploit any unknown or unmanaged asset.

How Palo Alto Networks Can Help

Get the full 2023 Unit 42 Attack Surface Threat Report for more global attack surface insights, trends and recommendations for best practices.

If attack surface management is new to your organization, or you’d like help with improving your program, Cortex Xpanse and Unit 42 Attack Surface Assessment can jump-start your journey. This assessment service gives you better visibility into your on-premises and cloud-based internet-connected assets and recommendations on prioritized actions to help you defend your organization.

Additional Resources

Wireshark Tutorial: Display Filter Expressions

Posted on by Brad Duncan

Executive Summary

Security professionals occasionally use Wireshark to review packet captures (pcaps) of malware-generated network traffic. To more efficiently review this type of activity, we suggest users customize their Wireshark installation.

In our previous tutorial, we customized Wireshark's column display. This tutorial introduces display filter expressions useful to review pcaps of malicious network traffic from infected Windows hosts.

This blog is the second in a series of Wireshark tutorials that provide customization options helpful for investigating malicious network traffic. It was first published in January 2019 and has been updated for 2023.

The pcaps in this tutorial contain traffic generated by Windows-based malware. Palo Alto Networks customers receive protection from these threats through Cortex XDR and our Next-Generation Firewall with Cloud-Delivered Security Services that include WildFire and Advanced Threat Prevention.

Related Unit 42 Topics pcap, Wireshark, Wireshark Tutorial

Requirements and Supporting Material

This tutorial requires readers to have reviewed and understand our previous Wireshark tutorial. Requirements also include using a recent version of Wireshark, at least version 3.6.2 or later. This tutorial uses Wireshark version 4.0.7 with a customized column display from the previous tutorial. As always, we recommend using the most recent version of Wireshark available for your environment.

Our requirements also include a basic knowledge of network traffic. Part of this knowledge is understanding the three-way handshake used for TCP connections. Furthermore, some of the pcaps for this tutorial contain malicious content from Windows-based infections, so we recommend using Wireshark in a non-Windows environment like BSD, Linux or macOS.

The five pcap files used in this tutorial are contained in a password-protected ZIP archive hosted at our GitHub repository. Download the ZIP file named Wireshark-tutorial-filter-expressions-5-pcaps.zip. Use infected as the password to extract the pcap files, as shown below in Figure 1.

Image 1 is a screenshot of the Palo Alto Networks Unit 42 Wireshark tutorials GitHub. A black arrow indicates to hit the download button on the page. A second black arrow points to the “password required” popup after selecting the zip file in the downloads folder. The password is entered. A final black arrow points to the contents of the zip file.
Figure 1. Acquiring pcap files for this tutorial.

The five extracted pcap files for this tutorial are:

  • Wireshark-tutorial-filter-expressions-1-of-5.pcap
  • Wireshark-tutorial-filter-expressions-2-of-5.pcap
  • Wireshark-tutorial-filter-expressions-3-of-5.pcap
  • Wireshark-tutorial-filter-expressions-4-of-5.pcap
  • Wireshark-tutorial-filter-expressions-5-of-5.pcap

Before continuing, we should ensure we are using a personal Wireshark profile, not the default.

Profile Check

During this tutorial, we save Wireshark filter expressions as filter buttons. Like the column changes from our previous tutorial, filter buttons will also be saved to your current Wireshark profile. The name of the personal profile from our previous tutorial is “Customized.”

To ensure you are using a personal profile, check the right side of the status bar, which shows the name of your current profile. You can also select “Configuration Profiles…” under the Edit menu to verify. Both options are shown below in Figure 2, revealing the customized profile name from our previous tutorial.

Image 2 is a Wireshark screenshot. Configuration profiles has been selected in the edit menu from the main menu. A popup window of the configuration profiles is inset in the screenshot. A red arrow indicates the customized profile is selected. A second red arrow indicates the bottom of the pane that shows the profile is customized.
Figure 2. Checking your current configuration profile in Wireshark.

After confirming use of a personal profile, we can examine the Wireshark display filter.

The Wireshark Display Filter

In Wireshark's default configuration, the display filter is a bar located immediately above the column display. This is where we type expressions to filter our view of Ethernet frames, IP packets or TCP segments from a pcap. When typing in the display filter bar, Wireshark offers a list of suggestions based on the typed text, as shown below in Figure 3.

Image 3 is a Wireshark screenshot displaying many filters. These are suggested based on what is typed into the filter menu.
Figure 3. Wireshark’s display filter offers suggestions based on what you type.

As long as the display filter bar remains red, the expression will not be accepted. Note the filter bar’s red color in Figure 3.

Open our first pcap named Wireshark-tutorial-filter-expressions-1-of-5.pcap in Wireshark. Type http.request in the display filter and hit Enter. If the filter bar is green, the expression has been accepted, and it should work properly, as shown below in Figure 4.

Image 4 is a Wireshark screenshot. The filter displayed is http.request.
Figure 4. Wireshark's display filter accepts an expression, and it works as intended.

If the filter bar turns yellow, the expression is accepted, but it may not work as intended. Yellow filter bar results are more common in earlier versions of Wireshark. For example, Figure 5 shows the filter expression dns && ip.addr || http.request using Wireshark version 3.6.2. This produces a yellow result in the filter bar, with a suggested solution at the bottom in the status bar.

Image 5 is a Wireshark screenshot. A red rectangle and a red arrow indicate it's a bad filter expression. Suggest parentheses around ‘&&’ within ‘||’. The inputted filter is yellow instead of green.
Figure 5. Bad filter expression for our first pcap in Wireshark version 3.6.2.

The results in Figure 5 reveal no HTTP request lines among the results in our column display. But using the same filter on the same pcap with Wireshark version 4.0.7 provides a green result and displays HTTP request lines, as shown below in Figure 6.

Image 6 is a Wireshark screenshot. The corrected filter is green. There is no suggestion to correct the filter language.
Figure 6. The same filter expression for our first pcap is green in Wireshark version 4.0.7.

This illustrates one of the differences between Wireshark’s version 3 series and version 4. As stated earlier, we recommend using the latest version of Wireshark available for your system.

Wireshark's display filter uses Boolean expressions, so we can specify values and chain them together. Below, Table 1 lists common Boolean operators used in Wireshark filter expressions.

Boolean Operator Expression Alternate Expression
Equals == eq
Not ! not
And && and
Or || or

Table 1. Boolean functions used in Wireshark display filter expressions.

Random examples of Wireshark display filter expressions include:

  • ip.addr eq 10.8.15[.]1 and dns.qry.name.len > 36
  • http.request && ip.addr == 10.8.15[.]101
  • http.request || http.response
  • dns.qry.name contains microsoft or icmp

Filtering for Web Traffic

Our previous Wireshark tutorial used the following filter for web traffic:

http.request or tls.handshake.type eq 1

The expression http.request reveals URLs for HTTP requests, and tls.handshake.type eq 1 shows domain names used in HTTPS or SSL/TLS traffic.

For web traffic generated by Windows hosts, results from this filter include HTTP requests over UDP port 1900. This HTTP traffic is Simple Service Discovery Protocol (SSDP). SSDP is used to discover plug-and-play devices and is not associated with normal web traffic. We can exclude SSDP traffic in our results by modifying our filter expression to:

(http.request or tls.handshake.type eq 1) and !(ssdp)

While parentheses in the above filter expression are not required in Wireshark version 4, we suggest including them to ensure filter expression compatibility with older versions of Wireshark. Use this filter on our first pcap, Wireshark-tutorial-filter-expressions-1-of-5.pcap and the results should appear similar to Figure 7.

Image 7 is a screenshot of a basic web filter used in Wireshark to examine traffic.
Figure 7. Using the basic web filter in our first pcap.

Reviewing the traffic shown in Figure 7 reveals several lines of unencrypted HTTP POST requests associated with Loki Bot malware to the URL hxxp://194.55.224[.]9/liuz/five/fre.php, which was reported to Threatfox in August 2023.

To examine the traffic, click on any of the lines for traffic to 194.55.224[.]9 to select the frame, then right-click to bring up a menu. From the menu, select “Follow” then “TCP Stream” or “HTTP Stream,” as shown below in Figure 8.

Image 8 is a Wireshark screenshot demonstrating how to follow a TCP stream. A black arrow indicates to click on a row within the traffic. The popup menu has “Follow” selected, and from a submenu, “TCP Stream” is selected.
Figure 8. Following a TCP stream in Wireshark.

This will bring up a new window, and we can review an ASCII representation of the content of this unencrypted HTTP traffic. Review this on your own to become familiar with Loki Bot command and control (C2) traffic.

Open our second pcap Wireshark-tutorial-filter-expressions-2-of-5.pcap in Wireshark. This is traffic from a standard variant IcedID (Bokbot) infection. It contains HTTP traffic to vrondafarih[.]com and HTTPS traffic to both magiketchinn[.]com and magizanqomo[.]com. All three were identified as IcedID-related domains in July 2023.

Figure 9 shows these IcedID-associated domains in our second pcap using the basic web filter in Wireshark.

Image 9 is a Wireshark screenshot. Red arrows pointing to the rows of traffic indicate the domains associated with an IcedID infection.
Image 9 is a Wireshark screenshot. Red arrows pointing to the rows of traffic indicate the domains associated with an IcedID infection.

Creating Filter Buttons

Complex filter expressions are very tedious to type in Wireshark's filter bar every time you need them. Fortunately, we can save any of our typed expressions as filter buttons.

On the right side of the Wireshark filter bar is a plus sign to add a filter button. Ensure we are still using the basic web filter shown in Figures 7, 8 and 9. After ensuring this filter has been implemented, click on the plus sign as shown below in Figure 10.

Image 10 is a Wireshark screenshot. A red rectangle indicates how to add a filter button after clicking the +. The options are Filter Button Preferences, Label, Filter, and Comment. Then the user can Cancel or hit OK.
Figure 10. Clicking the plus sign to add a filter button.

Clicking the plus sign generates a temporary panel immediately under the filter bar, as noted above in Figure 10. This panel has three fields: Label, Filter and Comment. The Filter field should contain the expression already implemented in the filter bar. Since this is our basic web filter, type basic in the Label field and click the OK button as shown below in Figure 11.

Image 11 is a Wireshark screenshot where a basic filter is being created. A black arrow indicates the label is “basic.” A second black arrow indicates to hit the OK button.
Figure 11. Creating our basic web filter button.

This should create a button to the right of Wireshark's filter bar labeled "basic" as shown below in Figure 12. Wireshark filter buttons have no borders and look like labels, but they function as buttons. Anytime you need this basic web filter, just left-click on it.

Image 12 is a zoomed-in Wireshark screenshot. A black arrow points to the basic filter button.
Figure 12. The button for our basic web filter.

For this tutorial, we should create the following filter buttons listed below in Table 2.

Button Label Filter Expression
basic basic (http.request or tls.handshake.type eq 1) and !(ssdp)
basic+ basic (http.request or tls.handshake.type eq 1 or (tcp.flags.syn eq 1 and tcp.flags.ack eq 0)) and !(ssdp)
basic+dns basic (http.request or tls.handshake.type eq 1 or (tcp.flags.syn eq 1 and tcp.flags.ack eq 0) or dns) and !(ssdp)

Table 2. Filter buttons to more fully investigate malicious web traffic.

When examining suspicious traffic in Wireshark, we should use a progressive method. Start simple with our basic web filter, then check for other non-web traffic using the “basic+” filter.

In Table 2, the “basic+” filter expression displays the same information as our “basic” filter, but it includes TCP segments with the SYN flag and not the ACK flag by adding or (tcp.flags.syn eq 1 and tcp.flags.ack eq 0). This displays TCP SYN segments that reveal the start of a TCP stream. With this filter, we can find non-web traffic in a pcap.

The “basic+” filter also reveals any TCP connection attempts that failed. Depending on the IP address, repeated and failed TCP connection attempts could indicate a C2 server that was off-line when the pcap was recorded.

After checking the “basic+” filter, we should review the “basic+dns” filter to check for any notable DNS activity.

In Table 2, the “basic+dns” filter expression shows the same data as our “basic+” filter, but it includes or dns. This filter reveals any DNS queries in the pcap. It is very helpful for determining domain names associated with non-web traffic.

Furthermore, if a malware sample’s C2 server is offline when the pcap was recorded, this filter could reveal one or more C2 domains associated with any failed connection attempts. Finally, this filter might reveal examples of DNS tunneling.

Add the “basic+” and “basic+dns” filters as shown below in Figure 13 and Figure 14. After adding the filter buttons, we should see all three to the right of Wireshark’s filter bar as shown below in Figure 15.

Image 13 is a Wireshark screenshot. Black arrows indicate create a “basic-plus” filter. The options are Filter Button Preferences, Label, Filter, and Comment. Then the user can Cancel or hit OK. The label entered is “basic+.”
Figure 13. Creating the “basic+” filter button.
Image 14 is a Wireshark screenshot. Black arrows indicate create a “basic-plus-dns” filter. The options are Filter Button Preferences, Label, Filter, and Comment. Then the user can Cancel or hit OK. The label entered is “basic+dns.” Entered into the filter is gs.ack eq 0) or dns) and !(ssdp).
Figure 14. Creating the “basic+dns” filter button.
Image 15 is a zoomed-in Wireshark screenshot. The new filter buttons are displayed in a row: basic, basic+ and basic+dns.
Figure 15. Our newly created filter buttons beside the Wireshark filter bar.

With our three newly created filter buttons in place, we can explore other types of malicious traffic.

Filtering for Non-Web Traffic

Open our third pcap Wireshark-tutorial-filter-expressions-3-of-5.pcap in Wireshark. This pcap contains post-infection traffic generated by a Remote Access Tool (RAT) malware called Ave Maria RAT (also known as Warzone RAT).

Using our basic web filter, nothing obvious stands out in the traffic. However, by using our “basic+dns” web filter and scrolling through the results, we can see things more clearly. We can find a DNS query for adaisreal.ddns[.]net that resolves to 87.121.221[.]212, then a TCP segment to that IP address with the SYN flag over TCP port 7888, as shown below in Figure 16.

Image 16 is a Wireshark screenshot. The filter used is the basic+dns filter. a black rectangle indicates the standard query used and the standard query response. The standard query is 0xdab7 A adaisreal dot ddns dot net. The standard query response is 0xdab7 A adaisreal dot ddns dot net A 87 dot 121 dot 221 dot 212. The SYN flag is also indicated.
Figure 16. Ave Maria RAT C2 traffic found in our third pcap.

This is just one example, but different RATs and other types of malware also generate similar types of non-web traffic. Our “basic+dns” filter provides a way to search for malicious non-web activity.

Filtering for FTP Traffic

Some infection traffic uses common protocols that Wireshark can easily decode. Our fourth pcap Wireshark-tutorial-filter-expressions-4-of-5.pcap contains post-infection activity caused by a malware executable that generates FTP traffic. Our “basic+dns” filter reveals traffic over TCP port 21 and another TCP port after a DNS query to valvulasthermovalve[.]cl as shown below in Figure 17.

Image 17 is a Wireshark screenshot. The filter used is the basic+dns filter. a black rectangle indicates the standard query used and the standard query response. The standard query is 0x583f A valvulasthermovalve dot cl. The standard query response is 0x583f A valvulasthermovalve dot cl A 190 dot 107 dot 177 dot 239. The SYN flag is also indicated.
Figure 17. Finding FTP traffic from our fourth pcap.

In Figure 17, we can also see HTTPS traffic to api.ipify[.]org immediately before the FTP activity. While this domain is not inherently malicious, malware often uses the service to check the IP address of an infected host.

Our “basic+dns” filter can help find unencrypted FTP traffic, but other filter expressions would better fit an FTP search. Two basic Wireshark filters for unencrypted FTP traffic are shown below in Table 3.

Filter Expression Description
ftp FTP activity in the control channel (TCP port 21)
ftp-data FTP activity in the data channel (ephemeral TCP port)

Table 3. Basic FTP searches for Wireshark.

A general-purpose filter expression to review unencrypted FTP activity is:

ftp.request.command or (ftp-data and tcp.seq eq 1)

Type the above expression into Wireshark’s display filter bar and hit enter. The results should look similar to the screenshot in Figure 18.

Image 18 is a Wireshark screenshot. The filter used, ftp.request.command or (ftp-data and tcp.seq eq 1), allows the end user to see the flow of FTP activity.
Figure 18. Filtering to see the flow of FTP activity in Wireshark.

Figure 18 shows the username and password for this compromised FTP site, then a STOR command to send an HTML file to the FTP server. This represents stolen data being exfiltrated from the infected Windows host. We can follow the TCP streams to review the FTP commands and examine the stolen data. If needed, you can save this filter expression as a filter button for future use.

Filtering for Email (Spambot) Traffic

In addition to FTP, malware can use other common protocols for malicious traffic. Spambot malware can turn an infected host into a spambot designed to constantly send email messages. This is characterized by a large amount of DNS requests to various mail servers followed by SMTP traffic on TCP ports 25, 465, 587 and other ports less-commonly associated with SMTP traffic.

Our fifth pcap, Wireshark-tutorial-filter-expressions-5-of-5.pcap, contains post-infection spambot traffic. Open that pcap and type the following expression into Wireshark’s filter bar:

smtp or dns

The results should look similar to Figure 19.

Image 19 is a Wireshark screenshot. Using the filter smtp or dns, the end user can review spambot activity.
Figure 19. Quick review of spambot activity in our fifth pcap.

If you scroll through the results, you should find several DNS queries for various mail server domains and different SMTP statements on the far right under the “Info” column.

Now type the following filter into the filter bar:

smtp.req.command

The results shown below in Figure 20 reveal the infected host contacted several different IP addresses for mail servers in a relatively short amount of time. Note how most of these SMTP requests state STARTTLS, which establishes an encrypted tunnel after the initial SMTP connection. Most email traffic is encrypted, and most spambot activity is also encrypted.

Image 20 is a Wireshark screenshot of the traffic displayed when the filter smtp.req.command is used.
Figure 20. Filtering on smtp.req.command in our fifth pcap.

However, spambot traffic might have unencrypted email messages we can review. To find these messages, type the following expression in Wireshark’s filter bar:

smtp.data.fragment

This should reveal seven results in the column display as shown below in Figure 21. We can follow the TCP stream for any of these to further investigate these messages.

Image 21 is a Wireshark screenshot of the traffic displayed when the filter smtp.req.command is used.
Figure 21. Filtering for emails sent over unencrypted spambot traffic.

While not extensive, these are the most common filter expressions useful for examining spambot traffic.

Conclusion

Wireshark display filter expressions are necessary to understand the contents of a pcap. When combined with an optimized column display, effective filters can immensely help security professionals investigate suspicious network activity.

Our next tutorial in this series reviews how to identify hosts and users when investigating suspicious network activity.

Pcaps used in this tutorial contain traffic generated by Windows-based malware. Palo Alto Networks customers receive protection from these threats through Cortex XDR and our Next-Generation Firewall with Cloud-Delivered Security Services that include WildFire, Advanced Threat Prevention and Advanced URL Filtering.

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

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

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

Indicators of Compromise

The following are indicators of malicious activity from the pcaps used in this tutorial.

URL hxxp://194.55.224[.]9/liuz/five/fre.php
Description Loki Bot C2 URL noted as early as 2023-08-15
IcedID C2 domains noted on 2023-07-27:
  • vrondafarih[.]com - HTTP traffic
  • magiketchinn[.]com - HTTPS traffic
  • magizanqomo[.]com - HTTPS traffic

 

URL 87.121.221[.]212:7888 - tcp://adaisreal.ddns[.]net:7888/
Description C2 for Ave Maria RAT (Warzone RAT) noted as early as 2023-06-05
SHA256 hash adfa401cdfaac06df0e529bc9d54b74cea9a28d4266a49edafa5b8e04e3b3594
File size 604,672 bytes
Filename unknown
File description Windows executable (EXE), info stealer using FTP for data exfiltration

 

URL 190.107.177[.]239:21 - fxp://valvulasthermovalve[.]cl/
Description Noted as early as 2023-06-07, FTP server on legitimate site used for data exfiltration, also used by the above malware sample
SHA256 hash f24259e65a935722c36ab36f6e4429a1d0f04c0ac3600e4286cc717acc5b03d7
File size 134,140 bytes
Filename Details-3922941.one
File description OneNote file as an attachment in unencrypted spambot emails for Emotet on 2023-03-16

 

Additional Resources

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

Default Heading

Read the article Right Arrow