Blog
/
Email
/
July 6, 2023

How Darktrace Foiled QR Code Phishing

Explore Darktrace's successful detection of QR code phishing. Understand the methods used to thwart these sophisticated cyber threats.
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
Alexandra Sentenac
Cyber Analyst
Default blog image
06
Jul 2023

What is a QR Code?

Invented by a Japanese company in 1994 to label automobile parts, Quick Response codes, best known as QR codes, are rapidly becoming ubiquitous everywhere in the world. Their design, inspired by the board and black and white pieces of the game of Go, permits the storage of more information than regular barcodes and to access that information more quickly. The COVID-19 pandemic contributed to their increased popularity as it conveniently replaced physical media of all types for the purpose of content sharing. It is now common to see them in restaurant menus, plane tickets, advertisements and even in stickers containing minimal to no text pasted on lamp posts and other surfaces, enticing passers-by to scan its content. 

QR Code Phishing Attacks (Quishing)

Recently, threat actors have been identified using QR codes too to embed malicious URLs leading the unsuspecting user to compromised websites containing malware or designed to harvest credentials. In the past month, Darktrace has observed an increase in the number of phishing emails leveraging malicious QR codes for malware distribution and/or credential harvesting, a new form of social engineering attack labelled “Quishing” (i.e., QR code phishing).

Between June 13 and June 22, 2023, Darktrace protected a tech company against one such Quishing attack when five of its senior employees were sent malicious emails impersonating the company’s IT department. The emails contained a QR code that led to a login page designed to harvest the credentials of these senior staff members. Fortunately for the customer, Darktrace / EMAIL thwarted this phishing campaign in the first instance and the emails never reached the employee inboxes. 

Trends in Quishing Attacks

The Darktrace/Email team have noticed a recent and rapid increase in QR code abuse, suggesting that it is a growing tactic used by threat actors to deliver malicious payload links. This trend has also been observed by other security solutions [1] [2] [3] [4]. The Darktrace/Email team has identified malicious emails abusing QR codes in multiple ways. Examples include embedded image links which load a QR code and QR code images being delivered as attachments, such as those explored in this case study. Darktrace/Email is continually refining its detection of malicious QR codes and QR code extraction capabilities so that it can detect and block them regardless of their size and location within the email.   

Quishing Attack Overview

The attack consisted of five emails, each sent from different sender and envelope addresses, displayed common points between them. The emails all conveyed a sense of urgency, either via the use of words such as “urgent”, “now”, “required” or “important” in the subject field or by marking the email as high priority, thus making the recipient believe the message is pressing and requires immediate attention. 

Additionally, the subject of three of the emails directly referred to two factor authentication (2FA) enabling or QR code activation. Another particularity of these emails was that three of them attempted to impersonate the internal IT team of the company by inserting the company domain alongside strings, such as “it-desk” and “IT”, into the personal field of the emails. Email header fields like this are often abused by attackers to trick users by pretending to be an internal department or senior employee, thus avoiding more thorough validation checks. Both instilling a sense of urgency and including a known domain or name in the personal field are techniques that help draw attention to the email and maximize the chances that it is opened and engaged by the recipient. 

However, threat actors also need to make sure that the emails actually reach the intended inboxes, and this can be done in several ways. In this case, several tactics were employed. Two of the five emails were sent from legitimate sender addresses that successfully passed SPF validation, suggesting they were sent from compromised accounts. SPF is a standard email authentication method that tells the receiving email servers whether emails have been sent from authorized servers for a given domain. Without SPF validation, emails are more likely to be categorized as spam and be sent to the junk folder as they do not come from authorized sources.

Another of the malicious emails, which also passed SPF checks, used a health care facility company domain in the header-from address field but was actually sent from a different domain (i.e., envelope domain), which lowers the value of the SPF authentication. However, the envelope domain observed in this instance belonged to a company recently acquired by the tech company targeted by the campaign.

This shows a high level of targeting from the attackers, who likely hoped that this detail would make the email more familiar and less suspicious. In another case, the sender domain (i.e., banes-gn[.]com) had been created just 6 days prior, thus lowering the chances of there being open-source intelligence (OSINT) available on the domain. This reduces the chances of the email being detected by traditional email security solutions relying on signatures and known-bad lists.

Darktrace Detects Quishing Attack

Despite its novelty, the domain was detected and assessed as highly suspicious by Darktrace. Darktrace/Email was able to recognize all of the emails as spoofing and impersonation attempts and applied the relevant tags to them, namely “IT Impersonation” and “Fake Account Alert”, depending on the choice of personal field and subject. The senders of the five emails had no prior history or association with the recipient nor the company as no previous correspondence had been observed between the sender and recipient. The tags applied informed on the likely intent and nature of the suspicious indicators present in the email, as shown in Figure 1. 

Darktrace/Email UI
Figure 1: Email log overview page, displaying important information clearly and concisely. 

Quishing Attack Tactics

Minimal Plain Text

Another characteristic shared by these emails was that they had little to no text included in the body of the email and they did not contain a plain text portion, as shown in Figure 2. For most normal emails sent by email clients and most automated programs, an email will contain an HTML component and a text component, in addition to any potential attachments present. All the emails had one image attachment, suggesting the bulk of the message was displayed in the image rather than the email body. This hinders textual analysis and filtering of the email for suspicious keywords and language that could reveal its phishing intent. Additionally, the emails were well-formatted and used the logo of the well-known corporation Microsoft, suggesting some level of technical ability on the part of the attackers. 

Figure 2: Email body properties giving additional insights into the content of the email. 

Attachment and link payloads

The threat actors employed some particularly innovative and novel techniques with regards to the attachments and link payloads within these emails. As previously stated, all emails contained an image attachment and one or two links. Figure 3 shows that Darktrace/Email detected that the malicious links present in these emails were located in the attachments, rather than the body of the email. This is a technique often employed by threat actors to bypass link analysis by security gateways. Darktrace/Email was also able to detect this link as a QR code link, as shown in Figure 4.

Figure 3: Further properties and metrics regarding the location of the link within the email. 
Figure 4: Darktrace / EMAIL analyzes multiple metrics and properties related to links, some of which are detailed here. 

The majority of the text, as well as the malicious payload, was contained within the image attachment, which for one of the emails looked like this: 

example of quishing email
Figure 5: Redacted screenshot of the image payload contained in one of the emails. 

Convincing Appearance

As shown, the recipient is asked to setup 2FA authentication for their account within two days if they don’t want to be locked out. The visual formatting of the image, which includes a corporate logo and Privacy Statement and Acceptable Use Policy notices, is well balanced and convincing. The payload, in this case the QR code containing a malicious link, is positioned in the centre so as to draw attention and encourage the user to scan and click. This is a type of email employees are increasingly accustomed to receiving in order to log into corporate networks and applications. Therefore, recipients of such malicious emails might assume represents expected business activity and thus engage with the QR code without questioning it, especially if the email is claiming to be from the IT department.  

Malicious Redirection

Two of the Quishing emails contained links to legitimate file storage and sharing solutions Amazon Web Services (AWS) and and InterPlanetary File System (IPFS), whose domains are less likely to be blocked by traditional security solutions. Additionally, the AWS domain link contained a redirect to a different domain that has been flagged as malicious by multiple security vendors [5]. Malicious redirection was observed in four of the five emails, initially from well-known and benign services’ domains such as bing[.]com and login[.]microsoftonline[.]com. This technique allows attackers to hide the real destination of the link from the user and increase the likelihood that the link is clicked. In two of the emails, the redirect domain had only recently been registered, and in one case, the redirect domain observed was hosted on the new .zip top level domain (i.e., docusafe[.]zip). The domain name suggests it is attempting to masquerade as a compressed file containing important documentation. As seen in Figure 6, a new Darktrace/Email feature allows customers to safely view the final destination of the link, which in this case was a seemingly fake Microsoft login page which could be used to harvest corporate credentials.

Figure 6: Safe preview available from the Darktrace/Email Console showing the destination webpage of one of the redirect links observed.

Gathering Account Credentials

Given the nature of the landing page, it is highly likely that this phishing campaign had the objective of stealing the recipients’ credentials, as further indicated by the presence of the recipients’ email addresses in the links. Additionally, these emails were sent to senior employees, likely in an attempt to gather high value credentials to use in future attacks against the company. Had they succeeded, this would have represented a serious security incident, especially considering that 61% of attacks in 2023 involved stolen or hacked credentials according to Verizon’s 2023 data breach investigations report [6]. However, these emails received the highest possible anomaly score (100%) and were held by Darktrace/Email, thus ensuring that their intended recipients were never exposed to them. 

Looking at the indicators of compromise (IoCs) identified in this campaign, it appears that several of the IPs associated with the link payloads have been involved in previous phishing campaigns. Exploring the relations tab for these IPs in Virus Total, some of the communicating files appear to be .eml files and others have generic filenames including strings such as “invoice” “remittance details” “statement” “voice memo”, suggesting they have been involved in other phishing campaigns seemingly related to payment solicitation and other fraud attempts.

Figure 7: Virus Total’s relations tab for the IP 209.94.90[.]1 showing files communicating with the IP. 

Conclusion

Even though the authors of this Quishing campaign used all the tricks in the book to ensure that their emails would arrive unactioned by security tools to the targeted high value recipients’ inboxes, Darktrace/Email was able to immediately recognize the phishing attempts for what they were and block the emails from reaching their destination. 

This campaign used both classic and novel tactics, techniques, and procedures, but ultimately were detected and thwarted by Darktrace/Email. It is yet another example of the increasing attack sophistication mentioned in a previous Darktrace blog [7], wherein the attack landscape is moving from low-sophistication, low-impact, and generic phishing tactics to more targeted, sophisticated and higher impact attacks. Darktrace/Email does not rely on historical data nor known-bad lists and is best positioned to protect organizations from these highly targeted and sophisticated attacks.

References

[1] https://www.infosecurity-magazine.com/opinions/qr-codes-vulnerability-cybercrimes/ 

[2] https://www.helpnetsecurity.com/2023/03/21/qr-scan-scams/ 

[3] https://www.techtarget.com/searchsecurity/feature/Quishing-on-the-rise-How-to-prevent-QR-code-phishing 

[4] https://businessplus.ie/tech/qr-code-phishing-hp/ 

[5] https://www.virustotal.com/gui/domain/fistulacure.com

[6] https://www.verizon.com/business/en-gb/resources/reports/dbir/ ; https://www.verizon.com/business/en-gb/resources/reports/dbir/

[7] https://darktrace.com/blog/shifting-email-conversation 

Darktrace Model Detections 

Association models

No Sender or Content Association

New Sender

Unknown Sender

Low Sender Association

Link models

Focused Link to File Storage

Focused Rare Classified Links

New Unknown Hidden Redirect

High Risk Link + Low Sender Association

Watched Link Type

High Classified Link

File Storage From New

Hidden Link To File Storage

New Correspondent Classified Link

New Unknown Redirect

Rare Hidden Classified Link

Rare Hidden Link

Link To File Storage

Link To File Storage and Unknown Sender

Open Redirect

Unknown Sender Isolated Rare Link

Visually Prominent Link

Visually Prominent Link Unexpected For Sender

Low Link Association

Low Link Association and Unknown Sender

Spoof models

Fake Support Style

External Domain Similarities

Basic Known Entity Similarities

Unusual models

Urgent Request Banner

Urgent Request Banner + Basic Suspicious Sender

Very Young Header Domain

Young Header Domain

Unknown User Tracking

Unrelated Personal Name Address

Unrelated Personal Name Address + Freemail

Unusual Header TLD

Unusual Connection From Unknown

Unbroken Personal

Proximity models

Spam + Unknown Sender

Spam

Spam models

Unlikely Freemail Correspondence

Unlikely Freemail Personalization

General Indicators models

Incoming Mail Security Warning Message

Darktrace Model Tags

Credential Harvesting

Internal IT Impersonation

Multistage payload

Lookalike Domain

Phishing Link

Email Account Takeover

Fake Account Alert

Low Mailing History

No Association

Spoofing Indicators

Unknown Correspondent

VIP

Freemail

IoC - Type - Description & Confidence

fistulacure[.]com

domain

C2 Infrastructure

docusafe[.]zip

domain

Possible C2 Infrastructure

mwmailtec[.]com

domain

Possible C2 Infrastructure

czeromedia[.]com

domain

Possible C2 Infrastructure

192.40.165[.]109

IP address

Probable C2 Infrastructure

209.94.90[.]1

IP address

C2 Infrastructure

52.61.107[.]58

IP address

Possible C2 Infrastructure

40.126.32[.]133

IP address

Possible C2 Infrastructure

211.63.158[.]157

IP address

Possible C2 Infrastructure

119.9.27[.]129

IP address

Possible C2 Infrastructure

184.25.204[.]33

IP address

Possible C2 Infrastructure

40.107.8[.]107

IP address

Probable C2 Infrastructure

40.107.212[.]111

IP address

Possible Infrastructure

27.86.113[.]2

IP address

Possible C2 Infrastructure

192.40.191[.]19

IP address

Possible C2 Infrastructure

157.205.202[.]217

IP address

Possible C2 Infrastructure

a31f1f6063409ecebe8893e36d0048557142cbf13dbaf81af42bf14c43b12a48

SHA256 hash

Possible Malicious File

4c4fb35ab6445bf3749b9d0ab1b04f492f2bc651acb1bbf7af5f0a47502674c9

SHA256 hash

Possible Malicious File

f9c51d270091c34792b17391017a09724d9a7890737e00700dc36babeb97e252

SHA256 hash

Possible Malicious File

9f8ccfd616a8f73c69d25fd348b874d11a036b4d2b3fc7dbb99c1d6fa7413d9a

SHA256 hash

Possible Malicious File

b748894348c32d1dc5702085d70d846c6dd573296e79754df4857921e707c439

SHA256 hash

Possible Malicious File

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
Alexandra Sentenac
Cyber Analyst

More in this series

No items found.

Blog

/

OT

/

September 2, 2026

Botnet Behind the Camera: Mirai Katana Activity on a Video Recording Device

Default blog imageDefault blog image

Key takeaways

  • Darktrace identified a camera device infected with the Mirai/Katana botnet in a sports-sector customer environment, showing how exposed IoT devices can become active participants in wider attack chains.
  • The compromise involved suspicious Wget behavior, file downloads from rare external IPs, unusual incoming HTTP connections to video recorder management interfaces, and large outbound data transfers to infrastructure associated with botnet activity.
  • The incident highlights the importance of extending visibility and response beyond traditional endpoints, as unmanaged or overlooked connected devices can be exploited for command-and-control, malware delivery, and data exfiltration.

Mirai and the Katana variant

Mirai is a botnet that first emerged in August 2016 and is well known for launching large-scale distributed-denial-of-service (DDoS) attacks, typically targeting exposed Internet of Things (IoT) devices. It identifies vulnerable IoT devices ,often by abusing default credentials or exposed services, and recruiting them into a remotely controlled botnet that can be used in DDoS campaigns [1].

Katana, one of the many variants that arose after Mirai’s source code was released publicly, was first observed in late 2020 and has been seen using more advanced capabilities, including custom command-and-control (C2), persistence mechanisms, and DDoS functionality [2].

In March 2026, research from the Nokia Deepfield Emergency Response Team (ERT) identified Katana as a Mirai-derived DDoS botnet targeting Android-based TV set-top boxes through exposed Android Debug Bridge (ADB) access.  Observed capabilities included custom C2, runtime domain rotation, multiple DDoS methods, and an on-device compiled kernel rootkit used for persistence and stealth [3].

Darktrace’s detection of Mirai Botnet activity on a camera device

In early 2026, Darktrace identified a Network/Digital Video Recorder (NVR/DVR) on the network of a sports-sector customer that had been infected with the Mirai Katana botnet and subsequently used to exfiltrate data from the customer’s environment. Seemingly related follow-up activity was observed on the same device several months later.

In both instances, the Darktrace Security Operations Centre (SOC) alerted the customer as part of the Managed Threat Detection (MTD) service. However, as Darktrace’s Autonomous Response capability was not fully enabled on the affected device, Darktrace was unable to proactively block the suspicious activity or prevent the compromise from continuing and recurring.

The initial compromise appears to have occurred when the affected device was seen using Wget to download Linux-based Executable and Linkable Format (ELF) files from a rare external IP, 195.177.94[.]105, which had not previously been observed in the customer’s network. Further analysis downloaded file hashes identified files related to the Mirai botnet.

Figure 1: Darktrace’s Real-Time AI Analyst investigation into the unusual outbound connection where the ELF files were downloaded.

Within a few hours, Darktrace detected the device uploading close to 3GB of data to another external IP, 50.7.49[.]4:3017 (ASN AS30058 FDCSERVERS), suggesting that the activity was likely routed via a virtual private server (VPS) hosted by FDC Servers [2]. Attackers often abuse VPS infrastructure from legitimate cloud providers to blend in with legitimate traffic and evade IP reputation and geolocation-based detections.

Figure 2:  Darktrace’s detection of the unusual data upload activity by the affected camera device.

Darktrace continued to observe similar data transfers to multiple rare endpoints  including 171.225.223[.]53, 95.161.128[.]62, 61.7.209[.]88, 95.161.128[.]62, which have been linked to Mirai by open-source intelligence (OSINT).

Figure 3: Darktrace’s detection of spikes in unusual external data transfer activity from the camera device.

Exploitation continued

Several months later, Darktrace identified the same exfiltration pattern on the device again, this time with stronger indications of associations with Mirai Katana botnet infection.

The device received incoming HTTP connections from 129.121.114[.]124, an external IP known to be associated with the Katana botnet IP [3]. The connections targeted the ‘/dvr/cmd’ path using the root username and user agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.246.

The ‘/dvr/cmd’ path appears to be associated with the affected device’s web management functionality. This API endpoint has historically been targeted by Mirai and other IoT botnets through the exploitation of critical command injection vulnerabilities and automated botnet exploitation [4].

Figure 4: Darktrace’s  detection of HTTP connectivity from the external IP associated with Mirai Katana Botnet.

A few days later, Darktrace observed the Wget utility being used to download ELF files, including “/lil”,  from the IP 129.121.114[.]124. OSINT reporting has since associated this IP address with the Mirai Katana botnet. Notably, the IP observed earlier in the year, 195.177.94[.]105, had also hosted a file named “lil”, indicating a link between the observed activity.

Over the following days, the device received a sudden spike in connections from multiple rare external endpoints, suggesting a possible successful brute force attack. Darktrace also observed the device exfiltrating just under 4GB of data to another Mirai-associated IP address,  66.92.198[.]194, over ports 3344, 954922, and 80. Finally, the device was seen uploading data to the Mirai botnet IP 5.175.249[.]53 over port138 and exhibited an increase in UDP connections to 34.18.28[.]10 over port 9068.

Following both file download events, Darktrace identified spikes in external data transfers and connection attempts to rare destinations. While Darktrace’s Threat Research team could not confirm with high confidence that this to activity was directly associated with Mirai, it may indicate that Mirai Katana includes data exfiltration functionality.

Darktrace’s threat researchers also identified an internet-facing NTP server belonging to a separate customer receiving incoming connection attempts from the same initially observed IP, 195.177.94[.]105,over the port 123. This suggests that Mirai Katana may not exclusively target IoT devices.

Conclusion

This case demonstrates how threat actors can exploit overlooked IoT and OT devices to support broader malicious objectives. Here, a camera device infected with a botnet was used to exfiltrate data from the customer's environment, showing how peripheral assets can become active participants in an attack chain.

This case also reinforces a challenge many organizations face today: extending security visibility beyond traditional endpoints and servers. Cameras, sensors, and other connected devices often operate with limited monitoring and may fall outside established security processes, despite maintaining network connectivity and access to potentially sensitive environments. This is particularly relevant in the sports sector, where growing reliance on connected cameras, smart stadium technologies, and other IoT devices continues to expand the attack surface, as highlighted in Darktrace's Sports Sector Threat Report.

As botnets like Kata and Mirai continue to evolve, defenders need visibility across unmanaged IoT and edge devices, as well as security solutions that can recognize subtle deviations in device behavior that may indicate an emerging compromise.

Credit to Parvatha Ananthakannan (Cyber Analyst), Signe Zaharka (Principal Analyst)

Edited by Ryan Traill (Content Manager)

Appendices

Darktrace Model Detections

·      Anomalous File / EXE from Rare External Location

·      Anomalous File / Multiple EXE from Rare External Locations

·      Device / Initial Attack Chain Activity

·      Unusual Activity / Unusual External Data to New Endpoint

·      Anomalous Connection / Data Sent to Rare Domain

·      Unusual Activity / Enhanced Unusual External Data Transfer

·      Anomalous Connection / Uncommon 1 GiB Outbound

·      Device / Significant UDP Increase

·      Anomalous Connection / Low and Slow Exfiltration to IP

·      Compromise / Large Number of Suspicious Failed Connections

·      Compromise / Large Number of Suspicious Successful Connections

·      Unusual Activity / Unusual External Activity

·      Compliance / SSH to Rare External Destination

·      Unusual Activity / Unusual DNS

·      Device / External Network Scan

·      Device / Suspicious DNS Activity

·      Device / Large Number of Model Alerts

List of Indicators of Compromise (IoCs)

Indicator of Compromise Type Description
195.177.94[.]105 IP C2 endpoint
50.7.49[.]4:30171 IP Possible C2 endpoint
129.121.114[.]124 IP C2 endpoint
hxxp://195.177.94[.]105/n3 URL Likely C2 endpoint
hxxp://195.177.94[.]105/n2 URL Likely C2 endpoint
hxxp://129.121.114[.]124/lil URL Likely C2 endpoint
hxxp://129.121.114[.]124/HHn URL Possible C2 endpoint
hxxp://129.121.114[.]124/JFc URL Possible C2 endpoint
hxxp://129.121.114[.]124/jum URL Likely C2 endpoint
hxxp://129.121.114[.]124/OaSf URL Likely C2 endpoint
hxxp://129.121.114[.]124/OPWg URL Possible C2 endpoint
hxxp://129.121.114[.]124/vHwK URL Possible C2 endpoint
hxxp://129.121.114[.]124/VLv URL Possible C2 endpoint
hxxp://129.121.114[.]124/WbJ URL Possible C2 endpoint
hxxp://129.121.114[.]124/zkR URL Possible C2 endpoint
Ab17883ae4c3bc6afa18c439166eeeb4b03186e3093d984e3a95f573e0fcb7d8 SHA-256 Mirai payload
3d587e809dac49d34a3f717e072fd0aebe5e71db63333e45c81577d6b4266f87 SHA-256 Mirai payload
Bf6e81733a7e209d3dce80d15bf3c5d300752d961fae6b45d90c9bbe7f8c89a2 SHA-256 Possible payload
f25488303813ab1ec0eaa71562938601aac185e8aaf93adb84522557f7cf4dd6 SHA-256 Possible payload
0cb4ff6b71f4423184bfa35c34e9090297637208b0e30205d4b224e56abde2ef SHA-256 Possible payload
19c24cbeaf06b2e7697083f33a85521a9315105c784691bde7420fde4cc69410 SHA-256 Likely Mirai payload
1e74f734fff8df91f4f7172d0de10c421eca78aeb800e8a48e16bc5dbde5d20e SHA-256 Possible payload
6e71f7763d1f29d5712106ebb122e281c32787540aa2342b0fe5351d585d18d7 SHA-256 Possible payload
71f4ff7cdb6d6a7d2673c543c5d2535093afbd707b20a5b9ddf735466c1105c1 SHA-256 Possible payload
76db7ee73ebf15e48a3cb24a074d92248671ef2c6ed3bc3e708377341fb7674d SHA-256 Possible payload
da87a65f7beb438e61f0b61964fed8aa305a380f569042f84c55eca8fa7929b8 SHA-256 Possible payload
e15809eb6ba66477175270d62cfa53e4bf278595f69938708c81c4bc457930fe SHA-256 Mirai payload

MITRE ATT&CK Mapping

Tactic Technique ID Technique / Sub-technique
Initial Access T1659 Content Injection
T1189 Drive-by Compromise
Exfiltration T1041 Exfiltration Over C2 Channel
T1048.003 Exfiltration Over Unencrypted Non-C2 Protocol
Command and Control T1105 Ingress Tool Transfer
T1095 Non-Application Layer Protocol
T1571 Non-Standard Port
Reconnaissance T1595.001 Scanning IP Blocks
Continue reading
About the author
Parvatha Ananthakannan
Cyber Analyst

Blog

/

/

August 26, 2026

AI Agents: Securing the Path from Intent to Action

Photograph of AI data centerDefault blog imageDefault blog image

The UK’s National Cyber Security Centre (NCSC) recently published guidance on managing the cyber risk of agentic AI. While the document is framed as interim advice as more formal guidance is developed, the framing reflects the current state of the industry: organizations are already deploying agents into production environments while standards, controls, and operating models for autonomous systems remain unsettled. Governance is evolving alongside adoption rather than preceding it, a reality which underscores the importance of robust controls.  

The NCSC’s guidance recommends aligning controls to an agent's level of autonomy, assigning distinct identities, limiting permissions, constraining access to systems and data, monitoring activity, maintaining human oversight, and preserving the ability to intervene when necessary. Most of these recommendations will sound familiar to security teams. The challenge is not the novelty of the controls. It is the type of system those controls now need to govern.

The shift from model security to agent security

For several years, AI security discussions have focused heavily on models. Can a model be manipulated? Jailbroken? Trusted? Can it expose information it should not? Those questions remain important, but they capture only part of the problem. A model generating text is one thing. A system connected to identities, applications, tools, workflows, and business data is another.

The difference becomes clearer when comparing a chatbot that answers questions with an agent that can retrieve customer records, update tickets, invoke tools, trigger workflows, and interact with external systems. The underlying model may be identical. Its access is not. The security question begins to shift from what the model knows to what the system can do.

The same theme appears in the Five Eyes statement released earlier this year, describing AI as a force multiplier that is accelerating both offensive and defensive cyber operations. The NCSC guidance explores what that reality looks like when autonomous systems begin operating inside enterprise environments.

Securing AI agents in operation

The NCSC spends relatively little time debating model behavior and considerably more time discussing identity, permissions, monitoring, oversight, containment, and response. Agents are treated as participants within an environment rather than isolated pieces of technology.  

That's broadly consistent with how we think about the problem at Darktrace.

An agent should not be treated as an extension of a user account. It develops its own behavioral patterns. It accesses systems, interacts with data, invokes tools, and moves across workflows in ways that can be observed independently. Understanding what an agent is permitted to do matters. Understanding how it actually behaves once deployed, and whether that behavior aligns with business intent, matters just as much.

Identity provides an obvious example. The NCSC recommends assigning distinct identities to agents rather than allowing them to disappear into surrounding human or service accounts. Most importantly, assigning agents distinct identities enables independent behavioral monitoring.

Development assumptions vs. real-world behavior

The same principle extends to monitoring. NCSC guidance places agent activity within normal security operations rather than treating it as a separate AI governance function. Many of the controls described are put in place before an agent begins operating. Sandboxing, credential design, approval workflows and human oversight all reflect judgments about how the system is expected to behave and what risks it is likely to create.

Actual use may challenge those assumptions. Access patterns change. Workflows expand. Systems begin interacting with resources they have never touched before. Processes that appeared reasonable during design behave differently in production. Human oversight requirements may turn out to be either excessive or inadequate once the system is operating at scale and operating within the context of unique business processes.

The Five Eyes statement points to a similar issue: organizations need confidence that controls continue to work as intended once systems are exposed to real users, data, tools and operational pressures. Often, the question is not whether an agent is technically allowed to perform an action, but whether its behavior remains consistent with the role it was intended to play.

Monitoring and governance of AI agents go hand-in-hand

This problem is exactly why monitoring and governance should be treated as part of the same process. Governance sets the initial parameters for deployment, while monitoring provides evidence about whether those parameters remain appropriate. That evidence should, in turn, inform changes to permissions, controls and oversight.

This matters increasingly as autonomous systems are integrated into business processes. The relevant risk is shaped not only by the model or agent itself, but by what it can access, what actions it can take, and how its behavior changes in practice.

Developing continuous oversight of AI agent behavior

The implication is clear: governance cannot end at deployment. Organizations need a way to understand how agents behave after deployment, test whether controls remain appropriate, and adjust them as conditions change. That requires visibility not just into technical activity, but into whether that activity makes sense in the context of the business process the agent is intended to support.

This is where business-centric behavioral security can become critical. Risk does not emerge from the model itself: it emerges from the actions an autonomous system takes within the enterprise and the downstream consequences of those actions.  

An agent can operate exactly as intended and still create risk if it accesses sensitive information in an unexpected context, exercises permissions in ways that create unintended exposure, or influences business processes in ways that were not anticipated during design and review.

Traditional governance vs. behavioral security

Traditional governance frameworks provide assurance at a point in time. Behavioral security can provide ongoing visibility into how autonomous systems interact with the organization they are meant to serve. Rather than focusing exclusively on model performance or policy compliance, organizations need to understand whether an agent's behavior aligns with business intent, operational expectations, and acceptable risk tolerances as conditions change.

As enterprises move from isolated AI deployments to interconnected ecosystems of agents, visibility into behavior becomes as important as visibility into code. Governance determines what an autonomous system is permitted to do. Behavioral analytics helps determine what it is doing, what business outcomes it is producing, and whether those outcomes remain aligned with the organization's objectives.

[related-resource]

Continue reading
About the author
Margaret Cunningham, PhD
VP, Security & AI Strategy, Field CISO
Your data. Our AI.
Elevate your network security with Darktrace AI