Blog
/
Network
/
June 3, 2024

The Price of Admission: Countering Stolen Credentials with Darktrace

This blog examines a network compromise that stemmed from the purchase of leaked credentials from the dark web. Credentials purchased from dark web marketplaces allow unauthorized access to internal systems. Such access can be used to exfiltrate data, disrupt operations, or deploy malware.
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
Charlotte Thompson
Cyber Analyst
Default blog image
03
Jun 2024

Using leaked credentials to gain unauthorized access

Dark web marketplaces selling sensitive data have increased accessibility for malicious actors, similar to Ransomware-as-a-Service (RaaS), lowering the barrier to entry usually associated with malicious activity. By utilizing leaked credentials, malicious actors can easily gain unauthorized access to accounts and systems which they can leverage to carry out malicious activities like data exfiltration or malware deployment.

Usage of leaked credentials by malicious actors is a persistent concern for both organizations and security providers. Google Cloud’s ‘H1 2024 Threat Horizons Report’ details that initial access seen in 2.9% of cloud compromises observed on Google Cloud resulted from leaked credential usage [1], with the ‘IBM X-Force Threat Intelligence Index 2024’ reporting 71% year-on-year increase in cyber-attacks which utilize stolen or compromised credentials [2].

Darktrace coverage of leaked credentials

In early 2024, one Darktrace customer was compromised by a malicious actor after their internal credentials had been leaked on the dark web. Subsequent attack phases were detected by Darktrace/Network and the customer was alerted to the suspicious activity via the Proactive Threat Notification (PTN) service, following an investigation by Darktrace’s Security Operation Center (SOC).

Darktrace detected a device on the network of a customer in the US carrying out a string of anomalous activity indicative of network compromise. The device was observed using a new service account to authenticate to a Virtual Private Network (VPN) server, before proceeding to perform a range of suspicious activity including internal reconnaissance and lateral movement.

Malicious actors seemingly gained access to a previously unused service account for which they were able to set up multi-factor authentication (MFA) to access the VPN. As this MFA setup was made possible by the configuration of the customer’s managed service provider (MSP), the initial access phase of the attack fell outside of Darktrace’s purview.

Unfortunately for the customer in this case, Darktrace RESPOND™ was not enabled on the network at the time of the attack. Had RESPOND been active, it would have been able to autonomously act against the malicious activity by disabling users, strategically blocking suspicious connections and limiting devices to their expected patterns of activity.

Attack timeline of leaked credentials spotted by darktrace

Network Scanning Activity

On February 22, 2024, Darktrace detected the affected device performing activity indicative of network scanning, namely initiating connections on multiple ports, including ports 80, 161 389 and 445, to other internal devices. While many of these internal connection attempts were unsuccessful, some successful connections were observed.

Devices on a network can gather information about other internal devices by performing network scanning activity. Defensive scanning can be used to support network security, allowing internal security teams to discover vulnerabilities and potential entry points that require their attention, however attackers are also able to take advantage of such information, such as open ports and services available on internal devices, with offensive scanning.

Brute Force Login Attempts

Darktrace proceeded to identify the malicious actor attempting to access a previously unused service account for which they were able to successfully establish MFA to access the organization’s VPN. As the customer’s third-party MSP had been configured to allow all users to login to the organization’s VPN using MFA, this login was successful. Moreover, the service account had never previously been used and MFA and never been established, allowing the attacker to leverage it for their own nefarious means.

Darktrace/Network identified the attacker attempting to authenticate over the Kerberos protocol using a total of 30 different usernames, of which two were observed successfully authenticating. There was a total of 6 successful Kerberos logins identified from two different credentials.  Darktrace also observed over 100 successful NTLM attempts from the same device for multiple usernames including “Administrator” and “mail”. These credentials were later confirmed by the customer to have been stolen and leaked on the dark web.

Advanced Search query results showing the usernames that successfully authenticated via NTLM.
Figure 1: Advanced Search query results showing the usernames that successfully authenticated via NTLM.

Even though MFA requirements had been satisfied when the threat actor accessed the organization’s VPN, Darktrace recognized that this activity represented a deviation from its previously learned behavior.

Malicious actors frequently attempt to gain unauthorized access to accounts and internal systems by performing login attempts using multiple possible usernames and passwords. This type of brute-force activity is typically accomplished using computational power via the use of software or scripts to attempt different username/password combinations until one is successful.

By purchasing stolen credentials from dark web marketplaces, attackers are able to significantly increase the success rate of brute-force attacks and, if they do gain access, they can easily act on their objectives, be that exfiltrating sensitive data or moving through their target networks to further the compromise.

Share Enumeration

Around 30 minutes after the initial network scanning activity, the compromised device was observed performing SMB enumeration using one of the aforementioned accounts. Darktrace understood that this activity was suspicious as the device had never previously been used to perform SMB activity and had not been tagged as a security device.

Darktrace/Network identifying the suspicious SMB enumeration performed by the compromised device.
Figure 2: Darktrace/Network identifying the suspicious SMB enumeration performed by the compromised device.

Such enumeration can be used by malicious actors to gain insights into the structures and configurations of a target device, view permissions associated with shared resources, and also view general identifying information about the system.

Darktrace further identified that the device connected to the named pipe “srvsvc”. By enumerating over srvsvc, a threat actor is able to request a list of all available SMB shares on a destination device, enabling further data gathering as part of network reconnaissance. Srvsvc also provides access to remote procedure call (RPC) for various services on a destination device.

At this stage, a Darktrace/Network Enhanced Monitoring model was triggered for lateral movement activity taking place on the customer’s network. As this particular customer was subscribed to the PTN service, the Enhanced Monitoring model alert was promptly triaged and investigated by the Darktrace SOC. The customer was alerted to the emerging activity and given full details of the incident and the SOC team’s investigation.

Attack and Reconnaissance Tool Usage

A few minutes later, Darktrace observed the device making a connection with a user agent associated with the Nmap network scanning tool, “Mozilla/5.0 (compatible; Nmap Scripting Engine; https://nmap.org/book/nse[.]html)”. While these tools are often used legitimately by an organization’s security team, they can also be used maliciously by attackers to exploit vulnerabilities that attackers may have unearthed during earlier reconnaissance activity.

As such services are often seen as normal network traffic, attackers can often use them to bypass traditional security measures. Darktrace’s Self-Learning AI, however, was able to recognize that the affected device was not a security device and therefore not expected to carry out such activity, even if it was using a legitimate Nmap service.

Darktrace/Network identifying the compromised device using the Nmap scanning tool.
Figure 3: Darktrace/Network identifying the compromised device using the Nmap scanning tool.

Further Lateral Movement

Following this suspicious Nmap usage, Darktrace observed a range of additional anomalous SMB activity from the aforementioned compromised account. The affected device attempted to establish almost 900 SMB sessions, as well as performing 65 unusual file reads from 29 different internal devices and over 300 file deletes for the file “delete.me” from over 100 devices using multiple paths, including ADMIN$, C$, print$.

Darktrace also observed the device making several DCE-RPC connections associated with Active Directory Domain enumeration, including DRSCrackNames and DRSGetNCChanges; a total of more than 1000 successful DCE-RPC connection were observed to a domain controller.

As this customer did not have Darktrace/Network's autonomous response deployed on their network, the above detailed lateral movement and network reconnaissance activity was allowed to progress unfettered, until Darktrace’s SOC alerted the customer’s security team to take urgent action. The customer also received follow-up support through Darktrace’s Ask the Expert (ATE) service, allowing them to contact the analyst team directly for further details and support on the incident.

Thanks to this early detection, the customer was able to quickly identify and disable affected user accounts, effectively halting the attack and preventing further escalation.

Conclusions

Given the increasing trend of ransomware attackers exfiltrating sensitive data for double extortion and the rise of information stealers, stolen credentials are commonplace across dark web marketplaces. Malicious actors can exploit these leaked credentials to drastically lower the barrier to entry associated with brute-forcing access to their target networks.

While implementing well-configured MFA and enforcing regular password changes can help protect organizations, these measures alone may not be enough to fully negate the advantage attackers gain with stolen credentials.

In this instance, an attacker used leaked credentials to compromise an unused service account, allowing them to establish MFA and access the customer’s VPN. While this tactic may have allowed the attacker to evade human security teams and traditional security tools, Darktrace’s AI detected the unusual use of the account, indicating a potential compromise despite the organization’s MFA requirements being met. This underscores the importance of adopting an intelligent decision maker, like Darktrace, that is able to identify and respond to anomalies beyond standard protective measures.

Credit to Charlotte Thompson, Cyber Security Analyst, Ryan Traill, Threat Content Lead

Appendices

Darktrace DETECT Model Coverage

-       Device / Suspicious SMB Scanning Activity (Model Alert)

-       Device / ICMP Address Scan (Model Alert)

-       Device / Network Scan (Model Alert)

-       Device / Suspicious LDAP Search Operation (Model Alert)

-       User / Kerberos Username Brute Force (Model Alert)

-       Device / Large Number of Model Breaches (Model Alert)

-       Anomalous Connection / SMB Enumeration (Model Alert)

-       Device / Multiple Lateral Movement Model Breaches (Enhanced Monitoring Model Alert)

-       Device / Possible SMB/NTLM Reconnaissance (Model Alert)

-       Anomalous Connection / Possible Share Enumeration Activity (Model Alert)

-       Device / Attack and Recon Tools (Model Alert)

MITRE ATT&CK Mapping

Tactic – Technique - Code

INITIAL ACCESS - Hardware Additions     -T1200

DISCOVERY - Network Service Scanning -T1046

DISCOVERY - Remote System Discovery - T1018

DISCOVERY - Domain Trust Discovery      - T1482

DISCOVERY - File and Directory Discovery - T1083

DISCOVERY - Network Share Discovery - T1135

RECONNAISSANCE - Scanning IP Blocks - T1595.001

RECONNAISSANCE - Vulnerability Scanning - T1595.002

RECONNAISSANCE - Client Configurations - T1592.004

RECONNAISSANCE - IP Addresses - T1590.005

CREDENTIAL ACCESS - Brute Force - T1110

LATERAL MOVEMENT - Exploitation of Remote Services -T1210

References

  1. 2024 Google Cloud Threat Horizons Report
    https://services.google.com/fh/files/misc/threat_horizons_report_h12024.pdf
  2. IBM X-Force Threat Intelligence Index 2024
    https://www.ibm.com/reports/threat-intelligence
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
Charlotte Thompson
Cyber Analyst

More in this series

No items found.

Blog

/

/

May 27, 2026

How to Evaluate AI Vendors: 5 Key categories for AI Adoption

Default blog imageDefault blog image

Understanding the AI buyers’ market

AI adoption has become a central topic of discussion in boardrooms, drawing growing interest from business leaders. Ultimately, organizations hope that an investment in AI technology will have tremendous returns. However, the process of buying an AI solution is not as straight forward as it appears on the surface.  

While business leaders may be eager to improve productivity across their operations, practitioners responsible for evaluating and selecting AI solutions may not always have the visibility or technical understanding needed to make the right decisions for their business. What is typically marketed as a holistic solution to their most critical problems is usually followed by uncertainty when AI tools are finally operationalized in real environments.

This guide is intended to support security leaders who are under growing pressure to adopt AI tools while navigating complex terminology, vendor claims, and increasingly crowded buying cycles. Ultimately, the goal is to help organizations evaluate and adopt AI in a safe, effective, and well-governed way. To support this, we’ve structured the evaluation framework across five key categories:

  1. Governance, safety, and data controls
  1. Data gathering and training
  1. Model and technique choice
  1. Performance and accuracy validation    
  1. Interpretability, adjustability, and transparency    

What buying AI looks like in cybersecurity

While investing in AI can bring immense benefits to your security team, first-time buyers of AI cybersecurity solutions may not know where to start. They will have to determine the type of tool they want, know the options available, and evaluate vendors. Research and understanding are critical to ensure purchases are worth the investment.  

With acceleration in AI adoption, accompanied by the recent boom in agentic AI and autonomous agents, CISOs must look “beneath the hood" of these tools to understand how they work, how they are governed, and to ensure the system is secure and compliant with internal policies.

Challenges in the AI buyers’ marketplace  

The AI security software market is buzzing with hype and flashy promises, which, understandably, needs to be addressed with due diligence. Potential buyers, especially in the cybersecurity space, are hesitant when it comes to allowing AI autonomous capabilities across their workflows, and a lack of vendor transparency can exacerbate those feelings.  

Reinforcing this sentiment, research from this year's Darktrace’s State of AI Cybersecurity report shows where confidence and hesitancy emerge amongst potential buyers. On the one hand, security professionals agree that they have good visibility into the logic and reasoning processes their AI solutions use. However, they lack the explainability and trust to allow AI to take independent remedial action.

  • 89% say they have good visibility into the reasoning behind the outputs generated by AI solutions
  • 92% say they need to understand how a defensive AI tool makes decisions before they can trust it
  • Only 14% say they allow AI to act independently, performing autonomous actions without human approval
  • 74% say they are limiting the autonomy of AI taking action in their SOC until explainability improves

Given the desire for trust and explainability we are seeing from buyers, it's important for them to be equipped with the right questions to ask vendors during an assessment or POV of AI tools in order to demystify marketing hype from real operational outcomes.

Below is a list of categories in which buyers can assess AI vendors or AI Service Providers (AISPs) to help reach safe adoption and maximize their ROI.  

5 categories of AI vendor assessment

Darktrace groups these AI-related questions into 5 categories: governance, data and training, model and technique choice, performance validation, and interpretability and adjustability. By asking questions regarding each of these 5 categories, buyers can gain a deeper understanding of how an AISP’s systems work and whether they suit their business requirements.

Governance, safety, and data controls

Governance of AI systems is critical for all AISPs. Whether their platform is based around a single model, or is a more complex, composite AI solution, strong governance is essential to ensure the system is safe, robust, and reliable.

A simple question you could ask is:

What AI governance policies and frameworks do you follow, and/or certifications do you currently maintain?

For more questions you can ask vendors, download the full guide here.

Darktrace is certified to the ISO/IEC 42001 standard, the world’s first AI Management System (AIMS) standard. ISO/IEC 42001 addresses the unique ethical and technical challenges AI poses by setting out a structured way to manage risks such as transparency, accuracy, and misuse. This includes a commitment to ethical AI development, and effective management and monitoring of AI systems both prior to and continually after release.

Data gathering and training

Accurate, meaningful, and unbiased data gathering is the first important step in producing any AI system. An AI model trained using inaccurate, unbalanced, or poor-quality training data will fail to perform optimally.

To alleviate concerns regarding training data quality, a question you could ask is:

What steps do you take to prevent bias in your AI models and training data?

For more questions, download the full guide here.

AISPs should be able to provide information about the steps taken, workflows followed, and auditing performed to reduce AI bias where appropriate. While it’s sometimes impossible to fully remove bias from an AI model, appropriate actions should be taken to mitigate or reduce bias where relevant.

Model and technique choice

Different AI techniques are optimal for different tasks. For example, research from Gartner suggests that relying on a single “one-size-fits-all" model can lead to data gaps, especially in highly specialized domains.

To achieve more accurate and robust AI solutions, AI leaders should move beyond using just one model or technique, embrace composite AI practices, and adopt a holistic AI system perspective.

A straightforward question you could ask is simply:

What type(s) of AI model(s) do you utilize in your solution?

For more questions, download the full guide here.

While specific detailed information about custom systems used by AISPs is likely proprietary, buyers should expect vendors to be able to provide an overview of the broad techniques used. This will allow you as a buyer to determine if the type of model is appropriate for your use case.

Performance and accuracy validation  

Testing and evaluation of performance is essential for all AI systems. Performance analysis should be performed both before release and continually after release to identify potential data or model drift.  

A question you could ask to understand an AISPs testing workflow is:

How do you audit, test, evaluate, verify, and validate your AI model outputs?

For more questions, download the full guide here.

Testing workflows will likely vary depending on the type of model – measurements relevant to one system may not always be relevant to others. Assessment of systems should also extend beyond these standard accuracy and robustness tests, and should also feature physical performance, such as latency and resource consumption.  

Interpretability, adjustability, and transparency  

AI systems are typically a black box, simply providing an output without an explanation of how that output was attained. Interpretability and transparency are critical to ensure that both SOC teams and end-users trust the outputs of a system to be accurate and meaningful.

A question you could ask is:

How do you promote a trust relationship between human analysts and AI outputs?

For more questions, download the full guide here.

In the context of cybersecurity, trust and interpretability are even more essential. This is particularly relevant for generative AI-based systems (including most AI Agents), where the risk of hallucination can reduce trust in responses.

Cybersecurity systems often need to perform autonomous actions to block incoming threats – an email filtering system may hold potentially dangerous emails; a firewall may block malicious inbound connections. If SOC teams can’t trust these systems to perform accurately, these systems may be limited or disabled, critically reducing their defensive power.

Darktrace as an AI-native cybersecurity vendor

Darktrace has been building and applying AI in cybersecurity for over a decade, developing its capabilities alongside an increasingly complex and fast‑moving threat landscape. This experience has resulted in a mature, multi-layered approach to AI, which continuously learns the normal patterns of each organization to understand behavior, interpret context, and identify meaningful deviations — without relying on predefined rules or known attack signatures. Over time, this has enabled a proven behavioral understanding that helps uncover subtle signals of risk that may otherwise be missed.

With the backing of our ISO/IEC 42001 certification, stakeholders, customers, and partners can be confident that Darktrace is responsibly, ethically, and safely developing its AI systems, and managing the use of AI in day-to-day operations in a compliant and secure manner.  

Explore the principles behind Darktrace’s responsible AI approach, informed by collaboration with global experts in academia and governments, detailing how accountability, explainability, and continuous validation are built into its cybersecurity technology.

How Darktrace secures AI systems

Darktrace now brings these capabilities to monitor and respond to risk generated from AI systems across organizations with Darktrace / SECURE AI. This solution analyzes how prompts, agents, and systems are used within the context of each organization, bringing every AI interaction into a single view. This unique approach helps teams understand intent, assess risk, protect sensitive data, and enforce policy across both human and AI agent activity.

Stay up to date

Sign up for the Secure AI Readiness Program here: This gives you exclusive access to the latest news on the latest AI threats, updates on emerging approaches shaping AI security, and insights into the latest innovations, including Darktrace’s ongoing work in this area.

Ready to talk with a Darktrace expert on securing AI? Register here to receive practical guidance on the AI risks that matter most to your business, paired with clarity on where to focus first across governance, visibility, risk reduction, and long-term readiness.  

Further Reading on AI in cybersecurity

When deciding to invest in an AI solution, it’s important to understand what this means for you and your organization. The questions presented here are only a starting point in understanding an AI solution and whether it is appropriate for your use case.  

Gain deeper knowledge on applications of AI in cybersecurity and Darktrace’s multi-layered AI in the AI Arsenal White Paper.

[related-resource]

Continue reading
About the author
Jamie Bali
Technical Author (AI) Developer

Blog

/

Compliance

/

May 26, 2026

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

cip-015, utilities, cybersecurityDefault blog imageDefault blog image

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.

Continue reading
About the author
Jeffrey Macre
Principal Industrial Security Solutions Architect
Your data. Our AI.
Elevate your network security with Darktrace AI