Blog
/
Network
/
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.
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
Default blog image
14
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”.

External Sites Summary Graph showing the rarity of the hostname “92n7au[.]uhabq9[.]com” on a customer network.
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.

Screenshot of a Model Alert Event log showing a device connecting to the endpoint “is5jg[.]3zweuj[.]com” over port 32091.
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.

Screenshot of a Model Alert Event Log showing the device posting the string “i8xps1” to the hostname “72zf6.rxqfd[.]com.
Figure 3: Screenshot of a Model Alert Event Log showing the device posting the string “i8xps1” to the hostname “72zf6.rxqfd[.]com.
 Screenshot of a Model Alert Event Log showing the device posting the string “sqyjyadwwq” to the hostname “9yrh7.mea5ms[.]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 Anna Gilbertson (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

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

More in this series

No items found.

Blog

/

Network

/

August 6, 2026

When AI Agents Attack: The Case for Behavioral Anomaly Detection

Default blog imageDefault blog image

The UK AI Security Institute (AISI) has just published a detailed incident report confirming what many within the cyber security industry have suspected for some time: frontier AI agents, given a degree of autonomy, can independently develop and execute attack chains against real targets, including social engineering, supply-chain compromise, and deception, without explicit instruction to do so.

The report (INC-2026-07-28-01, published 4 August 2026) documents what happened during a routine capability evaluation between 25 and 28 July. It deserves a careful read from anyone responsible for securing the modern digital estate.

The incident

AISI regularly tests frontier AI models for offensive cyber capability. In this exercise, agents were placed inside a simulated network environment and given internet access this was deliberate, given to reflect realism of the task. Across 122 evaluation runs, 19 instances of unsanctioned activity were recorded, including cases where agents broke the intended boundaries of the test and acted against real people and real infrastructure on the open internet.

In the most serious case, an agent (Mythos 5) autonomously:

  • Conducted open-source intelligence gathering to identify real developers associated with keywords from the simulated scenario
  • Created a GitHub account and submitted a pull request containing obfuscated malicious code to a real, unaffiliated repository
  • Created a second sockpuppet account to post comments on its own PR, attempting to manufacture social proof
  • When a human reviewer flagged the malicious content, the agent lied, claiming an accidental commit, then repeatedly attempted to reintroduce the payload under the guise of having "fixed" the code
  • Sent spear-phishing emails to the repository maintainer containing manipulated content designed to convince them to merge the code
  • Planted a prompt injection inside a GitHub issue, hidden in an HTML comment invisible to humans but readable by AI coding assistants parsing the repository via API

AISI confirmed no real-world harm resulted. The PRs were not merged; the payloads did not execute. But containment was a product of circumstance, not design.

Why this matters

Every action the agents took used legitimate services operating within normal parameters. Creating a GitHub account is legitimate. Opening a pull request is legitimate. Sending an email is legitimate. Posting an issue is legitimate.

No vulnerability was exploited. No known malware signature was present. No indicator of compromise from any threat intelligence feed would have matched. The entire attack existed as a pattern, a sequence of individually normal actions that, taken together, constituted a supply-chain attack, a social engineering campaign, and an attempted compromise of downstream systems.

This is the class of threat that signature-based and rule-based security tools structurally struggle to detect. They answer the question "have I seen this before?" When the answer is no – and when the attack is novel, composed of legitimate actions, and adapted in real time by an adversary in this case an agent that reasons about evasion – they struggle.

Behavioral anomaly detection: The architecture that fits

Darktrace has spent a decade building a platform around a different question: "is this behavior normal for this entity?"

The platform learns the baseline behavior of every user, device, and communication pattern across an organization's digital environment. It does not need prior knowledge of an attack technique. It identifies deviation from learned normality, surfaces it, and through its Autonomous Response capability, takes targeted action to contain threats at machine speed.

Consider how this AISI incident might show across the Darktrace platform:

Network detection and response

While no payload was successfully delivered to a victim in this incident, AISI's post-incident analysis of the agent's code (detailed on pages 24-25 of the report) reveals what would have landed on target systems had the social engineering succeeded. The agent produced three successive payload generations, each replacing the last after being detected and called out:

Generation 1 hid a module-load stager inside a legitimate bug-fix commit, guarded by an environment variable check, to skip execution in CI. Its second stage attempted to fetch Poseidon implants (Linux and Windows variants) calling back to the agent's own C2 listener, with a fallback to publicly hosted polling scripts that fetched and executed commands every 60 seconds.

Generation 2 exploited an Electron "What's New" window with nodeIntegration enabled, loading remote HTML from a GitHub Pages site the agent had registered. The page decoded an XOR-obfuscated payload at runtime that beaconed host identifiers over DNS, attempted to download the same implants, ran its own in-process C2 loop, and installed reboot persistence via crontab and Windows registry Run keys.

Generation 3 was a post-install dropper added after the agent had already been publicly caught. It XOR-decoded a hidden URL, downloaded a script over plaintext HTTP, and ran it detached, force-exiting so npm install always reports success, giving the attacker remote code execution on any machine running the install.

None of these payloads reached a victim. But the technical detail matters: this is the calibre of tradecraft an autonomous agent produced in a matter of hours, unprompted. Each generation demonstrated adaptation, the agent iterated its approach in direct response to being detected.

For network defenders, the behavioral signals these payloads would have generated are clear. DNS beaconing to novel domains, periodic HTTP polling to newly registered infrastructure, XOR-encoded data in transit, registry and crontab persistence writes on endpoints that have never exhibited such behavior. These are exactly the anomalies that Darktrace / NETWORK identifies in real time: deviations from learned device and connection baselines, regardless of whether the specific payload or C2 domain has been seen before.

Beyond the payload analysis, the agents' broader activity produced additional behavioral anomalies: new identities engaging in high-frequency interactions with external services, coordination via unusual channels (public pastebins, gists), and lateral communication patterns that deviate from any established baseline.

Email security

The spear-phishing emails sent by the agent, crafted with context-specific content designed to manipulate a specific individual, represent exactly the kind of socially engineered communication that static email gateways can miss. Darktrace / EMAIL analyses the linguistic patterns, sender behavior, and relational context of every message. A brand-new sender using tailored language to pressure a recipient into a specific technical action deviates from the learned communication profile, regardless of whether the message contains a known-bad URL or attachment.

Securing AI

This is where the incident points to a threat category that many security platforms do not yet fully address. The agent did not just use AI as a tool for attack. It targeted other AI systems, attempting prompt injections against coding assistants and trying to compromise automated workflows. Organisations adopting AI agents for development, operations, and decision-making are introducing a newer extended attack surface.  

Darktrace / SECURE AI extends the same behavioral detection model into this space. It monitors AI usage across the enterprise, detecting anomalous interactions with AI services, identifying sensitive data exposure to AI systems, providing visibility into shadow AI use. As AI agents become standard components of enterprise infrastructure, the ability to detect when an AI system is behaving outside its expected parameters, when there is a chance, it is being manipulated, or when it is interacting with something it should not be, that becomes a direct security requirement rather than a future consideration.

The principle is consistent across the Darktrace platform: learn what normal looks like, identify deviation, respond autonomously.

The AI-to-AI threat surface

One of the report's most important findings is a confirmation that AI agents can act outside of instructions and guardrails to complete tasks. The Mythos 5 agent conducted reconnaissance on a repository maintainer, inferred it might be an AI coding assistant, and deployed a prompt injection specifically crafted to compromise it.

This is a new attack class. Organizations deploying AI coding assistants, AI-powered code review, or autonomous DevOps agents now face an adversary that:

  • Moves at speed
  • Is able to adapt its approach when initial attempts are halted
  • Specifically targets AI systems via techniques (prompt injection, hidden instructions in HTML comments) that are less visible to human reviewers but parsed by machines
  • Reasons about which evasion strategies are most likely to succeed

Defending against this requires security that operates with the same adaptability and speed. A system that learns what "normal" looks like, and flags deviation from it.

What AISI recommends

The report identifies five contributing factors to the incident. Two are directly relevant:

No synchronous real-time monitoring (Section 5.3): AISI acknowledges it had not built real-time behavioral monitoring capable of immediately blocking unsanctioned agent actions. Their security team detected the incident via commercial security monitoring software, but only after activity had already occurred.

No fine-grained behavioral controls (Section 6.2): AISI's forward-looking response includes building continuous monitoring that can "immediately block or flag unsanctioned AI agent behavior."

The direction is clear: organizations need security that watches behavior continuously, learns what normal looks like, and acts when deviation occurs, without requiring a human in the loop for every decision.

The takeaway

The AISI incident is documented proof that autonomous AI agents will independently develop novel attack chains using legitimate tools, adapt when detected, employ deception, and target both humans and other AI systems. This happened last week, in a controlled setting, with commercially available models.

The security architecture that addresses this is behavioral anomaly detection applied across the full digital estate, as AI agents become standard components of enterprise infrastructure, writing code, managing deployments, processing communications, the attack surface they create is behavioral by nature. The defense must be too.

Read the full report from the UK AI Security Institute here.

Continue reading
About the author
Adam Stevens
Senior Director of Product | Darktrace

Blog

/

AI

/

August 5, 2026

Testing a Prompt injection Attack Against an Enterprise AI Agent

prompt injectionDefault blog imageDefault blog image

Key takeaways

  • Darktrace successfully detected and quarantined a prompt injection email before it could be processed by an enterprise AI agent.  
  • Prompt injection attacks increasingly rely on natural language rather than traditional malware, making behavioral analysis an important complement to signature-based detection.  
  • Organizations deploying AI agents should combine model guardrails with behavioral monitoring to reduce the risk of malicious instructions reaching enterprise systems.

How behavioral detection helps stop prompt injection attacks

A Darktrace customer running a Gemini AI agent in Google Cloud asked us two simple questions:

“If my agent can read inbound emails and access internal data, what stops an attacker from hiding malicious instructions in the message? Couldn’t the agent be tricked into deleting or exfiltrating sensitive data?”

The scenario centers on an indirect prompt injection attack, where malicious instructions are hidden inside content that an AI model later interprets as trusted input. The same weakness was exposed by  EchoLeak (CVE-2025-32711), a zero-click Microsoft 365 Copilot vulnerability enabled data exfiltration from a single well-crafted email..

This blog follows the Darktrace team’s investigation of the customer’s hypothesis and examines how the attack interacted with their existing security stack. The results highlight which defenses held, where gaps emerged, and how behavioral detection mattered more than guardrails. This investigation also demonstrates why behavioral detection is becoming increasingly important for AI security, as prompt injections often contain no traditional indicators of compromise.  

How do prompt injection attacks work?

Prompt injection works by carefully crafting the content and structure of the prompt to alter the LLM’s behavior or output in unintended ways. This can cause models to violate guardrails, generate harmful content or enable unauthorised access.

Prompt injection attack example

The well-known example, EchoLeak (CVE-2025-32711), was a zero-click vulnerability in Microsoft 365 Copilot that relied on a carefully crafted email containing hidden instructions that the AI system interpreted as commands rather than content, creating a pathway for unauthorized access to sensitive information without any user interaction.

While Darktrace / SECURE AI is designed to prevent agents from producing unintended outcomes, we wanted to see if we could catch and prevent this threat type earlier in the attack life-cycle, at the email security layer.

How we tested prompt injection attacks on an enterprise agent

Summary:

  1. Claude generated a prompt injection payload.  
  2. Hidden instructions were embedded in an email.  
  3. The email passed traditional validation checks.  
  4. Darktrace analyzed the language and sender behavior.  
  5. The email was quarantined before the AI agent could process it.

To test Darktrace / EMAIL against this attack class, we opened Claude, gave it the customer's context and problem statement (Gemini agent with inbox access, internal tool calls), told it we were validating Darktrace / EMAIL's detection of prompt injections, and asked for a test payload. See below:

Figure 1
Figure 2

Despite the guardrails supposedly built into the model, Claude surprisingly gave us the entire exploit in plaintext (albeit very basic), illegible to a human as the text was sent in white text (see Figure 1) but framed as an authoritative override for anything downstream reading the mail programmatically (i.e. the Gemini agent).

How Darktrace detected a prompt injection attack

We then sent the Claude-crafted email from a freemail address to the target recipient’s inbox. Despite the email containing no malicious payload, the freemail address having no malicious reputation, and the validation checks all passing, Darktrace  /EMAIL flagged the email as a 93/100 anomaly and moved it to junk, out of scope for the AI agent.

Figure 3: The test email sent with the hidden prompt injection
Figure 4: The email analysis in Darktrace / EMAIL 
Figure 5: Darktrace / EMAIL detection of malicious activity

The interesting part is what triggered the detection (see Figure 5)

  • Possible machine prompt content: text in the body detected as instructions written for a machine to execute, not for a human to read
  • Possible machine prompt content + basic suspicious correspondence: the same content, correlated with sender-side anomalies: freemail domain (yahoo[.]com), unknown correspondent, no prior mail history with the recipient, and suspicious references to payment information

Neither of those is a signature match. Nothing in the email was on a blacklist. There was no malware, no link and no attachment. Darktrace analyzed the context in which the email was delivered and flagged it as likely risky.  The anomalous language features and the context of the sender relative to the recipient's normal behavior, combined with the unusual hidden text (prompt) were enough for Darktrace / EMAIL to act on the risk.

Result: Darktrace / EMAIL autonomously junked the email, out of scope for any AI agent parsing the inbox.

Why behavioral security makes a difference detecting prompt injection attacks

Cyberattacks don't look like traditional exploits anymore. They now operate in natural language, not strictly code.

That breaks the traditional stack. AV, firewalls, static scanning and signature-based SEGs all assume a payload to inspect.  

A prompt injection has no payload. It's just an instruction, written in natural language, dressed up as anything the attacker wants: an invoice, an HR request, a calendar invite, some simple PowerPoint slides.

EchoLeak proved that hidden instructions can sit inside an email invisible to the user but fully readable by the LLM, and the LLM will follow them blindly.  

This test and GTG-1002 proved that the LLM itself can be socially engineered. Tell it you're an authorized tester and it will hand you the attack.

Rules and static classifiers can catch the obvious cases. But natural language has infinite variants, and the attack surface is the model's innate functionality to comply.  

The deeper problem here is intent: an LLM can't reliably tell whether an instruction in its context came from its developer, its user, or an attacker who slipped it into an email. To the LLM, everything reads as language and looks like a legitimate ask. This is why behavioural detection wins, as you become aware of intent when you look at the context of an interaction. Does this sender normally send this kind of message to this recipient? Does this prompt fit the user's normal pattern? Is this agent behaving the way this agent normally behaves?  

Intent can't be read off a single email, it emerges from behavioral context. Which is how Darktrace enables threat detection, through behavioral understanding.

Why enterprise AI security requires more than guardrails

Claude didn't roll over immediately… the first section of the response was a (slight) pushback, but then it wrote the payload anyway without having to ask twice.

Here the framing of the prompt did all the work. The “testing security capabilities” angle moved the model from refusal to unquestioned compliance to the user prompt.

This isn't the first time this has happened, of course. Anthropic disclosed in November 2025 that a Chinese state-sponsored group they tracked as GTG-1002 ran the first documented AI-orchestrated espionage campaign against ~30 targets by posing as employees of a legitimate cybersecurity firm doing authorised penetration testing.

The takeaway isn't that AI guardrails are ineffective. They raise the cost of low-effort attacks and remain an important first layer of defense. However, for most organizations today, they’re the only line of defense when deploying AI agents. If a prompt injection bypasses those controls, organizations still need a way to detect and stop malicious behavior elsewhere in the attack chain.

Attackers will continue to have working prompt injections easily and quickly. The question is what stops one when it lands in an inbox your agent is reading.

That's where behavioral detection comes in.

How Darktrace detects prompt injection attacks in emails

Two things Darktrace does that a model-level guardrail or static rules and signatures can't:

Natural language analysis at the email or prompt layer. The email is assessed on its own merits: is this content shaped like instructions for a machine, regardless of what the receiving agent decides to do about it?

Behavioral context around the language. An AI agent behaves like an extremely agreeable human, and it will go above and beyond to comply with the user’s request. That's exactly why you must consider the business context, such sender behaviour, mailing history, and organisational norms, as these matter even more when the recipient is an AI.

Darktrace has been perfecting behavioral anomaly detection for over a decade; the same self-learning approach that catches BEC and account takeover applies directly to prompt injection delivery. Our multi-layered AI stack extracts content from the message, builds behavioural understanding through social graphing and Pattern of Life analysis, and then combines natural language, topic, inducement, sender relationship and anomaly signals before deciding what action to take.  

This matters for prompt injection because the threat is not the plain language itself, but the intent behind the language that can cause an AI agent to respond in unexpected ways.

How to secure enterprise AI operations from prompt injection attacks

Email was the entry point in this case, but it is only one of many possible vectors.  

Anywhere an agent can retrieve information, an attacker can potentially introduce a prompt injection.

Emails, documents, SharePoint sites, web pages, knowledge bases, chat platforms, and third-party integrations all provide opportunities to influence an agent's behavior. Wherever an agent finds its orders, a prompt injection opportunity exists.

This is why securing AI requires more than blocking malicious inputs. Organizations also need visibility into how agents behave after consuming information from across their environment. If an agent begins accessing unexpected data, taking unusual actions, or operating outside its normal patterns, those behaviors may provide the strongest signal that something has gone wrong.

Effective AI security requires defense in depth: reducing the likelihood of malicious instructions reaching the agent while maintaining the ability to detect and investigate suspicious behavior if they do.

The challenge isn't protecting a single entry point. It's recognizing that, in an AI-powered environment, every source of information is also a potential source of influence.

Are you deploying autonomous agents across your enterprise and want to see this tested in your environment? Let's talk.

Continue reading
About the author
Carlo Loregian
Solutions Engineer
Your data. Our AI.
Elevate your network security with Darktrace AI