Blog
/
Network
/
March 20, 2025

Cyberhaven Supply Chain Attack: Exploiting Browser Extensions

In late 2024, Darktrace detected unusual activity linked to Cyberhaven's Chrome browser extension. Read more about Darktrace’s investigation here.
Inside the SOC
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
Written by
Rajendra Rushanth
Cyber Analyst
woman looking at laptop in the office buildingDefault blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog image
20
Mar 2025

The evolution of supply chain attacks

Supply chain attacks are becoming increasingly sophisticated. As network defenses improve, threat actors continuously adapt and refine their tactics, techniques, and procedures (TTPs) to achieve their goals. In recent years, this has led to a rise in the exploitation of trusted services and software, including legitimate browser extensions. Exploitation of these extensions can provide adversaries with a stealthy means to infiltrate target networks and access high-value accounts undetected.

A notable example of this trend was the compromise of the Cyberhaven Chrome extension at the end of 2024. This incident appeared to be part of a broader campaign targeting multiple Chrome browser extensions, highlighting the evolving nature of supply chain attacks [1].

What is Cyberhaven?

Cyberhaven, a US-based data security organization, experienced a security breach on December 24, 2024, when a phishing attack reportedly compromised one of their employee's credentials [2]. This allowed attackers to publish a malicious version of the Cyberhaven Chrome extension, which exfiltrated cookies and authenticated sessions from targeted websites. The malicious extension was active from December 25 to December 26 – a time when most businesses and employees were out of office and enjoying the festive period, a fact not lost on threat actors. The attackers, likely a well-organized and financially motivated group, compromised more than 30 additional Chrome extensions, affecting more than 2.6 million users [3]. They used sophisticated phishing techniques to authorize malicious OAuth applications, bypassing traditional security measures and exploiting vulnerabilities in OAuth authorizations. The primary motive appeared to be financial gain, targeting high-value platforms like social media advertising and AI services [4].

In late December 2024, multiple Darktrace customers were compromised via the Cyberhaven Chrome extension; this blog will primarily focus on Darktrace / NETWORK detections from one affected customer.

Darktrace’s coverage of Cyberhaven compromises

On December 26, 2024, Darktrace identified a series of suspicious activities across multiple customer environments, uncovering a structured attack sequence that progressed from initial intrusion to privilege escalation and data exfiltration. The attack was distributed through a malicious update to the Cyberhaven Chrome extension [2]. The malicious update established a foothold in customer environments almost immediately, leading to further anomalies.

As with other Chrome browser extensions, Cyberhaven Chrome extensions were updated automatically with no user interaction required. However, in this instance, the automatic update included a malicious version which was deployed to customer environments. This almost immediately introduced unauthorized activity, allowing attackers to establish a foothold in customer networks. The update allowed attackers to execute their objectives in the background, undetected by traditional security tools that rely on known indicators of compromise (IoCS) rather than identifying anomalies.

While multiple customer devices were seen connecting to cyberhaven[.]io, a legitimate Cyberhaven domain, Darktrace detected persistent beaconing behavior to cyberhavenext[.]pro, which appeared to be attempting to masquerade as another legitimate Cyberhaven domain. Darktrace recognized this activity as unusual, triggering several model alerts in Darktrace / NETWORK to highlight the persistent outbound connections to the suspicious domain.

Further analysis of external connectivity patterns indicated  an increase in anomalous HTTP requests alongside this beaconing activity. Multiple open-source intelligence (OSINT) sources also suggest that the cyberhavenext[.]pro endpoint is associated with malicious activities [5].

Darktrace / NETWORK’s detection of beaconing activity to cyberhavenext[.]pro
Figure 1: Darktrace / NETWORK’s detection of beaconing activity to cyberhavenext[.]pro

Analysis using Darktrace’s Advanced Search revealed that some of these connections were directed to the suspicious external IP address 149.28.124[.]84. Further investigation confirmed that the IP correlated with two SSL hostnames, including the malicious cyberhavenext[.]pro, further reinforcing its connection to the attack infrastructure.

Darktrace Advanced Search analysis showing the IP address 149.28.124[.]84 correlating to two SSL hostnames, one of which is cyberhavenext[.]pro.
Figure 2: Darktrace Advanced Search analysis showing the IP address 149.28.124[.]84 correlating to two SSL hostnames, one of which is cyberhavenext[.]pro.

Between December 23 and December 27, Darktrace observed sustained beaconing-like activity from affected devices on the customer’s network.

Darktrace’s detection of beaconing activities from a customer device to the endpoint 149.28.124[.]84 between December 23 and December 27.
Figure 3: Darktrace’s detection of beaconing activities from a customer device to the endpoint 149.28.124[.]84 between December 23 and December 27.

Darktrace observed 27 unique devices connecting to the malicious command-and-control (C2) infrastructure as far back as December 3. While most connections were brief, they represented an entry point for malicious activity. Over a two-day period, two devices transmitted 5.57 GiB of incoming data and 859.37 MiB of outgoing data, generating over 3 million log events across SSL, HTTP, and connection data.

Subsequent analysis identified a significant increase in unauthorized data transfers to the aforementioned 149.28.124[.]84 IP on another customer network, highlighting the potential broader impact of this compromise. The volume and frequency of these transfers suggested that attackers were leveraging automated data collection techniques, further underscoring the sophistication of the attack.

Darktrace’s detection of the likely exfiltration of 859.37 MiB to the endpoint 149.28.124[.]84.
Figure 4: Darktrace’s detection of the likely exfiltration of 859.37 MiB to the endpoint 149.28.124[.]84.

External research suggested that once active, the Cyberhaven extension would begin silently collecting session cookies and authentication tokens, specifically targeting high-value accounts such as Facebook Ads accounts [4]. Darktrace’s analysis of another affected customer noted many HTTP POST connections directed to a specific URI ("ai-cyberhaven"), while GET requests contained varying URIs prefixed with "/php/urlblock?args=AAAh....--redirect." This activity indicated an exfiltration mechanism, consistent with techniques observed in other compromised Chrome extensions. By compromising session cookies, attackers could potentially gain administrative access to connected accounts, further escalating their privileges [4].

Conclusion

This incident highlights the importance of monitoring not just endpoint security, but also cloud and browser-based security solutions, as attackers increasingly target these trusted and oft overlooked vectors.

Ultimately, by focusing on anomaly detection and behavioral analysis rather than static signatures and lists of ‘known bads’, Darktrace was able to successfully detect devices affected by the Cyberhaven Chrome browser extension compromise, by identifying activity that would likely have been considered legitimate and benign by traditional security solutions.

This compromise also serves as a reminder that supply chain attacks are not limited to traditional software vendors. Browser extensions, cloud-based applications, and SaaS services are equally vulnerable, as evidenced by Darktrace's detection of Balada Injector malware exploiting WordPress vulnerabilities to gain unauthorized network access [6]. Therefore, increased targeting of browser-based security tools, and a greater exploitation of OAuth and session hijacking techniques are to be expected. Attackers will undoubtedly refine their methods to infiltrate legitimate vendors and distribute malicious updates through trusted channels. By staying informed, vigilant, and proactive, organizations can mitigate exposure to evolving supply chain threats and safeguard their critical assets from emerging browser-based attack techniques.

Credit to Rajendra Rushanth (Cyber Analyst) Justin Torres (Senior Cyber Analyst) and Ryan Traill (Analyst Content Lead)

[related-resource]

Appendices

Darktrace Model Detections

·       Compromise / Beaconing Activity To External Rare (AP: C2 Comms)

·       Compromise / Beacon for 4 Days (AP: C2 Comms)

·       Compromise / HTTP Beaconing to Rare Destination (AP: C2 Comms)

·       Device / Suspicious Domain (AP: C2 Comms, AP: Tooling)

·       Compromise / Sustained TCP Beaconing Activity To Rare Endpoint (AP: C2 Comms)

·       Anomalous Server Activity / Rare External from Server (AP: C2 Comms)

·       Anomalous Connection / Multiple Failed Connections to Rare Endpoint (AP: C2 Comms)

·       Anomalous Server Activity / Anomalous External Activity from Critical Network Device (AP: C2 Comms)

·       Compromise / Slow Beaconing Activity To External Rare (AP: C2 Comms)

·       Compromise / Repeating Connections Over 4 Days (AP: C2 Comms)

·       Anomalous Connection / Multiple HTTP POSTs to Rare Hostname (AP: C2 Comms)

·       Anomalous Server Activity / Outgoing from Server (AP: C2 Comms)

·       Compromise / High Volume of Connections with Beacon Score (AP: C2 Comms)

·       Compromise / Large Number of Suspicious Failed Connections (AP: C2 Comms)

·       Email Nexus / Connection to Hijacked Correspondent Link

·       Compromise / Suspicious TLS Beaconing To Rare External (AP: C2 Comms)

·       Compromise / Quick and Regular Windows HTTP Beaconing (AP: C2 Comms)

List of IoCs

IoC - Type - Description + Confidence

cyberhavenext[.]pro - Hostname - Used for C2 communications and data exfiltration (cookies and session tokens)

149.28.124[.]84 - IP - Associated with malicious infrastructure

45.76.225[.]148 - IP - Associated with malicious infrastructure

136.244.115[.]219 - IP - Associated with malicious infrastructure

MITRE ATT&CK Mapping

Tactic – Technique – Sub-Technique

INITIAL ACCESS - T1176 - Browser Extensions

EXECUTION - T1204.002 - Malicious Browser Extensions

PERSISTENCE - T1176 - Browser Extensions

COMMAND AND CONTROL - T1071.001 - Web Protocols

COMMAND AND CONTROL - T1001 - Data Obfuscation

CREDENTIAL ACCESS - T1539 - Steal Web Session Cookie

DISCOVERY - T1518.001 - Security Software Discovery

LATERAL MOVEMENT - T1557.003 - Man-in-the-Browser

EXFILTRATION - T1041 - Exfiltration Over C2 Channel

EXFILTRATION - T1567.002 - Exfiltration to Cloud Storage

IMPACT - T1583.006 - Session Hijacking

References

[1] https://thehackernews.com/2024/12/16-chrome-extensions-hacked-exposing.html

[2] https://www.cyberhaven.com/blog/cyberhavens-chrome-extension-security-incident-and-what-were-doing-about-it

[3] https://www.infosecurity-magazine.com/news/chrome-browser-extensions-hijacked/

[4] https://www.theverge.com/2024/12/28/24330758/chrome-extension-cyberhaven-hijack-phishing-cyberattack-facebook-ads-authentication-theft

[5] https://www.virustotal.com/gui/domain/cyberhavenext.pro

[6] https://darktrace.com/blog/balada-injector-darktraces-investigation-into-the-malware-exploiting-wordpress-vulnerabilities

Get the latest insights on emerging cyber threats

This report explores the latest trends shaping the cybersecurity landscape and what defenders need to know in 2025

Inside the SOC
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
Written by
Rajendra Rushanth
Cyber Analyst

More in this series

No items found.

Blog

/

Cloud

/

August 11, 2025

Minimizing Permissions for Cloud Forensics: A Practical Guide to Tightening Access in the Cloud

Cloud permissions cloud forensicsDefault blog imageDefault blog image

Most cloud environments are over-permissioned and under-prepared for incident response.

Security teams need access to logs, snapshots, and configuration data to understand how an attack unfolded, but giving blanket access opens the door to insider threats, misconfigurations, and lateral movement.

So, how do you enable forensics without compromising your security posture?

The dilemma: balancing access and security

There is a tension between two crucial aspects of cloud security that create a challenge for cloud forensics.

One aspect is the need for Security Operations Center (SOC) and Incident Response (IR) teams to access comprehensive data for investigating and resolving security incidents.

The other conflicting aspect is the principle of least privilege and minimal manual access advocated by cloud security best practices.

This conflict is particularly pronounced in modern cloud environments, where traditional physical access controls no longer apply, and infrastructure-as-code and containerization have transformed the landscape.

There are several common but less-than-ideal approaches to this challenge:

  • Accepting limited data access, potentially leaving incidents unresolved
  • Granting root-level access during major incidents, risking further compromise

Relying on cloud or DevOps teams to retrieve data, causing delays and potential miscommunication

[related-resource]

Challenges in container forensics

Containers present unique challenges for forensic investigations due to their ephemeral and dynamic nature. The orchestration and management of containers, whether on private clusters or using services like AWS Elastic Kubernetes Service (EKS), introduce complexities in capturing and analyzing forensic data.

To effectively investigate containers, it's often necessary to acquire the underlying volume of a node or perform memory captures. However, these actions require specific Identity and Access Management (IAM) and network access to the node, as well as familiarity with the container environment, which may not always be straightforward.

An alternative method of collection in containerized environments is to utilize automated tools to collect this evidence. Since they can detect malicious activity and collect relevant data without needing human input, they can act immediately, securing evidence that might be lost by the time a human analyst is available to collect it manually.

Additionally, automation can help significantly with access and permissions. Instead of analysts needing the correct permissions for the account, service, and node, as well as deep knowledge of the container service itself, for any container from which they wish to collect logs. They can instead collect them, and have them all presented in one place, at the click of a button.

A better approach: practical strategies for cloud forensics

It's crucial to implement strategies that strike a balance between necessary access and stringent security controls.

Here are several key approaches:

1. Dedicated cloud forensics accounts

Establishing a separate cloud account or subscription specifically for forensic activities is foundational. This approach isolates forensic activities from regular operations, preventing potential contamination from compromised environments. Dedicated accounts also enable tighter control over access policies, ensuring that forensic operations do not inadvertently expose sensitive data to unauthorized users.

A separate account allows for:

  • Isolation: The forensic investigation environment is isolated from potentially compromised environments, reducing the risk of cross-contamination.
  • Tighter access controls: Policies and controls can be more strictly enforced in a dedicated account, reducing the likelihood of unauthorized access.
  • Simplified governance: A clear and simplified chain of custody for digital evidence is easier to maintain, ensuring that forensic activities meet legal and regulatory requirements.

For more specifics:

2. Cross-account roles with least privilege

Using cross-account IAM roles, the forensics account can access other accounts, but only with permissions that are strictly necessary for the investigation. This ensures that the principle of least privilege is upheld, reducing the risk of unauthorized access or data exposure during the forensic process.

3. Temporary credentials for just-in-time access

Leveraging temporary credentials, such as AWS STS tokens, allows for just-in-time access during an investigation. These credentials are short-lived and scoped to specific resources, ensuring that access is granted only when absolutely necessary and is automatically revoked after the investigation is completed. This reduces the window of opportunity for potential attackers to exploit elevated permissions.

For AWS, you can use commands such as:

aws sts get-session-token --duration-seconds 43200

aws sts assume-role --role-arn role-to-assume --role-session-name "sts-session-1" --duration-seconds 43200

For Azure, you can use commands such as:

az ad app credential reset --id <appId> --password <sp_password> --end-date 2024-01-01

For more details for Google Cloud environments, see “Create short-lived credentials for a service account” and the request.time parameter.

4. Tag-based access control

Pre-deploying access control based on resource tags is another effective strategy. By tagging resources with identifiers like "Forensics," access can be dynamically granted only to those resources that are relevant to the investigation. This targeted approach minimizes the risk of overexposure and ensures that forensic teams can quickly and efficiently access the data they need.

For example, in AWS:

Condition: StringLike: aws:ResourceTag/Name: ForensicsEnabled

Condition: StringLike: ssm:resourceTag/SSMEnabled: True

For example, in Azure:

"Condition": "StringLike(Resource[Microsoft.Resources/tags.example_key], '*')"

For example, in Google Cloud:

expression: > resource.matchTag('tagKeys/ForensicsEnabled', '*')

Tighten access, enhance security

The shift to cloud environments demands a rethinking of how we approach forensic investigations. By implementing strategies like dedicated cloud forensic accounts, cross-account roles, temporary credentials, and tag-based access control, organizations can strike the right balance between access and security. These practices not only enhance the effectiveness of forensic investigations but also ensure that access is tightly controlled, reducing the risk of exacerbating an incident or compromising the investigation.

Find the right tools for your cloud security

Darktrace delivers a proactive approach to cyber resilience in a single cybersecurity platform, including cloud coverage.

Darktrace’s cloud offerings have been bolstered with the acquisition of Cado Security Ltd., which enables security teams to gain immediate access to forensic-level data in multi-cloud, container, serverless, SaaS, and on-premises environments.

In addition to having these forensics capabilities, Darktrace / CLOUD is a real-time Cloud Detection and Response (CDR) solution built with advanced AI to make cloud security accessible to all security teams and SOCs. By using multiple machine learning techniques, Darktrace brings unprecedented visibility, threat detection, investigation, and incident response to hybrid and multi-cloud environments.

Continue reading
About the author
Calum Hall
Technical Content Researcher

Blog

/

Network

/

August 11, 2025

Ivanti Under Siege: Investigating the Ivanti Endpoint Manager Mobile Vulnerabilities (CVE-2025-4427 & CVE-2025-4428)

ivanti cve exploitation edge infrastructure Default blog imageDefault blog image

Ivanti & Edge infrastructure exploitation

Edge infrastructure exploitations continue to prevail in today’s cyber threat landscape; therefore, it was no surprise that recent Ivanti Endpoint Manager Mobile (EPMM) vulnerabilities CVE-2025-4427 and CVE-2025-4428 were exploited targeting organizations in critical sectors such as healthcare, telecommunications, and finance across the globe, including across the Darktrace customer base in May 2025.

Exploiting these types of vulnerabilities remains a popular choice for threat actors seeking to enter an organization’s network to perform malicious activity such as cyber espionage, data exfiltration and ransomware detonation.

Vulnerabilities in Ivanti EPMM

Ivanti EPMM allows organizations to manage and configure enterprise mobile devices. On May 13, 2025, Ivanti published a security advisory [1] for their Ivanti Endpoint Manager Mobile (EPMM) devices addressing a medium and high severity vulnerability:

  • CVE-2025-4427, CVSS: 5.6: An authentication bypass vulnerability
  • CVE-2025-4428, CVSS: 7.2: Remote code execution vulnerability

Successfully exploiting both vulnerabilities at the same time could lead to unauthenticated remote code execution from an unauthenticated threat actor, which could allow them to control, manipulate, and compromise managed devices on a network [2].

Shortly after the disclosure of these vulnerabilities, external researchers uncovered evidence that they were being actively exploited in the wild and identified multiple indicators of compromise (IoCs) related to post-exploitation activities for these vulnerabilities [2] [3]. Research drew particular attention to the infrastructure utilized in ongoing exploitation activity, such as leveraging the two vulnerabilities to eventually deliver malware contained within ELF files from Amazon Web Services (AWS) S3 bucket endpoints and to deliver KrustyLoader malware for persistence. KrustyLoader is a Rust based malware that was discovered being downloaded in compromised Ivanti Connect Secure systems back in January 2024 when the zero-day critical vulnerabilities; CVE-2024-21887 and CVE-2023-46805 [10].

This suggests the involvement of the threat actor UNC5221, a suspected China-nexus espionage actor [3].

In addition to exploring the post-exploit tactics, techniques, and procedures (TTPs) observed for these vulnerabilities across Darktrace’s customer base, this blog will also examine the subtle changes and similarities in the exploitation of earlier Ivanti vulnerabilities—specifically Ivanti Connect Secure (CS) and Policy Secure (PS) vulnerabilities CVE-2023-46805 and CVE-2024-21887 in early 2024, as well as CVE-2025-0282 and CVE-2025-0283, which affected CS, PS, and Zero Trust Access (ZTA) in January 2025.

Darktrace Coverage

In May 2025, shortly after Ivanti disclosed vulnerabilities in their EPMM product, Darktrace’s Threat Research team identified attack patterns potentially linked to the exploitation of these vulnerabilities across multiple customer environments. The most noteworthy attack chain activity observed included exploit validation, payload delivery via AWS S3 bucket endpoints, subsequent delivery of script-based payloads, and connections to dpaste[.]com, possibly for dynamic payload retrieval. In a limited number of cases, connections were also made to an IP address associated with infrastructure linked to SAP NetWeaver vulnerability CVE-2025-31324, which has been investigated by Darktrace in an earlier case.

Exploit Validation

Darktrace observed devices within multiple customer environments making connections related to Out-of-Band Application Security Testing (OAST). These included a range of DNS requests and connections, most of which featured a user agent associated with the command-line tool cURL, directed toward associated endpoints. The hostnames of these endpoints consisted of a string of randomly generated characters followed by an OAST domain, such as 'oast[.]live', 'oast[.]pro', 'oast[.]fun', 'oast[.]site', 'oast[.]online', or 'oast[.]me'. OAST endpoints can be leveraged by malicious actors to trigger callbacks from targeted systems, such as for exploit validation. This activity, likely representing the initial phase of the attack chain observed across multiple environments, was also seen in the early stages of previous investigations into the exploitation of Ivanti vulnerabilities [4]. Darktrace also observed similar exploit validation activity during investigations conducted in January 2024 into the Ivanti CS vulnerabilities CVE-2023-46805 and CVE-2024-21887.

Payload Delivery via AWS

Devices across multiple customer environments were subsequently observed downloading malicious ELF files—often with randomly generated filenames such as 'NVGAoZDmEe'—from AWS S3 bucket endpoints like 's3[.]amazonaws[.]com'. These downloads occurred over HTTP connections, typically using wget or cURL user agents. Some of the ELF files were later identified to be KrustyLoader payloads using open-source intelligence (OSINT). External researchers have reported that the KrustyLoader malware is executed in cases of Ivanti EPMM exploitation to gain and maintain a foothold in target networks [2].

In one customer environment, after connections were made to the endpoint fconnect[.]s3[.]amazonaws[.]com, Darktrace observed the target system downloading the ELF file mnQDqysNrlg via the user agent Wget/1.14 (linux-gnu). Further investigation of the file’s SHA1 hash (1dec9191606f8fc86e4ae4fdf07f09822f8a94f2) linked it to the KrustyLoader malware [5]. In another customer environment, connections were instead made to tnegadge[.]s3[.]amazonaws[.]com using the same user agent, from which the ELF file “/dfuJ8t1uhG” was downloaded. This file was also linked to KrustyLoader through its SHA1 hash (c47abdb1651f9f6d96d34313872e68fb132f39f5) [6].

The pattern of activity observed so far closely mirrors previous exploits associated with the Ivanti vulnerabilities CVE-2023-46805 and CVE-2024-21887 [4]. As in those cases, Darktrace observed exploit validation using OAST domains and services, along with the use of AWS endpoints to deliver ELF file payloads. However, in this instance, the delivered payload was identified as KrustyLoader malware.

Later-stage script file payload delivery

In addition to the ELF file downloads, Darktrace also detected other file downloads across several customer environments, potentially representing the delivery of later-stage payloads.

The downloaded files included script files with the .sh extension, featuring randomly generated alphanumeric filenames. One such example is “4l4md4r.sh”, which was retrieved during a connection to the IP address 15.188.246[.]198 using a cURL-associated user agent. This IP address was also linked to infrastructure associated with the SAP NetWeaver remote code execution vulnerability CVE-2025-31324, which enables remote code execution on NetWeaver Visual Composer. External reporting has attributed this infrastructure to a China-nexus state actor [7][8][9].

In addition to the script file downloads, devices on some customer networks were also observed making connections to pastebin[.]com and dpaste[.]com, two sites commonly used to host or share malicious payloads or exploitation instructions [2]. Exploits, including those targeting Ivanti EPMM vulnerabilities, can dynamically fetch malicious commands from sites like dpaste[.]com, enabling threat actors to update payloads. Unlike the previously detailed activity, this behavior was not identified in any prior Darktrace investigations into Ivanti-related vulnerabilities, suggesting a potential shift in the tactics used in post-exploitation stages of Ivanti attacks.

Conclusion

Edge infrastructure vulnerabilities, such as those found in Ivanti EPMM and investigated across customer environments with Darktrace / NETWORK, have become a key tool in the arsenal of attackers in today’s threat landscape. As highlighted in this investigation, while many of the tactics employed by threat actors following successful exploitation of vulnerabilities remain the same, subtle shifts in their methods can also be seen.

These subtle and often overlooked changes enable threat actors to remain undetected within networks, highlighting the critical need for organizations to maintain continuous extended visibility, leverage anomaly based behavioral analysis, and deploy machine speed intervention across their environments.

Credit to Nahisha Nobregas (Senior Cyber Analyst) and Anna Gilbertson (Senior Cyber Analyst)

Appendices

Mid-High Confidence IoCs

(IoC – Type - Description)

-       trkbucket.s3.amazonaws[.]com – Hostname – C2 endpoint

-       trkbucket.s3.amazonaws[.]com/NVGAoZDmEe – URL – Payload

-       tnegadge.s3.amazonaws[.]com – Hostname – C2 endpoint

-       tnegadge.s3.amazonaws[.]com/dfuJ8t1uhG – URL – Payload

-       c47abdb1651f9f6d96d34313872e68fb132f39f5 - SHA1 File Hash – Payload

-       4abfaeadcd5ab5f2c3acfac6454d1176 - MD5 File Hash - Payload

-       fconnect.s3.amazonaws[.]com – Hostname – C2 endpoint

-       fconnect.s3.amazonaws[.]com/mnQDqysNrlg – URL - Payload

-       15.188.246[.]198 – IP address – C2 endpoint

-       15.188.246[.]198/4l4md4r.sh?grep – URL – Payload

-       185.193.125[.]65 – IP address – C2 endpoint

-       185.193.125[.]65/c4qDsztEW6/TIGHT_UNIVERSITY – URL – C2 endpoint

-       d8d6fe1a268374088fb6a5dc7e5cbb54 – MD5 File Hash – Payload

-       64.52.80[.]21 – IP address – C2 endpoint

-       0d8da2d1.digimg[.]store – Hostname – C2 endpoint

-       134.209.107[.]209 – IP address – C2 endpoint

Darktrace Model Detections

-       Compromise / High Priority Tunnelling to Bin Services (Enhanced Monitoring Model)

-       Compromise / Possible Tunnelling to Bin Services

-       Anomalous Server Activity / New User Agent from Internet Facing System

-       Compliance / Pastebin

-       Device / Internet Facing Device with High Priority Alert

-       Anomalous Connection / Callback on Web Facing Device

-       Anomalous File / Script from Rare External Location

-       Anomalous File / Incoming ELF File

-       Device / Suspicious Domain

-       Device / New User Agent

-       Anomalous Connection / Multiple Connections to New External TCP Port

-       Anomalous Connection / New User Agent to IP Without Hostname

-       Anomalous File / EXE from Rare External Location

-       Anomalous File / Internet Facing System File Download

-       Anomalous File / Multiple EXE from Rare External Locations

-       Compromise / Suspicious HTTP and Anomalous Activity

-       Device / Attack and Recon Tools

-       Device / Initial Attack Chain Activity

-       Device / Large Number of Model Alerts

-       Device / Large Number of Model Alerts from Critical Network Device

References

1.     https://forums.ivanti.com/s/article/Security-Advisory-Ivanti-Endpoint-Manager-Mobile-EPMM?language=en_US

2.     https://blog.eclecticiq.com/china-nexus-threat-actor-actively-exploiting-ivanti-endpoint-manager-mobile-cve-2025-4428-vulnerability

3.     https://www.wiz.io/blog/ivanti-epmm-rce-vulnerability-chain-cve-2025-4427-cve-2025-4428

4.     https://www.darktrace.com/blog/the-unknown-unknowns-post-exploitation-activities-of-ivanti-cs-ps-appliances

5.     https://www.virustotal.com/gui/file/ac91c2c777c9e8638ec1628a199e396907fbb7dcf9c430ca712ec64a6f1fcbc9/community

6.     https://www.virustotal.com/gui/file/f3e0147d359f217e2aa0a3060d166f12e68314da84a4ecb5cb205bd711c71998/community

7.     https://www.virustotal.com/gui/ip-address/15.188.246.198

8.     https://blog.eclecticiq.com/china-nexus-nation-state-actors-exploit-sap-netweaver-cve-2025-31324-to-target-critical-infrastructures

9.     https://www.darktrace.com/blog/tracking-cve-2025-31324-darktraces-detection-of-sap-netweaver-exploitation-before-and-after-disclosure

10.  https://www.synacktiv.com/en/publications/krustyloader-rust-malware-linked-to-ivanti-connectsecure-compromises

The content provided in this blog is published by Darktrace for general informational purposes only and reflects our understanding of cybersecurity topics, trends, incidents, and developments at the time of publication. While we strive to ensure accuracy and relevance, the information is provided “as is” without any representations or warranties, express or implied. Darktrace makes no guarantees regarding the completeness, accuracy, reliability, or timeliness of any information presented and expressly disclaims all warranties.

Nothing in this blog constitutes legal, technical, or professional advice, and readers should consult qualified professionals before acting on any information contained herein.

Any references to third-party organizations, technologies, threat actors, or incidents are for informational purposes only and do not imply affiliation, endorsement, or recommendation.

Darktrace, its affiliates, employees, or agents shall not be held liable for any loss, damage, or harm arising from the use of or reliance on the information in this blog.

The cybersecurity landscape evolves rapidly, and blog content may become outdated or superseded. We reserve the right to update, modify, or remove any content without notice.

Continue reading
About the author
Nahisha Nobregas
SOC Analyst
Your data. Our AI.
Elevate your network security with Darktrace AI