Lost in Translation: Darktrace Blocks Non-English Phishing Campaign Concealing Hidden Payloads
15
May 2024
This blog explores how Darktrace/Email was able to successfully identify a wave of phishing emails sent from addresses belonging to a major fast-food chain which were leveraged in a coordinated attack. Despite the use of non-English language emails and payloads hidden behind QR codes, Darktrace was able to detect the attack and block the phishing emails in the first instance.
Email – the vector of choice for threat actors
In times of unprecedented globalization and internationalization, the enormous number of emails sent and received by organizations every day has opened the door for threat actors looking to gain unauthorized access to target networks.
Now, increasingly global organizations not only need to safeguard their email environments against phishing campaigns targeting their employees in their own language, but they also need to be able to detect malicious emails sent in foreign languages too [1].
Why are non-English language phishing emails more popular?
Many traditional email security vendors rely on pre-trained English language models which, while function adequately against malicious emails composed in English, would struggle in the face of emails composed in other languages. It should, therefore, come as no surprise that this limitation is becoming increasingly taken advantage of by attackers.
Darktrace/Email™, on the other hand, focuses on behavioral analysis and its Self-Learning AI understands what is considered ‘normal’ for every user within an organization’s email environment, bypassing any limitations that would come from relying on language-trained models [1].
In March 2024, Darktrace observed anomalous emails on a customer’s network that were sent from email addresses belonging to an international fast-food chain. Despite this seeming legitimacy, Darktrace promptly identified them as phishing emails that contained malicious payloads, preventing a potentially disruptive network compromise.
Attack Overview and Darktrace Coverage
On March 3, 2024, Darktrace observed one of the customer’s employees receiving an email which would turn out to be the first of more than 50 malicious emails sent by attackers over the course of three days.
The Sender
Darktrace/Email immediately understood that the sender never had any previous correspondence with the organization or its employees, and therefore treated the emails with caution from the onset. Not only was Darktrace able to detect this new sender, but it also identified that the emails had been sent from a domain located in China and contained an attachment with a Chinese file name.
Darktrace further detected that the phishing emails had been sent in a synchronized fashion between March 3 and March 5. Eight unique senders were observed sending a total of 55 emails to 55 separate recipients within the customer’s email environment. The format of the addresses used to send these suspicious emails was “12345@fastflavor-shack[.]cn”*. The domain “fastflavor-shack[.]cn” is the legitimate domain of the Chinese division of an international fast-food company, and the numerical username contained five numbers, with the final three digits changing which likely represented different stores.
*(To maintain anonymity, the pseudonym “Fast Flavor Shack” and its fictitious domain, “fastflavor-shack[.]cn”, have been used in this blog to represent the actual fast-food company and the domains identified by Darktrace throughout this incident.)
As these emails were sent from a legitimate domain associated with a trusted organization and seemed to be coming from the correct connection source, they were verified by Sender Policy Framework (SPF) and were able to evade the customer’s native email security measures. Darktrace/Email; however, recognized that these emails were actually sent from a user located in Singapore, not China.
The Emails
Darktrace/Email autonomously analyzed the suspicious emails and identified that they were likely phishing emails containing a malicious multistage payload.
There has been a significant increase in multistage payload attacks in recent years, whereby a malicious email attempts to elicit recipients to follow a series of steps, such as clicking a link or scanning a QR code, before delivering a malicious payload or attempting to harvest credentials [2].
In this case, the malicious actor had embedded a suspicious link into a QR code inside a Microsoft Word document which was then attached to the email in order to direct targets to a malicious domain. While this attempt to utilize a malicious QR code may have bypassed traditional email security tools that do not scan for QR codes, Darktrace was able to identify the presence of the QR code and scan its destination, revealing it to be a suspicious domain that had never previously been seen on the network, “sssafjeuihiolsw[.]bond”.
At the time of the attack, there was no open-source intelligence (OSINT) on the domain in question as it had only been registered earlier the same day. This is significant as newly registered domains are typically much more likely to bypass gateways until traditional security tools have enough intelligence to determine that these domains are malicious, by which point a malicious actor may likely have already gained access to internal systems [4]. Despite this, Darktrace’s Self-Learning AI enabled it to recognize the activity surrounding these unusual emails as suspicious and indicative of a malicious phishing campaign, without needing to rely on existing threat intelligence.
The most commonly used sender name line for the observed phishing emails was “财务部”, meaning “finance department”, and Darktrace observed subject lines including “The document has been delivered”, “Income Tax Return Notice” and “The file has been released”, all written in Chinese. The emails also contained an attachment named “通知文件.docx” (“Notification document”), further indicating that they had been crafted to pass for emails related to financial transaction documents.
Conclusion
Although this phishing attack was ultimately thwarted by Darktrace/Email, it serves to demonstrate the potential risks of relying on solely language-trained models to detect suspicious email activity. Darktrace’s behavioral and contextual learning-based detection ensures that any deviations in expected email activity, be that a new sender, unusual locations or unexpected attachments or link, are promptly identified and actioned to disrupt the attacks at the earliest opportunity.
In this example, attackers attempted to use non-English language phishing emails containing a multistage payload hidden behind a QR code. As traditional email security measures typically rely on pre-trained language models or the signature-based detection of blacklisted senders or known malicious endpoints, this multistage approach would likely bypass native protection.
Darktrace/Email, meanwhile, is able to autonomously scan attachments and detect QR codes within them, whilst also identifying the embedded links. This ensured that the customer’s email environment was protected against this phishing threat, preventing potential financial and reputation damage.
Credit to: Rajendra Rushanth, Cyber Analyst, Steven Haworth, Head of Threat Modelling, Email
Appendices
List of Indicators of Compromise (IoCs)
IoC – Type – Description
sssafjeuihiolsw[.]bond – Domain Name – Suspicious Link Domain
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:
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.
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.
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.
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.
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.
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.
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
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
Tactic - Technique - Initial Access
T1190 – Exploiting Public-Facing Application
Execution T1059 – Command and Scripting Interpreter
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
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