Blog
/
Network
/
September 21, 2023

How Darktrace Detected Black Basta Ransomware

Discover how Darktrace uncovered Black Basta ransomware. Learn about its tactics, techniques, and how to protect your network from this threat.
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
Matthew John
Director of Operations, SOC
Default blog image
21
Sep 2023

What is Black Basta?

Over the past year, security researchers have been tracking a new ransomware group, known as Black Basta, that has been observed targeted organizations worldwide to deploy double extortion ransomware attacks since early 2022. While the strain and group are purportedly new, evidence seen suggests they are an offshoot of the Conti ransomware group [1].

The group behind Black Basta run a Ransomware as a Service (RaaS) model. They work with initial access brokers who will typically already have a foothold in company infrastructure to begin their attacks. Once inside a network, they then pivot internally using numerous tools to further their attack.

Black Basta Ransomware

Like many other ransomware actors, Black Basta uses double extortion as part of its modus operandi, exfiltrating sensitive company data and using the publication of this as a second threat to affected companies. This is also advertised on a dark web site, setup by the group to apply further pressure for affected companies to make ransom payments and avoid reputational damage.

The group also seems to regularly take advantage of existing tools to undertake the earlier stages of their attacks. Notably, the Qakbot banking trojan, seems to be the malware often used to gain an initial foothold within compromised environments.

Analysis of the tools, procedures and infrastructure used by Black Basta belies a maturity to the actors behind the ransomware. Their models and practices suggest those involved are experienced individuals, and security researchers have drawn possible links to the Conti ransomware group.

As such, Black Basta is a particular concern for security teams as attacks will likely be more sophisticated, with attackers more patient and able to lie low on digital estates for longer, waiting for the opportune moment to strike.

Cyber security is an infinite game where defender and attacker are stuck as cat and mouse; as new attacks evolve, security vendors and teams respond to the new indicators of compromise (IoCs), and update their existing rulesets and lists. As a result, attackers are forced to change their stripes to evade detection or sometimes even readjust their targets and end goals.

Anomaly Based Detection

By using the power of Darktrace’s Self-Learning AI, security teams are able to detect deviations in behavior. Threat actors need to move through the kill chain to achieve their aims, and in doing so will cause affected devices within networks to deviate from their expected pattern of life. Darktrace’s anomaly-based approach to threat detection allows it recognize these subtle deviations that indicate the presence of an attacker, and stop them in their tracks.

Additionally, the ecosystem of cyber criminals has matured in the last few decades. It is well documented how many groups now operate akin to legitimate companies, with structure, departments and governance. As such, while new attack methods and tactics do appear in the wild, the maturity in their business models belie the experience of those behind the attack.

As attackers grow their business models and develop their arsenal of attack vectors, it becomes even more critical for security teams to remain vigilant to anomalies within networks, and remain agnostic to underlying IoCs and instead adopt anomaly detection tools able to identify tactics, techniques, and procedures (TTPs) that indicate attackers may be moving through a network, ahead of deployment of ransomware and data encryption.

Darktrace’s Coverage of Black Basta

In April 2023, the Darktrace Security Operations Center (SOC) assisted a customer in triaging and responding to an ongoing ransomware infection on their network. On a Saturday, the customer reached out directly to the Darktrace analyst team via the Ask the Expert service for support after they observed encrypted files and locked administrative accounts on their network. The analyst team were able to investigate and clarify the attack path, identifying affected devices and assisting the customer with their remediation. Darktrace DETECT™ observed varying IoCs and TTPs throughout the course of this attack’s kill chain; subsequent analysis into these indicators revealed this had likely been a case of Black Basta seen in the wild.

Initial Intrusion

The methods used by the  group to gain an initial foothold in environments varies – sometimes using phishing, sometimes gaining access through a common vulnerability exposed to the internet. Black Basta actors appear to target specific organizations, as opposed to some groups who aim to hit multiple at once in a more opportunistic fashion.

In the case of the Darktrace customer likely affected by Black Basta, it is probable that the initial intrusion was out of scope. It may be that the path was via a phishing email containing an Microsoft Excel spreadsheet that launches malicious powershell commands; a noted technique for Black Basta. [3][4]  Alternatively, the group may have worked with access brokers who already had a foothold within the customer’s network.

One particular device on the network was observed acting anomalously and was possibly the first to be infected. The device attempted to connect to multiple internal devices over SMB, and connected to a server that was later found to be compromised and is described throughout the course of this blog. During this connection, it wrote a file over SMB, “syncro.exe”, which is possibly a legitimate Remote Management software but could in theory be used to spread an infection laterally. Use of this tool otherwise appears sporadic for the network, and was notably unusual for the environment.

Given these timings, it is possible this activity is related to the likely Black Basta compromise. However, there is some evidence online that use of Syncro has been seen installed as part of the execution of loaders such as Batloader, potentially indicating a separate or concurrent attack [5].

Internal Reconnaissance + Lateral Movement

However the attackers gained access in this instance, the first suspicious activity observed by Darktrace originated from an infected server. The attacker used their foothold in the device to perform internal reconnaissance, enumerating large portions of the network. Darktrace DETECT’s anomaly detection noted a distinct rise in connections to a large number of subnets, particularly to closed ports associated with native Windows services, including:

  • 135 (RPC)
  • 139 (NetBIOS)
  • 445 (SMB)
  • 3389 (RDP)

During the enumeration, SMB connections were observed during which suspiciously named executable files were written:

  • delete.me
  • covet.me

Data Staging and Exfiltration

Around 4 hours after the scanning activity, the attackers used their knowledge gained during enumeration about the environment to begin gathering and staging data for their double extortion attempts. Darktrace observed the same infected server connecting to a file storage server, and downloading over 300 GiB of data. Darktrace DETECT identified that the connections had been made via SMB and was able to present a list of filenames to the customer, allowing their security team to determine the data that had likely been exposed to the attackers.

The SMB paths detected by Darktrace showed a range of departments’ file areas being accessed by threat actors. This suggests they were interested in getting as much varied data as possible, presumably in an attempt to ensure a large amount of valuable information was at their disposal to make any threats of releasing them more credible, and more damaging to the company.

Shortly after the download, the device made an external connection over SSH to a rare domain, dataspt[.]com, hosted in the United States. The connection itself was made over an unusual port, 2022, and Darktrace recognized that the domain was new for the network.

During this upload, the threat actors uploaded a similar volume of data to the 300GiB that had been downloaded internally earlier. Darktrace flagged the usual elements of this external upload, making the identification and triage of this exfiltration attempt easier for the customer.

On top of this, Darktrace’s autonomous investigation tool Cyber AI Analyst™ launched an investigation into this on-going activity and was able to link the external upload events to the internal download, identifying them as one exfiltration incident rather than two isolated events. AI Analyst then provided a detailed summary of the activity detected, further speeding up the identification of affected files.

Preparing for Exploitation

All the activity documented so far had occurred on a Wednesday evening. It was at this point that the burst of activity calmed, and the ransomware lay in wait within the environment. Other devices around the network, particularly those connected to by the original infected server and a domain controller, were observed performing some elements of anomalous activity, but the attack seemed to largely take a pause.

However, on the Saturday morning, 3 days later, the compromised server began to change the way it communicated with attackers by reaching out to a new command and control (C2) endpoint. It seemed that attackers were gearing up for their attack, taking advantage of the weekend to strike while security teams often run with a reduced staffing.

Darktrace identified connections to a new endpoint within 4 minutes of it first being seen on the customer’s environment. The server had begun making repeated SSL connections to the new external endpoint, faceappinc[.]com, which has been flagged as malicious by various open-source intelligence (OSINT) sources.

The observed JA3 hash (d0ec4b50a944b182fc10ff51f883ccf7) suggests that the command-line tool BITS Admin was being used to launch these connections, another suggestion of the use of mature tooling.

In addition to this, Darktrace also detected the server using an administrative credential it had never previously been associated with. Darktrace recognized that the use of this credential represented a deviation from the device’s usual activity and thus could be indicative of compromise.

The server then proceeded to use the new credential to authenticate over Keberos before writing a malicious file (“management.exe”) to the Temp directory on a number of internal devices.

Encryption

At this point, the number of anomalous activities detected from the server increased massively as the attacker seems to connect networkwide in an attempt to cause as quick and destructive an encryption effort as possible. Darktrace observed numerous files that had been encrypted by a local process. The compromised server began to write ransom notes, named “instructions_read_me.txt” to other file servers, which presumably also had successfully deployed payloads. While Black Basta actors had initially been observed dropping ransom notes named “readme.txt”, security researchers have since observed and reported an updated variant of the ransomware that drops “instructions_read_me_.txt”, the name of the file detected by Darktrace, instead [6].

Another server was also observed making repeated SSL connections to the same rare external endpoint, faceappinc[.]com. Shortly after beginning these connections, the device made an HTTP connection to a rare IP address with no hostname, 212.118.55[.]211. During this connection, the device also downloaded a suspicious executable file, cal[.]linux. OSINT research linked the hash of this file to a Black Basta Executable and Linkable File (ELF) variant, indicating that the group was highly likely behind this ransomware attack.

Of particular interest again, is how the attacker lives off the land, utilizing pre-installed Windows services. Darktrace flagged that the server was observed using PsExec, a remote management executable, on multiple devices.

Darktrace Assistance

Darktrace DETECT was able to clearly detect and provide visibility over all stages of the ransomware attack, alerting the customer with multiple model breaches and AI Analyst investigation(s) and highlighting suspicious activity throughout the course of the attack.

For example, the exfiltration of sensitive data was flagged for a number of anomalous features of the meta-data: volume; rarity of the endpoint; port and protocol used.

In total, the portion of the attack observed by Darktrace lasted about 4 days from the first model breach until the ransomware was deployed. In particular, the encryption itself was initiated on a Saturday.

The encryption event itself was initiated on a Saturday, which is not uncommon as threat actors tend to launch their destructive attacks when they expect security teams will be at their lowest capacity. The Darktrace SOC team regularly observes and assists in customer’s in the face of ransomware actors who patiently lie in wait. Attackers often choose to strike as security teams run on reduced hours of manpower, sometimes even choosing to deploy ahead of longer breaks for national or public holidays, for example.

In this case, the customer contacted Darktrace directly through the Ask the Expert (ATE) service. ATE offers customers around the clock access to Darktrace’s team of expert analysts. Customers who subscribe to ATE are able to send queries directly to the analyst team if they are in need of assistance in the face of suspicious network activity or emerging attacks.

In this example, Darktrace’s team of expert analysts worked in tandem with Cyber AI Analyst to investigate the ongoing compromise, ensuring that the investigation and response process were completed as quickly and efficiently as possible.

Thanks to Darktrace’s Self-Learning AI, the analyst team were able to quickly produce a detailed report enumerating the timeline of events. By combining the human expertise of the analyst team and the machine learning capabilities of AI Analyst, Darktrace was able to quickly identify anomalous activity being performed and the affected devices. AI Analyst was then able to collate and present this information into a comprehensive and digestible report for the customer to consult.

Conclusion

It is likely that this ransomware attack was undertaken by the Black Basta group, or at least using tools related to their method. Although Black Basta itself is a relatively novel ransomware strain, there is a maturity and sophistication to its tactics. This indicates that this new group are actually experienced threat actors, with evidence pointing towards it being an offshoot of Conti.

The Pyramid of Pain is a well trodden model in cyber security, but it can help us understand the various features of an attack. Indicators like static C2 destinations or file hashes can easily be changed, but it’s the underlying TTPs that remain the same between attacks.

In this case, the attackers used living off the land techniques, making use of tools such as BITSAdmin, as well as using tried and tested malware such as Qakbot. While the domains and IPs involved will change, the way these malware interact and move about systems remains the same. Their fingerprint therefore causes very similar anomalies in network traffic, and this is where the strength of Darktrace lies.

Darktrace’s anomaly-based approach to threat detection means that these new attack types are quickly drawn out of the noise of everyday traffic within an environment. Once attackers have gained a foothold in a network, they will have to cause deviation from the usual pattern of a life on a network to proceed; Darktrace is uniquely placed to detect even the most subtle changes in a device’s behavior that could be indicative of an emerging threat.

Machine learning can act as a force multiplier for security teams. Working hand in hand with the Darktrace SOC, the customer was able to generate cohesive and comprehensive reporting on the attack path within days. This would be a feat for humans alone, requiring significant resources and time, but with the power of Darktrace’s Self-Learning AI, these deep and complex analyses become as easy as the click of a button.

Credit to: Matthew John, Director of Operations, SOC, Paul Jennings, Principal Analyst Consultant

Get the latest insights on emerging cyber threats

Attackers are adapting, are you ready? This report explores the latest trends shaping the cybersecurity landscape and what defenders need to know in 2025.

  • Identity-based attacks: How attackers are bypassing traditional defenses
  • Zero-day exploitation: The rise of previously unknown vulnerabilities
  • AI-driven threats: How adversaries are leveraging AI to outmaneuver security controls

Stay ahead of evolving threats with expert analysis from Darktrace. Download the report here.

Appendices

Darktrace DETECT Model Breaches

Internal Reconnaissance

Device / Multiple Lateral Movement Model Breaches

Device / Large Number of Model Breaches

Device / Network Scan

Device / Anomalous RDP Followed by Multiple Model Breaches

Device / Possible SMB/NTLM Reconnaissance

Device / SMB Lateral Movement

Anomalous Connection / SMB Enumeration

Anomalous Connection / Possible Share Enumeration Activity

Device / Suspicious SMB Scanning Activity

Device / RDP Scan

Anomalous Connection / Active Remote Desktop Tunnel

Device / Increase in New RPC Services

Device / ICMP Address Scan

Download and Upload

Unusual Activity / Enhanced Unusual External Data Transfer

Unusual Activity / Unusual External Data Transfer

Anomalous Connection / Uncommon 1 GiB Outbound

Anomalous Connection / Data Sent to Rare Domain

Anomalous Connection / Download and Upload

Compliance / SSH to Rare External Destination

Anomalous Server Activity / Rare External from Server

Anomalous Server Activity / Outgoing from Server

Anomalous Connection / Application Protocol on Uncommon Port

Anomalous Connection / Multiple Connections to New External TCP Port

Device / Anomalous SMB Followed By Multiple Model Breaches

Unusual Activity / SMB Access Failures

Lateral Movement and Encryption

User / New Admin Credentials on Server

Compliance / SMB Drive Write

Device / Anomalous RDP Followed By Multiple Model Breaches

Anomalous Connection / High Volume of New or Uncommon Service Control

Anomalous Connection / New or Uncommon Service Control

Device / New or Unusual Remote Command Execution

Anomalous Connection / SMB Enumeration

Additional Beaconing and Tooling

Device / Initial Breach Chain Compromise

Device / Multiple C2 Model Breaches

Compromise / Large Number of Suspicious Failed Connections

Compromise / Sustained SSL or HTTP Increase

Compromise / SSL or HTTP Beacon

Compromise / Suspicious Beaconing Behavior

Compromise / Large Number of Suspicious Successful Connections

Compromise / High Volume of Connections with Beacon Score

Compromise / Slow Beaconing Activity To External Rare

Compromise / SSL Beaconing to Rare Destination

Compromise / Beaconing Activity To External Rare

Compromise / Beacon to Young Endpoint

Compromise / Agent Beacon to New Endpoint

Anomalous Server Activity / Rare External from Server

Anomalous Connection / Multiple Failed Connections to Rare Endpoint

Anomalous File / EXE from Rare External Location

IoC - Type - Description + Confidence

dataspt[.]com - Hostname - Highly Likely Exfiltration Server

46.22.211[.]151:2022 - IP Address and Unusual Port - Highly Likely Exfiltration Server

faceappinc[.]com - Hostname - Likely C2 Infrastructure

Instructions_read_me.txt - Filename - Almost Certain Ransom Note

212.118.55[.]211 - IP Address - Likely C2 Infrastructure

delete[.]me - Filename - Potential lateral movement script

covet[.]me - Filename - Potential lateral movement script

d0ec4b50a944b182fc10ff51f883ccf7 - JA3 Client Fingerprint - Potential Windows BITS C2 Process

/download/cal.linux - URI - Likely BlackBasta executable file

1f4dcfa562f218fcd793c1c384c3006e460213a8 - Sha1 File Hash - Likely BlackBasta executable file

References

[1] https://blogs.blackberry.com/en/2022/05/black-basta-rebrand-of-conti-or-something-new

[2] https://www.cybereason.com/blog/threat-alert-aggressive-qakbot-campaign-and-the-black-basta-ransomware-group-targeting-u.s.-companies

[3] https://www.trendmicro.com/en_us/research/22/e/examining-the-black-basta-ransomwares-infection-routine.html

[4] https://unit42.paloaltonetworks.com/atoms/blackbasta-ransomware/

[5] https://www.trendmicro.com/en_gb/research/23/a/batloader-malware-abuses-legitimate-tools-uses-obfuscated-javasc.html

[6] https://www.pcrisk.com/removal-guides/23666-black-basta-ransomware

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
Matthew John
Director of Operations, SOC

More in this series

No items found.

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

Blog

/

Email

/

May 26, 2026

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

Man at a computerDefault 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
Your data. Our AI.
Elevate your network security with Darktrace AI