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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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).
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.
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.
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.
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.
Disable all HTTP and HTTPs traffic to the MOVEit Transfer host.
Review, delete and reset any unauthorized files and user accounts.
Apply the relevant patch.
Verify all malicious files and user accounts have been deleted/reset.
Reset the service account credentials again.
Re-enable all HTTP and HTTPs traffic to the MOVEit Transfer environment
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.
1
2
3
4
5
6
7
// Description: Look for MOVEit IIS process writing an aspx file to disk. Review the results for possible web shells.
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.
Figure 3. Advanced Threat Prevention overview.
Cloud-Delivered Security Services for the Next-Generation Firewall
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 CloudWAAS customers are protected from this threat through the App Firewall SQL Injection protection.
Figure 4. A screenshot of the Cortex Xpanse interface, showing the MOVEit Transfer rule enabled.
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.
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.
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.)
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.
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.
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.
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. 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.
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.
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.
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.
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:
Figure 10. 81.19.135[.]21 services scan.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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
Mustang Panda, BRONZE PRESIDENT, TA416, RedDelta and Earth Preta
Timeline of Activity
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.”
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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=.
Dumping Lsass: The attackers tried to dump the Lsass process using the procdump tool.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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
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.
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.
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.
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.
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.
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.
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:
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:
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:
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.
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.
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.
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.
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.
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.
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.
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.
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”
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.
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:
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:
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
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.
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.
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.
Figure 1a. Capibar code snippet loading XML received from its C2.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.
Figure 2. Kazuar injected into explorer.exe and prevented by Cortex XDR.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.
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.
Figure 5. Snake execution detection shown in Cortex XDR in detect mode.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.
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.
Figure 8. QUIETCANARY’s alerts shown in Cortex XDR.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.
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.
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.
Figure 11. Kopiluwak’s reconnaissance commands.
Figure 12 shows Cortex XDR raising an execution prevention alert for Kopiluwak.
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.
Figure 13. Topinambour execution detection shown in Cortex XDR in detect mode.
Figure 14 shows the prevention alert pop-up raised by Cortex XDR.
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.
Figure 15. Crutch execution detection shown in Cortex XDR in detect mode.Figure 16. Crutch execution prevention alert shown in Cortex XDR.
Malware: ComRAT
Aliases: Agent.btz
Malware Type: Backdoor
First Seen: 2007
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.
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.
Figure 19. Carbon creates a service that loads the additional components, which is shown in Cortex XDR in detect mode.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.
Figure 21. HyperStack creates a service for persistence shown in Cortex XDR in detect mode.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. 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.
Figure 24. TinyTurla prevention shown in Cortex XDR in detect mode.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.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
Figure 13. Creating the “basic+” filter button.Figure 14. Creating the “basic+dns” filter button.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.
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.
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.
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.
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.
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.
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.
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.
Earlier this month, our quiz Crossing the Line: Unit 42 Wireshark Quiz for RedLine Stealer introduced a packet capture (pcap) from July 2023 with a RedLine Stealer infection. This article provides answers to the quiz, and it offers a more in-depth look at RedLine Stealer traffic.
Traffic for this quiz occurred in an Active Directory (AD) environment during July 2023. Details of the Local Area Network (LAN) environment for the pcap follow.
Local Area Network (LAN) Details
LAN segment range: 10.7.10[.]0/24 (10.7.10[.]1 through 10.7.10[.]255)
Domain: coolweathercoat[.]com
Domain controller IP address: 10.7.10[.]9
Domain controller hostname: WIN-S3WT6LGQFVX
LAN segment gateway: 10.7.10[.]1
LAN segment broadcast address: 10.7.10[.]255
This quiz requires Wireshark, and we recommend using the latest version, since it has more features, capabilities and bug fixes over previous versions.
We also recommend readers customize their Wireshark display to better analyze web traffic. A list of tutorials and videos is available. As always, we recommend using Wireshark in a non-Windows environment like BSD, Linux or macOS when analyzing malicious Windows-based traffic.
To obtain the pcap, visit our GitHub repository, download the July 2023 ZIP archive and extract the pcap. Use infected as the password to unlock the ZIP archive.
Quiz Questions
For this RedLine Stealer infection, we ask participants to answer the following questions previously described in our standalone quiz post.
What is the date and time in UTC the infection started?
What is the IP address of the infected Windows client?
What is the MAC address of the infected Windows client?
What is the hostname of the infected Windows client?
What is the user account name from the infected Windows host?
What type of information did this RedLine Stealer try to steal?
Quiz Answers
Answers for this Wireshark quiz follow:
The infection started on July 10, 2023, at 22:39 UTC.
Infected Windows client IP address: 10.7.10[.]47
Infected Windows client MAC address: 80:86:5b:ab:1e:c4
Infected Windows hostname: DESKTOP-9PEA63H
Infected Windows client IP user account name: rwalters
Information RedLine malware attempted to steal:
Various types of files on the victim's desktop
Various types of files in the victim's Documents folder
User data for Chrome, Chromium, Edge, Opera, Vivaldi and various other web browsers
Data for various cryptocurrency wallets and browser plugins for those cryptocurrency wallets
API keys and login credentials from other applications
Pcap Analysis: Victim Details
The following analysis uses Wireshark customized from our tutorials. Applying the basic web filter reveals a single internal IP address at 10.7.10[.]47 as the only source IP address, as shown below in Figure 1. Using the frame details, we can correlate this source IP with a MAC address at 80:86:5b:ab:1e:c4.
Figure 1. Determining the victim’s IP address and MAC address in Wireshark.
Determine the victim’s hostname by filtering on NetBIOS Name Service (NBNS) traffic. Use the Wireshark filter nbns to find DESKTOP-9PEA63H, as shown below in Figure 2.
Figure 2. Determining the victim’s Windows hostname from NBNS traffic in Wireshark.
Verify the victim’s hostname and Windows user account name through Kerberos authentication traffic. Filter on kerberos.CNameString to find the Windows user account name rwalters, as shown below in Figure 3.
Figure 3. Determining the victim’s Windows user account name from Kerberos traffic in our customized Wireshark setup.
Pcap Analysis: Malicious Web Traffic
Go back to the basic web filter to find three unencrypted HTTP GET requests in our pcap as shown below in Figure 4. Two of the GET requests are to 623start[.]site. The other GET request is a URL to hxxp://guiatelefonos[.]com/data/czx.jpg.
Figure 4. Three unencrypted HTTP GET requests seen in the web traffic.
Unencrypted HTTP GET requests not caused by the operating system are worth investigating. Follow the TCP stream for either of the HTTP GET requests to 623start[.]site. This should appear as TCP stream 68, and the User-Agent line in the HTTP request headers indicate this traffic was issued through Windows PowerShell as shown below in Figure 5.
While User-Agent strings can be spoofed by malware or web browser extensions, WindowsPowerShell in the User-Agent line is a reliable indicator that this traffic was generated by a PowerShell script. URLs for these two HTTP GET requests are:
These requests both returned a 404 HTTP Error from the server. The first HTTP request reported an antivirus used on the victim host. In this case, av=Windows%20Defender indicates Windows Defender is the antivirus. The second URL reports an install status for this malware.
In our pcap, the last unencrypted HTTP GET request is hxxp://guiatelefonos[.]com/data/czx.jpg. Follow the TCP stream for this GET request. The TCP stream reveals this URL redirected to an HTTPS version of the same URL as shown below in Figure 6.
Figure 6. HTTP URL to guiatelefonos[.]com redirected to an HTTPS URL.hxxps://guiatelefonos[.]com/data/czx.jpg has been reported to URLhaus as hosting a RedLine Stealer malware binary, and this specific RedLine Stealer malware binary is associated with the URL.
Pcap Analysis: RedLine Stealer Data Exfiltration
Command and Control (C2) traffic for RedLine Stealer uses TCP traffic over an ephemeral port. To find this traffic in our pcap, use the following Wireshark filter:
tcp.flags eq 0x0002 and !(tcp.port eq 443) and !(tcp.port eq 80) and !(ip.dst eq 10.7.10.0/24)
This filter searches for TCP SYN segments that represent the start of a TCP stream. The search excludes any web traffic over TCP port 80 and TCP port 443. This filter also excludes any SYN segments sent to the internal IP addresses from this AD environment. The result reveals a single TCP SYN segment sent to 194.26.135[.]119 over TCP port 12432 as shown below in Figure 7.
Figure 7. Finding the Redline Stealer C2 traffic in Wireshark.
Follow the TCP stream to examine post-infection traffic from this RedLine Stealer infection. The window should show TCP stream 71 as shown below in Figure 8.
Figure 8. TCP stream for Redline Stealer C2 traffic generated by this infection.
In Figure 8, initial strings from the TCP stream include the C2 channel at tcp://194.26.135[.]119:12432/ and URLs using tempuri[.]org. The term "tempuri" is short for "temporary URI," and the domain tempuri[.]org is a placeholder namespace URI used in Microsoft development tools like Visual Studio. This tempuri domain is not seen in any other traffic from our RedLine Stealer infection.
To better understand what this RedLine Stealer sample is looking for, select data sent from the server to the infected Windows host as shown below in Figure 9.
Figure 9. TCP stream viewing data sent from the C2 server to the infected Windows host.
Data from the RedLine C2 server is requesting various types of user information from the victim’s host. Figure 10 highlights data this infection is looking for under the victim’s user profile.
Figure 10. Information searched for under the victim’s user profile.
The list includes wildcard searches on the victim’s desktop and the victim’s Documents folder. This includes text files, Word documents and cryptocurrency wallet files as shown below.
The list then indicates data from different applications, based on their expected locations under the victim’s AppData directory in their user profile. The list is shown below in alphabetical order.
%USERPROFILE%\AppData\Local\360Browser\Browser\User Data
%USERPROFILE%\AppData\Local\7Star\7Star\User Data
%USERPROFILE%\AppData\Local\Amigo\User\User Data
%USERPROFILE%\AppData\Local\Battle.net
%USERPROFILE%\AppData\Local\BraveSoftware\Brave-Browser\User Data
%USERPROFILE%\AppData\Local\CatalinaGroup\Citrio\User Data
%USERPROFILE%\AppData\Local\CentBrowser\User Data
%USERPROFILE%\AppData\Local\Chedot\User Data
%USERPROFILE%\AppData\Local\Chromium\User Data
%USERPROFILE%\AppData\Local\Chromodo\User Data
%USERPROFILE%\AppData\Local\CocCoc\Browser\User Data
%USERPROFILE%\AppData\Local\Comodo\Dragon\User Data
%USERPROFILE%\AppData\Local\Comodo\User Data
%USERPROFILE%\AppData\Local\Coowon\Coowon\User Data
%USERPROFILE%\AppData\Local\CryptoTab Browser\User Data
%USERPROFILE%\AppData\Local\Elements Browser\User Data
%USERPROFILE%\AppData\Local\Epic Privacy Browser\User Data
Scroll down a little further, and we find what appears to be various cryptocurrency wallets this infection looked for as shown below in Figure 11. The data includes identifiers for extensions used by Chromium-based web browsers like Google Chrome and Microsoft Edge.
Figure 11. Data on cryptocurrency wallet programs and their associated browser extensions.
These cryptocurrency wallet browser extensions are listed below, sorted alphabetically by wallet name. (Read: Chromium-based extension string|extension name.)
fhilaheimglignddkjgofkcbgekhenbh|AtomicWallet
fhbohimaelbohpjbbldcngcnapndodjp|BinanceChain
fihkakfobkmkjojpchpfgcmhfjnmnfpi|BitAppWallet
aodkkagnadcbobfpggfnjeongemjbjca|BoltX
odbfpeeihdkbihmopkbjmoonfanlbfcl|BraveWallet
aeachknmefphepccionboohckonoeemg|Coin98Wallet
hnfanknocfeofbddgcijnmhnfnkdnaad|Coinbase
blnieiiffboillknjnepogjhkgnoapac|EqualWallet
hpglfhgfnhbgpjdenjgmdgoeiappafln|GuardaWallet
nanjmdknhkinifnkgdcggcfnhdaammmj|GuildWallet
fnnegphlobjdpkhecapkijjdkgcjhkib|HarmonyWallet
kncchdigobghenbbaddojjnnaogfppfj|iWallet
cjelfplplebdjjenllpjcblmjkfcffne|JaxxxLiberty
pdadjkfkgcafgbceimcpbkalnfnepbnk|KardiaChain
kpfopkelmapcoipemfendmdcghnegimn|LiqualityWallet
dngmlblcodfobpdpecaadgfbcggfjfnm|MaiarDeFiWallet
afbcbjpbpfadlkmhmclhkeeodmamcflc|MathWallet
nkbihfbeogaeaoehlefnkodbefgpgknn|Metamask
nlbmnnijcnlegkjjpcfjclmcfggfefdm|MewCx
lpfcbjknijpeeillifnkikgncikgfhdo|NamiWallet
jbdaocneiiinmjbjlgalhcelgbejmnid|NiftyWallet
fhilaheimglignddkjgofkcbgekhenbh|Oxygen
mgffkfbidihjpoaomajlbgchddlicgpn|PaliWallet
bfnaelmomeimhlpmgjnjophhpkkoljpa|Phantom
fnjhmkhhmkbjkkabndcnnogagogbneec|RoninWallet
nkddgncdjgjfcddamfgcmfnlhccnimig|SaturnWallet
aiifbnbfobpmeekipheeijimdpnlpgpp|TerraStation
cgeeodpfagjceefieflmdfphplkenlfk|TonCrystal
ibnejdfjmmkpcnlpebklmnkoeoihofec|Tronlink
amkmjjmmflddogmhpjloimipbofnfjih|Wombat
hmeobnfnfcmdkdcmlblgagmfpfboieaf|XdefiWallet
ffnbelfdoeiohenkjibnmadjiehjhajb|YoroiWallet
Scroll to the end of the stream, and we find this infection searches for API keys and login data for other programs that might be installed on the host as shown below in Figure 12.
Figure 12. Data search includes API keys and other sensitive data associated with various applications.
This list includes various cloud platforms, social media applications, and miscellaneous tools. An alphabetically-sorted list follows.
ALGOLIA_API_KEY
AMAZON_AWS_ACCESS_KEY_ID
AMAZON_AWS_SECRET_ACCESS_KEY
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AZURE_CLIENT_ID
AZURE_CLIENT_SECRET
AZURE_PASSWORD
AZURE_USERNAME
binance_api
binance_secret
BITTREX_API_KEY
BITTREX_API_SECRET
CF_PASSWORD
CF_USERNAME
CI_DEPLOY_PASSWORD
CI_DEPLOY_PASSWORD
CI_DEPLOY_USER
CI_DEPLOY_USER
CI_JOB_JWT
CI_JOB_JWT_V2
CI_JOB_TOKEN
CIRCLE_TOKEN
CODECLIMATE_REPO_TOKEN
CONSUMER_KEY
CONSUMER_SECRET
COVERALLS_REPO_TOKEN
DIGITALOCEAN_ACCESS_TOKEN
DOCKER_EMAIL
DOCKER_PASSWORD
DOCKER_USERNAME
DOCKERHUB_PASSWORD
FACEBOOK_ACCESS_TOKEN
FACEBOOK_APP_ID
FACEBOOK_APP_SECRET
FIREBASE_TOKEN
FOSSA_API_KEY
GH_ENTERPRISE_TOKEN
GH_TOKEN
GITLAB_USER_LOGIN
GOOGLE_API_KEY
GOOGLE_APPLICATION_CREDENTIALS
HEROKU_API_KEY
HEROKU_API_USER
MAILGUN_API_KEY
MCLI_PRIVATE_API_KEY
MCLI_PUBLIC_API_KEY
MSI_ENDPOINT
MSI_SECRET
NGROK_AUTH_TOKEN
NGROK_TOKEN
NPM_AUTH_TOKEN
OKTA_AUTHN_GROUPID
OKTA_CLIENT_ORGURL
OKTA_CLIENT_TOKEN
OKTA_OAUTH2_CLIENTID
OKTA_OAUTH2_CLIENTSECRET
OS_PASSWORD
OS_USERNAME
PERCY_TOKEN
SAUCE_ACCESS_KEY
SAUCE_USERNAME
SENTRY_AUTH_TOKEN
SLACK_TOKEN
square_access_token
square_oauth_secret
STRIPE_API_KEY
STRIPE_DEVICE_NAME
SURGE_LOGIN
SURGE_TOKEN
TOKEN
TRAVIS_OS_NAME
TRAVIS_SECURE_ENV_VARS
TRAVIS_SUDO
TWILIO_ACCOUNT_SID
VAULT_CLIENT_KEY
VAULT_TOKEN
VULTR_ACCESS
VULTR_SECRET
Next, switch the TCP stream window to view data sent from the infected host to the server. This reveals indicators that a screenshot of the infected victim’s Windows desktop was sent to the C2 server as shown below in Figure 13.
Figure 13. Data exfiltrated from the infected Windows host includes a screenshot of the victim’s desktop.
We can extract the screenshot from this traffic. First, show the data from the infected Windows host to the C2 server as "Raw," then save it, as shown below in Figure 14.
Figure 14. Saving raw data from infected host to C2 server in the TCP stream window.
Open the saved binary in a hex editor, and delete everything before the PNG image file starts as shown below in Figure 15.
Figure 15. Carving the saved binary in a hex editor.
Save the edited file under a new name using the file extension .png. The first byte of your newly saved file should be 0x89. This newly saved file still contains other non-image data, but we can see the screenshot with an image viewer as shown below in Figure 16.
Figure 16. Viewing the screenshot image from the infected Windows host.
In Figure 16, the screenshot reveals a PowerShell window with data from a web traffic connection.
After reviewing the image, return to the TCP stream (tcp.stream eq 71), view it as ASCII data and select traffic only going from the infected Windows host to the C2 server. Scroll to the end to review additional data sent to the C2 server.
Knowing a little more about the infected Windows host will help us better understand this data. The infected Windows host was a minimal installation, and it only had one set of login credentials stored in the Microsoft Edge browser. The host had just one Word document stored in the user’s Documents folder. The file was named Top_secret_ducment.docx.
Near the end of this TCP stream we find a list of running processes as shown below in Figure 17. We can also find hardware information from the infected host, login credentials from the Edge browser, and the file named Top_secret_ducment.docx.
Figure 17. Running processes, hardware info, login credentials, and Word document exfiltrated from the infected Windows host.
The running process list in Figure 17 also reveals a process for powershell.exe running a file at C:\Users\rwalters\Documents\mystery_file.ps1. That .ps1 file generated the infection traffic for this Wireshark quiz.
Conclusion
This post provides answers and analysis for our Unit 42 Wireshark quiz featuring a RedLine Stealer infection from July 2023. We now have a better idea of the information this malware looks for, and the types of data it sends from an infected host. RedLine Stealer is important to identify and stop, because it targets sensitive information like login credentials and cryptocurrency wallet info.
Since many security professionals lack access to full packet capture, they may also lack experience with RedLine Stealer and other malware traffic. Training material like this Wireshark quiz is designed to help. Pcap analysis is a very useful skill when investigating a malware infection.
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
Traffic from the pcap related to the RedLine Stealer infection:
hxxp://623start[.]site/?status=start&av=
hxxp://623start[.]site/?status=install
hxxp://guiatelefonos[.]com/data/czx.jpg
hxxps://guiatelefonos[.]com/data/czx.jpg
tcp://194.26.135[.]119:12432/
Files associated with traffic from this RedLine Stealer infection:
Wireshark is a free protocol analyzer that can record and display packet captures (pcaps) of network traffic. IT professionals use this tool to investigate a wide range of network issues. Security professionals also use Wireshark to review traffic generated from malware.
What makes Wireshark so useful? It is very customizable. Wireshark’s default column display provides a wealth of information, but you should customize the columns to meet your specific needs.
This article is the first in a series of Wireshark tutorials that provides customization options helpful for investigating malicious network traffic. It was first published in August 2018 and has been updated for 2023.
We recommend using a non-Windows environment like BSD, Linux or macOS. Pcaps from Windows infections may contain malicious binaries that present a risk of infection when using Wireshark on a Windows computer. For this tutorial, we use the Xubuntu Linux distro.
If possible, review pcaps using the most recent version of Wireshark for your environment. Recent versions have more features, capabilities and bug fixes than older versions. We recommend at least version 3.6.2 or later. In this tutorial, we use Wireshark version 4.0.7.
Wireshark users must have a basic understanding of network traffic, and this series of tutorials focuses on IPv4 traffic. The term “basic understanding” means different things to different people, but the knowledge does not have to be extensive.
For example, readers should know the difference between a public IPv4 address and an internal, nonroutable IPv4 address. Basic network knowledge includes recognizing TCP and UDP traffic and knowing about DNS. Readers should also have some idea how network traffic is routed between an internal client like a desktop computer and an external server like a website.
Ultimately, this series of tutorials assumes readers have some sort of background and interest in reviewing malicious network traffic.
Supporting Material
The pcap for this tutorial is hosted at our GitHub repository. Download the pcap as shown below in Figure 1.
Figure 1. Saving the pcap for this tutorial from our GitHub repository.
The name of your downloaded ZIP archive should be Wireshark-tutorial-column-setup.pcap.zip. Use infected as the password to unlock the ZIP archive as shown below in Figure 2.
Figure 2. Extracting our pcap from the password-protected zip archive.
The extracted pcap for this tutorial is named Wireshark-tutorial-column-setup.pcap. Now that we have our pcap, let’s check our version of Wireshark.
Wireshark Version Check
Without any pcap loaded, Wireshark displays its version number on the welcome screen as shown below in Figure 3.
Figure 3. Wireshark’s version number displayed on its welcome screen.
We can also select “About Wireshark” under the Help menu to view the version number as shown below in Figure 4.
Figure 4. Wireshark’s version number from About Wireshark under the Help menu.
Configuration Profiles
After confirming you have Wireshark version 3.6.2 or newer, select Configuration Profiles under Wireshark’s Edit menu. Make a copy of the default configuration profile by clicking the Copy button as shown below in Figure 5.
Figure 5. Copying the default configuration profile in Wireshark.
After copying the default profile, give it a new name. We suggest changing the name to “Customized” as shown below in Figure 6.
Figure 6. Renaming the copy of the default configuration profile.
If this newly created profile is still selected when we close the Configuration Profiles window, any customizations to Wireshark will be stored to this newly created profile.
Web Traffic and the Default Wireshark Column Display
Malware distribution frequently occurs through web traffic. Data exfiltration and command and control activity can also use web traffic. However, when reviewing such malicious activity, Wireshark's default column options are not ideal.
Fortunately, we can customize Wireshark’s column display to provide a better view of web traffic. To view the default layout of Wireshark, open the pcap we previously downloaded for this tutorial. The default layout for Wireshark version 4.0.7 is shown below in Figure 7.
Figure 7. Default layout for Wireshark version 4.0.7 after opening our pcap.
Examine your column display. Wireshark’s default columns are listed below in Table 1.
Column Name
Column Description
No.
Frame number from the beginning of the pcap. The first frame is always 1.
Time
Seconds broken down to the microsecond from the first frame of the pcap. The first frame is always 0.000000.
Source
Source address, commonly an IPv4, IPv6 or Ethernet address.
Destination
Destination address, commonly an IPv4, IPv6 or Ethernet address.
Protocol
Protocol used in the Ethernet frame, IP packet or TCP segment (ARP, DNS, TCP, HTTP, etc.).
Length
Length of the frame in bytes.
Info
Information about the Ethernet frame, IP packet or TCP segment.
Table 1. Columns used in Wireshark’s default display.
To better examine Windows-based malware traffic, this tutorial customizes Wireshark to use the columns shown below in Table 2.
Column Name
Column Description
Time
Date and time in UTC.
Source address
IPv4, IPv6 or Ethernet source address.
Source port
TCP or UDP port used by the source address for IPv4 or IPv6 traffic.
Destination address
IPv4, IPv6 or Ethernet destination address.
Destination port
TCP or UDP port used by the destination address for IPv4 or IPv6 traffic.
Domain
Domain name used in HTTP or HTTPS traffic.
Info
Information about the Ethernet frame, IP packet or TCP segment.
Table 2. Columns for our customized Wireshark column display.
To customize our Wireshark column display, we will first change the Time column to show the date and time in Universal Coordinated Time (UTC).
Changing Date and Time to UTC
When publicly sharing information about a malware infection, the recipients can be in any part of the world. Due to the different time-zones, a standard format for reporting the time of malicious activity is UTC.
To change Wireshark's time display format, under the View menu, go to "Time Display Format," and change the value from "Seconds Since Beginning of Capture" to "UTC Date and Time of Day." Use the same menu path to change the resolution from "Automatic" to "Seconds." Figure 8 shows the menu paths for these options.
Figure 8. Changing Wireshark’s time display format to UTC date and time.
When finished, the column display shows the UTC date and time as noted below in Figure 9. Now when we review a pcap, we immediately know the date and time of the network traffic.
Figure 9. UTC date and time in our updated Wireshark column display.
Our next step in customizing Wireshark is to remove columns we do not need for our day-to-day work.
Removing Columns
The No., Protocol and Length columns are not necessary when reviewing web-based traffic, so we suggest removing them. To remove these columns, right-click on the column header and select "Remove this Column" from the menu as shown below in Figure 10.
Figure 10. Removing the No. column in Wireshark.
Your updated column display should now show only four columns: Time, Source, Destination and Info, as noted in Figure 11.
Figure 11. The four columns remaining in our updated column display.
After removing the unnecessary columns, we are ready to add new columns to our Wireshark display.
Adding Columns
We can add columns in Wireshark using the Column Preferences window. To open this window, right-click on any of the column headers, then select “Column Preferences…” in the resulting menu as shown below in Figure 12.
Figure 12. Getting to the Column Preferences window.
This brings up the Column Preferences window, which lists all of Wireshark’s columns, viewed or hidden. Near the bottom-left side of the Column Preferences window are two buttons. One is labeled with a plus sign to add columns. The other has a minus sign to remove columns. Left-click on the plus sign as shown below in Figure 13.
Figure 13. The button to add a new column to Wireshark’s column display.
A new entry with the title “New Column” should appear at the bottom of the list. Double-click on the title to change the column name as shown below in Figure 14.
Figure 14. Renaming the newly created column.
Name this new column “Src port” and change the column type from number by double-clicking on column type setting as shown below in Figure 15.
Figure 15. Getting ready to change our newly created column’s type.
Click again to bring up a scrollable list of options for the column type. Scroll down and select “Src port (unresolved)” for the column type as shown below in Figure 16.
Figure 16. Selecting Src port (unresolved).
Next, create a new column entry, label it “Dst port” and select “Dest port (unresolved)” as the column type as shown below in Figure 17.
Figure 17. Selecting Dest port (unresolved) for a newly created Dst port column.
When finished, the Column Preferences window should show the two newly created columns as shown below in Figure 18.
Figure 18. Our two newly created columns for Wireshark’s column display.
We can drag these columns to place Src port after the Source address and Dst port after the Destination address entry. Left-click to select, hold the mouse button and drag the entry to its new position in the list. Figure 19 shows an attempt to move the Dst port column to a position immediately after the Destination address entry.
Figure 19. Moving our newly created Dst port column entry.
After moving our newly created Src port and Dst port entries, we suggest changing the column type for your Source address to “Src addr (unresolved)” and Destination address to “Dest addr (unresolved).” If you do this, the Column Preferences window should appear similar to Figure 20.
Figure 20. Our updated column list in the Column Preferences window.
After completing these changes, click OK to close the Column Preferences window. Wireshark should now display the following six columns (read: label - type):
Time - Time (format as specified)
Src - Src addr (unresolved)
Src port - Src port (unresolved)
Dst - Dest addr (unresolved)
Dst port - Dest port (unresolved)
Info - Information
Figure 21 shows an example of what this should look like.
Figure 21. Wireshark’s column display after updating our columns.
Figure 21 reveals our newly created Src port and Dst port columns are aligned to the right, while all the other columns are aligned to the left. Right click the column header for each of our right-aligned columns to bring up a menu, then click the “Align Left” checkbox to align these columns to the left. Figure 22 shows an example for the Src port column.
Figure 22. Aligning our newly created Src port column to the left.
When finished, the Src port and Dst port columns should be aligned to the left, matching all the other columns as shown below in Figure 23.
Figure 23. Src port and Dst port columns now aligned to the left.
While we can add several different types of columns through the Column Preferences window, we cannot add every conceivable column type. For example, we cannot add a column showing the domains associated with web traffic this way. Fortunately we can add a customized column that reveals these web traffic domains.
Adding Customized Columns
Wireshark allows users to add customized columns based on almost any value found in the frame details window. To better view the frame details, we should temporarily hide the hexadecimal view. Under the View menu, uncheck "Packet Bytes" as shown below in Figure 24.
Figure 24. Hiding the hexadecimal panel by unchecking the Packet Bytes view.
Now we should only have two sections displaying pcap data: the column display and the frame details.
First, we should create a customized column for domains used in unencrypted HTTP web traffic. In Wireshark, type http.request in the Wireshark filter bar and hit enter. Select the first frame in your column display. In the frame details section, expand the line for Hypertext Transmission Protocol. Then find the “Host” line. In this case, it should have msftconnecttest in the name. Left-click on that line to select it, then right-click to bring up a menu. Select “Apply as Column” as shown below in Figure 25.
Figure 25. Under the frame details window, find the line to create an HTTP hostname column.
This should create a new column titled Host as shown below in Figure 26.
Figure 26. Newly created Host column shown when viewing HTTP traffic in our pcap.
Next, let’s create another customized column for domains used in encrypted HTTPS web traffic. Clear your Wireshark filter bar, then type tls.handshake.type eq 1 and hit enter. Select the first frame in your column display.
In the frame details panel, expand the line for Transport Layer Security. Under that, expand the line for TLSv1.2 Record Layer: Handshake Protocol: Client Hello. Under that, expand the line that reads Handshake Protocol Client Hello. The expanded frame details are shown below in Figure 27.
Figure 27. Filtering on HTTPS traffic and expanding items in the frame details window.
Scroll down in the frame details section to find and expand the line that starts with Extension: server_name. Under that, find and expand the line that reads Server Name: Indication extension. Under that is a line that reads Server Name: geo.prod.do.dsp.mp.microsoft.com. Left-click on that line to select it, right-click to bring up a menu and select Apply as Column as shown below in Figure 28.
Figure 28. Under the frame details window, find the line to create an HTTPS server name column.
This should create a new column to the right of our recently created Host column titled “Server Name” as shown below in Figure 29.
Figure 29. Newly created Server Name column shown when viewing HTTPS traffic in our pcap.
Right-click any of the column headers to bring up a menu to reach our Column Preferences window again. In our Column Preferences window, we see these two newly created customized columns as shown below in Figure 30.
Figure 30. Our two newly created customized columns in the Column Preferences window.
To save screen space, we should combine these two columns into a single column. First, double-click on the Fields value in the Server Name entry and copy the text reading tls.handshake.extensions_server_name as shown below in Figure 31.
Figure 31. Copying the Fields value from the Server Name column.
Next, use the or operand to combine that text with the Fields value for the Host entry. The new value for the Host entry should read http.host or tls.handshake.extensions_server_name as shown below in Figure 32.
Figure 32. New Fields value for our recently created Host column.
Since both Fields values are now in the Host entry, delete the Server Name entry as shown below in Figure 33.
Figure 33. Delete the Server Name column, because it is no longer needed.
When finished, the list in your Column Preferences window should appear similar to Figure 34.
Figure 34. Our updated column display list.
Close the Column Preference window. Now we can filter for both HTTP and HTTPS activity, and any domains associated with this web traffic will appear in our updated Host column.
Type the following in your Wireshark filter:
http.request or tls.handshake.type eq 1
Scroll through the results in your updated Wireshark column display. The results should look similar to the Wireshark screenshot in Figure 35.
Figure 35. Updated Host column showing domains associated with web traffic.
Now that we have created all of our columns, we can hide any of them as needed.
Hiding Columns
When reviewing pcaps of web traffic generated by malware, the activity is often collected from a single internal IP address used by the infected host. One such example is a pcap generated by an online sandbox that analyzes malware. When investigating an alert for a suspected infection, investigators pull traffic from the internal IP associated with that alert, if the traffic is available.
In these cases, filtering on web traffic will reveal the same internal IP address in our Src column. For this tutorial, we captured our pcap from an internal IP address at 172.16.1[.]135, so our column display will only show that IP in the Src column when filtering for web traffic.
Because of this, we can hide the Src and Src port columns to better focus on the web traffic.
To hide any column in Wireshark, left-click on any of the column headers, then uncheck the columns you want to hide. Figure 36 shows unchecked boxes for the Src and Src port columns.
Figure 36. Hiding the Src and Src port columns by unchecking the boxes.
Hiding these columns provides a better idea of the traffic when viewing web activity. For example, we see the host generated unencrypted web traffic to the site httpforever[.]com on Aug. 7, 2023, at 18:57 UTC as revealed below in Figure 37.
Figure 37. A more concise view of the web traffic in our pcap.
Now that we have customized our column display, we should export our updated configuration profile.
Exporting Your Updated Configuration Profile
Recent versions of Wireshark allow users to export or load personal configuration profiles. This is useful when installing Wireshark in a new environment. Instead of redoing all the steps in this tutorial, we can load the profile saved from a previously exported configuration.
To export our newly customized configuration profile, select “Configuration Profiles…” under the Edit menu as shown below in Figure 38.
Figure 38. Menu path for the Configuration Profiles window.
The Configuration Profiles window should still have our customized profile selected. To export this profile, click on the Export button as shown below in Figure 39. You can export multiple personal profiles you have created.
Figure 39. Exporting your personal profile(s) from the Configuration Profile window.
Exported profile(s) are saved as a ZIP archive. If necessary, ensure your saved filename has a .zip file extension as shown below in Figure 40.
Figure 40. Save your exported profile(s) as a ZIP archive.
To import a saved profile, click the Import button in your Configuration Profiles window as shown below in Figure 41.
Figure 41. Importing a previously exported configuration profile from the Configuration Profiles window.
Conclusion
Wireshark’s default configuration works well for many people, but users can customize Wireshark to better fit their specific needs. For example, the customizations in this tutorial can be extremely useful when reviewing web traffic to determine an infection chain.
Attackers have increased targeted attacks on Linux systems, and the easy accessibility of hacktool utilities like LaZagne (a popular open-source password recovery tool) has made this increasingly convenient for threat actors to use in malware attack chains for dumping passwords. The tool poses a significant risk to Linux users because it targets popular chat software like Pidgin, using D-Bus APIs to extract sensitive information including passwords.
This article provides a concise overview of how LaZagne leverages the Pidgin D-Bus APIs to fetch this information, and why keeping an eye on the D-Bus APIs can be a smart security move. We will also examine how attackers use LaZagne in specific malware campaigns.
Advanced WildFire for Linux empowered with eBPF successfully detects D-Bus API related activities. Palo Alto Networks customers receive protection from the hacktool LaZagne in Wildfire through YARA and behavioral rules to detect suspicious activity related to the LaZagne threat.
Desktop-Bus, commonly called D-Bus, is an inter-process communication (IPC) mechanism in *nix-based systems that allows applications and services to communicate with each other efficiently. D-Bus uses a client-server architecture where the dbus-daemon application acts as a server and applications act as clients.
D-Bus is widely used in popular software like NetworkManager, PulseAudio, systemd and Evolution, and it enables seamless communication between various system components and applications. For example, Evolution email clients use D-Bus for communication with other components like the Evolution Data Server. This data server handles tasks such as storing and managing email accounts, contacts and calendars.
The D-Bus APIs on a Linux system facilitate communication between applications and services, potentially exposing sensitive data. Therefore, the APIs could pose risk if they are not monitored. The LaZagne hacktool leverages the Pidgin D-Bus APIs to dump credentials.
How LaZagne Steals Pidgin Credentials
LaZagne connects to the Pidgin client’s D-Bus API and fetches account credentials, including usernames and passwords, while the application runs (as shown in Figure 1).
Figure 1. LaZagne fetching account credentials.
The code in Figure 2 shows how the LaZagne hacktool connects with the Pidgin D-Bus APIs to retrieve credentials.
Figure 2. LaZagne leveraging D-Bus to fetch passwords. Source: AlessandroZ/LaZagne.
Here is a breakdown of the highlighted code shown above in Figure 2.
The get_password_from_dbus method is defined inside the Pidgin class, which inherits from the ModuleInfo class.
D-Bus connections for each session are created using dbus.bus.BusConnection(session). For each method called on the purple object (created as an instance of the Pidgin D-Bus APIs), the dbus-python library internally handles the creation, sending and receiving of D-Bus messages.
The PurpleAccountGetUsername(_acc), PurpleAccountGetPassword(_acc) and PurpleAccountGetProtocolName(_acc) methods are used to interact with the Pidgin application. They fetch the username, password and protocol name respectively, for each account from the Pidgin D-Bus APIs.
The extracted information is then stored in a list called pwd_found as dictionaries.
Some of the low-level libdbus library APIs (shown in Figure 3) that could be used for similar processes include:
dbus_message_new_method_call()
To create a new D-Bus message for a method call
dbus_message_append_args()
To append arguments to a D-Bus message
dbus_connection_send_with_reply_and_block()
To send the message and wait for a reply
dbus_message_get_args()
To extract the arguments from the reply message
Figure 3. Low-level implementation of LaZagne’s Pidgin class.
LaZagne allows threat actors to dump credentials for other accounts in addition to Pidgin’s. It can also dump KDE Wallet (KWallet) passwords via D-Bus APIs. KWallet is a secure password management system used by the KDE desktop environment on Linux. These passwords are the individual passwords saved within the KWallet system, which can include passwords for websites, email accounts, Wi-Fi networks or any other credentials a user chooses to store.
Threat actors have leveraged these D-Bus APIs to obtain sensitive data, and various public sources document cases of criminal groups that have utilized LaZagne during the past few years.
LaZagne in Malware Campaigns
LaZagne's availability on multiple operating systems has made it an attractive tool for threat actors.
In 2019, suspected Iranian-sponsored threat group Agent Serpens (aka Charming Kitten or APT35) used LaZagne in a series of attacks that harvested login credentials from Windows-based systems.
In 2020, the activity cluster Unit 42 researchers track as CL-CRI-0025 (tracked by other companies as a threat actor known as UNC1945 or LightBasin), used a custom Quick Emulator (QEMU) Linux virtual machine that contained various tools, including LaZagne, to harvest credentials from Italian and other European targets.
Since 2020, the threat actor we track as Prying Libra (aka Gold Dupont, behind attacks leading to RansomEXX ransomware) have reportedly used LaZagne to extract credentials from targeted hosts.
As early as July 2021, Adept Libra (aka TeamTNT) used LaZagne as part of its Chimaera campaign to steal passwords from various operating systems, including Linux distributions in cloud-based environments. This campaign continued through at least December 2021, when Adept Libra used LaZagne to steal passwords from a WordPress site in a Kubernetes environment.
The following table summarizes the use of the hacktool in various malware attack campaigns:
Figure 4. TeamTNT LaZagne script (VirusTotal results by hash).
The use of LaZagne by sophisticated threat groups in their campaigns highlight the tool's effectiveness in capturing passwords and enabling further exploitation.
Monitoring D-Bus API
Since LaZagne can leverage D-Bus to extract sensitive data from running applications, we can monitor D-Bus API calls to detect such suspicious activity. Library tracing tools such as those based on Extended Berkeley Packet Filter (eBPF) help in exposing the D-Bus API calls.
Figure 5 below illustrates monitoring of D-Bus APIs using the bpftrace tool against LaZagne hacktool activity (SHA256: d2421efee7a559085550b5575e2301a7c2ed9541b9e861a23e57361c0cdbdbdb)
Bpftrace is a command-line tool for Linux systems, designed for dynamic analysis of kernel and user-level programs. Using the bpftrace tool, we set the probe on the dbus_message_get_args() API. We used this API to extract the arguments from the reply message, which is defined in the libdbus-1.so.3 shared object library.
The one-liner bpftrace probe command we used is as follows:
1
sudo bpftrace-e'uprobe:/lib/x86_64-linux-gnu/libdbus-1.so.3:dbus_message_get_args { printf("pid: %d, comm: %s, func: %s called with 1st param value: 0x%lx\n", pid, comm, func, arg0); }'
Figure 5. Monitoring D-Bus API using bpftrace.
Figure 5 above shows that Pidgin usernames and passwords were successfully dumped by LaZagne (on the left terminal) and the API calls were logged in the bpftrace output (on the right terminal).
Hooking high level D-Bus APIs and logging the details like process identifier (PID) and program name can be useful as they allow us to identify which process is calling the API.
Conclusion
Closely monitoring D-Bus APIs could be an important way for defenders to secure applications and connected systems against malware and hacktools. Developers and cybersecurity professionals must collaborate to stay informed about security risks and take necessary actions to protect applications and sensitive user data.
With the increasing adoption of cloud computing and IoT, robust security measures are essential. Advanced WildFire for Linux empowered with eBPF successfully detects D-Bus API related activities. Palo Alto Networks customers receive protection from the hacktool LaZagne in Wildfire through YARA and behavioral rules to detect suspicious activity related to the LaZagne 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
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.
Acknowledgments
I would like to thank Yang Ji and Dongrui Zeng for their valuable inputs and suggestions that helped shape up this article.
![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.](https://unit42.paloaltonetworks.com/wp-content/uploads/2023/10/word-image-130507-14.jpeg)
![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.](https://unit42.paloaltonetworks.com/wp-content/uploads/2023/09/word-image-130278-3-1.png)
![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.](https://unit42.paloaltonetworks.com/wp-content/uploads/2023/09/word-image-130278-20-1.png)
![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].](https://unit42.paloaltonetworks.com/wp-content/uploads/2023/09/word-image-130156-2.png)
Get updates from Unit 42 