Onomastics Gymnastics : How Darktrace Detects Spoofing and Business Email Compromise in Multi-Name Users
05
Nov 2024
Spanish-language naming conventions complicate identity mapping for spoofing & especially whale-spoofing detection. Darktrace / EMAIL incorporates parsing logic that allows for faithful spoofing detection in conjunction with anomaly detection.
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.
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.
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.
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).
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
Oops! Something went wrong while submitting the form.
Newsletter
Stay ahead of threats with the Darktrace blog newsletter
Get the latest insights from the cybersecurity landscape, including threat trends, incident analysis, and the latest Darktrace product developments – delivered directly to your inbox, monthly.
Thanks, your request has been received
A member of our team will be in touch with you shortly.
Oops! Something went wrong while submitting the form.
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.
Understanding the NERC-CIP015 Internal Network Security Monitoring (INSM) Requirements
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:
How does the solution help with ongoing compliance and reporting including CIP-015? Or any other regulations we comply with?
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?
How deep is the traffic visibility—does it offer Layer 7 (application) insights, or is it limited to Layers 3-4?
Is the solution compatible with our existing infrastructure (firewalls, IDS/IPS, SIEM, OT networks)?
Is this solution inline, passive, or hybrid? What impact will it have on network latency?
Does the vendor have experience with electric utilities or critical infrastructure environments?
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.
Post Exploitation Activities on Fortinet Devices: A Network-Based Analysis
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:
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.
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.
Figure 2: Advanced Search HTTP log to the exploitation IP noting the retrieval of JavaScript content using the curl user agent.
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.
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.
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.
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.
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
![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.](https://cdn.prod.website-files.com/626ff4d25aca2edf4325ff97/672278683c8a45583feb3e36_672277fb7340135883a97489_Screenshot%25202024-10-30%2520at%252011.16.20%25E2%2580%25AFAM.png)
