This article summarizes the malware families (and groups pushing malware) seen by Unit 42 and shared with the broader threat hunting community through our social channels. Some malware – such as IcedID and DarkGate – came up repeatedly. We also included a number of posts about the cybercrime group TA577 – who have distributed multiple malware families but here favor Pikabot. In other cases, we posted about newer malware such as JinxLoader.
By sharing timely threat intelligence via social media channels, we report on malware infections and other threat intelligence of note in an expedited manner. These posts summarize the infection chain, offer helpful screenshots of active traffic and point towards indicators of compromise (IoCs). In 2023, our 93 timely threat intelligence posts in total generated 1.6 million-plus impressions, showing the value of getting IoCs out to the community quickly.
This article reviews all our timely threat intelligence released from October through December 2023. Summarizing these threat intelligence posts provides an opportunity to spot trends that are less visible in single posts. We’ve included a table in the Indicators of Compromise section that lists all the posts in full by date posted, name, links to social media channels and IoCs on GitHub.
Many of these posts contain screenshots of infection traffic filtered in Wireshark, links to the network IoCs and comments linking to packet captures (pcaps) of the associated activity, so this article also provides readers an opportunity to practice and improve their Wireshark skills.
In addition to the in-depth articles published on this site, Unit 42 also shares timely threat intelligence – IoCs, TTPs and other observations about active campaigns – through our social channels.
Besides recapping all social media posts published from October to December, we’ve included a table at the end of this review that includes links to the original posts as well as to all of the IoCs on our GitHub. These original posts include the images from the threat intelligence shared, which range from screen captures of malware and artifacts to the associated traffic filtered in Wireshark. Here we’ll only include the infection chain (as applicable), but head over to X (formerly Twitter) or LinkedIn to review the rest.
A note: The infection date is not always the same as the date when shared on social channels. The table in the IoCs section includes the posting date. The infection date itself is included in all of the infection chain images. Don’t get confused if you’re comparing the infection date to the posting date and they don’t match up!
Timely Threat Intelligence: October
DarkGate
We reported on two instances of DarkGate in October. The first instance was DarkGate malware distributed through Microsoft Teams. The attacker posed as the target organization's CEO and sent victims a Teams invite. The message sent contains a password-protected .zip archive. See the entire infection chain below in Figure 1.
Figure 1. DarkGate infection chain from Microsoft Teams message.
The second instance saw DarkGate malware distributed through fake invoice or billing emails with PDF attachments that spoof DocuSign. Figure 2 illustrates how the process worked. An attentive reader will be able to spot the differences between these two infection chains.
Figure 2. DarkGate infection chain from email.
Pikabot
We also reported on two instances of Pikabot in October. The first was a Pikabot infection leading to Cobalt Strike HTTPS C2 traffic using zzerxc[.]com on 179.60.149[.]244:443. Figure 3 shows the full series of events.
Figure 3. Pikabot infection chain.
The second instance saw the cybercrime threat actor TA577 pushing a Pikabot infection with HTTPS Cobalt Strike traffic on 45.155.249[.]171:443 using ponturded[.]com. We’ll definitely see more TA577 activity in this roundup – the infection chain below in Figure 4 will differ from other TA577 activity.
Figure 4. Pikabot infection chain.
IcedID (Bokbot)
Our only report in October of banking Trojan IcedID saw a forked variant infection with BackConnect, Anubis VNC, CobaltStrike and ConnectWise ScreenConnect. We also saw "hands on the keyboard" approximately 95 minutes after initial infection! Figure 5 lays out how this variant worked.
Figure 5. IcedID forked variant infection chain.
WS_FTP Server Critical Vulnerability
We observed multiple attempts to exploit the WS_FTP Server Critical Vulnerability, where threat actors attempted to deliver a Meterpreter payload via the URL 103[.]163.187.12:8080/cz3eKnhcaD0Fik7Eexo66A. Figure 6 includes not only the infection chain but the command line used.
Figure 6. Infection chain exploiting WS_FTP.
AsyncRAT
A 404 TDS URL chain led to an infection by an AsyncRAT variant. Figure 7 shows the simple infection chain.
Figure 7. AsyncRAT variant infection chain.
Citrix NetScaler
October 2023 saw several indicators of criminals exploiting the Citrix remote-code execution vulnerability CVE-2023-3519. Monitoring this vulnerability in the wild led to a timely snapshot of associated activity. Figure 8 displays the information in a simple column graph. We saw the most detections of this exploit – over 300 – from jscloud[.]biz.
Figure 8. Snapshot of data from Oct. 17, 2023 showing instances of Citrix RCE vulnerability CVE-2023-3519 in the wild.
Timely Threat Intelligence: November
IcedID
Our first timely threat intelligence post in November saw an IcedID (aka Bokbot) infection from an .msi file. Along with the regular HTTPS C2 traffic, we saw IcedID BackConnect activity on 159.89.124[.]188:443. Note the activity highlighted in red in Figure 9.
Figure 9. IcedID infection chain stemming from unknown source.
Cybercrime group TA577 once more distributed an IcedID (aka Bokbot) variant via a disk image downloaded from an emailed link. Figure 10 illustrates this process. As we continue to review TA577 activity, trends will begin to emerge for analysts to be mindful of.
Figure 10. Infection chain where cybercrime group TA577 distributes an IcedID variant.
DarkGate
At least two instances of DarkGate reared their heads in November. In our first sighting, a probable email led the victim to a password-protected .zip file. See it in full with Figure 11.
Figure 11. DarkGate infection chain stemming from probable email.
The second November appearance of DarkGate also came from an unknown source distributing a password-protected .zip. Comparing and contrasting to the DarkGate activity seen elsewhere in this post shows the variations attackers implement.
Figure 12. DarkGate infection chain from unknown source.
Pikabot
A 10-hour infection run led to our list of IoCs from the Pikabot sighting found in November, once more spearheaded by TA577. This infection was from an email and led to a persistent Pikabot DLL. See Figure 13 for the details.
Figure 13. Infection chain of Pikabot distributed by TA577.
JinxLoader
Reportedly named for a League of Legends character, JinxLoader is written in Go. Symantec issued a protection bulletin on JinxLoader just a short while ago. In our post about it (the first public post!) we note that JinxLoader is a relatively new malware service first posted to hackforums[.]net on April 30, 2023. The eight steps of this infection chain are detailed in Figure 14.
Figure 14. Infection chain of JinxLoader distributing Formbook/Xloader.
Timely Threat Intelligence: December
Loader EXE
We started off December by spotting an EXE Loader leading to unidentified malware with C2 using encoded/encrypted TCP traffic on 91.92.120[.]119:62520. See Figure 15.
Figure 15. Infection chain of loader to unidentified malware.
While one security vendor has identified the loader as “PureLoader” and the unidentified malware as a “PureLogs” stealer, we have seen little else shared publicly on this unidentified malware.
DarkGate
We reported on one example of DarkGate malware in December 2023. This example was distributed though a PDF file found on VirusTotal. The PDF file has a link that downloaded a malicious ZIP archive for DarkGate. Figure 16 shows a screenshot of the PDF file.
Figure 16. DarkGate infection from PDF that links to malicious .zip archive.
Astaroth/Guildma
Astaroth and Guildma may sound like characters from a 1970s pulp sci-fi novel with three moons and blue-skinned aliens on the cover, but they’re actually the name of malware we saw in a Portuguese-language email impersonating Brazil’s State Transport Department (Detran) as shown in Figure 17. This Detran-themed malspam tempted the end user with a link for a zip download – which is how the Guildma (aka Astaroth) malware infection would start.
Figure 17. Screenshot of email written in Portuguese that links to malicious download.
Pikabot
Our second-to-last report of TA577 in 2023 sees the group distributing Pikabot from an email link. Figure 18 shows the sequence. How does this differ from the previous entries about TA577?
Figure 18. Infection chain of Pikabot pushed by threat group TA577.
In the last of our threat intelligence shares for the year (barring additional incidents), we see that, once more, TA577 is spreading a Pikabot infection.
In this instance, it led to Cobalt Strike on 207.246.99[.]159:443 using masterunis[.]net as its domain. Figure 19 dissects the traffic.
Figure 19. Pikabot malware traffic shown in Wireshark.
Conclusion
Much of our timely threat intelligence focuses on Windows malware, and we seek to post on malware families of current interest to the community.
If you’re interested in following our updates in real time, follow us on LinkedIn or X (formerly Twitter). If you track hashtags, follow #Unit42ThreatIntel to always catch the latest posts. Another option is to sign up for notifications on our GitHub repo.
As soon as you’re in the know, you’re also welcome to participate: comment, share or ask questions.
This article examines two specific issues in Google Kubernetes Engine (GKE). While each issue might not result in significant damage on its own, when combined they create an opportunity for an attacker who already has access to a Kubernetes cluster to escalate their privileges. This article serves as a crucial resource for Kubernetes users and administrators, offering insights on safeguarding their clusters from potential attacks.
The first issue we’ll discuss is the default configuration of GKE's logging agent FluentBit, which runs by default on all clusters. The second issue is the default privileges for Anthos Service Mesh (ASM), which is an optional add-on that customers can enable. ASM is Google's implementation of the Istio Service Mesh that controls service-to-service communication within a GKE environment.
If an attacker has the ability to execute in the FluentBit container (e.g., by discovering a remotely exploitable vulnerability in that component) and the cluster has ASM installed, they can create a single powerful chain to gain complete control of a Kubernetes cluster. Attackers can use this access to conduct data theft, deploy malicious pods and disrupt the cluster's operations.
Kubernetes is the most widely adopted open-source container platform used for application deployment and management. Due to its complexity, many Kubernetes environments are susceptible to security breaches due to misconfiguration and excessive privileges. In some cases, this can occur without any awareness from the customer, which can leave them exposed to security vulnerabilities.
Google fixed both configuration issues on Dec. 14, 2023, with GCP-2023-047.
Palo Alto Networks customers are better protected from the attacks described in this article in the following ways:
Before delving into the issues and their exploitable nature, it is imperative to establish a common understanding of several fundamental Kubernetes concepts, as well as a basic overview of GKE capabilities.
Kubernetes Concepts
Kubernetes is a complex platform that is composed of a number of different concepts. These concepts are essential for understanding the attack scenario. For a better understanding of the attack scenario we will explain two of them: DaemonSets and role-based access control (RBAC).
DaemonSets
DaemonSets and Deployments are two Kubernetes controllers that are used to manage the creation and deployment of pods.
However, they have different purposes and use cases. Deployments are used to manage the creation and deployment of multiple instances of a pod across a Kubernetes cluster. This is useful for running stateless applications, such as web servers and database servers.
DaemonSets are used to ensure that a single instance of a pod is running on each node in a Kubernetes cluster. This is useful for running pods that provide essential cluster services, such as logging, monitoring and networking.
Figure 1. Example of a deployment pod.Figure 2. Example of a DaemonSet pod.
RBAC Permissions
Role-based access control (RBAC) is a security mechanism that provides a fine-grained access control mechanism for resources in a Kubernetes cluster. RBAC works by assigning users and groups to roles, and then granting those roles permissions to specific resources.
RBAC is an important security feature in Kubernetes because it helps prevent accidental privilege escalation and unauthorized access. By carefully configuring RBAC permissions, it is possible to ensure that users and groups only have the permissions that they need to perform their jobs.
Figure 3. Permissions granted to Kubernetes pod.
GKE Features
GKE provides a number of features that are inherent to the platform, as well as some optional features that can be enabled. These features are designed to simplify the deployment and management of Kubernetes clusters. However, it is important to be aware of the potential security implications of these features.
FluentBit
FluentBit is a lightweight and efficient log processor and forwarder. Since Milestone 105 (March 2023), FluentBit has been the default logging agent in all GKE clusters, deployed by default as DaemonSets.
This means FluentBit is installed on each node in the cluster. It is enabled by default from Container-Optimized OS 109, and the legacy agent is disabled by default.
Anthos Service Mesh
Anthos Service Mesh is Google's implementation of the powerful Istio open-source project, allowing users to manage, observe and secure services without having to change application code.
The Next Generation of Second-Stage Cloud Attacks
Second-stage cloud attacks are a type of attack where the attacker has already gained some level of access to the Kubernetes cluster. The attacker will then look to spread into the cluster or escalate their privilege and they will search for misconfigurations or other vulnerabilities to do so.
In these cat and mouse games between attackers and defenders, container escape will continue to be a threat. Attackers will always try to find a way to escape and gain control over cloud environments. Cloud infrastructures and environments should be secure enough that even if an attacker succeeds in entering, they will not be able to do damage (or at least no significant damage).
Sometimes it will be possible to think that a certain misconfiguration is not necessarily a security matter or an issue that can affect your protected cloud environment. However, chaining several misconfigurations can lead to the creation of a strong exploit chain.
The two issues described in this post can be chained as a part of a second-stage attack to gain full control of a Kubernetes cluster.
The Privilege Escalation Finale
Prerequisite Step: FluentBit Exploit or Container to Node Escape
Since this is a second-stage attack, the attacker must first exploit the FluentBit container by discovering a remote code execution or arbitrary file read vulnerability, or otherwise breaking out of another container to gain access to the Node.
First Step: Exploit FluentBit Permissions To Read Projected Service Account Tokens
The first step of this chain exploits a misconfiguration, which is that the FluentBit container mounted the /var/lib/kubelet/pods volume. Below this directory, each pod running on a node has a kube-api-access volume that contains a projected service account token.
Figure 4 shows how this allows the FluentBit container to access any token of any of the pods on the node.
The kube-api-access volume contains the projected service account token for a pod to communicate with the Kubernetes API, which is a sensitive piece of information. If an attacker compromises the FluentBit pod, it would have access to its volume, and they could use any token of any pod on the node.
Using the pod token, the attacker can impersonate a pod with privileged access to the Kubernetes API server and gain unauthorized access to the cluster. In addition, the attacker could map the entire cluster, as they are able to list the running pods (using the get pods command).
Besides gaining unauthorized access to the cluster, an attacker can escalate their privilege or perform harmful actions. In fact, this gives the attacker a huge attack surface, depending on the permissions of the neighboring pods in the node.
The FluentBit container, by default and even generally, does not need direct access to the Kubernetes API server. This container can use either the Kubernetes infrastructure or its sidecar container. This is because the sidecar container’s primary purpose is to collect, parse and forward logs from the main application container. The sidecar container operates within the context of the pod and leverages the Kubernetes infrastructure to access log files and container runtime metadata.
Figure 4. FluentBit misconfiguration in which a volume mount includes too much access to the pod directory.
Second Step: Exploit Istio Post-Installation Permissions
The second step of this chain exploits the fact that the ASM's Container Network Interface (CNI) DaemonSet retains excessive permissions post-installation. This allows an attacker to create a new pod with ASM's CNI DaemonSet permissions. When enabling Anthos Service Mesh, Istio-cni-node DaemonSet is installed in the cluster.
The Istio-cni-node DaemonSet is responsible for installing and configuring the Istio CNI plugin on each node in the cluster. As such, it has powerful permissions to perform these tasks. But once it's up and running, it won't need such extensive permissions.
The DaemonSet has two roles:
Installing the CNI plugin. It does this by hostPath mounts and writing some files to the host FS (later read by Kubelet). This requires no RBAC, but does use a hostPath mount.
A "repair" mode. This detects if pods were started without configuration and handles them. This requires some RBAC privileges to work.
The need for these permissions by ASM's CNI DaemonSet can allow an attacker to exploit the DaemonSet and gain unauthorized access to the cluster, for example, by creating a “powerful pod.”
Chaining the two issues we’ve discussed together allows an attacker to gain complete control over the Kubernetes cluster by escalating privileges to cluster admin.
Figure 5. Anthos Service Mesh misconfiguration: Istio installer keeps its powerful permissions after installation.
Full Chain: Gaining Cluster Admin
After understanding the Kubernetes concepts and the issues, let’s see how we can leverage them to gain privileged access to the cluster as a cluster admin.
Prerequisite: Anthos Service Mesh Feature Is Enabled
Once the attacker has gained privileged access to the Kubernetes cluster – a task that can be done by taking control of the FluentBit container – an attacker can exploit the default configuration of a FluentBit container to mount the /var/lib/kubelet/pods volume. which has access to the kube-api-access-<random-suffix> directory. By doing so, the attacker will have all the tokens from all pods with a node.
The fact that FluentBit is a DaemonSet allows the attacker to search for any mounted tokens of any other pods in the cluster by repeating the initial compromise on each node. The attacker can map the entire cluster and find the Istio-Installer-container token.
The attacker will then take advantage of the ASM CNI DaemonSet's powerful permissions after the installation process is complete. The attacker will then create a new pod in the Kube-System namespace.
For this to be a meaningful privilege escalation, the attacker would need to target a powerful service account.
The Kube-System namespace offers a number of preinstalled, extremely powerful service accounts to choose from.
The clusterrole-aggregation-controller (CRAC) service account is probably the leading candidate, as it can add arbitrary permissions to existing cluster roles. The attacker can update the cluster role bound to CRAC to possess all privileges.
Figure 6 shows how the attacker will grant the CRAC’s service account in the pod’s YAML file and they will finally save the token in one of their own volume folders.
The CRAC token is now mounted to the new pod the attacker just created. The attacker can once again exploit the FluentBit misconfiguration and take the CRAC token, which has permissions to operate as a cluster admin by itself.
FluentBit uses a hostPath volume mount of the /var/lib/kubelet/pods directory to let it read certain logs, which it needs to do its job. Before the fix, it was clear that the volume mount configuration included unnecessary access to the pod directory (including the projected service account tokens). The Google Security Team fixed and reduced FluentBit's access to only the logs required.
Regarding Anthos Service Mesh, Google was already aware of the high privileges associated with its CNI DaemonSet from an internal report. They were already in the process of fixing it and reducing its permissions when we reported it to them and this has now been fixed.
Unit 42 researchers were the first to combine the FluentBit vulnerability with ASM's CNI DaemonSet privileges to an attack chain that eventually allows escalating to cluster admin privileges.
Following our advisory and over the course of the last several weeks, Google deployed fixes and mitigations to FluentBit volume mount and Anthos Service Mesh high-privilege permissions. These prevent the reported attack and harden the platform against similar exploits.
Google addressed these issues by doing the following:
They removed the /var/lib/kubelet/pod volume mount from the Fluent Bit pod, eliminating its access to the projected service account tokens for other pods.
They modified ASM's ClusterRole and re-architected some of its functionality to remove excessive RBAC permissions.
Conclusion
Kubernetes is a powerful container orchestration platform that organizations of all sizes use to run their applications. However, system pods in some circumstances can be an unguarded area of an organization’s security.
Cloud vendors automatically create system pods when your cluster is launched. They are built in your Kubernetes infrastructure, the same as add-on pods that have been created when you enable a feature. This is because cloud or application vendors typically create and manage them, and the user has no control over their configuration or permissions. This can also be extremely risky since these pods run with elevated privileges.
This post demonstrates how an attacker can use two issues in system pods and add-on pods to escalate privileges and gain admin permissions.
Palo Alto Networks Protections and Mitigations
Prisma Cloud
Palo Alto Networks Prisma Cloud is a cloud security platform that are designed to help you protect your Kubernetes cluster from a variety of threats, including attacks that target system pods and add-on pods.
Prisma Cloud provides a variety of features that can help you to:
Monitor and detect suspicious activity in your cluster.
Identify misconfigurations and excessive privileges in system pods and add-on pods.
Prevent attackers from exploiting misconfigurations and vulnerabilities in system pods and add-on pods.
By using Prisma Cloud, you can improve the security of your Kubernetes cluster and protect it from a wide range of threats.
Cortex
Cortex XDR enhances the capabilities of SOC teams by providing a comprehensive incident narrative which may span their entire digital environment. This is achieved through the integration of activity data from Kubernetes Nodes and Kubernetes API Server audit logs, as well as endpoint and network data. Cortex effectively uses this information to identify anomalous Kubernetes actions that align with established TTPs, including Kubernetes credential theft, cryptojacking, container escapes and other security threats.
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 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.
Disclosure Timeline
Sep. 12, 2023: Palo Alto Networks submitted a report Dual Privilege Escalation Chain to Google
Cloud Vulnerability Reward Program regarding this issue.
Sep. 13, 2023: Google Security Team accepted the report as a security issue.
Oct. 24, 2023: Google Security Team accepted the report as a bypass of significant security controls.
Nov. 24, 2023: Palo Alto Networks notified Google of the intention to publish an article and offered the opportunity for fixes and input on the article.
Dec. 11, 2023: Google Security Team sent inputs on the article.
Dec. 14, 2023: Google Security Team fixed the security issues.
Unit 42 researchers have observed threat actors using malicious JavaScript samples to steal sensitive information by abusing popular survey sites, low-quality hosting and web chat APIs. In some campaigns, attackers created chatbots that they registered to someone noteworthy such as an Australian footballer. Other malware campaigns we saw included both web skimmers injected into compromised sites and traditional phishing sites.
In this article, we’ll describe some of the tactics used by malicious JavaScript to steal information through several case studies. The case studies show specific examples of how the malware we observed tries to evade traditional static and dynamic analysis by using obfuscation, unusual Document Object Model (DOM) interactions and selective payload detonation.
How JavaScript Malware Exfiltrates Secrets: Skimmers, Stealers, Phishing Pages
In our research on malicious JavaScript, we’ve noticed attackers using new techniques to collect and aggregate stolen information including passwords or credit card numbers. Attackers use these exfiltration methods both in traditional phishing pages (where the remote host is malicious) and in skimming pages, where a malicious script has compromised the remote host.
Detecting classic phishing cases is already difficult on its own. Detecting pages that skimmers have compromised can be even more difficult, because detection logic cannot use any features of the site or URL to aid detection.
Skimming sites are hosted exactly where they are supposed to be, and therefore detection systems do not notice anything visually different about the hosting site. Phishing pages often hide the exfiltration endpoint to evade detection of the credential collection point, even if the hosting page is detectable.
To help detect such evasive skimmers and phishing exfiltration attacks, we’ve developed new techniques to analyze JavaScript to track the fine-grained information flowing through the program. By identifying information flows that steal data, our analysis can identify when scripts send sensitive information outside of the script to attackers.
The Palo Alto Networks AUF service detected over 216,000 distinct exfiltration attacks in one three-month period. We observed the following activity in those attacks:
83% of these attacks steal password information
2% steal credit card information
Less than 1% steal browser cookies
Around 15% steal other text information on the page
Our data shows that malicious websites often reuse the same exfiltration endpoint across different domains and URLs. In Figure 1, we see that one endpoint is shared among thousands of different domains and more than 66,000 URLs.
We see that 33% of exfiltration collection points are shared across more than one domain and 56% are shared across more than one URL. In general, we see more sharing across different URLs than domains, such as when attacks use a distinct URL for each victim. However, we still see many cases where multiple separate domains share a common credential collection point.
Figure 1. Exfiltration collection endpoint reuse across multiple attack frontends. Graph in log-log scale.
Attackers Are Using Chat and Survey REST APIs to Steal Data
Using our information flow analysis, we have discovered some examples of exfiltration techniques attackers are using to abuse popular, legitimate cloud APIs for the purpose of exfiltrating credentials.
Figure 2a shows a sample with top-level dynamically generated HTML and Figure 2b shows the same instance obfuscated.
This malware sample uses a chat platform’s REST API to exfiltrate the data after it is stolen.
Figure 2a. Top level dynamically generated HTML.
Figure 2b shows that the entire page is dynamically generated with one layer of simple escape obfuscation.
Figure 2b. Obfuscated code.
However, the sample shown in Figure 3 uses multiple layers of obfuscation, some using custom unpacking functions (see the highlighted sd5e95e572) that must be dynamically executed to detonate the encoded payload. Attackers often use this type of obfuscation to evade static analysis, but it is possible to analyze the payload in a dynamic execution sandbox.
Figure 3. Obfuscated code using a custom unpacker.
Figure 4 shows multiple public REST APIs used for this purpose. Typically, these are APIs associated with chat programs or surveys.
Figure 4. Malicious payload.
Next, we analyze the code.
Once we analyze the dynamically generated code (shown above in Figure 4), we observe that this sample collects multiple types of sensitive data:
PIN
Password
Customer number
The sample then sends this data to a specific chatbot that the attacker controls, to harvest the data for further exploitation. This is just one example of attackers abusing cloud APIs to collect exfiltrated credentials. Other examples we see besides chatbot APIs are survey form APIs, low-quality rentable domains and dynamic DNS domains.
We speculate that attackers use the legitimate cloud API domains to evade analysis by using the cloud website’s higher reputation to prevent firewall blocking. Since threat operators use these endpoints for credential collection, it is difficult to tell that the APIs are being abused without having visibility into the malicious sample.
Using cloud APIs can also reveal information about the malware author. For example, chatbot endpoints also contain ways to query for information about specific bots. In this case, the chatbot is registered to someone claiming to be an Australian footballer. While this is likely a fake name, some chat endpoints point to a specific chat room that victims can join, or they contain other information.
Malware Hides Information Theft Using Unusual DOM Elements
Malware samples can also use other techniques to hide exfiltration without being noticed. Figure 5 shows an example of a malware author exfiltrating information by loading a hidden image with query parameters that include the stolen information.
Figure 5. Exfiltration using image loading.
The hidden img tag causes the browser to send an HTTP request to download the image, but it also sends the stolen data (a credit card number, in this case) to the attacker. We believe this is an attempt to evade detection using atypical exfiltration methods.
The malware author also encodes the exfiltration domain to avoid detection from simple static analysis and signatures. We’ve seen other examples of attackers using unusual DOM elements to exfiltrate information, such as script, object and img elements.
Obfuscation is also a well-known technique that continues to allow information stealers to evade detection. What is surprising is that an increasing number of cases do not use code generation. For example, threat authors will execute code with eval, which is a dynamic code generation function that attackers can use to obfuscate the true payload.
We speculate that when threat authors don’t use dynamic code generation, they are doing so to avoid detection because many detectors monitor dynamically generated code during sandbox analysis. The following is a list of samples (available on VirusTotal) that use exfiltration, which continue to evade many vendors’ detection by using simple obfuscation methods:
Malware Evades Detection by Refusing to Detonate Its Payload
Obfuscation can prevent detection by most static analysis, but to evade dynamic analysis, malware can selectively detonate its payload. This is not a new phenomenon, but we are seeing specific tactics to evade analysis for JavaScript malware.
By reducing the number of times when the payload detonates, the malware authors reduce the opportunity for pure dynamic analysis to identify their malware. Forcing payload detonation is one of the key techniques that allows our analysis emulator to detect highly evasive JavaScript.
At the same time, refusing to detonate payloads is still effective for evading detection by many other vendors. At the time of writing, the samples with the following SHA256 hashes are currently undetected by all vendors on VT:
In the first example, we see the malware only activating on pages that contain keywords. Using the word checkout indicates that the victim might be entering sensitive information.
We also see malware explicitly checking for analysis artifacts in the execution environment, like that shown in the code in Figure 6. Such artifacts would typically only be present during debugging sessions.
Figure 6. Checking for artifacts in the execution environment.
Malware samples can also check for crawler artifacts that might tell whether the browser ended up on the page organically (like a potential victim would) or with direct navigation (like a security crawler might). The malware will refuse to detonate if it is under analysis by a security crawler (as shown in Figure 7).
Figure 7. Checking if the browser is a victim user or an automated service.
Tracking Information Flows Through JavaScript Code
Our JavaScript malware analysis emulator uses a mixture of static and dynamic code analysis to explore the program's behavior. Static analysis typically looks at code as a static artifact. In contrast, dynamic analysis will run the program and observe the behavior of one specific execution path.
Exploring the complete behavior of a normal, benign JavaScript program is difficult enough due to JavaScript’s dynamic features, which can limit static analysis. Achieving complete dynamic code coverage even on a normal program is often not possible.
When analyzing malware, the malware author often makes programs intentionally more difficult to analyze to evade detection. Malware authors use obfuscation and analysis evasion techniques to avoid detonating the payload when the sample is under analysis. In addition, malware might require specific user input that is difficult to automate, like solving a captcha or entering specially formatted information.
Our analysis technique for this research article aims to detect highly evasive malware that tries to hide from static and dynamic analysis. To detect these highly evasive cases, we use a mixture of both static and dynamic methods to simulate approximate program execution across the entire sample under analysis. This has the benefit of unpacking deobfuscation while also forcing the detonation of dynamic evasions.
After we detonate payloads, our analysis tracks the information flows that occur during program execution. We use a technique called taint tracking, which helps us track the movement of each piece of data in the program. Taint tracking is a general technique that can help identify many different information flow properties of programs.
In our implementation, for each piece of data in the program we track whether it contains sensitive information, such as passwords or credit card data. During execution, our modified JavaScript environment labels each piece of data to include whether the data is tainted. Then we can track the propagation of the trained data from its origin to the destination.
During execution, our analysis monitors for when information that is “tainted” with such sensitive information is sent outside of the browser (e.g., via XMLHttpRequest). When we observe a flow of sensitive information to a suspicious exfiltration path, this is a signal that the JavaScript sample is performing an exfiltration attack.
Conclusion
We’re continuing to see JavaScript information stealers use a variety of techniques to evade detection. In addition to using various obfuscation techniques, they increasingly use ways to evade dynamic analysis by selectively detonating their payload and also use custom loaders to further complicate the detection process.
The end goal of these stealers is to exfiltrate sensitive information from the victims. We identified evasive techniques that are becoming increasingly popular to exfiltrate sensitive information such as the following:
Using popular survey sites
Low quality hosting
Web chat APIs
We recommend that security practitioners continuously monitor exfiltration endpoints to identify such malicious use cases. Furthermore, we believe service providers of such services can take measures to proactively weed out malicious parties abusing their platforms.
Palo Alto Networks customers receive protection from the threats discussed above through our Advanced URL Filtering cloud-delivered security service, which automatically analyzes offline and online information stealing attacks. Also, Cortex XDR analytics provides coverage for such threats with NDR and EDR analytics detectors for instant messaging, exfiltration and C2 techniques using local and global analytics profiles.
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the IoCs shared in this research.
We recommend that website operators continue to keep their software up to date, as this is a common vector for attackers to compromise websites to host malicious JavaScript.
Indicators of Compromise
The malware evasion techniques described in this article are general malware behaviors and not limited to the specific campaigns here. However, here is a list of the samples referenced in this article:
Malicious actors often acquire a large number of domain names (called stockpiled domains) at the same time or set up their infrastructure in an automated fashion. They do so, for example, by creating DNS settings and certificates for these domains using scripts.
Automation employed by attackers can leave traces of information about their campaigns in various data sources. Security defenders can find these traces in locations such as certificate transparency logs (e.g., certificate field reputation or timing information) and passive DNS (pDNS) data (e.g., infrastructure reuse or characteristics).
Leveraging these crumbs of information, we built a detector to identify stockpiled domains. The two main advantages of detecting stockpiled domains are expanding coverage of malicious domains and providing patient-zero detections as attackers stock up on domains for future use.
To detect stockpiled domains, we engineered over 300 features to process many terabytes of data and billions of pDNS and certificate records. We used a knowledge base of millions of malicious and benign domains to calculate certificate and pDNS reputation and to train and test a Random Forest machine learning algorithm.
As of July 2023, our detection pipeline has found 1,114,499 unique stockpiled root domain names and identifies tens of thousands of malicious domains weekly. Our model, on average, found stockpiled domains 34.4 days earlier compared to vendors on VirusTotal. The success of our approach emphasizes the need to combine multiple large datasets, such as passive DNS and certificate logs, to detect malicious campaigns.
The stockpiled detector continuously picks up a wide variety of scam, phishing, malware distribution, C2 and other campaigns. Some of these phishing campaigns target the largest software companies, online retail shops, banks, streaming services and more. In this article, we share both large campaigns leveraging thousands of domains and small campaigns involving just a few domains.
In our previous article on fast fluxing, we described how, over time, techniques used by cybercriminals evolved into the domain wars. This ongoing struggle involves criminals registering many domain names to make it harder for law enforcement to take down their botnets.
The domain wars have spread across all types of online crime, including:
Phishing
Scams
Malware and Potentially Unwanted Program (PUP) distribution
Adversarial Search Engine Optimization (SEO)
Distribution of illicit content (e.g., adult pages, gambling and pirated movies)
In this article, we return to our fictional scenario of an interaction between cybercriminals and law enforcement, namely Chief Emilia and Lisa (who is the sister of Bart from our previous episode).
We’ll also discuss multiple campaigns that we’ve detected with our model, as a way of illustrating how we can use various features to improve protection.
The Misadventures of Lisa and the Puppy Scam Site
In our fictional scenario, Chief Emilia saw that even though stricter registration policy changes that researchers had proposed could be useful, these changes would take a long time. These changes also wouldn’t be enough by themselves to solve the domain wars. Thus, she created a research team to collect data about malicious domain names and to develop detectors to identify them.
In the meantime, our budding cybercriminal Lisa had an evil plan. Lisa hasn’t always been evil. In fact, she was a very good-hearted person. But her parents never let her have a puppy, and slowly, she turned sour.
One day, Lisa decided that if she couldn’t have a puppy as a kid, then no other kids could. She began her descent into evil by launching puppy scam websites. Figure 1 shows a real-life example of a puppy scam site.
Figure 1. Screenshot of a puppy scam website baronessabernesemountaindogpuppies[.]com.She started this endeavor by stockpiling a bunch of domain names and cutting together content from real puppy web shops but with fraudulent email addresses, phone numbers and payment sites. (We call these domains registered by the same actor for use in malicious campaigns stockpiled domains.)
Unfortunately for Lisa, Emilia’s team has long been monitoring newly registered domains (NRDs), and they have applied extra scrutiny to these domains. Emilia’s team scraped the sites’ content, analyzed registration behavior and discovered the underlying infrastructure. (This is just as we at Palo Alto Networks pay special attention to NRDs, finding many malicious ones). As a result, Lisa’s scam websites were swiftly found and taken down.
Lisa was determined to succeed. So, before launching the puppy scam campaigns, she started aging domain names used for the websites. As Emilia monitored various scam campaigns, she quickly caught on to the tactic of strategically aging domains (see our research on aged domains) and set her team to watch for when dormant domains get activated.
To evade having her sites scraped by Chief Emilia’s team, Lisa employed a variety of tactics. These included cloaking (showing benign content to suspected crawling bots) and user targeting (showing malicious content only to specific users).
Researchers have shown that cybercriminals use various cloaking and user-targeting techniques, which pose a significant challenge to detect malicious domains. Palo Alto Networks inspects web traffic inline, ensuring we block malicious websites even if they leverage cloaking or user-targeting practices.
Inline detection has its limitations, so Emilia’s team set out to combine a variety of large datasets (including certificate logs and pDNS) to train a machine learning model. This model can find malicious domains leveraging similar automation or infrastructure, or that the same criminal group owns.
Ultimately, it became tough for Lisa to maintain her scam campaigns without getting caught.
One day, while looking at a real web shop that sold puppies, she saw one that looked exactly like the one she wanted as a little girl. She suddenly realized all the evil she had done and decided to give up her life of crime. She adopted the puppy as an adult and joined Emilia’s team to fight cybercrime to undo some of her wrongdoing.
Scam Sites in the Real World
Unfortunately, not all cybercriminals have turned their life around, so we have plenty of similar examples to examine in the real world. Figure 1 shows a real-life puppy scam website (baronessabernesemountaindogpuppies[.]com) and how our detection model gives an advantage in detecting this scam.
Threat actors registered this site on April 21, 2023. Our stockpiled detector first flagged it on April 24, 2023. Two days later, one vendor on VirusTotal marked it as malicious. Then on Aug. 22, 2023, volunteers on a scam-hunting website Artists Against 419marked it as a scam site.
Early Detection of Malicious/Phishing Domains
Fighting the domain wars is a global community effort where we lean on previous work by academic researchers, law enforcement, cybersecurity professionals, policymakers and volunteers. Researchers in the past have shown that WHOIS and pDNS data are useful for finding malicious domain names registered in bulk.
More recently, researchers looking into certificate datasets discovered they can use these datasets to find stockpiled domains (potentially independent of registration time) where certificates were set up similarly because the criminals likely used automated scripts. Closest to our work is research by AlSabah et al., where the authors looked at both certificate transparency logs and pDNS to identify phishing domains.
Detecting Stockpiled Domain Names
Recognizing that automation can leave us crumbs of information in different datasets, we extracted features from certificate transparency logs, pDNS data and domain name strings that our detector can use to find malicious domain names. Browsers enforce certificate transparency to monitor and audit certificates to make it harder for cybercriminals to use malicious certificates (e.g., when a certificate authority is compromised).
We collect millions of certificates and domains every day from multiple transparency log servers that maintain immutable records of certificates. Similarly, pDNS is a database of DNS request-response pairs passively collected from all over the world (e.g., when users access various web resources or send emails). Our pDNS database consists of billions of DNS records daily.
From these datasets, we collect the following six categories of features as shown in Figure 2.
Certificate Features
Domain Name Lexical Features
Certificate Domain Aggregation Features
Certificate Reputation and Aggregation Features
pDNS and Certificate Aggregation Features
pDNS Reputation and Aggregation Features
Figure 2. High-level overview of the stockpiled detector’s feature extraction pipeline.
Then we follow a series of steps to gather further information.
Certificate-Specific Features
These features include, for example, the validity length of the certificate or the number of root domain names in the certificate. When cybercrooks automate their processes, they might not think to change these details.
Domain-Specific Certificate Features
These features include, for example, the number of certificates and issuers we see for a domain name, which would signal that their owners treat them similarly.
Certificate Reputation and Aggregation Features for Various Certificate Fields
For example, this category includes the proportion of malicious domain names or the distribution of words for specific fields of certificates. We compute reputation scores for certificate fields (e.g., validity length, seen time, not before field and fingerprint). Certificate reputation features help our classifier understand certain field values commonly set by malicious operations.
Lexical Features for Domains
From the domain name itself, we calculate features like the randomness of the name, the number of words, encoding of the top-level domain (TLD), and whether there is a brand name in the domain name. These features help us capture whether a malicious campaign is targeting a specific set of brands, or if the same algorithm generated the domain names.
pDNS Reputation and Aggregation Features
From pDNS we calculate features like the known malicious and benign proportions of domains and the average domain age or the number of certificates for an IP (or a /24 subnet). PDNS reputation helps us understand more about the shared infrastructure of stockpiled domain names.
Aggregate Features for Certificates and pDNS
These features include, for example, the number of IPs of all the domains in a certificate. Aggregating across multiple data sources (e.g., certificates and pDNS) is essential to understanding the deeper connection between certificate setup and the infrastructure of stockpiled domain names.
After generating features from domain names, certificate logs and pDNS, we train a Random Forest machine learning classifier to predict stockpiled domain names. We leverage our extensive knowledge of millions of malicious and benign domain names as labeled data for training and fine-tuning the classifier for high precision.
Our classifier can achieve 99% precision with 48% recall, even though many of the malicious domains might not be stockpiled or cybercriminals might not leave traces of information in certificate logs and passive DNS data.
Our detection pipeline has found 1,114,499 unique stockpiled root domain names since July 2023, identifying tens of thousands of malicious domains weekly. Other content and behavior analysis-based detectors later identified 45,862 malware, 8,989 phishing and 844 C2 domains among the stockpiled domains.
Our model caught stockpiled domains on average 34.4 days earlier than vendors on VirusTotal. We expect the average delay to grow as other detectors find already identified stockpiled domains.
Our stockpiled detector picked up a variety of campaigns including scams, phishing, malware distribution and C2. Below, we share a few interesting campaigns that our stockpiled detector was able to detect early.
A Malicious Redirection Campaign
Our detector captured more than 9,000 registered domains that were part of a malicious redirection campaign, for example:
Whdytdof[.]tk
Pbyiyyht[.]gq
Rthgjwci[.]cf
Cgptvfjz[.]ml
VirusTotal vendors were only able to mark 31.7% of these domains as malicious. Even when they found a domain to be malicious, our detector was capable of finding them 32.3 days earlier on average.
Perpetrators rarely set up such a large campaign without leaving some valuable information for our machine learning model. Even though these domains use Cloudflare, which makes pDNS-based identification challenging, we can follow other trails.
In a recent example, perpetrators randomly generated domains using low-quality TLDs. Also, all the domains had the same validity length for their certificates. And while their activation dates are different, perpetrators activated them all fairly recently.
In this campaign, victims are redirected to different websites before reaching a landing page, which is usually an adware or a scam page. For example, Figure 3 shows a screenshot of the final payload received by our crawler after redirections.
In both cases, our crawler was redirected to a fake notification scam with clickbait. A fake warning message was displayed to trick people into allowing an attacker-controlled website to send browser notifications. Additionally, both pages have a clickbait advertisement at the bottom of the website.
Figure 3. Fake warning message after an example of malicious redirection from pbyiyyht[.]gq.Further analysis shows that all these hostnames redirected users to one of two hostnames (i.e., thewinjackpot[.]life and winjackpot[.]life). From the visual analysis of the content of a few detected hostnames, we found that a URL of these two hostnames was assigned to windows.location.href with a timeout (shown in Figure 4). We surmise the campaign owner likely owns both these hostnames, and they later redirect victims to other websites.
Figure 4. Example of JavaScript snippet (from whdytdof[.]tk) that redirects users to a malicious website.
A European Postal Phishing Campaign
In a postal phishing campaign targeting Italian- and German-speaking users, the phishing page harvested victims’ login credentials. Our detector found a group of related domains.
Vendors on VirusTotal marked only two out of our four example domains as malicious:
Abschlussschritte-info[.]com
Aksunnatechnologies[.]com
222camo[.]com
Rothost[.]best
Abschlussschritte-info[.]com was registered on June 2, 2023, and our detector found it to be malicious ten days later, on June 12, 2023. We only saw VirusTotal vendors detecting it two months later, on Aug. 11, 2023.
Figure 5 shows what the original webpage poste[.]it looks like.
Figure 5. The legitimate Italian postal service page poste[.]it.Figure 6 is a screenshot of the phishing domain 222camo[.]com that is impersonating the original website.
Figure 6. A phishing domain 222camo[.]com impersonating poste[.]it.These four domains clearly had the same content and were part of the same campaign. However, there were a few signals related to automation for our detector to use.
Although these domains had the same validity length, they were registered on vastly different dates and used different IP addresses. Thus, our model mainly relied on certificate field-based and pDNS-based reputation features to identify the domains in this campaign.
A USPS Phishing Campaign
Our detector caught a campaign impersonating the United States Postal Service (USPS) where more than 30 domains (including the following examples) are used to host the same website shown in Figure 7:
Delivery-usps[.]vip
Delivery-usps[.]wiki
Delivery-usps[.]ren
These domains are registered under only four certificates. Our stockpiled domain detector caught all these domains before VirusTotal first detected them. We detected some of these domains days (e.g., usps-redelivery[.]art – 3 days) or weeks (e.g., usps-redelivery[.]live – 2 weeks) ahead of other vendors.
These domains were registered in the time span between June 17, 2023, and Aug. 28, 2023, and the domain certificates were obtained on the same day of registration. The aggregation of domains into a few certificates and the correlation to domain creation time suggests that threat actors created these domains with some level of automation. This automation allowed us to connect the dots and detect all of these malicious stockpiled domains.
Figure 7. A phishing page impersonating USPS using multiple domains (e.g., delivery-usps[.]vip, delivery-usps[.]wiki and delivery-usps[.]ren) registered under different TLDs.
A High-Yield Investment Scam Campaign
One of these campaigns consisted of more than 17 domains focusing on high-yield investment scams. In these campaigns, scammers try to convince users that in return for a small initial investment, they would earn a lot of money.
The following are a few example domains in this campaign:
Erinemailbiz[.]com
Natashafitts[.]com
Makemoneygeorge[.]com
Julieyeoman[.]com
While VirusTotal vendors found 12 out of 17 of these domains, on average they found them 34.7 days later than our detector.
When criminals set these domains up for their malicious campaigns, they left crumbs of information. For example, all the domains had the same validity length for their certificates, and they used the same IP address. While their registration dates are different, and they had more than one registrar, they were all newly registered domains.
At first, customers will be presented with a page (shown in Figure 8) that asks for very little. Give us your name and email address in return for earning $500 deposits. What is there to lose, right?
After filling out the information, victims will be redirected to another page to double-check if they’re ready to be tricked.
Figure 8. Scam domain erinemailbiz[.]com initial page screenshot.People who fill out the information and click the submission button will be redirected to checkout.mytraffic[.]biz, as shown in Figure 9. On this page, victims are asked if they want a massive discount. But when they click “Yes,” they’re redirected to the final landing page.
Figure 9. Redirection page from erinemailbiz[.]com to checkout.mytraffic[.]biz.Finally, the victims are redirected to the landing page on checkout.mytraffic[.]biz (shown in Figure 10). The page checks every checkbox for a phishing page:
The offer is too good to be true.
There’s a count to hasten people into filling out their information.
The page also indicates that other people are waiting to take the offer.
The page is packed with big logos signaling that the page is secure and that there’s a 30-day money-back guarantee.
We hope not many people filled in their credit card information at the bottom.
Figure 10. Victims redirected to the final landing page on checkout.mytraffic[.]biz.
Conclusion
As the domain wars unfolded, cybercriminals started to automate their infrastructure setup. However, bulk domain registration and infrastructure automation can leave crumbs of information that allow us to detect stockpiled domains. The success of our approach emphasizes the need for security defenders looking to improve their detection to combine multiple large datasets, such as pDNS and certificate logs, to uncover malicious campaigns.
Our high-precision, machine learning-based detector processes terabytes of certificate and DNS logs to discover thousands of stockpiled domains weekly. Our detection pipeline has uncovered a wide variety of different types of campaigns earlier than VirusTotal vendors, and we also found domains that were not detected by others.
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the IoCs shared in this research.
Acknowledgments
We want to thank George Jones, Arun Kumar, Alex Starov, Lysa Myers, Bradley Duncan, Erica Naone and Jun Javier Wang for their invaluable input on this post.
Early this year, Ukrainian cybersecurity researchers found Fighting Ursa leveraging a zero-day exploit in Microsoft Outlook (now known as CVE-2023-23397). This vulnerability is especially concerning since it doesn’t require user interaction to exploit. Unit 42 researchers have observed this group using CVE-2023-23397 over the past 20 months to target at least 30 organizations within 14 nations that are of likely strategic intelligence value to the Russian government and its military.
During this time, Fighting Ursa conducted at least two campaigns with this vulnerability that have been made public. The first occurred between March-December 2022 and the second occurred in March 2023.
Unit 42 researchers discovered a third, recently active campaign in which Fighting Ursa also used this vulnerability. The group conducted this most recent campaign between September-October 2023, targeting at least nine organizations in seven nations.
Of the 14 nations targeted throughout all three campaigns, all are organizations within NATO member countries, except for entities in Ukraine, Jordan and the United Arab Emirates. These organizations included critical infrastructure and entities that provide an information advantage in diplomatic, economic and military affairs.
Target organizations included those related to:
Energy production and distribution
Pipeline operations
Materiel, personnel and air transportation
Ministries of Defense
Ministries of Foreign Affairs
Ministries of Internal Affairs
Ministries of the Economy
Fighting Ursa (aka APT28, Fancy Bear, Strontium/Forest Blizzard, Pawn Storm, Sofacy or Sednit) is a group associated with Russia’s military intelligence and they are well known for their focus on targets of Russian interest – especially those of military interest. Fighting Ursa has been attributed to Russia's General Staff Main Intelligence Directorate (GRU) 85th special Service Centre (GTsSS) military intelligence Unit 26165.
We are publishing this research to highlight Fighting Ursa using this vulnerability in multiple campaigns despite their tactics having been publicized by security industry research documenting this activity. High risk organizations and nations using Microsoft Outlook should patch CVE-2023-23397 immediately and ensure appropriate configuration to defend against future attacks.
Palo Alto Networks customers receive protection with the following products against the types of threats discussed in this blog:
Prior to the conflict in Ukraine, Fighting Ursa had established a reputation for its hacking in support of Russia’s information warfare operations. This support includes the following efforts:
Less internationally well known are Fighting Ursa’s collective hacking campaigns in the lead-up to Russia’s invasion of Ukraine through today.
On Feb. 24, 2022, Russia initiated a full-scale armed invasion of Ukraine. Three weeks later (March 18, 2022), Fighting Ursa emailed the first known instance of an exploit using the CVE-2023-23397 vulnerability (which was then a publicly undiscovered zero-day exploit) to target the State Migration Service of Ukraine.
Fighting Ursa continued to use this vulnerability as part of its targeting strategy even after Ukrainian cybersecurity researchers discovered the exploit and Microsoft publicly attributed its use to “a Russia-based threat actor” on March 14, 2023, when issuing a patch for the vulnerability.
Overall, Unit 42 researchers have observed three distinct Fighting Ursa campaigns associated with this CVE:
Zero-daycampaign (Initial campaign prior to discovery): March 18-Dec. 29, 2022
Second campaign (post-identification of CVE): March 15-29, 2023
Third campaign: Aug. 30-Oct. 11, 2023
Figure 1 shows Fighting Ursa’s last observed attempt to use CVE-2023-23397 in a message sent to a Montenegrin Ministry of Defense account on Oct. 11, 2023. This message was sent from an account the actors had created on a public mail service (portugalmail[.]pt).
Figure 1. Malicious task request sent to Montenegrin Ministry of Defense account. SHA256 4238c061102400fa27356266c6f677d1d7320f66f955a7f389eb24f10a49b53d.
Successful exploitation of Microsoft Outlook using this vulnerability results in a relay attack using Windows (New Technology) NT LAN Manager (NTLM) as described in our threat brief for CVE-2023-23397.
NTLM is a challenge-response style authentication protocol that is prone to relay attacks, so Kerberos has been the default authentication protocol in Windows systems since Windows 2000. However, many Microsoft applications still use NTLM as a fallback protocol in cases where Kerberos is not feasible. Microsoft Outlook is one such application.
When a vulnerable or misconfigured Outlook application receives a specially crafted email exploiting CVE-2023-23397, Outlook sends an NTLM authentication message to an attacker-controlled remote file share. The NTLM authentication response is an NTLMv2 hash that Fighting Ursa uses to impersonate the victim, accessing and maneuvering within the victim's network. This is commonly known as an NTLM relay attack.
Unit 42 researchers attribute the activities within these campaigns to Fighting Ursa for two primary reasons:
The targeted victims in these campaigns are all of apparent intelligence value to the Russian military.
The campaigns all used co-opted Ubiquiti networking devices to harvest NTLM authentication messages from victim networks, which is consistent with previous Fighting Ursa campaigns.
Victimology: A Study in Russian Targeting Priorities
Delving into more than 50 observed samples in which Fighting Ursa targeted victims with CVE-2023-23397 provides unique and informative insights into Russian military priorities during a time of international conflict for them. Zero-day exploits by their nature are valuable commodities for APTs. Threat actors only use these exploits when the rewards associated with the access and intelligence gained outweigh the risk of public discovery of the exploit.
Using a zero-day exploit against a target indicates it is of significant value. It also suggests that existing access and intelligence for that target were insufficient at the time.
In the second and third campaigns, Fighting Ursa continued to use a publicly known exploit that was already attributed to them, without changing their techniques. This suggests that the access and intelligence generated by these operations outweighed the ramifications of public outing and discovery.
For these reasons, the organizations targeted in all three campaigns were most likely a higher than normal priority for Russian intelligence.
There are a few key takeaways when looking at the targets collectively, as shown in Figure 2:
Other than Ukraine, all of the targeted European nations are current members of the North Atlantic Treaty Organization (NATO)
Outside of government organizations, attackers focused on targeting critical infrastructure-related organizations within the following sectors:
Energy
Transportation
Telecommunications
Information technology
Military industrial base
Figure 2. Observed targets of Fighting Ursa CVE-2023-23397 campaigns.
Conclusion
It is rare to have such a detailed understanding of an APT’s targeting priorities, especially an APT like Fighting Ursa whose mission mandate is to conduct attacks on behalf of Russia’s military.
Governments and critical infrastructure providers across NATO and European nations are encouraged to take the following actions:
Take note of these tactics
Patch this vulnerability
Configure endpoint protections to block these types of malicious campaigns
Protections and Mitigations
Cortex XDR customers who have Advanced API Monitoring enabled receive protection from exploitation attempts of CVE-2023-23397 using XDR Anti-Exploit protection.
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the IoCs shared in this research.
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 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.
Unit 42 researchers observed a series of apparently related attacks against organizations in the Middle East, Africa and the U.S. We will discuss a set of tools used in the course of the attacks that reveal clues about the threat actors’ activity. We are sharing this research to provide detection, prevention and hunting recommendations to help organizations strengthen their overall security posture.
These tools were used to perform the following activities:
Establish backdoor capabilities
For command and control (C2)
Steal user credentials.
Exfiltrate confidential information
Unit 42 is sharing these results with the purpose of helping organizations defend against the tools observed here.
We assess with medium confidence that this threat activity cluster aligns to nation-state related threat actors due to the nature of the organizations that were compromised, the TTPs observed and the customization of the tool set. We have not confirmed a particular nation-state or threat group.
Tools that were used in this cluster were the following:
A new backdoor we’ve named Agent Racoon
This malware family is written using the .NET framework and leverages the domain name service (DNS) protocol to create a covert channel and provide different backdoor functionalities. Threat actors have used this along with the other two tools in multiple attacks targeting organizations across the U.S., Middle East and Africa. Its C2 infrastructure dates back to 2020.
A new tool we’ve named Ntospy
This malware is a Network Provider DLL module designed to steal user credentials.
A customized version of Mimikatz called Mimilite
The compromised organizations belong to the following industries:
Education
Real estate
Retail
Non-profit organizations
Telecom companies
Governments
Based on unique similarities in tools as well as tactics, techniques and procedures (TTPs), we are tracking this threat activity cluster as CL-STA-0002.
What follows is a detailed description of the activity we observed as well as characteristics of the tool set.
Palo Alto Networks customers receive protection from these threats through Cortex XDR as well as Advanced URL Filtering, DNS Security and Advanced Wildfire. Organizations can engage the Unit 42 Incident Response team for specific assistance with this threat and others.
The threat actor used temporary directories such as C:\Windows\Temp and C:\Temp to deploy specific components of their tool set across the different affected organizations. They used the following similar filenames for batch and PowerShell scripts:
c:\windows\temp\crs.ps1
c:\windows\temp\ebat.bat
c:\windows\temp\install.bat
c:\windows\temp\mslb.ps1
c:\windows\temp\pb.ps1
c:\windows\temp\pb1.ps1
c:\windows\temp\pscan.ps1
c:\windows\temp\set_time.bat
c:\windows\temp\usr.ps1
While the attackers commonly used Ntospy across the affected organizations, the Mimilite tool and the Agent Racoon malware have only been found in nonprofit and government-related organizations’ environments.
After each attack session, the threat actor leveraged cleanmgr.exe to clean up the environment used during the session.
Gaining Access to Credentials with Ntospy
To perform credential theft, the threat actor used a custom DLL module implementing a Network Provider. A Network Provider module is a DLL component implementing the interface provided by Microsoft to support additional types of network protocols during the authentication process.
Due to the file naming patterns of the DLL module, and as a reference to the previous research and tools, Unit 42 researchers named this malware family Ntospy. The threat actor registers the Ntospy DLL module as a Network Provider module to hijack the authentication process, to get access to the user credentials every time the victim attempts to authenticate to the system.
Figure 1 illustrates the path of the processes the malware used during the authentication process to load the malicious DLL module in an MS Exchange Server environment.
Figure 1. Image path of processes loading the malicious DLL component in an MS Exchange environment.
The threat actor’s implementation of this technique has some unique features. They created different versions of the Ntospy malware over the time frame we observed. They all share similarities, such as the following:
Using filenames with Microsoft patch patterns.
.msu extensions pretending to be Microsoft Update Package files to store the received credentials in cleartext.
RichPE header hashes that link different samples to the same compilation environment.
To install the DLL module, the threat actor registers a new Network Provider called credman. They do so by using an installation script found at C:\Windows\Temp\install.bat that installs the Network Provider by using reg.exe. The malware then sets the DLL module path by pointing to the malicious DLL module c:\windows\system32\ntoskrnl.dll.
Figure 2 shows static commonalities across the different DLL modules we identified as belonging to the same malware family. The image also illustrates that there are overlaps on the RichPE header hash as well as the PE sections of the samples.
Figure 2. Graph of static features relation across samples.
In the group of samples with the same RichPE header hash, we saw that they had been compiled using the same environment. In this case, that was Visual Studio 2019 v16.0.0 build 27508. Other samples of the malware family have been compiled on different environments or even tweaked to avoid overlapping.
The samples that don’t share the same build environment are actually similar in behavior, but they have some differences in implementation. For instance, some of the malware samples contain the file path used to store the credentials hard-coded in plain text. Figures 3 and 4 show how others use an encrypted file path and stack strings.
Figure 3. Pseudocode showing the hard-coded file path in cleartext.Figure 4. Pseudocode showing the file path encrypted with a stream cipher.
Decrypting the file path at runtime shows that the versions using an encrypted file path also use the same file path pattern, as shown in Figure 5.
Figure 5. File path decrypted at runtime.
All the DLL modules we identified use the same file path pattern, abusing the .msu file extension to masquerade as a Microsoft Update Package. The following paths are used by the malware samples:
Also, the DLL files are stored in the following file paths:
C:\Windows\System32\ntoskrnl.dll
C:\Windows\Temp\ntoskrnl.dll
C:\Windows\Temp\ntos.dll
While the first file path is the one used to actually install the Network Provider module, the Temp directory is the working directory used by the threat actor to temporarily store the DLL modules. As shown in the file paths above, the threat actor used Windows binary name patterns (based on the Windows system file named ntoskrnl.exe) in an attempt to trick victims and analysts into overlooking the malicious DLL component.
The first activity is identified with the malware sample with the file hash SHA256 bcd2bdea2bfecd09e258b8777e3825c4a1d98af220e7b045ee7b6c30bf19d6df. This overlaps with another threat activity cluster that we call CL-STA-0043, originally published in June 2023.
Credentials Dumping Through Mimilite
Another tool used for gathering credentials and sensitive information is a customized version of the well-known Mimikatz tool that, according to references within the sample, the threat actor calls Mimilite.
The tool is a reduced version of Mimikatz, which needs to be given a password through the command line to run:
1
C:\temp\update.exe1dsfjlosdf23dsfdfr
When the binary is executed, it takes the command-line argument as a decryption key to decrypt the actual payload using a stream cipher. Before executing the decrypted payload, the binary verifies that the payload has been successfully decrypted with the right key by performing an integrity check. This check is done by comparing the MD5 hash of the decrypted payload with the hard-coded value b855dfde7f778f99a3724802715a0baa, as shown in the code snippet in Figure 6.
Figure 6. Execution logic.
When executed properly, the tool dumps the credentials to the file path C:\Windows\Temp\KB200812134.txt. This choice of filename is another attempt by the threat actors to masquerade as a Microsoft update.
The Mimilite sample was found at C:\temp\update.exe with the file hash SHA256 3490ba26a75b6fb295256d077e0dbc13e4e32f9fd4e91fb35692dbf64c923c98. It was first uploaded to VirusTotal on 2020-05-11 05:43:00 UTC and first identified in the wild on 2021-02-12 21:54:35 UTC. What we find interesting is that according to VirusTotal, this sample has been uploaded and discovered in the wild using the following path and filename:
The elements of this path might suggest that the same binary has been involved in some sort of research that the uploader believed was linked with nation-state actors.
Agent Racoon Backdoor
The Agent Racoon malware family is built to provide backdoor capabilities. It is written using the .NET framework, and leverages DNS to establish a covert channel with the C2 server. Unit 42 researchers named the malware family Agent Racoon due to some references found within the code of the identified samples, as shown in Figure 7.
Figure 7. .NET Project details.
When executed, the threat has some predefined settings such as:
The base domain used to create the DNS covert channel
A unique key per sample, used as a seed to generate an encryption password to encrypt the DNS communication
A fallback DNS server if no DNS server can be read from the compromised system
All the C2 domains identified fulfill the same base pattern, with unique values for the four character identifier across different samples:
[4 characters].telemetry.[domain].com
The value of Program.dns_ip is different for each sample found, which could indicate that the threat actor is building the binary with specific settings gathered from the targeted environment.
Figure 8. Main function of the malware sample.
With that pattern, the threat communicates with the C2 server by adding additional subdomains to build the DNS query. It uses Internationalizing Domain Names for Applications’ (IDNA) domain names with Punycode encoding. This encoding type is a representation of Unicode values over the ASCII encoding for internet hostnames.
The screenshot from Wireshark in Figure 9 illustrates a complete DNS query:
Figure 9. Sample DNS query.
To manage the communication with the C2 server, the malware uses a communication loop shown in Figure 10.
Figure 10. Communication loop.
The following are some main features of the communication loop above:
The communication loop finishes when the answer xn--cc is received from the C2 server, or a communication error occurs.
The randomized delay between messages can have multiple reasons:
To avoid network spikes.
To avoid potential network congestion.
To provide randomness as an attempt to avoid network beaconing detection.
The encryption of all the communication messages through Program.Util.RC.
The encryption routine implements a stream cipher that takes the initial unique key per sample Program.key (this.defaultkey), as shown in Figure 11. It then creates a 1-byte encryption key to later encrypt the message with an XOR.
Figure 11. Stream cipher routine.
Depending on the length of the message sent to the C2 server, different subdomains are added to the query, as shown in the code snippet in Figure 12.
Figure 12. Partial request crafting.
The this.Rand() component of the fully qualified domain name (FQDN) build is intended to avoid caching and ensure the request reaches out to the C2 server.
Agent Racoon provides the following backdoor functionality:
Command execution
File uploading
File downloading
Although Agent Racoon does not provide any sort of persistence mechanism by itself, during the activity we observed, the threat was executed by using scheduled tasks.
Unit 42 researchers discovered the following samples using different subdomains of telemetry.geoinfocdn[.]com, as shown in Figure 13. The domain geoinfocdn[.]com was registered on 2022/08/19 UTC for one year.
Figure 13. Samples linked with file path and base C2 domain.
Unit 42 researchers were able to track the Agent Racoon malware family back to July 2022. Two samples of the malware family were uploaded to VirusTotal from Egypt and Thailand in September 2022 and July 2022 with the following SHA256 hashes:
These two samples used the same subdomain patterns, but this time the domain used for C2 was telemetry.geostatcdn[.]com. Threat actors performed the following activities regarding this domain on the dates shown:
Registered: 2020/08/27 UTC
First seen in the wild: 2021/06/17 23:10:58 UTC
Renewed: 2021/08/18 UTC
Expired: 2022/08/27 UTC
Figure 14 shows that with this information, two groups of malware samples can be identified using different C2 domain names and file paths since 2020.
Figure 14. Malware samples identified.
The threat actor tried to disguise the Agent Racoon binary as Google Update and MS OneDrive Updater binaries.
The malware developers made small modifications to the source code in an attempt to evade detection. Some samples used a domain hard-coded in plain text to establish the DNS covert channel (as shown in Figure 15), whereas other samples used a Base64 encoded string.
Figure 15. Base64 encoded C2 domain.
Aside from the Base64 feature, the differences are in the settings and not in the actual source code, except for the sample with SHA256 hash 354048e6006ec9625e3e5e3056790afe018e70da916c2c1a9cb4499f83888a47.
This sample has a compilation timestamp that was modified and is outside the time frame of activity: 2075/02/23 08:12:59 UTC.
As shown in Figure 16, the threat actor also tried to obfuscate the constant cmd.exe to avoid signature-based detections. They did so by using the equivalent Base64 encoded value with the added constant 399 so the equivalent Base64 encoded string can’t be detected through signatures.
Figure 16. Obfuscated cmd.exe pattern.
Data Exfiltration
Unit 42 researchers also identified the collection and successful exfiltration of confidential information, such as emails from MS Exchange environments, using PowerShell snap-ins to dump the emails.
In the search criteria from the command above, the threat actor used similar commands to search through different folders, mailboxes and dates to dump those emails.
After dumping the emails, the threat actor tried to compress the .pst file with a command-line RAR tool before exfiltrating it:
However, the threat actor canceled the attempt to compress the .pst file by using the tool taskkill.exe approximately eight minutes later.
Eventually the threat actor discarded the usage of raren.exe and simply renamed the .pst file, moving it to the IIS root directory and mimicking an error log in a compressed file to download it through the web server.
And finally, the ai.pst file is removed.
This process is repeated for several mailboxes with different search criteria.
In addition to the email exfiltration, Unit 42 researchers identified exfiltration of the victim’s Roaming Profile. A Roaming Profile is used to serve the same profile to the user when logging in from different computers from the same Active Directory environment.
To exfiltrate this, the threat actor compressed the directory by using the standalone version of the 7-Zip tool (which they dropped into the system using certutil.exe), and split the compressed file into chunks of 100 MB.
Later, following the same procedure, the threat actor exfiltrated the content.
Conclusion
Our hope in sharing the descriptions of this tool set is that readers can use this information to search their networks to identify other possible attacks using these tools. This tool set is not yet associated with a specific threat actor, and not entirely limited to a single cluster or campaign.
As mentioned at the beginning of this article, we found an overlapping Ntospy sample with SHA256 bcd2bdea2bfecd09e258b8777e3825c4a1d98af220e7b045ee7b6c30bf19d6df with a previously identified threat activity cluster CL-STA-0043. However, the overlaps are not limited to that sample.
We have also identified two compromised organizations in common across both activity clusters. Some of the TTPs match on both clusters, such as the MS Exchange PowerShell snap-ins and one of the Network Provider DLL modules.
Unit 42 researchers believe this threat activity cluster aligns with medium confidence to nation-state related threat actors for the following reasons:
The detection and defense evasion techniques used
The exfiltration activity observed
The victimology
The customization level of the tools used
The TTPs observed
Palo Alto Networks customers receive protections from the threats discussed above through the following products:
Cortex XDR includes detections and protections related to the IoCs shared in this research
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the IoCs shared in this research
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 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.
MITRE ATT&CK Mapping
During the research activity related to the tool set uncovered on this blog, Unit 42 researchers identified a set of TTPs, which we’ve mapped to the MITRE ATT&CK matrix in the table below.
ID
Name
T1003
OS Credential Dumping
T1018
Remote System Discovery
T1021.006
Remote Services: Windows Remote Management
T1027.009
Obfuscated Files or Information: Embedded Payloads
T1030
Data Transfer Size Limits
T1036.005
Masquerading: Match Legitimate Name or Location
T1036.008
Masquerading: Masquerade File Type
T1041
Exfiltration Over C2 Channel
T1046
Network Service Discovery
T1047
Windows Management Instrumentation
T1053.005
Scheduled Task/Job: Scheduled Task
T1059.001
Command and Scripting Interpreter: PowerShell
T1059.003
Command and Scripting Interpreter: Windows Command Shell
Unit 42 researchers discovered a security risk in the Google Workspace (formerly known as G Suite) domain-wide delegation feature. We exposed an unexpected way to gain access to the Google Workspace domain data from Google Cloud Platform (GCP).
We found that a GCP identity with the necessary permission can generate an access token to a delegated user. A malicious insider or an external attacker with stolen credentials can use this access token to impersonate Google Workspace users, granting unauthorized access to their data or to perform operations on their behalf.
In this article, we will highlight the risk of the Google Workspace domain-wide delegation feature. In doing so, we will explore its potential misuse by malicious actors and examine the implications for the security of Google Workspace data.
As organizations increasingly rely on the power of cloud-based services like Google Workspace and Google Cloud Platform GCP, it becomes crucial to delve into the intricacies of their security features and vulnerabilities. We will discuss the link between GCP and Google Workspace and examine how the GCP permission model can impact the security of Google Workspace.
Palo Alto Networks customers receive protection from the issue discussed in this article through Cortex XDR and Prisma Cloud.
A possible attack path shown in Figure 1 could be a malicious insider (e.g., a developer with editor permissions in a GCP project) exploiting their access. They could do so by abusing a service account that is granted domain-wide delegation permissions in Google Workspace. The insider has permission to generate access tokens to service accounts within the same GCP project.
Figure 1. Second attack scenario.
With the domain-wide delegation permissions enabled, a malicious insider can impersonate users in the Google Workspace domain and use the access tokens to authenticate API requests. By leveraging the appropriate scopes and API access, the insider can access and retrieve sensitive Google Workspace data, potentially compromising emails, documents and other confidential information stored within the domain. Such actions highlight the threats of the domain-wide delegation feature.
A worst case scenario would come about if an attacker has obtained a GCP service account token attached to a compute engine instance (e.g., the compute engine default service account, which has editor permissions by default). From there, the attacker may be able to exploit the domain-wide delegation feature for larger impact. If in the same project, a service account with domain-wide delegation exists, this can lead the attacker to impersonate the delegated service account and move laterally from GCP to gain access to the Google Workspace environment.
Google Workspace
Before we delve into the intricacies of a recent security risk that surfaced within Google Workspace and GCP, it is crucial to establish a solid foundation of understanding about these powerful cloud-based services.
Google Workspace apps are a collection of cloud-based collaboration tools. Organizations use Google Workspace to enhance their productivity and communication through various tools such as the following:
Email
Calendar
File storage and sharing
Team communication
Workflow automation
Security
Administration
Google Workspace provides role-based access control (RBAC) capabilities and allows administrators to assign specific roles to users, granting them predefined sets of permissions based on their responsibilities and needs. These roles include the following:
Super admin
Groups admin
User management admin
Each role has specific privileges and controls over different aspects of the organization's Google Workspace environment. The Google Workspace super admin holds elevated permissions and broader domain management responsibilities, including the ability to grant domain-wide delegation permission to service accounts, which we will explore in more detail later.
Google Workspace administrators can also define application-specific permissions and restrict sharing and visibility settings. For example, an administrator can enforce policies that prevent users from publicly sharing files and limit sharing options to ensure files remain within authorized boundaries.
A common use case for a link between GCP and Google Workspace is when an application hosted on GCP needs to interact with one of the Google Workspace services. These services include the following:
Gmail
Calendar
Drive
Docs
This integration allows the application to access and manipulate user-specific data, perform actions on behalf of users, or leverage the collaboration and productivity features of Google Workspace.
A delegated GCP service account is required to create an application that interacts with Google services, accesses Google APIs, handles users' data or performs actions on their behalf.
What Is a Service Account?
A service account is a special type of account in GCP that represents nonhuman entities, such as applications or virtual machines. It allows them to authenticate and interact with Google APIs. A service account is associated with the application itself rather than an individual end user.
Service accounts are not members of your Google Workspace domain, unlike user accounts. They aren't subject to domain policies set by Google Workspace administrators and can only access users' data if they are granted domain-wide delegation.
What Is Domain-Wide Delegation?
Domain-wide delegation is a feature in Google Workspace that allows GCP service accounts to access Google Workspace users' data and to act on their behalf within a specific domain.
When using the domain-wide delegation feature, applications can act on behalf of users in a Google Workspace domain without requiring individual users to authenticate and authorize the application.
Only a Google Workspace super admin can authorize an application, acting as the service account, to access data on behalf of users in a domain. This authorization is called “delegating domain-wide authority" to a service account.
How Does Domain-Wide Delegation Work?
To use the domain-wide delegation feature, the following steps (shown in Figure 2) are required:
Enabling Domain-Wide Delegation: The Google Workspace super admin grants domain-wide delegation for a service account, along with a set of OAuth scopes allowed for that access. These scopes detail which specific services and specific actions the service account will have access to. For example, if just the scope /auth/gmail.readonly is granted, the service account will have access to read a user’s Gmail messages when acting on behalf of that user, but not their other Workspace data such as access to files in Drive.
Requesting Google Workspace Access Token: The application sends a request to the Google Workspace token endpoint with the appropriate credentials. This includes the service account's client ID and client secret, as well as the desired scopes for accessing the user data. If the request is valid and the service account has been granted the necessary domain-wide delegation privileges, the token endpoint responds with an access token. The application can use this access token to access user data across the domain within the limits of the scopes requested.
API Access: The application includes the access token in API requests as an authorization header, and it acts as proof of authentication and authorization on behalf of the service account.
Figure 2. Domain-wide delegation flow.
When granted domain-wide delegation, a service account in Google Workspace can access user data, act on their behalf and authenticate requests to Google APIs. The specific capabilities and data accessible depend on the defined scopes.
Understanding the Risks and Implications of the Domain-Wide Delegation Feature
Once the domain-wide delegation is granted to a GCP service account, a GCP identity with the necessary permission can generate an access token to a delegated service account in the same project. A malicious insider can then use this access token to impersonate Google Workspace users, granting unauthorized access to the users' data or performing operations on their behalf.
This scenario creates a mismatch between the sensitivity of the domain-wide delegation permission and the permission model managed on the GCP platform.
Google documentation includes a cautionary notice concerning the domain-wide delegation feature, which outlines the significant capabilities of this feature. Google mentions that, “For this reason, only super admins can manage domain-wide delegation, and they must specify each API scope that the app can access.”
Using Audit Logs From Both Ends to Identify Potential Misuse
It is impossible to understand the complete picture of the activity and identify any potential misuse of the domain-wide delegation feature without analyzing the audit logs from both platforms, GCP and Google Workspace. The generation of a service account key log will appear in GCP logs while Google key generation and API call execution logs will appear in Google Workspace logs.
In Figure 3, there is an XQL query from the Cortex web interface that is searching for service account key creation in GCP audit logs.
Figure 3. Searching for service account key creation.Figure 4. Equivalent query in Prisma Cloud RQL syntax.
Figure 5 shows an XQL query that searches for the service account authorization log.
Figure 5. Searching for the Google Workspace access token request.Figure 6. Equivalent query in Prisma Cloud RQL syntax.
Figure 7 shows we checked who gave this service account domain-wide delegation permission and when that happened.
Figure 7. Searching for the log that indicates that domain-wide delegation permissions were granted to a service account.Figure 8. Equivalent query in Prisma Cloud RQL syntax.
Figure 9 shows the alert “A Google Workspace admin has enabled domain-wide delegation to a GCP service account and granted him access to a sensitive scope” was triggered in the Cortex web interface.
Figure 9. Domain-wide delegation alert in the Cortex web interface.
Mitigation
The security risk we have identified lies in the mismatch between the initial permissions necessary for a malicious insider to misuse the domain-wide delegation feature and the potential impact.
Optimal security practices for service accounts with domain delegation permissions are to position them within a higher-level folder in the GCP hierarchy. In the GCP hierarchy model, access control is hierarchical.
Permissions and policies set at a higher level (e.g., organization or folder) do not automatically grant access to lower-level folders or projects. Access control is not inherited downward in the hierarchy, meaning that lower-level folders or projects do not have automatic access to higher-level ones.
Figure 10. GCP resource hierarchy tree
This strategy reduces the surface area for security breaches by potential malicious insiders who would normally only have permissions within lower-level folders or projects within the GCP hierarchy shown in Figure 10. You can stop entities in lower-level areas from getting the service account's access tokens by making sure that only entities in the same or higher-level folders or projects can generate access tokens to the delegated service account. This helps prevent the misuse of domain-wide delegation permissions and prevents access to Google Workspace data.
Conclusion
We’ve been discussing this issue with Google through a variety of contact points since June 2023. This issue was also identified by Team Axon, which they have also reported to Google.
There are risks and implications associated with the domain-wide delegation feature that security defenders need to consider when configuring this permission. Depending on the scope that was granted with the domain-wide delegation, an attacker can use the feature to impersonate Google Workspace users, perform actions on their behalf and gain unauthorized access to their data.
It’s important to highlight the mismatch between the initial permissions required for the attacker to misuse this feature, and the possible impact. In worst cases, an attacker or a malicious insider can leak sensitive Google Workspace data, such as emails, documents, and other confidential information stored within the domain.
Palo Alto Networks customers receive protection from the issue discussed in this article through both Cortex XDR and Prisma Cloud.
Cortex XDR capabilities can identify and alert on various abnormal activities such as the granting of domain wide delegation permissions or the creation of GCP service account keys. Cortex XDR is able to learn the behavior of GCP and Google Workspace entities and detect unusual behavior.
Prisma Cloud CIEM can help mitigate risky and over-privileged access by providing:
Visibility, alerting, and automated remediation on risky permissions
Automatic findings of unused permissions with Least-privilege access remediations
Prisma Cloud Threat Detection capabilities can alert on various identity-related anomalous activities such as unusual usage of credentials from inside or outside of the cloud.
Prisma Cloud can also perform runtime operation monitoring and provide governance, risk and compliance (GRC) requirements for any component associated with their cloud environment.
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 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.
Disclosure Timeline
June 27, 2023: Palo Alto Networks submitted a report about the domain-wide delegation security risk to the Google Workspace product team.
July 10, 2023: Security discussion between Google Workspace product team and Palo Alto Networks cloud research group.
July 18, 2023: Palo Alto Networks submitted a report to the Google Vulnerability Reward Program regarding this issue.
Aug. 2, 2023: Palo Alto Networks filed a bug with the Google Workspace product team and they replied that they would implement a fix if required.
August 2023: Palo Alto Networks notified Google of the intention to publish on the security risk and offered the opportunity for fixes or input.
Nov. 8, 2023: Palo Alto Networks invited Google’s input on our article on the domain-wide delegation security risk.
Unit 42 researchers recently discovered two separate campaigns targeting job-seeking activities linked to state-sponsored threat actors associated with the Democratic People’s Republic of Korea (DPRK), commonly known as North Korea. We call the first campaign “Contagious Interview,” where threat actors pose as employers (often anonymously or with vague identities) to lure software developers into installing malware through the interview process. This malware creates the potential for various types of theft. We attribute with moderate confidence that Contagious Interview is run by a North Korea state-sponsored threat actor.
We call the second campaign “Wagemole,” where threat actors seek unauthorized employment with organizations based in the US and other parts of the world, with potential for both financial gain and espionage. We attribute with high confidence that Wagemole is a North Korea state-sponsored threat. Activity from both campaigns remains an ongoing active threat.
We nicknamed the first campaign Contagious Interview because the threat actor attempts to infect software developers with malware through a fictitious job interview. We originally discovered Contagious Interview through customer telemetry, and our research indicates it started as early as December 2022. Some of the infrastructure supporting this campaign remains active, and this activity remains a consistent threat. The first campaign's objective is likely cryptocurrency theft and using compromised targets as a staging environment for additional attacks. We track Contagious Interview as CL-STA-0240.
While pivoting on indicators from Contagious Interview, we discovered exposed files on a different threat actor-controlled infrastructure. These files indicate fraudulent job-seeking activity targeting a wide variety of United States (US) companies. This trove of information includes resumes with different technical skill sets and multiple identities impersonating individuals from various nations. It also includes common job interview questions and answers, scripts for interviews and downloaded job postings from US companies. We call this separate campaign "Wagemole" and track it as CL-STA-0241.
During our investigation of Contagious Interview, we discovered two new families of malware we named BeaverTail and InvisibleFerret. BeaverTail is JavaScript-based malware hidden inside Node Package Manager (NPM) packages. InvisibleFerret is a simple but powerful Python-based backdoor. Both are cross-platform malware that can run on Windows, Linux and macOS.
This article provides an overview of these two campaigns, and we examine the two new malware families, BeaverTail and InvisibleFerret.
This article also provides insight on how these threat actors are both seeking jobs and targeting job seekers to accomplish their goals. We provide recommendations for both job applicants and employers to consider when interviewing or applying for remote jobs.
For example:
Don’t use company-issued computers for personal activities.
Be wary of GitHub accounts with few repositories or updates.
Confirm the legitimacy of companies you’re applying for.
While investigating our telemetry, we discovered suspicious activity as early as March 2023 related to previously unidentified malware samples. Our investigation revealed two new malware families, and tactics used in this campaign align with previously reported activity by North Korean threat actors, as noted in our Attribution section. We track this campaign as Contagious Interview or CL-STA-0240, and infrastructure for this campaign was established as early as December 2022.
Through advertisements on job search platforms, the threat actor behind CL-STA-0240 targets software developers by posing as a prospective employer. The advertisements we can tie to this campaign are often anonymous or purposefully vague, with no real indicator of the employer they represent. Based on some of the file names of malware associated with this campaign, we believe this threat actor might also impersonate legitimate AI, cryptocurrency and NFT-related companies or recruitment agencies. Like other threat actors, this threat actor could also reach potential victims through email, social media platforms, or chat channels on community forums used by software developers.
After establishing contact, the threat actor invites the victim to participate in an online interview. The threat actor likely uses video conferencing or other online collaboration tools for the interview.
During the interview, the threat actor convinces the victim to download and install an NPM-based package hosted on GitHub. The threat actor likely presents the package to the victim as software to review or analyze, but it actually contains malicious JavaScript designed to infect the victim’s host with backdoor malware.
Below, Figure 1 summarizes the chain of events for CL-STA-0240.
Figure 1. Simplified chain of events for a CL-STA-0240 attack.
To better understand this chain of events, we should first understand how the threat actor abused GitHub for this campaign.
GitHub Abuse for Contagious Interview
Designed as a collaborative space for software developers, GitHub is attractive to many developers because its basic service option is free. This also makes GitHub attractive to criminals. The threat actor behind Contagious Interview is one of many criminals who have used GitHub’s free service plan to host innocent-looking repositories and use them as powerful tools for compromise.
The threat actor behind Contagious Interview created different identities to host a number of GitHub repositories, establishing an infrastructure to inspire trust by its intended victims. However, a closer examination reveals that these GitHub repositories are not as trustworthy as they might initially appear.
The free GitHub accounts used for Contagious Interview have only one repository that is not updated, while many legitimate software developers host multiple repositories with several updates.
Further examination of suspicious repositories found during our investigation confirmed our initial assessment. A GitHub repository’s Issues section often provides clues.
Below, Figure 2 shows comments in the Issues section of a repository used in Contagious Interview. The repository named react-ecommerce was established under a GitHub user account named brainjobs35. This repository and account are no longer active.
Figure 2. User comments in the Issues section of a suspicious GitHub repository.
GitHub’s Insights feature also provides clues. Below Figure 3 shows GitHub users commenting through the Insights feature about a malicious file named ServiceWorker.js related to the Contagious Interview campaign.
Figure 3. Comments on GitHub Insights related to Contagious Interview.
NPM, Open Source and Supply Chain Attacks
Software developers increasingly rely on third-party packages and libraries to streamline their projects. These provide an avenue for supply chain attacks. Among these packages, NPM is a central hub for countless projects using JavaScript, with 17 million developers worldwide according to the NPM website.
The open-source nature of NPM helps malicious actors find ways to inject harmful code in legitimate NPM packages and distribute these packages through GitHub. Once installed, these compromised NPM packages act as subtle backdoors, granting threat actors unauthorized access into targeted networks. GitHub and Phylum have recently reported similar attacks.
Malicious NPM packages help the threat actor elude most traditional detection techniques, because:
Most static and dynamic analysis detection engines cannot execute an NPM package in a Node.js runtime environment because this is not a supported file type.
Cloning a repository and running Node.js code is a normal, allowed operation in most software development teams that will not be considered suspicious.
As a result, malicious JavaScript files in these NPM packages have a low or zero detection rate when submitting to a service like VirusTotal.
Furthermore, NPM can be easily installed on multiple operating systems, allowing threat actors to maximize their attack surface when distributing a malicious NPM package.
The Act of Compromise
During the interview process, victims prepare their development environment. In the attacks we investigated, most developers used Visual Studio Code with a set of plugins like Code Helper, along with Git and Node.js extensions. This includes NPM.
After these basic system requirements are met, the threat actor asks the victim to install the malicious NPM package posing as legitimate software on GitHub. This malicious NPM package contains JavaScript for newly discovered malware we have named BeaverTail.
BeaverTail steals information, and it retrieves additional malware as its second-stage payload. This payload is a cross-platform backdoor we have named InvisibleFerret.
The next section provides analysis and insight into the loader, BeaverTail.
BeaverTail Analysis
Distributed as JavaScript inside NPM packages, BeaverTail serves two purposes.
Information stealer
Loader
As an information stealer, BeaverTail targets cryptocurrency wallets and credit card information stored in the victim’s web browsers. As a loader, BeaverTail retrieves and runs the next stage of malware, InvisibleFerret.
The BeaverTail JavaScript file inside an NPM package is heavily obfuscated to evade detection. The threat actor might upload an entire malicious NPM package to GitHub or they might also inject BeaverTail code into other developer’s legitimate NPM projects. Figure 4 shows an example of this injected script.
Figure 4. BeaverTail’s obfuscated JavaScript, injected into the NPM file of a legitimate developer’s project.
In addition to the heavily obfuscated code illustrated in Figure 4, the BeaverTail also requires human interaction to execute due to its dependency on the Node.js environment. These characteristics help the malware to evade detection.
Once the malicious NPM package is successfully installed on a Windows, Linux or macOS host, BeaverTail collects basic system information. This threat also searches the victim’s web browser for extensions associated with cryptocurrency wallets, like Binance and Coinbase. Table 1 shows the full list below.
Browser Extension ID
Browser Extension Name
Target Browser
fhbohimaelbohpjbbldcngcnapndodjp
Binance Wallet
Chrome
aeachknmefphepccionboohckonoeemg
Coin98 Wallet
Chrome
hnfanknocfeofbddgcijnmhnfnkdnaad
Coinbase Wallet
Chrome
hifafgmccdpekplomjjkcfgodnhcellj
Crypto.com Wallet
Chrome
nkbihfbeogaeaoehlefnkodbefgpgknn
Metamask Wallet
Chrome
ejbalbakoplchlghecdalmeeeajnimhm
MetaMask Wallet
Microsoft Edge
bfnaelmomeimhlpmgjnjophhpkkoljpa
Phantom Wallet
Chrome
fnjhmkhhmkbjkkabndcnnogagogbneec
Ronin Wallet
Chrome
ibnejdfjmmkpcnlpebklmnkoeoihofec
TRON Wallet
Chrome
Table 1. Browser extensions for cryptocurrency wallets BeaverTail searches for.
BeaverTail also checks for a Solana cryptocurrency wallet, searching for ~/.config/solana/id.json.
While performing data exfiltration and loading InvisibleFerret, BeaverTail generates the following web traffic as described below in Table 2.
URL Pattern
Description
Save Location
hxxp://<c2_server>:1224/keys
HTTP POST request sends data collected by BeaverTail
Not applicable
hxxp://<c2_server>:1224/uploads
HTTP POST request sends other collected information like Solana cryptocurrency wallet data
HTTP GET request for helper DLL files when decrypting credentials stored in Chrome, if needed
%USERPROFILE%\store.node
hxxp://<c2_server>:1224/pdown
HTTP GET request for Python executable and associated libraries
%TEMP%\p.zi or %HOMEPATH%\.pyp\
hxxp://<c2_server>:1224/client/<campaign_id>
HTTP GET request for InvisibleFerret
%HOMEPATH%\.npl or ~/.npl
Table 2. Infection traffic generated by BeaverTail malware.
At this stage, the threat actor has been able to successfully drop a silent, simple and cross-platform backdoor on the victim machine.
InvisibleFerret: A Cross-Platform Python Backdoor
InvisibleFerret is newly discovered malware retrieved and executed by BeaverTail NPM packages. Cross-platform malware written in Python, InvisibleFerret consists of various components with the following functions:
Fingerprinting
Remote control
Keylogging
Data exfiltration
Browser stealing capabilities
Downloading the AnyDesk client if required for additional control
Figure 5 presents a diagram that reveals the modular nature of InvisibleFerret, showing an initial script and two additional components that perform different functions.
Figure 5. Diagram revealing the initial script and two components of InvisibleFerret.
Initial Script
BeaverTail downloads the InvisibleFerret script using the URL structure from the final row in Table 2. An example of a URL to download InvisibleFerret follows:
hxxp://<c2_server>:1224/client/<campaign_id>
The initial script for InvisibleFerret is saved under the user’s home directory, named .npl and executed using Python. An example of the command line to run this file on a Windows host is:
The initial script for InvisibleFerret uses obfuscated data. An example is shown below in Figure 6.
Figure 6. Example of Python script for InvisibleFerret.
The bottom section of Figure 6 shows a decoding routine that is consistent across all script files used for InvisibleFerret and its components:
The first eight characters of the temp string represent a key for decoding.
The remainder of the temp string is converted from Base64.
The result is processed through an XOR loop using the eight character key.
This initial script installs the required Python modules using pip, and it also defines variables, establishing values to identify the command and control (C2) server and port.
The main objective of the initial script is to retrieve and run two different components of InvisibleFerret. These components are downloaded and saved as shown in Table 3.
Request for Component
Save Location
hxxp://<c2_server>:1224/payload/<campaign_id>
Local file path .n2/pay
http://<c2_server>:1224/bow/<campaign_id>
Local file path .n2/bow
Table 3. Infection traffic generated by BeaverTail malware.
Of note, the second component is only downloaded when the operating system is not macOS.
InvisibleFerret Components
The first component for InvisibleFerret collects system data to create a fingerprint, then sends this data to a C2 server. The first component collects:
Internal IP address
IP geolocation information
System information including OS version, release, host and user information
It sends this information to the server in JSON format.
The second component for InvisibleFerret deploys remote control and information stealing capabilities. Once executed, it prepares the environment by installing the following Python packages, if they are not already present on the system:
pyWinhook: Python wrapper for out-of-context input hooks in Windows that provides callbacks for global mouse and keyboard events.
pyperclip: Cross-platform Python module for copy and paste clipboard functions.
psutil: Cross-platform Python library for process and system monitoring.
InvisibleFerret establishes a connection with the C2 server over TCP traffic and periodically checks in and waits for further instructions. This traffic consists of JSON messages.
The infected host checks in using heartbeat messages with JSON content using code and args keys with a code value of 0 as illustrated below in Figure 7. This heartbeat message also contains a campaign identifier (sType) and the victim’s hostname (sHost).
Figure 7. Diagram for a heartbeat C2 message.
The C2 server returns JSON data instructing the backdoor with the next actions to take. The JSON response contains the same two main keys:
code: A value specifying an action or command
args: A string or JSON dictionaries with multiple key value pairs containing the required arguments for the specified command
InvisibleFerret implements a total of eight commands described below in Table 4.
Command
Description
ssh_cmd
Checks if the args value is equal to delete and if so, closes the session. To notify the C2 server, it sends the message string [close].
ssh_obj
Command execution. Extracts the command value from args['cmd'] and runs it. JSON results sent to the C2 server with code value 1 and args indicating the results.
ssh_clip
Send contents of keylogger buffer and clipboard data. Reports to C2 server with JSON code value 3 and args containing the collected data.
ssh_run
Downloads and runs the browser stealer component. Reports to C2 server with JSON code value 4 and args containing the file path for this component.
ssh_upload
Upload data to a C2 server. Subcommands include:
Upload all contents of a specific directory.
Upload specific files.
Upload files matching a given pattern looking recursively in a given folder.
Contents are uploaded to an actor-controlled FTP server, provided in the JSON response using the following args:
hn: FTP host.
un: Username.
pw: Password.
The logic contains exclusion lists for specific files and folders as well as a list of paths that are specifically uploaded when found. These paths show focus not only in documents (.xls, .doc, etc.) but also in cryptocurrency specific file paths (metamask, wallet, etc.).
While uploading contents, the backdoor keeps sending requests with JSON data with code value 5 and args value indicating the state of the upload.
ssh_kill
Kill Chrome and Brave browser processes. When done, send JSON with code value 6 and args value indicating these processes are terminated.
ssh_any
Download and run a malicious binary for AnyDesk. Before downloading AnyDesk, send JSON containing code value 7 and args value to indicate the victim’s OS.
ssh_env
Collect content specific folders (“Documents” and “Downloads” for Windows, /home and /Volumes for others) and upload these files to the FTP server.
Table 4. Commands for InvisibleFerret.
When InvisibleFerret finishes its tasks, it reports the results to the C2 server. This report uses the same JSON code and args parameters with specific values outlined above in Table 4.
Keylogger Functionality
InvisibleFerret also starts a keylogger to continually collect keyboard, mouse and clipboard data in a buffer that can be requested at any time from the C2 server using the command ssh_clip described above.
Browser Stealer Functionality
Based on Python, InvisibleFerret targets popular web browsers on Windows, Linux and macOS to steal login credentials and other sensitive data. This functionality includes retrieving a browser’s login data, decrypting the information and stealing the victim’s login credentials. InvisibleFerret can also retrieve credit card information used by the victim through a web browser.
After collecting this information, InvisibleFerret sends the data to a C2 server using the JSON format with various keys representing the content, as shown below in Figure 8.
Figure 8. JSON format used for sending stolen browser data.
Follow-Up Malware: AnyDesk
When the ssh_any command is received, InvisibleFerret downloads an additional script using the following URL pattern:
http://<c2_server>:1224/adc/<campaign_id>
This script is stored on the C2 server with the following filename:
any_<campaign_id>.py
InvisibleFerret stores the file on disk for execution under the following directory.
.n2/adc
This file uses the same obfuscation seen in other scripts used for InvisibleFerret.
This script retrieves an AnyDesk binary from the C2 server if it is not already present on the victim’s host. This process updates AnyDesk’s configuration and restarts the program if it was already running.
While pivoting on infrastructure associated with this Contagious Interview campaign, we discovered files used for a separate activity. We have nicknamed this separate campaign “Wagemole” and track it as CL-STA-0241.
CL-STA-0241: Wagemole
While pivoting on GitHub infrastructure associated with Contagious Interview (CL-STA-0240), we discovered files accidentally exposed on a GitHub repository on a different GitHub account. These files include:
Resumes with fake identities, impersonating individuals of various nationalities
Frequently asked job interview questions and answers
Self-introduction scripts including personal information of the impersonated identity
Copies of IT job opening posts from US companies
Scanned copy of a stolen US Permanent Resident Card
A list of unidentified account seller contacts
Timestamps on the files indicate this campaign started as early as August 2022, and the timestamps run through early December 2022. While we have not noticed further updates for this batch of files, this activity remains an ongoing threat.
These files indicate another campaign applying for remote IT jobs using fake identities, which we are calling Wagemole. Information from some of the documents indicate this threat actor is associated with North Korea. Resumes from these files indicate targets include a wide range of US companies and freelance job marketplaces. This activity is likely related to a recent report that North Korea uses remote workers to funnel wages to its weapons programs.
Below, Figure 9 shows one of the resumes.
Figure 9. Example of a resume from this infrastructure.
Each fake resume has a different US phone number for personal contact, specifically using Voice over Internet Protocol (VoIP) numbers. Some resumes include links to a LinkedIn profile and links to GitHub content. Figure 10 shows a GitHub repository one of the job seekers has maintained.
Figure 10. GitHub repository maintained by one of the fraudulent job seekers.
These GitHub accounts appear well maintained and have a lengthy activity history. These accounts indicate frequent code updates and socialization with other developers. As a result, these GitHub accounts are nearly indistinguishable from legitimate accounts.
A portion from one of the phone interview preparation scripts is shown below in Figure 11. This document indicates the target is a job that requires at least some on-site presence. As indicated in Figure 11, the job seeker claims to be based in the US and tells the interviewer they are currently out of the country visiting family overseas due to COVID but can start working remotely.
Figure 11. Part of the interview preparation script.These documents are not limited to remote IT jobs at US-based companies. Some of the documents indicate this threat actor also seeks freelance jobs in multiple marketplaces, targeting a broader scale of global markets that include Africa.
These fraudulent job seekers have maintained multiple accounts for email, freelance websites, source code repositories and job agency platforms. As a tactic to win job bids and hide their true identity, these job seekers have also sought to purchase or borrow accounts with a high reputation in account seller marketplaces.
Figure 12 shows a message on a freelance job platform from one of the job seekers used in this campaign. Figure 13 shows message activity with an underground marketplace seeking to purchase or rent high reputation accounts on freelance job platforms.
Figure 12. Actor seeking work on a freelance job platform.Figure 13. Messages from an underground market for freelance platform accounts.
Among the copies of US job postings hosted on this infrastructure, the largest portion is for IT and recruiting. Jobs for IT services and solutions might provide the threat actor behind Wagemole additional opportunities for downstream supply chain attacks. Recruiting jobs could provide more personal identity materials such as job applicant IDs, resumes and other personal data that attackers could further use in the Wagemole campaign.
Attribution
The tactics, techniques and procedures (TTPs) observed in both Contagious Interview (CL-STA-0240) and Wagemole (CL-STA-0241) align with previous activity attributed to North Korea state-sponsored APTs. However, the confidence level of our attribution is different for the two campaigns.
For Wagemole activity, several of the documents we discovered contain information that more definitively points to North Korea. Many of the passwords associated with these documents were made through Korean language typed on a US keyboard, and some passwords include words only used in North Korea. Furthermore, Korean keyboard language settings were found on computers used by threat actors behind these campaigns.
These documents indicate similar activity as reported by numerous media outlets based on US government and FBI announcements.
For these reasons, we assess with high confidence that Wagemole can be attributed to a North Korea-sponsored APT, which we track as CL-STA-0241.
Contagious Interview also bears the hallmarks of a North Korean threat actor. For example, a North Korean group previously posed as job recruiters for Meta using similar tactics to infect job seekers with malware. Operation Dream Job run by the North Korean APT Lazarus Group reportedly used social media to trick victims into installing a trojanized VNC app as part of a fake job interview. North Korea-sponsored APT groups have often posed as job recruiters to infect potential victims with backdoor malware.
In the course of our research into Contagious Interview, we also observed indicators that the developer of BeaverTail and InvisibleFerret corresponded or collaborated with other GitHub accounts, where we found direct association with Wagemole. We track the threat actor behind Contagious Interview as CL-STA-0240, and attribute with moderate confidence that this is also a North Korea state-sponsored threat actor.
In light of this analysis, we attribute with a moderate level of confidence that both campaigns trace to North Korea state-sponsored threat actors.
Conclusion
Unit 42 researchers investigated suspicious activity from our telemetry and discovered these two campaigns, Contagious Interview and Wagemole, which we track as CL-STA-0240 and CL-STA-0241 respectively. In the process, we discovered two new malware families we have named BeaverTail and InvisibleFerret used in the Contagious Interview campaign.
Software developers are often the weakest link for supply chain attacks, and fraudulent job offers are an ongoing concern, so we expect continued activity from Contagious Interview. Furthermore, Wagemole represents an opportunity to embed insiders in targeted companies. We will continue to monitor our telemetry for further activity from these and other campaigns.
Recommendations and Protections
What is an effective strategy against these threats? For Contagious Interview and many other threats, software developers should not use a company-issued computer for personal or non-work related activities like job interviews. Personal activity on a company-issued computer can provide opportunities for threat actors to access a company's network through malware.
Developers should also be suspicious of GitHub accounts containing a single repository with little or no updates. Threat actors frequently abuse free services like GitHub to distribute malware. Also, no one should install unknown files from unverified sources on their work or home computers.
Job applicants should exercise due diligence to confirm the existence and legitimacy of companies offering job interviews, and also confirm that prospective interviewers actually work for the companies they claim to represent. It is also wise to be cautious of downloading and installing unusual types of communications software or of downloading software packages as a prerequisite for obtaining an interview.
For Wagemole, employers should thoroughly vet all job applicants. Fake identities are an increasing concern on job-related social media platforms, and threat actors can easily generate an alias for remote work. If in-person interviews are not an option, use teleconferencing to interview job applicants. Be aware of anyone who applies for an on-site job, states they are currently out of the area and then offers immediate availability for remote work. For remote-only roles, employers should be suspicious of anything that seems unusual with any job applicant during the hiring process.
Next-Generation Firewall with the Advanced Threat Prevention security subscription can help block the malware's C2 traffic with best practices via the following Threat Prevention signatures: 86817, 86818, 86819.
If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200
Palo Alto Networks has shared our findings 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
SHA256 hashes for files associated with BeaverTail:
Coinciding with these real-world events, Unit 42 researchers observed three Stately Taurus campaigns during the month of August. These campaigns are assessed to have targeted entities in the South Pacific including the Philippines government. The campaigns leveraged legitimate software including Solid PDF Creator and SmadavProtect (an Indonesian-based antivirus solution) to sideload malicious files. Threat actors also creatively configured the malware to impersonate legitimate Microsoft traffic for command and control (C2) connections.
Stately Taurus (aka Mustang Panda, Bronze President, Red Delta, Luminous Moth, Earth Preta and Camaro Dragon) has been operating since at least 2012. It is assessed to be a Chinese advanced persistent threat (APT) group that routinely conducts cyberespionage campaigns. This group has historically targeted government entities and nonprofits, as well as religious and other non-governmental organizations across North America, Europe and Asia.
Palo Alto Networks customers receive protection from the threats described in this article through Cortex XDR and WildFire malware analysis.
Unit 42 observed three Stately Taurus campaigns during the month of August.
Campaign 1
The first campaign was observed on Aug. 1, 2023, when we identified a Stately Taurus malware package that was hosted for download on Google Drive. Threat operators configured this malware package as a ZIP file named 230728 meeting minutes.zip. Upon extracting this archive, unsuspecting victims are presented with the view shown in Figure 1.
Figure 1. ZIP archive contents.
By default, victims are presented with a visible application (20230728 meeting minutes.exe) that contains a PDF icon. This file is in fact a legitimate copy of Solid PDF Creator software that has been renamed. However, what victims don’t see is that this folder contains a second hidden file named SolidPDFCreator.dll.
Any attempt to execute the legitimate Solid PDF Creator software will result in the side-loading of the malicious DLL contained in the same folder. Once loaded, the malicious DLL then establishes a connection with 45.121.146[.]113 to facilitate C2.
We assess that an entity associated with the Philippines government saw this first malware package as early as Aug. 1, 2023.
Campaign 2
We subsequently identified a second Stately Taurus malware campaign on Aug. 3, 2023. This malware package was configured as a ZIP file named NUG's Foreign Policy Strategy.zip. In this case, the acronym “NUG” is believed to be a reference to the National Unity Government of Myanmar. Upon extracting this archive, victims are presented with a view that is similar to the first campaign, which is shown in Figure 2.
Figure 2. ZIP archive contents.
Here we see a legitimate copy of Solid PDF Creator software that has been renamed as NUG’s Foreign Policy Strategy.exe. We also see the hidden SolidPDFCreator.dll file that is side-loaded when the application is launched. However, what is deceiving about this sample is that this ZIP file also contains additional files hidden in the path:
After traversing 11 folders named #, we identified three additional files, shown in Figure 3.
Figure 3. Contents of # folder.
In terms of process flow, upon executing the visible NUG’s Foreign Policy Strategy.exe binary, the threat side-loads SolidPDFCreator.dll. This DLL then copies these three files (errordetails, SmadavProtect32.exe and Smadhook32c.dll) to the victim's home directory and establishes a registry key (HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\AHealthDB) to call SmadavProtect32.exe when a user logs on.
SmadavProtect32.exe is a legitimate and benign copy of an Indonesian antivirus program called SmadAV. Upon login, SmadavProtect32.exe will load the malicious DLL (SmadHook32c.dll) and then the malware (errordetails) contained in the same folder. Once running, the malware is configured to call home to 45.121.146[.]113 for C2.
Campaign 3
The third campaign is structurally identical to the first campaign, and it was created on Aug. 16, 2023. However, the ZIP and EXE filenames use Labour Statement.zip instead of 230728 meeting minutes from the first example.
Upon extracting the contents of the ZIP file, victims are presented with two files. The first file, called Labour Statement.exe, is a benign copy of Solid PDF Creator software. The second file is a malicious DLL named SolidPDFCreator.dll. Following execution of the application, the malicious DLL is loaded, and it establishes a connection to 45.121.146[.]113 for C2 consistent with the previous two campaigns.
C2 Infrastructure
The IP address 45.121.146[.]113 was first associated with Stately Taurus during a series of campaigns launched in June 2023. We assess that the actors continued to leverage this infrastructure throughout the month of August 2023. However, one interesting aspect of the C2 activity is that the actors attempted to disguise it as legitimate Microsoft traffic, as shown in Figure 4.
Figure 4. Malware POST statement.
Specifically, in the POST statements the malware sets the host field to wcpstatic.microsoft[.]com despite the traffic being directed to an IP address in Malaysia that has no relation to any legitimate Microsoft services.
Additionally, in monitoring traffic associated with the C2 server, we identified multiple connections between Aug. 10 and Aug. 15, 2023, originating from Philippines government infrastructure. Given traffic to the known malicious C2 server, we assess a Philippines government entity was likely compromised during these campaigns, at least for the five-day period in August 2023.
Conclusion
During the month of August, Stately Taurus actors launched at least three campaigns targeting entities in the South Pacific. We assess that at least one of these campaigns directly targeted the Philippines government and that the actors were successful in their attempts to compromise a government entity for five days in August.
Stately Taurus continues to demonstrate its ability to conduct persistent cyberespionage operations as one of the most active Chinese APTs. These operations target a variety of entities globally that align with geopolitical topics of interest to the Chinese government. We encourage organizations to leverage our findings to inform the deployment of protective measures to defend against this threat group.
Protection Recommendations
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 can identify 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.
Protections and Mitigations
Palo Alto Networks customers receive protection from the threats discussed above through the following products:
Advanced WildFire cloud-delivered malware analysis service accurately identifies the malware described in this blog as malicious.
Cortex XDR prevents the execution of known malware and also prevents the execution on unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.
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 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.
During our analysis of a July 2023 campaign targeting groups supporting Ukraine's admission into NATO, we discovered a new vulnerability for bypassing Microsoft's Mark-of-the-Web (MotW) security feature. This activity has been attributed by the community to the pro-Russian APT group known as Storm-0978 (also known as the RomCom Group, in reference to their use of the RomCom backdoor). This group used a highly complex and well-developed exploit chain leveraging a remote code execution (RCE) vulnerability in Microsoft Office designated CVE-2023-36884 to infect its targets with malware.
Our investigation revealed a new exploit method related to CVE-2023-36884 that can bypass MotW. Microsoft awarded our team a bug bounty and assigned CVE-2023-36584 (CVSS score 5) to this new vulnerability discovered during our investigation.
The lure for these attacks is a weaponized Microsoft Word document disguised as talking points for attendees of the July 2023 NATO Summit discussing Ukraine’s entry into NATO. This article examines the file and provides technical insight into the attack’s exploit chain that has not yet been publicly discussed.
Palo Alto Networks customers receive protections from and mitigations for the threats discussed in this article. Cortex XDR and Prisma Cloud detect and prevent this exploit chain in its early and post-exploitation stages. Organizations can also engage the Unit 42 Incident Response team for specific assistance with this and other threats.
While monitoring Ukraine's threat landscape, our team observed an interesting Microsoft Word document (.docx file) first submitted to VirusTotal on July 3, 2023, named Overview_of_UWCs_UkraineInNATO_campaign.docx. The filename and content indicate it targeted participants at the July 2023 NATO Summit discussing Ukraine’s entry into NATO.
This activity has been attributed by the community to a pro-Russian APT group known as Storm-0978 (also known as the RomCom Group, in reference to their use of the RomCom backdoor). Below, Figure 1 shows a screenshot of this document.
Figure 1. Malicious Word document lure.
VirusTotal indicates this document was hosted at the following URL:
The above link indicates this document was most likely distributed through email, with the email text containing a link to the .docx file. The document’s creation date and the registration date of domain ukrainianworldcongress[.]info are both June 26, 2023. This timing suggests an email-based campaign with a link to the .docx file targeted organizations or individuals attending the July 2023 NATO Summit.
When the file was initially submitted to VirusTotal, 27 of the 62 AV engines identified it as malicious. While we found no evidence this lure was sent to any of our customers, we conducted in-depth analysis to ensure coverage of any associated vulnerabilities.
Our investigation revealed a new vulnerability for CVE-2023-36584. The next section of this article provides detailed technical analysis and fully explains each step of the full exploit chain.
Technical Analysis Leading to CVE-2023-36584
Our investigation starts with a closer examination of Overview_of_UWCs_UkraineInNATO_campaign.docx, then we review the remaining steps of this exploit chain in further detail.
A Closer Look at the Word Document
Microsoft Office documents have been a common attack method for criminals to distribute malware. In response to this threat, Microsoft implemented its MotW security feature that restricts various functions in Office documents from untrusted locations.
Windows identifies these files as high-risk. A file tagged with MotW generates a SmartScreen prompt indicating it is potentially dangerous.
In our .docx file, successful exploitation occurs when the Word document is not tagged as MotW, which causes Protected View to be disabled. We investigated this document to explore the full exploit chain that includes CVE-2023-36884.
To understand how CVE-2023-36884 was exploited by this specific lure, we should first understand Microsoft Word’s implementation of the Open XML file format, in this case for MS-DOCX (.docx) files.
An MS-DOCX file is a compressed ZIP archive containing multiple specification files used to display the Word document. One of those is an XML file at word/document.xml. This is the core XML component of an MS-DOCX file, and it contains the document’s text and formatting.
When viewing an MS-DOCX file in Microsoft Word, much of the document's content is imported by word/document.xml.
In our .docx lure, word/document.xml imports content using the Anchor for Imported External Content element known as altChunk, shown below in Figure 2.
Figure 2. Snippet from word/document.xml.
This altChunk element can import content that uses another format, such as Rich Text Format (RTF). As shown above in Figure 2, word/document.xml from our .docx file has an altChunk element that indicates a relationship (r) to external content using the identifier AltChunkId5. This identifier is defined in a relationship file at word/_rels/document.xml.rels.
Figure 3. Snippet from word/_rels/document.xml.rels.
The snippet of document.xml.rels shown above in Figure 3 identifies the imported target as a file at word/afchunk.rtf.
The RTF file afchunk.rtf contains two malicious Object Linking and Embedding (OLE) objects. The first OLE object uses type OLE autolink set with the objautlink RTF control word. After the objautlink control word, an objupdate control word forces the objects to update before they are displayed, as noted below in Figure 4.
Figure 4. objautlink snippet from word/afchunk.rtf.
As shown above in Figure 4, the object class is defined as Word.Document.8, and its data contains the LinkedObject structure in its header followed by ASCII text representing hexadecimal characters.
We used Didier Steven’s rtfdump.py tool to further inspect afchunk.rtf. Below, Figure 5 shows hexadecimal (hex) output of the objautlink snippet shown previously in Figure 4. This output more clearly shows the LinkedObject structure.
Figure 5. rtfdump.py output for first malicious OLE object.
This hex dump reveals \\104.234.239[.]26\share1\MSHTML_C7\file001.url, a malicious URL that uses the Server Messenger Block (SMB) protocol.
Using rtfdump.py to review afchunk.rtf, we found another malicious OLE object using the xmlfile class, and its header contains the EmbeddedObject structure. The embedded object is a compound document that contains a URLMoniker that loads an XML file from the URL hxxp://74.50.94[.]156/MSHTML_C7/start.xml, noted in blue in Figure 6 below.
Figure 6. rtfdump.py output for the second malicious OLE object.
First Stage of the Exploit Chain
Initial research on this exploit chain resulted in a flow chart created by @zcracgaand shared by @r00tbsd on July 12, 2023 (Figure 7). This flow chart is helpful to visualize the different stages as we work our way through the exploit chain.
Figure 7. Flow chart of the exploit chain. Source: @r00tbsd post, designed by @zcracga.
Our initial area of concern is two URLs from the malicious OLE objects in afchunk.rtf. As noted previously, these OLE objects request content from the following URLs:
\\104.234.239[.]26\share1\MSHTML_C7\file001.url
hxxp://74.50.94[.]156/MSHTML_C7/start.xml
When a Windows client connects to an SMB server, that client sends Windows NT LAN Manager (NTLM) credentials for authentication. Because of this, when the victim host accesses the URL at \\104.234.239[.]26\share1\MSHTML_C7\file001.url, it leaks the victim's NTLM credentials along with its hostname and username to the attacker-controlled SMB server. The collected information is later used in the attack chain.
Figure 8 reveals HTML code embedded inside file001.url.
Figure 8. Snippet from file001.url.
Examining file001.url, the UName variable contains the victim’s username. This is the username collected by the attacker-controlled SMB server from the victim’s leaked NTLM credentials. If variable d shown above in Figure 8 is not empty, the exploit chain concatenates the username with an attacker-passed value that is used to create a path to the CHM file named 2222.chm contained in a file named file001.zip.
At this stage in the exploit chain, 2222.chm doesn’t exist, or it could be part of some other exploit used by the attackers. Further behaviors of file001.url will be explained later, as it closely relates to 2222.chm.
The second malicious OLE object in afchunk.rtf retrieves a file from hxxp://74.50.94[.]156/MSHTML_C7/start.xml. This start.xml file contains an iframe to load another file named RFile.asp, from the same server and directory path. Below, Figure 9 shows the iframe snippet from start.xml referencing RFile.asp.
Figure 9. Snippet from start.xml.
RFile.asp is responsible for loading another file with an attack-specific path on the server defined as:
This path is assembled from the victim’s public IP address for <ip> and a five-digit identifier for <id>. We refer to this file as file001.htm.
Figure 10. Snippet from RFile.asp.
Abusing the Windows Search Handler
The core behavior of file001.htm is the execution of JavaScript as seen below from the code snippet in Figure 11.
Figure 11. Snippet from file001.htm.
JavaScript from file001.htm uses iframes to load several files. It first loads a saved search file with a filename consisting of the victim’s IP address and five-digit identifier that ends with the string file001.search-ms. We will refer to this file as the last part of its filename, file001.search-ms.
This is followed by three HTTP requests using the string .zip_k* in their URLs. This behavior has no apparent value besides performing a timing or no-op operation.
Finally, MSHTML re-loads file001.search-ms and then loads redir_obj.htm.
The order of these requests stands out, because the intended purpose is not immediately apparent. Based on the timestamps from an example of the associated network traffic, we speculated this order of events achieved a bypass through server-side manipulation, where the requests to the .zip_k* files are used as a delay mechanism. Figure 12 shows a packet capture (pcap) of the traffic filtered in Wireshark, highlighting a two-second delay between one of the HTTP GET requests and its HTTP response.
Figure 12. Delay in response to the request with zip_k.asp. Source: VirusTotal.
When examining the file redir_obj.htm, we found a code snippet shown below in Figure 13. This code loads a file from a local path that uses the leaked hostname and username captured during the initial SMB connection as CompName and UName variables, respectively. This is used to open an HTML file named 1111.htm contained in file file001.zip.
Figure 13. Snippet from redir_obj.htm.
Recreating Windows Search Handler File
We used Windows File Explorer to create a blank saved search file with the .search-ms file extension to control where the ZIP file containing 2222.chm is extracted and illustrate how this exploit chain works. We initiated a search in File Explorer and saved the results, which created a .search-ms file. This saved search file is a blank template that can reproduce search handler file behaviors used in this exploit chain.
The Windows system file Windows.Storage.Search.dll processes .search-ms files. In order for the ZIP file to be successfully extracted into the directory specified in the redir_obj.htm file, loaded by the JavaScript iframe shown earlier in Figure 11, several changes need to be made.
First, the include element must contain a local path as its network path and use FILE_ATTRIBUTE_NORMAL, implemented as the variable attributes="128" shown below in Figure 14.
Figure 14. Basic .search-ms file, altered to trigger ZIP extraction.
Next, the autoListFlags attribute must have its second least significant bit turned on, implemented as shown below in Figure 15. This results in a complete search that also includes the content of any ZIP archives.
Figure 15. Sample of .search-ms processing in Windows.Storage.Search.dll.
Processing the .search-ms file at this point would create a directory on the target machine in the following path:
The contents of the ZIP file are then extracted into this directory.
File .search-ms handles the ZIP file placement and extraction of its contents based on the earlier SMB-leaked host information.
Our results confirmed the two files extracted from the ZIP file: 1111.htm and 2222.chm.
Similar behavior was observed during an exploit for a previous RCE vulnerability in Office, CVE-2021-40444. In that attack, attackers would exploit a Microsoft Compressed Archive (CAB) path traversal extraction bug to achieve a similar objective: extracting an HTML file to a predictable path on the machine.
Before discussing our 1111.htm and 2222.chm files, we first should understand Windows Security Zones.
Windows Security Zones and Other Obstacles
Also known as Internet Explorer Security Zones or URL Security Zones, Windows Security Zones are the mechanism Microsoft uses to determine permissions for files originating from various sources. Typically, files retrieved from the internet are identified as from the “Internet Zone” and tagged with MotW for restricted permissions.
For the rest of the exploit chain to succeed, the 1111.htm and 2222.chm files must both be identified with a ZoneId value of 1 in their Zone.Identifier ADS (Security Zone 1). However, this presents an obstacle, because ZIP content downloaded from a remote path and extracted by .search-ms has a ZoneId value of 3, and this content is automatically tagged with MotW.
Two other obstacles must also be addressed for successful exploitation:
Obstacle 1: When our Windows Search using .search-ms completes, it deletes the [Temp1_zip_filename] directory. This generates a race condition to load files inside the temporary directory.
Obstacle 2: By default, Windows will not search the contents of CHM files. Our 2222.chm file is required as part of this exploit chain, but it will not be extracted from the ZIP archive using default settings for Windows Search.
New MotW Bypass - CVE-2023-36584
During our analysis of this exploit chain using CVE-2023-36884, our team discovered a different exploit vector, which Microsoft designated as CVE-2023-36584 and awarded us a bug bounty for.
Windows Search iterates through all files inside a ZIP archive during its search. Windows Search checks the file extension of each file to determine if its contents also need to be searched. If so, Windows Search writes the file to a temporary directory and adds MotW to it.
This implementation generates an inherent race condition. There is a short time window between writing an extracted file to disk and marking it with MotW. If we delay Windows Search during this window, we can solve the race condition and ultimately bypass MotW.
A previous technique exploiting CVE-2022-41049 bypassed MotW by adding a read-only attribute to files inside the ZIP archive. This avoided modifications to the Zone.Identifier ADS and prevented extracted files from receiving MotW. This technique inspired us and led to our discovery to bypass MotW.
Technique #1: Server Side ZIP Swap - Metadata TOCTOU
Server-side manipulation enables us to solve these issues. We found a Time-Of-Check to Time-Of-Use (TOCTOU) vulnerability that is exploitable when the ZIP archive is downloaded from a remote server.
Windows uses the system file zipfldr.dll to extract the content of ZIP archives. This Windows DLL file reads the ZIP file’s header and caches the data in memory while the ZIP archive’s content is extracted and saved to disk. Zipfldr.dll exposes an API, which can be used to extract a file by specifying its index in the ZIP archive.
When using zipfldr.dll to extract contents of a ZIP archive, the extracted file’s header is read from cached memory. This creates a scenario that can prevent extracted files from receiving MotW.
Once the file header is read and before it is decompressed using zipfldr.dll, we can replace the ZIP file on the remote server with a ZIP file that holds files with different names, leading to the MotW not being written.
This technique works because urlmon.dll uses the file path to write the MotW originally read from the ZIP’s header cached in memory. This makes it possible to bypass writing the MotW to the file.
This technique solves the two obstacles mentioned earlier regarding the exploitation of CVE-2023-36884. The .chm file that otherwise would fail to extract is successfully extracted, and the files are not immediately deleted.
Below, Figure 16 shows a Process Monitor (procmon) view illustrating failed attempts to create a substitute file named 2222.txt. This condition allows the previously-saved 2222.chm to avoid MotW.
Figure 16. Demonstration of MotW bypass using the TOCTOU vulnerability.
We cannot confirm this is the exact technique threat actors used in the original exploit chain. However, behavioral logs from VirusTotal’s sandbox analysis of the initial .docx lure show the creation of a file named 1111.txt indicating a possible substitute filename mirroring 1111.htm, and this hints at the same method we discuss here for Technique #1.
Technique #2: Server Side Delay - Close Operation
Discovering the first technique opened the door to further research, and we discovered two additional techniques that can significantly delay the writing of the MotW. This scenario prevents the MotW attribute from being written and allows the files to be executed from another thread in Security Zone 1.
After extracting files from the ZIP archive and before the MotW is added to the Zone.Identifier ADS, we can introduce a timing delay from the attacker-controlled SMB server. This is possible due to the SMB2 protocol’s close operation, which consists of a close request and a close response that ends an SMB-based file transfer.
When a client receives all data from the transferred file, it sends an SMB close request back to the server and waits for an SMB close response. The file has been transferred, but the transfer operation is not yet complete until the client receives a close response. This is a synchronic operation, which can be delayed for a significant period of time.
Below, the procmon list in Figure 17 shows a 30 second delay after an SMB server at 111.222.111[.]20 transferred a file named served.zip before the next operation. This indicates a 30-second delay between close request and close response.
During this 30-second window, the 1111.htm file is a Security Zone 1 file without MotW. After a close response is finally sent 30 seconds later, the process continues, and it writes the MotW to 1111.htm.
Figure 17. Demonstration of MotW bypass using delayed close.
Technique #3: Server Side Delay - Read Operation
When transferring a large file from a ZIP archive, Windows reads portions of the file from the remote share, appends the data to a local file on disk, then reads additional portions from the remote share until the file is fully written to disk. If we append random data at the end of the file (keeping it usable), we can delay writing of the file from the SMB server before Windows adds MotW to the file. The file is usable during this writing process, since it is opened with a read/write dwShareMode.
We tested this theory by introducing ten second delays in the process as shown below in Figure 18.
Figure 18. Demonstration of MotW bypass using delayed read response.
Microsoft Security Updates Address CVE-2023-36884
The threat actors that developed this exploit chain knew the path for a temporarily-saved local file used during SMB file transfer was predictable. But after Microsoft’s August 2023 security updates, researchers like Will Dorman reported a Universally Unique Identifier (UUID) has been added to the temporarily-saved local filename that makes the path random. We confirmed this, as shown below in Figure 19.
Figure 19. Temporarily-saved local file path after Microsoft’s August 2023 security updates.
As shown above in Figure 19 during our test run, the temporarily saved file includes the UUID string 90be3adb-6ec5-4f3f-bdd8-1e22ee6c326c in the directory path for the temporarily saved local file.
During the SMB file transfer process for a ZIP archive, zipfldr.dll creates a temporary folder by calling the CTempFileNameArray::GetTempLocation function, which calls CTempFileNameArray::_TryCreatingInPath.
Using BinDiff to find changes in the patched version of zipfldr.dll, we spotted a notable new code block in the CTempFileNameArray::_TryCreatingInPath function, as shown below in Figure 20.
Figure 20. Call to UuidCreate.
Microsoft added a call to UuidCreate, and extracting content from a ZIP archive fails if the path is not constructed with the new UUID.
Another interesting update in the patched version of zipfldr.dll is found in the ExtractZipToFile function. New code is added after extracting the file, which will append the MotW immediately after the file is written. If SetFileAttributes fails, the file is deleted, as shown in Figure 21.
Figure 21. Call to DeleteFileW.
Continuing the Exploit Chain
Although Microsoft's August 2023 Security Updates mitigated this exploit chain, other steps of the chain remained unpatched.
ActiveX Attack Surface
Running a file in Security Zone 1 results in a more permissive policy toward ActiveX controls and provides a greater ActiveX attack surface. This allows executing old ActiveX code that could be exploited to execute malicious code.
An increased ActiveX attack surface allows us to trigger the next step in the exploit chain. Below, Figure 22 shows a code snippet from 1111.htm that leads to the next step.
Figure 22. 1111.htm reloading in a WebBrowser control.
This code from 1111.htm creates a hidden popup and runs the ActiveX WebBrowser control within the hidden popup. The WebBrowser control is a wrapper that allows web browsing functionality in Windows-based applications. Developers often use this ActiveX control to embed an HTML viewer in an application.
Elevating Security Zones For Command Execution
While Security Zone 1 allows us to avoid MotW and increase the ActiveX attack surface, we can elevate our files to Security Zone 0 for command execution. Files tagged as Security Zone 0 represent the "Local Machine" zone, which is the most trusted zone and provides maximum allowable permissions.
At this stage, the WebBrowser control redirects the page from a network path in Zone 1 to a local path of the same page. Now that file 1111.htm is loaded from a local path, it executes in Security Zone 0.
Next, 1111.htm loads 2222.chm by invoking ms-its shown below in Figure 23.
Figure 23. 1111.htm loading 2222.chm.
Windows uses this ms-its handler to display Microsoft Compiled HTML Help (CHM) files. This function is implemented in module itss.dll, which loads the extracted 2222.chm file.
Figure 24 below reveals the contents of 2222.chm when viewing the file in HTML Help Workshop.
Figure 24. Contents of 2222.chm viewed in HTML Help Workshop.
The CHM file contains a file named file1.htm, which redirects to file1.mht (handled by inetcomm.dll, part of Microsoft's internet messaging API). Then file1.mht uses the showHelp method to load fileH.htm. Then FileH.htm redirects to fileH.mht, and finally fileH.mht executes the script shown below in Figure 25.
Figure 25. Snippet of fileH.mht - code calls open function.
The code snippet from fileH.mht in Figure 25 uses the window.open method to invoke the ShellExecuteExW API to open a file at:
The Internet Shortcut (URL) file named ex001.url from Figure 25 points to file[:]//104.234.239[.]26/share1/MSHTML_C7/ex001.zip/file001.vbs.
The downloaded file001.vbs file contains malicious Visual Basic Script (VBS) designed to bypass SmartScreen protection.
When a URL file points to a remote UNC path, the URL file downloads and runs content returned from that path. Executing the content calls the ShellExecuteW API which triggers the CheckSmartScreen function, prompting the user for confirmation, as shown below in Figure 26.
Figure 26. SmartScreen warning.
However, our file resides within a ZIP archive, so it triggers a slightly different behavioral flow. File file001.vbs is downloaded during the exploit chain and extracted to the user’s local temp directory with MotW, but it is immediately executed without any popup warnings. This is illustrated below from the procmon list below in Figure 27.
Figure 27. Wscript.exe is immediately launched, successfully bypassing SmartScreen.
As shown above in Figure 27, file ex001.zip is retrieved from a remote directory, then file001.vbs is extracted from the ZIP archive. Later in the process event list, we find a Process Create entry for wscript.exe to run the VBS file, as highlighted in blue.
Disabling cross protocol navigation prevents navigation between URI schemes. This mitigation stops the redirection from RFile.asp, discussed earlier with Figure 9 and Figure 10.
Conclusion
Starting with the malicious .docx file, our analysis of the July 2023 campaign targeting groups supporting Ukraine's admission into NATO revealed a more complex exploit than originally reported. Our analysis of this chain revealed a chain of more than 20 steps that not only exploited CVE-2023-36884, but included additional vulnerabilities to bypass protections in Microsoft Office and Windows.
Microsoft awarded our team a bug bounty and assigned CVE-2023-36584 to a new vulnerability discovered in our research.
Palo Alto Networks customers receive protection from and mitigation for these exploits the following ways:
Cortex XDR customers received protection from these exploit methods before they were discovered.
Prisma Cloud is capable of detecting and preventing cloud application deployment that contains exploits against either CVE-2023-36884 or CVE-2023-36584. Protection from these exploits was available out of the box.
If you think you may have been compromised or have an urgent matter, contact the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
Palo Alto Networks has shared our findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Indicators of Compromise
The following files are associated with the July 2023 campaign lure Overview_of_UWCs_UkraineInNATO_campaign.docx and have been posted to VirusTotal. Of note, SHA256 hashes for some of these files are different for each infection.
Since the end of August 2023, we have observed a significant rise in compromised servers specializing in clickbait and ad content. But why are sites like this such an attractive target for criminals? Mainly because these sites are designed to reach a large number of potential victims. Furthermore, clickbait sites often use outdated or unpatched software, making them vulnerable to compromise.
This article educates readers on the dangers of clickbait articles. We discuss how clickbait sites increase traffic for ad revenue. Additionally, we review a strategy to detect vulnerable clickbait sites based on the characteristics of their web traffic. Finally, we reveal trends on the recent jump in compromised clickbait sites based on exploitation of CVE-2023-3169.
Clickbait is best described as a link to web content of dubious value, designed to make readers want to click it. Sites specializing in clickbait content exist for the sole purpose of generating advertising (ad) revenue. As a result, webpages from clickbait sites contain a great deal of intrusive ads.
Clickbait requires a significant number of views to generate ad revenue, so these sites often use the following three strategies to increase their traffic.
Evergreen topics
Content discovery platforms
Generative artificial intelligence (AI) tools
Evergreen Topics
One strategy to increase traffic is focusing on evergreen topics. Evergreen describes topics that are not tied to a particular time or place and people continue to find them interesting. For example, finance and health are considered evergreen topics. Figure 1 and Figure 2 show two examples of pages from clickbait sites.
Figure 1. Example of a finance-themed clickbait article.Figure 2. Example of a health-themed clickbait article.
Content Discovery Platforms
Since clickbait content is itself distributed through ads, many clickbait sites also rely on a second strategy to increase traffic: content discovery platforms.
News organizations and other content providers use content discovery platforms to generate revenue. Clickbait providers often hire these services to drive traffic to their own content.
Content discovery platforms often use techniques to disguise ads. One such method is called native advertising. This method configures ad content to resemble the look and feel of the site on which it appears. As a result, viewers can have difficulty distinguishing between the site’s original content and the ad content.
Figure 3 shows examples of native ads appearing on a news site.
Figure 3. Example of native ads appearing on a news site.
In Figure 3, we added a red arrow pointing to clickbait content hosted at hxxps://gofindyou[.]com/health/what-causes-plaque-psoriasis-heres-what-doctors-need-you-to-know. A quick check reveals this site was running at least one piece of outdated software. The HTML code from the webpage indicates it uses a WordPress plugin for Yoast SEO shown below in Figure 4.
Figure 4. HTML code of a clickbait page showing Yoast SEO plugin v20.8.
The HTML showing Yoast SEO plugin version 20.8 was originally released on May 23, 2023. The webpage shown in Figure 4 was served on Oct. 27, 2023, when the most current version of the Yoast SEO plugin was 21.4, making this plugin out-of-date. We routinely discover clickbait sites with outdated software or plugins.
(This specific case does not imply any specific vulnerability, but outdated software can be more vulnerable than fully patched versions.)
Generative AI Tools
The newest strategy for clickbait authors is using generative AI tools like Jasper and AIPRM. These tools provide an easy method to generate SEO-optimized content to increase site traffic.
(Threat actors often abuse, take advantage of or subvert legitimate products for malicious purposes. This does not necessarily imply a flaw or malicious quality to the legitimate product being abused.)
One example is an article written with ChatGPT at hxxps://delhiproduct[.]info/top-24-earn-money-with-paid-online-surveys as demonstrated in a YouTube video. In this example, the website is a WordPress site that runs an outdated version of the MonsterInsights plugin (version 8.1.0) as shown below in Figure 5.
Figure 5. HTML from delhiproductinfo[.]com reveals outdated MonsterInsights plugin.As of Oct. 3, 2023, the most current version of the MonsterInsights plugin is 8.20.1. This means the 8.1.0 version is at least two years out-of-date. The 8.1.0 version of this plugin is also vulnerable to a stored XSS attack.
Finding Vulnerable Sites
To compromise any website, attackers must know the web stack used by the site's web server. This data includes the operating system, web content management software (CMS), and any associated plugins and themes.
Threat actors use web stack data to determine if a server is running any out-of-date software or applications. Armed with this information, attackers can easily find publicly known vulnerabilities and exploits to compromise the website.
How can we determine a server's web stack? We can discover this information through a website’s URL patterns, HTML content and functionality. A webpage’s look and feel can also provide clues.
Table 1 provides examples of indicators that can reveal parts of a site’s web stack.
Pattern
Description
/wp-content/ or /wp-includes/
Either of these strings in a URL or a webpage’s HTML code indicates the associated site might use WordPress.
<!-- This site uses the Google Analytics by MonsterInsights plugin v8.1.0 - Using Analytics tracking - https://www.monsterinsights[.]com/ -->
This comment in a webpage’s HTML code indicates the site uses the MonsterInsights plugin for WordPress. Comments for plugin information are accurate in most cases.
Table 1. Pattern examples that can reveal parts of a web stack.
The first two techniques described in Table 1 can be helpful when confirming exploitation of CVE-2023-3169.
Unit 42 team members monitor Palo Alto Networks telemetry for malicious activity. This data includes indicators from HTML code in webpages and their associated URLs. From this data, we confirm a compromised website through the presence of malicious script and other indicators.
Previous research revealed a massive campaign using the Balada Injector to compromise thousands of sites vulnerable through CVE-2023-3169. According to this research, websites compromised by this campaign generated pages that loaded malicious content from the following location:
hxxps://stay[.]decentralappps[.]com/src/page.js
Our data confirmed this finding. Analyzing our telemetry, we saw a spike in compromised WordPress sites associated with CVE-2023-3169 that began in late August 2023.
We discovered approximately 10,300 compromised WordPress sites during a two-month period. Below, Figure 6 shows a graph illustrating this spike in our detections.
Figure 6. Our data on WordPress sites that were compromised through CVE-2023-3169.
As presented in Figure 6, a significant portion of these compromised sites were clickbait or ad sites. Our investigation found that clickbait and ads accounted for over 30% of the detections. Of that 30%, further investigation revealed at least 80% of the compromised sites used tagDiv’s Newspaper theme and an additional 6% used tagDiv’s Newsmag theme.
Example of Injected Script
Figure 7 shows an example from early October 2023 of the malicious script injected into webpages that was served by one of the compromised sites. The injected script is highlighted in yellow.
Figure 7. Example of the injected script on a webpage from a WordPress site.
This obfuscated script uses decimal values representing ASCII characters. Converting these numbers to ASCII text reveals the malicious script shown below in Figure 8.
Figure 8. Malicious script decoded from highlighted text in Figure 7.
The decoded script in Figure 8 contains the same hxxps://stay[.]decentralappps[.]com/src/page.js URL noted in previous reports about campaigns exploiting CVE-2023-3169 using the Balada Injector.
Trends for Clickbait and Ad Sites
We use Cortex Xpanse and other tools to track vulnerability trends from our telemetry. In addition to CVE-2023-3169, we track websites compromised by other vulnerabilities.
During a case study from Sept. 15-22, 2023, we monitored a dataset of 1,600 randomly selected WordPress sites, detecting attempted visits by our customers to compromised websites.
The results indicate a nearly three to one ratio of compromised clickbait and ad sites compared to other categories. Figure 9 shows the weekly average of detections from our case study.
Figure 9. From our case study: Detections for compromised WordPress sites.
Whether from CVE-2023-3169 or other vulnerabilities, our telemetry reveals a consistently higher amount of compromised clickbait and ad sites when compared with other categories.
Conclusion
When reviewing compromised website indicators from our telemetry, we continue to see a large volume of compromised clickbait and ad sites when compared with other categories. We explored some of the reasons behind that trend in this article.
With the potential to reach a large number of victims, these sites often use out-of-date or unpatched software, making them an attractive target for threat actors. As a result, clickbait articles are inherently risky. Readers should be aware of this risk and adjust their browsing habits accordingly.
Next-Generation Firewall with the Advanced Threat Prevention security subscription can help block the attacks with best practices via the following Threat Prevention signature: 94459.
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 with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Acknowledgments
We’d like to thank the entire Unit 42 team for supporting us with this blog. Special thanks to Shehroze Farooqi, Billy Melicher and Jackson Rolf for helping us with the data and reviewing the blog.
Updated Dec. 1, 2023, at 2:45 p.m. PT to expand product protections.
Unit 42 has identified malicious Chinese APT infrastructure masquerading as cloud backup services. Monitoring telemetry associated with two prominent Chinese APT groups, we observed network connections predominately originating from the country of Cambodia, including inbound connections originating from at least 24 Cambodian government organizations.
We assess with high confidence that these Cambodian government entities were targeted and remain compromised by Chinese APT actors. This assessment is due to the malicious nature and ownership of the infrastructure combined with persistent connections over a period of several months.
In recent years, China’s most notable investment has been a project to modernize Cambodia's Ream Naval Base. This project generated controversy and drew scrutiny from several Western nations due to initial attempts by both countries to conceal the project.
As the project nears completion this year, the naval base is on track to become China’s first overseas outpost in Southeast Asia. As such, this project demonstrates how significant Cambodia is to China’s ambitions of projecting power and expanding naval operations in the region.
Most recently, this certificate was used by servers on six target-facing IP addresses. Each of these servers host several subdomains associated with six domains.
Based on their names, a number of these domains appear to masquerade as cloud storage services. This disguise likely lends a sense of legitimacy to the unusual amount of traffic during times of high activity levels from the actor, such as data exfiltration from the victim network.
Figure 1 provides a visualization of the malicious infrastructure.
Figure 1. Infrastructure overview.
Suspected Cambodian Government Targets
We observed a total of 24 Cambodian government organizations regularly communicating with this infrastructure between September and October 2023. A number of these organizations provide critical services in the following industries:
National defense
Election oversight
Human rights
National treasury and finance
Commerce
Politics
Natural resources
Telecommunications
These targets all hold vast amounts of sensitive data, including the following:
Financial data
Personally identifiable information of citizens
Classified government information
We assess that these organizations are likely the targets of long-term cyberespionage activities that have leveraged this infrastructure for persistent access to government networks of interest.
Command and Control Infrastructure
We assess with high confidence that the target-facing IP addresses are being used as command and control (C2) infrastructure by the threat actor. We believe the infrastructure is running the Cowrie honeypot on port 2222. The attackers are likely using this honeypot as a cover to deceive network defenders and researchers investigating anomalous activity.
We have also observed IP filtering on this infrastructure. Specifically, we have observed the blocking of connections from the following:
Known Palo Alto Networks IP ranges
Some VPS and cloud hosting providers
IP ranges from a number of Big Tech and other cybersecurity companies
We believe this threat actor is filtering connections to the malicious infrastructure to minimize the risk of the C2s being profiled by IP scanners or identified by cybersecurity researchers.
We have also observed C2 ports open during activity times for the threat actor and closed at all other times. Again, this is likely to minimize the risk of the infrastructure being profiled by IP scanners or identified by researchers.
Table 2 outlines the known actor and target-facing ports.
IP Address
Target Port
Domain(s)
165.232.186[.]197
80, 443, 4433
api.infinitycloud[.]info
connect.infinitycloud[.]info
ns.infinitycloud[.]info
167.71.226[.]171
80, 81, 82, 443, 769, 4433, 8086, 8089
file.wonderbackup[.]com
connect.infinitybackup[.]net
share.infinitybackup[.]net
sync.wonderbackup[.]com
104.248.153[.]204
82, 443
update.wonderbackup[.]com
login.wonderbackup[.]com
ns1.infinitybackup[.]net
143.110.189[.]141
443
mfi.teleryanhart[.]com
ads.teleryanhart[.]com
172.105.34[.]34
8081, 8087, 8443, 8888
jlp.ammopak[.]site
kwe.ammopak[.]site
lxo.ammopak[.]site
dfg.ammopak[.]site
fwg.ammopak[.]site
194.195.114[.]199
8080, 8443, 9200
connect.clinkvl[.]com
Table 2. Target-facing infrastructure details.
Actor Pattern of Life
While investigating the cluster of infrastructure, we were able to determine the actor’s pattern of life. We predominantly observed the actor’s activity between 08:30 and 17:30 UTC +08:00 (China Standard Time) on weekdays (Monday to Friday). This pattern might indicate the actor is attempting to avoid detection by blending into regular Cambodian business hours which are UTC +07:00.
However, we also observed a significant change in actor activity that suggests the actor is based in China and working regular business hours in China.
This change in the actor’s pattern of life occurred between Sep. 29 and Oct. 8, 2023. Actor activity ceased on Sep. 29, with low amounts of activity through the week of Oct. 2-8, including the weekend of Oct. 7-8. We saw actor activity return to regular levels and patterns starting Oct. 9.
The dates of the actor’s activity changes align with China’s Golden Week, held on Sep. 29 to Oct. 6, 2023, and “Special Working Days,” designated as Oct. 7-8, 2023. Special Working Days are Chinese government-mandated working days to compensate for the extended holiday.
Figure 2 shows the regular activity pattern and deviation during Golden Week, before returning to normal.
Figure 2. Actor pattern of life.
Conclusion
Unit 42 identified Chinese APT-associated activity targeting Cambodia, including over 20 Cambodian government organizations across a range of key industries. This activity is believed to be part of a long-term espionage campaign.
The observed activity aligns with geopolitical goals of the Chinese government as it seeks to leverage their strong relations with Cambodia to project their power and expand their naval operations in the region. We encourage all organizations to leverage our findings to inform the deployment of protective measures to defend against this activity.
Protection Recommendations
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 cloud-delivered security services. This includes threat prevention, URL filtering, DNS security and a malware prevention engine capable of identifying and blocking malicious samples and infrastructure.
Security Automation: Delivered through a Cortex 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.
Container Security: Delivered through the Palo Alto Networks Prisma Cloud advanced container security features for container runtime environments to ensure detection and prevention of known malicious executables. Advanced URL Filtering blocks malicious IoCs related to this operation. WildFire integration for cloud-delivered malware analysis service accurately identifies known samples as malicious.
Protections and Mitigations
Palo Alto Networks customers receive protection from the threats discussed above through the following products:
If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200
Palo Alto Networks has shared these findings 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.
Unit 42 researchers have investigated a series of destructive cyberattacks beginning in January 2023 and continuing as recently as October 2023, targeting the education and technology sectors in Israel.
The attacks are characterized by attempts to steal sensitive data, such as personally identifiable information (PII) and intellectual property. Once the attackers stole the information, they deployed various wipers intended to cover the attackers’ tracks and to render the infected endpoints unusable.
Our investigation revealed the perpetrators of the attacks have strong connections to an Iranian-backed APT group Unit 42 tracks as Agonizing Serpens (aka Agrius, BlackShadow, Pink Sandstorm, DEV-0022).
Unit 42 researchers were also able to identify novel new wipers and tools that Agonizing Serpens used in their most recent attacks:
MultiLayer wiper
PartialWasher wiper
BFG Agonizer wiper
Sqlextractor - a custom tool to extract information from database servers
Based on forensic evidence, it appears that the Agonizing Serpens APT group has recently upgraded their capabilities and they are investing great efforts and resources to attempt to bypass endpoint detection and response (EDR) and other security measures. To do so, they have been rotating between using different known proof of concept (PoC) and pentesting tools as well as custom tools.
For the attacks described below, the attacker was unsuccessful at bypassing Cortex XDR. Cortex XDR and XSIAM detect and prevent the execution flow described. They also build behavioral profiles of user activity over time with machine learning, allowing them to detect anomalous activity indicative of, for example, credential-based attacks.
We are sharing this research to provide detection, prevention and hunting recommendations to help organizations protect against the threats associated with Agonizing Serpens.
Agonizing Serpens (aka Agrius) is an Iranian-linked APT group that has been active since 2020. The group is known for its destructive wiper and fake-ransomware attacks and mainly targets Israeli organizations across multiple industries and countries.
Though earlier reports of these attacks mentioned ransomware and ransom notes, these turned out to be a ruse (a trend noted in the 2023 Unit 42 Ransomware and Extortion Report). In the most recent attacks, the attackers did not request ransom – rather, the potential result of the attacks was vast data loss and disruptions of business continuity.
Attacks from Agonizing Serpens usually have two main goals, the first being stealing sensitive information that includes PII and intellectual property, which threat actors then publish on social media or Telegram channels. It seems likely that their motivation to publish on social media is to sow fear or inflict reputational damage. The second goal is wreaking havoc and inflicting considerable damage by wiping as many endpoints as possible.
Since its emergence, the group has developed new custom tools and they have also leveraged known hacking tools and techniques to carry out their aggressive operations.
Technical Analysis
The following sections detail the different stages of a recent incident carried out by Agonizing Serpens in October 2023, as analyzed by Unit 42 researchers.
Entry Vector
The attackers gained initial access to the environment by exploiting vulnerable internet facing web servers. Subsequently, they deployed multiple web shells, which granted them a foothold in the network.
The web shells that threat actors used in the described attack (shown in Figure 1) contain the same code as web shells that were observed in previous Agonizing Serpens attacks, with variations to the naming of functions. The web shells appear to be variations of ASPXSpy.
Figure 1. Snippet from xcopy.aspx web shell.
Another web shell used in this attack was named Uploader.aspx. Figure 2 shows almost identical code found in two web shells used by Agonizing Serpens, one from a recent attack and the other from a past attack.
Figure 2. Top: snippet from Uploader.aspx, Bottom: Snippet from a web shell used in an Agonizing Serpens attack in the past against an Israeli company.
Figure 3 shows how, shortly after the attackers deployed the web shells, they started to execute basic reconnaissance commands via the web shells.
Figure 3. Basic reconnaissance commands via the web shells shown in Cortex XDR.
Reconnaissance
To map out the network, the attackers used various known and publicly available scanners.
Nbtscan
The attackers used Nbtscan, renamed as systems.txt, to scan the network for existing hosts (shown in Figure 4).
Figure 4. Nbtscan used to scan the network.
WinEggDrop
Figure 5 shows how the attackers used an open-source SYN/TCP port scanner by WinEggDrop to scan particular hosts of interest.
Figure 5. WinEggdDrop scanner used for port scanning.
NimScan
NimScan is another publicly available port scanner that the attackers used in the attack, as shown in Figure 6.
Figure 6. NimScan being used for port scanning.
Credential Stealing
A crucial phase of the attack consisted of obtaining credentials of users with administrative privileges. To do so, the attackers tried multiple methods to obtain credentials, which were prevented by the Cortex XDR platform:
Mimikatz (filename: Mimi.exe)
SMB password spraying
SMB password brute force (shown in Figure 7)
Figure 7. Password brute forcing using SMB.
Dumping the SAM file (shown in Figure 8)
Figure 8. Dumping the SAM file.
Lateral Movement
Figure 9 shows that to move laterally in the environment, the attackers mostly used Plink (renamed as systems.exe) to create remote tunneling and establish connections to remote machines.
Figure 9. Plink used to establish remote tunneling.
Stealing and Exfiltrating Data
Attackers attempted to steal information from databases and other critical servers before executing wipers to cover their tracks. They then tried to exfiltrate this information to the attackers’ C2 servers, using different publicly available tools such as WinSCP and Putty.
Extracting Database Information Using Sqlextractor
The attackers used a custom tool they named sqlextractor (binary name sql.net4.exe). Its purpose is to query SQL databases and extract sensitive PII data, such as the following:
ID numbers
Passport scans
Emails
Full addresses
The data was saved into CSV files as shown in Figures 10 and 11. The tool writes the data to a hard-coded staging path: C:\windows\temp\s\.
Figure 10 shows the attackers then used 7za.exe to archive the extracted data in preparation for exfiltration.
Figure 10. Sqlextractor and 7za.exe used to extract files and archive them.Figure 11. Sqlextractor writes extracted data to CSV files.
Figure 12 shows the attackers also used 7zG.exe to archive interesting folders in the infected environment.
Figure 12. 7zG.exe used to archive various folders.
Data Exfiltration Using WinSCP
The attackers attempted to use WinSCP to exfiltrate files from the environment, as shown in Figures 13 and 14.
Figure 13. WinSCP being used to exfiltrate files.Figure 14. Exfiltration alerts by Cortex XDR.
Data Exfiltration Using Pscp.exe (PuTTY Secure Copy Protocol)
Figure 15 shows that another tool the attackers used for exfiltration is pscp.exe (PuTTY Secure Copy Protocol).
The attackers attempted to establish a connection to the C2, then searched for .7z and .ezip files that contain stolen data, as well as .dmp files created by ProcDump.
Figure 15. pscp.exe used for exfiltration.
Wiper Payloads
During the incident, the attackers attempted to use three separate wipers as part of the destructive attack. While some of the wipers show code similarities to previously reported wipers the Agonizing Serpens group used, others are considered brand new. These have been used for the first time in this attack, as detailed in the following section.
MultiLayer Wiper
The first wiper that the attackers used is .NET malware called MultiLayer. As its name suggests, this wiper contains multiple layers and stages.
Its compilation date is Oct. 14, 2093. As this is set to a future date, it is a clear sign of metadata manipulation.
Figure 16 shows that it contains two more binaries in its resources section, named MultiList and MultiWip.
Figure 16. MultiLayer resources.
MultiLayer drops and executes each of the aforementioned binaries, then deletes them right after their execution.
The MultiList Component - Setting the Target Files
MultiList generates a list of all the files and their paths on the fixed drives on the system. It does this by enumerating all files on the infected operating system while excluding specific folders defined in a predefined list (shown in Figure 17). The attackers can define the path to which this tool should store the list via the command line.
Figure 17. MultiList exclusion functionality.
MultiWip - the Core Wiper Component
The MultiWip component contains the actual file wiping functionality. It relies on the previous component (MultiList) and reads the output list of files to wipe, which is passed as a command-line argument.
MultiWip’s main function is called DoJob() and is responsible for carrying out the file-wiping activity in the manner shown in Figure 18.
Figure 18. Snippet from MultiWip’s main DoJob() function.
The malware takes the following steps in the order indicated:
Files located on network drives are deleted immediately.
Locally stored files are corrupted and overwritten with random data to thwart file recovery efforts, as shown in Figure 19.
Figure 19. Snippet of MultiWip File data destruction function.
The malware changes the original timestamps in the following FileSystemInfo properties: LastAccessTime, LastWriteTime and CreationTime. This is a well-known anti-forensic timestomping technique. The malware timestomps according to the file system. If the file system is NTFS, the malware sets the timestamp to 1601.1.1. Any other file system, the malware sets it to 1980.1.1 (shown in Figure 20).
Figure 20. MultiWip timestomp function.
The malware changes the original paths of the deleted files, using Path.GetRandomFileName, to make any recovery efforts extremely hard.
Finally, the malware deletes the files.
Covering Tracks and Rendering the System Unusable
MultiLayer is designed to cover its tracks by erasing evidence of its execution. It does so by running various commands to prevent restoration of lost data and to render the disk unusable.
Figure 21 shows that MultiLayer uses the DeleteLogs() function to create a scheduled task that launches a batch script only once. The script then removes all the Windows Event Logs.
Figure 21. MultiLayer scheduled task to delete events logs.
To remain stealthy, MultiLayer removes all the files it uses after its execution, including itself. To remove itself, MultiLayer uses SelfDelete().
The removal is implemented by threat actors writing a batch file named remover.bat to %TEMP% and executing it. The batch file deletes the assembly file and the batch itself, and then it clears the file system cache memory, leveraging the ProcessIdleTasks export in advapi32.dll.
To further prevent data restoration, MultiLayer tries to remove all shadow copies on the system as shown in Figure 22, and then remove the Volume Shadow Copy (VSS) service itself.
Figure 22. MultiLayer deletion of the shadow copies.
Figure 23 shows that, to ensure that the system can no longer boot, MultiLayer opens a handle to \\\\.\\PhysicalDrive0 and wipes the first 512 bytes (aka the boot sector).
Figure 23. MultiLayer wiping the boot sector.
Finally, after the boot sector is corrupted, MultiLayer adjusts its privileges to SeShutdownPrivilege and calls the Windows API ExitWindowsEx with the EWX_REBOOT flag, which indicates system reboot. Once the system reboots, it will not be able to boot again.
The attempt to execute MultiLayer was prevented by Cortex XDR, as depicted in Figure 24 below.
Figure 24. Blocked execution of the MultiLayer wiper by Cortex XDR platform.
Similarities to Apostle, IPsec Helper, and Fantasy
Throughout our analysis of MultiLayer, we noticed multiple code overlaps with Apostle, IPsec Helper and Fantasy. These are custom tools previously used by Agonizing Serpens. This might be the result of a shared codebase or being written by the same team of developers. When comparing the code of the aforementioned tools, it appears that MultiLayer shares naming conventions and even entire code blocks with them.
Example 1: Self-Deletion Mechanism
The self-deletion mechanism of MultiLayer is implemented in a similar manner to IPsec Helper, Apostle and Fantasy. They share the same name for the function, named SelfDelete(). They also delete themselves by writing a batch file named remover.bat to %TEMP% and executing it, using the above mentioned functions shown in Figures 25 and 26.
The recursive directory listing mechanism of MultiList is implemented in a similar manner to Fantasy and Apostle. They share the same name for the function, named GetSubDirectoryFileListRecusrive.
They also both call GetSubDirectoryFileListRecusrive() and GetDirectoryFileList(), where GetSubDirectoryFileListRecusrive() is called recursively as shown in the code snippets in Figures 27 and 28.
Figure 27. Recursive directory listing in MultiList.Figure 28. Recursive directory listing in Fantasy. Source: Figure 6 in ESET blog "Fantasy – a new Agrius wiper deployed through a supply‑chain attack."
PartialWasher Wiper
During the attack, the attackers attempted to use a second wiper, which they call PartialWasher or PW. Figure 29 shows that it was compiled on Oct. 8 and, unlike other .NET wipers mentioned in this article, it is written in C++.
Figure 29. The compilation timestamp of PartialWasher.
PartialWasher defines itself as a crucial process by calling NtSetInformationProcess, and it supports command-line arguments. In case no arguments are provided, the default functionality would be a wiper functionality.
When passing 1 as an argument, the attacker can then use an interactive command-line interface (CLI). There are several typos in the interface’s text, indicating that the authors are likely not native English speakers.
Figure 30 shows an example of the passed arguments S /p. They trigger the malware to gather information about available drives on the infected machine.
Figure 30. PartialWasher’s CLI and typos marked in red squares.
The supported commands demonstrate the wiper’s further capabilities to perform individual wiping tasks at the request of its operators. These commands include:
S - Scan drives and retrieve information about them, depending on the provided secondary argument
/a - Get all drive information and partition details
/p - Get only drive information
/v - Get only partition details
D - Write around 420 MB of binary data to a provided device number, most likely to make a drive unusable
F - Wipe files in a specified folder and its subfolders if the files are not empty
I - Wipe a specified file if it is not empty
W - Change file attributes and wipe files
The attempt to execute PartialWiper was prevented by Cortex XDR, as depicted in Figure 31 below.
Figure 31. PartialWasher detected and prevented by Cortex XDR.
BFG Agonizer Wiper
The BFG Agonizer
A third wiper that the attackers used is called BFG Agonizer (bfg.exe), according to its PDB path (E:\tools2\BFG agonizer\INFECTOR\Dropper\Dropper\Release\Dropper.pdb). The file metadata indicates that it was compiled on Oct. 8, as shown in Figure 32.
Figure 32. BGF Agonizer’s compilation timestamp.
It is worth noting that there are many code similarities between BFG Agonizer and an open-source project called CRYLINE-v5.0, hosted on GitHub. We assess that BFG’s authors copied, or at the very least, relied heavily on this publicly available code.
Before the wiper commences its wiping activity, it first attempts to circumvent security measures that might exist on the infected endpoint. It does so by implementing several anti-hooking techniques, which have not been reported thus far as part of the group's known techniques. This suggests a possible upgrade of their capabilities.
The following sections list the anti-hooking functions BFG runs before its main payload.
DLL Unhooking
DLL unhooking is an anti-hooking technique that attempts to remove the user mode inline hooks, which various security solutions often implement. The technique works by restoring the bytes of the hooked functions to their original disk values. This technique is well known, and it is likely that the wipers’ authors largely adopted the following publicly available code.
To wipe the boot sector, the wiper retrieves a device handle to \\.\PhysicalDrive0 as shown in Figure 33. In turn, it calls DeviceIoControl with the IOCTL_DISK_GET_PARTITION_INFO control code to find the partition style.
Figure 33. BFG retrieves a device handle to \\.\PhysicalDrive0.
Finally, after the sectors are infected, the wiper adjusts its privileges to have the SeShutdownPrivilege and calls the native API NtRaiseHardError, which triggers a blue screen of death (BSOD) in the system with the error code of 0xC0000420. Once the system crashes, it will not be able to boot again (shown in Figure 35).
Figure 35. BFG causing a BSOD on the system after corrupting the boot sector.
The attempt to execute BFG Agonizer wiper was prevented by Cortex XDR, as depicted in Figure 36 below.
Figure 36. Execution of BFG Agonizer wiper blocked by the Cortex XDR platform.
Attempted Anti-EDR Activity
During the attack, the group specifically attempted to bypass EDR solutions to carry out their attack uninterrupted and with greater stealth. These attempts were blocked by the Cortex XDR platform. It is interesting to note that the group tried multiple tools and techniques, and each time they failed with one, they tried to leverage another.
While most of the techniques are known and well-documented, the group has not used them in previous publicly reported attacks. This could suggest that the group is becoming increasingly advanced and aggressive in its approach.
The following sections list some of the EDR bypass tools and techniques in the order they leveraged them.
EDR Service Dependency Bypass
The threat actor attempted their first EDR bypass technique on Oct. 6. The actor tried to manipulate the Cortex XDR service auto-start functionally. By leveraging previously obtained Administrator privileges, the attackers tried to modify the services Cortex XDR depends on, so it would not be able to auto-start upon system startup.
Figure 37 shows these attempts were prevented, and then the attackers shifted into using custom tools that abuse the “bring your own vulnerable driver” (BYOVD) technique.
Figure 37. Cortex XDR prevents service registry manipulation.
DrvIX: A Custom BYOVD Loader
The first custom tool the attackers used was a binary named agmt.exe, which was compiled on Oct. 7. According to its PDB path (C:\Users\dude\source\repos\drvix\x64\Release\drvix.pdb), it appears that this tool’s original name is drvIX (shown in Figure 38).
Figure 38. agmt.exe PDB path and compilation date.
However, according to the binary help function shown in Figure 39, the name is Drvtopia.
Figure 39. DrvIX help section mentions Drvtopia.
Agmt.exe is a custom loader and operator for the GMER driver, gmer64.sys (renamed to AGMT.sys). GMER’s original intended purpose is to detect and remove rootkits; however, threat actors can also leverage it to remove security products. Using agmt.exe, the attackers can specify the PID of the target process they wish to terminate via the command line.
Agmt.exe starts by registering GMER a new kernel driver (agmt.sys) as a service named AGMT and starting it, which in turn causes the operating system to load the driver into the kernel.
To communicate and abuse the GMER functionality of terminating processes, agmt.exe retrieves a device handle to GMER’s device object as shown in Figure 40.
Figure 40. Agmt.exe opens a handle to the GMER device object.
Then, agmt.exe uses DeviceIoControl Windows API with the control code 0x9876C094, while specifying the PID in the Input_Buffer parameter of the call (shown in Figure 41).
Figure 41. Agmt.exe communicates with the GMER driver for terminating processes.
DeviceIoControl allows user mode processes to directly communicate with kernel drivers, allowing the processes to request the drivers to service certain operations for them.
In the case of agmt.exe, the DeviceIoControl API call triggers a process termination operation for the GMER driver. Figure 44 shows that by inspecting the GMER driver, we can determine that the functionality of the 0x9876C094 control code is to terminate the target process provided by PID.
Figure 42. GMER 0x9876C094 control code functionally.
The function opens a handle to the target process PID using ZwOpenProcess and then terminates it by calling ZwTerminateProcess.
The attempt to leverage the GMER driver failed, as shown in Figure 43 below.
Figure 43. Loading of the GMER driver being blocked by the Cortex XDR Platform.
Second Vulnerable Driver Attempt (Rentdrv2 Driver)
As the attempt to exploit the GMER driver failed, the attackers tried arming their drvIX tool. They did so using a different vulnerable driver from a new publicly available PoC tool called BadRentdrv2, first published in the beginning of October 2023.
The attacker used the same project and compiled a modified version of the tool a day later, on Oct. 8 as shown in Figure 44. This time, the binary’s original name drvIX.exe was not changed.
Figure 44. PDB path and compilation for drvIX.exe.
The loading code of the driver looks almost identical to the aforementioned drvIX version. Similarly, drvIX.exe accepts the PID of the target process the attacker wishes to terminate via the command line.
DrvIX retrieves a device handle to its device object and communicates with the Rentdrv2 driver via DeviceIoControl. DrvIX then sends the target PID by specifying it in a structure sent as the Input_Buffer and specifies the control code as 0x22E010 (shown in Figure 45).
Figure 45. DrvIX communicates with Rentdrv2.
Similarly to the GMER driver, the 0x220E010 control code terminates the target process provided by its PID, as shown in Figure 46.
Figure 46. Rentdrv2 0x22E010 control code functionality.
Figure 47 shows this attempt was blocked and prevented by the Cortex XDR platform.
Figure 47. Prevention of an attempt to terminate the Cortex XDR service.
Attribution
Based on the Unit 42 attribution model, we assess with a high level of confidence that the attacks described in this article were carried out by the Iranian-linked Agonizing Serpens APT group.
This assessment is based on the following reasons and evidence:
Multiple code similarities in wipers: The analysis of the MultiLayer wiper in this article shows multiple code similarities and similar naming convention to previously documented Agonizing Serpens wipers known as Apostle, its successor Fantasy, and the IPsec Helper backdoor.
Code similarity in web shells: The attackers used web shells variants that consisted of the same code, except for variable and function names that are replaced for each sample.
Destructive nature of the attacks: The final step of the attacks implements a “scorched earth” policy, using custom wipers to render the endpoints unusable and cover the tracks of the attackers. This is congruent with all previous reports about the group’s activity.
Targeting Israeli organizations: Our telemetry did not detect non-Israeli organizations affected by the attacks. This APT group seems to specifically target Israeli entities.
Conclusion
In this article we provided a deep dive analysis of a recent destructive wiper attack carried out by the Iranian-linked Agonizing Serpens APT group. This attack is a part of a broader offensive campaign that targets Israeli organizations. Based on our telemetry, the most targeted organizations belong to the education and technology sectors.
Our investigation uncovered new tools in the group’s arsenal that include a set of three previously undocumented wipers, as well as a database extractor tool. Analysis of the new wipers revealed that the group has upgraded their capabilities, putting an emphasis on stealth and evasive techniques designed to bypass security solutions such as EDR technology.
As shown throughout our research, the Cortex XDR platform can detect and prevent the various stages of the attack lifecycle.
Protections and Mitigations
Palo Alto Networks customers receive protection from the different tools that were observed during the recent Agonizing Serpens campaign. The Cortex XDR and XSIAM platforms detect and prevent the execution flow described in the screenshots included in the previous section.
For Palo Alto Networks customers, our products and services provide the following coverage associated with this group.
Cortex XDR and XSIAM detect user and credential-based threats by analyzing user activity from multiple data sources including the following:
Endpoints
Network firewalls
Active Directory
Identity and access management solutions
Cloud workloads
Cortex XDR and XSIAM build behavioral profiles of user activity over time with machine learning. By comparing new activity to past activity, peer activity and the expected behavior of the entity, Cortex XDR and XSIAM detect anomalous activity indicative of credential-based attacks.
They also offer the following protections related to the attacks discussed in this post:
Prevent the execution of known malicious malware and also prevents the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module
Protect against credential gathering tools and techniques using the new Credential Gathering Protection available from Cortex XDR 3.4
Protect against exploitation of different vulnerabilities including ProxyShell and ProxyLogon using the Anti-Exploitation modules as well as Behavioral Threat Protection
Cortex XDR Pro detects post-exploitation activity, including credential-based attacks, with behavioral analytics.
If you think you might have been impacted or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America Toll-Free: 866.486.4842 (866.4.UNIT42)
EMEA: +31.20.299.3130
APAC: +65.6983.8730
Japan: +81.50.1790.0200
Palo Alto Networks has shared these findings 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.
Unit 42 stopped monitoring this threat and updating the brief on Aug. 14, 2025. Please refer to the Citrix website for the latest information.
On Oct. 10, 2023, Citrix published a patch for their Netscaler ADC and Netscaler Gateway products. One particular vulnerability that this patch is meant to mitigate has come to be known as Citrix Bleed (CVE-2023-4966).
This nickname was given because the vulnerability can leak sensitive information from the device’s memory, which can include session tokens. Attackers can then use these credentials to gain a foothold into systems via session hijacking. At the time of the patch, Citrix was unaware of ongoing attacks using this vulnerability but has since stated that they have observed threat actors using it.
The Unit 42 Incident Response and Managed Threat Hunting teams have observed ransomware groups exploiting Citrix Bleed. The Managed Threat Hunting team has also observed what appeared to be remote executions from Netscaler gateways in association with exploitation of this vulnerability.
Using Cortex Xpanse device signature data, our researchers observed nearly 8,000 IP addresses advertising a vulnerable version of NetScaler Gateway and 6,000 IPs advertising NetScaler ADC devices. The largest number (3,100) of these devices are located in the United States, 800 are in Germany, 450 in China and 400 in the United Kingdom.
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of Citrix Bleed.
Cortex Xpanse has published a new Threat Response Event for CVE-2023-4966 that can help identify generally exposed instances and those with known insecure versions.
Cortex XDR and XSIAM help detect and protect against post-exploitation activities.
Palo Alto Networks also recommends patching against this vulnerability as well as CVE-2023-4967, with the software update provided by Citrix.
Citrix Bleed (CVE-2023-4966) is a sensitive information disclosure vulnerability affecting Citrix Netscaler Gateway and Netscaler ADC products with a CVSS score of 9.4. It was patched by Citrix on Oct. 10, 2023.
This vulnerability can allow an unauthenticated attacker to steal session tokens via a specially crafted request and gain access to vulnerable systems. There was also a publication from security firm Assetnote that provides specific details as well as proof of concept (PoC) code to exploit this vulnerability.
Citrix reports that the following products are affected by this vulnerability:
NetScaler ADC and NetScaler Gateway 14.1 before 14.1-8.50
NetScaler ADC and NetScaler Gateway 13.1 before 13.1-49.15
NetScaler ADC and NetScaler Gateway 13.0 before 13.0-92.19
At the time of patch publication for CVE-2023-4966, Citrix stated that the vulnerability had been found internally and that they were unaware of attacks targeting it. However, they have since stated that they have received reports of attacks using this vulnerability for session hijacking. As such, they have advised people to immediately apply the patch to affected devices.
There are also public reports of various attackers using this vulnerability to hijack session tokens and use them to gain access. It’s also been reported that Python scripts have been distributed to ransomware affiliates to exploit and gain access to victim networks. The combination of these sensitive access systems and publicly available PoC code makes the exposure of this vulnerability extremely sensitive.
The Unit 42 Incident Response and Managed Threat Hunting teams have observed ransomware groups exploiting Citrix Bleed. Additional MTH observations are described in the following section.
Unit 42 Managed Threat Hunting Observations
The Unit 42 Managed Threat Hunting team observed multiple compromised users executing reconnaissance commands and dropping additional tooling on VDI hosts. This activity appeared to be remote executions from Netscaler gateways that were potentially exploited by threat actors.
In this incident, we observed remote PowerShell sessions that spawned cmd.exe and executed various reconnaissance commands, such as the following:
In addition, the threat actor downloaded multiple tools into the VDI hosts, using Chrome or Microsoft Edge browsers. Among the tools, we observed the following:
A binary called s.exe, which appeared to be XScan, a red teaming tool developed by Xteam that is capable of scanning vulnerabilities:
While this activity took place over the course of a week, the threat actor did not manage to move laterally outside of the VDI hosts.
Interim Guidance
Citrix has advised that there is no workaround for this vulnerability and strongly recommends patching the affected software immediately.
Unit 42 recommends prioritizing public-facing Netscaler Gateway and Netscaler ADC instances and applying patches to the affected products immediately.
Conclusion
Due to the ease of exploitation caused by the publicly availability of PoC code and the internet facing posture of these products, Palo Alto Networks recommends following Citrix’s guidance and immediately patching affected Citrix Netscaler products. Prioritize public-facing instances of these products or consider disabling if a patch cannot be immediately applied.
Palo Alto Networks and Unit 42 will continue to monitor the situation for updated information.
Palo Alto Networks customers receive protection from our products, as listed below. We will update this threat brief as more relevant information becomes available.
Palo Alto Networks Product Protections for Citrix Bleed
Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat.
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
Unit 42 Managed Threat Hunting Recommendations
By installing Cortex XDR agents on Citrix guests, VDI instances and widely throughout the environment, Cortex XDR will be able to provide detection, prevention and telemetry for any activity or attempted lateral movement that occurs after exploitation. The Unit 42 MTH team can be engaged to continuously hunt for threats hiding in your infrastructure, allowing you to take action before damage occurs.
Next-Generation Firewalls and Prisma Access With Advanced Threat Prevention
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of Citrix Bleed.
Cortex Xpanse
Cortex Xpanse has published a new Threat Response Event for CVE-2023-4966 that includes Attack Surface Rules for detecting Citrix Netscaler Gateway and Citrix Netscaler ADC, as shown in Figure 1. This Threat Response Event can identify both generally exposed instances and those with known insecure versions.
Figure 1. Citrix NetScaler ADC and Gateway [CVE-2023-4966] view in Cortex Xpanse.
Cortex XDR and XSIAM
Cortex XDR and XSIAM agents help detect and protect against post-exploitation activities using the agent protection modules such as Behavioral Threat Protection, Anti-Webshell Protection, Credential Gathering Protection, analytics and more. XSIAM customers with the ASM module can also take advantage of the Cortex Xpanse detection capabilities outlined above.
Indicators of Compromise
C:\Users\Public\Documents\s.exe - XScan
C:\Users\Public\Documents\dsquery.exe - Tool designed to search for an active directory objects
C:\Users\Public\Documents\dsget.exe - Tool designed to view active directory objects
PowerShell Empire is a popular post-exploitation framework used by threat actors, and it remains an ongoing threat. Using machine learning (ML) and artificial intelligence (AI) methods, we have developed an extremely effective system to detect Empire's command and control (C2) traffic.
In this article, we review the Empire framework, examine Empire C2 traffic and discuss issues affecting ML-based C2 detection. The primary issue is adversarial attacks, a category of AI attack that threat actors can use to poison or evade ML-based detection. We solved this challenge by developing a learning system using a more robust model with adversarial training. This robust learning system will effectively counter a threat actor’s attempt to evade ML-based C2 detection.
We review the concepts behind our Empire C2 robust learning system, and we discuss the effectiveness of training this model with both real-world traffic and AI-generated data.
Empire is powerful, flexible and easy to use, making it one of the most popular C2 frameworks in recent years. Various threat actors have been publicly documented using Empire, and this framework has also been associated with high-profile ransomware cases. Organizations that fail to detect and prevent Empire C2 in their networks face a huge potential impact.
Due to these factors, we tested against the Empire C2 framework when developing our ML-based robust learning system. Furthermore, effective detection of Empire C2 should also work well against similar C2 frameworks.
Characteristics of Empire C2 Traffic
Empire C2 traffic is web-based, and characteristics of this traffic are defined in a Malleable C2 profile. We previously reviewed Malleable C2 profiles used in Cobalt Strike, and the same concept applies for Empire. In this case, “Malleable” means easy to modify to meet different requirements.
Malleable C2 profiles follow an easily customizable template that allows attackers to tailor C2 traffic to their exact specifications. A Malleable C2 profile lends versatility to its associated framework or tool.
Malleable C2 Profile Format
A Malleable C2 profile defines variables used in C2 communications. Figure 1 shows the format of a Malleable C2 profile.
Figure 1. Format of a malleable C2 profile.
Variables associated with the Malleable C2 profile include sleeptime, useragent, uri, and various header lines for web traffic generated by both the client and the server. Figure 2 shows an example of these variables defined in a partial Malleable C2 profile.
Figure 2. A partial malleable C2 profile.
The partial profile in Figure 2 defines variables for HTTP GET requests used in the C2 web traffic. The section starting with http-get defines characteristics of traffic between a client and the C2 server.
The set uri function assigns the URI generated by the client sent to the server. The terms netbiosu and uri-append indicate the session key information will be encoded and appended to the URI of an HTTP request. The Cobalt Strike user guide provides more details on the Malleable C2 format also used by Empire.
Example of Empire C2 Traffic
Below, Figure 3 shows the HTTP traffic generated using the Malleable C2 profile from Figure 2.
Figure 3. HTTP traffic generated by Empire C2 based on the malleable C2 profile.
The first line in Figure 3 is a GET request from the HTTP request headers. This HTTP GET request reveals a session key as an ASCII string embedded in the URI between /CWoNaJLBo/VTNeW11212/ and /UTWOqV132/. This session key has been encoded by netbiosu as defined in the Malleable C2 profile from Figure 2.
The Challenge of ML-Based Empire C2 Traffic Detection
Understanding Empire’s use of Malleable C2 profiles is essential when developing a robust learning system that can detect Empire C2 traffic. Due to the endlessly possible customizations, a signature-based approach is not fully effective, so we developed a ML-based model for Empire C2 detection.
ML-Based Detection
When developing an ML-based detection model for Empire C2 traffic, we reviewed different options. Security defenders are using a growing number of ML and AI techniques for C2 detection.
One possible option is using traditional ML-based approaches. In the traditional approach, ML extracts characteristics of C2 activity from the traffic, a process known as feature engineering.
For example, researchers can extract features from network traffic such as URI parameters, cookie data and various HTTP headers to identify C2 traffic. We could build a model on these features using traditional ML algorithms such as logistic regression or support vector machine (SVM) to differentiate malicious C2 traffic from benign traffic.
Another option for C2 detection is deep learning. Deep learning is a subset of ML that relies on artificial neural networks to enhance performance, and it is effective at analyzing large datasets.
But developing a robust learning system for C2 detection requires countermeasures against adversaries who would exploit any vulnerabilities in the finished product.
Countering ML Through Adversarial Attacks
Adversarial attacks in AI and ML systems are not new. As more AI systems arise, adversaries are starting to target these services using various methods like evasion or poisoning attacks. Various sources have reported evasion as the most common AI attack method.
Evasion attacks target online AI systems by crafting inputs that mislead the AI model into making incorrect predictions. ML-based C2 detectors are particularly vulnerable to evasion attacks, as open-source frameworks with high configurability make it easier for attackers to generate a large number of inputs and identify those that can bypass AI systems.
Attackers can conduct evasion attacks by using Malleable C2 profiles. These profiles allow threat actors to more easily launch large-scale evasion attacks that explore the limits of Empire C2 detectors in a test environment. After discovering a profile that can bypass detection, threat actors can launch their attacks on real targets.
How an Attacker Might Use Empire Framework To Evade Detection
The following is an example of how a Malleable C2 profile can control the HTTP indicator.
In this case, an attacker intends to launch a privilege escalation attack on a victim using the profile shown below in Figure 4.
Figure 4. Mapping between the HTTP header and mal.profile.
Figure 4 shows both the profile configuration and the actual traffic generated during the C2 session. The profile sets the URI for its HTTP request with the value /api/v1/users. The profile also sets Base64 as the encoding algorithm for its session key and appends it to the URI.
During an attack, a threat actor could generate different HTTP requests by periodically updating their Malleable C2 profile. For example, the same attack could also use the profile shown below in Figure 5.
Figure 5. Updated mapping between the HTTP header and mal.profile.
Figure 5 shows HTTP traffic that is completely different from the example in Figure 4. As a result, a signature-based approach would miss the second attack if it only relies on a signature based on values seen in Figure 4.
Fortunately, an ML-based approach can train a reliable model to tolerate these variances if we provide enough training datasets. This is the approach we used for our robust learning system.
Empire C2 Robust Learning System
Our Empire C2 robust learning system provides a robust detection model capable of defeating evasion and other potential adversarial attacks. Our Empire C2 detection is built on top of a Convolutional Neural Network (CNN). CNN is a deep learning algorithm that can take in an input, assign importance to various aspects of the input and differentiate one from the other.
Our learning system starts with an Empire C2 fuzzer we developed that generates Empire C2 traffic simulating adversarial attacks. Traffic generated by our fuzzer is reviewed through a data quality monitor.
After traffic passes the quality check, we train our model on the results. Ultimately, we train our model both on collected Empire C2 traffic and internally generated Empire C2 traffic that simulates adversarial attacks.
Figure 6 provides an overview of our Empire C2 Robust Learning System.
Figure 6. The overview of our Empire C2 Robust Learning System.
The effectiveness of this system is based on our Empire C2 Fuzzer.
Empire C2 Fuzzer
Fuzzing is an automatic software testing or vulnerability detection approach. It introduces various inputs into a system and identifies those inputs that result in a failure, meaning the tested system did not work as intended. In this case, we leverage fuzzing to generate more C2 profiles of good quality for our robust learning purpose.
We developed an Empire C2 fuzzer using the Empire C2 framework. Our fuzzer takes a known Empire C2 profile as input and executes relevant functions in the Empire C2 framework to generate listeners, stagers and the associated Empire C2 traffic.
To generate more diverse results, the fuzzer applies random mutation and similar techniques to the original profile. Random mutation involves assigning a randomized value to a selected field in the profile. By manipulating the inputs, our fuzzer can generate a large number of examples for Empire C2 traffic, effectively simulating adversarial attacks.
Empire C2 Data Quality Monitoring
The feedback mechanism for our Empire C2 fuzzer provides code coverage for the current C2 profile being analyzed. Code coverage is a metric that measures the number of lines of code executed by our Empire C2 fuzzer with the input of a profile.
If two profiles have different logics, the code coverage should be different, since they trigger different code logics. This means C2 traffic generated by these two profiles should also be different.
We use code coverage to assess the quality of a newly generated profile. A profile that passes our quality check triggers a code coverage change. We define this as an unseen profile, meaning it is totally new to our generated dataset. Our goal is to collect as many unseen profiles as possible to train our Empire C2 detection model.
To meet this goal, we use an Empire C2 data quality monitoring engine. Our monitoring engine determines when to retrain the model by monitoring the number of unseen C2 profiles. Once the number of unseen profiles reaches a certain limit, our quality monitoring engine signals the need for retraining.
Empire C2 Traffic Generation Engine
We built our C2 traffic generation engine on top of the Empire C2 framework. We used this framework to generate C2 traffic for our dataset.
Our traffic generation engine will set up a client environment and mimic C2 communication with a C2 server. At the same time, it will collect C2 traffic samples and save them as packet captures (pcap) files for our model training.
Empire C2 Model Training
Our objective to improve C2 detection capability is twofold. We want to detect real-world cases of Empire activity like default C2 profiles used in red team engagements, and we need to simulate adversarial settings as discussed earlier.
To achieve these goals, we conducted the initial training on the original Empire C2 dataset with default C2 profiles. Subsequently, we harnessed the Empire C2 fuzzer to gather additional Empire C2 traffic that we incorporated into the training dataset for updating the model weights using various optimizers.
We categorize our dataset using three labels: “benign,” “non-adv” and “adv.”
“Benign” is C2 traffic from real-world uses, like penetration testing Empire C2 activity. “Non-adv” stands for non-adversarial attacks, indicating the datasets are from default profiles. Finally, the “adv” datasets are from simulated adversarial attack profiles.
We balanced our model detection on both “non-adv” and “adv” categories, designing our loss function to consider these labels. Our loss function is designed to increase the number of “adv” samples we create, which should increase our detection rate for adversarial attacks.
We employed a periodic training approach, relying on the feedback from our data quality monitoring engine. Whenever our data quality monitoring engine generated a signal, we captured the newly generated C2 traffic for model retraining.
The model is retrained on the new “adv” samples with the original dataset. Since our loss function will pay more attention to “adv” samples, the retrained model is guaranteed to have a good detection rate on adversarial (“adv”) samples.
Conclusion
Empire C2 is a widely used framework used by red team personnel and malicious threat actors. Empire's support for Malleable C2 profiles further enhances configurability and makes detection more difficult. We reviewed how Empire C2 works and discussed why we picked this framework to train our ML-based robust learning system.
Our approach trains the model with both real-world examples and simulated adversarial attacks, improving the robustness of our Empire C2 detection.
Palo Alto Networks customers receive protections from and mitigations for Empire C2 based attacks in the following ways:
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 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.
Get updates from Unit 42
Peace of mind comes from staying ahead of threats. Subscribe today.
Get the latest news, invites to events, and threat alerts
![Image 11 is a screenshot of a document to prepare for an interview. Common Questions. I flied to [redacted] several weeks ago. My parents got Covid and I decide to be with family members for awhile. Now, I am planning to go back to Los Angeles in 3 months. I am thinking that I could start work remotely right now, then I will be on board when I go back to LA.](https://unit42.paloaltonetworks.com/wp-content/uploads/2023/11/word-image-131292-11.png)
Get updates from Unit 42 