ブログ
/
Network
/
September 13, 2023

How Darktrace Stopped Akira Ransomware

Learn how Darktrace is uniquely placed to identify and contain the novel Akira ransomware strain, first observed in March 2023.
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
Manoel Kadja
Cyber Analyst
Default blog image
13
Sep 2023

Introduction to Akira Ransomware

In the face of a seemingly never-ending production line of novel ransomware strains, security teams across the threat landscape are continuing to see a myriad of new variants and groups targeting their networks. Naturally, new strains and threat groups present unique challenges to organizations. The use of previously unseen tactics, techniques, and procedures (TTPs) means that threat actors can often completely bypass traditional rule and signature-based security solutions, thus rendering an organization’s digital environment vulnerable to attack.

What is Akira Ransomware?

One such example of a novel ransomware family is Akira, which was first observed in the wild in March 2023. Much like many other strains, Akira is known to target corporate networks worldwide, encrypting sensitive files and demanding huge sums of money to retrieve the data and stop it from being posted online [1].

Key characteristics of Akira Ransomware

  • Targeted Attacks: Focuses on specific industries and organizations, often targeting those with valuable data.
  • Double Extortion Tactics: Employs double extortion by encrypting data and threatening to release it publicly if the ransom is not paid.
  • Advanced Encryption: Utilizes sophisticated encryption algorithms to ensure that data recovery is impossible without the decryption key.
  • Custom Ransom Notes: Delivers personalized ransom notes tailored to the victim, often containing detailed instructions and specific payment demands.
  • Stealth Techniques: Uses advanced evasion techniques to avoid detection by security tools and to remain undetected for extended periods.
  • Fast Encryption Process: Known for its rapid encryption process, minimizing the time window for detection and response by the victim.
  • Frequent Updates: Regularly updates its malware to bypass the latest security defenses and to improve its effectiveness.
  • Professional Communication: Maintains professional and often polite communication with victims to facilitate ransom payments and decryption.

Darktrace AI capabilities detect Akira Ransomware

In late May 2023, Darktrace observed multiple instances of Akira ransomware affecting networks across its customer base. Thanks to its anomaly-based approach to threat detection, Darktrace successfully identified the novel ransomware attacks and provided full visibility over the cyber kill chain, from the initial compromise to the eventual file encryptions and ransom notes. In cases where Darktrace was enabled in autonomous response mode, these attacks were mitigated the early stages of the attack, thus minimizing any disruption or damage to customer networks.

Initial access and privileged escalation

Methods used by Akira ransomware for privileged escalation

The Akira ransomware group typically uses spear-phishing campaigns containing malicious downloads or links as their primary initial access vector; however, they have also been known to use Remote Desktop Protocol (RDP) brute-force attacks to access target networks [2].

While Darktrace did observe the early access activities that are detailed below, it is very likely that the actual initial intrusion happened prior to this, through targeted phishing attacks that fell outside of Darktrace’s purview. The first indicators of compromise (IoCs) that Darktrace observed on customer networks affected by Darktrace were typically unusual RDP sessions, and the use of compromised administrative credentials.

Darktrace detection of initial access and priviledged escalation

On one Darktrace customer’s network (customer A), Darktrace identified a highly privileged credential being used for the first time on an internal server on May 21, 2023. Around a week later, this server was observed establishing RDP connections with multiple internal destination devices via port 3389. Further investigation carried out by the customer revealed that this credential had indeed been compromised. On May 30, Darktrace detected another device scanning internal devices and repeatedly failing to authenticate via Kerberos.

As the customer had integrated Darktrace with Microsoft Defender, their security team received additional cyber threat intelligence from Microsoft which, coupled with the anomaly alerts provided by Darktrace, helped to further contextualize these anomalous events. One specific detail gleaned from this integration was that the anomalous scanning activity and failed authentication attempts were carried out using the compromised administrative credentials mentioned earlier.

By integrating Microsoft Defender with Darktrace, customers can efficiently close security gaps across their digital infrastructure. While Darktrace understands customer environments and provides valuable network-level insights, by integrating with Microsoft Defender, customers can further enrich these insights with endpoint-specific information and activity.

In another customer’s network (customer B), Darktrace detected a device, later observed writing a ransom note, receiving an unusual RDP connection from another internal device. The RDP cookie used during this activity was an administrative RDP cookie that appeared to have been compromised. This device was also observed making multiple connections to the domain, api.playanext[.]com, and using the user agent , AnyDesk/7.1.11, indicating the use of the AnyDesk remote desktop service.

Although this external domain does not appear directly related to Akira ransomware, open-source intelligence (OSINT) found associations with multiple malicious files, and it appeared to be associated with the AnyDesk user agent, AnyDesk/6.0.1 [3]. The connections to this endpoint likely represented the malicious use of AnyDesk to remotely control the customer’s device, rather than Akira command-and-control (C2) infrastructure or payloads. Alternatively, it could be indicative of a spoofing attempt in which the threat actor is attempting to masquerade as legitimate remote desktop service to remain undetected by security tools.

Around the same time, Darktrace observed many devices on customer B’s network making anomalous internal RDP connections and authenticating via Kerberos, NTLM, or SMB using the same administrative credential. These devices were later confirmed to be affected by Akira Ransomware.

Figure 1 shows how Darktrace detected one of those internal devices failing to login via SMB multiple times with a certain credential (indication of a possible SMB/NTLM brute force), before successfully accessing other internal devices via SMB, NTLM and RDP using the likely compromised administrative credential mentioned earlier.

Figure 1: Model Breach Event Log indicating unusual SMB, NTLM and RDP activity with different credentials detected which led to the Darktrace model breaches, "Unusual Admin RDP Session” and “Successful Admin Brute-Force Activity”.

Darktrace models observed for initial access and privilege escalation:

  • Device / Anomalous RDP Followed By Multiple Model Breaches
  • Anomalous Connection / Unusual Admin RDP Session
  • New Admin Credentials on Server
  • Possible SMB/NTLM Brute Force Indicator
  • Unusual Activity / Successful Admin Brute-Force Activity

Internal Reconnaissance and Lateral Movement

The next step Darktrace observed during Akira Ransomware attacks across the customer was internal reconnaissance and lateral movement.

How Akira Ransomware conducts internal reconnaissance

In another customer’s environment (customer C), after authenticating via NTLM using a compromised credential, a domain controller was observed accessing a large amount of SMB shares it had never previously accessed. Darktrace understood that this SMB activity represented a deviation in the device’s expected behavior and recognized that it could be indicative of SMB enumeration. Darktrace observed the device making at least 196 connections to 34 unique internal IPs via port 445. SMB actions read, write, and delete were observed during those connections. This domain controller was also one of many devices on the customer’s network that was received incoming connections from an external endpoint over port 3389 using the RDP protocol, indicating that the devices were likely being remotely controlled from outside the network. While there were no direct OSINT links with this endpoint and Akira ransomware, the domain controller in question was later confirmed to be compromised and played a key role in this phase of the attack.

Moreover, this represents the second IoC that Darktrace observed that had no obvious connection to Akira, likely indicating that Akira actors are establishing entirely new infrastructure to carry out their attacks, or even utilizing newly compromised legitimate infrastructure. As Darktrace adopts an anomaly-based approach to threat detection, it can recognize suspicious activity indicative of an emerging ransomware attack based on its unusualness, rather than having to rely on previously observed IoCs and lists of ‘known-bads’.

Darktrace further observed a flurry of activity related to lateral movement around this time, primarily via SMB writes of suspicious files to other internal destinations. One particular device on customer C’s network was detected transferring multiple executable (.exe) and script files to other internal devices via SMB.

Darktrace recognized that these transfers represented a deviation from the device’s normal SMB activity and may have indicated threat actors were attempting to compromise additional devices via the transfer of malicious software.

Figure 2: Advanced Search results showing 20 files associated with suspicious SMB write activity, amongst them executable files and dynamic link libraries (DLLs).

Darktrace DETECT models observed for internal reconnaissance and lateral movement:

  • Device / RDP Scan
  • Anomalous Connection / SMB Enumeration
  • Anomalous Connection / Possible Share Enumeration Activity
  • Scanning of Multiple Devices (Cyber AI Analyst Incident)
  • Device / Possible SMB/NTLM Reconnaissance
  • Compliance / Incoming Remote Desktop
  • Compliance / Outgoing NTLM Request from DC
  • Unusual Activity / Internal Data Transfer
  • Security Integration / Lateral Movement and Integration Detection
  • Device / Anomalous SMB Followed By Multiple Model Breaches

Ransomware deployment

In the final phase of Akira ransomware attacks detected on Darktrace customer networks, Darktrace identified the file extension “.akira” being added after encryption to a variety of files on the affected network shares, as well as a ransom note titled “akira_readme.txt” being dropped on affected devices.

On customer A’s network, after nearly 9,000 login failures and 2,000 internal connection attempts indicative of scanning activity, one device was detected transferring suspicious files over SMB to other internal devices. The device was then observed connecting to another internal device via SMB and continuing suspicious file activity, such as appending files on network shares with the “.akira” extension, and performing suspicious writes to SMB shares on other internal devices.

Darktrace’s autonomous threat investigator, Cyber AI Analyst™, was able to analyze the multiple events related to this encryption activity and collate them into one AI Analyst incident, presenting a detailed and comprehensive summary of the entire incident within 10 minutes of Darktrace’s initial detection. Rather than simply viewing individual breaches as standalone activity, AI Analyst can identify the individual steps of an ongoing attack to provide complete visibility over emerging compromises and their kill chains. Not only does this bolster the network’s defenses, but the autonomous investigations carried out by AI Analyst also help to save the security team’s time and resources in triaging and monitoring ongoing incidents.

Figure 3: Darktrace Cyber AI Analyst incident correlated multiple model breaches together to show Akira ransomware encryption activity.

In addition to analyzing and compiling Darktrace model breaches, AI Analyst also leveraged the host-level insights provided by Microsoft Defender to enrich its investigation into the encryption event. By using the Security Integration model breaches, AI Analyst can retrieve timestamp and device details from a Defender alert and further investigate any unusual activity surrounding the alert to present a full picture of the suspicious activity.

In customer B’s environment, following the unusual RDP sessions and rare external connections using the AnyDesk user agent, an affected device was later observed writing around 2,000 files named "akira_readme.txt" to multiple internal SMB shares. This represented the malicious actor dropping ransom notes, containing the demands and extortion attempts of the actors.

Figure 4: Model Breach Event Log indicating the ransom note detected on May 12, 2023, which led to the Darktrace DETECT model breach, Anomalous Server Activity / Write to Network Accessible WebRoot.
Figure 5: Packet Capture (PCAP) demonstrating the Akira ransom note captured from the connection details seen in Figure 4.

As a result of this ongoing activity, an Enhanced Monitoring model breach, a high-fidelity detection model type that detects activities that are more likely to be indicative of compromise, was escalated to Darktrace’s Security Operations Center (SOC) who, in turn were able to further investigate and triage this ransomware activity. Customers who have subscribed to Darktrace’s Proactive Threat Notification (PTN) service would receive an alert from the SOC team, advising urgent follow up action.

Darktrace detection models observed during ransomware deployment:

  • Security Integration / Integration Ransomware Incident
  • Security Integration / High Severity Integration Detection
  • Security Integration / Integration Ransomware Detected
  • Device / Suspicious File Writes to Multiple Hidden SMB Shares
  • Compliance / SMB Drive Write
  • Compromise / Ransomware / Suspicious SMB Activity (Proactive Threat Notification Alerted by the Darktrace SOC)
  • Anomalous File / Internal / Additional Extension Appended to SMB File
  • Anomalous File / Internal / Unusual SMB Script Write
  • Compromise / Ransomware / Ransom or Offensive Words Written to SMB
  • Anomalous Server Activity /Write to Network Accessible WebRoot
  • Anomalous Server Activity /Write to Network Accessible WebRoot

Darktrace autonomous response neutralizes Akira Ransomware

When Darktrace is configured in autonomous response mode, it is able to follow up successful threat identifications with instant autonomous actions that stop malicious actors in their tracks and prevent them from achieving their end goals.

In the examples of Darktrace customers affected by Akira Ransomware outlined above, only customer A had autonomous response mode enabled during their ransomware attack. The autonomous response capability of Darktrace helped the customer to minimize disruption to the business through multiple targeted actions on devices affected by ransomware.

One action carried out by Darktrace's Autonomous Respose was to block all on-going traffic from affected devices. In doing so, Darktrace effectively shuts down communications between devices affected by Akira and the malicious infrastructure used by threat actors, preventing the spread of data on the client network or threat actor payloads.

Another crucial response action applied on this customer’s network was combat Akira was to “Enforce a Pattern of Life” on affected devices. This action is designed to prevent devices from performing any activity that would constitute a deviation from their expected behavior, while allowing them to continue their ‘usual’ business operations without causing any disruption.

While the initial intrusion of the attack on customer A’s network likely fell outside of the scope of Darktrace’s visibility, Darktrace was able to minimize the disruption caused by Akira, containing the ransomware and allowing the customer to further investigate and remediate.

Darktrace Autonomous Response model breaches:

  • Antigena / Network / External Threat / Antigena Ransomware Block
  • Antigena / Network / External Threat / Antigena Suspicious Activity Block
  • Antigena / Network / Significant Anomaly / Antigena Enhanced Monitoring from Server Block
  • Antigena / Network / External Threat / Antigena Suspicious Activity Block
  • Antigena / Network / External Threat / Antigena File then New Outbound Block
  • Antigena / Network / Insider Threat / Antigena Unusual Privileged User Activities Block
  • Antigena / Network / Significant Anomaly / Antigena Breaches Over Time Block
  • Antigena / Network / Significant Anomaly / Antigena Significant Anomaly from Client Block
  • Antigena / Network /Insider Threat /Antigena SMB Enumeration Block

Conclusion

The impact of cyber attacks

Novel ransomware strains like Akira Ransomware present a significant challenge to security teams across the globe due to the constant evolution of attack methods and tactics, making it huge a challenge for security teams to stay up to date with the most current threat intelligence.  

Therefore, it is paramount for organizations to adopt a technology designed around an intelligent decision maker able to identify unusual activity that could be indicative of a ransomware attack without depending solely on rules, signatures, or statistic lists of malicious IoCs.

Importance of AI-powered cybersecurity solutions

Darktrace identified Akira ransomware at every stage of the attack’s kill chain on multiple customer networks, even when threat actors were utilizing seemingly legitimate services (or spoofed versions of them) to carry out malicious activity. While this may have gone unnoticed by traditional security tools, Darktrace’s anomaly-based detection enabled it to recognize malicious activity for what it was. When enabled in autonomous response mode, Darktrace is able to follow up initial detections with machine-speed preventative actions to stop the spread of ransomware and minimize the damage caused to customer networks.  

There is no silver bullet to defend against novel cyber-attacks, however Darktrace’s anomaly-based approach to threat detection and autonomous response capabilities are uniquely placed to detect and respond to cyber disruption without latency.

Credit to: Manoel Kadja, Cyber Analyst, Nahisha Nobregas, SOC Analyst.

Appendices

IOC - Type - Description/Confidence

202.175.136[.]197 - External destination IP -Incoming RDP Connection

api.playanext[.]com - External hostname - Possible RDP Host

.akira - File Extension - Akira Ransomware Extension

akira_readme.txt - Text File - Akira Ransom Note

AnyDesk/7.1.11 - User Agent -AnyDesk User Agent

MITRE ATT&CK Mapping

Tactic & Technique

DISCOVERY

T1083 - File and Directory Discovery

T1046 - Network Service Scanning

T1135 - Network Share Discovery

RECONNAISSANCE

T1595.002 - Vulnerability Scanning

CREDENTIAL ACCESS, COLLECTION

T1557.001 - LLMNR/NBT-NS Poisoning and SMB Relay

DEFENSE EVASION, LATERAL MOVEMENT

T1550.002 - Pass the Hash

DEFENSE EVASION, PERSISTENCE, PRIVILEGE ESCALATION, INITIAL ACCESS

T1078 - Valid Accounts

DEFENSE EVASION

T1006 - Direct Volume Access

LATERAL MOVEMENT

T1563.002 - RDP Hijacking

T1021.001 - Remote Desktop Protocol

T1080 - Taint Shared Content

T1021.002 - SMB/Windows Admin Shares

INITIAL ACCESS

T1190 - Exploit Public-Facing Application

T1199 - Trusted Relationship

PERSISTENCE, INITIAL ACCESS

T1133 - External Remote Services

PERSISTENCE

T1505.003 - Web Shell

IMPACT

T1486 - Data Encrypted for Impact

References

[1] https://www.bleepingcomputer.com/news/security/meet-akira-a-new-ransomware-operation-targeting-the-enterprise/

[2] https://www.civilsdaily.com/news/cert-in-warns-against-akira-ransomware/#:~:text=Spread%20Methods%3A%20Akira%20ransomware%20is,Desktop%20connections%20to%20infiltrate%20systems

[3] https://hybrid-analysis.com/sample/0ee9baef94c80647eed30fa463447f000ec1f50a49eecfb71df277a2ca1fe4db?environmentId=100

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 2026.

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
Manoel Kadja
Cyber Analyst

More in this series

No items found.

Blog

/

Compliance

/

May 26, 2026

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

Default 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

Blog

/

Email

/

May 26, 2026

Journey of a Threat: How Multi-Layered AI Works in Darktrace / EMAIL

Default blog imageDefault blog image

Darktrace / EMAIL is an implementation of the Darktrace methodology – a multi-layered AI system built into a single product. As with other Darktrace products, Darktrace / EMAIL learns the expected behaviours of an organization and its employees to identify novel threats and anomalous activity.

The diagram below represents the architecture of Darktrace / EMAIL’s multi-layered AI: a structured visualization of how intelligence is built, step by step, from raw data to actionable insight. Each layer plays a distinct role, feeding into the next: collecting data, understanding behaviour, analysing intent, making decisions, and presenting clear outcomes.

It all starts with an email

In this blog, we’ll follow a malicious email as it passes through the Darktrace / EMAIL system, showing exactly what happens as it travels through each layer of the pyramid, from basic data extraction to AI-powered metric creation, and finally deciding on any autonomous actions.

Let’s take this example email. As an end-user, you can see that this is an obvious extortion attempt where an adversary is threatening legal action if money isn’t paid within 24 hours, but how does Darktrace figure that out?

Part 1: Data Gathering

Processing of an email begins on point-of-transit for all inbound, outbound, or lateral emails. The first step is to extract information directly. This includes taking information from the headers (such as sending and receiving addresses, sender IP address, routing, and authentication protocols), as well as extraction of raw HTML and CSS data from the email itself.

This directly extracted information only allows for immediate surface level analysis, such as identifying signature-based attacks (known malicious addresses / domains), but is insufficient for identifying novel threats, complex attacks, or potential email or vendor compromise. This is where Darktrace’s AI analysis shines.

In this example, the SPF, DKIM, and DMARC authentication all passed successfully, showing that even malicious emails can still bypass these signature-based checks. Even with this success, Darktrace will continue to analyse the email.

Diving deeper into the technical information, we can see further information extracted from the headers, including aggregations from the header information, historical calculations such as the frequency and volume of emails to and from a particular domain, and much more.

Part 2: Social Graphing

Social Graphing involves the analysis of sending and receiving behaviours of different mailboxes to create peer-groups. Mailboxes who often send and receive to and from the same mailboxes, or exhibit other correlated behaviours, will be clustered together using a collection of unsupervised AI clustering systems. These groups may represent uses in the same teams who perform similar activity, groups of external facing mailboxes which often receive unsolicited emails, or groups of VIP users (such as C-suite or executives).

Social graphing is an essential component of Darktrace’s pattern of life analysis. This clustering allows Darktrace to understand the responsibilities of individuals – for example, behaviours which are anomalous for one group of users may be completely expected of another group.

In our example, the email was sent to 3 different users within the organization. As part of the social graphing, an “Association Anomaly” is calculated which indicates the likelihood that these users would receive emails from this user or domain, based on historical patterns.

Part 3: Metric Calculation

Metrics are calculated for every email, representing more complex characteristics of an email which can’t be directly extracted. Darktrace / EMAIL features over 1000 unique metrics, calculated both algorithmically and using an ensemble of AI systems.

Algorithmically calculated (non-AI) metrics include further historical calculations, and counts of features such as code blocks, and hidden text, to name a few.

AI-driven metrics include Inducement Classification which uses Natural Language Processing to identify potential phishing, solicitation, or extortion attempts; Named Entity Recognition to identify PII and other sensitive data within an email to support Data Loss Prevention; and many more.

We can follow our example email through this process and view the outcome of these metric calculations. Looking at the language metrics for this email, we can see that our email has reported a high extortion inducement, along with identification of banking information and language indicating urgency.

Part 4: Evaluation and Combination Engine (models)

Once all metrics have been calculated for an email, it gets sent to an evaluation and combination engine where the metrics are compared against blocks of logic to determine if an email contains a threat. One key model which alerted for this example message was a model to tag and block extortion attempts.

Since our example email has a high inducement score for extortion, along the presence of a bitcoin wallet address in the message, this model alerts. When a model in the engine is activated, actions are taken – in this case adding a tag to the email to flag it as extortion in the console and hold the email to prevent it from reaching the end-user mailbox.

Part 5: Meta-Modelling and Actions

Once the models have been run, the actions are taken against the email. If the email hasn’t been blocked or held, this is the point where it will reach the end-user's mailbox.

In the Darktrace / EMAIL UI, all actions models which alerted for an email and actions taken as a result can be seen. At the top of this page, you can see the alert indicating an extortion attempt along with the action to hold the message.

Alongside this, a meta-classifier is used to calculate an overall anomaly score for each email, based on how much the email differs from the pattern of life for the user. The score of the email is boosted by any actions that have taken place.

Part 6: Campaign Clustering

All emails are passed through the Darktrace / EMAIL campaign clustering system. This system creates clusters based on related features within the emails to identify groups of emails with the same sender or intent.

In our case, the email was identified as part of a campaign, alongside other emails which were also identified as extortion attempts against a small group of recipients.

Email campaigns may have additional actions applied to them if the campaign is deemed malicious, and in this case, you can see that the autonomous response was to hold all emails in the campaign. This means that if an email manages to avoid being blocked in the evaluation and combination engine but gets identified as part of the campaign, the hold action will be applied to it retroactively.

Part 7: Cyber AI Analyst

Darktrace’s Cyber AI Analyst presents key information and anomaly indicators for each email, such as further information about authentication, specific metrics, or other identified anomalies and mismatches.

Cyber AI Analyst can also utilize data from Darktrace / EMAIL to enhance its investigation of incidents from other Darktrace products, correlating relevant information to build a fuller picture. More information about the Cyber AI Analyst is available in the Darktrace AI Arsenal.

Part 8: Data Presentation (UI)

Once all processing has taken place against the email, it is presented in the Darktrace / EMAIL UI. Here, members of the SOC team can investigate incidents and anomalies, interact with malicious emails to see why they were blocked, and much more.

Our email stands out here with its 100 anomaly score. Every email which passes through a Darktrace / EMAIL will undergo the same thorough and rigorous analysis to identify potential risks, apply autonomous actions where required, and will ultimately be assigned a score to be displayed here. By providing a single overall score in the UI, rather than presenting emails in full, Darktrace / EMAIL allows SOC teams to more easily identify which emails are most important to investigate, increasing efficiency and reducing alert fatigue.

Take the next step

Many email security tools on the market that claim to be AI-driven are in fact bolting AI onto attack-centric approaches, which rely on automating the identification of known threats. These approaches struggle, and will continue to struggle, with adapting to novel, AI-generated threats.

By analyzing every email within its deeply integrated, multi-layered AI system, Darktrace / EMAIL is able to identify the subtle threats that others miss. This depth not only improves detection accuracy, but enables confident, autonomous action, giving security teams clearer insight into AI outcomes and greater control while supporting users.

For a full deep dive into each stage of the AI system, check out the white paper: A Guide to the Multi-Layered AI in Darktrace / EMAIL

Learn more about securing AI in your enterprise.

[related-resource]

Continue reading
About the author
Jamie Bali
Technical Author (AI) Developer
あなたのデータ × DarktraceのAI
唯一無二のDarktrace AIで、ネットワークセキュリティを次の次元へ