Blog
/
Compliance
/
May 22, 2026

The CIP-015 Countdown: What Utilities Should Be Doing Before October 2028

CIP-015 is pushing utilities beyond perimeter security toward continuous internal network visibility. This blog explores what the standard requires, why anomaly detection and evidence retention matter, and how utilities can build a defensible INSM capability before the October 2028 compliance deadline.
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
Jeffrey Macre
Principal Industrial Security Solutions Architect
cip-015, utilities, cybersecurityDefault blog image
22
May 2026

CIP-015 what you need to know

The electric sector already knows CIP-015 is coming. The better question is whether utilities are using the time before October 1, 2028 to build an Internal Network Security Monitoring program that is defensible, auditable, and operationally useful.

I have spent most of my OT cybersecurity career around the power sector, from early NERC CIP program work as an asset owner, to consulting with utilities ranging from small municipalities and rural cooperatives to some of the largest power companies in the country, to now working with technology that helps organizations improve visibility and detection across IT and OT. One lesson has been consistent across all of those roles: compliance is not just about having a control in place. It is about being able to prove the control works.

That is where CIP-015 becomes important.

The standard is not simply asking utilities to deploy a tool inside the Electronic Security Perimeter and call the job done. CIP-015 is about improving the probability of detecting anomalous or unauthorized network activity so that organizations can improve response and recovery from an attack. That purpose is directly stated in the standard itself. (NERC)

The real work between now and October 2028 is not just buying technology. It is building an INSM capability that can collect the right data, detect meaningful activity, support evaluation, retain the right evidence, and protect that evidence from unauthorized deletion or modification.

Why CIP-015 exists

CIP-015 exists because perimeter security alone does not solve the internal visibility problem.

For years, many CIP controls have focused heavily on access management, segmentation, patching, logging, training, and other security practices that help reduce the likelihood of unauthorized access. Those controls still matter. But they do not fully answer what happens after an attacker, insider, compromised vendor account, misused credential, or malicious activity is already operating inside a trusted environment.

NERC’s technical rationale explains that Internal Network Security Monitoring focuses on the collection and analysis of network communications inside a “trust zone,” such as an ESP. In other words, CIP-015 is not only about defending the edge. It is about understanding what is happening inside the environment once traffic is already within the trusted zone. (NERC)

That is the internal visibility gap utilities need to close.

Why traditional security monitoring does not fully satisfy CIP-015

One mistake utilities should avoid is assuming that existing security event monitoring automatically solves CIP-015.

Many organizations already have logging programs tied to CIP-007, SIEM use cases, host-level security events, authentication logs, malware alerts, and incident response workflows. Those capabilities remain valuable, but they are not the same as Internal Network Security Monitoring.

Security event monitoring often tells you what happened on or to a system. INSM is intended to help show what is happening between systems, across network communications, devices, connections, and internal traffic patterns. That distinction is especially important in OT environments where adversaries may use legitimate pathways, valid credentials, native protocols, remote access, engineering workstations, or trusted systems to move inside the environment.

CIP-015 pushes utilities toward a different level of visibility: not just “did a system log something,” but “can we see and evaluate anomalous or unauthorized activity occurring inside the ESP?”

What CIP-015 requires

At a high level, CIP-015-1 requires three core capabilities.

Requirement R1: Monitoring internal network activity  

First, under Requirement R1, Responsible Entities must implement, using a risk-based rationale, network data feeds to monitor network activity, including connections, devices, and network communications. They must also implement one or more methods to detect anomalous network activity using those feeds, and one or more methods to evaluate detected anomalous activity to determine further actions.

Requirement R2: Retaining INSM data for investigations

Second, under Requirement R2, entities must retain INSM data associated with anomalous network activity at least until the related evaluation and action are complete. The standard also notes that entities are not required to retain INSM data that is not relevant to detected anomalous activity.

Requirement R3: Protecting monitoring data from tampering

Third, under Requirement R3, entities must protect INSM data collected for R1 and retained for R2 from unauthorized deletion or modification.

Those requirements may sound straightforward, but implementation is where the challenge begins.

What should utilities be asking themselves for CIP-015?

  • Where are we collecting network data inside the ESP, and why are those feeds defensible?
  • What methods are we using to detect anomalous network activity?
  • How do we distinguish meaningful anomalous behavior from normal operational change?
  • Who evaluates detections, and how are decisions documented?
  • What data is retained, and how is it protected from unauthorized deletion or modification?
  • Can we produce evidence that proves this process has worked over time?

Those answers matter because auditors will not be looking for marketing claims. They will be looking for evidence.

Why anomaly detection is central to CIP-015 compliance

One of the most important parts of CIP-015 is also one of the easiest to oversimplify: the word anomalous.

NERC’s technical rationale provides useful context. It explains that, as used in CIP-015, “anomalous” refers to unexpected, undesired, unusual, or undetermined network traffic. It also makes clear that the term does not refer to any single proprietary technology commonly marketed as “anomaly detection.”

Understanding static baselines vs true anomaly detection

A static baseline is not the same thing as meaningful anomaly detection. If a platform observes traffic for a limited period of time, assumes that observed behavior is “normal,” and then flags future deviations without deeper context, the result can be noisy, brittle, and operationally frustrating.

In real OT environments, “normal” is not fixed. Maintenance windows, vendor access, failovers, engineering changes, testing activity, backup jobs, and operational shifts can all change behavior. Detection has to keep learning and understand context. Otherwise, the organization may end up with alerts that are technically anomalous but not practically useful.

CIP-015 is not just about producing anomalies. It is about producing meaningful detections that can be evaluated, documented, and acted upon.

What should utilities consider when looking for anomaly detection tools

Some technologies were built around behavioral analysis and anomaly detection long before CIP-015 existed. What practitioners should look for is if the technology behind the phrase can identify meaningful deviations, provide context, reduce noise, and support the evaluation and evidence expectations of the standard.

Utilities should be cautious of vendor positioning that treats “anomaly” as a simple compliance keyword. This is especially important when evaluating tools historically built around signature-based, threat-based, or rule-based detection methods that are now being positioned as anomaly detection because CIP-015 uses the term.

A platform does not solve CIP-015 simply because it can baseline traffic or generate alerts when something changes.

The question is not: Can this tool create alerts?

The question is: Can this tool identify meaningful anomalous activity with enough context, prioritization, and evidence to support evaluation and response?

Why evidence and audit readiness matter for CIP-015

In NERC CIP, the control is only part of the story. Evidence is the part that proves the control existed, worked, and was followed.

That is why CIP-015 readiness should not be treated as a simple deployment project. It should be treated as a compliance operations and evidence program.

What auditors will expect utilities to prove

For R1, examples of evidence include documentation of network data feeds and the risk-based rationale for selecting them, anomalous network detection events, INSM configuration settings, communication baselines or other detection methods, methods used to evaluate anomalous activity, and actions taken in response to detected anomalies.

For R2, evidence may include documentation of the retention process, system configurations, or system-generated reports showing retention timelines sufficient to support evaluation. For R3, evidence may include documentation showing how INSM data is protected from unauthorized deletion or modification.

Common evidence gaps that can create compliance risk

If an entity implements a platform that generates noisy detections, lacks context, does not retain the right data, cannot demonstrate how data is protected, or cannot produce useful audit evidence, the issue may not become obvious until much later. By then, an organization may discover during an audit that it cannot prove what it thought it had implemented.

That is a bad place to be.

CIP evidence gaps can create exposure that goes back over time, not just to the day the audit finding is discovered. This is why utilities need to validate the process early. Do not wait until an audit cycle to find out whether your INSM approach can stand up to scrutiny.

How utilities should prepare for CIP-015 before 2028

October 2028 may sound far away, but in utility planning terms, it is not.

Utilities should already be moving through a structured readiness process.

Assessing internal network visibility across trusted environments

Start with scope. Identify the applicable High and Medium Impact BES Cyber Systems, the relevant ESPs, and the environments where INSM requirements will apply. Then map current visibility. Where do you already have useful network monitoring? Where are you relying mostly on logs, perimeter controls, or assumptions? Where do you have limited east-west visibility inside trusted environments?

Building a defensible network data feed strategy

Next, define the network data feed strategy. CIP-015 requires a risk-based rationale, so the organization should be able to explain why specific feeds were selected and how they support detection of anomalous activity across relevant connections, devices, and communications.

Validating anomaly detection workflows

Then validate the detection method. This is where utilities need to go deeper than vendor claims. Ask how the platform identifies anomalous activity. Ask how it reduces noise. Ask what context is provided for evaluation. Ask how it handles changes in normal operations. Ask what evidence is retained and how that evidence can be produced.

Testing evidence retention and protection processes

After that, build the evaluation workflow. Who reviews detections? How are anomalies classified as benign, abnormal but not suspicious, suspicious, or potentially malicious? When does an event move into CIP-008 incident response? What documentation is created during that process?

Finally, test evidence production. Utilities should be able to show detection records, configuration settings, evaluation notes, response actions, retention records, and data protection controls before an auditor asks for them.

Where Darktrace Fits into CIP-015

This is where technology matters, but only as part of the broader program.

Darktrace was built on self-learning anomaly detection long before CIP-015 created a new compliance driver around anomalous network activity. Its value is rooted in continuous behavioral understanding, multiple analytical techniques, and the ability to identify meaningful deviations across complex IT and OT environments. That matters because CIP-015 requires more than basic alerting. It requires detection that supports evaluation, evidence, and action.

This IT and OT visibility is especially important in power utility environments. High and Medium Impact environments are not made up only of industrial protocols and field devices. Control centers, operational workstations, engineering workstations, servers, remote access systems, domain services, printers, and other enterprise-class assets often sit inside or adjacent to critical operational environments. A useful INSM capability should understand a wide range of communications across both IT and OT, not only traditional industrial protocols like Modbus, DNP3, or IEC 61850.

That distinction matters because “protocol support” can mean very different things. Identifying that a protocol is present is not the same as performing deeper packet analysis that can provide behavioral context, richer protocol understanding, and meaningful detection across the communications actually used inside the environment. For CIP-015, utilities should be asking whether a platform can help evaluate activity across both enterprise and industrial communications, because real power utility environments are rarely “OT-only.”

This is also why utilities should look carefully at how vendors use the word “anomaly.” Some platforms were designed around behavioral understanding and anomaly detection long before CIP-015 created a new compliance driver. Others may now be adopting the language because the standard uses the term. The difference matters. Utilities should ask whether the platform’s detection approach is foundational to the technology, or simply a new label applied to existing signature-based, threat-based, or rule-based methods.

In OT environments, detection quality matters. Utilities do not need more noise. They need visibility into internal communications, confidence in what is normal, context when something changes, and prioritization that helps security and operations teams focus on what matters.

A strong INSM program should help utilities move from raw monitoring to operational confidence. It should support east-west visibility, better anomaly evaluation, defensible evidence retention, protection of monitoring data, and alignment between compliance and security outcomes.

That is the right way to think about CIP-015.

Not as “deploy a tool and move on.”But as “build a capability that can be trusted, operated, and proven.”

CIP-015 is about proving your INSM capability works

The CIP-015 countdown is real, but the countdown itself is not the whole story.

The real story is what utilities do with the time that remains.

Organizations that treat CIP-015 as a checkbox may be able to say they deployed something. But organizations that treat it as an opportunity to close the internal visibility gap will gain something much more valuable: better detection, better response, better evidence, and stronger operational resilience.

The question utilities should be asking now is not whether they can produce more alerts before October 2028.

The question is whether they can prove their INSM capability actually works.

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
Jeffrey Macre
Principal Industrial Security Solutions Architect

More in this series

No items found.

Blog

/

/

October 5, 2026

AI-Assisted Attacks Still Leave a Behavioral Trace  

Default blog imageDefault blog image

Key Insights

  • Darktrace identified behavioral indicators associated with two campaigns linked to AI-assisted threat activity, highlighting the growing role of AI in modern cyber-attacks.
  • Observed activity involved suspicious WebDAV file transfers, disguised executable downloads, beaconing to rare infrastructure, unusual process execution, and communications with C2 infrastructure linked to active intrusion campaigns.

Introduction

Just as organizations are incorporating AI into their operations to take advantage of its benefits, threat actors are doing the same, creating new challenges for defenders.

Much of the discussion around AI risk has focused on the expanding attack surface created by AI systems within organizations. These systems are often granted privileged access and heightened permissions to carry out their duties, introducing new security risks and unintended consequences.

At the same time, threat actors are learning to leverage AI to enable malicious activities such as vulnerability discovery, exploit creation, and progressing through the Cyber Kill Chain more quickly. By accelerating development, adaptation, and scaling, AI enables attackers to operate more efficiently while making some capabilities more accessible to less skilled operators.

Whether AI is the target or the enabler, the resulting activity still manifests through networks, identities, endpoints and cloud services. Those interactions create observable signals that defenders can investigate, regardless of how the attack was developed.

AI as part of the attacker’s workflow

Darktrace has previously documented how threat actors are increasingly incorporating AI into offensive operations [1]. Two recent investigations from open-source intelligence (OSINT) illustrate this. In both cases, researchers identified the role of AI within malicious operations. Separately, Darktrace detected activity in customer environments that aligned with the infrastructure and techniques reported in those campaigns. These perspectives provide a view of both attacker workflow and operational consequences.

Although AI played different roles in each campaign, it did not remove the need for the attackers to interact with their targets. Payloads still had to be delivered, processes executed, and command-and-control (C2) connections established, creating behavioral anomalies that Darktrace was able to identify.

‍

Case 1: A Mexican government impersonation campaign with LLM-assisted malware development

Rapid7 reported on a malware delivery operation that used generative AI to assist development, testing, documentation and refinement of attacker infrastructure. Between May and June 2026, Darktrace similarly observed two chains of suspicious activity across customer environments in the Americas that exhibited clear similarities in behavior.

In both cases Darktrace observed:

  • WebDAV communication with onedrive[.]cv·138.124.123[.]87, retrieving a file from the path /Downloads/CURP/
  • Transfer of a masqueraded .scr executable
  • Subsequent communication with google.services[.]ug·77.110.127[.]205 over unusual high ports
  • Additional Darktrace detections correlating the unusual behavior seen spanning payload delivery and C2 communication
  • Darktrace’s Autonomous Response capability alerted across multiple stages of the attack

The infrastructure and behavior observed by Darktrace closely aligned with a campaign reported by Rapid7, in which a WebDAV malware delivery environment was exposed. Rapid7 assessed that threat actors had used generative AI to support the development, testing, documentation and refinement of the operation. The observed activity also aligned with reporting on a campaign in which impersonation of Mexico’s government Unique Population Registry Code (CURP) identity-record service led to delivery of PureRAT, a .NET-based information stealer and remote access trojan (RAT) [2]. The infrastructure overlap and consistent behavioural sequence provides strong alignment and offers a view of how an AI-assisted development pipeline ultimately manifested inside target environments.

Case 2: A suspected China-linked intrusion campaign with AI-assisted automation

In July 2026, Hunt.io published research into a suspected China-based intrusion operation targeting government and financial services organizations [3]. Material recovered from exposed attacker infrastructure by Hunt.io indicated that Claude Code and DeepSeek-v4-pro were being used as active components of the attacker’s workflow. According to the research, the models supported activities including attack reasoning, script generation, execution, exploit adaptation, and phishing-page development.

The investigation identified 192.229.115[.]229 and 192.229.115[.]230 as infrastructure associated with suspected TencShell operations and a possible second C2 framework known as Gshell [3].

Darktrace identified likely related activity within a financial services customer environment involving a newly observed laptop running the Windows 11 Pro operating system. Over a six-day period in July, the device made repeated outbound connections to 192.229.115[.]229 over port 8083.

Darktrace recognized the destination was highly rare for the environment, and the connectivity exhibited beaconing characteristics. During the same timeframe, Darktrace also identified suspicious process behavior associated with process chains involving svchost.exe and cmd.exe. The device repeatedly communicated with infrastructure identified in the Hunt.io research while exhibiting beaconing characteristics and suspicious process activity, strengthening the assessment that the activity likely was associated with the same operation.

Unlike many previous examples of AI-assisted cybercrime, the Hunt.io investigation provided rare visibility into how large language models were being incorporated directly into operational workflows rather than being used solely for content generation. Darktrace, meanwhile, observed how activity associated with that operation ultimately manifested inside a target environment, providing a complementary view of its operational impact.

Operational consequences of AI-assisted attacks

These investigations provide two complementary perspectives on AI-assisted cyber operations. OSINT research revealed how AI was incorporated into attacker workflows, while Darktrace observed the resulting activity within customer environments.

Although AI played different roles in each campaign, it did not remove the need for attackers to interact with their targets, deliver payloads, execute processes, and communicate with C2, all of which generated observable signals.

In these cases, Darktrace identified suspicious file delivery, unusual process behavior, beaconing activity, and communication with rare external infrastructure that aligned with campaigns later linked to AI-assisted operations. While AI may influence how attacks are developed, adapted, and scaled, it does not make them operationally invisible.

For defenders, the broader lesson extends beyond these specific campaigns. As AI becomes increasingly embedded within both enterprise operations and attacker workflows, understanding what a model was asked to do is often less important than understanding the actions it ultimately took and the consequences those actions produced. Whether the actor is human, AI-assisted, or increasingly autonomous, activity still manifests through identities, endpoints, applications, cloud services and network infrastructure.

Credit to Angel Arribas Lopez (Associate Principal Cyber Analyst), Emma Foulger (Global Threat Research Operations Lead), Nathaniel Jones, SVP Global Threat Intelligence
Edited by Ryan Traill (Content Manager)

‍

Appendices

Darktrace Model Detections

Case 1

Anomalous File / Masqueraded File Transfer from New External Endpoint

Anomalous File / Script from Rare External Location

Anomalous File / EXE from Rare External Location

Anomalous File / Script and EXE from Rare External

Anomalous Connection / Multiple Failed Connections to Rare Endpoint

Anomalous Connection / Rare External SSL Self-Signed

Compromise / New or Repeated to Unusual SSL Port

Compromise / Large Number of Suspicious Failed Connections

Device / Initial Attack Chain Activity

Antigena / Network / External Threat::Antigena Suspicious File Block

Antigena / Network / Significant Anomaly::Antigena Enhanced Monitoring from Client Block

Antigena / Network / Significant Anomaly::Antigena Controlled and Model Alert

Antigena / Network / External Threat::Antigena File then New Outbound Block

Antigena / Network / Significant Anomaly::Antigena Significant Anomaly from Client Block

Antigena / Network / Significant Anomaly::Antigena Alerts Over Time Block

Case 2

Anomalous Connection / Multiple Failed Connections to Rare Endpoint

Compromise / High Volume of Connections with Beacon Score

Compromise / Large Number of Suspicious Failed Connections

‍

Indicators of Compromise (IoCs)

‍

Case 1

                                                                                                                                                                                                                                                 
IoCTypeDescription + Confidence
onedrive[.]cvHostnameLikely C2 server
138.124.123[.]87IP AddressPossible C2 server
hXXp://onedrive[.]cv/Downloads/CURP/ReportFinal.%E2%80%AE%E1%BA%9D%D4%81%EF%BD%90.scrURIPossible payload
google.services[.]ugHostnameLikely C2 server
77.110.127[.]205IP AddressLikely C2 server
google.services[.]ug:57666Hostname + PortLikely C2 communication
google.services[.]ug:57888Hostname + PortLikely C2 communication
google.services[.]ug:56001Hostname + PortLikely C2 communication

‍

Case 2

IoC Type Description + Confidence
192.229.115[.]229 IP Address Likely C2 communication
Continue reading
About the author
Angel Arribas Lopez
Associate Principal Cyber Analyst

Blog

/

Network

/

October 5, 2026

A Chain Reaction: Blockchain-Hosted Infostealer Campaign Targets Windows and macOS

Default blog imageDefault blog image

Key Insights

  • Darktrace detected a blockchain-hosted infostealer campaign targeting Windows and macOS devices across multiple customer environments.
  • The campaign combined ClickFix social engineering with trusted services and decentralized blockchain infrastructure to support malware delivery and C2 activity.
  • Compromised devices were observed connecting to rare and unusual external endpoints, including DGA C2 domains, blockchain-related endpoints, and cryptocurrency mining infrastructure.
  • The activity was associated with information-stealing malware strains including Atomic macOS Stealer (AMOS), Lumma, Rhadamanthys, Vidar, and Phexia.
  • Darktrace identified anomalous device behavior, beaconing patterns, rare external connections, cryptomining activity, and suspicious TLS/SSL communications without relying solely on prior knowledge or static indicators of compromise.
  • The campaign highlights how attackers are increasingly using legitimate and decentralized infrastructure to make detection, disruption, and attribution more challenging for defenders.

The Infostealer Ecosystem

The information stealer malware ecosystem continues to grow in value for threat actors across the digital threat landscape. Infostealers are increasingly delivered through Malware-as-a-Service (MaaS) operating models, distributed through affiliate networks, and designed to withstand infrastructure takedowns. This resilience was demonstrated by the recent takedown of Lumma Stealer malicious domains by Microsoft’s Digital Crimes Unit (DCU) [1].

Infostealers are used to gather and exfiltrate sensitive information, including non-human identity (NHI) data, from compromised systems across cloud, Software-as-a-Service (SaaS), Virtual Private Network (VPN), and development environments. They can also support ransomware operations by expanding the credentials and access paths available to threat actors, contributing to the high volume of identity-based attacks observed across the broader threat landscape [2][3].

Darktrace’s Observations of ClickFix and Infostealers

Throughout 2026, Darktrace has observed multiple campaigns using ClickFix social engineering to trick users into carrying out malicious actions and downloading initial payloads, including information stealers. More recently, Darktrace’s Threat Research team identified a specific ClickFix campaign involving a blockchain-hosted infostealer targeting Windows and macOS devices.

Darktrace identified affected customer environments across Europe, the United States, Asia, and the Middle East where blockchain-hosted infostealer malware appears to have been delivered to compromised systems following likely ClickFix-driven initial access. Darktrace investigated the activity and found that decentralized blockchain infrastructure, alongside widely trusted legitimate services, was used to support malware delivery and information theft across Windows and macOS systems.

Following initial access, compromised systems established C2 communication, with C2 configuration and payloads hosted on public blockchain infrastructure. The ultimate objective appears to be credential and cryptocurrency theft through the deployment of information stealers such as Atomic macOS Stealer (AMOS), Lumma, Rhadamanthys, and Vidar [5][6][7].

Darktrace’s Investigation

Affected devices across the Darktrace customer base were observed making outbound connections to rare external endpoints in patterns consistent with beaconing and C2 activity. Darktrace primarily detected devices making repeated connections to algorithmically generated domains (DGA) such as hf98x4d[.]site [8]. In many cases, these domains were linked through open-source intelligence (OSINT) to information-stealing malware families including AMOS and Phexia [5][6][7][8][9].

In multiple cases, devices were also observed connecting to blockchain-related endpoints, such as polygon[.]drpc[.]org, as well as legitimate public services, including GitHub. The use of decentralized blockchain infrastructure and trusted services such as GitHub to facilitate malware distribution and C2 activity can make disruption and attribution significantly more difficult for defenders.

Darktrace also detected a significant proportion of impacted devices making outbound connections to cryptocurrency mining infrastructure associated with the legitimate open-source XMRig mining software and the HashVault mining pool, including pool.hashvault[.]pro and donate[.]ssl[.]xmrig[.]com, which were abused by the attackers, indicating, including pool.hashvault[.]pro and donate[.]ssl[.]xmrig[.]com, indicating active cryptomining on compromised systems.

In one case, mining activity was observed before and during connections to the DGA endpoint hf98x4d[.]site. Due to its highly anomalous nature, Darktrace's Real-Time AI Analyst autonomously investigated the activity as it occurred, correlating the two events into a single cryptocurrency mining incident and providing comprehensive visibility into the broader attack.

‍

Figure 1: Real-Time AI Analyst investigation of suspicious SSL and C2 communications with hf98x4d[.]site over port 443.

‍

Figure 2: Real-Time AI Analyst investigation into cryptocurrency mining activity involving pool[.]hashvault[.]pro over SSL on port 443.

‍

Around the same time, Darktrace identified the same device initiating connections to the GitHub endpoint release-assets[.]githubusercontent[.]com while continuing to make repeated connections to hf98x4d[.]site.

‍

Figure 3: Darktrace's detection of an affected device connecting to a GitHub endpoint between repeated connections to the anomalous external endpoint hf98x4d[.]site.

On the network of another customer, Darktrace observed an affected device making highly unusual outbound connections consistent with beaconing activity. The device initiated multiple connections over port 443 to the external hostname polygon[.]drpc[.]org. According to OSINT, this hostname is a Remote Procedure Call (RPC) endpoint provided by dRPC, a legitimate service enabling decentralized applications (dApps), cryptocurrency wallets, and developer tools to interact with the Polygon blockchain [10].

The same device was later observed making repeated TLS/SSL connections to the previously mentioned DGA C2 domain. In addition, it made outbound connections to the external IP 195.242.214[.]34 over destination port 51820, an endpoint associated with the ProtonVPN service. Collectively, these connections to blockchain-related infrastructure, the DGA C2 domain, and ProtonVPN-associated infrastructure suggested the device had been affected by the campaign.

Conclusion

This campaign demonstrates how attackers can combine ClickFix social engineering with trusted services and decentralized blockchain infrastructure to create a resilient, cross-platform malware delivery chain. By using services such as GitHub alongside blockchain RPC endpoints and rapidly replaceable DGA domains, the activity can blend into legitimate traffic while making infrastructure disruption and attribution more difficult.

For defenders, it’s a reminder that trusted infrastructure does not automatically mean trusted activity. Security teams should look for the behaviors surrounding these connections, including unusual outbound communication, repeated beaconing, unexpected access to blockchain services, suspicious TLS/SSL activity and cryptomining. In this campaign, Darktrace identified and correlated these deviations without depending solely on previously known indicators, providing visibility as affected devices moved between legitimate services, decentralized infrastructure and malicious C2 endpoints

Credit to Nahisha Nobregas (Associate Principal Cyber Analyst), Manoel Kadja (Senior Cyber Analyst)

Edited by Ryan Traill (Content Manager)

Appendices

Darktrace Model Detections

▪ Compromise / Beaconing Activity To External Rare

▪ Compromise / Beacon to Young Endpoint

▪ Compromise / Fast Beaconing to DGA

▪ Compromise / High Volume of Connections with Beacon Score

▪ Compromise / DGA Beacon

▪ Compromise / Slow Beaconing Activity To External Rare

▪ Compromise / Agent Beacon (Long Period)

▪ Compromise / Agent Beacon (Medium Period)

▪ Compromise / Sustained SSL or HTTP Increase

▪ Compromise / Large Number of Suspicious Failed Connections

▪ Compromise / SSL Beaconing to Rare Destination

▪ Compromise / Beacon for 4 Days

▪ Compromise / High Priority Crypto Currency Mining

▪ Compromise / Monero Mining

▪ Device / Long Agent Connection to New Endpoint

▪ Device / New Connections On Suspicious Port

▪ Anomalous Connection / High Volume of Connections to Rare Domain

‍

‍

List of Indicators of Compromise (IoCs)

 
Indicator Description
hf98x4d[.]site C2 Endpoint (Hostname)
sj98xe4[.]xyz C2 Endpoint (Hostname)
citcix6[.]xyz C2 Endpoint (Hostname)
bduwih8[.]pro C2 Endpoint (Hostname)

‍

‍

MITRE ATT&CK Mapping

 
Tactic (ID) Technique
Persistence (T1176) Browser Extensions (T1176.001)
Persistence (T1176) Software Extensions
Command and Control (T1071) Web Protocols (T1071.001)
Command and Control (T1568) Domain Generation Algorithms (T1568.002)
Command and Control (T1071) Application Layer Protocol
Command and Control (T1102) One-Way Communication (T1102.003)
Command and Control (T1571) Non-Standard Port
Command and Control (T1104) Multi-Stage Channels
Command and Control (T1573) Encrypted Channel
Command and Control (T1008) Fallback Channels
Initial Access ICS (T0862) Supply Chain Compromise
Command and Control ICS (T0885) Commonly Used Port
Collection (T1185) Browser Session Hijacking
Impact (T1496) Compute Hijacking (T1496.001)
Impact (T1496) Resource Hijacking
Command and Control (T1071) Publish/Subscribe Protocols (T1071.001)
Lateral Movement (T1210) Exploitation of Remote Services

‍

References:

1.        https://www.microsoft.com/en-us/security/blog/2025/05/21/lumma-stealer-breaking-down-the-delivery-techniques-and-capabilities-of-a-prolific-infostealer/

2.        https://spycloud.com/resource/report/spycloud-annual-identity-exposure-report-2026/

3.        https://www.darktrace.com/blog/why-trust-is-the-new-attack-surface-darktraces-mid-year-threat-update-2026

4.        https://www.darktrace.com/blog/unpacking-clickfix-darktraces-detection-of-a-prolific-social-engineering-tactic

5.        https://abekweng.medium.com/inside-a-blockchain-hosted-malware-campaign-targeting-windows-and-macos-f5bcdeffed66

6.        https://cloud.google.com/blog/topics/threat-intelligence/unc5142-etherhiding-distribute-malware

7.        https://haveibeensquatted.com/blog/from-typosquatting-to-macos-backdoor-clickfix-blockchain-c2

8.        https://www.virustotal.com/gui/domain/hf98x4d.site/community

9.        https://x.com/FABO97662188/status/2074125545026244795

10.  https://www.virustotal.com/gui/url/b0e5c51a411065864119c305fddf218b7c120731f655932cc1c3307ad5b43f94/gti-summary

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