Unit 42 researchers identified two Cobalt Strike Team Server instances hosted on the internet and uncovered new profiles that are not available on public repositories. We will highlight the distinct techniques attackers use to exploit the Cobalt Strike platform and circumvent signature-based detections.
We identified Team Server instances connected to the internet that host Beacon implants and provide command-and-control (C2) functionality. We have also extracted the Malleable C2 profile configuration from the Beacon binary to help us understand the various methods used to evade conventional detections.
The operators of the Cobalt Strike Team Servers attempted to conceal their C2 infrastructure behind benign and well-known services to evade detection. We have also found Team Server C2 infrastructure hosted on well-known public cloud infrastructure providers. The operators also deployed new Malleable C2 profiles. Threat and red team actors create new profiles to deceive security controls, bypass security measures and avoid detection. These tactics involve modifying HTTP URLs, header parameters and host headers with harmless and widely recognized domains.
Palo Alto Networks customers receive protections and mitigations for Cobalt Strike Beacon and Team Server C2 communication in the following ways:
The Next-Generation Firewall (NGFW) with an Advanced Threat Prevention subscription can identify and block Cobalt Strike HTTP C2 requests generated by custom profiles and block Cobalt Strike HTTP C2 requests and responses that are masked with the Base64-encoding settings of the default profile (signatures 86445 and 86446).
WildFire and Cortex XDR can identify and block Cobalt Strike Beacon binaries, and XDR will report related exploitation attempts.
Cobalt Strike is a highly effective platform used by professionals to simulate threats in enterprise network environments. Its primary objective is to establish a secure and undetectable communication channel between Beacon implants and the Team Server. With the use of Malleable C2, Cobalt Strike operators can easily create highly flexible and evasive network profiles, generating different C2 traffic with ease.
Unit 42 researchers have discovered two distinct tactics used by threat or red team actors to evade detections from current security controls. By examining these cases, we can better understand the techniques these people use to carry out harmful actions without raising any security alerts.
The case studies below are derived from true positive detection analysis. In the following scenarios, we identified Cobalt Strike Team Server infrastructure, extracted Malleable C2 profile configuration information and reconstructed the configuration and implant data for use in detection improvements.
Case 1: Brand New Profile
Cobalt Strike has a well-documented custom profile language. Attackers and red teamers tend to craft well-designed and unique Malleable C2 profiles to conduct their operations, aiming to bypass security filters that look for known public Malleable C2 profiles.
We found a Team Server running on 23.95.44[.]80:80 that hosted a Beacon file with the SHA-256 hash 22631d171fd7d531c0bc083a5335a910a95257e3194b50d8b471740d3a91fe34. We used internal tools to derive and reconstruct the Malleable C2 profile from the configuration extracted from the Beacon binary.
Figure 1 shows an extracted and recreated custom profile. The left half of the image shows the GET transaction and the right side shows the POST transaction of the Beacon communication.
The encrypted and encoded data in the GET transaction is placed in a Cookie Parameter SESSIONID. The ID in the POST transaction is added to the custom header User. The ID is double encoded using Mask and NetBIOSU. The output from the task execution is also double encoded and appended to the data parameter in the POST body.
Security vendors use elements of HTTP traffic to determine if a given flow is suspicious or malicious. If the domain in the Host header of an HTTP request is on a ranked list of popular domains, some malicious criteria could be discarded as the request might be identified as benign. Similarly, if the destination server belongs to a well-known cloud provider, that IP address could be on the allow list and considered benign.
Attackers use these detection criteria to their advantage by generating HTTP request traffic to mimic known good services in order to evade identification. We routinely catch Malleable C2 profiles that mimic well-known benign websites such as e-commerce sites, search engines and email providers.
Case 2.1: Host with Benign/Famous Domain to Evade Security Detection
Attackers often use forged host headers to generate traffic that appears to be benign, thus evading network security inspection. However, this traffic can still be identified as malicious when inspected by an expert.
Figure 2 shows a Beacon sample using a modified Malleable C2 profile hosted on GitHub. The person intended to disguise the malicious traffic as benign traffic from a highly reputable website. However, the ASN record for the destination IP address shows a different owner, confirming the deception.
Figure 2. Malleable C2 Profile with forged HTTP Host header.
Case 2.2: Destination IP Used from Public Cloud to Evade Security Detection
This example shows how threat or red team actors can use public cloud platforms as a C2 server. Generally, these cases are hard to detect by IP reputation services such as VirusTotal or URL filtering products due to the benign nature of the service provider.
Penetration testers are well aware of the popularity of online services and use them to their advantage. They can hide payloads in seemingly harmless services, making it harder to detect malicious activity.
Unit 42 researchers identified a Team Server on the IP 35.224.140[.]15:443 that hosted the Cobalt Strike Beacon with the SHA-256 hash 3ac4be4291bddaaa39a815cc05ece6d611cd69a1604fec8dec0f7e5451659cfa. The Team Server IP belongs to a prominent cloud provider.
Figure 3 shows the Malleable C2 profiles recreated from the Beacon binary hosted on the Team Server instance. The Team Server was running on a well-known cloud provider.
Figure 3. Malleable C2 Profile using a known public cloud service.
Conclusion
Cobalt Strike is a highly versatile tool, and most security vendors struggle to detect its C2 traffic accurately. This makes Cobalt Strike an ideal choice for attackers looking to increase their malware's chances of success.
We are continuously discovering new Team Servers that host active Beacon binaries. This threat hunting has proven fruitful against the misuse of Cobalt Strike in cyberattacks. The continuous cycle of scanning and learning helps us remain vigilant and provide active defenses against cybercrime.
Palo Alto Networks customers receive protection from the attack above with the following products:
The Next-Generation Firewall with an Advanced Threat Prevention subscription can identify and block the Cobalt Strike HTTP C2 request in nondefault profiles. ATP signatures 86445 and 86446 can identify HTTP C2 requests with the Base64 metadata encoding in default profiles.
WildFire, an NGFW security subscription and Cortex XDR identify and block CobaltStrike Beacon.
Cortex XSOAR response pack and playbook can automate the mitigation process.
Cortex XDR will report related exploitation attempts.
Since March 2023, Unit 42 researchers have observed threat actors leveraging several IoT vulnerabilities to spread a variant of the Mirai botnet. The vulnerabilities exploited include those listed in the following table:
The threat actors have the ability to gain complete control over the compromised devices, integrating those devices into the botnet. These devices are then used to execute additional attacks, including distributed denial-of-service (DDoS) attacks.
On March 14, 2023, Unit 42 researchers observed some remote command execution exploit traffic from our internal threat-hunting system, originating from 185.44.81[.]114. The threat actor tried to download a shell script downloader as a file named y from hxxp://zvub[.]us/.
If executed, the shell script downloader would download and execute the following bot clients to accommodate different Linux architectures:
hxxp://185.225.74[.]251/armv4l
hxxp://185.225.74[.]251/armv5l
hxxp://185.225.74[.]251/armv6l
hxxp://185.225.74[.]251/armv7l
hxxp://185.225.74[.]251/mips
hxxp://185.225.74[.]251/mipsel
hxxp://185.225.74[.]251/sh4
hxxp://185.225.74[.]251/x86_64
hxxp://185.225.74[.]251/i686
hxxp://185.225.74[.]251/i586
hxxp://185.225.74[.]251/arc
hxxp://185.225.74[.]251/m68k
hxxp://185.225.74[.]251/sparc
After executing the bot client, the shell script downloader will delete the client executable file to cover its tracks.
Unit 42 researchers conducted an analysis of the malware host domain and found out there are two IP addresses corresponding to the domain zvub[.]us:
185.44.81[.]114 (From Aug. 15, 2022, to March 24, 2023)
185.225.74[.]251 (After March 25, 2023)
Upon conducting a thorough retrospective analysis, we noticed telnet brute force attempts from 185.44.81[.]114 since Oct. 6, 2022, and attempts to exploit multiple vulnerabilities since March 14, 2023.
Unit 42 researchers also noticed another campaign from source IP 193.32.162[.]189 since April 11, 2023, that delivers the same shell downloader from zvub[.]us, as shown in Figure 1. Based on our analysis, we believe that the same threat actor operated these two campaigns for the following reasons:
The two campaigns share the same infrastructure.
The botnet samples are almost identical.
Figure 1. Vulnerability exploit attempts.
Figure 2 is a diagram illustrating the campaign overview.
Figure 2. Campaign overview diagram.
Malware Analysis
Based on behavior and patterns Unit 42 researchers observed while analyzing the downloaded botnet client samples, we believe the sample is a variant of the Mirai botnet.
Upon execution, the botnet client prints listening tun0 to the console. The malware also contains a function that ensures only one instance of this malware runs on the same device. If a botnet process already exists, the botnet client will terminate the current running process and start a new one.
For the botnet client configuration string, the Mirai variant (like IZ1H9 and V3G4) will first initialize an encrypted string table and then retrieve the strings through an index. However, this Mirai variant will directly access the encrypted strings in the .rodata section via an index (as shown in Figure 3).
Also, notice that for Mirai variants like IZ1H9 and V3G4, the configuration contains a string that indicates the branch name of this variant (for example, /bin/busyboxIZ1H9) while this variant does not have a branch name.
For the configuration decryption, this Mirai variant first uses a table key 0xDEADBEEF to generate a single-byte config decryption key 0x22, then for the encrypted configuration, the malware performs XOR decryption with the following bytewise operations:
encrypted_char ^ 0x22 = decrypted_char
During the analysis, Unit 42 researchers noticed that this Mirai sample doesn’t contain the functionality to brute force telnet/SSH login credentials and exploit vulnerabilities, which means the only channels for spreading this variant are the botnet operator’s manual vulnerability exploitation attempts.
Conclusion
The widespread adoption of IoT devices has become a ubiquitous trend. However, the persistent security concerns surrounding these devices cannot be ignored. The Mirai botnet, discovered back in 2016, is still active today. A significant part of the reason for its popularity among threat actors lies in the security flaws of IoT devices.
These remote code execution vulnerabilities targeting IoT devices exhibit a combination of low complexity and high impact, making them an irresistible target for threat actors. As a result, protecting IoT devices against such threats becomes an urgent task.
To combat this threat, it is highly recommended that patches and updates are applied when possible.
Palo Alto Networks customers receive protection against vulnerabilities and malware through the following products and services:
The Palo Alto Networks IoT security platform can leverage network traffic information to identify the vendor, model and firmware version of a device and identify specific devices that are vulnerable to the aforementioned CVEs.
In addition, IoT Security has an inbuilt machine learning-based anomaly detection that can alert the customer if a device exhibits nontypical behavior, such as the following:
The sudden appearance of traffic from a new source
An unusually high number of connections
An inexplicable surge of certain attributes typically appearing in IoT application payloads
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.
This malicious traffic was first detected as a part of the campaign on March 14, 2023. The command execution vulnerability is due to the failure to sanitize the value of x509type in the kerbynet component of Zeroshell
We captured this exploit traffic on May 1, 2023. The exploit targets a command injection vulnerability in the D-Link wireless router’s /gena.cgi component, which does not successfully sanitize the user input in the service parameter. This leads to arbitrary command execution.
The exploit was detected on April 11, 2023. The exploit works due to the D-Link wireless router admin.cgi component failing to adequately sanitize the user-supplied input data, which leads to remote command execution.
Figure 6. CVE-2019-20500 exploit in the wild.
CVE-2021-25296: Nagios XI Remote Command Injection Vulnerability
We observed this exploit traffic on April 11, 2023. The exploit targets the Nagios XI device’s /nagiosxi/config/monitoringwizard.php component. If insufficient input validation is found, the attacker can exploit the vulnerability to launch a remote command injection attack.
The malicious traffic was first detected on March 14, 2023. The command injection vulnerability is due to the failure to sanitize the value of the cmd parameter in the cgi-bin/admin.cgi interface of the Telesquare router.
We captured this exploit traffic on April 14, 2023. The exploit targets a command injection vulnerability in the Arris TR3300’s user.cgi component, which does not successfully sanitize the user input in the DDNS_HOST parameter. This leads to a command injection.
This exploit was detected on March 15, 2023. The exploit works due to the SolarView Compact confi_mail.php component failing to adequately sanitize the user-supplied input data, which leads to command injection.
We observed this exploit traffic on March 14, 2023. The exploit targets the Tenda HG9 router’s /boaform/formPing component. If insufficient input validation is found, the attacker can exploit the vulnerability to launch a remote code execution attack
This malicious traffic was first detected on March 14, 2023. The command injection vulnerability is due to the failure to sanitize the value of the mtu parameter in the /cgi-bin/handler interface of Zyxel.
Figure 12. CVE-2022-30525 exploit in the wild.
CVE-2022-31499: Nortek Linear eMerge Command Injection Vulnerability
We captured this exploit traffic on May 1, 2023. The exploit targets a command injection vulnerability in the Nortek Linear eMerge device’s card_scan.php component, which does not successfully sanitize the user input in the ReaderNo parameter. This leads to remote command injection.
Figure 13. CVE-2022-31499 exploit in the wild.
CVE-2022-37061: FLIR AX8 Unauthenticated OS Command Injection Vulnerability
This exploit was detected on May 1, 2023. The exploit works due to the FLIR AX8 device’s res.php component failing to adequately sanitize the user-supplied input data, which leads to OS command injection.
We observed this exploit traffic on March 15, 2023. The exploit targets the Intelbras WiFiber device’s /boaform/formPing6 component. If insufficient input validation is found, the attacker can exploit the vulnerability to launch a command injection attack.
This malicious traffic was first detected on April 12, 2023. The remote command execution vulnerability is due to a failure to sanitize the value of the timezone parameter in the /management/set_timezone.
We captured this exploit traffic on April 12, 2023. The exploit targets a command injection vulnerability in the TP-Link Archer router’s cgi-bin/luci component, which does not successfully sanitize the user input in the country parameter. This leads to arbitrary command execution.
The exploit was detected on April 11, 2023. The exploit works due to the D-Link device /ping.ccp component failing to adequately sanitize the user-supplied input data, which leads to a command injection vulnerability.
We observed this exploit traffic on April 12, 2023. The exploit targets the Tenda AX3 router’s /goform/AdvSetLanip component. If insufficient input validation is found, the attacker can exploit the vulnerability to launch a remote command injection attack.
This exploit traffic was detected on March 14, 2023. The exploit targets a remote code execution in multiple CCTV/DVR devices’ /language components. The component does not successfully sanitize the value of the HTTP parameter.
We detected this exploit traffic on April 12, 2023. The exploit works due to the /cgi-bin/usbinteract.cgi component of the EnGenius EnShare device failing to sanitize the value of the HTTP parameter path.
This malicious traffic was captured on April 11, 2023. The exploit works due to the MVPower DVR failing to sanitize user input, which in turn could lead to remote command execution.
We captured this exploit traffic on March 14, 2023. The exploit targets the setup.cgi component of Netgear DGN1000. The component does not sanitize the value of the HTTP parameter cmd, which leads to remote code execution.
We observed this exploit traffic on March 14, 2023. The exploit targets the Vacron NVR device’s board.cgi component. If insufficient input validation is found, the attacker can exploit the vulnerability to launch a remote code execution attack.
The exploit traffic was first detected as a part of a campaign on April 12, 2023. The remote code execution vulnerability is due to the failure to sanitize the value of the SYSLOGD_REMOTE_HOST parameter in the user.cgi interface of a MediaTek WiMAX device.
After seeing reports of two similar privilege escalation vulnerabilities in Microsoft Windows – CVE-2021-1732 and CVE-2022-21882 – we decided to analyze both to better understand the code involved in each. This is a continuation of Inside Win32k Exploitation, in which we discussed the Win32k internals and exploitation in general as background information to explore the issues surrounding CVE-2021-1732 and CVE-2022-21882.
Here, we will dig deeper into CVE-2021-1732 and CVE-2022-21882 and their related proof-of-concept (PoC) exploits. We’ll walk through an analysis of these two exploits, and thus see why the patch for CVE-2021-1732 was not sufficient to prevent CVE-2022-21882.
Both vulnerabilities discussed in this series are detected and blocked by the Cortex XDR Anti-LPE protection module. Both vulnerabilities are data-only exploits that copy the NT/Authority System privilege token to that of the current (exploit) process for privilege escalation. The XDR Anti-LPE modules monitor for this specific type of privilege escalation technique.
In this section we’ll discuss two Win32k PoC exploits, CVE-2021-1732 and CVE-2022-21882. Both of these vulnerabilities abused xxxClientAllocWindowClassExtraBytes and NtUserConsoleControl to overwrite the tagWND.cbWndExtra data field of an adjacent window to a large value, allowing for an arbitrary write primitive. They each use this arbitrary write to create a fake spmenu in the adjacent window, and then use GetMenuBarInfo to create an arbitrary read primitive. The arbitrary read/write primitives are then used to copy the NT/AUTHORITY SYSTEM token to the current (exploited) process.
We analyze the CVE-2022-21882 PoC in detail, and we’ll discuss CVE-2021-1732 during relevant sections of this analysis to explain how it differs from CVE-2022-21882. Then we’ll discuss why the patch Microsoft issued for CVE-2021-1732 wasn’t sufficient to prevent CVE-2022-21882.
The reason we decided to spend more time discussing CVE-2022-21882 is because there are several blogs with a detailed analysis of CVE-2021-1732 by Google and DBAPPSecurity Threat Intelligence Center.
Both of these exploits are examples of data-only attacks, which means they only require a read/write primitive and do not execute any attacker controlled code. These types of exploits are becoming more common due to the increased difficulty of bypassing modern-day exploit mitigations being deployed within the latest operating systems.
Microsoft did release a patch for Windows 11 for this vulnerability as well. The PoC we are analyzing here was tested on Windows 10 version 21H2.
Triggering the vulnerability
Historically, exploit authors have relied heavily on abusing tagWND or bitmap objects to implement read/write primitives. As we mentioned earlier, Microsoft has gone through great pains to make abusing these objects much more difficult. Specifically, as of Windows 10 version 1703, using SetWindowLong only changes the ExtraBytes field in the user-mode copy of the desktop heap and not the kernel desktop heap, except when operating on a console window.
To get past this limitation, both vulnerabilities rely on changing a window to a console window during a user-mode callback by calling NtUserConsoleControl at a time when the Windows operating system is not expecting it. As a result of converting the window to a console window, this function adds 0x800 to the tagWND.dwExtraFlag mask to indicate that the tagWND.pExtraBytes field is now an offset into the kernel rather than a user-mode pointer.
Because Windows did not have any checks in place to verify window types, when SetWindowLong is called on this window, it will now make changes to the kernel desktop heap just like it did before Windows 10 version 1703. Let’s take a look at how this is implemented by walking through a PoC for CVE-2022-21882.
Store pointers to xxxClientAllocWindowClassExtraBytes and xxxClientFreeWindowClassExtraBytes
Define a couple of window classes
Groom the heap
Create some windows
Leak user-mode tagWND locations with HMValidateHandle
Leak user-mode tagWND locations with HMValidateHandle
Calculate offsets between windows
Call NtUserConsoleControl on lowest window address
Create a third (magic) window
Hook xxxClientAllocWindowClassExtraBytes with a malicious version that calls NtUserConsoleControl and NtCallbackReturn, then returns to the real xxxClientAllocWindowClassExtraBytes
Use NtUserMessageCall to trigger the hooked function on WndMagic
Use SetWindowlongA to create an arbitrary write primitive
Use SetWindowLongPtrA to leak Wnd1’s spmenu kernel address and replace it with a fake spmenu object
Use arbitrary read/write to clone system token
Create a new process with System privileges and fix up any changed kernel values
In the next section, we will begin to walk through this summary, starting with steps 1-5.
Unit 42 researchers have observed a surge of malware written for the Android platform that is attempting to impersonate the popular ChatGPT application. These malware variants emerged along with the release by OpenAI of GPT-3.5, followed by GPT-4, infecting victims interested in using the ChatGPT tool.
Here, we provide an in-depth analysis of two types of currently active malware clusters. The first cluster is a Meterpreter Trojan disguised as a "SuperGPT" app. The second is a "ChatGPT" app that sends short-text messages to premium-rate numbers in Thailand, resulting in charges for the victim that are pocketed by the threat actor.
Android users can download applications written for the Android platform from a variety of places. The Google Play store is the official source, but users are also free to obtain applications from other sources such as websites or links in emails. This means there is potential for users to obtain applications that have not been vetted by Google.
The files described here have been sent to Google and will be blocked from the Google Play store. Google Play Protect also protects users from apps known to contain this malware on Android devices with Google Play Services, even when those apps come from other sources. This underscores the need for users to be aware of the risks when obtaining applications for mobile devices outside of official channels. It is still possible that users could encounter malicious applications for download elsewhere on the internet.
Palo Alto Networks customers with Cortex XDR, the Next-Generation Firewall and Advanced URL Filtering benefit from protections against the ChatGPT-themed attacks discussed in this article. Additionally, the malicious indicators (domains, URLs and hashes) can be prevented with our DNS Security and WildFire services.
OpenAI created a tool known as Chat "Generative Pre-trained Transformer," or ChatGPT for short. This tool is powered by a large language model (LLM) and is currently in its fourth version.
ChatGPT first became publicly available on Nov. 30, 2022. It quickly went viral, since it demonstrated remarkable question-answering ability, though not necessarily in an accurate manner.
Threat actors are always seeking to distribute their wares via effective attack vectors, and impersonating prevalent applications according to the current global trend is among the most effective means to accomplish this objective. For instance, attackers commonly leveraged the COVID-19 pandemic to spread their own malicious versions of “Health and Wellness” category applications written for the Android platform.
Past reports on malware masquerading as a ChatGPT-related tool, as well as our earlier publication "ChatGPT-Themed Scam Attacks on the Rise," found that scammers were taking advantage of ChatGPT's popularity to launch attacks. Threat actors are using similarly worded domain names to trick victims into giving away personal information or downloading malware.
Here, we continue to report on this trend, sharing our findings on some malicious Android applications we've recently discovered in our telemetry. Specifically, we found two types of active malware. One is a Meterpreter Trojan disguised as a "SuperGPT" app, and the other is a "ChatGPT" app that sends messages to premium-rate numbers in Thailand.
Meterpreter Trojan
Our team uncovered a malicious Android Package Kit (APK) sample, which turned out to be a Trojanized version of a legitimate application. The legitimate application is an AI assistant based on the latest version of ChatGPT. The malicious version of this application enables the actor to establish remote access to an Android device if exploitation is successful.
Table 1 describes the legitimate application and Table 2 shows the malicious application.
The MainActivity class of the malware sample contains a String variable reference to the official ChatGPT URL https://chat.openai.com/chat. Package-Class named v3.v is a custom WebViewClient class implementation (WebView is Android's built-in implementation to embed web browser functionality in apps made for its operating system). As such, this Java class is able to extend or override the default functionality. It does so by adding the following redirect rules:
According to VirusTotal (VT), this sample was first submitted through VT's web interface from Nicaragua (NI), on 2023-03-16 02:06:04 UTC, as filename 2021id.apk.
Payload Implantation
Comparing the differences between the legitimate and malicious APK samples, it is clear that the critical Trojanizing addition to the file is the following line of Smali language code (shown in Figure 1).
Figure 1. Added line of malicious Smali language code.
The core threat in this malware sample is known as "Meterpreter." It is created using the Metasploit framework.
The source code of the initial Java-based Android Meterpreter stager can be found on Rapid7's GitHub repository. The main functionality is implemented within the Payload class. The Payload class' start method is invoked by the MainService class. The MainService class, in turn, can be either:
Started by the MainActivity class
Started by the MainBroadcastReceiver class automatically upon completion of the device boot sequence
The Payload class' main method is responsible for performing the following sequence of actions:
Parse the hard-coded exploit configuration stored in the configBytes byte array (shown in Figure 2).
Note: This is not obfuscated in any way (e.g., the TCP or HTTP remote host address and port are clearly visible)
Ensure the Android device's central processing unit (CPU) remains on via the Power Manager system service's partial wake lock functionality.
Hide the icon’s application if requested.
Establish a socket connection to the author-managed remote host.
Download a secondary payload upon successful connection, implementing the full range of capabilities (e.g., the dump_sms command).
In the case of the APK malware sample in question, the following sequence of operations triggers this Meterpreter payload:
The service named com.dominapp.supergpt.eluad.Vojnd starts upon the BOOT_COMPLETED action, as declared in the AndroidManifest.xml file.
The thread named com.dominapp.supergpt.eluad.C2094e spawns and runs.
The main method of the package class named com.dominapp.supergpt.eluad.Dapjs is invoked.
Figure 2. Configuration byte array, characteristic of a Meterpreter payload.
The Meterpreter payload is configured to connect to the remote endpoint tcp[://]Gwdidkfkf-47070[.]portmap[.]io:47070. Portmap.io is a service that performs port forwarding free of charge.
Certificate Attribution
The digital code-signing certificate used to sign this sample belongs to the attacker with the following characteristics:
Email address – lkpandey950@gmail[.]com
Organization Common Name (CN) – Hax4Us
Located in Shahdara, Delhi, India
The certificate is valid from 2020-07-17 11:08:41 UTC to 2047-12-02 11:08:41 UTC
Serial number – 1a505d53b1c75046a81acb021fdb5f99936b75db
This certificate is attached to over a hundred other publicly shared malware samples on VT (as shown in Figure 3).
Figure 3. Snapshot of partial results for VT search query androguard:"C:IN, CN:hax4us, L:shahdara, O:hax4us, ST:delhi, email:lkpandey950@gmail[.]com."In contrast, the legitimate application is digitally signed with a generic certificate.
SMS to Premium-Rate Numbers
We've also uncovered another cluster of APK malware samples. On the surface, the malware seems to be presenting the following webpage (shown in Figure 4) containing a description of ChatGPT. But in fact, this threat conceals a sinister intent underneath.
Figure 4. ChatGPT: Optimizing Language Models for Dialogue. hxxps[://]apkafe[.]com/what-is-chatgpt.Figure 5. OpenAI logo and logotype.
Moreover, all these APK samples share the OpenAI logo often associated with ChatGPT (shown in Figure 5) as their application icon, adding to the deceptive narrative that this application is related to the ChatGPT AI tool.
These APK malware samples are capable of sending SMS messages to premium-rate numbers in Thailand (TH). Premium-rate numbers cost more than calls to normal phone numbers, in exchange for rendering some sort of service (e.g., users providing information). The business behind it collects the earnings, but this can also be abused to conduct scams and fraudulent activity. For reference, the official Android Open Source Project (AOSP) codebase contains a list of premium-rate numbers by country.
The Android permission to send SMS text messages, android.permission.SEND_SMS, is requested by the application, and a reference to the "country":"thailand" is passed as a ContentValue. The samples also make use of OneSignal, a service that enables apps to send messages via push notifications, including by email, SMS and within the app itself.
For instance, the configuration obtained from the URL hxxps[://]api[.]onesignal[.]com/apps/af63b434-ec50-46a0-9374-d57a383f2e03/android_params[.]js is reproduced below:
(The OneSignal app ID is af63b434-ec50-46a0-9374-d57a383f2e03)
The formatted phone number in the android_sender_id field value is +661-9406-4544.
These APK samples are digitally signed with a generic certificate. As for other key attributes, their values are depicted in Table 3 below.
Validity
From 2008-02-29 01:33:46 UTC
To 2035-07-17 01:33:46 UTC
Serial number
936eacbe07f201df
Thumbprint (SHA-1)
61ED377E85D386A8DFEE6B864BD85B0BFAA5AF81
Table 3. Code-signing certificate attributes for Type II APK samples.
This cluster of samples can be subdivided into two smaller batches, each sharing some common characteristics. APK samples in the first batch send an SMS text message to one hard-coded, premium-rate Thai number and make use of the OneSignal service. APK samples in the second batch send different SMS text messages to two other hard-coded, premium-rate Thai numbers, and they do not obtain configuration from an external OneSignal endpoint.
The APK samples belonging to the first batch have a lower version compared to those from the second. This suggests that the first batch could be an earlier iteration of malware development than the second. This theory is supported by the earlier "first submission" timestamp of these APK samples on VT: batch one (February 2023), followed by batch two (March 2023).
Batch One
These are the SHA-256 hashes of samples in this batch:
Table 5. Static attributes of Batch 2 APK samples.
Conclusion
The emergence of ChatGPT-themed APK malware poses a severe threat to the security and privacy of mobile devices. These types of malware can potentially steal sensitive information, spy on user activities and cause significant financial losses for unsuspecting victims.
To protect themselves against this type of malware, mobile users should take proactive measures, such as installing reputable antivirus software, being cautious when downloading apps from third-party sources and keeping their devices up to date with the latest security patches.
Overall, the threat of mobile malware highlights the critical importance of mobile device security. By remaining vigilant and taking proactive steps to safeguard our devices, we can help prevent the spread of this dangerous malware and protect ourselves from potential harm.
In late January 2022, several reports on social media indicated that a new Microsoft Windows privilege escalation vulnerability (CVE-2022-21882) was being exploited in the wild. These reports prompted us to do an analysis of CVE-2022-21882, which turned out to be a vulnerability in the Win32k.sys user-mode callback function xxxClientAllocWindowClassExtraBytes.
In 2021, a very similar vulnerability (CVE-2021-1732) was reported to – and patched by – Microsoft. We decided to take a closer look at both vulnerabilities to better understand the code involved in each. In our initial analysis we wanted to determine why the patch for CVE-2021-1732 was not sufficient to prevent CVE-2022-21882.
This is part one of a series that will cover Win32k internals and exploitation in general using these two vulnerabilities and their related proof-of-concept (PoC) exploits as examples.
Here, we cover a significant amount of background information, including years worth of background research, conducted by several excellent researchers, to get the reader up to date to the latest implementations of Win32k and its associated exploitation methodologies. For an even deeper understanding of the subject, we also recommend reading all of the linked references at the end of the post.
Both vulnerabilities discussed in this series are detected and blocked by the Cortex XDR Anti-LPE protection module. Both vulnerabilities are data-only exploits that copy the NT/Authority System privilege token to that of the current (exploit) process for privilege escalation. The XDR Anti-LPE modules monitor for this specific type of privilege escalation technique.
Quite a lot has been written on Windows development via the Win32 API, and Windows internals. However, in our experience, very few security-related sources cover development via the graphical user interface (GUI) or its underlying internals. This interface is implemented within Win32k.sys, Win32kbase.sys and Win32kfull.sys.
Therefore, we decided to do some research to get better acquainted with the Windows GUI internals and associated APIs. We read a few whitepapers on Win32k exploitation written over the past 10 years or so, as well as the Microsoft Developer Network (MSDN) documentation on the Win32 API.
We don’t want to assume any level of expertise with the underlying code involved. Therefore, to ease the understanding of the two vulnerabilities being analyzed as well as other Win32k.sys vulnerabilities and exploits, in our first post we will cover some background on the relevant APIs, objects and data structures involved.
Because exploitation of these vulnerabilities and the patch bypass method was relatively easy to understand, we chose these two recent examples to walk through some of the Win32k internals to help people understand how they are commonly leveraged to obtain read/write primitives. It also provides us with a good opportunity to discuss common Win32k exploit targets (user-mode callbacks) within the Win32k.sys codebase.
Win32k – History and Background
Prior to Windows NT 4.0, Microsoft implemented the GUI functionalities of the Win32 API within a user-mode process called the Client-Server Runtime SubSystem (CSRSS.exe). However, context switches between user-mode and kernel-mode were computationally expensive and required large memory overhead.
To eliminate these issues and speed up the overall Windows operating system, Microsoft decided to move the Windows subsystem (Window Manager, GDI and graphics drivers) to the kernel. This transition started with Windows NT 4.0 in 1996.
This change was implemented through a kernel-mode driver called Win32k.sys, in what is now known as the kernel-mode Windows subsystem. The user-mode component of the Windows subsystem still resides within CSRSS.
Although the move to the kernel greatly reduced the overhead required, Microsoft had to resort to some old tricks, such as caching management data structures within the user-mode portion of the client’s address space. In fact, to further avoid context switches, some management structures have historically been stored exclusively in user-mode. However, in an effort to eliminate kernel address leaks, Microsoft has started to implement methods that use user-mode and kernel-mode copies of these structures to prevent kernel addresses from being stored in user-mode structures.
Additionally, because Win32k needed a way to access these user-mode structures and support some existing user-mode functionality such as window hooking, user-mode callbacks were implemented to facilitate these tasks.
“User-mode callbacks allow Win32k to make calls back into user-mode and perform tasks such as invoking application-defined hooks, providing event notifications, and copying data to/from user-mode,” Tarjei Mandt wrote in a detailed whitepaper. His research was also presented at Black Hat USA in 2011. In doing so, he demonstrated the challenges Microsoft faced in implementing user-mode callbacks and preserving data integrity.
Mandt demonstrated that many objects were not being properly locked before making user-mode callbacks, which allowed user-mode code to destroy these objects during the user-mode callback, resulting in Use-After-Free (UAF) vulnerabilities. Although Microsoft has addressed many of the issues Mandt pointed out in 2011, user-mode callbacks are still abused today.
Inspired by Mandt’s research, in 2019 Gil Dabah wrote a paper building upon Mandt’s research. He discovered that even if user-mode code destroys objects that are correctly locked during user-mode callbacks, the destroyed objects can have secondary effects on other objects that are not locked correctly. This activity resulted in secondary object destruction and further UAF vulnerabilities.
Basic Windows GUI API Background
Before we discuss Win32k internals, we will briefly cover a simple C program that creates and destroys a window using the Win32 API. This will allow us to begin to understand how graphics windows are programmatically created and manipulated. It will also allow us to examine the underlying structures that define each window and their menus.
We’ll be referring to the sample code in Figures 1-3 below to discuss the basics of window creation and the underlying structures used to define windows and menus. Comments have been added to the sample code to make it as understandable as possible.
As shown in Figure 1, the sample program starts off by defining a window class. A process must register a window class before it can create a window of the type defined within the WNDCLASSEX structure. First a window class object is declared WNDCLASSEX wcx = { }, then the window class structure is filled in.
Figure 1. Defining the window class.
The elements of the window class are as follows:
cbSize: The size, in bytes, of this structure. Set this member to sizeof(WNDCLASSEX).
style: The window class styles. This member can be any combination of the Class Styles.
lpfnWndProc: Pointer to the function that processes all messages sent to windows in the class and defines the behavior of the window. Typically, the default window procedure is used for at least some messages. However, custom window procedures are often used to create unique window experiences. For more information, see WindowProc.
cbClsExtra: The number of extra bytes to allocate following the window-class structure. The system initializes the bytes to zero.
cbWndExtra: The number of extra bytes to allocate following the window instance. The system initializes the bytes to zero. Do not confuse this with cbClsExtra, which is common to all windows of this window class. This is often 0, but when it’s not, the memory is typically used to store data that is not constant across windows. We’ll see this used in the PoC later.
hInstance: A handle to the instance that contains the window procedure for the class. Identifies the application or .DLL that registered the class. Assigned the hinstance argument to WinMain here.
hIcon: A handle to the class. LoadIcon(NULL, IDI_APPLICATION) loads the default icon.
hCursor: A handle to the class cursor. LoadCursor(NULL, IDC_ARROW) loads the default cursor.
hbrBackground: A handle to the class background brush. GetStockObject (WHITE_BRUSH) returns a handle to a white brush. The return value must be cast because GetStockObject returns a generic object.
lpszMenuName: Pointer to a null-terminated character string that specifies the resource name of the class menu, as the name appears in the resource file. If no menu bar is needed, this field can be NULL.
lpszClassName: The class name that identifies this window class structure.
hIconSm: A handle to the small class icon.
Now that the attributes of the window class have been defined, we need to register it with the application using RegisterClassEx(), shown in Figure 2 below. On failure, RegisterClassEX() returns 0. Otherwise, it returns a class atom that uniquely identifies the class being registered. Registering the window class defines the class and its associated structure members to Windows.
Figure 2. Registering a window class.
Creating a Window
Once the window has been registered, we can create an instance of the window class by calling CreateWindowExA(), shown in Figure 3 below.
Figure 3. Code for creating a window.
The arguments of CreateWindowEX are as shown in Figure 4.
Figure 4. CreateWindowExA function prototype.
A brief description of each argument is listed below:
dwExStyle: The extended window style of the window being created. In this case, we have set it to the default window constant of WS_EX_LEFT, which gives the window generic left-aligned properties.
lpClassName: The class name. Taken from wcx.lpszClassName that was declared in the call to RegisterClassEX.
lpWindowName: The window name.
dwStyle: The style of the window being created. In this case, we used WS_OVERLAPPEDWINDOW, which creates a top-level (parent) window.
X: The initial horizontal position of the window. For an overlapped or pop-up window, the x parameter is the initial x-coordinate of the window's upper-left corner, in screen coordinates. For a child window, x is the x-coordinate of the upper-left corner of the window relative to the upper-left corner of the parent window's client area. If x is set to CW_USEDEFAULT, the system selects the default position for the window's upper-left corner and ignores the y-parameter.
Y: Same as above but for the y-coordinate.
nWidth: The width of the window.
nHeight: The height of the window.
hWndParent: A handle to the parent or owner window of the window being created.
hMenu: A handle to a menu, or specifies a child-window identifier, depending on the window style. For an overlapped or pop-up window, hMenu identifies the menu to be used with the window; it can be NULL if the class menu is to be used.
hInstance: A handle to the instance of the module to be associated with the window.
lpParam: The extra information that is passed to the window's window procedure. If no extra information is to be transmitted, pass NULL.
Once the window has been created with the call to CreateWindowEx(), the window has been created internally – which is to say, memory has been allocated and its structures populated – but not shown. To display the window, we call the ShowWindow() function.
ShowWindow() takes the handle obtained from the call to CreateWindowEXW() and the state variable nCmdShow, obtained from WinMain(). ThenCmdShow variable determines how the window will be displayed on screen, whether it’s normal, maximized or minimized, for example.
ShowWindow() only controls how the application window is displayed. This includes elements such as a title bar, a menu bar, the window menu, the minimize button, etc. The client area is the area where the application displays data, such as where you type text in a text editor. The client area is painted by calling the UpdateWindow() function.
If you specify the WS_VISIBLE window style as the dwStyle parameter to the CreateWindowEXW() function, you do not need to call the ShowWindow() function. This is implied, and Windows will take care of invoking this for you. On a similar note, if you do not specify the WS_VISIBLE style and you also do not call the ShowWindow() function, the window will remain hidden from view.
Window Messages and Window Procedures
After the call to UpdateWindow(), the window is fully visible and ready for use. When writing a simpler console application for Windows, the application makes explicit function calls in response to user input from the console.
In a windowed application, a user can typically interact with the application by entering text, clicking through buttons and menus, or just by moving the mouse. Each of these actions have their own special functionality. To make this work, Microsoft implemented an event driven system that relays messages from user input (e.g., keyboard, mouse or touch) to the various windows in each application. These messages are handled by a function within each window, known as the window procedure.
Windows maintains a message queue for each thread, which will relay any user input event that affects the state of the window. Windows then translates these events into messages and places them into the message queue. The application processes these messages by executing the code similar to that in Figure 5 below.
Figure 5. Window message queue loop.
The GetMessage() function retrieves the next message from the message queue. The MSG parameter is a structure that contains the message information required for the assigned window procedure to properly handle the message.
Among the members of the MSG structure are a handle (hwnd) to the window whose window procedure receives the message, and a message that contains an identifier that determines what request is being asked of the window procedure. For example, if the message contains a WM_PAINT message, it tells the window procedure that the window’s client area has changed and must be repainted.
The TranslateMessage() function translates virtual-key messages into character messages, but this is not important for the current discussion. The DispatchMessage() sends the message to the window, identified by the window handle in the msg structure, to be handled by the window procedure defined by that window class.
Up to this point, the example code has accomplished the overhead of defining the window class by performing the following actions:
Registering the window
Creating an instance of a window defined by the window class
Displaying the window on the screen
Entering the message loop
It’s the window procedure that determines what is displayed and how it responds to user input. Windows provides a default window procedure to handle any window messages that an application does not process, and it provides the minimal functionality for any window to function properly.
The window procedure is where all the functionality of the window is defined and, as one might guess, they can be quite involved. For our purposes we are currently only interested in Microsoft’s default window procedure, DefWindowProc().
Window Structures
As mentioned earlier, Windows now manages GUI objects such as menus, windows, etc., in the kernel via Win32k.sys. When a window object is created, its properties are tracked within a data structure known as tagWND.
Unfortunately, Microsoft removed many of the Win32k debugging symbols, making it much more difficult to gain transparency into these structures. Based on some reverse engineering, Figure 6 shows what the structure looks like in Windows 10 version 21H1.
Figure 6. TagWND parent structure.
This is not a comprehensive list of members, but only those important to this discussion. Looking at HMAllocObject during a call to xxxCreateWindowEx, where the allocation of the structure occurs, we can confirm this structure is 0x150 (336) bytes in size.
The WinDbg output just prior to the call to HMAllocObject is shown in Figure 7. You can see the fourth argument, which represents the allocation size, is stored in the r9 register and is equal to 0x150.
Figure 7. WinDbg output showing input parameters to HMAllocObject.
The tagWND structure, shown in Figure 6, used to be referenced within the Win32ClientInfo entry of the Thread Environment Block (TEB). It has since been removed to prevent easy leaking of kernel-mode addresses.
The first entry in the kernel tagWND structure is the window handle. Each window will have a representative tagWND structure associated with it in the kernel.
During the analysis of CVE-2022-21882, this structure will be important, but for now, we’ll focus on offset 0x28. I’ve labeled it as *pWND because Microsoft no longer supplies symbols. Additionally, Microsoft no longer provides a name for this structure — however, in the past it has been referred to as state or WW. According to Microsoft, these names are deprecated and no longer used internally.
What is important to know about this pointer is that it’s a user-mode version of the tagWND data that does not include kernel addresses, and it is structured differently than its parent tagWND structure. This child structure exists both in the kernel as well as in user-mode. This is how Windows manages the data in an attempt to avoid leaking kernel addresses, because any user-mode application will work with the copy of the tagWND structure located on the user-mode desktop heap and hence will not be able to see any kernel-mode addresses.
I will continue to refer to the child structure as a tagWND structure. Be aware, it is structured differently (as shown in Figure 8, below) than the parent tagWND structure above, but is still commonly referred to as tagWND in other research blogs and papers.
The child tagWND structure is shown in Figure 8, and the elements and their offsets were confirmed through reverse engineering. The gaps were not analyzed and are not important for this discussion.
Many of the elements of the WNDCLASSEX structure discussed in the section about creating a window can be seen within the tagWND structure. Therefore, it’s pretty clear that when a window is created, the properties assigned via the WNDCLASSEX structure are passed to the kernel and stored within the tagWND structures. The properties are then propagated to the user copies in both the kernel and user-mode desktop heaps.
Figure 8. User-mode safe copy of the tagWND structure.
Figures 9 and 10 show both the parent tagWND and the kernel copy of the user-mode safe tagWND structures respectively.
Figure 9. WinDbg memory dump of the parent tagWND structure.
The Figure above is the parent tagWND, and you can see that the handle (offset 0x00) is the same as that of the copy tagWND below. You can also see that the parent structure has kernel addresses, while the user-mode safe copy only has user-mode addresses. Lastly, notice the parent tagWND+0x28 is a pointer to the child tagWND copy’s address.
Figure 10. WinDbg memory dump of the child tagWND structure.
Historically, there have been a few methods to leak the kernel mode addresses of window objects. All objects within Win32k that store properties set by user-mode code (e.g., windows, menus) are commonly referred to as user objects.
All user objects, the user-mode copy of the tagWND structure being one of many, are indexed within a per-session handle table commonly known as the UserHandleTable. (Though the tagWND structure wasn’t always a user-mode safe copy and did once contain kernel addresses.)
It used to be possible to locate tagWND objects via the UserHandleTable through an exportable structure within User32.dll, called gSharedInfo. This is no longer possible as of Windows 10 version 1703. Due to Microsoft’s continued efforts to eliminate kernel address leaks, they have removed the kernel addresses of objects within the desktop heap from the UserHandleTable.
The Window Manager validates handles with an non-exported function, HMValidateHandle, which is located in User32.dll. Prior to Windows 10 version 1803, the Window Manager returned the kernel-mode pointer to the object whose handle was to be validated and it was commonly used to leak this address. Even though the kernel address leak has been fixed, this method will be important when we look at the two vulnerabilities later.
The reason exploit writers are so interested in locating tagWND structures is because, historically, you can modify tagWND.cbExtra with a large value to allow for an arbitrary write into an adjacent tagWND structure using the SetWindowLong function. However, as of Windows 10 version 1703, any bytes written by SetWindowLong are no longer written to the kernel. That is except under a specific condition, which will be discussed later during the analysis of the exploit. This fix has effectively killed this technique for creating an arbitrary write.
User objects are stored in one of three types of memory within the kernel: the desktop heap, the shared heap or the session pool. For the purposes of this discussion, we are interested in the desktop heap because the objects we’ll be working with are stored here.
Each desktop gets its own desktop heap. Since Windows stores management structures in the desktop heap, which resides in the kernel, there needs to be a way for user-mode applications to access these structures.
Historically, Windows created a user-mode mapped copy of the desktop heap that contained kernel-mode pointers to relevant structures. Today, these pointers have been replaced with user-mode pointers, indicating that Windows has begun to create an isolated copy of the desktop heap in user-mode to eliminate the disclosure of kernel-mode pointer addresses.
Typically when you are trying to exploit a kernel vulnerability, you need a few things to enable exploitation from user-mode. One of these is a way to determine where objects of interest are located within the kernel in order to get around kernel address space layout randomization (KASLR). Therefore, knowing where the desktop heap is located, as well as the ability to find specific objects of interest within the desktop heap is highly desirable.
In fact, since Windows 10 version 1607, Microsoft started adding mitigations in an attempt to prevent exploit writers from locating the desktop heap and its associated objects in the kernel. These mitigations include removal of kernel addresses from the UserHandleTable, as discussed above, as well as removal of kernel pointer references to the desktop heap within the Win32ClientInfo structure located in each process’ Thread Environment Block (TEB). Additionally, HMValidateHandle now returns user-mode (versus kernel-mode) pointers for any object handles passed to it.
We should note that there is an assumption that we are operating under a low-integrity process. If the process is medium-integrity or higher, it is trivial to use API functions such as EnumDeviceDrivers and NtQuerySystemInformation to obtain kernel pointers of interest.
User-mode Callbacks
The final thing that needs to be discussed in this first post discussing the background of these PoCs are user-mode callbacks.
Because the windows subsystem is primarily located within the Windows kernel, while the windows themselves operate in user-mode, Win32k must make frequent calls from the kernel into user-mode. User-mode callbacks provide a mechanism to implement items such as application defined hooks, event notifications and copying data to/from the kernel from/to user-mode.
Win32k calls KeUserModeCallback, with the associated ApiNumber of the user-mode function it wants to call, when making a user-mode callback. The ApiNumber is an index into a function table, located within User32.dll (USER32!apfnDispatch). The address of this table is copied to the process environment block (PEB) (PEB.KernelCallbackTable) during initialization of User32.dll within each process.
In the analysis of the exploits, we show how user-mode callbacks are hooked via the KernelCallback table and show what the table looks like in WinDbg(shown in Figure 21 and Figure 22). The function prototype of KeUserModeCallback and its associated parameters are shown in Figure 11 below.
Figure 11. KeUserModeCallback function prototype.
The user-mode callback input parameters are passed via the InputBuffer, while the output from the callback function is returned within the OutputBuffer. Upon invoking a system call, ntdll!KiSystemService or ntdll!KiFastCallEntry stores a trap frame (TRAP_FRAME) on the kernel thread stack to save the current thread context and enable the restoration of registers upon returning to user-mode.
To make the transition back to user-mode in a user-mode callback, KeUserModeCallback first copies the InputBuffer to the user-mode stack using the trap frame information held by the thread object. It then creates a new trap frame with EIP set to ntdll!KiUserCallbackDispatcher, replaces the thread object's TrapFrame pointer, and finally calls ntdll!KiServiceExit to return execution to the user-mode callback dispatcher.
Figure 12. KiUserCallbackDispatcher function prototype.
Once the user-mode callback has completed, NtCallbackReturn is called to resume execution in the kernel. This function copies the result of the callback back to the original kernel stack and restores the saved trap frame (PreviousTrapFrame) and kernel stack stored in the KERNEL_STACK_CONTROL structure. Before jumping to the location where it previously left off (in ntdll!KiCallUserMode), the kernel callback stack is deleted.
Figure 13. NtCallbackReturn function prototype.
The Window Manager uses the Executive Resource (ERESOURCE) synchronization primitive, as opposed to exclusive locks, when operating on Win32k management structures. The ERESOURCE primitive allows multiple threads to access a shared resource in the cases where each thread is only attempting to read the resource in question. The ERESOURCE primitive is also known as a single writer, multiple readers primitive. Once the ERESOURCE is initialized, threads can acquire an exclusive lock (for writes) using ExAcquireResourceExclusiveLite, or a shared lock (for reads) by calling ExAcquireResourceSharedLite. The thread then releases the resource by calling ExReleaseResourceLite. There is a requirement for normal kernel APCs to be disabled to use the acquire APIs discussed here, and this is done by calling KeEnterCriticalRegion, prior to the acquire call, and KeLeaveCriticalRegion after the release call.
If Win32k didn’t release the resource upon calling a user-mode callback, and that user-mode callback allowed an application to freeze the GUI subsystem, Win32k would not be able to perform other tasks while the GUI subsystem was frozen. Therefore, Win32k always releases the resource upon calling a user-mode callback. The code in Figure 14 below demonstrates how this occurs.
Figure 14. Pseudo code showing how Windows enters and leaves a critical region before calls to KeUserModeCallback.
This practice creates a dilemma. Because user-mode code is free to do things like modify the properties of objects and reallocate arrays, upon returning from a user-mode callback, Win32k must ensure that referenced objects are still in an untrusted state. Operating on such objects without performing the proper checks or object locking can and does create security vulnerabilities.
In fact, Tarjei Mandt’s 2011 paper, "Kernel Attacks Through User-Mode Callbacks," identified multiple instances of these types of vulnerabilities, and was the basis for research on Win32k exploitation for many years. Microsoft subsequently reviewed the Windows user-mode callback functions to ensure proper verification or locking of objects, making it significantly more difficult to exploit this class of bugs.
In 2019, Gil Dabah demonstrated that, although Microsoft had effectively eliminated Win32k bugs through operations on objects modified through direct calls to user-mode callbacks, it was still possible to create kernel-mode to user-mode states that indirectly modified objects (e.g. destroying a parent window while performing operations on a child window) in order to leverage similar bugs. The vulnerabilities identified were much more complex, making them harder to identify and likely much smaller in number.
User-mode callbacks were deemed important enough to track by Microsoft that they were given special prefixes. User-mode callback function names are preceded with either a xxx or zzz. Those preceded by an xxx leave the critical region and call the user-mode callback, just like we described above. Those that are preceded by a zzz invoke asynchronous or deferred callbacks. We’ll only be concerned with xxx type callbacks for this discussion.
Conclusion
In our first installment of this series, we’ve covered using the Win32 API to create GUI objects such as windows and menus. We covered the user-mode and kernel-mode data structures that are used to manage these objects and how they have changed over the years to help optimize and secure the transition between user-mode and kernel-mode.
In our next post, we’ll walk through a PoC for CVE-2022-21882 and explain what the code is doing. Finally, we’ll discuss the vulnerability, how it’s used to elevate privileges, and why the patch for CVE-2021-1732 wasn’t sufficient to prevent CVE-2022021882.
Both vulnerabilities discussed in this series are detected and blocked by the Cortex XDR Anti-LPE protection module. The XDR Anti-LPE modules monitor for techniques such as these that are data-only exploits, which copy the NT/Authority System privilege token to that of the current process for privilege escalation.
Unit 42 researchers have identified a growing trend of cyberattacks targeting web applications and application programming interfaces (APIs) hosted by cloud service providers. Based on the data from our research, 14.9% of attacks in late 2022 on web applications and APIs targeted cloud-hosted deployments.
Attackers are also operating in the cloud and using it to launch their attacks on applications and APIs, as 5.1% of the attacks originated from cloud service providers' addresses. We will discuss what web and API attacks are and why attackers are exploiting them in the cloud. We will also review possible reasons for attacks originating from the cloud, as well as the potential impact on businesses and individuals.
Palo Alto Networks customers using Prisma Cloud are protected from these threats through the WAAS module, which is designed to protect web applications and APIs in cloud environments.
APIs and web applications play a pivotal role in today's digital landscape. Web applications are software programs accessed through web browsers, providing interactive and engaging user experiences. Meanwhile, APIs act as intermediaries that facilitate communication between different software applications.
By enabling seamless interaction between applications, APIs simplify complex processes and promote a more connected digital ecosystem. Generally, both web applications and APIs are served on the HTTP protocol.
The widespread use of web applications and APIs has made them an integral part of the modern online world. Businesses, organizations and developers are increasingly adopting them to create user-friendly interfaces and automate processes, boosting efficiency and productivity.
The growing reliance on these technologies has also led to an increased focus on ensuring their security and reliability. As a result, it is essential to keep up with best practices and stay informed about potential vulnerabilities to protect valuable data and to maintain users' trust.
Web Applications and APIs on the Cloud
There has been a significant surge of organizations moving web applications and APIs to the cloud in recent years. Recognition among businesses and organizations of the numerous benefits offered by cloud solutions is driving this transformation.
Cloud applications are mainly based on microservices architecture, which is why the shift to the cloud is encouraging an evolution in software architecture. This difference is driving these organizations to embrace microservices architecture.
There are also many advantages of employing a microservices architecture, which is an approach to software development where an application is divided into small, independent services that communicate with each other through APIs.
A recent survey of nearly 400 organizations by TechTarget's Enterprise Strategy Group (ESG) Research Team, published in April 2023 and co-sponsored by Palo Alto Networks, revealed that organizations plan to double down on microservices architecture for their applications and move their production workloads into cloud providers.
Figure 1. Public-facing web applications based on microservices. "Today” and "from now" date from the April 2023 survey. Source: "Securing the API Attack Surface," ESG and Palo Alto Networks.Figure 2. Production workloads run on public cloud infrastructure. “Today” and "from now" date from the April 2023 survey. Source: "Securing the API Attack Surface," ESG and Palo Alto Networks.
A wide variety of organizations are increasingly deploying their web applications and APIs in the cloud due to its compelling advantages. Cloud-based infrastructure offers scalability, flexibility and cost-effectiveness, allowing businesses to adapt to changing demands quickly and only pay for the resources they use. Moreover, the cloud enables faster development and deployment cycles, promoting innovation and agility.
Attacks on Web Applications and APIs in the Cloud
Unit 42 researchers conducted research on roughly 12 billion attacks targeting web applications and APIs to determine if attackers are targeting such instances on the cloud. Their findings revealed that attackers indeed place increased emphasis on targeting cloud-hosted web applications and APIs.
Through the analysis of this data, we discovered that 14.9% of attacks on web applications and APIs were directed at workloads hosted by the top three cloud vendors. This indicates that the cloud is not only a critical component for businesses but also an increasingly attractive target for cybercriminals.
Figure 3. Destination of the attacks.
We believe attackers are increasingly targeting web applications and APIs in the cloud for several reasons.
Growing adoption of cloud services:
As more businesses and individuals migrate their workloads to the cloud for scalability, cost-effectiveness and convenience, the attack surface for cybercriminals expands, providing more opportunities.
Complex security landscape:
Cloud environments often have complex architectures and multitenant setups, leading to increased security risks. Attackers can take advantage of misconfigurations, unsecured data storage or vulnerable APIs to exploit systems.
Abundant resources:
Cloud environments offer abundant computing resources, making them attractive targets for resource-intensive attacks such as distributed denial-of-service (DDoS) attacks or cryptojacking.
Value and Impact:
Web applications and APIs often handle valuable data or provide critical services. Attackers target these systems in the cloud to gain unauthorized access to sensitive information, disrupt services or leverage compromised resources for further attacks.
Origination of Web Application and API Attacks
In the course of analyzing attacks on web applications and APIs, Unit 42 researchers placed special emphasis on determining the origins of these attacks. We discovered that 5.1% of the attacks were initiated from deployments hosted by the top three cloud service providers.
One plausible explanation for this high percentage is that attackers compromise legitimate cloud-hosted workloads and then use them as launch pads for further attacks. This tactic enables threat actors to spread their reach to other cloud environments, expanding the scope of their malicious activities.
Another potential reason is that some attackers may pose as legitimate users to gain access to cloud infrastructure. In order to do so, they could use free tiers offered by cloud vendors or use stolen credit card information to pay for cloud services. Once inside the cloud environment, these attackers can launch their attacks directly from within the cloud.
Figure 4. Origin of web application and API attacks.
Conclusion
In light of this research, organizations must be vigilant in securing their cloud environments, ensuring proper configurations, and monitoring for potential threats. By understanding the risks and implementing robust security measures, businesses can better protect their web applications and APIs from cloud-based attacks.
As more businesses shift their web applications and APIs to the cloud, attackers might perceive these environments as attractive targets, offering a wealth of valuable data and resources. This trend underscores the importance of implementing robust security measures to safeguard cloud-hosted web applications and APIs.
Palo Alto Networks customers using Prisma Cloud are protected from these threats through the WAAS module, which is designed to protect web applications and APIs in cloud environments.
Our introductory blog Cold as Ice: Unit 42 Wireshark Quiz for IcedID provides a packet capture (pcap) from an IcedID infection in April 2023. This blog provides the answers. Also known as Bokbot, IcedID is well-established Windows-based malware that can lead to ransomware. Reviewing the pcap provides an opportunity to analyze IcedID infection traffic.
Traffic for this quiz occurred in an Active Directory (AD) environment during April 2023. The infection is similar to previous IcedID activity tweeted by Unit 42 in March 2023. Details of the Local Area Network (LAN) environment for the pcap follow.
LAN segment range: 10.4.19[.]0/24 (10.4.19[.]1 through 10.4.19[.]255)
Domain: boogienights[.]live
Domain controller IP address: 10.4.19[.]19
Domain controller hostname: WIN-GP4JHCK2JMV
LAN segment gateway: 10.4.19[.]1
LAN segment broadcast address: 10.4.19[.]255
This quiz requires Wireshark, and we recommend using the latest version of Wireshark, 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 April 2023 ZIP archive and extract the pcap. Use infected as the password to unlock the ZIP archive.
Quiz Questions
For this IcedID 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?
Is there any follow-up activity from other malware?
Quiz Answers
The AD environment for this pcap contains three Windows clients, but only one was infected with IcedID.
Answers for this Wireshark quiz follow.
Malicious traffic for this infection started on April 19, 2023, at 15:31 UTC.
Infected Windows client IP address: 10.4.19[.]136
Infected Windows client MAC address: 14:58:d0:2e:c5:ae
Infected Windows client hostname: DESKTOP-SFF9LJF
Infected Windows client user account name: csilva
Follow-up activity: BackConnect traffic
Pcap Analysis: IcedID Chain of Events
To understand IcedID network traffic, you should understand the chain of events for an IcedID infection. A flow chart illustrating this chain of events is shown in Figure 1.
Figure 1. Flowchart for chain of events in the April 2023 IcedID infection.
Most IcedID infections use a standard variant of IcedID. These infections typically use an EXE or DLL that acts as an installer. This installer generates an unencrypted HTTP GET request that retrieves a gzip-compressed binary. The installer then converts this binary into malware used for a persistent IcedID infection.
The newly created, persistent IcedID generates HTTPS traffic to communicate with command and control (C2) servers. The C2 activity can lead to BackConnect traffic, Cobalt Strike and Virtual Network Computing (VNC) activity.
If the infected host is part of a high-value environment, an IcedID infection would likely lead to ransomware.
Pcap Analysis: Infection Vector
Using Wireshark customized from our tutorials, apply a basic web filter to see if anything stands out. Review the results in your column display. Look for unencrypted HTTP traffic over TCP port 80 directly to an IP address without an associated domain. This is a common characteristic in the chain of events for various malware infections.
At 15:31:08 UTC, the host at 10.4.19[.]136 generated an HTTP GET request to hxxp://80.77.25[.]175/main.php as shown below in Figure 2.
Figure 2. Suspicious HTTP traffic directly to an IP address shown in Wireshark.
Follow the TCP stream for this HTTP GET request, as shown in Figure 3. This should generate a window for TCP stream 32, as shown in Figure 4.
Figure 3. Following TCP stream for suspicious HTTP GET request.Figure 4. TCP stream for the suspicious HTTP GET request and response.
Figure 4 reveals HTTP request headers that contain a User-Agent string ending with Edg/112.0.1722.48. This string indicates the traffic was likely generated by the Microsoft Edge browser. However, web traffic generated by malware can spoof different User-Agent strings, and some browser extensions also have this ability, so we cannot be certain this was actually Microsoft Edge.
The HTTP response headers in Figure 4 show a 302 code, redirecting traffic to the following URL:
This Firebase Storage URL has been reported as malicious by at least seven security vendors on VirusTotal, and it appears in URLhaus tagged as IcedID. Fortunately, Google has taken the URL offline, and it is no longer active.
To further refine our search, add the client’s IP address 10.4.19[.]136 to the basic web filter as shown below in Figure 5. This reveals HTTPS traffic to firebasestorage.googleapis[.]com shortly after traffic to the initial URL at hxxp://80.77.25[.]175/main.php.
Figure 5. HTTPS traffic to firebasestorage.googleapis[.]com after the initial suspicious URL.Follow the TCP stream for the initial frame showing fire in the Wireshark column display. The TCP stream reveals 273 KB of data sent from the server to the Windows host, as shown below in Figure 6. This indicates a file might have been sent to the Windows host.
Figure 6. TCP stream showing 275 KB of data sent from firebasestorage.googleapis[.]com to the Windows host.While the Firebase Storage URL is tagged as IcedID on URLhaus, this only indicates a distribution method for the IcedID installer. Based on this pcap, the victim opened a link that led to the Firebase Storage URL, and that URL delivered a file for an IcedID installer.
Figure 7. URLhaus entry for our firebasestorage URL shows it delivered a zip archive.
The ZIP archive was submitted to Malware Bazaar. The archive is password-protected with the ASCII string 1235, and it contains a file named Scan_Inv.exe. This Windows executable file is an IcedID installer.
Pcap Analysis: IcedID Traffic
An IcedID loader first generates an unencrypted HTTP GET request over TCP port 80 to a domain using GET / without any further URL. This returns a gzip binary used by the installer to create the persistent malware on the victim’s host.
To find the gzip binary, use the same basic web filter with the victim’s IP address noted earlier in Figure 5. Scroll down to an HTTP GET request to skigimeetroc[.]com at 15:35:39 UTC and follow the TCP stream as shown below, in Figure 8.
Figure 8. Following the TCP stream for IcedID installer’s initial HTTP GET request.
This is TCP stream 53 from the pcap, as shown below in Figure 9. The HTTP request headers for traffic generated by the IcedID installer have no User-Agent string. Note the cookie sent in the request headers in Figure 9.
Figure 9. HTTP GET request generated by the IcedID installer.
_ga= Information based on the infected host’s CPU.
_gat= Windows version. For example, 10.0.22621.64 is an identifier for 64-bit Windows 11 version 22H2 and 10.0.19045.64 is an identifier for 64-bit Windows 10 version 22H2.
These cookie parameters are unique to IcedID infections. You can identify this traffic as IcedID without understanding the values. However, the _u= parameter reveals the victim’s hostname and Windows user account name. This information is very useful for our investigation. These hex values translate to a hostname of DESKTOP-SFF9LJF and a Windows user account name of csilva, as shown below in Figure 10.
Figure 10. Using the _u= cookie parameter to determine the victim’s hostname and Windows user account name.
After retrieving the gzip binary, an IcedID installer creates persistent IcedID malware that takes over the infection. The infected Windows host then starts generating HTTPS traffic to IcedID C2 servers.
These C2 servers use different domain names and IP addresses than the initial domain contacted by the IcedID installer. IcedID’s HTTPS C2 traffic starts within a minute or two after the installer retrieves the gzip binary, and this activity uses at least two domains with random alphabetic names.
Our pcap reveals HTTPS traffic from the infected host to two domains after skigimeetroc[.]com at 15:35:39 UTC. These HTTPS C2 servers are askamoshopsi[.]com on 104.168.53[.]18 and skansnekssky[.]com on 217.199.121[.]56.
To find these servers, use the same basic web filter with the victim’s IP address noted earlier in Figure 5. HTTPS traffic starting at 15:36:41 UTC reveals these domains, as shown below in Figure 11.
Figure 11. HTTPS C2 traffic after HTTP request by the IcedID installer.
Both C2 servers at askamoshopsi[.]com and skansnekssky[.]com use self-signed certificates for their HTTPS traffic. Self-signed certificates for HTTPS traffic will generate warnings about potential security risks when the site is viewed in any modern web browser.
Why do web browsers display warnings about websites that use self signed certificates? Because these are not validated by a Certificate Authority. Criminals can generate self-signed certificates that impersonate an existing company, or they can use generic values for the certificate issuer. Without a validated certificate, web browsers cannot be sure a website is what it says it is.
Figure 12 shows what the server at askamoshopsi[.]com looked like when we attempted to view it with the Firefox web browser. This warning allows users to view the server’s self-signed certificate.
Figure 12. Attempting to view the web server at askamoshopsi[.]com using Firefox.As shown above in Figure 12, the certificate uses values like Internet Widgits Pty Ltd for the issuer’s Organization name and Some-State for the State/Province name. Values for self-signed certificates used by IcedID C2 servers are the same default values seen when using OpenSSL to create a certificate in Xubuntu as shown below in Figures 13 and 14.
Figure 13. Creating an x509 certificate for a web server using OpenSSL in Xubuntu.Figure 14. Default values when creating an x509 certificate for a web server using OpenSSL in Xubuntu.
Since Internet Widgits Pty Ltd is a default value for a self-signed certificate in HTTPS traffic, and this value is sometimes seen in C2 traffic for malware. This should be more closely examined if it’s found when investigating a suspected malware infection. We can easily check any pcap for this value using the following Wireshark filter:
x509sat.uTF8String eq "Internet Widgits Pty Ltd"
The results from our pcap reveal the same IP addresses used by IcedID C2 servers for askamoshopsi[.]com at 104.168.53[.]18 and skansnekssky[.]com at 217.199.121[.]56. Expand the frame details for any of the results to find the same certificate issuer data, as shown in Figure 15.
Figure 15. Self-signed certificate by IcedID C2 servers using Internet Widgits Pty Ltd as the Organization name shown in Wireshark.
This certificate data is not unique to IcedID. The same values for self-signed certificates are also seen in HTTPS C2 traffic by other malware families like Bumblebee.
Pcap Analysis: BackConnect Traffic
Undetected IcedID infections lead to follow-up activity like BackConnect traffic.
For the past several months, BackConnect traffic caused by IcedID was easy to detect because it occurred over TCP port 8080. However, as early as April 11, 2023, BackConnect activity for IcedID changed to TCP port 443, making it harder to find.
This BackConnect activity from IcedID Unit 42 tweeted on April 11, 2023 used an IP address of 193.149.176[.]100 over TCP port 443. Filter for that IP address in Wireshark and combine it with tcp.flags eq 0x0002 as shown below, in Figure 16. This reveals the beginning of three streams.
Figure 16. Filtering in Wireshark for BackConnect traffic in our pcap.
Follow the TCP stream for the first result, which is TCP stream 950. This stream reveals encoded or otherwise encrypted TCP traffic, as shown in Figure 17.
Figure 17. The first TCP stream for BackConnect activity.
Go back to the Wireshark filter used to reveal the TCP streams to 193.149.176[.]100. Follow the TCP stream for the second frame in the results, which is TCP stream 951. This reveals encoded or encrypted data followed by a command to reveal all hosts under the domain controller for boogienights[.]live as shown below, in Figure 18.
Figure 18. BackConnect traffic with a command to and results enumerating the victim’s AD environment.
The response to this command enumerates the victim’s AD environment, showing three clients logged in to the domain:
DESKTOP-JAL4D68
DESKTOP-RETP4BU
DESKTOP-SFF9LJF
Go back to the Wireshark filter used to reveal the TCP streams to 193.149.176[.]100. Follow the TCP stream for the last frame in the results, which is TCP stream 953. This lists disk drives on the victim client, and it provides a directory listing for each of these drives, as shown below in Figure 19.
The C:\ drive is the victim’s system drive. Z:\ is likely a mapped drive from a server’s shared directory that does not contain any files.
Figure 19. BackConnect traffic showing contents of the victim’s system drive and mapped drive.
Previous IcedID infections reveal this threat can use BackConnect traffic to load and run Cobalt Strike. We tweeted about one such case from March 24, 2023. However, this pcap does not contain any indicators of Cobalt Strike.
Previous IcedID infections also reveal this threat can generate VNC traffic over the same IP address used by BackConnect traffic. This happened during the same IcedID infection from March 24, 2023.
Pcap Analysis: Victim Details
The common internal IP address for the malicious traffic we have reviewed is 10.4.19[.]136. This is our victim’s IP address. To find the Windows user account name, filter on that IP address and kerberos.CNameString as shown in Figure 20.
Figure 20. Finding the Windows user account name for our infected Windows host.
In some cases, lightweight directory access protocol (LDAP) might also provide the full name of the user. Use the following Wireshark filter:
ldap.AttributeDescription == "givenName"
This should provide four frames in our column display. Select any of them and expand the frame details until you find the user’s full name, Cornelius Silva, as shown below in Figure 21.
Figure 21. Finding the victim’s full name from LDAP traffic.
Perhaps the easiest way to find a victim’s hostname in Wireshark is to combine the victim’s IP address with a search for ip contains "DESKTOP-" as shown below, in Figure 22. Several results in the info column show Host Announcement DESKTOP-SFF9LJF sent by our infected Windows host at 10.4.19[.]136.
Figure 22. Finding the Windows hostname in Wireshark.
To find the victim’s MAC address, just correlate the IP address to the host’s MAC address in any of the frame details windows, as shown below in Figure 23.
Figure 23. Correlating the victim’s MAC address with its associate IP address.
Conclusion
This blog provides answers and analysis for our Unit 42 Wireshark quiz featuring an IcedID infection from April 2023. IcedID is important to identify and stop, because it is a known vector for ransomware infections.
Many organizations lack access to full packet capture in their IT environment. As a result, security professionals might lack experience reviewing IcedID and other malware traffic. Training material like this Wireshark quiz can help. Pcap analysis is a useful skill that helps us better understand malicious activity.
You can also read the original post, without answers, from our standalone quiz post.
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 IcedID infection:
So far in 2023, IcedID has been a relatively constant presence in our threat landscape. Also known as BokBot, IcedID is Windows-based malware that can lead to ransomware. This Wireshark quiz presents a packet capture (pcap) from an IcedID infection that occurred in April 2023, and it provides experience analyzing traffic generated by this malware.
Anyone can participate in this quiz. However, participants should have some familiarity with Wireshark. Participants should also have a basic knowledge of IPv4 traffic. Palo Alto Networks has published a series of Wireshark tutorials to help people gain knowledge helpful for these quizzes.
Traffic for the IcedID infection occurred in an Active Directory (AD) environment during April 2023. This infection is similar to previous IcedID activity from March 24, 2023, which was tweeted by Unit 42.
Details of the network and questions for the quiz follow.
Local Area Network (LAN) Details
LAN segment range: 10.4.19[.]0/24 (10.4.19[.]1 through 10.4.19[.]255)
Domain: boogienights[.]live
Domain controller IP address: 10.4.19[.]19
Domain controller hostname: WIN-GP4JHCK2JMV
LAN segment gateway: 10.4.19[.]1
LAN segment broadcast address: 10.4.19[.]255
Quiz Questions
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?
Is there any follow-up activity from other malware?
Requirements
Since this is a Wireshark quiz, participants should use Wireshark to review the pcap. We encourage participants to customize Wireshark when reviewing malware traffic. Participants can customize Wireshark as demonstrated in the Unit 42 series of tutorials and videos.
We recommend using the latest version of Wireshark, since it has more features, capabilities and bug fixes over previous versions. Older Wireshark versions like 1.x and 2.x are not recommended for our Wireshark quizzes.
Infection traffic often contains malicious code targeting Microsoft Windows, so we recommend using a non-Windows environment to review the pcap for this quiz. Operating systems like BSD, Linux or macOS provide an ideal environment for Wireshark when reviewing traffic from Windows-based malware like IcedID.
Accessing the Pcap
To obtain the pcap, visit our GitHub repository as shown in Figure 1 and download the ZIP archive named 2023-04-Unit42-Wireshark-quiz.pcap.zip as shown in Figure 2. Use infected as the password to unlock the ZIP archive as shown in Figure 3.
Figure 1. Selecting the pcap for this quiz from our GitHub repository.Figure 2. Downloading the pcap.Figure 3. Extracting the pcap from the downloaded ZIP archive.
Conclusion
IcedID is a prominent part of our current threat landscape. This Wireshark quiz can help participants better understand network traffic associated with an IcedID 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.
On April 10, Unit 42 researchers observed a Mirai variant called IZ1H9, which used several vulnerabilities to spread itself. The threat actors use the following vulnerabilities to target exposed servers and networking devices running Linux:
Compromised devices can be fully controlled by attackers and become a part of the botnet. Those devices can be used to conduct further attacks, such as distributed denial-of-service (DDoS) attacks.
Since November 2021, Unit 42 researchers have observed multiple campaigns using the Mirai IZ1H9 variant. Based on our analysis, we believe that these campaigns were operated by the same threat actor for the following reasons:
The malware shell script downloaders used in both campaigns are almost identical.
The botnet samples use the same XOR decryption key: 0xBAADF00D
The botnet client samples use almost identical functions.
Botnet client samples among those campaigns share the same infrastructure.
On April 10, 2023, Unit 42 researchers observed some abnormal traffic from our threat hunting system. This threat group tried to download and execute a shell script downloader lb.sh from IP 163.123.143[.]126.
If executed, the shell script downloader would first delete logs to hide its tracks. Then the following bot clients would be downloaded and executed, to accommodate different Linux architectures:
hxxp://163.123.143[.]126/bins/dark.x86
hxxp://163.123.143[.]126/bins/dark.mips
hxxp://163.123.143[.]126/bins/dark.mpsl
hxxp://163.123.143[.]126/bins/dark.arm4
hxxp://163.123.143[.]126/bins/dark.arm5
hxxp://163.123.143[.]126/bins/dark.arm6
hxxp://163.123.143[.]126/bins/dark.arm7
hxxp://163.123.143[.]126/bins/dark.ppc
hxxp://163.123.143[.]126/bins/dark.m68k
hxxp://163.123.143[.]126/bins/dark.sh4
hxxp://163.123.143[.]126/bins/dark.86_64
In the last step, the shell script downloader would block network connection from several ports including SSH, telnet and HTTP. It did so by modifying the device’s iptable rules, so that the victim wouldn’t be able to connect and recover the compromised device remotely, as depicted in Figure 1.
Figure 1. Iptable modification.
Threat Group Analysis
Unit 42 researchers conducted analysis on the downloaded botnet client samples and found two URLs hosting more shell script downloaders:
hxxp://2.56.59[.]215/i.sh
hxxp://212.192.241[.]72/lolol.sh
Figure 2 is a diagram illustrating the campaign overview.
Figure 2. Campaign overview diagram.
The shell script downloader from 2.56.59[.]215 would download botnet clients from hxxp://2.56.59[.]215/bins/. Those botnet client samples would contact a command and control (C2) server at 195.133.40[.]141 where there were URLs in the malware samples that hosted two shell scripts:
hxxp://31.210.20[.]100/lolol[.]sh
hxxp://212.192.241[.]72/lolol[.]sh
The shell script downloader from 212.192.241[.]72 would download botnet clients from hxxp://212.192.241[.]87/bins/, and those botnet client samples would contact the C2 domain dotheneedfull[.]club.
Malware Analysis
Based on behavior and patterns Unit 42 researchers observed during the analysis of the downloaded samples, we believe that they are a variant of the Mirai botnet called IZ1H9.
Discovered in August 2018, IZ1H9 is one of the most active Mirai variants. Just like the original Mirai, the IZ1H9 botnet client first checks the network portion of the infected device’s IP address. The client avoids execution for a list of IP blocks, including government networks, internet providers and large tech companies.
The botnet client makes its presence visible by printing the word “Darknet” to the console. The malware also contains a function that ensures the device is running only one instance of this malware. If a botnet process already exists, the botnet client will terminate the current process and start a new one, as depicted in Figure 3.
Figure 3. IZ1H9 ensures there is only a single instance of execution.
The botnet client also contains a list of process names belonging to other Mirai variants and other botnet malware families. The malware checks the running process names on the infected host to terminate them.
The IZ1H9 variant tries to connect to a hard-coded C2 address: 193.47.61[.]75, as shown in Figure 4.
Figure 4. IZ1H9 malware C2 address.
Botnet Client Configuration String Decryption
For botnet client configuration strings, the IZ1H9 variant will first initialize an encrypted string table. It will then retrieve the encrypted strings through an index (as shown in Figures 5 and 6).
The IZ1H9 variant uses a table key during the string decryption process: 0xBAADF00D. For each encrypted character, the malware performs XOR decryption with the following bytewise operations:
According to the logic behind XOR operation, the configuration string key equals to
0xBA ^ 0xAD ^ 0xF0 ^ 0x0D = 0xEA
IZ1H9 Sample Spreading Through HTTP, SSH and Telnet Protocol
For SSH and telnet channels, IZ1H9 inherits the most significant feature from the original Mirai source code: a data section with embedded default login credentials for scanner and brute-force purposes.
The original Mirai and IZ1H9 also both encrypt their login credentials with a 1 byte XOR key. The keys vary in different versions, but this variant uses 0x54, as shown in Figure 7.
This IZ1H9 variant initializes the table of nearly 100 pairs of telnet/SSH login credentials in the scanner function. It then spreads through brute forcing network devices’ weak username and password combinations.
For the HTTP channel, IZ1H9 uses four remote code execution vulnerabilities to get access to the vulnerable devices, and it executes the shellcode script downloader shown in Figure 8.
Figure 8. Exploit scanner function.
Notice that in the Tenda vulnerability exploit function, the payload downloads tenda.sh from the malware host server but executes netlog.sh, as shown in Figure 9. In this case, the exploit will not work.
Figure 9: Malware executes wrong downloader.
The malware will initialize all DDoS attack functions before the botnet client establishes a connection with the C2 server. According to the Mirai source code, the malware developer will define the attack method and assign a command code to represent the attack method, as depicted in Figure 10.
Figure 10. Mirai attack method definition.
In this IZ1H9 sample, the threat actor defines a set of attack methods, shown in Table 1.
Command
Attack Method
Description
0
attack_method_tcpsyn
TCP SYN flooding attack
1
attack_method_tcpack
TCP ACK flooding attack
2
attack_method_tcpusyn
TCP URG-SYN flooding attack
3
attack_method_tcpall
TCP DDoS with all options set
4
attack_method_tcpfrag
TCP fragmentation attack
5
attack_method_asyn
TCP SYN-ACK flooding attack
6
attack_method_udpgame
UDP attack targets online gaming servers
7
attack_method_udpplain
UDP flooding with fewer options
8
attack_method_greip
GRE IP flooding attack
9
attack_method_std
STD flooding attack
10
attack_method_udpdns
DNS flooding attack
11
attack_method_udpgeneric
UDP flooding attack
12
attack_app_http
HTTP flooding attack
13
attack_method_dnsamp
DNS amplification attack
Table 1. IZ1H9 attack method.
Conclusion
IoT devices have always been a lucrative target for threat actors, and remote code execution attacks continue to be the most common and most concerning threats affecting IoT devices and linux servers. Exposed vulnerable devices could lead to serious threats.
The vulnerabilities used by this threat are less complex, but this does not decrease their impact, since they could still lead to remote code execution. Once the attacker gains control of a vulnerable device, they can include the newly compromised devices in their botnet. This allows them to conduct further attacks such as DDoS.
To combat this threat, it is highly recommended that patches and updates are applied when possible.
Palo Alto Networks customers receive protection from the vulnerabilities and malware discussed above through the following products and services:
Next Generation Firewall with a Threat Prevention security subscription can help block the attacks with Best Practices via Threat Prevention signatures: 93386, 93718, 93721, 93722.
Advanced Threat Prevention provides inline machine learning that can detect vulnerability exploits in real time.
WildFire can help stop the malware with static signature detections.
Advanced URL Filtering and DNS Security are able to block the C2 domain and malware-hosting URLs.
The Palo Alto Networks IoT Security platform can leverage network traffic information to identify the vendor, model and firmware version of a device, and it can identify specific devices that are vulnerable to particular CVEs.
In addition, IoT Security has inbuilt machine learning-based anomaly detection that can alert the customer if a device exhibits nontypical behavior such as the sudden appearance of traffic from a new source, an unusually high number of connections, or an inexplicable surge of certain attributes typically appearing in IoT application payloads.
This malicious traffic was first detected as a part of the IZ1H9 campaign on April 10, 2023. The command injection vulnerability is due to the failure to sanitize the value of the language parameter in the cgi-bin/luci interface of Tenda G103.
We captured this exploit traffic on April 10, 2023. The exploit targets a command injection vulnerability in the LB-Link wireless router’s /goform/set_LimitClinet_cfg component, which does not successfully sanitize the user input in the time1, time2 and mac parameters. This leads to arbitrary command execution.
The exploit was detected on April 10, 2023. The exploit works due to the Digital China Network DCBI-Netlog-LAB nsg_masq.cgi component failing to adequately sanitize the user-supplied input data, which leads to remote command execution.
We observed this exploit traffic on Dec. 16, 2022. The exploit targets the Zyxel router’s /bin/zhttpd/ component. If insufficient input validation is found, the attacker can exploit the vulnerability to launch a remote code execution attack.
Within Unit 42 Threat Intelligence, we are often asked, “How does Unit 42 define and track actor activity?” To answer this question, we’ll give you a glimpse into our day-to-day activities, specifically focusing on how Unit 42 Threat Intelligence tracks behavior-based activity clusters.
The convention that Unit 42 Threat Intelligence uses for naming formal threat actor groups has been discussed in a previous blog. In this post, we’ll step back to give you a broader view, covering how the Unit 42 team builds and tracks activity clusters, and then associates this behavior with temporary threat actor groups. We’ll also discuss how we decide when to enact our formal actor naming and definition processes.
Defining a cluster of activity or a temporary actor group is a complex and often ambiguous process that typically takes a lot of time, effort and coordination. Formal actor naming begins when our team analyzes artifacts and TTPs from a single intrusion. It then evolves when we build and track additional activity into what we call an activity cluster.
Activity clusters consist of observed threat actor behavior that we have identified and use as a basis for tracking. These behaviors are clustered into groups of tactics, techniques and procedures (TTPs). We continually review and push these TTPs through our analysis process such that the clusters grow over time, potentially becoming a temporary threat actor group.
Figure 1. Logical flow of tracked activity cluster to a formal actor name.
To achieve Unit 42’s mission of protecting the digital world against cyberattacks, we need to consistently track and monitor activity clusters and temporary threat actor groups.
Activity Clusters
An activity cluster is a grouping of related threat activity that includes observable artifacts like adversary tools, infrastructure or trade craft. The intention of defining an activity cluster is to build out a corpus of knowledge on a cluster of activity over time before “graduating” that cluster to a temporarily tracked threat group.
These clusters start with data collected in a single incident or investigation, and they grow by piecing together additional data from other incidents and collection sources. While running investigations, Unit 42 researchers often discover new artifacts associated with their investigations that can grow, merge or break off clusters of activity.
The Unit 42 team defines activity clusters based on our hypothesis of the actor’s motivation, where it is possible to establish. We name clusters using the following shorthand notation:
CL - short for cluster
CRI - short for criminal motivation
STA - short for state-backed motivation
MIX - short for mixed motivation
UNK - short for unknown motivation
Using this shorthand, Unit 42 names clusters of activity as follows:
CL-{CRI | STA | MIX | UNK} - ####
The number assigned to the activity cluster is in consecutive order, incrementing by one from the previously classified activity cluster.
Let’s examine how this looks with an example.
Unit 42 researchers are often involved in the research of multiple incidents targeting medical facilities throughout the United States. While working on each of the incidents, we find that the different adversary tools, infrastructure and trade craft are sometimes related. This helps us form an activity cluster.
We will often find the adversary exploiting the same vulnerabilities to gain initial access, applying the same lateral movement and exfiltration tactics, and using the same infrastructure for command and control (C2) across varying medical organizations. However, in many cases, we might not know the motivation of the adversary. Based on this, Unit 42 could track this as an activity cluster named CL-UNK-0042.
Now that we’ve examined some of the core tenants of tracking activity clusters, let’s examine the next step of our definition process: creating temporary actor groups.
Temporary Actor Groups
The concept of creating temporary actor groups is a way for the Unit 42 team to graduate activity clusters to a more solidified categorization. This graduation means the researcher feels confident that a single actor is participating in the threat activity.
It is important to note that within Unit 42 Threat Intelligence, we prevent direct migration of activity clusters to formally named actor groups. The activity clusters must first go through graduation to a temporary threat actor group.
This graduation is done after establishing several correlation points over time and across activity clusters, and after mapping those overlaps to the Diamond Model of Intrusion Analysis. This model focuses on core features of intrusions such as adversary, capability, victim and infrastructure, which Unit 42 researchers leverage and examine to correlate related clusters of activity.
For temporary actor groups, we opted to keep the same naming convention, with the addition of TGR, which is short for “threat group.”
We name temporary group names as follows:
TGR-{CRI | STA | MIX | UNK} - ####
Like the numbering for activity clusters, the number assigned at the end of the name for a threat group is in consecutive order, incrementing by one from the previously classified threat group.
Let’s look at an example of how we name a temporary actor group using our defined convention, continuing with tracking CL-UNK-0042. Further tracking and analysis revealed shared usage of phishing and C2 infrastructure in addition to overlaps with another activity cluster: CL-STA-0073.
During tracking, researchers also determined that threat actors were sharing tooling and malware throughout both clusters of activity, some of which were custom created. Based on these and previous investigative findings, Unit 42 could now start tracking clusters CL-STA-0042 and CL-STA-0073 as TGR-STA-0051.
Consistent tracking and analysis over time of TGR-STA-0051 could ultimately lead to a formal Unit 42 threat actor name, after we establish higher confidence in the relationship between the temporary group and the formal group.
Final Thoughts
In this blog, we wanted to give a glimpse into a day in the life of a researcher who’s identifying, defining and tracking activity clusters and temporary threat actor groups. We hope this insight provides clarity into how some of the more nebulous aspects of threat research are performed. You can now be better informed about the meaning of these two groupings, as Unit 42 starts to leverage activity clusters and temporary actor groups in our forthcoming publications.
Royal ransomware has been involved in high-profile attacks against critical infrastructure, especially healthcare, since it was first observed in September 2022. Bucking the popular trend of hiring affiliates to promote their threat as a service, Royal ransomware operates as a private group made up of former members of Conti.
The Unit 42 team has observed this group compromising victims through a BATLOADER infection, which threat actors usually spread through search engine optimization (SEO) poisoning. This infection involves dropping a Cobalt Strike Beacon as a precursor to the ransomware execution. Unit 42 incident responders have participated in 15 cases involving Royal ransomware in the last 9 months.
Royal ransomware also expanded their arsenal by developing an ELF variant to impact Linux and ESXi environments. The ELF variant is quite similar to the Windows variant, and the sample does not contain any obfuscation. All strings, including the RSA public key and ransom note, are stored as plaintext.
Palo Alto Networks customers receive protections against ransomware used by the Royal ransomware group from Cortex XDR, as well as from the WildFire Cloud-Delivered Security Service for the Next-Generation Firewall. The Unit 42 Incident Response team can also be engaged to help with a compromise or to provide a proactive assessment to lower your risk.
The Royal ransomware group was first observed in September 2022, compromising victims and using multi-extortion to pressure victims to pay their fee. Before their first appearance, this group had been linked to a previous ransomware family named Zeon, starting in January of the same year.
Unlike major ransomware groups like LockBit 3.0, which typically operate as a ransomware-as-a-service (RaaS) by hiring affiliates and promoting their RaaS model, we have not observed this particular group using a similar approach. It is suspected that this group is made up mainly of former members of the Conti ransomware group, who operate covertly and behind closed doors. The ex-members that formed this group are known as Team One.
Because some of the people behind this threat were part of the development of Ryuk (discovered in 2018), which is the predecessor of Conti, they have many years of experience. This means they have a solid base for carrying out attacks and know what works when extorting victims. Perhaps due to this experience, the group has already impacted numerous organizations across the globe. We’ve observed them making demands up to $25 million dollars in BTC.
Royal also has frequently threatened certain critical infrastructure sectors, such as manufacturing and healthcare. In a few months in 2022, the group impacted 14 manufacturing organizations, according to their leak site, and then followed up by publicizing claims of attacking 26 additional manufacturing organizations in 2023. They have also impacted eight healthcare organizations since their inception. The U.S. Department of Health and Human Services issued a warning about the threat Royal ransomware poses to the healthcare sector in January 2023.
Royal also has been one of the ransomware groups disrupting the education industry. We observed that they impacted 14 organizations in the education sector, including school districts and universities. In fact, in just the first few days of May 2023, the group had already impacted four educational institutions.
This group has leveraged their leak site to publicly extort victims into paying the ransom, as shown in Figure 1. The Royal group will harass victims until the payment is secured, using techniques such as emailing victims and mass-printing ransom notes.
Figure 1. Royal ransomware leak site.
The Royal ransomware threat actor has an active Twitter account that was created in October 2022, called “LockerRoyal.” Most of the account content is announcements of compromised victims, tagging the victim’s Twitter account. In some cases, the threat actor will also reply to those same announcements.
It’s not unusual to see threat actor groups create social media accounts to keep spreading their brand and announcements. It’s clear that this group is trying to get attention from multiple organizations through any means necessary.
Figure 2. Royal Twitter account replying to an alert.
This particular ransomware group has been observed using multiple initial access vectors to secure access into vulnerable systems, such as the following:
Once access is secured, this group uses multiple tools to support the intrusion operation, like the TCP/UDP tunnel Chisel and the Active Directory query tool AdFind, among others.
Victimology
Royal ransomware has impacted a variety of industries, including small businesses and large corporations alike. Based on information from their leak site and public reporting outlets, we can see that Royal ransomware has impacted industries such as manufacturing, as well as wholesale and retail. Since 2022, Royal ransomware has claimed responsibility for impacting 157 organizations on their leak site.
It's important to note that the impact of Royal ransomware extends beyond just financial losses. There have been instances where the group has targeted critical infrastructure, such as healthcare organizations and agricultural facilities. Since 2022, we have observed this group impacting seven local government entities – like the recent attack on the city of Dallas – in the United States and Europe.
Unit 42 incident responders have participated in 15 cases involving Royal ransomware.
This demonstrates the potential for broader and more severe consequences, as shown in Figure 3.
Figure 3. Industries distribution per Royal leak site post.
Most of the organizations impacted by this ransomware are located in the United States, comprising 64% of the impacted organizations. Canada is the country second most impacted by this ransomware family, making the total for North America 73.2%. The next most impacted countries include Germany, the United Kingdom, Brazil, Italy and others (shown in Figure 4).
Figure 4. Countries impacted distribution per Royal leak site post.
Infection Chain
There are several different infection chains that lead to Royal ransomware. In some cases, we have observed instances where SEO poisoning and malvertising were used as initial access vectors. The goal of these two methods is to trick a victim into downloading and executing a malicious file that masquerades as legitimate software.
This kicks off a complex infection chain with multiple stages, including PowerShell scripts and MSI files. In certain cases, this leads to infection with BATLOADER.
BATLOADER will then attempt to download further payloads to the infected machine, such as VidarStealer, Ursnif/ISFB and Redline Stealer, as well as legitimate tooling such as the system management tool NSudo and the Syncro remote monitoring and management (RMM) tool. Most importantly, BATLOADER has been seen loading Cobalt Strike, which is often a precursor to ransomware distribution.
In one particular case where we saw Royal ransomware deployed, a snippet of C# code was identified that was originally pulled down from Pastebin. This code, when compiled, would decrypt and load shellcode. The shellcode appeared to be a simple Meterpreter stager that would reach out to an IP address and execute the final Meterpreter beacon. The IP address also hosted a Cobalt Strike server, from which we were able to retrieve the Cobalt Strike configuration.
The configuration contained fairly standard values, although the watermark appeared to be somewhat unique and not randomly generated: 12345. Querying for live Cobalt Strike servers on Shodan with the same watermark returned just over 50 results.
While this unique watermark could indicate a cracked version of Cobalt Strike, examining the domain names for these C2s revealed commonalities across the board. Almost every domain was named to resemble a security company.
For example, the following servers hosted Cobalt Strike beacons with the watermark 12345:
altocloudzone[.]live
cloudmane[.]online
palaltocloud[.]online
kasperslkyupdate[.]com
palalto[.]live
altocdn[.]online
paloaltokey[.]store
kasperskyupdates[.]com
Rapidfinact[.]com
Note that the names above are the work of a threat actor attempting to impersonate legitimate organizations and do not represent actual affiliations with that organization. The threat actor’s impersonation does not imply a vulnerability in the legitimate organizations’ products or services.
Defense Evasion
Unit 42 researchers observed Royal ransomware operators using PowerTool. This is a piece of software that has access to the kernel and is ideal for removing endpoint security software. They also executed batch scripts to disable security-related services, and deleted shadow file copies and logs after successful exfiltration.
Lateral Movement
Unit 42 researchers observed Royal threat actors using the network discovery software NetScan to identify and map out various connected computer resources such as other user targets and shares. In addition to using NetScan, we also observed them using PsExec for conducting lateral movement within the infected environments.
Command and Control (C2)
Unit 42 researchers observed threat actors using various popular legitimate remote management software also used heavily by other ransomware operations to maintain access to the infected environment. The use of Cobalt Strike and related beacons were also observed for C2. An interesting observation of a tool used for maintaining access was the use of Chisel, a TCP/UDP tunneling tool written in Golang.
Exfiltration
Unit 42 researchers observed Royal threat actors using Rclone, a legitimate tool to manage files between two systems, for exfiltrating stolen data before the deployment of ransomware. We found Rclone deployed in folders such as ProgramData, or renamed and masquerading in other folders. One popular filename used was svchost.exe.
Ransomware Functionality
Windows Variant
It is important to note that, while many ransomware families employ various forms of anti-analysis, as of late April, Royal ransomware does not employ anti-analysis tricks or string encryption.
There are five possible arguments for the Windows variant of Royal ransomware:
Argument
Purpose
-path
Path to be used for targeting encryption
-id
32-character ID for running sample
-ep
Encryption percentage - indicates the percentage of each file to be encrypted
-localonly
Encrypt only the local system
-networkonly
Encrypt file shares connected to system
In Figure 5 below, the decompiled view contains the various command-line arguments to be evaluated at the start of the binary being executed.
Figure 5. Command-line arguments Royal accepts as inputs.
Upon evaluating the command-line arguments provided, the ransomware then will create a cmd.exe process with the parameter to execute vssadmindelete shadows /all /quiet. The command is part of the standard ransomware playbook for impacting restoration services.
For the encryption process, Royal ransomware has a hard-coded RSA public key within the binary and uses AES for encryption. The AES encryption is set up using a 32-byte key and a 16-byte initialization vector (IV). The encrypted files are encrypted with the extension .royal_w.
During file enumeration and encryption, the sample avoids files with the following extensions and filenames (also shown in Figure 6):
Extensions:
.exe
.dll
.bat
.lnk
.royal_w
.royal_u
Files and folders:
README.TXT
Windows
Royal
Recycle.bin
Google
Perflogs
Mozilla
Tor browser
Boot
$Windows.~ws
$Windows.~bt
Windows.old
During the encryption process, if a file is encountered which is actively being used by the computer system, the ransomware can use the RestartManager API functionality to close a file. As shown in Figure 6, the strings related to skipped extensions and folder paths are shown in the .rdata section of the binary.
Figure 6. Extensions and folders excluded.
The ransom note dropped as a README.txt is shown in Figure 7 below.
Figure 7. Royal ransomware ransom note.
Royal also contains functionality to encrypt network shares connected to the victim machine. The decompiled view of the code path responsible for enumerating shares is shown in Figure 8 below.
Figure 8. Enumerates network shares and excludes ADMIN and IPC shares.
For supporting cryptographic operations used in the ransomware, the code is statically compiled with OpenSSL. The cryptographic references can be seen in Figure 9 below and can be cross-referenced by examining the library on GitHub.
Figure 9. OpenSSL library statically compiled with ransomware binary.
Linux Variant
During development of this post, a Linux variant of Royal ransomware was identified by @BushidoToken on Feb. 1, 2023. This is the first known version not targeting Windows systems. However, considering many ransomware families have an ESXi/Linux focused variant, this isn’t unusual. It only makes sense that this group would expand their arsenal to impact other environments.
There are minimal differences between the Linux and Windows variants in terms of encryption. AES-256 is used for symmetric encryption, while RSA-4096 is used for asymmetric encryption within the sample.
Additionally, there is a lack of obfuscation within the Linux sample. All strings are stored as plaintext, including the RSA public key and the ransom note.
There are five possible arguments for the Linux variant of Royal ransomware:
Argument
Purpose
-id
32-character ID for running sample
-ep
Encryption percentage – indicates the percentage of each file that will be encrypted
-stopv
Indicates to the sample whether to stop VM-linked processes or not
-fork
Forks the current process for encryption
-logs
Informs the sample to log information to a file
During file enumeration and encryption, the sample avoids files with the following extensions and filenames:
Extensions:
.v00
.b00
.sf
.royal_u
.royal_w
.royal_log_
.readme
The variant is also compiled with the OpenSSL library, resulting in a large number of unreferenced crypto-linked strings.
Figure 10. OpenSSL strings seen within Linux ransomware binary.
Conclusion
Royal ransomware has been more active this year, using a wide variety of tools and more aggressively targeting critical infrastructure organizations. Organizations should implement security best practices and be wary of the ongoing threat of ransomware. This is true not only for Royal ransomware but for other opportunistic criminal groups as well.
The Unit 42 team recommends that defenders have advanced logging capabilities deployed and configured properly. This includes tools such as Sysmon, Windows command-line logging and PowerShell logging.
Ideally, you should be forwarding these logs to a security information and event management tool (SIEM) to create queries and detection opportunities. Keep computer systems patched and up to date wherever possible to reduce the attack surface related to exploitation techniques.
Deploy an XDR/EDR solution to perform in-memory inspection and detect process injection techniques. Perform threat hunting looking for signs of unusual behavior related to security product defense evasion, service accounts for lateral movement and domain administrator-related user behavior.
Protections and Mitigations
Palo Alto Networks customers receive protections from the threats discussed above through the following products.
WildFire: All known samples are identified as malware.
Anti-Ransomware module to detect Royal encryption behaviors on Windows
Local Analysis detection for Royal binaries on Windows
Behavioral Threat Protection (BTP) rule helps prevent ransomware activity on Linux
Next-Generation Firewalls (NGFW): DNS signatures detect the known command and control (C2) domains, which are also categorized as malware in URL Filtering.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200
Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (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.
Configuration data that changes across each instance of deployed malware can be a gold mine of information about what the bad guys are up to. The problem is that configuration data in malware is usually difficult to parse statically from the file, by design. Malware authors know the intelligence value as they provide directives for how the malware should behave.
Malware is like most complex software systems in that there are many advantages for code reuse and abstraction. Therefore, it is not surprising to see that the concept of software configuration is pervasive across the various malware families we analyze. After all, it’s pretty hard to imagine a stereotypical cybercriminal wanting to bother with recompiling their code to change an IP address or whatever else, when going after different targets.
But the good news is that statically armored configuration data can often easily be found and parsed directly from memory. We will cover a nice example of an IcedID (information stealer) configuration, how it was obfuscated and how we’ve extracted it.
Palo Alto Networks customers receive improved detection for the evasions discussed in this blog through Advanced WildFire. As we continue to parse and extract this information from malware families at scale, we hope to build out a pool of threat intelligence that will better help us understand the campaigns and tactics of the various threat actors who are targeting various organizations.
So what exactly do we mean by the term “configuration” when talking about malware? Outside the context of malware, we think of configuration in terms of defining how systems should behave. For example, we would consider the rules used to define which networking routes for a firewall are allowed, or which font size your web browser uses while you read this, as configurable information.
For malware, this is no different. Malware configurations are just collections of elements that define how a malware operates, such as the following:
Command-and-control (C2) network addresses
Passwords for remote administrators
File paths in which to drop persistent payloads
The way these elements are embedded in malware components tends to be specific to each malware family. Also, they might evolve over time as malware undergoes development, or when malware authors change their build process.
Generally speaking, malware configuration elements tend to be the properties of malware that the authors want to make easily editable between campaigns and deployments without requiring manual code edits for each one. Malware configuration elements can also expose latent behaviors and malware infrastructure that are not typically observable under routine dynamic analysis.
Malware configurations have intelligence value for security practitioners because they provide insights into campaigns over time. In some cases, defenders could use them as actionable artifacts for network detection, or for identifying infected hosts. The successful extraction and validation of a malware configuration can also be used to reinforce our confidence when identifying a file as malicious.
Because malware configurations have value to security systems and defenders alike, it is state-of-practice for modern malware authors to protect their configuration elements using different techniques. These protections often include a blend of encryption, obfuscation and compression. They might also be layered with evasive techniques.
This protection poses a significant challenge for malware configuration extractors that operate solely by using static analysis, because all of these protections must be detected and bypassed before extraction can be performed. Using an advanced dynamic analysis sandbox combined with intelligent runtime memory analysis makes it possible to bypass many of these protections and pinpoint the best opportunities to perform extraction.
When we represent and store these configurations using standardized schemas, it enables us to extract maximum value through automation, machine learning and interactive analysis. The DC3-MWCP library defines a schema for many of the most common configuration element types, and it provides a simple library for serialization to JSON.
The MITRE MAEC and STIX projects also provide us with a more general vocabulary for representing malware configuration elements. This also allows us to correlate the elements with observable objects collected during dynamic analysis.
IcedID Analysis
Let’s look at one IcedID binary and how its configurations are encrypted.
This particular attack chain, shown in Figure 1, was discovered in early November 2022. It delivered IcedID, an information stealer also known as Bokbot, as the final payload. This threat is well-known malware that has been attacking people since 2019.
The following diagram shows the infection chain.
Figure 1. IcedID infection chain.
Authors of IcedID took pains to hide their configurations. Recent samples of IcedID stage two would only be downloaded if the victim’s machine matched the requirements of the threat actor.
The configurations of IcedID consisted of C2 URLs and their campaign IDs. The C2 URLs included some that might not be revealed during the execution of the IcedID binaries. The campaign ID links IcedID samples back to specific threat actors.
We will go through the following steps to extract the configurations found in the IcedID stage one and two binaries:
Unpack the IcedID binary
Locate the encrypted configuration data blob
Extract the encryption key
Decrypt the configuration data blob with the encryption key
Unpacking IcedID Stage One
IcedID stage one unpacks itself by first allocating memory using the VirtualAlloc function. This is followed by erasing the allocated memory using the Memset function, as shown in Figure 2. Finally, it copies the unpacked data to the allocated memory using the Memmove function.
To dump the unpacked data, we set a breakpoint at Memmove. The second argument of Memmove contains the address of the unpacked data. Figure 2 also shows the DOS MZ header of the unpacked IcedID stage one in the right-hand side of the hex dump.
Figure 2. Unpacking IcedID stage one.
Locating the Encrypted Configuration Data Blob
Next, we located the encrypted configuration data blob using the unpacked stage one IcedID. While debugging the unpacked IcedID stage one file, we set a breakpoint at the address that called WinHttpConnect, as shown in Figure 3. The address pointed to by register RDI contains the string of the C2 URL.
Figure 3. Debugging IcedID stage one.
By backtracing the code, we located a function that used the decrypted configuration as shown in Figure 4.
Figure 4. Tracing code in IcedID stage one.
Tracing the code flow back, we found the loop that decrypted the configuration, as shown in Figure 5.
Figure 5. Configuration decryption loop for IcedID stage one.
The instruction at 0x7FEF33339CD loaded the address of the encrypted configuration data blob (Encrypted_Config) into register RDX.
Extracting the Encryption Key
The instruction at 0x7FEF33339D4 reads the encryption key. The key is 0x40 bytes offset from the address of Encrypted_Config. We also learned the configuration is 0x20 bytes long. An XOR loop was used to decrypt the configuration.
Decrypting the Configuration Data Blob With the Encryption Key
After gathering the encryption key, the encrypted data blob and the decryption routine, we can now decrypt the configuration using the following script shown in Figure 6.
Figure 6. Configuration decryption script for IcedID stage one.
The decrypted IcedID stage 1 configuration has the following format, as shown in Figure 7.
Figure 7. IcedID stage one configuration format.
From the decrypted configuration, we can extract the following IoCs:
C2 URL
bayernbadabum[.]com
Campaign ID
1139942657
Now, we will decrypt the configuration for the IcedID stage two binary.
Unpacking the IcedID Stage Two Binary
As the IcedID stage two binary uses the same packer as stage one, we will not repeat the unpacking steps here.
Locating the Encrypted Configuration Data Blob
We set a breakpoint at the address that calls Winhttpconnect, as shown in Figure 8.
Figure 8. Debugging IcedID stage two.
After tracing the code, we located the function that used the decrypted configuration, as shown in Figure 9.
Figure 9. Tracing code in IcedID stage two.
Extracting the Encryption Key
Tracing the code flow even further back, we found the function that decrypts the configuration. The first few instructions located the encrypted configuration blob. The encrypted blob is 0x25c bytes long. The encryption key is the last 0x10 bytes of the encrypted configuration blob, as shown in Figure 10.
Figure 10. Loading the encryption key for IcedID stage two.
After retrieving the encryption key, the next step is the loop to decrypt the encrypted blob, as shown in Figure 11.
Figure 11. Configuration decryption loop for IcedID stage two.
Decrypting the Configuration Data Blob With the Encryption Key
We replicated the instructions in the decryption loop using Python. After gathering the encryption key, encrypted data blob and the decryption routine, we can now decrypt the configuration using the following script (shown in Figure 12).
Figure 12. Configuration decryption script for IcedID stage two. Note: Jquinn147 and myrtus0x0 published a similar configuration decryption script for IcedID in May 2021, called IcedDecrypt (GitHub).
The decrypted IcedID stage two configuration has the following format, shown in Figure 13.
Figure 13. Configuration format for IcedID stage two.
From the decrypted configuration, we can extract the following indicators of compromise (IoCs):
C2 URLs
newscommercde[.]com
spkdeutshnewsupp[.]com
germanysupportspk[.]com
nrwmarkettoys[.]com
C2 URI
news
Campaign ID
1139942657
We have manually decrypted the configuration for both the IcedID stage one and two binaries.
Scaling Up
Now that we’ve discussed the work of figuring out how to target the configuration data in memory, the next challenge is to figure out how to perform this at scale. The massive scale of most malware processing systems means that most practitioners looking to build out a configuration extraction system will need to be careful about adding additional overhead. This means that we will need a mechanism to intelligently identify only the samples of interest for each parser, so we’re not unnecessarily running dozens of parsers across millions of samples.
We think a reasonable approach to this problem involves using intelligent runtime memory analysis, as it provides us with excellent visibility into the secrets malware authors want to protect. A typical workflow for our malware configuration extractors includes the following activities:
Scanning memory and/or other dynamic analysis artifacts
Applying a noise filter on the results to identify the best candidates for extraction
Performing extraction using the best fitting module and storing the results for reporting and indexing
Generalizing this common workflow presented us with the opportunity to make the following improvements:
Optimizing the search phase by only scanning analysis data once in most cases
Applying abstractions and reusable code for many common tasks
Limiting the impact of modules with problematic inputs or other bugs
Giving our security researchers visibility into the performance of their modules
The following example shows some of the IoCs from a recent IcedID extractor after being deployed at scale. Having a nice framework for deploying configuration extractors means that once you are finished crafting a configuration extraction script, it’s time to kick your feet up and relax while hundreds of configurations flow into your malware configuration database.
Figure 14. IoCs from IcedID samples.
Conclusion
Thank you for joining us in this overview of malware configurations and why we are working hard to parse this information at scale in Advanced WildFire. Reverse engineering variants of each malware family allow us to build out parsers to extract meaningful and relevant data for all of them at scale.
There is a staggering amount of diversity among payloads in the malware landscape, which makes the task of supporting them all more or less impossible. Where possible, we use metrics-based approaches to prioritize focus on the malware families and variants most relevant to our customers. In this ongoing area of research, our team will continue to expand support for new malware families and variants.
Palo Alto Networks customers receive protections from threats such as those discussed in this post with Advanced WildFire.
Recent observations of exploits used in the wild November 2022-January 2023 reveal that attackers have been using newly published remote code execution vulnerabilities in the following three products:
Roxy-WI, a web interface for managing and monitoring RoxyDNS
CWP, a free web hosting control panel (aka Control Web Panel or CentOS Web Panel)
Cacti, an open-source network monitoring and graphing tool used to track the performance of various network devices, servers and applications
Additionally, attackers have also been taking advantage of a traversal and information disclosure vulnerability in ThoughtWorks GoCD to read sensitive files stored on servers.
In our observations of network security trends, Unit 42 researchers have pinpointed several attacks based on proof-of-concept (PoC) availability and impact. We have detailed below which of these we believe should be on the defender’s radar.
Other insights that could assist defenders include the following:
Rankings of the most commonly used attack techniques and the types of vulnerabilities that attackers have recently favored. For example, among 6,169 newly published vulnerabilities, a large portion (almost 11%) involves cross-site scripting.
Lists of major vulnerabilities identified by evaluating more than 276 million attack sessions including code execution, traversal and information disclosure.
Insight into how these vulnerabilities are exploited in the wild based on real-world data collected from our Next-Generation Firewalls.
Summaries of key trends from November 2022-January 2023.
Analysis of the most recently published vulnerabilities, including the severity and attack origin distribution.
Classification of these vulnerabilities to provide a clear view of the prevalence of the different types, such as cross-site scripting or denial-of-service.
Lists of the most commonly exploited vulnerabilities attackers are using, as well as the severity, category and origin of each attack.
Palo Alto Networks customers receive protections from the vulnerabilities discussed here through the Next-Generation Firewall, Cloud-Delivered Security Services and Prisma Cloud WAAS, including Threat Prevention, WildFire, Advanced URL Filtering and Cortex XDR.
Analysis of Published Vulnerabilities, November 2022-January 2023
From November 2022-January 2023, a total of 6,169 new Common Vulnerabilities and Exposures (CVE) numbers were registered. To better understand the potential impact these newly published vulnerabilities could have on network security, we provide our observations based on the severity, availability of working proof-of-concept (PoC) code, and vulnerability categories.
How Severe Are the Latest Vulnerabilities?
To estimate the potential impact of vulnerabilities, we consider their severity and examine any reliable PoCs available that attackers could easily launch. Some of the public sources we use to find PoCs are Exploit-DB, GitHub and Metasploit. Distribution of the CVEs that have an assigned severity score of Medium or higher can be seen in the following table:
Severity
Count
Ratio
Ratio Change From Last Quarter %
PoC Availability
Change in PoC Availability
Critical
1,100
17.8%
-1.1%
3%
+0.1%
High
2,339
37.9%
-4.2%
3.1%
+0.9%
Medium
2,730
44.3%
+5.3%
2.2%
-0.1%
Table 1. Severity distribution for CVEs registered November 2022-January 2023,including only those rated Medium-Critical.
Figure 1. Severity distribution for CVEs registered November 2022-January 2023, including only those rated Medium-Critical.
Our classification of vulnerabilities is based on CVSS v3 scores. Many conditions must be met to rate a vulnerability as Critical, so there are very few at this level. One of the common factors for rating a vulnerability at this level is having a working PoC available. To be considered Critical, vulnerabilities generally have low attack complexity, and it is often easy to create a PoC to exploit them.
Vulnerability Category Distribution
It is crucial to understand each type of vulnerability and its consequences. Out of the newly published CVEs that were analyzed, 22.6% are classified as local vulnerabilities, requiring prior access to compromised systems, while the remaining 77.4% are remote vulnerabilities, which can be exploited over a network. This means that most newly published vulnerabilities introduce potential opportunities for threat actors to attack vulnerable organizations from anywhere in the world.
In Figure 2, the most common vulnerability types are ranked by how prevalent they were among the most recent set of published vulnerabilities.
Figure 2. Vulnerability category distribution for CVEs registered November 2022-January 2023.
Cross-site scripting remains the most reported vulnerability from November 2022-January 2023. We also saw that the prevalence of cross-site scripting vulnerabilities increased during this time, and the majority of the vulnerabilities in this category are ranked Medium. Code execution and information disclosure vulnerabilities decreased. Most of the recently published cross-site scripting and information disclosure vulnerabilities are at Medium severity (rather than Critical).
Figure 3. Vulnerability category distribution compared with the previous quarter.
This quarter, we have observed an increase in cross-site scripting vulnerabilities compared to last quarter. Cross-site scripting is a classic attack vector that is still very popular today. We have also observed a slight increase in denial-of-service vulnerabilities, while code execution vulnerabilities have decreased slightly.
Network Security Trends: Analysis of Exploits in the Wild, November 2022-January 2023
Data Collection
By leveraging Palo Alto Networks Next-Generation Firewalls as sensors on the perimeter, Unit 42 researchers observed malicious activities from November 2022-January 2023. The malicious traffic we identified is further processed and based on metrics such as IP addresses, port numbers and timestamps. This ensures the uniqueness of each attack session and thus eliminates potential data skews. We analyzed 276 million valid malicious sessions and then correlated the refined data with other attributes to infer attack trends over time to get a picture of the threat landscape.
How Severe Were the Attacks Exploited in the Wild?
To arrive at 276 million valid malicious sessions, we excluded the original set of low-severity signature triggers used to detect scanning and brute-force attacks, as well as internal triggers used for research purposes. Therefore, we consider exploitable vulnerabilities with a Medium and higher severity ranking (based on the CVSS v3 Score) as a verified attack.
Figure 4. Attack severity distribution, November 2022-January 2023, including only Medium through Critical vulnerabilities.
Figure 4 shows the session count and ratio of attacks grouped by the severity of each vulnerability. Compared with the previous quarters' severity distribution, this quarter shows a decrease in Critical attacks, because attacks against CVE-2021-35394 decreased.
We focus more on Critical-severity attacks because of their greater potential impact. Although there has been a decline, the vulnerabilities rated as Critical are still exploited the most, because attackers typically leverage more severe vulnerabilities for exploits. Defenders should prioritize preventing and mitigating High-severity and Critical-severity network attacks.
Figure 5. Vulnerability severity distribution compared with the previous quarter.
When Did the Network Attacks Occur?
Figure 6. Severity of exploits in the wild measured weekly from November 2022-January 2023.
During November 2022-January 2023, attackers increased their exploitation of Critical-severity vulnerabilities starting in January, and the number of attacks against High-severity and Medium-severity vulnerabilities gradually increased. Note, the last set of data records eight days of attack volume instead of seven days.
As we’ve seen in the past, attackers frequently use recently disclosed vulnerabilities, especially those from 2021-2022. This shows the importance of updating security products and applying software patches as soon as they become available to protect against the most recently discovered vulnerabilities.
Figure 7. Observed attacks broken down by the year in which the exploited CVE was disclosed, measured weekly from November 2022-January 2023.
Exploits in the Wild, November 2022-January 2023: A Detailed View
Among the latest published attacks, the following exploits stood out due to their PoC availability, severity and ease of exploitation. We have provided snippets showing how attackers used open-source tools to compromise the different targets, allowing defenders to better understand how the exploit operates.
This is a vulnerability that allows attackers to inject malicious commands and sniff sensitive information. This is accomplished by poisoning the IMAP route cache entries in the memcached server. This server is used to query Zimbra users and push their HTTP requests to the appropriate backend service.
Roxy-WI is a web interface used to manage HAProxy, NGINX and Keepalived servers. This vulnerability allows attackers to construct malicious requests, execute arbitrary commands without logging in and control the server.
Control Web Panel (CWP) is a popular web hosting platform. This vulnerability exists in the /login/index.php component, allowing an unauthenticated attacker to execute arbitrary system commands through crafted HTTP requests.
Cacti is an open-source platform for operational monitoring and a fault management framework. Due to a verification flaw in the remote_agent.php file, an unauthenticated attacker can bypass authentication by setting the variable at the beginning of HTTP_ to the host name of the Cacti server, to achieve command execution.
ThoughtWorks GoCD is an open source build and release tool. An unauthenticated attacker could exploit this vulnerability to obtain all secrets known to the GoCD server.
Pentaho is business intelligence software that provides data-related services. An attacker could exploit a vulnerability where the default configuration allows them to extract pieces of information without valid credentials.
vCenter is virtual server management software by VMware. An unauthenticated remote attacker could exploit this vulnerability by uploading a crafted forged file to an affected vCenter Server deployment to transform commands and software. The whole attack process is very simple and does not require any user interaction.
This is a vulnerability in Apache OpenOffice, an open-source office software suite. The vulnerability opens dBase/DBF documents and displays the contents as a spreadsheet. When the DBF (a database file where data is organized by fields) data is read, the size of some fields is not checked. The data is copied into local variables. This vulnerability could be exploited by a malicious file opened by the software, executing malware on the machine.
This is a remote code execution vulnerability in Windows Network File System due to improper handling of NFSv4 requests. An unauthenticated attacker could exploit this bug to execute arbitrary code in the context of SYSTEM1.
This vulnerability exists in Connected Components Workbench, ISaGRAF Workbench, and Safety Instrumented System Workstation because there is no restriction on the objects that can be deserialized.
Figure 18. CVE-2022-1118.
Attack Category Distribution
We classified each network attack by category and organized them in terms of prevalence. In the period discussed, remote code execution ranks highest. Traversal and information disclosure vulnerabilities were the second and third most popular attacks of the quarter. Both of these types of vulnerabilities can be exploited by attackers to obtain sensitive information. Attackers typically aim to gain maximum information from and control over the systems they target.
Figure 19. Attack category and severity, November 2022-January 2023.
Compared with the previous quarter, most categories of attacks have increased. The number of remote code execution attacks has decreased, possibly due to a decrease in attacks against CVE-2021-35394. However, we have observed an increase in traversal, information disclosure and SQL injection vulnerabilities. These four types of vulnerabilities are frequently exploited by attackers.
We have also observed an increase in the use of hack tools, especially FFuF (often used for identifying security vulnerabilities in web applications by fuzzing them with a large number of test cases) and Nmap (often used for network exploration and discovery by scanning hosts and services on a network and creating a map of the network topology).
Where Did the Attacks Originate?
After identifying the region from which each network attack originated, we discovered that the majority of them seem to originate from the United States, followed by France and then Germany. Attacks from Vietnam decreased significantly this quarter. That may be because almost all attacks from Vietnam last quarter were against CVE-2021-35394, and the attacker stopped or changed attack source location this quarter.
We recognize that attackers might leverage proxy servers and VPNs located in those countries to hide their actual physical locations.
Figure 20. Locations ranked in terms of how frequently they were the origin of observed attacks from November 2022-January 2023.Figure 21. Attack origination comparison between August 2022-October 2022 and November 2022-January 2023.
It is worth noting that Luxembourg and Switzerland, where there were not many attacks last quarter, saw a lot of attacks in this quarter. Let’s look more closely at the attacks from these two places.
There were about 31,000 attacks originating from Luxembourg in November 2022, which is a relatively high level. From December 2022-January 2023, the number of attacks from Luxembourg rose from about 2.2 million to 5.8 million, showing a rapid growth rate.
Unlike Luxembourg, attacks originating from Switzerland were at about 2.1 million and 1.2 million in November and December 2022, respectively, and then they dropped sharply to about 730,000 in January 2023.
We also observed that in this quarter, among all the attacks from Luxembourg, the number of attacks targeting CVE-2021-35394 reached 7.77 million. This accounted for 96% of the total number of attacks from Luxembourg.
About 1.9 million attacks from Switzerland were aimed at the Code Execution of Netis/Netcore Router vulnerability. This accounted for 45% of their total attacks.
From this evidence, we can conclude that the current attacks on hardware devices, especially network devices, are very active.
Figure 22. Attack geolocation distribution from November 2022-January 2023.
Conclusion
The vulnerabilities disclosed from November 2022-January 2023 indicate that web applications remain popular targets for attackers, and that Critical vulnerabilities are more likely to have PoCs publicly available.
In the meantime, we continue to capture newly published vulnerabilities that are exploited in the wild. This emphasizes the need for organizations to promptly patch their systems and implement security best practices. Attackers continue to make a concerted effort to expand their tool kit of exploits whenever possible.
While cybercriminals will never cease their malicious activities, Palo Alto Networks customers receive protections from the attacks discussed in this blog through the Next-Generation Firewall and Cloud-Delivered Security Services, including Threat Prevention, WildFire and Advanced URL Filtering, as well as through Cortex XDR. Prisma Cloud customers using WAAS are protected from such threats through the App Firewall feature, which detects attacks such as cross-site scripting, SQL injection, directory traversals and more.
To further mitigate any risks to your network:
Run a Best Practice Assessment to identify where your configuration could be altered to improve your security posture.
Run a Security Lifecycle Review to get a consolidated view of your largest threats and if you have coverage to prevent them.
Continuously update your Next-Generation Firewalls with the latest Palo Alto Networks Threat Prevention content (e.g., versions 8686 and above).
From July-December 2022, Unit 42 researchers have observed and analyzed over 67 million unique malicious URLs, domains and IPs, which we use to block associated malicious network traffic. We will cover the trends we have observed during the second half of 2022 based on our detections of malicious URLs, domains and IPs.
We present our analysis and findings of these internet threat trends, including the following information:
A view of the internet threat landscape
This includes malicious URL distribution, geolocation, category analysis and statistics describing attempted malware attacks that we observe
A spotlight on internet threats of particular interest
This includes industry sectors being targeted for spoofing in phishing pages, as well as downloaded malware statistics, injected JavaScript (JS) malware analysis and malicious DNS analysis
A case study of a classic web skimmer that infected a Tranco top 1 million-rated website
Palo Alto Networks customers receive protections from the web and DNS threats discussed here via the Advanced URL Filtering, DNS Security and Advanced Threat Prevention Cloud-Delivered Security Services.
During the second half of 2022 (H2), we amassed over 67 million malicious domains and URLs, an increase of over 52% over the first half of 2022 (H1). These malicious domains and URLs have a broad impact on their victims. We observed over 12 million HTTP requests to some of these malicious URLs and over 60 million DNS requests to these domains every day. These malicious URLs are collected from third-party feeds as well as our own internal analyzers. These analyzers include a variety of types including web crawlers, malware traffic analyzers and deep learning models.
Looking more closely at malicious JavaScript samples as an example, during the second half of 2022, we detected over 4 million malicious JS samples hosted on 4.8 million malicious URLs and 1.6 million hostnames. Compared to the first half of the year, the total number of URLs containing malicious JavaScripts increased by 99.3%.
Figure 1. The number of malicious JS and their hosting URLs and hostnames.
Malicious URL and Domain Distribution
Figure 2 shows the number of newly observed malicious URLs each quarter. Compared to H1 2022, the number of malicious URLs in H2 increased by 52%. For the grayware and command-and-control (C2) categories, even though the number of observed URLs dropped in Q4, the total increase in H2 is still 80% and 165%, respectively, when compared to H1.
Figure 2. Number of newly observed malicious URLs from Q1 to Q4 2022.
Figure 3 shows the number of new malicious domains in each month from July-December 2022. Note that for the monthly numbers for the grayware and C2 categories, the number of detections are distributed less evenly than the other categories, mainly because they are more related to specific attack campaigns.
For example, one of the main sources of URLs in the grayware category is from detected clusters of malicious domains belonging to the same campaign at their registration time. More details of this detection logic are presented in Detecting and Preventing Malicious Domains Proactively with DNS Security.
Figure 3. The number of malicious domains observed from July-December 2022.
Geolocation Analysis of Malicious URLs
By looking at passive DNS data and an IP to location database, we can retrieve the IPs where the domains hosting the malicious URLs are located. Figures 4 and 5 below show the geolocation distribution of the domains hosting malicious URLs worldwide.
Figure 4. Geolocation distribution of domains (in millions) hosting malicious URLs during July-December 2022.
Although malicious websites are hosted in more than 150 countries and regions, over 85% are hosted in the top eight countries, as shown in Figure 5.
Similar to what we observed in Q1 2022 and Q2 2022, the majority of all malicious URLs and domains continue to be hosted in the United States. During the second half of 2022, the next most common hosting locations were Brazil and China.
Figure 5. Top eight countries hosting malicious URLs during July-December 2022.
Category Analysis
We also analyzed the distribution of the original content categories of the malicious URLs and domains we amassed. In other words, we determined what they were intended for before they were used for malicious purposes or were otherwise detected as malicious. This analysis aims to find the common targets for these cyberattacks and how they might be trying to fool people.
Figure 6 shows the distribution of the original categories for the malicious URLs in Advanced URL Filtering. Unsurprisingly, URLs with the original categories Insufficient Content and Newly Registered Domains make up over 30% of all malicious URLs. We classify a URL as Insufficient Content when it does not host enough content for classification. In both cases, this result makes sense as, after an attacker registers a domain, it will likely fall into these two categories before the URL starts serving content for malicious purposes.
Figure 6. Categories of the URLs before they are identified as malicious during July-December 2022.
Impact of Malicious URLs and Domains
Not all the malicious domains and URLs we detected and collected were actively resolved or visited by victims, as threat actors can make them short-lived by design, or they can be blocked by other security products. Figures 7 and 8 below present the number of URLs and domains visited or resolved during the last three months of 2022.
Unique domains/URLs indicate the number of malicious domains and URLs visited at least once. Sessions indicate the number of DNS and HTTP sessions to these blocked malicious domains and URLs.
These statistics represent the impact of all the malicious URLs and domains. We calculated these numbers based on lookups from the Palo Alto Networks firewall to the Advanced URL Filtering and DNS cloud. Due to the cache on the firewall, the absolute number could be higher. All these domains and URLs were blocked when visited by Palo Alto Networks customers.
Figure 7 below shows the number of malicious URLs visited and how many times these malicious URLs were visited in total. From October-December 2022, the number of malicious URLs visited at least once increased 8.7% monthly. In total, the number of times victims visited these URLs increased 11.5% each month.
Figure 7. Malicious HTTP/HTTPs URL sessions during October-December 2022.
Figure 8 shows the number of malicious domains resolved and how many times these malicious domains were resolved. From October to December 2022, we saw the number of malicious domains that were resolved at least once increased 4.5% monthly. In total, the number of times potential victims resolved these domains increased 4.4% each month.
On average, users visited each malicious URL ten times, while each domain was resolved 28 times. We would expect a domain to be resolved more frequently than a URL visited by potential victims. This could be because an attacker launched a campaign with different URL parameters for different targets, even though the domains are the same.
Figure 8. Malicious DNS sessions October-December 2022.
Internet Threats Highlights
Phishing Attacks
In Figure 9 below, we present the changes in industry sectors impersonated in phishing attacks between Q2, Q3 and Q4. In general, the following types of sites were the most popular sectors to target for spoofing, across all three quarters:
Online document and storage
Internet portals and web mail
Financial services sites
Compared to Q2, during Q3 and Q4 we observed an increase of phishing attacks disguising themselves as online document and storage platforms, from 27.8% to over 38.1%. During the same time period, fake online shopping and marketplace sites became more popular as sources of phishing campaigns.
Figure 9. Changes in the distribution of phishing target sectors in Q2, as well as Q3 and Q4 2022.
During the second half of 2022, we detected 2.7 million URLs that distributed 1.9 million malicious files. Among those malware-downloading URLs, we found malicious campaigns that distributed a large number of malicious PDF files. Among all the detected file types, PDF was by far the most common (96.0%), followed by Windows PE – including both EXE and DLL files – (1.8%) and archive files (1.6%).
Figure 10 reports the top five most common VirusTotal family names for downloaded malicious PDF files. These families, with names such as PDF.Spam.Heur.1 and Trojan.PDF.Phishing, are heuristic or generic detection names associated with the distribution of malicious content through deceptive strategies.
Figure 10. Distribution of the top families that download malicious PDFs.
For instance, one of these PDF files uses a deceptive CAPTCHA button to convince the user to click it. Upon clicking, the user could be redirected through random websites before reaching the final destination page that hosts malicious content (such as fake browser extensions and fake antivirus).
As shown in Figure 11, JS downloader threats showed the most activity, followed by web skimmers and web miners (aka cryptominers).
Figure 11: Top five web threats category distribution during July-December 2022.
Malware Family Analysis
Based on our classification of injected JS malware explained in the previous section, we further organized our set by malware family.
The malware family classification is important to understand how the malware works. Injected JS malware in the same family share similar code even if the HTML landing pages where they appear have different layouts and styles.
As we did in our analysis blog mentioned above, we identified pieces of malware as part of a family by checking for certain characteristics: similar code patterns or behaviors, or having originated from the same attacker.
Figure 12 shows the number of similar snippets observed for the top 10 injected JS malware families we identified. As we’ve seen previously, there were fewer families of redirectors, web scams and downloaders, while web skimmers show more diversity in code and behavior.
Figure 12. Web threat malware family distribution July-December 2022.
Malicious DNS Analysis
While attackers still prefer registering their own domains for malicious activities, we observe that a nontrivial number of malicious domains (4.8%) are the subdomains of well-known web hosting services. These malicious subdomains inherit the reputation of the web hosting services and thus make it more difficult for both victims and security analysts to determine their true intentions. Among all the web hosting services that attackers abused, two popular web hosting services account for around 70% of all the malicious web hosting subdomains.
Internet Threats Case Study
We discovered a web skimmer that infected an active motor retail website, ranking in the Tranco 1 million, which is a research-oriented top sites ranking list. On this motor retail website, we can see the malicious JS code (motor.js) injected in almost every page that contains sensitive information (e.g., login page, shopping cart page). The objective is to steal the customer’s information. This information includes username, login password and payment information, as shown in Figures 13 and 14.
Figure 13. Screenshot of the infected login page.Figure 14. Screenshot of the infected shopping cart page.
We can see all those pages contain the same JS file named motor.js located in a malicious domain that delivered malware before, as shown in Figure 15.
Figure 15. VirusTotal screenshot of personallydeliver[.]com.The original web skimmer in motor.js is not straightforward, as shown in Figure 16.
Figure 16. A screenshot of the source code of personallydeliver.com/motor[.]js.After deobfuscating the JS code in motor.js and taking a closer look at this skimmer, we can see the code uses
var1 == var2 ? statement1: statement2
This structure is meant as a trick to slow analysis by researchers, combined with obfuscation in the code itself. Let’s look at this code logic in more detail.
As shown in Figure 17, we can see there are two main functions. One is function HraHMoYftE() and the other one is function XGSsWznnKh(). For function HraHMoYftE(), it tries to get the victim’s input from the website page through fields including input, select and textarea.
After they collect this kind of sensitive information, the function HraHMoYftE() will pass the sensitive information to the function XGSsWznnKh(). This latter function mainly stores the sensitive information in an array and sends information transformed into a string to the malicious server hosted by attackers, with the img.src method shown in Figure 17.
Figure 17. Two main functions of the deobfuscated code of personallydeliver.com/motor[.]js.
Conclusion
We have tracked and presented the internet security trends for H2 of 2022, including malicious URL category analysis and geolocation analysis.
In particular, we found that in the second half of 2022, attackers more commonly impersonated the following types of businesses and services:
Cloud-based documents
Cloud storage services
Online shopping websites
For malicious websites, malicious PDFs are still the predominant type of downloaded malicious files. JS downloaders and web skimmers are the most popular injected malicious JS.
We also observed that a nontrivial number of malicious domains are subdomains of well-known web hosting services. In addition, we shared the case study of a web skimmer that infected a retail website in Tranco’s top 1 million.
To protect your systems against the threats discussed in this post, we recommend the following actions:
Unit 42 researchers recently identified a new variant of PingPull malware used by Alloy Taurus actors designed to target Linux systems. While following the infrastructure leveraged by the actor for this PingPull variant, we also identified their use of another backdoor we track as Sword2033.
The first samples of PingPull malware date back to September 2021. Monitoring its use across several campaigns, in June 2022 Unit 42 published research outlining the functionality of PingPull and attributed the use of the tool to Alloy Taurus.
Operating since at least 2012, Alloy Taurus (aka GALLIUM, Softcell) is assessed to be a Chinese advanced persistent threat (APT) group that routinely conducts cyberespionage campaigns. This group has historically targeted telecommunications companies operating across Asia, Europe and Africa. In recent years we have also observed the group expand their targeting to include financial institutions and government entities.
We provide a detailed breakdown of the following:
A new variant of PingPull
Sword2033 samples linked to the same command and control (C2) infrastructure
Recent activity by Alloy Taurus in South Africa and Nepal
At the time of writing, three out of 62 vendors found the sample to be malicious. Despite a largely benign verdict, additional analysis has determined that this sample is a Linux variant of PingPull malware. This determination was made based on matching HTTP communication structure, POST parameters, AES key, and C2 commands, which are outlined below.
Upon execution, this sample is configured to communicate with the domain yrhsywu2009.zapto[.]org over port 8443 for C2. It uses a statically linked OpenSSL (OpenSSL 0.9.8e) library to interact with the domain over HTTPS via the following HTTP POST request:
Figure 1. PingPull Linux variant POST request.
The payload then expects the C2 server to respond with data that is Base64 encoded ciphertext, encrypted with AES using P29456789A1234sS as the key. This is the same key that we previously observed in the original Windows PE variant of PingPull.
Once decoded, the cleartext resembles HTTP parameters and the payload will parse the cleartext for & and = with the following parameters:
Figure 2. PingPull HTTP parameters.
The value in the P29456789A1234sS parameter will contain a single upper case character between A and K, as well as M, which the payload will use as the command value. The values in the z0, z1 and z2 parameters are used for the arguments passed to the command.
After running the command, the payload will send the results back to the C2 server via an HTTPS request that resembles the beacon request, but contains Base64 encoded ciphertext. The command handler supports the following functionality that aligns with both China Chopper capabilities and those observed in the PingPull Windows PE variant:
Cmd
Description
A
Get the current directory
B
List folder
C
Read text file
D
Write text file
E
Delete file or folder
F
Read binary file, convert to hex
G
Write binary file, convert to hex
H
Copy file or folder
I
Rename file
J
Create Directory
K
Timestomp file with specified timestamp in "%04d-%d-%d %d:%d:%d" format
M
Run command
Table 2. PingPull command handler functionality.
Of note, the HTTP parameters z0, z1 and z2 and command handlers A-K, M also align to commands A-K, M observed in the web shell China Chopper. This suggests that Alloy Taurus is using code they might be familiar with, and they are integrating it into the development of custom tooling.
Sword2033 Backdoor
Pivoting on the C2 domain, we identified one additional sample that also communicated with yrhsywu2009.zapto[.]org:
Similar to the PingPull variant above, this sample was designed to connect to port 8443 over HTTPS. However, analysis of the sample revealed that it’s a simple backdoor that we track as Sword2033. This backdoor supports three basic functions:
Cmd
Description
#up
Uploads a file to the system
#dn
Downloads a file from the system
exc /c:
Executes a command, but appends ;echo <random number>\n before running it
Table 4. Sword2033 command handler functionality.
These three commands map to commands in a second command handler that uses A, C, D and M commands, which are identical in value and functionality with the PingPull commands identified in Table 2 above.
Searching for other recent samples of Sword2033, we identified a second sample:
This sample was seen in July 2022. Analysis of this sample revealed that it’s configured to connect to 196.216.136[.]139, located in South Africa, for C2.
Infrastructure Analysis
Analysis of the C2 domain yrhsywu2009.zapto[.]org found in the PingPull Linux variant and the first Sword2033 sample shows it was most recently hosted on 5.181.25[.]99 until early February 2023. However, a historical review of its hosting revealed that this domain resolved to 45.251.241[.]82 for a single day in April 2022. This IP was outlined as an active indicator of compromise (IoC) in our June 2022 report, thereby drawing a clear link to Alloy Taurus activities.
Analysis of the C2 for the second Sword2033 sample (Hopke, referenced in Table 5) found that the domain *.saspecialforces.co[.]za resolved to 196.216.136[.]139. This domain has been hosted on eight other IPs throughout its history with various mail-related subdomains.
None of these IPs appear to have any affiliation with the South African government, but the domain name gives the impression of a connection to the South African military. The establishment of a C2 server that appears to impersonate the South African military is uniquely notable when analyzed in the context of recent events. In February 2023, South Africa joined Russia and China to participate in combined naval exercises.
Additionally, 196.216.136[.]139 resolved to vpn729380678.softether[.]net from late December 2022 through mid-February 2023. Alloy Taurus is known for leveraging the SoftEther VPN service in their operations to facilitate access and maintain persistence to their targeted network.
Threat actors often abuse, take advantage of or subvert legitimate products like SoftEther VPN for malicious purposes. This does not necessarily imply a flaw or malicious quality to the legitimate product being abused.
Reviewing traffic to the Sword2033 C2 server 196.216.136[.]139, we identified sustained connections originating from an IP that hosts several subdomains for an organization that finances long-term urban infrastructure development projects in Nepal.
Conclusion
Alloy Taurus remains an active threat to telecommunications, finance and government organizations across Southeast Asia, Europe and Africa. The identification of a Linux variant of PingPull malware, as well as recent use of the Sword2033 backdoor, suggests that the group continues to evolve their operations in support of their espionage activities. We encourage all organizations to leverage our findings to inform the deployment of protective measures to defend against this threat group.
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.
Protections and Mitigations
In order to defend against the threats described in this blog, Palo Alto Networks recommends organizations employ the following capabilities:
Network Security: Delivered through a Next-Generation Firewall (NGFW) configured with machine learning enabled, and best-in-class, cloud-delivered security services. This includes, for example, threat prevention, URL filtering, DNS security and a malware prevention engine capable of identifying and blocking malicious samples and infrastructure.
Endpoint Security: Delivered through an XDR solution that is capable of identifying malicious code through the use of advanced machine learning and behavioral analytics. This solution should be configured to act on and block threats in real time as they are identified.
Security Automation: Delivered through an XSOAR or XSIAM solution capable of providing SOC analysts with a comprehensive understanding of the threat derived by stitching together data obtained from endpoints, network, cloud and identity systems.
Specific Product Protections and Mitigations
For Palo Alto Networks customers, our products and services provide the following coverage associated with this group:
WildFire cloud-based threat analysis service accurately identifies the malware described in this blog as malicious.
Cortex XDR prevents the execution of known malware samples as malicious. Behavioral threat protection covers this activity starting from content version 930.
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)
![Image 5 is a screenshot of the HTTPS traffic to firebasestorage.googleapis[.]com after the initial suspicious URL. Highlighted in green in the screenshot is the command to insert into Wireshark. Two arrows indicate the request and the suspicious URLs.](https://unit42.paloaltonetworks.com/wp-content/uploads/2023/05/word-image-128267-5.jpeg)
![Image 6 is the TCP stream window showing the 275 kB of data sent from firebasestorage.googleapis[.]com to the Windows host. This is highlighted by an arrow in a menu that shows the entire conversation.](https://unit42.paloaltonetworks.com/wp-content/uploads/2023/05/word-image-128267-6.jpeg)
Get updates from Unit 42 