Blog
/
Network
/
July 26, 2022

Identifying PrivateLoader Network Threats

Learn how Darktrace identifies network-based indicators of compromise for the PrivateLoader malware. Gain insights into advanced threat detection.
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
Sam Lister
Specialist Security Researcher
Written by
Shuh Chin Goh
Default blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog image
26
Jul 2022

Instead of delivering their malicious payloads themselves, threat actors can pay certain cybercriminals (known as pay-per-install (PPI) providers) to deliver their payloads for them. Since January 2022, Darktrace’s SOC has observed several cases of PPI providers delivering their clients’ payloads using a modular malware downloader known as ‘PrivateLoader’.

This blog will explore how these PPI providers installed PrivateLoader onto systems and outline the steps which the infected PrivateLoader bots took to install further malicious payloads. The details provided here are intended to provide insight into the operations of PrivateLoader and to assist security teams in identifying PrivateLoader bots within their own networks.  

Threat Summary 

Between January and June 2022, Darktrace identified the following sequence of network behaviours within the environments of several Darktrace clients. Patterns of activity involving these steps are paradigmatic examples of PrivateLoader activity:

1. A victim’s device is redirected to a page which instructs them to download a password-protected archive file from a file storage service — typically Discord Content Delivery Network (CDN)

2. The device contacts a file storage service (typically Discord CDN) via SSL connections

3. The device either contacts Pastebin via SSL connections, makes an HTTP GET request with the URI string ‘/server.txt’ or ‘server_p.txt’ to 45.144.225[.]57, or makes an HTTP GET request with the URI string ‘/proxies.txt’ to 212.193.30[.]45

4. The device makes an HTTP GET request with the URI string ‘/base/api/statistics.php’ to either 212.193.30[.]21, 85.202.169[.]116, 2.56.56[.]126 or 2.56.59[.]42

5. The device contacts a file storage service (typically Discord CDN) via SSL connections

6. The device makes a HTTP POST request with the URI string ‘/base/api/getData.php’ to either 212.193.30[.]21, 85.202.169[.]116, 2.56.56[.]126 or 2.56.59[.]42

7. The device finally downloads malicious payloads from a variety of endpoints

The PPI Business 

Before exploring PrivateLoader in more detail, the pay-per-install (PPI) business should be contextualized. This consists of two parties:  

1. PPI clients - actors who want their malicious payloads to be installed onto a large number of target systems. PPI clients are typically entry-level threat actors who seek to widely distribute commodity malware [1]

2. PPI providers - actors who PPI clients can pay to install their malicious payloads 

As the smugglers of the cybercriminal world, PPI providers typically advertise their malware delivery services on underground web forums. In some cases, PPI services can even be accessed via Clearnet websites such as InstallBest and InstallShop [2] (Figure 1).  

Figure 1: A snapshot of the InstallBest PPI login page [2]


To utilize a PPI provider’s service, a PPI client must typically specify: 

(A)  the URLs of the payloads which they want to be installed

(B)  the number of systems onto which they want their payloads to be installed

(C)  their geographical targeting preferences. 

Payment of course, is also required. To fulfil their clients’ requests, PPI providers typically make use of downloaders - malware which instructs the devices on which it is running to download and execute further payloads. PPI providers seek to install their downloaders onto as many systems as possible. Follow-on payloads are usually determined by system information garnered and relayed back to the PPI providers’ command and control (C2) infrastructure. PPI providers may disseminate their downloaders themselves, or they may outsource the dissemination to third parties called ‘affiliates’ [3].  

Back in May 2021, Intel 471 researchers became aware of PPI providers using a novel downloader (dubbed ‘PrivateLoader’) to conduct their operations. Since Intel 471’s public disclosure of the downloader back in Feb 2022 [4], several other threat research teams, such as the Walmart Cyber Intel Team [5], Zscaler ThreatLabz [6], and Trend Micro Research [7] have all provided valuable insights into the downloader’s behaviour. 

Anatomy of a PrivateLoader Infection

The PrivateLoader downloader, which is written in C++, was originally monolithic (i.e, consisted of only one module). At some point, however, the downloader became modular (i.e, consisting of multiple modules). The modules communicate via HTTP and employ various anti-analysis methods. PrivateLoader currently consists of the following three modules [8]: 

  • The loader module: Instructs the system on which it is running to retrieve the IP address of the main C2 server and to download and execute the PrivateLoader core module
  • The core module: Instructs the system on which it is running to send system information to the main C2 server, to download and execute further malicious payloads, and to relay information regarding installed payloads back to the main C2 server
  • The service module: Instructs the system on which it is running to keep the PrivateLoader modules running

Kill Chain Deep-Dive 

The chain of activity starts with the user’s browser being redirected to a webpage which instructs them to download a password-protected archive file from a file storage service such as Discord CDN. Discord is a popular VoIP and instant messaging service, and Discord CDN is the service’s CDN infrastructure. In several cases, the webpages to which users’ browsers were redirected were hosted on ‘hero-files[.]com’ (Figure 2), ‘qd-files[.]com’, and ‘pu-file[.]com’ (Figure 3). 

Figure 2: An image of a page hosted on hero-files[.]com - an endpoint which Darktrace observed systems contacting before downloading PrivateLoader from Discord CDN
Figure 3: An image of a page hosted on pu-file[.]com- an endpoint which Darktrace observed systems contacting before downloading PrivateLoader from Discord CDN


On attempting to download cracked/pirated software, users’ browsers were typically redirected to download instruction pages. In one case however, a user’s device showed signs of being infected with the malicious Chrome extension, ChromeBack [9], immediately before it contacted a webpage providing download instructions (Figure 4). This may suggest that cracked software downloads are not the only cause of users’ browsers being redirected to these download instruction pages (Figure 5). 

Figure 4: The event log for this device (taken from the Darktrace Threat Visualiser interface) shows that the device contacted endpoints associated with ChromeBack ('freychang[.]fun') prior to visiting a page ('qd-file[.]com') which instructed the device’s user to download an archive file from Discord CDN
 Figure 5: An image of the website 'crackright[.]com'- a provider of cracked software. Systems which attempted to download software from this website were subsequently led to pages providing instructions to download a password-protected archive from Discord CDN


After users’ devices were redirected to pages instructing them to download a password-protected archive, they subsequently contacted cdn.discordapp[.]com over SSL. The archive files which users downloaded over these SSL connections likely contained the PrivateLoader loader module. Immediately after contacting the file storage endpoint, users’ devices were observed either contacting Pastebin over SSL, making an HTTP GET request with the URI string ‘/server.txt’ or ‘server_p.txt’ to 45.144.225[.]57, or making an HTTP GET request with the URI string ‘/proxies.txt’ to 212.193.30[.]45 (Figure 6).

Distinctive user-agent strings such as those containing question marks (e.g. ‘????ll’) and strings referencing outdated Chrome browser versions were consistently seen in these HTTP requests. The following chrome agent was repeatedly observed: ‘Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.169 Safari/537.36’.

In some cases, devices also displayed signs of infection with other strains of malware such as the RedLine infostealer and the BeamWinHTTP malware downloader. This may suggest that the password-protected archives embedded several payloads.

Figure 6: This figure, obtained from Darktrace's Advanced Search interface, represents the post-infection behaviour displayed by a PrivateLoader bot. After visiting hero-files[.]com and downloading the PrivateLoader loader module from Discord CDN, the device can be seen making HTTP GET requests for ‘/proxies.txt’ and ‘/server.txt’ and contacting pastebin[.]com

It seems that PrivateLoader bots contact Pastebin, 45.144.225[.]57, and 212.193.30[.]45 in order to retrieve the IP address of PrivateLoader’s main C2 server - the server which provides PrivateLoader bots with payload URLs. This technique used by the operators of PrivateLoader closely mirrors the well-known espionage tactic known as ‘dead drop’.

The dead drop is a method of espionage tradecraft in which an individual leaves a physical object such as papers, cash, or weapons in an agreed hiding spot so that the intended recipient can retrieve the object later on without having to come in to contact with the source. When threat actors host information about core C2 infrastructure on intermediary endpoints, the hosted information is analogously called a ‘Dead Drop Resolver’ or ‘DDR’. Example URLs of DDRs used by PrivateLoader:

  • https://pastebin[.]com/...
  • http://212.193.30[.]45/proxies.txt
  • http://45.144.225[.]57/server.txt
  • http://45.144.255[.]57/server_p.txt

The ‘proxies.txt’ DDR hosted on 212.193.40[.]45 contains a list of 132 IP address / port pairs. The 119th line of this list includes a scrambled version of the IP address of PrivateLoader’s main C2 server (Figures 7 & 8). Prior to June, it seems that the main C2 IP address was ‘212.193.30[.]21’, however, the IP address appears to have recently changed to ‘85.202.169[.]116’. In a limited set of cases, Darktrace also observed PrivateLoader bots retrieving payload URLs from 2.56.56[.]126 and 2.56.59[.]42 (rather than from 212.193.30[.]21 or 85.202.169[.]116). These IP addresses may be hardcoded secondary C2 address which PrivateLoader bots use in cases where they are unable to retrieve the primary C2 address from Pastebin, 212.193.30[.]45 or 45.144.255[.]57 [10]. 

Figure 7: Before June, the 119th entry of the ‘proxies.txt’ file lists '30.212.21.193' -  a scrambling of the ‘212.193.30[.]21’ main C2 IP address
Figure 8: Since June, the 119th entry of the ‘proxies.txt’ file lists '169.85.116.202' - a scrambling of the '85.202.169[.]116' main C2 IP address

Once PrivateLoader bots had retrieved C2 information from either Pastebin, 45.144.225[.]57, or 212.193.30[.]45, they went on to make HTTP GET requests for ‘/base/api/statistics.php’ to either 212.193.30[.]21, 85.202.169[.]116, 2.56.56[.]126, or 2.56.59[.]42 (Figure 9). The server responded to these requests with an XOR encrypted string. The strings were encrypted using a 1-byte key [11], such as 0001101 (Figure 10). Decrypting the string revealed a URL for a BMP file hosted on Discord CDN, such as ‘hxxps://cdn.discordapp[.]com/attachments/978284851323088960/986671030670078012/PL_Client.bmp’. These encrypted URLs appear to be file download paths for the PrivateLoader core module. 

Figure 9: HTTP response from server to an HTTP GET request for '/base/api/statistics.php'
Figure 10: XOR decrypting the string with the one-byte key, 00011101, outputs a URL in CyberChef

After PrivateLoader bots retrieved the 'cdn.discordapp[.]com’ URL from 212.193.30[.]21, 85.202.169[.]116, 2.56.56[.]126, or 2.56.59[.]42, they immediately contacted Discord CDN via SSL connections in order to obtain the PrivateLoader core module. Execution of this module resulted in the bots making HTTP POST requests (with the URI string ‘/base/api/getData.php’) to the main C2 address (Figures 11 & 12). Both the data which the PrivateLoader bots sent over these HTTP POST requests and the data returned via the C2 server’s HTTP responses were heavily encrypted using a combination of password-based key derivation, base64 encoding, AES encryption, and HMAC validation [12]. 

Figure 11: The above image, taken from Darktrace's Advanced Search interface, shows a PrivateLoader bot carrying out the following steps: contact ‘hero-files[.]com’ --> contact ‘cdn.discordapp[.]com’ --> retrieve ‘/proxies.txt’ from 212.193.30[.]45 --> retrieve ‘/base/api/statistics.php’ from 212.193.30[.]21 --> contact ‘cdn.discordapp[.]com --> make HTTP POST request with the URI ‘base/api/getData.php’ to 212.193.30[.]21
Figure 12: A PCAP of the data sent via the HTTP POST (in red), and the data returned by the C2 endpoint (in blue)

These ‘/base/api/getData.php’ POST requests contain a command, a campaign name and a JSON object. The response may either contain a simple status message (such as “success”) or a JSON object containing URLs of payloads. After making these HTTP connections, PrivateLoader bots were observed downloading and executing large volumes of payloads (Figure 13), ranging from crypto-miners to infostealers (such as Mars stealer), and even to other malware downloaders (such as SmokeLoader). In some cases, bots were also seen downloading files with ‘.bmp’ extensions, such as ‘Service.bmp’, ‘Cube_WW14.bmp’, and ‘NiceProcessX64.bmp’, from 45.144.225[.]57 - the same DDR endpoint from which PrivateLoader bots retrieved main C2 information. These ‘.bmp’ payloads are likely related to the PrivateLoader service module [13]. Certain bots made follow-up HTTP POST requests (with the URI string ‘/service/communication.php’) to either 212.193.30[.]21 or 85.202.169[.]116, indicating the presence of the PrivateLoader service module, which has the purpose of establishing persistence on the device (Figure 14). 

Figure 13: The above image, taken from Darktrace's Advanced Search interface, outlines the plethora of malware payloads downloaded by a PrivateLoader bot after it made an HTTP POST request to the ‘/base/api/getData.php’ endpoint. The PrivateLoader service module is highlighted in red
Figure 14: The event log for a PrivateLoader bot, obtained from the Threat Visualiser interface, shows a device making HTTP POST requests to ‘/service/communication.php’ and connecting to the NanoPool mining pool, indicating successful execution of downloaded payloads

In several observed cases, PrivateLoader bots downloaded another malware downloader called ‘SmokeLoader’ (payloads named ‘toolspab2.exe’ and ‘toolspab3.exe’) from “Privacy Tools” endpoints [14], such as ‘privacy-tools-for-you-802[.]com’ and ‘privacy-tools-for-you-783[.]com’. These “Privacy Tools” domains are likely impersonation attempts of the legitimate ‘privacytools[.]io’ website - a website run by volunteers who advocate for data privacy [15]. 

After downloading and executing malicious payloads, PrivateLoader bots were typically seen contacting crypto-mining pools, such as NanoPool, and making HTTP POST requests to external hosts associated with SmokeLoader, such as hosts named ‘host-data-coin-11[.]com’ and ‘file-coin-host-12[.]com’ [16]. In one case, a PrivateLoader bot went on to exfiltrate data over HTTP to an external host named ‘cheapf[.]link’, which was registered on the 14th March 2022 [17]. The name of the file which the PrivateLoader bot used to exfiltrate data was ‘NOP8QIMGV3W47Y.zip’, indicating information stealing activities by Mars Stealer (Figure 15) [18]. By saving the HTTP stream as raw data and utilizing a hex editor to remove the HTTP header portions, the hex data of the ZIP file was obtained. Saving the hex data using a ‘.zip’ extension and extracting the contents, a file directory consisting of system information and Chrome and Edge browsers’ Autofill data in cleartext .txt file format could be seen (Figure 16).

Figure 15: A PCAP of a PrivateLoader bot’s HTTP POST request to cheapf[.]link, with data sent by the bot appearing to include Chrome and Edge autofill data, as well as system information
Figure 16: File directory structure and files of the ZIP archive 

When left unattended, PrivateLoader bots continued to contact C2 infrastructure in order to relay details of executed payloads and to retrieve URLs of further payloads. 

Figure 17: Timeline of the attack

Darktrace Coverage 

Most of the incidents surveyed for this article belonged to prospective customers who were trialling Darktrace with RESPOND in passive mode, and thus without the ability for autonomous intervention. However in all observed cases, Darktrace DETECT was able to provide visibility into the actions taken by PrivateLoader bots. In one case, despite the infected bot being disconnected from the client’s network, Darktrace was still able to provide visibility into the device’s network behaviour due to the client’s usage of Darktrace/Endpoint. 

If a system within an organization’s network becomes infected with PrivateLoader, it will display a range of anomalous network behaviours before it downloads and executes malicious payloads. For example, it will contact Pastebin or make HTTP requests with new and unusual user-agent strings to rare external endpoints. These network behaviours will generate some of the following alerts on the Darktrace UI:

  • Compliance / Pastebin 
  • Device / New User Agent and New IP
  • Device / New User Agent
  • Device / Three or More New User Agents
  • Anomalous Connection / New User Agent to IP Without Hostname
  • Anomalous Connection / POST to PHP on New External Host
  • Anomalous Connection / Posting HTTP to IP Without Hostname

Once the infected host obtains URLs for malware payloads from a C2 endpoint, it will likely start to download and execute large volumes of malicious files. These file downloads will usually cause Darktrace to generate some of the following alerts:

  • Anomalous File / EXE from Rare External Location
  • Anomalous File / Numeric Exe Download
  • Anomalous File / Masqueraded File Transfer
  • Anomalous File / Multiple EXE from Rare External Locations
  • Device / Initial Breach Chain Compromise

If RESPOND is deployed in active mode, Darktrace will be able to autonomously block the download of additional malware payloads onto the target machine and the subsequent beaconing or crypto-mining activities through network inhibitors such as ‘Block matching connections’, ‘Enforce pattern of life’ and ‘Block all outgoing traffic’. The ‘Enforce pattern of life’ action results in a device only being able to make connections and data transfers which Darktrace considers normal for that device. The ‘Block all outgoing traffic’ action will cause all traffic originating from the device to be blocked. If the customer has Darktrace’s Proactive Threat Notification (PTN) service, then a breach of an Enhanced Monitoring model such as ‘Device / Initial Breach Chain Compromise’ will result in a Darktrace SOC analyst proactively notifying the customer of the suspicious activity. Below is a list of Darktrace RESPOND (Antigena) models which would be expected to breach due to PrivateLoader activity. Such models can seriously hamper attempts made by PrivateLoader bots to download malicious payloads. 

  • Antigena / Network / External Threat / Antigena Suspicious File Block
  • Antigena / Network / Significant Anomaly / Antigena Controlled and Model Breach
  • Antigena / Network / External Threat / Antigena File then New Outbound Block
  • Antigena / Network / Significant Anomaly / Antigena Significant Anomaly from Client Block 
  • Antigena / Network / Significant Anomaly / Antigena Breaches Over Time Block

In one observed case, the infected bot began to download malicious payloads within one minute of becoming infected with PrivateLoader. Since RESPOND was correctly configured, it was able to immediately intervene by autonomously enforcing the device’s pattern of life for 2 hours and blocking all of the device’s outgoing traffic for 10 minutes (Figure 17). When malware moves at such a fast pace, the availability of autonomous response technology, which can respond immediately to detected threats, is key for the prevention of further damage.  

Figure 18: The event log for a Darktrace RESPOND (Antigena) model breach shows Darktrace RESPOND performing inhibitive actions once the PrivateLoader bot begins to download payloads

Conclusion

By investigating PrivateLoader infections over the past couple of months, Darktrace has observed PrivateLoader operators making changes to the downloader’s main C2 IP address and to the user-agent strings which the downloader uses in its C2 communications. It is relatively easy for the operators of PrivateLoader to change these superficial network-based features of the malware in order to evade detection [19]. However, once a system becomes infected with PrivateLoader, it will inevitably start to display anomalous patterns of network behaviour characteristic of the Tactics, Techniques and Procedures (TTPs) discussed in this blog.

Throughout 2022, Darktrace observed overlapping patterns of network activity within the environments of several customers, which reveal the archetypal steps of a PrivateLoader infection. Despite the changes made to PrivateLoader’s network-based features, Darktrace’s Self-Learning AI was able to continually identify infected bots, detecting every stage of an infection without relying on known indicators of compromise. When configured, RESPOND was able to immediately respond to such infections, preventing further advancement in the cyber kill chain and ultimately preventing the delivery of floods of payloads onto infected devices.

IoCs

MITRE ATT&CK Techniques Observed

References

[1], [8],[13] https://www.youtube.com/watch?v=Ldp7eESQotM  

[2] https://news.sophos.com/en-us/2021/09/01/fake-pirated-software-sites-serve-up-malware-droppers-as-a-service/

[3] https://www.researchgate.net/publication/228873118_Measuring_Pay-per Install_The_Commoditization_of_Malware_Distribution 

[4], [15] https://intel471.com/blog/privateloader-malware

[5] https://medium.com/walmartglobaltech/privateloader-to-anubis-loader-55d066a2653e 

[6], [10],[11], [12] https://www.zscaler.com/blogs/security-research/peeking-privateloader 

[7] https://www.trendmicro.com/en_us/research/22/e/netdooka-framework-distributed-via-privateloader-ppi.html

[9] https://www.gosecure.net/blog/2022/02/10/malicious-chrome-browser-extension-exposed-chromeback-leverages-silent-extension-loading/

[14] https://www.proofpoint.com/us/blog/threat-insight/malware-masquerades-privacy-tool 

[16] https://asec.ahnlab.com/en/30513/ 

[17]https://twitter.com/0xrb/status/1515956690642161669

[18] https://isc.sans.edu/forums/diary/Arkei+Variants+From+Vidar+to+Mars+Stealer/28468

[19] http://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html

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
Sam Lister
Specialist Security Researcher
Written by
Shuh Chin Goh

More in this series

No items found.

Blog

/

Compliance

/

November 25, 2025

UK Cyber Security & Resilience Bill: What Organizations Need to Know

Default blog imageDefault blog image

Why the Bill has been introduced

The UK’s cyber threat landscape has evolved dramatically since the 2018 NIS regime was introduced. Incidents such as the Synnovis attack against hospitals and the British Library ransomware attack show how quickly operational risk can become public harm. In this context, the UK Department for Science, Innovation and Technology estimates that cyber-attacks cost UK businesses around £14.7 billion each year.

At the same time, the widespread adoption of AI has expanded organisations’ attack surfaces and empowered threat actors to launch more effective and sophisticated activities, including crafting convincing phishing campaigns, exploiting vulnerabilities and initiating ransomware attacks at unprecedented speed and scale.  

The CSRB responds to these challenges by widening who is regulated, accelerating incident reporting and tightening supply chain accountability, while enabling rapid updates that keep pace with technology and emerging risks.

Key provisions of the Cyber Security and Resilience Bill

A wider set of organisations in scope

The Bill significantly broadens the range of organisations regulated under the NIS framework.

  • Managed service providers (MSPs) - medium and large MSPs, including MSSPs, managed SOCs, SIEM providers and similar services,will now fall under NIS obligations due to their systemic importance and privileged access to client systems. The Information Commissioner’s Office (ICO) will act as the regulator. Government analysis anticipates that a further 900 to 1,100 MSPs will be in scope.
  • Data infrastructure is now recognised as essential to the functioning of the economy and public services. Medium and large data centres, as well as enterprise facilities meeting specified thresholds, will be required to implement appropriate and proportionate measures to manage cyber risk. Oversight will be shared between DSIT and Ofcom, with Ofcom serving as the operational regulator.
  • Organisations that manage electrical loads for smart appliances, such as those supporting EV charging during peak times, are now within scope.

These additions sit alongside existing NIS-regulated sectors such as transport, energy, water, health, digital infrastructure, and certain digital services (including online marketplaces, search engines, and cloud computing).

Stronger supply chain requirements

Under the CSRB, regulators can now designate third-party suppliers as ‘designated critical suppliers’ (DCS) when certain threshold criteria are met and where disruption could have significant knock-on effects. Designated suppliers will be subject to the same security and incident-reporting obligations as Operators of Essential Services (OES) and Relevant Digital Service Providers (RDSPs).

Government will scope the supply chain duties for OES and RDSPs via secondary legislation, following consultation. infrastructure incidents where a single supplier’s compromise caused widespread disruption.

Faster incident reporting

Sector-specific regulators, 12 in total, will be responsible for implementing the CSRB, allowing for more effective and consistent reporting. In addition, the CSRB introduces a two-stage reporting process and expands incident reporting criteria. Regulated entities must submit an initial notification within 24 hours of becoming aware of a significant incident, followed by an incident report within 72 hours. Incident reporting criteria are also broadened to capture incidents beyond those which actually resulted in an interruption, ensuring earlier visibility for regulators and the National Cyber Security Centre (NCSC). The importance of information sharing across agencies, law enforcement and regulators is also facilitated by the CSRB.

The reforms also require data centres and managed service providers to notify affected customers where they are likely to have been impacted by a cyber incident.

An agile regulatory framework

To keep pace with technological change, the CSRB will enable the Secretary of State to update elements of the framework via secondary legislation. Supporting materials such as the NCSC Cyber Assessment Framework (CAF) are to be "put on a stronger footing” allowing for requirements to be more easily followed, managed and updated. Regulators will also now be able to recover full costs associated with NIS duties meaning they are better resourced to carry out their associated responsibilities.

Relevant Managed Service Providers must identify and take appropriate and proportionate measures to manage risks to the systems they rely on for providing services within the UK. Importantly, these measures must, having regard to the state of the art, ensure a level of security appropriate to the risk posed, and prevent or minimise the impact of incidents.

The Secretary of State will also be empowered to issue a Statement of Strategic Priorities, setting cross-regime outcomes to drive consistency across the 12 competent authorities responsible for implementation.

Penalties

The enforcement framework will be strengthened, with maximum fines aligned with comparable regimes such as the GDPR, which incorporate maximums tied to turnover. Under the CSRB, maximum penalties for more serious breaches could be up to £17 million or 4% of global turnover, whichever is higher.

Next steps

The Bill is expected to progress through Parliament over the course of 2025 and early 2026, with Royal Assent anticipated in 2026. Once enacted, most operational measures will not take immediate effect. Instead, Government will bring key components into force through secondary legislation following further consultation, providing regulators and industry with time to adjust practices and prepare for compliance.

Anticipated timeline

  • 2025-2026: Parliamentary scrutiny and passage;
  • 2026: Royal Assent;  
  • 2026 consultation: DSIT intends to consult on detailed implementation;
  • From 2026 onwards: Phased implementation via secondary legislation, following further consultation led by DSIT.

How Darktrace can help

The CSRB represents a step change in how the UK approaches digital risk, shifting the focus from compliance to resilience.

Darktrace can help organisations operationalise this shift by using AI to detect, investigate and respond to emerging threats at machine speed, before they escalate into incidents requiring regulatory notification. Proactive tools which can be included in the Darktrace platform allow security teams to stress-test defences, map supply chain exposure and rehearse recovery scenarios, directly supporting the CSRB’s focus on resilience, transparency and rapid response. If an incident does occur, Darktrace’s autonomous agent, Cyber AI Analyst, can accelerate investigations and provide a view of every stage of the attack chain, supporting timely reporting.  

Darktrace’s AI can provide organisations with a vital lens into both internal and external cyber risk. By continuously learning patterns of behaviour across interconnected systems, Darktrace can flag potential compromise or disruption to detect supply chain risk before it impacts your organisation.

In a landscape where compliance and resilience go hand in hand, Darktrace can equip organisations to stay ahead of both evolving threats and evolving regulatory requirements.

[related-resource]

Continue reading
About the author
The Darktrace Community

Blog

/

OT

/

November 20, 2025

Managing OT Remote Access with Zero Trust Control & AI Driven Detection

managing OT remote access with zero trust control and ai driven detectionDefault blog imageDefault blog image

The shift toward IT-OT convergence

Recently, industrial environments have become more connected and dependent on external collaboration. As a result, truly air-gapped OT systems have become less of a reality, especially when working with OEM-managed assets, legacy equipment requiring remote diagnostics, or third-party integrators who routinely connect in.

This convergence, whether it’s driven by digital transformation mandates or operational efficiency goals, are making OT environments more connected, more automated, and more intertwined with IT systems. While this convergence opens new possibilities, it also exposes the environment to risks that traditional OT architectures were never designed to withstand.

The modernization gap and why visibility alone isn’t enough

The push toward modernization has introduced new technology into industrial environments, creating convergence between IT and OT environments, and resulting in a lack of visibility. However, regaining that visibility is just a starting point. Visibility only tells you what is connected, not how access should be governed. And this is where the divide between IT and OT becomes unavoidable.

Security strategies that work well in IT often fall short in OT, where even small missteps can lead to environmental risk, safety incidents, or costly disruptions. Add in mounting regulatory pressure to enforce secure access, enforce segmentation, and demonstrate accountability, and it becomes clear: visibility alone is no longer sufficient. What industrial environments need now is precision. They need control. And they need to implement both without interrupting operations. All this requires identity-based access controls, real-time session oversight, and continuous behavioral detection.

The risk of unmonitored remote access

This risk becomes most evident during critical moments, such as when an OEM needs urgent access to troubleshoot a malfunctioning asset.

Under that time pressure, access is often provisioned quickly with minimal verification, bypassing established processes. Once inside, there’s little to no real-time oversight of user actions whether they’re executing commands, changing configurations, or moving laterally across the network. These actions typically go unlogged or unnoticed until something breaks. At that point, teams are stuck piecing together fragmented logs or post-incident forensics, with no clear line of accountability.  

In environments where uptime is critical and safety is non-negotiable, this level of uncertainty simply isn’t sustainable.

The visibility gap: Who’s doing what, and when?

The fundamental issue we encounter is the disconnect between who has access and what they are doing with it.  

Traditional access management tools may validate credentials and restrict entry points, but they rarely provide real-time visibility into in-session activity. Even fewer can distinguish between expected vendor behavior and subtle signs of compromise, misuse or misconfiguration.  

As a result, OT and security teams are often left blind to the most critical part of the puzzle, intent and behavior.

Closing the gaps with zero trust controls and AI‑driven detection

Managing remote access in OT is no longer just about granting a connection, it’s about enforcing strict access parameters while continuously monitoring for abnormal behavior. This requires a two-pronged approach: precision access control, and intelligent, real-time detection.

Zero Trust access controls provide the foundation. By enforcing identity-based, just-in-time permissions, OT environments can ensure that vendors and remote users only access the systems they’re explicitly authorized to interact with, and only for the time they need. These controls should be granular enough to limit access down to specific devices, commands, or functions. By applying these principles consistently across the Purdue Model, organizations can eliminate reliance on catch-all VPN tunnels, jump servers, and brittle firewall exceptions that expose the environment to excess risk.

Access control is only one part of the equation

Darktrace / OT complements zero trust controls with continuous, AI-driven behavioral detection. Rather than relying on static rules or pre-defined signatures, Darktrace uses Self-Learning AI to build a live, evolving understanding of what’s “normal” in the environment, across every device, protocol, and user. This enables real-time detection of subtle misconfigurations, credential misuse, or lateral movement as they happen, not after the fact.

By correlating user identity and session activity with behavioral analytics, Darktrace gives organizations the full picture: who accessed which system, what actions they performed, how those actions compared to historical norms, and whether any deviations occurred. It eliminates guesswork around remote access sessions and replaces it with clear, contextual insight.

Importantly, Darktrace distinguishes between operational noise and true cyber-relevant anomalies. Unlike other tools that lump everything, from CVE alerts to routine activity, into a single stream, Darktrace separates legitimate remote access behavior from potential misuse or abuse. This means organizations can both audit access from a compliance standpoint and be confident that if a session is ever exploited, the misuse will be surfaced as a high-fidelity, cyber-relevant alert. This approach serves as a compensating control, ensuring that even if access is overextended or misused, the behavior is still visible and actionable.

If a session deviates from learned baselines, such as an unusual command sequence, new lateral movement path, or activity outside of scheduled hours, Darktrace can flag it immediately. These insights can be used to trigger manual investigation or automated enforcement actions, such as access revocation or session isolation, depending on policy.

This layered approach enables real-time decision-making, supports uninterrupted operations, and delivers complete accountability for all remote activity, without slowing down critical work or disrupting industrial workflows.

Where Zero Trust Access Meets AI‑Driven Oversight:

  • Granular Access Enforcement: Role-based, just-in-time access that aligns with Zero Trust principles and meets compliance expectations.
  • Context-Enriched Threat Detection: Self-Learning AI detects anomalous OT behavior in real time and ties threats to access events and user activity.
  • Automated Session Oversight: Behavioral anomalies can trigger alerting or automated controls, reducing time-to-contain while preserving uptime.
  • Full Visibility Across Purdue Layers: Correlated data connects remote access events with device-level behavior, spanning IT and OT layers.
  • Scalable, Passive Monitoring: Passive behavioral learning enables coverage across legacy systems and air-gapped environments, no signatures, agents, or intrusive scans required.

Complete security without compromise

We no longer have to choose between operational agility and security control, or between visibility and simplicity. A Zero Trust approach, reinforced by real-time AI detection, enables secure remote access that is both permission-aware and behavior-aware, tailored to the realities of industrial operations and scalable across diverse environments.

Because when it comes to protecting critical infrastructure, access without detection is a risk and detection without access control is incomplete.

Continue reading
About the author
Pallavi Singh
Product Marketing Manager, OT Security & Compliance
Your data. Our AI.
Elevate your network security with Darktrace AI