October 14, 2024

How Triada Affects Banking and Communication Apps

Explore the intricacies of the Triada Trojan and its targeting of communication and banking apps. Learn how to safeguard against this threat.

Written by

Justin Torres

Cyber Analyst

Inside the SOC

Darktrace cyber analysts are world-class experts in threat intelligence, threat hunting and incident response, and provide 24/7 SOC support to thousands of Darktrace customers around the globe. Inside the SOC is exclusively authored by these experts, providing analysis of cyber incidents and threat trends, based on real-world experience in the field.

Written by

Justin Torres

Cyber Analyst

Oct 2024

The rise of android malware

Recently, there has been a significant increase in malware strains targeting mobile devices, with a growing number of Android-based malware families, such as banking trojans, which aim to steal sensitive banking information from organizations and individuals worldwide.

These malware families attempt to access users’ accounts to steal online banking credentials and cookies, bypass multi-factor authentication (MFA), and conduct automatic transactions to steal funds [1]. They often masquerade as legitimate software or communications from social media platforms to compromise devices. Once installed, they use tactics such as keylogging, dumping cached credentials, and searching the file system for stored passwords to steal credentials, take over accounts, and potentially perform identity theft [1].

One recent example is the Antidot Trojan, which infects devices by disguising itself as an update page for Google Play. It establishes a command-and-control (C2) channel with a server, allowing malicious actors to execute commands and collect sensitive data [2].

Despite these malware’s ability to evade detection by standard security software, for example, by changing their code [3], Darktrace recently detected another Android malware family, Triada, communicating with a C2 server and exfiltrating data.

Triada: Background and tactics

First surfacing in 2016, Triada is a modular mobile trojan known to target banking and financial applications, as well as popular communication applications like WhatsApp, Facebook, and Google Mail [4]. It has been deployed as a backdoor on devices such as CTV boxes, smartphones, and tablets during the supply chain process [5]. Triada can also be delivered via drive-by downloads, phishing campaigns, smaller trojans like Leech, Ztorg, and Gopro, or more recently, as a malicious module in applications such as unofficial versions of WhatsApp, YoWhatsApp, and FM WhatsApp [6] [7].

How does Triada work?

Once downloaded onto a user’s device, Triada collects information about the system, such as the device’s model, OS version, SD card space, and list of installed applications, and sends this information to a C2 server. The server then responds with a configuration file containing the device’s personal identification number and settings, including the list of modules to be installed.

After a device has been successfully infected by Triada, malicious actors can monitor and intercept incoming and outgoing texts (including two-factor authentication messages), steal login credentials and credit card information from financial applications, divert in-application purchases to themselves, create fake messaging and email accounts, install additional malicious applications, infect devices with ransomware, and take control of the camera and microphone [4] [7].

For devices infected by unofficial versions of WhatsApp, which are downloaded from third-party app stores [9] and from mobile applications such as Snaptube and Vidmate , Triada collects unique device identifiers, information, and keys required for legitimate WhatsApp to work and sends them to a remote server to register the device [7] [12]. The server then responds by sending a link to the Triada payload, which is downloaded and launched. This payload will also download additional malicious modules, sign into WhatsApp accounts on the target’s phone, and request the same permissions as the legitimate WhatsApp application, such as access to SMS messages. If granted, a malicious actor can sign the user up for paid subscriptions without their knowledge. Triada then collects information about the user’s device and mobile operator and sends it to the C2 server [9] [12].

How does Triada avoid detection?

Triada evades detection by modifying the Zygote process, which serves as a template for every application in the Android OS. This enables the malware to become part of every application launched on a device [3]. It also substitutes system functions and conceals modules from the list of running processes and installed apps, ensuring that the system does not raise the alarm [3]. Additionally, as Triada connects to a C2 server on the first boot, infected devices remain compromised even after a factory reset [4].

Triada attack overview

Across multiple customer deployments, devices were observed making a large number of connections to a range of hostnames, primarily over encrypted SSL and HTTPS protocols. These hostnames had never previously been observed on the customers’ networks and appear to be algorithmically generated. Examples include “68u91.66foh90o[.]com”, “92n7au[.]uhabq9[.]com”, “9yrh7.mea5ms[.]com”, and “is5jg.3zweuj[.]com”.

Figure 1: External Sites Summary Graph showing the rarity of the hostname “92n7au[.]uhabq9[.]com” on a customer network.

Most of the IP addresses associated with these hostnames belong to an ASN associated with the cloud provider Alibaba (i.e., AS45102 Alibaba US Technology Co., Ltd). These connections were made over a range of high number ports over 1000, most commonly over 30000 such as 32091, which Darktrace recognized as extremely unusual for the SSL and HTTPS protocols.

Figure 2: Screenshot of a Model Alert Event log showing a device connecting to the endpoint “is5jg[.]3zweuj[.]com” over port 32091.

On several customer deployments, devices were seen exfiltrating data to hostnames which also appeared to be algorithmically generated. This occurred via HTTP POST requests containing unusual URI strings that were made without a prior GET request, indicating that the infected device was using a hardcoded list of C2 servers.

Figure 3: Screenshot of a Model Alert Event Log showing the device posting the string “i8xps1” to the hostname “72zf6.rxqfd[.]com.

Figure 4: Screenshot of a Model Alert Event Log showing the device posting the string “sqyjyadwwq” to the hostname “9yrh7.mea5ms[.]com”.

These connections correspond with reports that devices affected by Triada communicate with the C2 server to transmit their information and receive instructions for installing the payload.

A number of these endpoints have communicating files associated with the unofficial WhatsApp versions YoWhatsApp and FM WhatsApp [11] [12] [13] . This could indicate that the devices connecting to these endpoints were infected via malicious modules in the unofficial versions of WhatsApp, as reported by open-source intelligence (OSINT) [10] [12]. It could also mean that the infected devices are using these connections to download additional files from the C2 server, which could infect systems with additional malicious modules related to Triada.

Moreover, on certain customer deployments, shortly before or after connecting to algorithmically generated hostnames with communicating files linked to YoWhatsApp and FM WhatsApp, devices were also seen connecting to multiple endpoints associated with WhatsApp and Facebook.

Figure 5: Screenshot from a device’s event log showing connections to endpoints associated with WhatsApp shortly after it connected to “9yrh7.mea5ms[.]com”.

These surrounding connections indicate that Triada is attempting to sign in to the users’ WhatsApp accounts on their mobile devices to request permissions such as access to text messages. Additionally, Triada sends information about users’ devices and mobile operators to the C2 server.

The connections made to the algorithmically generated hostnames over SSL and HTTPS protocols, along with the HTTP POST requests, triggered multiple Darktrace models to alert. These models include those that detect connections to potentially algorithmically generated hostnames, connections over ports that are highly unusual for the protocol used, unusual connectivity over the SSL protocol, and HTTP POSTs to endpoints that Darktrace has determined to be rare for the network.

Conclusion

Recently, the use of Android-based malware families, aimed at stealing banking and login credentials, has become a popular trend among threat actors. They use this information to perform identity theft and steal funds from victims worldwide.

Across affected customers, multiple devices were observed connecting to a range of likely algorithmically generated hostnames over SSL and HTTPS protocols. These devices were also seen sending data out of the network to various hostnames via HTTP POST requests without first making a GET request. The URIs in these requests appeared to be algorithmically generated, suggesting the exfiltration of sensitive network data to multiple Triada C2 servers.

This activity highlights the sophisticated methods used by malware like Triada to evade detection and exfiltrate data. It underscores the importance of advanced security measures and anomaly-based detection systems to identify and mitigate such mobile threats, protecting sensitive information and maintaining network integrity.

Credit to: Justin Torres (Senior Cyber Security Analyst) and Charlotte Thompson (Cyber Security Analyst).

Appendices

Darktrace Model Detections

Model Alert Coverage

Anomalous Connection / Application Protocol on Uncommon Port

Anomalous Connection / Multiple Connections to New External TCP Port

Anomalous Connection / Multiple HTTP POSTS to Rare Hostname

Anomalous Connections / Multiple Failed Connections to Rare Endpoint

Anomalous Connection / Suspicious Expired SSL

Compromise / DGA Beacon

Compromise / Domain Fluxing

Compromise / Fast Beaconing to DGA

Compromise / Sustained SSL or HTTP Increase

Compromise / Unusual Connections to Rare Lets Encrypt

Unusual Activity / Unusual External Activity

‍

AI Analyst Incident Coverage

Unusual Repeated Connections to Multiple Endpoints

Possible SSL Command and Control

Unusual Repeated Connections

List of Indicators of Compromise (IoCs)

Ioc – Type - Description

is5jg[.]3zweuj[.]com - Hostname - Triada C2 Endpoint
68u91[.]66foh90o[.]com - Hostname - Triada C2 Endpoint
9yrh7[.]mea5ms[.]com - Hostname - Triada C2 Endpoint
92n7au[.]uhabq9[.]com - Hostname - Triada C2 Endpoint
4a5x2[.]fs4ah[.]com - Hostname - Triada C2 Endpoint
jmll4[.]66foh90o[.]com - Hostname - Triada C2 Endpoint
mrswd[.]wo87sf[.]com - Hostname - Triada C2 Endpoint
lptkw[.]s4xx6[.]com - Hostname - Triada C2 Endpoint
ya27fw[.]k6zix6[.]com - Hostname - Triada C2 Endpoint
w0g25[.]66foh90o[.]com - Hostname - Triada C2 Endpoint
kivr8[.]wd6vy[.]com - Hostname - Triada C2 Endpoint
iuwe64[.]ct8pc6[.]com - Hostname - Triada C2 Endpoint
qefgn[.]8z0le[.]com - Hostname - Triada C2 Endpoint
a6y0x[.]xu0h7[.]com - Hostname - Triada C2 Endpoint
wewjyw[.]qb6ges[.]com - Hostname - Triada C2 Endpoint
vx9dle[.]n0qq3z[.]com - Hostname - Triada C2 Endpoint
72zf6[.]rxqfd[.]com - Hostname - Triada C2 Endpoint
dwq[.]fsdw4f[.]com - Hostname - Triada C2 Endpoint
tqq6g[.]66foh90o[.]com - Hostname - Triada C2 Endpoint
1rma1[.]4f8uq[.]com - Hostname - Triada C2 Endpoint
0fdwa[.]7j3gj[.]com - Hostname - Triada C2 Endpoint
5a7en[.]1e42t[.]com - Hostname - Triada C2 Endpoint
gmcp4[.]1e42t[.]com - Hostname - Triada C2 Endpoint
g7190[.]rt14v[.]com - Hostname - Triada C2 Endpoint
goyvi[.]2l2wa[.]com - Hostname - Triada C2 Endpoint
zq6kk[.]ca0qf[.]com - Hostname - Triada C2 Endpoint
sv83k[.]bn3avv[.]com - Hostname - Triada C2 Endpoint
9sae7h[.]ct8pc6[.]com - Hostname - Triada C2 Endpoint
jpygmk[.]qt7tqr[.]com - Hostname - Triada C2 Endpoint
av2wg[.]rt14v[.]com - Hostname - Triada C2 Endpoint
ugbrg[.]osz1p[.]com - Hostname - Triada C2 Endpoint
hw2dm[.]wtws9k[.]com - Hostname - Triada C2 Endpoint
kj9atb[.]hai8j1[.]com - Hostname - Triada C2 Endpoint
pls9b[.]b0vb3[.]com - Hostname - Triada C2 Endpoint
8rweau[.]j7e7r[.]com - Hostname - Triada C2 Endpoint
wkc5kn[.]j7e7r[.]com - Hostname - Triada C2 Endpoint
v58pq[.]mpvflv[.]com - Hostname - Triada C2 Endpoint
zmai4k[.]huqp3e[.]com - Hostname - Triada C2 Endpoint
eajgum[.]huqp3e[.]com - Hostname - Triada C2 Endpoint
mxl9zg[.]kv0pzv[.]com - Hostname - Triada C2 Endpoint
ad1x7[.]mea5ms[.]com - Hostname - Triada C2 Endpoint
ixhtb[.]s9gxw8[.]com - Hostname - Triada C2 Endpoint
vg1ne[.]uhabq9[.]com - Hostname - Triada C2 Endpoint
q5gd0[.]birxpk[.]com - Hostname - Triada C2 Endpoint
dycsw[.]h99n6[.]com - Hostname - Triada C2 Endpoint
a3miu[.]h99n6[.]com - Hostname - Triada C2 Endpoint
qru62[.]5qwu8b5[.]com - Hostname - Triada C2 Endpoint
3eox8[.]abxkoop[.]com - Hostname - Triada C2 Endpoint
0kttj[.]bddld[.]com - Hostname - Triada C2 Endpoint
gjhdr[.]xikuj[.]com - Hostname - Triada C2 Endpoint
zq6kk[.]wm0hd[.]com - Hostname - Triada C2 Endpoint
8.222.219[.]234 - IP Address - Triada C2 Endpoint
8.222.244[.]205 - IP Address - Triada C2 Endpoint
8.222.243[.]182 - IP Address - Triada C2 Endpoint
8.222.240[.]127 - IP Address - Triada C2 Endpoint
8.219.123[.]139 - IP Address - Triada C2 Endpoint
8.219.196[.]124 - IP Address - Triada C2 Endpoint
8.222.217[.]73 - IP Address - Triada C2 Endpoint
8.222.251[.]253 - IP Address - Triada C2 Endpoint
8.222.194[.]254 - IP Address - Triada C2 Endpoint
8.222.251[.]34 - IP Address - Triada C2 Endpoint
8.222.216[.]105 - IP Address - Triada C2 Endpoint
47.245.83[.]167 - IP Address - Triada C2 Endpoint
198.200.54[.]56 - IP Address - Triada C2 Endpoint
47.236.113[.]126 - IP Address - Triada C2 Endpoint
47.241.47[.]128 - IP Address - Triada C2 Endpoint
/iyuljwdhxk - URI - Triada C2 URI
/gvuhlbzknh - URI - Triada C2 URI
/sqyjyadwwq - URI - Triada C2 URI
/cncyz3 - URI - Triada C2 URI
/42k0zk - URI - Triada C2 URI
/75kdl5 - URI - Triada C2 URI
/i8xps1 - URI - Triada C2 URI
/84gcjmo - URI - Triada C2 URI
/fkhiwf - URI - Triada C2 URI

MITRE ATT&CK Mapping

Technique Name - Tactic - ID - Sub-Technique of

Data Obfuscation - COMMAND AND CONTROL - T1001

Non-Standard Port - COMMAND AND CONTROL - T1571

Standard Application Layer Protocol - COMMAND AND CONTROL ICS - T0869

Non-Application Layer Protocol - COMMAND AND CONTROL - T1095

Masquerading - EVASION ICS - T0849

Man in the Browser - COLLECTION - T1185

Web Protocols - COMMAND AND CONTROL - T1071.001 -T1071

External Proxy - COMMAND AND CONTROL - T1090.002 - T1090

Domain Generation Algorithms - COMMAND AND CONTROL - T1568.002 - T1568

Web Services - RESOURCE DEVELOPMENT - T1583.006 - T1583

DNS - COMMAND AND CONTROL - T1071.004 - T1071

Fast Flux DNS - COMMAND AND CONTROL - T1568.001 - T1568

One-Way Communication - COMMAND AND CONTROL - T1102.003 - T1102

Digital Certificates - RESOURCE DEVELOPMENT - T1587.003 - T1587

References

[1] https://www.checkpoint.com/cyber-hub/cyber-security/what-is-trojan/what-is-a-banking-trojan/

[2] https://cyberfraudcentre.com/the-rise-of-the-antidot-android-banking-trojan-a-comprehensive-guide

[3] https://www.zimperium.com/glossary/banking-trojans/

[4] https://www.geeksforgeeks.org/what-is-triada-malware/

[5] https://www.infosecurity-magazine.com/news/malware-infected-devices-retailers/

[6] https://www.pcrisk.com/removal-guides/24926-triada-trojan-android

[7] https://securelist.com/malicious-whatsapp-mod-distributed-through-legitimate-apps/107690/

[8] https://securityboulevard.com/2024/02/impact-of-badbox-and-peachpit-malware-on-android-devices/

[9] https://threatpost.com/custom-whatsapp-build-malware/168892/

[10] https://securelist.com/triada-trojan-in-whatsapp-mod/103679/

[11] https://www.virustotal.com/gui/domain/is5jg.3zweuj.com/relations

[12] https://www.virustotal.com/gui/domain/92n7au.uhabq9.com/relations

[13] https://www.virustotal.com/gui/domain/68u91.66foh90o.com/relations

Written by

Justin Torres

Cyber Analyst

Inside the SOC

Written by

Justin Torres

Cyber Analyst

Senior Product Marketing Manager, Email

Watch the NIS2 Webinar

Blog

Email

December 18, 2025

Why organizations are moving to label-free, behavioral DLP for outbound email

Why outbound email DLP needs reinventing

In 2025, the global average cost of a data breach fell slightly — but remains substantial at USD 4.44 million (IBM Cost of a Data Breach Report 2025). The headline figure hides a painful reality: many of these breaches stem not from sophisticated hacks, but from simple human error: mis-sent emails, accidental forwarding, or replying with the wrong attachment. Because outbound email is a common channel for sensitive data leaving an organization, the risk posed by everyday mistakes is enormous.

In 2025, 53% of data breaches involved customer PII, making it the most commonly compromised asset (IBM Cost of a Data Breach Report 2025). This makes “protection at the moment of send” essential. A single unintended disclosure can trigger compliance violations, regulatory scrutiny, and erosion of customer trust –consequences that are disproportionate to the marginal human errors that cause them.

Traditional DLP has long attempted to mitigate these impacts, but it relies heavily on perfect labelling and rigid pattern-matching. In reality, data loss rarely presents itself as a neat, well-structured pattern waiting to be caught – it looks like everyday communication, just slightly out of context.

How data loss actually happens

Most data loss comes from frustratingly familiar scenarios. A mistyped name in auto-complete sends sensitive data to the wrong “Alex.” A user forwards a document to a personal Gmail account “just this once.” Someone shares an attachment with a new or unknown correspondent without realizing how sensitive it is.

Traditional, content-centric DLP rarely catches these moments. Labels are missing or wrong. Regexes break the moment the data shifts formats. And static rules can’t interpret the context that actually matters – the sender-recipient relationship, the communication history, or whether this behavior is typical for the user.

It’s the everyday mistakes that hurt the most. The classic example: the Friday 5:58 p.m. mis-send, when auto-complete selects Martin, a former contractor, instead of Marta in Finance.

What traditional DLP approaches offer (and where gaps remain)

Most email DLP today follows two patterns, each useful but incomplete.

Policy- and label-centric DLP works when labels are correct — but content is often unlabeled or mislabeled, and maintaining classification adds friction. Gaps appear exactly where users move fastest
Rule and signature-based approaches catch known patterns but miss nuance: human error, new workflows, and “unknown unknowns” that don’t match a rule

The takeaway: Protection must combine content + behavior + explainability at send time, without depending on perfect labels.

Your technology primer: The three pillars that make outbound DLP effective

1) Label-free (vs. data classification)

Protects all content, not just what’s labeled. Label-free analysis removes classification overhead and closes gaps from missing or incorrect tags. By evaluating content and context at send time, it also catches misdelivery and other payload-free errors.

No labeling burden; no regex/rule maintenance
Works when tags are missing, wrong, or stale
Detects misdirected sends even when labels look right

2) Behavioral (vs. rules, signatures, threat intelligence)

Understands user behavior, not just static patterns. Behavioral analysis learns what’s normal for each person, surfacing human error and subtle exfiltration that rules can’t. It also incorporates account signals and inbound intel, extending across email and Teams.

Flags risk without predefined rules or IOCs
Catches misdelivery, unusual contacts, personal forwards, odd timing/volume
Blends identity and inbound context across channels

3) Proprietary DSLM (vs. generic LLM)

Optimized for precise, fast, explainable on-send decisions. A DSLM understands email/DLP semantics, avoids generative risks, and stays auditable and privacy-controlled, delivering intelligence reliably without slowing mail flow.

Low-latency, on-send enforcement
Non-generative for predictable, explainable outcomes
Governed model with strong privacy and auditability

The Darktrace approach to DLP

Darktrace / EMAIL – DLP stops misdelivery and sensitive data loss at send time using hold/notify/justify/release actions. It blends behavioral insight with content understanding across 35+ PII categories, protecting both labeled and unlabeled data. Every action is paired with clear explainability: AI narratives show exactly why an email was flagged, supporting analysts and helping end-users learn. Deployment aligns cleanly with existing SOC workflows through mail-flow connectors and optional Microsoft Purview label ingestion, without forcing duplicate policy-building.

Deployment is simple: Microsoft 365 routes outbound mail to Darktrace for real-time, inline decisions without regex or rule-heavy setup.

A buyer’s checklist for DLP solutions

When choosing your DLP solution, you want to be sure that it can deliver precise, explainable protection at the moment it matters – on send – without operational drag.

To finish, we’ve compiled a handy list of questions you can ask before choosing an outbound DLP solution:

Can it operate label free when tags are missing or wrong? 
Does it truly learn per user behavior (no shortcuts)? 
Is there a domain specific model behind the content understanding (not a generic LLM)? 
Does it explain decisions to both analysts and end users? 
Will it integrate with your label program and SOC workflows rather than duplicate them?

For a deep dive into Darktrace’s DLP solution, check out the full solution brief.

[related-resource]

About the author

Carlos Gray

Senior Product Marketing Manager, Email

Blog

Email

December 17, 2025

Beyond MFA: Detecting Adversary-in-the-Middle Attacks and Phishing with Darktrace

What is an Adversary-in-the-middle (AiTM) attack?

Adversary-in-the-Middle (AiTM) attacks are a sophisticated technique often paired with phishing campaigns to steal user credentials. Unlike traditional phishing, which multi-factor authentication (MFA) increasingly mitigates, AiTM attacks leverage reverse proxy servers to intercept authentication tokens and session cookies. This allows attackers to bypass MFA entirely and hijack active sessions, stealthily maintaining access without repeated logins.

This blog examines a real-world incident detected during a Darktrace customer trial, highlighting how Darktrace / EMAIL^TM and Darktrace / IDENTITY^TM identified the emerging compromise in a customer’s email and software-as-a-service (SaaS) environment, tracked its progression, and could have intervened at critical moments to contain the threat had Darktrace’s Autonomous Response capability been enabled.

What does an AiTM attack look like?

Inbound phishing email

Attacks typically begin with a phishing email, often originating from the compromised account of a known contact like a vendor or business partner. These emails will often contain malicious links or attachments leading to fake login pages designed to spoof legitimate login platforms, like Microsoft 365, designed to harvest user credentials.

Proxy-based credential theft and session hijacking

When a user clicks on a malicious link, they are redirected through an attacker-controlled proxy that impersonates legitimate services. This proxy forwards login requests to Microsoft, making the login page appear legitimate. After the user successfully completes MFA, the attacker captures credentials and session tokens, enabling full account takeover without the need for reauthentication.

Follow-on attacks

Once inside, attackers will typically establish persistence through the creation of email rules or registering OAuth applications. From there, they often act on their objectives, exfiltrating sensitive data and launching additional business email compromise (BEC) campaigns. These campaigns can include fraudulent payment requests to external contacts or internal phishing designed to compromise more accounts and enable lateral movement across the organization.

Darktrace’s detection of an AiTM attack

At the end of September 2025, Darktrace detected one such example of an AiTM attack on the network of a customer trialling Darktrace / EMAIL and Darktrace / IDENTITY.

In this instance, the first indicator of compromise observed by Darktrace was the creation of a malicious email rule on one of the customer’s Office 365 accounts, suggesting the account had likely already been compromised before Darktrace was deployed for the trial.

Darktrace / IDENTITY observed the account creating a new email rule with a randomly generated name, likely to hide its presence from the legitimate account owner. The rule marked all inbound emails as read and deleted them, while ignoring any existing mail rules on the account. This rule was likely intended to conceal any replies to malicious emails the attacker had sent from the legitimate account owner and to facilitate further phishing attempts.

Figure 1: Darktrace’s detection of the anomalous email rule creation.

Internal and external phishing

Following the creation of the email rule, Darktrace / EMAIL observed a surge of suspicious activity on the user’s account. The account sent emails with subject lines referencing payment information to over 9,000 different external recipients within just one hour. Darktrace also identified that these emails contained a link to an unusual Google Drive endpoint, embedded in the text “download order and invoice”.

Figure 2: Darkrace’s detection of an unusual surge in outbound emails containing suspicious content, shortly following the creation of a new email rule.

Figure 3: Darktrace / EMAIL’s detection of the compromised account sending over 9,000 external phishing emails, containing an unusual Google Drive link.

As Darktrace / EMAIL flagged the message with the ‘Compromise Indicators’ tag (Figure 2), it would have been held automatically if the customer had enabled default Data Loss Prevention (DLP) Action Flows in their email environment, preventing any external phishing attempts.

Figure 4: Darktrace / EMAIL’s preview of the email sent by the offending account.

Darktrace analysis revealed that, after clicking the malicious link in the email, recipients would be redirected to a convincing landing page that closely mimicked the customer’s legitimate branding, including authentic imagery and logos, where prompted to download with a PDF named “invoice”.

Figure 5: Download and login prompts presented to recipients after following the malicious email link, shown here in safe view.

After clicking the “Download” button, users would be prompted to enter their company credentials on a page that was likely a credential-harvesting tool, designed to steal corporate login details and enable further compromise of SaaS and email accounts.

Darktrace’s Response

In this case, Darktrace’s Autonomous Response was not fully enabled across the customer’s email or SaaS environments, allowing the compromise to progress, as observed by Darktrace here.

Despite this, Darktrace / EMAIL’s successful detection of the malicious Google Drive link in the internal phishing emails prompted it to suggest ‘Lock Link’, as a recommended action for the customer’s security team to manually apply. This action would have automatically placed the malicious link behind a warning or screening page blocking users from visiting it.

Figure 6: Autonomous Response suggesting locking the malicious Google Drive link sent in internal phishing emails.

Furthermore, if active in the customer’s SaaS environment, Darktrace would likely have been able to mitigate the threat even earlier, at the point of the first unusual activity: the creation of a new email rule. Mitigative actions would have included forcing the user to log out, terminating any active sessions, and disabling the account.

Conclusion

AiTM attacks represent a significant evolution in credential theft techniques, enabling attackers to bypass MFA and hijack active sessions through reverse proxy infrastructure. In the real-world case we explored, Darktrace’s AI-driven detection identified multiple stages of the attack, from anomalous email rule creation to suspicious internal email activity, demonstrating how Autonomous Response could have contained the threat before escalation.

MFA is a critical security measure, but it is no longer a silver bullet. Attackers are increasingly targeting session tokens rather than passwords, exploiting trusted SaaS environments and internal communications to remain undetected. Behavioral AI provides a vital layer of defense by spotting subtle anomalies that traditional tools often miss

Security teams must move beyond static defenses and embrace adaptive, AI-driven solutions that can detect and respond in real time. Regularly review SaaS configurations, enforce conditional access policies, and deploy technologies that understand “normal” behavior to stop attackers before they succeed.

Credit to David Ison (Cyber Analyst), Bertille Pierron (Solutions Engineer), Ryan Traill (Analyst Content Lead)

Appendices

Models

SaaS / Anomalous New Email Rule

Tactic – Technique – Sub-Technique

Phishing - T1566

Adversary-in-the-Middle - T1557

About the author

Your data. Our AI.

Elevate your network security with Darktrace AI

Get a demo

Check out this article by Darktrace: How Triada Affects Banking and Communication Apps

How Triada Affects Banking and Communication Apps

The rise of android malware

Triada: Background and tactics

How does Triada work?

How does Triada avoid detection?

Triada attack overview

Conclusion

Appendices

Darktrace Model Detections

List of Indicators of Compromise (IoCs)

MITRE ATT&CK Mapping

References

Beyond MFA: Detecting Adversary-in-the-Middle Attacks and Phishing with Darktrace

Why organizations are moving to label-free, behavioral DLP for outbound email

Enjoying the blog?

More in this series

React2Shell: How Opportunist Attackers Exploited CVE-2025-55182 Within Hours

Atomic Stealer: Darktrace’s Investigation of a Growing macOS Threat

CastleLoader & CastleRAT: Behind TAG150’s Modular Malware Delivery System

Blog

Email

December 18, 2025

Why organizations are moving to label-free, behavioral DLP for outbound email

Why outbound email DLP needs reinventing

How data loss actually happens

What traditional DLP approaches offer (and where gaps remain)

Your technology primer: The three pillars that make outbound DLP effective

1) Label-free (vs. data classification)

2) Behavioral (vs. rules, signatures, threat intelligence)

3) Proprietary DSLM (vs. generic LLM)

The Darktrace approach to DLP

A buyer’s checklist for DLP solutions

Blog

Email

December 17, 2025

Beyond MFA: Detecting Adversary-in-the-Middle Attacks and Phishing with Darktrace

What is an Adversary-in-the-middle (AiTM) attack?

What does an AiTM attack look like?

Inbound phishing email

Proxy-based credential theft and session hijacking

Follow-on attacks

Darktrace’s detection of an AiTM attack

Internal and external phishing

Darktrace’s Response

Conclusion

Appendices

Models