Blog
/

Threat Finds

RESPOND

/
September 19, 2021

Defending Tokyo Olympics: AI Neutralizes IoT Attack

Default blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog imageDefault blog image
19
Sep 2021
Learn how Darktrace autonomously thwarted a cyber-attack on a national sporting body before the Tokyo Olympics in this detailed breakdown.

One of the greatest issues in security is how to deal with high-stress scenarios when there is a significant breach, and there is too much to do in too little time. The nightmare scenario for any CISO is when this happens during a critical moment for the organization: an important acquisition, a crucial news announcement, or in this case, a global sporting event attracting an audience of millions.

Threat actors often exploit the pressure of these events to cause disruption or extract hefty sums. Sporting occasions, especially Formula 1 races, the Super Bowl, and the Olympics, attract a great deal of criminal interest.

The games begin

There have been several recorded attacks and data breaches at the Olympics this year, including an incident when a volleyball commentator asked his colleague for his computer password – not realizing he was still on air.

In a more nefarious case discovered by Darktrace, a Raspberry Pi device was covertly implanted into a national sporting body directly involved in the Olympics, in an attempt to exfiltrate sensitive data. The events took place one week before the start of the Games, and a data breach at this time would have had significant ramifications for the reputation of the organization, the confidentiality of their plans, and potentially the safety of their athletes.

Darktrace AI recognized this activity as malicious given its evolving understanding of ‘self’ for the organization, and Antigena – Darktrace’s autonomous response capability – took action at machine speed to interrupt the threat, affording the human security team the critical time they needed to catch up and neutralize the attack.

In what follows, we break down the attack.

Figure 1: The overall dwell time was three days.

Breaking down the attack

July 15, 14:09 — Initial intrusion

An unauthorized Raspberry Pi device connected to the organization’s digital environment – disguised and named in a way which mimicked the corporate naming convention. As a small IoT device, Raspberry Pis can be easily hidden and are difficult to locate physically in large environments. They have been used in various high-profile hacks in the past including the 2018 NASA breach.

IoT devices – from printers to fish tanks – pose a serious risk to security, as they can be exploited to gather information, move laterally, and escalate privileges.

July 15, 15:25 — External VPN activity

Anomalous UDP connections were made to an external endpoint over port 1194 (Open VPN activity). URIs showed that the device downloaded data potentially associated with Open VPN configuration files. This could represent an attempt to establish a secure channel for malicious activity such as data exfiltration.

By establishing an outgoing VPN, the attacker obfuscated their activity and bypassed the organization’s signature-based security, which could not detect the encrypted traffic. Antigena immediately blocked the suspicious connectivity, regardless of the encryption, identifying that the activity was a deviation from the ‘pattern of life’ for new devices.

July 15, 16:04 — Possible C2 activity

The Raspberry Pi soon began making repeated HTTP connections to a new external endpoint and downloaded octet streams — arbitrary binary data. It seems the activity was initiated by a standalone software process as opposed to a web browser.

Darktrace revealed that the device was performing an unusual external data transfer to the same endpoint, uploading 7.5 MB which likely contained call home data about the new location and name of the device.

July 15, 16:41 — Internal reconnaissance

The device engaged in TCP scanning across three unique internal IP addresses over a wide range of ports. Although the network scan only targeted three internal servers, the activity was identified by Darktrace as a suspicious increase in internal connections and failed internal connections.

Antigena instantly stopped the Raspberry Pi from making internal connections over the ports involved in the scanning activity, as well as enforcing the device’s ‘pattern of life’.

Figure 2: Device event log showing the components which enable Darktrace to detect network scanning.

July 15, 18:14 — Multiple internal reconnaissance tactics

The Raspberry Pi then scanned a large number of devices on SMB port 445 and engaged in suspicious use of the outdated SMB version 1 protocol, suggesting more in-depth reconnaissance to find exploitable vulnerabilities.

Reacting to the scanning activity alongside the insecure protocol SMBv1, Antigena blocked connections from the source device to the destination IPs for one hour.

Four minutes later, the device engaged in connections to the open-source vulnerability scanner, Nmap. Nmap can be used legitimately for vulnerability scanning and so often is not alerted to by traditional security tools. However, Darktrace’s AI detected that the use of the tool was highly anomalous, and so blocked all outgoing traffic for ten minutes.

July 15, 22:03 — Final reconnaissance

Three hours later, the Raspberry Pi initiated another network scan across six unique external IPs – this was in preparation for the final data exfiltration. Antigena responded with instant, specific blocks to the external IPs which the device was attempting to connect to – before any data could be exfiltrated.

After 30 minutes, Darktrace detected bruteforcing activity from the Raspberry Pi using the SMB and NTLM authentication protocols. The device made a large number of failed login attempts to a single internal device using over 100 unique user accounts. Antigena blocked the activity, successfully stopping another wave of attempted SMB lateral movement.

By this stage, Antigena had bought the security team enough time to respond. The team applied an Antigena quarantine rule (the most severe action Antigena can take) to the Raspberry Pi, until they were able to find the physical location of the device and unplug it from the network.

How AI Analyst stitched together the incident

Cyber AI Analyst autonomously reported on three key moments of the attack:

  • Unusual External Data Transfer
  • Possible HTTP Command and Control
  • TCP Scanning of Multiple Devices (the attempted data exfiltration)

It tied together activities over the span of multiple days, which could have been easily missed by human analysis. The AI provided crucial pieces of information, including the extent of the scanning activity. Such insights are time-consuming to calculate manually.

Figure 3: A screenshot from Cyber AI Analyst summarizing potential C2 activity.

Autonomous Response

Antigena took targeted action throughout to neutralize the suspicious behavior, while allowing normal business operations to continue unhindered.

Rather than widespread blocking, Antigena implemented a range of nuanced responses depending on the situation, always taking the smallest action necessary to deal with the threat.

Figure 4: Darktrace’s UI reveals the attempted network reconnaissance, and Antigena actions a targeted response. All IP addresses have been randomized.

Raspberry Pi: IoT threats

In an event involving 206 countries and 11,000 athletes, facing attacks from hacktivists, criminal groups, and nation states, with many broadcasters working remotely and millions watching from home, organizations involved in the Olympics needed a security solution which could rise to the occasion.

Even with the largest affairs, threats can come from the smallest places. The ability to detect unauthorized IoT devices and maintain visibility over all activity in your digital estate is essential.

Autonomous Response protects against the unexpected, stopping malicious activity at machine speed without any user input. This is necessary for rapid response and remediation, especially for resource-stretched internal security teams. When it comes to defending systems and outpacing attackers, AI always wins the race.

Thanks to Darktrace analysts Emma Foulger and Greg Chapman for their insights on the above threat find.

Learn how two rogue Raspberry Pi devices infected a healthcare provider

Darktrace model detections:

  • Compromise / Ransomware / Suspicious SMB Activity
  • Tags / New Raspberry Pi Device
  • Device / Network Scan
  • Unusual Activity / Unusual Raspberry Pi Activity
  • Antigena / Network / Insider Threat / Antigena Network Scan Block
  • Device / Suspicious Network Scan Activity
  • Antigena / Network / Significant Anomaly / Antigena Significant Anomaly from Client Block
  • Antigena / Network / Significant Anomaly / Antigena Controlled and Model Breach
  • Device / Suspicious SMB Scanning Activity
  • Antigena / Network / Significant Anomaly / Antigena Breaches Over Time Block
  • Device / Attack and Recon Tools
  • Device / New Device with Attack Tools
  • Device / Anomalous Nmap Activity
  • Device / External Network Scan
  • Device / SMB Session Bruteforce
  • Antigena / Network / Manual / Block All Outgoing Connections
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
Oakley Cox
Director of Product

Oakley is a Product Manager within the Darktrace R&D team. He collaborates with global customers, including all critical infrastructure sectors and Government agencies, to ensure Darktrace/OT remains the first in class solution for OT Cyber Security. He draws on 7 years’ experience as a Cyber Security Consultant to organizations across EMEA, APAC and ANZ. His research into cyber-physical security has been published by Cyber Security journals and by CISA. Oakley has a Doctorate (PhD) from the University of Oxford.

Book a 1-1 meeting with one of our experts
Share this article

More in this series

No items found.

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

Blog

/

November 1, 2024

/

Inside the SOC

Post Exploitation Activities on Fortinet Devices: A Network-Based Analysis

Default blog imageDefault blog image

Introduction: Uncovering active exploitation of Fortinet vulnerabilities

As part of the Darktrace Threat Research team's routine analysis of October's Patch Tuesday vulnerabilities, the team began searching for signs of active exploitation of a critical vulnerability (CVE-2024-23113) affecting the FortiGate to FortiManager (FGFM) protocol.[1]

Although the investigation was prompted by an update regarding CVE 2024-23113, results of the inquiry yielded evidence of widespread exploitation of Fortinet devices in both June and September 2024 potentially via multiple vulnerabilities including CVE 2024-47575. Analysts identified two clusters of activity involving overlapping indicators of compromise (IoCs), likely constituting unique campaigns targeting Fortinet appliances.

This blog will first highlight the finding and analysis of the network-based indicators of FortiManager post-exploitation activity in September, likely involving CVE 2024-47575. The article will then briefly detail a similar pattern of malicious activity observed in June 2024 that involved similar IoCs that potentially comprises a distinct campaign targeting Fortinet perimeter devices.

Fortinet CVE Disclosures

FortiManager devices allow network administrators to manage Fortinet devices on organizations’ networks.[2] One such subset of devices managed through this method are Fortinet firewalls known as FortiGate. These manager and firewall devices communicate with each other via a custom protocol known as FortiGate to FortiManager (FGFM), whereby devices can perform reachability tests and configuration-related actions and reporting.[3] By default, FortiManager devices operate this protocol via port 541.[4]

Fortinet Product Security Incident Response Team released multiple announcements revealing vulnerabilities within the daemon responsible for implementing operability of the FGFM service. Specifically, CVE 2024-23113 enables attackers to potentially perform arbitrary remote command execution through the use of a specially crafted format string to a FortiGate device running the “fgfm daemon”.[5][6]  Similarly, the exploitation of CVE 2024-47575  could also allow remote command execution due to a missing authentication mechanism when targeting specifically FortiManager devices.[7][8]  Given how prolific both FortiGate and FortiManager devices are within the global IT security ecosystem, Darktrace analysts hypothesized that there may have been specific targeting of such devices within the customer base using these vulnerabilities throughout mid to late 2024.

Campaign Analysis

In light of these vulnerability disclosures, Darktrace’s Threat Research team began searching for signs of active exploitation by investigating file download, lateral movement or tooling activity from devices that had previously received suspicious connections on port 541. The team first noticed increases in suspicious activity involving Fortinet devices particularly in mid-September 2024. Further analysis revealed a similar series of activities involving some overlapping devices identified in June 2024. Analysis of these activity clusters revealed a pattern of malicious activity against likely FortiManager devices, including initial exploitation, payload retrieval, and exfiltration of probable configuration data.

Below is an overview of malicious activity we have observed by sector and region:

Sector and region affected by malicious activity on fortigate devices
The sectors of affected customers listed above are categorized according to the United Kingdom’s Standard Industrial Classification (SIC).

Initial Exploitation of FortiManager Devices

Across many of the observed cases in September, activity began with the initial exploitation of FortiManager devices via incoming connectivity over TLS/SSL. Such activity was detected due to the rarity of the receiving devices accepting connections from external sources, particularly over destination port 541. Within nearly all investigated incidents, connectivity began with the source IP, 45.32.41[.]202, establishing an SSL session with likely FortiManager devices.  Device types were determined through a combination of the devices’ hostnames and the noted TLS certificate issuer for such encrypted connections.

Due to the encrypted nature of the connection, it was not possible to ascertain the exploit used in the analyzed cases. However, given the similarity of activities targeting FortiManager devices and research conducted by outside firms, attackers likely utilized CVE 2024-47575.[9] For example, the source IP initiating the SSL sessions also has been referenced by Mandiant as engaging in CVE 2024-47575 exploitation. In addition to a consistent source IP for the connections, a similar JA3 hash was noted across multiple examined accounts, suggesting a similarity in source process for the activity.

In most cases observed by Darktrace, the incoming connectivity was followed by an outgoing connection on port 443 to the IP 45.32.41[.]202. Uncommon reception of encrypted connections over port 541, followed by the initiation of outgoing SSL connections to the same endpoint would suggest probable successful exploitation of FortiManager CVEs during this time.

Model alert logs highlighting the incoming connectivity over port 541 to the FortiManager devices followed by outgoing connection to the external IP.
Figure 1: Model alert logs highlighting the incoming connectivity over port 541 to the FortiManager devices followed by outgoing connection to the external IP.

Payload Retrieval

Investigated devices commonly retrieved some form of additional content after incoming connectivity over port 541. Darktrace’s Threat Research team noted how affected devices would make HTTP GET requests to the initial exploitation IP for the URI: /dom.js. This URI, suggestive of JavaScript content retrieval, was then validated by the HTTP response content type. Although Darktrace could see the HTTP content of the connections, usage of destination port 443 featured prominently during these HTTP requests, suggesting an attempt at encryption of the session payload details.

Advanced search HTTP log to the exploitation IP noting the retrieval of JavaScript content using the curl user agent.
Figure 2: Advanced search HTTP log to the exploitation IP noting the retrieval of JavaScript content using the curl user agent.
Cyber AI Analyst investigation into the initial exploitation activity. This incident emphasizes the rare external connectivity over port 443 requesting JavaScript content following the incoming connections over port 541.
Figure 3: Cyber AI Analyst investigation into the initial exploitation activity. This incident emphasizes the rare external connectivity over port 443 requesting JavaScript content following the incoming connections over port 541.

The operators of the campaign also appear to have used a consistent user agent for payload retrieval: curl 8.4.0. Usage of an earlier version of the curl (version 7 .86.0) was only observed in one instance. The incorporation of curl utility to establish HTTP connections therefore suggests interaction with command-line utilities on the inspected Fortinet hosts. Command-line interaction also adds validity to the usage of exploits such as CVE 2024-47575 which enable unauthenticated remote command execution. Moreover, given the egress of data seen by the devices receiving this JavaScript content, Darktrace analysts concluded that this payload likely resulted in the configuration aggregation activity noted by external researchers.

Data Exfiltration

Nearly all devices investigated during the September time period performed some form of data exfiltration using the HTTP protocol. Most frequently, devices would initiate these HTTP requests using the same curl user agent already observed during web callback activity.  Again, usage of this tool heavily suggests interaction with the command-line interface and therefore command execution.

The affected device typically made an HTTP POST request to one or both of the following two rare external IPs: 104.238.141[.]143 and 158.247.199[.]37. One of the noted IPs, 104.238.141[.]143, features prominently within external research conducted by Mandiant during this time. These HTTP POST requests nearly always sent data to the /file endpoint on the destination IPs. Analyzed connections frequently noted an HTTP mime type suggestive of compressed archive content. Some investigations also revealed specific filenames for the data sent externally: “.tm”. HTTP POST requests occurred without a specified hostname. This would suggest the IP address may have already been cached locally on the device from a running process or the IP address was hardcoded into the details of unwarranted code running on the system. Moreover, many such POSTs occurred without a GET request, which can indicate exfiltration activity.

Model alert logs noting both the connection to the IP 158.247.199[.]37 over port 443 without a hostname, and the unusual activity metric describing how the request was made without a prior HTTP GET request. Such activity can indicate malicious data exfiltration.
Figure 4: Model alert logs noting both the connection to the IP 158.247.199[.]37 over port 443 without a hostname, and the unusual activity metric describing how the request was made without a prior HTTP GET request. Such activity can indicate malicious data exfiltration.

Interestingly, in many investigations, analysts noticed a lag period between the initial access and exploitation, and the exfiltration of data via HTTP. Such a pause, sometimes over several hours to over a day, could reflect the time needed to aggregate data locally on the host or as a strategic pause in activity to avoid detection. While not present within every compromise activity logs inspected, the delay could represent slight adjustments in behavior during the campaign by the threat actor.

Figure 5: Advanced search logs showing both the payload retrieval and exfiltration activity, emphasizing the gap in time between payload retrieval and exfiltration via HTTP POST request.

HTTP and file identification details identified during this time also directly correspond to research conducted by Mandiant. Not only do we see overlap in IPs identified as receiving the posted data (104.238.141[.]143) we also directly observed an overlap in filenames for the locally aggregated configuration data. Moreover, the gzip mime type identified in multiple customer investigations also corresponds directly to exfiltration activity noted by Mandiant researchers.

Advanced search logs noting the filename and URL of the posted data to one of the exfiltration IPs. The .tm filename corresponds to the locally stored file on affected FortiManager devices analyzed by external researchers.
Figure 6: Advanced search logs noting the filename and URL of the posted data to one of the exfiltration IPs. The .tm filename corresponds to the locally stored file on affected FortiManager devices analyzed by external researchers.

Activity detected in June 2024

Common indicators

Analysts identified a similar pattern of activity between June 23 and June 25. Activity in this period involved incoming connections from the aforementioned IP 45.32.41[.]202 on either port 541 or port 443 followed by an outgoing connection to the source. This behavior was then followed by HTTP POSTs to the previously mentioned IP address 158.247.199[.]37 in addition to the novel IP: 195.85.114[.]78  using same URI ‘/file’ noted above. Given the commonalties in indicators, time period, and observed behaviors, this grouping of exploitation attempts appears to align closely with the campaign described by Mandiant and may represent exploitation of CVE 2024-47575 in June 2024. The customers targeted in June fall into the same regions and sectors as seen those in the September campaign.

Deviations in behavior

Notably, Darktrace detected a different set of actions during the same June timeframe despite featuring the same infrastructure. This activity involved an initial incoming connection from 158.247.199[.]37 to an internal device on either port 541 or port 443. This was then followed by an outgoing HTTP connection to 158.247.199[.]37 on port 443 with a URI containing varying external IPs. Upon further review, analysts noticed the IPs listed may be the public IPs of the targeted victim, suggesting a potential form device registration by the threat actor or exploit validation. While the time period and infrastructure closely align with the previous campaign described, the difference in activity may suggest another threat actor sharing infrastructure or the same threat actor carrying out a different campaign at the same time. Although the IP 45.32.41[.]202 was contacted, paralleling activity seen in September, analysts did notice a different payload received from the external host, a shell script with the filename ver.sh.

AI Analyst timeline noting the suspicious HTTP behavior from a FortiManager device involving the IP: 158.247.199[.] 37.
Figure 7: AI Analyst timeline noting the suspicious HTTP behavior from a FortiManager device involving the IP: 158.247.199[.] 37.

Darktrace's depth of detection and investigation

Darktrace detected spikes in anomalous behavior from Fortinet devices within the customer base between September 22 and 23, 2024. Following an in-depth investigation into affected accounts and hosts, Darktrace identified a clear pattern where one, or multiple, threat actors leveraged CVEs affecting likely FortiManager devices to execute commands on the host, retrieve malicious content, and exfiltrate sensitive data. During this investigation, analysts then identified possibly related activity in June 2024 highlighted above.

The gathering and exfiltration of configuration data from network security management or other perimeter hosts is a technique that can enable future access by threat actors. This parallels activity previously discussed by Darktrace focused on externally facing devices, such as Palo Alto Networks firewall devices.  Malicious entities could utilize stolen configuration data and potentially stored passwords/hashes to gain initial access in the future, irrespective of the state of device patching. This data can also be potentially sold by initial access brokers on illicit sites. Moreover, groups can leverage this information to establish persistence mechanisms within devices and host networks to enable more impactful compromise activity.

Uncover threat pattens before they strike your network

Network and endpoint management services are essential tools for network administrators and will remain a critical part of IT infrastructure. However, these devices are often configured as internet-facing systems, which can unintentionally expose organizations networks' to attacks. Internet exposure provides malicious groups with novel entry routes into target environments. Although threat actors can swap vulnerabilities to access target networks, the exploitation process leaves behind unusual traffic patterns, making their presence detectable with the right network detection tools.

By detecting the unusual patterns of network traffic which inevitably ensue from exploitation of novel vulnerabilities, Darktrace’s anomaly-based detection and response approach can continue to identify and inhibit such intrusion activities irrespective of exploit used. Eulogizing the principle of least privilege, configuration and asset management, and maintaining the CIA Triad across security operations will continue to help security teams boost their defense posture.

See how anomaly-based detection can enhance your security operations—schedule a personalized demo today.

Get a demo button for Darktrace

Credit to Adam Potter (Senior Cyber Analyst), Emma Foulger (Principal Cyber Analyst), Nahisha Nobregas (Senior Cyber Analyst), Hyeongyung Yeom (Principal Cyber Analyst & Analyst Team Lead, East Asia), Sam Lister (Senior Cyber Analyst)

Appendix

Model Alerts

  • Anomalous Connection / Posting HTTP to IP without Hostname
  • Anomalous Connection / Callback on Web Facing Device
  • Anomalous Server Activity / New Internet Facing Server
  • Anomalous Server Activity / Outgoing from Server

Cyber AI Analyst Incidents

  • Possible HTTP Command and Control
  • Possible HTTP Command and Control to Multiple Endpoints

IoCs

Indicator – Type - Description

104.238.141[.]143 -  IP Address  - C2 infrastructure

158.247.199[.]37 - IP Address - C2 infrastructure

45.32.41[.]202 - IP Address - C2 infrastructure

104.238.141[.]143/file – URL - C2 infrastructure

158.247.199[.]37/file  - URL - C2 infrastructure

45.32.41[.]202/dom.js – URL - C2 infrastructure

.tm – Filename - Gzip file

MITRE Attack Framework

  • Initial Access
    T1190 Exploiting Public-Facing Application
  • Execution:
    T1059 Command and Scripting Interpreter  (Sub-Techniques: T1059.004 Unix Shell, T1059.008 Network Device CLI)
  • Discovery:
    T1083 File and System Discovery
    T1057 Process Discovery
  • Collection:
    T1005 Data From Local System
  • Command and Control:
    T1071 Application Layer Protocols (Sub-Technique:
    T1071.001 Web Protocols)
    T1573  Encrypted Channel
    T1573.001  Symmetric Cryptography
    T1571 Non-Standard Port
    T1105 Ingress Tool Transfer
    T1572 Protocol Tunnelling 
  • Exfiltration:
    T1048.003 Exfiltration Over Unencrypted Non-C2 Protocol

References

{1} https://cloud.google.com/blog/topics/threat-intelligence/fortimanager-zero-day-exploitation-cve-2024-47575/

{2} https://docs.fortinet.com/document/fortimanager/6.4.0/ports-and-protocols/606094/fortigate-fortimanager-protocol#:~:text=The%20FortiGate%2DFortiManager%20(FGFM),by%20using%20the%20FGFM%20protocol.

{3)https://docs.fortinet.com/document/fortigate/6.4.0/ports-and-protocols/373486/fgfm-fortigate-to-fortimanager-protocol
{4} https://www.fortiguard.com/psirt/FG-IR-24-029
{5} https://www.fortiguard.com/psirt/FG-IR-24-423
{6}https://www.fortinet.com/content/dam/fortinet/assets/data-sheets/fortimanager.pdf

{7} https://doublepulsar.com/burning-zero-days-fortijump-fortimanager-vulnerability-used-by-nation-state-in-espionage-via-msps-c79abec59773

{8} https://darktrace.com/blog/post-exploitation-activities-on-pan-os-devices-a-network-based-analysis

Continue reading
About the author
Adam Potter
Senior Cyber Analyst
Your data. Our AI.
Elevate your network security with Darktrace AI