Blog
/

Inside the SOC

/
May 25, 2022

Uncovering the Sysrv-Hello Crypto-Jacking Bonet

Default blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog image
25
May 2022
Discover the cyber kill chain of a Sysrv-hello botnet infection in France and gain insights into the latest TTPs of the botnet in March and April 2022.

In recent years, the prevalence of crypto-jacking botnets has risen in tandem with the popularity and value of cryptocurrencies. Increasingly crypto-mining malware programs are distributed by botnets as they allow threat actors to harness the cumulative processing power of a large number of machines (discussed in our other Darktrace blogs.1 2 One of these botnets is Sysrv-hello, which in addition to crypto-mining, propagates aggressively across the Internet in a worm-like manner by trolling for Remote Code Execution (RCE) vulnerabilities and SSH worming from the compromised victim devices. This all has the purpose of expanding the botnet.

First identified in December 2020, Sysrv-hello’s operators constantly update and change the bots’ behavior to evolve and stay ahead of security researchers and law enforcement. As such, infected systems can easily go unnoticed by both users and organizations. This blog examines the cyber kill chain sequence of a Sysrv-hello botnet infection detected at the network level by Darktrace DETECT/Network, as well as the botnet’s tactics, techniques, and procedures (TTPs) in March and April 2022.

Figure 1: Timeline of the attack

Delivery and exploitation

The organization, which was trialing Darktrace, had deployed the technology on March 2, 2022. On the very same day, the initial host infection was seen through the download of a first-stage PowerShell loader script from a rare external endpoint by a device in the internal network. Although initial exploitation of the device happened prior to the installation and was not observed, this botnet is known to target RCE vulnerabilities in various applications such as MySQL, Tomcat, PHPUnit, Apache Solar, Confluence, Laravel, JBoss, Jira, Sonatype, Oracle WebLogic and Apache Struts to gain initial access to internal systems.3 Recent iterations have also been reported to have been deployed via drive-by-downloads from an empty HTML iframe pointing to a malicious executable that downloads to the device from a user visiting a compromised website.4

Initial intrusion

The Sysrv-hello botnet is distributed for both Linux and Windows environments, with the corresponding compatible script pulled based on the architecture of the system. In this incident, the Windows version was observed.

On March 2, 2022 at 15:15:28 UTC, the device made a successful HTTP GET request to a malicious IP address5 that had a rarity score of 100% in the network. It subsequently downloaded a malicious PowerShell script named ‘ldr.ps1'6 onto the system. The associated IP address ‘194.145.227[.]21’ belongs to ‘ASN AS48693 Rices Privately owned enterprise’ and had been identified as a Sysrv-hello botnet command and control (C2) server in April the previous year. 3

Looking at the URI ‘/ldr.ps1?b0f895_admin:admin_81.255.222.82:8443_https’, it appears some form of query was being executed onto the object. The question mark ‘?’ in this URI is used to delimit the boundary between the URI of the queryable object and the set of strings used to express a query onto that object. Conventionally, we see the set of strings contains a list of key/value pairs with equal signs ‘=’, which are separated by the ampersand symbol ‘&’ between each of those parameters (e.g. www.youtube[.]com/watch?v=RdcCjDS0s6s&ab_channel=SANSCyberDefense), though the exact structure of the query string is not standardized and different servers may parse it differently. Instead, this case saw a set of strings with the hexadecimal color code #b0f895 (a light shade of green), admin username and password login credentials, and the IP address ‘81.255.222[.]82’ being applied during the object query (via HTTPS protocol on port 8443). In recent months this French IP has also had reports of abuse from the OSINT community.7

On March 2, 2022 at 15:15:33 UTC, the PowerShell loader script further downloaded second-stage executables named ‘sys.exe’ and ‘xmrig.2 sver.8 9 These have been identified as the worm and cryptocurrency miner payloads respectively.

Establish foothold

On March 2, 2022 at 17:46:55 UTC, after the downloads of the worm and cryptocurrency miner payloads, the device initiated multiple SSL connections in a regular, automated manner to Pastebin – a text storage website. This technique was used as a vector to download/upload data and drop further malicious scripts onto the host. OSINT sources suggest the JA3 client SSL fingerprint (05af1f5ca1b87cc9cc9b25185115607d) is associated with PowerShell usage, corroborating with the observation that further tooling was initiated by the PowerShell script ‘ldr.ps1’.

Continual Pastebin C2 connections were still being made by the device almost two months since the initiation of such connections. These Pastebin C2 connections point to new tactics and techniques employed by Sysrv-hello — reports earlier than May do not appear to mention any usage of the file storage site. These new TTPs serve two purposes: defense evasion using a web service/protocol and persistence. Persistence was likely achieved through scheduling daemons downloaded from this web service and shellcode executions at set intervals to kill off other malware processes, as similarly seen in other botnets.10 Recent reports have seen other malware programs also switch to Pastebin C2 tunnels to deliver subsequent payloads, scrapping the need for traditional C2 servers and evading detection.11

Figure 2: A section of the constant SSL connections that the device was still making to ‘pastebin[.]com’ even in the month of April, which resembles beaconing scheduled activity

Throughout the months of March and April, suspicious SSL connections were made from a second potentially compromised device in the internal network to the infected breach device. The suspicious French IP address ‘81.255.222[.]82’ previously seen in the URI object query was revealed as the value of the Server Name Indicator (SNI) in these SSL connections where, typically, a hostname or domain name is indicated.

After an initial compromise, attackers usually aim to gain long-term remote shell access to continue the attack. As the breach device does not have a public IP address and is most certainly behind a firewall, for it to be directly accessible from the Internet a reverse shell would need to be established. Outgoing connections often succeed because firewalls generally filter only incoming traffic. Darktrace observed the device making continuous outgoing connections to an external host listening on an unusual port, 8443, indicating the presence of a reverse shell for pivoting and remote administration.

Figure 3: SSL connections to server name ‘81.255.222[.]8’ at end of March and start of April

Accomplish mission

On March 4, 2022 at 15:07:04 UTC, the device made a total of 16,029 failed connections to a large volume of external endpoints on the same port (8080). This behavior is consistent with address scanning. From the country codes, it appears that public IP addresses for various countries around the world were contacted (at least 99 unique addresses), with the US being the most targeted.

From 19:44:36 UTC onwards, the device performed cryptocurrency mining using the Minergate mining pool protocol to generate profits for the attacker. A login credential called ‘x’ was observed in the Minergate connections to ‘194.145.227[.]21’ via port 5443. JSON-RPC methods of ‘login’ and ‘submit’ were seen from the connection originator (the infected breach device) and ‘job’ was seen from the connection responder (the C2 server). A high volume of connections using the JSON-RPC application protocol to ‘pool-fr.supportxmr[.]com’ were also made on port 80.

When the botnet was first discovered in December 2020, mining pools MineXMR and F2Pool were used. In February 2021, MineXMR was removed and in March 2021, Nanopool mining pool was added,12 before switching to the present SupportXMR and Minergate mining pools. Threat actors utilize such proxy pools to help hide the actual crypto wallet address where the contributions are made by the crypto-mining activity. From April onwards, the device appears to download the ‘xmrig.exe’ executable from a rare IP address ‘61.103.177[.]229’ in Korea every few days – likely in an attempt to establish persistency and ensure the cryptocurrency mining payload continues to exist on the compromised system for continued mining.

On March 9, 2022 from 18:16:20 UTC onwards, trolling for various RCE vulnerabilities (including but not limited to these four) was observed over HTTP connections to public IP addresses:

  1. Through March, the device made around 5,417 HTTP POSTs with the URI ‘/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php’ to at least 99 unique public IPs. This appears to be related to CVE-2017-9841, which in PHPUnit allows remote attackers to execute arbitrary PHP code via HTTP POST data beginning with a ‘13 PHPUnit is a common testing framework for PHP, used for performing unit tests during application development. It is used by a variety of popular Content Management Systems (CMS) such as WordPress, Drupal and Prestashop. This CVE has been called “one of the most exploitable CVEs of 2019,” with around seven million attack attempts being observed that year.14 This framework is not designed to be exposed on the critical paths serving web pages and should not be reachable by external HTTP requests. Looking at the status messages of the HTTP POSTs in this incident, some ‘Found’ and ‘OK’ messages were seen, suggesting the vulnerable path could be accessible on some of those endpoints.

Figure 4: PCAP of CVE-2017-9841 vulnerability trolling

Figure 5: The CVE-2017-9841 vulnerable path appears to be reachable on some endpoints

  1. Through March, the device also made around 5,500 HTTP POSTs with the URI ‘/_ignition/execute-solution’ to at least 99 unique public IPs. This appears related to CVE-2021-3129, which allows unauthenticated remote attackers to execute arbitrary code using debug mode with Laravel, a PHP web application framework in versions prior to 8.4.2.15 The POST request below makes the variable ‘username’ optional, and the ‘viewFile’ parameter is empty, as a test to see if the endpoint is vulnerable.16

Figure 6: PCAP of CVE-2021-3129 vulnerability trolling

  1. The device made approximately a further 252 HTTP GETs with URIs containing ‘invokefunction&function’ to another minimum of 99 unique public IPs. This appears related to a RCE vulnerability in ThinkPHP, an open-source web framework.17

Figure 7: Some of the URIs associated with ThinkPHP RCE vulnerability

  1. A HTTP header related to a RCE vulnerability for the Jakarta Multipart parser used by Apache struts2 in CVE-2017-563818 was also seen during the connection attempts. In this case the payload used a custom Content-Type header.

Figure 8: PCAP of CVE-2017-5638 vulnerability trolling

Two widely used methods of SSH authentication are public key authentication and password authentication. After gaining a foothold in the network, previous reports3 19 have mentioned that Sysrv-hello harvests private SSH keys from the compromised device, along with identifying known devices. Being a known device means the system can communicate with the other system without any further authentication checks after the initial key exchange. This technique was likely performed in conjunction with password brute-force attacks against the known devices. Starting from March 9, 2022 at 20:31:25 UTC, Darktrace observed the device making a large number of SSH connections and login failures to public IP ranges. For example, between 00:05:41 UTC on March 26 and 05:00:02 UTC on April 14, around 83,389 SSH connection attempts were made to 31 unique public IPs.

Figure 9: Darktrace’s Threat Visualizer shows large spikes in SSH connections by the breach device

Figure 10: Beaconing SSH connections to a single external endpoint, indicating a potential brute-force attack

Darktrace coverage

Cyber AI Analyst was able to connect the events and present them in a digestible, chronological order for the organization. In the aftermath of any security incidents, this is a convenient way for security users to conduct assisted investigations and reduce the workload on human analysts. However, it is good to note that this activity was also easily observed in real time from the model section on the Threat Visualizer due to the large number of escalating model breaches.

Figure 11: Cyber AI Analyst consolidating the events in the month of March into a summary

Figure 12: Cyber AI Analyst shows the progression of the attack through the month of March

As this incident occurred during a trial, Darktrace RESPOND was enabled in passive mode – with a valid license to display the actions that it would have taken, but with no active control performed. In this instance, no Antigena models breached for the initial compromised device as it was not tagged to be eligible for Antigena actions. Nonetheless, Darktrace was able to provide visibility into these anomalous connections.

Had Antigena been deployed in active mode, and the breach device appropriately tagged with Antigena All or Antigena External Threat, Darktrace would have been able to respond and neutralize different stages of the attack through network inhibitors Block Matching Connections and Enforce Group Pattern of Life, and relevant Antigena models such as Antigena Suspicious File Block, Antigena Suspicious File Pattern of Life Block, Antigena Pastebin Block and Antigena Crypto Currency Mining Block. The first of these inhibitors, Block Matching Connections, will block the specific connection and all future connections that matches the same criteria (e.g. all future outbound HTTP connections from the breach device to destination port 80) for a set period of time. Enforce Group Pattern of Life allows a device to only make connections and data transfers that it or any of its peer group typically make.

Conclusion

Resource hijacking results in unauthorized consumption of system resources and monetary loss for affected organizations. Compromised devices can potentially be rented out to other threat actors and botnet operators could switch from conducting crypto-mining to other more destructive illicit activities (e.g. DDoS or dropping of ransomware) whilst changing their TTPs in the future. Defenders are constantly playing catch-up to this continual evolution, and retrospective rules and signatures solutions or threat intelligence that relies on humans to spot future threats will not be able to keep up.

In this case, it appears the botnet operator has added an object query in the URL of the initial PowerShell loader script download, added Pastebin C2 for evasion and persistence, and utilized new cryptocurrency mining pools. Despite this, Darktrace’s Self-Learning AI was able to identify the threats the moment attackers changed their approach, detecting every step of the attack in the network without relying on known indicators of threat.

Appendix

Darktrace model detections

  • Anomalous File / Script from Rare Location
  • Anomalous File / EXE from Rare External Location
  • Compromise / Agent Beacon (Medium Period)
  • Compromise / Slow Beaconing Activity To External Rare
  • Compromise / Beaconing Activity To External Rare
  • Device / External Address Scan
  • Compromise / Crypto Currency Mining Activity
  • Compromise / High Priority Crypto Currency Mining
  • Compromise / High Volume of Connections with Beacon Score
  • Compromise / SSL Beaconing to Rare Destination
  • Anomalous Connection / Multiple HTTP POSTs to Rare Hostname
  • Device / Large Number of Model Breaches
  • Anomalous Connection / Multiple Failed Connections to Rare Endpoint
  • Anomalous Connection / SSH Brute Force
  • Compromise / SSH Beacon
  • Compliance / SSH to Rare External AWS
  • Compromise / High Frequency SSH Beacon
  • Compliance / SSH to Rare External Destination
  • Device / Multiple C2 Model Breaches
  • Anomalous Connection / POST to PHP on New External Host

MITRE ATT&CK techniques observed:

IoCs

Thanks to Victoria Baldie and Yung Ju Chua for their contributions.

Footnotes

1. https://www.darktrace.com/en/blog/crypto-botnets-moving-laterally

2. https://www.darktrace.com/en/blog/how-ai-uncovered-outlaws-secret-crypto-mining-operation

3. https://www.lacework.com/blog/sysrv-hello-expands-infrastructure

4. https://www.riskiq.com/blog/external-threat-management/sysrv-hello-cryptojacking-botnet

5. https://www.virustotal.com/gui/ip-address/194.145.227.21

6. https://www.virustotal.com/gui/url/c586845daa2aec275453659f287dcb302921321e04cb476b0d98d731d57c4e83?nocache=1

7. https://www.abuseipdb.com/check/81.255.222.82

8. https://www.virustotal.com/gui/file/586e271b5095068484446ee222a4bb0f885987a0b77e59eb24511f6d4a774c30

9. https://www.virustotal.com/gui/file/f5bef6ace91110289a2977cfc9f4dbec1e32fecdbe77326e8efe7b353c58e639

10. https://www.ironnet.com/blog/continued-exploitation-of-cve-2021-26084

11. https://www.zdnet.com/article/njrat-trojan-operators-are-now-using-pastebin-as-alternative-to-central-command-server

12. https://blogs.juniper.net/en-us/threat-research/sysrv-botnet-expands-and-gains-persistence

13. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9841

14. https://www.imperva.com/blog/the-resurrection-of-phpunit-rce-vulnerability

15. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3129

16. https://isc.sans.edu/forums/diary/Laravel+v842+exploit+attempts+for+CVE20213129+debug+mode+Remote+code+execution/27758

17. https://securitynews.sonicwall.com/xmlpost/thinkphp-remote-code-execution-rce-bug-is-actively-being-exploited

18. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5638

19. https://sysdig.com/blog/crypto-sysrv-hello-wordpress

‍

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.
Author
Shuh Chin Goh
Watch the NIS2 Webinar
Book a 1-1 meeting with one of our experts
Get in touch
Share this article
Trending blogs
1
Darktrace Releases 2024 Half-Year Threat Insights
Aug 6, 2024
2
Introducing ‘Defend Beyond’: Our promise to customers in the face of evolving threats
Aug 27, 2024
3
Darktrace: Microsoft UK Partner of the Year 2024
Jun 27, 2024
4
Navigating buying and adoption journeys for AI cybersecurity tools
Oct 15, 2024
5
How Darktrace won an email security trial by learning the business, not the breach
Oct 9, 2024

More in this series

No items found.

Blog

/

November 7, 2024

/

Inside the SOC

Onomastics Gymnastics: How Darktrace Detects Spoofing and Business Email Compromise in Multi-Name Users

Default blog imageDefault blog image

Note: For privacy reasons, actual surnames and email addresses observed in these incidents below have been replaced with fictitious placeholder names, using the common Spanish names “Fulano” and “Mengano”.

Naming conventions

Modeling names and their variants of members of an organization is a critical component to properly detect if those same names and variants are being spoofed by malicious actors. For many predominantly English-speaking organizations, these variants can largely be captured by variants of a person’s given name (e.g. James-Jimmy-Jim) and a consistent, singular surname or family name (e.g. Smith). Naming conventions, however, are far from universal. This piece will review how Darktrace / EMAIL manages the common naming conventions of much of the Spanish-speaking world, and can use its modeling to create high-fidelity detections of multiple types of spoofing attempts.

A brief summary of the common convention across Spain and much of Spanish-speaking America: most people are given one or two given names (e.g. Roberto, Juan, María, Natalia), and their surnames are the first surname of their father, followed by the first surname of their mother. While there are various exceptions to this norm, the below graphic Wikipedia [1][2] highlights the general rule.

Example Spanish naming convention for father “José García Torres” and mother “María Acosta Gómez” for child “Pablo García Acosta”. If shortened to one surname, the convention holds the child would be referred to as “Pablo García”
Figure 1: Example Spanish naming convention for father “José García Torres” and mother “María Acosta Gómez” for child “Pablo García Acosta”. If shortened to one surname, the convention holds the child would be referred to as “Pablo García” [1].

Detection of improper name usage

Implicit in the above comment that shortening to one surname follows the convention of using the first surname, shortening to the second surname is often a tell-tale sign of someone unfamiliar with the person or their broader culture. This can be a useful corroborating feature in detecting a spoof attempt – analogous to a spelling error.

In the case of a Spanish customer, this misuse of name shortening contributed to the detection of a spoof attempt trying to solicit a response by impersonating an internal user forwarding information about ‘Data Protection’.

Figure 2: The Cyber AI Analyst summary of the Darktrace / EMAIL detections shows the use of the Gmail sender impersonating Isabel Maria Fulano Mengano, but incorrectly uses the second surname Mengano.

While the limited communication history from the sender and the nature of the text content already marks the mail as suspicious, Darktrace / EMAIL notes the personal name used in the email is similar to a high-value user (‘whale’ to use the terminology of spearphishing). The additional context provided by the detection of the attempted spoof prompted more severe actioning of this email, leading to a ‘Hold’ action instead of a less-severe ‘Unspoof’ action via a banner on the email.

The content summary of the sender showing the ‘Personal’ field of the email being ‘Isabel Mengano’, breaking from the standard name-shortening convention. The additional metrics identify features that might be anomalous about the sender.
Figure 3: The content summary of the sender showing the ‘Personal’ field of the email being ‘Isabel Mengano’, breaking from the standard name-shortening convention. The additional metrics identify features that might be anomalous about the sender.

Malicious email properly using both surnames

Misusing the name-shortening convention is not the only way that Darktrace / EMAIL can detect spoofing attempts. In the case of another Spanish customer,  Darktrace observed a whale impersonation being sent to 230 users with solicitation content, but no links or attachments. Although the name was modeled internally in the “Surname, Given-name” format, Darktrace identified the spoofing attempt targeting a high-value user and took action, blocking the series of emails from reaching end-user inboxes to prevent unsuspecting users from responding.

Cyber AI Analyst summary of a suspicious email
Figure 4: Cyber AI Analyst summary of a suspicious email. The personal field is visible as ‘juan fulano mengano’, which is consistent with the reverse-order modelled user ‘fulano mengano, juan’. The subject line ‘Urgent Request’ sent to 230 users gives an intuitive indicator of the emails potentially being part of a malicious solicitation campaign.

In Summary: A case of onomastics gymnastics

The variety in valid usage of human language can be a barrier to evaluating when a given text is benign or malicious. Despite this, Darktrace / EMAIL is designed to manage this variety, as exemplified by the detections of two spoofing attempts seen against organizations using the distinct Spanish-speaking world’s common naming convention. The scope of this design as seen in this onomastic context, extends to a wide range of detections surrounding emails and their behavioral anomalies.

Credit to Roberto Romeu (Principal Cyber Analyst), Justin Torres (Senior Cyber Analyst) and Natalia Sánchez Rocafort (Senior Analyst Consultant).

Darktrace / Email solution brief screenshot

Secure Your Inbox with Cutting-Edge AI Email Protection

Discover the most advanced cloud-native AI email security solution to protect your domain and brand while preventing phishing, novel social engineering, business email compromise, account takeover, and data loss.

  • Gain up to 13 days of earlier threat detection and maximize ROI on your current email security
  • Experience 20-25% more threat blocking power with Darktrace / EMAIL
  • Stop the 58% of threats bypassing traditional email security

‍

References

[1] https://en.wikipedia.org/wiki/Naming_customs_of_Hispanic_America

[2] https://en.wikipedia.org/wiki/Spanish_naming_customs

Continue reading
About the author
Roberto Romeu
Senior SOC Analyst

Blog

/

October 31, 2024

/

OT

Understanding the NERC-CIP015 Internal Network Security Monitoring (INSM) Requirements

Default blog imageDefault blog image

Background: NERC CIP-015

In January of 2023 the Federal Energy Regulatory Commission (FERC) released FERC Order 887 which addresses a critical security gap in Critical Infrastructure Protection (CIP) standards, the lack of internal network security monitoring (INSM).

The current NERC CIP standards only require solutions that use traditional detection systems that identify malicious code based on known rules and signatures. The new legislation will now require electric cooperatives to implement INSMs to detect malicious activity in east-west network traffic. INSMs establish a baseline of network activity and detect anomalies that would bypass traditional detection systems, improving an organization’s ability to detect novel threats. Without INSM, organizations have limited visibility into malicious activities inside their networks, leaving them vulnerable if attackers breach initial defenses like firewalls and anti-virus software.

Implementation of NERC CIP-015

Once approved, Bulk Electronic Systems (BESs) will have 36 months to implement INSM, and medium-impact BESs with external routable connectivity (ERC) will have 60 months to do so.

While the approval of the NERC CIP-015 requirements have not been finalized, preparation on the part of electric cooperatives should start as soon as possible. Darktrace is committed to helping electric cooperatives meet the requirements for INSM and help reach compliance standards.

Why is internal network security monitoring important?

NERC CIP-015 aims to enhance the detection of anomalies or unauthorized network activity within CIP environments, underscoring the importance of monitoring East-West traffic within trust zones. This approach enables faster response and recovery times.

INSMs are essential to detecting threats that bypass traditional defenses. For example, insider threats, sophisticated new attack techniques, and threats that exploit compromised credentials—such as those obtained through phishing or other malicious activities—can easily bypass traditional firewalls and antivirus software. These threats either introduce novel methods or leverage legitimate access, making them difficult to detect.

INSMs don’t rely on rules and signatures to detect anomalous activity, they spot abnormalities in network traffic and create alerts based on this activity making them vital to detecting sophisticated threats. Additionally, INSM sits behind the firewall and provides detections utilizing the passive monitoring of east west and north south traffic within the enforcement boundary.

Buyers should be aware of the discrepancies between different INSMs. Some systems require constant tuning and updating, external connectivity forcing holes in segmentation or have intrusive deployments that put sensitive OT assets at risk.

What are the NERC CIP-015 requirements?

The goal of this directive is to ensure that cyber threats are identified early in the attack lifecycle by mandating implementation of security systems that detect and speed up mitigation of malicious activity.

The requirements are divided into three sections:

  • Network security monitoring
  • Data retention for anomalous activity
  • Data protection

NERC CIP-015 emphasizes the importance of having documented processes and evidence of implementation, with a focus on risk-based monitoring, anomaly detection, evaluation, retention of data, and protection against unauthorized access. Below is a breakdown of each requirement.

R1: Network Security Monitoring

The NERC CIP-015 requires the implementation of and a documented process for monitoring networks within Electronic Security Perimeters (ESPs) that contain high and medium impact BES Cyber Systems.

Key parts:

Part 1.1: Use a risk-based rationale to implement network data feeds that monitor connections, devices, and communications.

Part 1.2: Detect anomalous network activity using the data feeds.

Part 1.3: Evaluate the anomalous activity to determine necessary actions.

M1: Evidence for R1 Implementation: Documentation of processes, including risk-based rationale for data collection, detection events, configuration settings, and network baselines.

Incorporating automated solutions for network baselining is essential for effective internal monitoring, especially in diverse environments like substations and control centers. Each environment requires unique baselines—what’s typical for a substation may differ significantly from a control center, making manual monitoring impractical.

A continuous internal monitoring solution powered by artificial intelligence (AI) simplifies this challenge by instantly detecting all connected assets, dynamically learning the environment’s baseline behavior, and identifying anomalies in real-time. Unlike traditional methods, Darktrace’s AI-driven approach requires no external connectivity or repeated tuning, offering a seamless, adaptive solution for maintaining secure operations across all environments.

R2: Data Retention for Anomalous Activity

Documented processes must be in place to retain network security data related to detected anomalies until the required actions are completed.

Note: Data that does not relate to detected anomalies (Part 1.2) is not required to be retained.

M2: Evidence for Data Retention (R2): Documentation of data retention processes, system configurations, or reports showing compliance with R2.

R3: Data Protection: Implement documented processes to protect the collected security monitoring data from unauthorized deletion or modification.

M3: Evidence for Data Protection (R3): Documentation demonstrating how network security monitoring data is protected from unauthorized access or changes.

How to choose the right INSM for your organization?

Several vendors will offer INSM, but how do you choose the right solution for your organization?

Here are seven questions to help you get started evaluating potential INSM vendors:

  1. How does the solution help with ongoing compliance and reporting including CIP-015? Or any other regulations we comply with?
  2. Does the solution provide real-time monitoring of east-west traffic across critical systems? And what kind of threats has it proven capable of finding?
  3. How deep is the traffic visibility—does it offer Layer 7 (application) insights, or is it limited to Layers 3-4?
  4. Is the solution compatible with our existing infrastructure (firewalls, IDS/IPS, SIEM, OT networks)?
  5. Is this solution inline, passive, or hybrid? What impact will it have on network latency?
  6. Does the vendor have experience with electric utilities or critical infrastructure environments?
  7. Where and how are logs and monitoring data stored?

How Darktrace helps electric utilities with INSM requirements

Darktrace's ActiveAI Security Platform is uniquely designed to continuously monitor network activity and detect anomalous activity across both IT and OT environments successfully detecting insider threats and novel ransomware, while accelerating time to detection and incident reporting.

Most INSM solutions require repeated baselining, which creates more work and increases the likelihood of false positives, as even minor deviations trigger alerts. Since networks are constantly changing, baselines need to adjust in real time. Unlike these solutions, Darktrace does not depend on external connectivity or cloud access over the public internet. Our passive network analysis requires no agents or intrusive scanning, minimizing disruptions and reducing risks to OT systems.

Darktrace's AI-driven threat detection, asset management, and incident response capabilities can help organizations comply with the requirements of NERC CIP-015 for internal network security monitoring and data protection. Built specifically to deploy in OT environments, Darktrace / OT comprehensively manages, detects, evaluates, and protects network activity and anomalous events across IT and OT environments, facilitating adherence to regulatory requirements like data retention and anomaly management.

See how INSM with Darktrace can enhance your security operations, schedule a personalized demo today.

‍

Disclaimer

The information provided in this blog is intended for informational purposes only and reflects Darktrace’s understanding of the NERC CIP-015 INSM requirements as of the publication date. While every effort has been made to ensure the accuracy and reliability of the content, Darktrace makes no warranties or representations regarding its accuracy, completeness, or applicability to specific situations. This blog does not constitute legal or compliance advice and readers are encouraged to consult with qualified professionals for guidance specific to their circumstances. Darktrace disclaims any liability for actions taken or not taken based on the information contained herein.

References

1.     https://www.nerc.com/pa/Stand/Reliability%20Standards/CIP-015-1.pdf

Continue reading
About the author
Daniel Simonds
Director of Operational Technology
Your data. Our AI.
Elevate your network security with Darktrace AI