Blog
/
/
April 4, 2022

Explore Internet-Facing System Vulnerabilities

Read about 2021's top four incidents and how Darktrace's advanced threat detection technology identified and mitigated vulnerabilities. Learn more.
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
Sam Lister
Specialist Security Researcher
Default blog image
04
Apr 2022

By virtue of their exposure, Internet-facing systems (i.e., systems which have ports open/exposed to the wider Internet) are particularly susceptible to compromise. Attackers typically compromise Internet-facing systems by exploiting zero-day vulnerabilities in applications they run. During 2021, critical zero-day vulnerabilities in the following applications were publicly disclosed:

Internet-facing systems running these applications were consequently heavily targeted by attackers. In this post, we will provide examples of compromises of these systems observed by Darktrace’s SOC team in 2021. As will become clear, successful exploitation of weaknesses in Internet-facing systems inevitably results in such systems doing things which they do not normally do. Rather than focusing on identifying attempts to exploit these weaknesses, Darktrace focuses on identifying the unusual behaviors which inevitably ensue. The purpose of this post is to highlight the effectiveness of this approach.

Exchange server compromise

In January, researchers from the cyber security company DEVCORE reported a series of critical vulnerabilities in Microsoft Exchange which they dubbed ‘ProxyLogon’.[1] ProxyLogon consists of a server-side request forgery (SSRF) vulnerability (CVE-2021-26855) and a remote code execution (RCE) vulnerability (CVE-2021-27065). Attackers were observed exploiting these vulnerabilities in the wild from as early as January 6.[2] In April, DEVCORE researchers reported another series of critical vulnerabilities in Microsoft Exchange which they dubbed ‘ProxyShell’.[3] ProxyShell consists of a pre-authentication path confusion vulnerability (CVE-2021-34473), a privilege elevation vulnerability (CVE-2021-34523), and a post-authentication RCE vulnerability (CVE-2021-31207). Attackers were first observed exploiting these vulnerabilities in the wild in August.[4] In many cases, attackers exploited the ProxyShell and ProxyLogon vulnerabilities in order to create web shells on the targeted Exchange servers. The presence of these web shells provided attackers with the means to remotely execute commands on the compromised servers.

In early August 2021, by exploiting the ProxyShell vulnerabilities, an attacker gained the rights to remotely execute PowerShell commands on an Internet-facing Exchange server within the network of a US-based transportation company. The attacker subsequently executed a number of PowerShell commands on the server. One of these commands caused the server to make a 28-minute-long SSL connection to a highly unusual external endpoint. Within a couple of hours, the attacker managed to strengthen their foothold within the network by installing AnyDesk and CobaltStrike on several internal devices. In mid-August, the attacker got the devices on which they had installed Cobalt Strike to conduct network reconnaissance and to transfer terabytes of data to the cloud storage service, MEGA. At the end of August, the attacker got the devices on which they had installed AnyDesk to execute Conti ransomware and to spread executable files and script files to further internal devices.

In this example, the attacker’s exploitation of ProxyShell immediately resulted in the Exchange Server making a long SSL connection to an unusual external endpoint. This connection caused the model Device / Long Agent Connection to New Endpoint to breach. The subsequent reconnaissance, lateral movement, C2, external data transfer, and encryption behavior brought about by the attacker were also picked up by Darktrace’s models.

A non-exhaustive list of the models that breached as a result of the behavior brought about by the attacker:

  • Device / Long Agent Connection to New Endpoint
  • Device / ICMP Address Scan
  • Anomalous Connection / SMB Enumeration
  • Anomalous Server Activity / Outgoing from Server
  • Compromise / Beacon to Young Endpoint
  • Anomalous Server Activity / Rare External from Server
  • Compromise / Fast Beaconing to DGA
  • Compromise / SSL or HTTP Beacon
  • Compromise / Sustained SSL or HTTP Increase
  • Compromise / Beacon for 4 Days
  • Anomalous Connection / Multiple HTTP POSTs to Rare Hostname
  • Unusual Activity / Enhanced Unusual External Data Transfer
  • Anomalous Connection / Data Sent to Rare Domain
  • Anomalous Connection / Uncommon 1 GiB Outbound
  • Compliance / SMB Drive Write
  • Anomalous File / Internal / Additional Extension Appended to SMB File
  • Anomalous Connection / Suspicious Read Write Ratio
  • Anomalous Connection / Suspicious Read Write Ratio and Unusual SMB
  • Anomalous Connection / Sustained MIME Type Conversion
  • Unusual Activity / Anomalous SMB Move & Write
  • Unusual Activity / Unusual Internal Data Volume as Client or Server
  • Device / Suspicious File Writes to Multiple Hidden SMB Shares
  • Compromise / Ransomware / Suspicious SMB Activity
  • Anomalous File / Internal / Unusual SMB Script Write
  • Anomalous File / Internal / Masqueraded Executable SMB Write
  • Device / SMB Lateral Movement
  • Device / Multiple Lateral Movement Model Breaches

Confluence server compromise

Atlassian’s Confluence is an application which provides the means for building collaborative, virtual workspaces. In the era of remote working, the value of such an application is undeniable. The public disclosure of a critical remote code execution (RCE) vulnerability (CVE-2021-26084) in Confluence in August 2021 thus provided a prime opportunity for attackers to cause havoc. The vulnerability, which arises from the use of Object-Graph Navigation Language (OGNL) in Confluence’s tag system, provides attackers with the means to remotely execute code on vulnerable Confluence server by sending a crafted HTTP request containing a malicious parameter.[5] Attackers were first observed exploiting this vulnerability towards the end of August, and in the majority of cases, attackers exploited the vulnerability in order to install crypto-mining tools onto vulnerable servers.[6]

At the beginning of September 2021, an attacker was observed exploiting CVE-2021-26084 in order to install the crypto-mining tool, XMRig, as well as a shell script, onto an Internet-facing Confluence server within the network of an EMEA-based television and broadcasting company. Within a couple of hours, the attacker installed files associated with the crypto-mining malware, Kinsing, onto the server. The Kinsing-infected server then immediately began to communicate over HTTP with the attacker’s C2 infrastructure. Around the time of this activity, the server was observed using the MinerGate crypto-mining protocol, indicating that the server had begun to mine cryptocurrency.

In this example, the attacker’s exploitation of CVE-2021-26084 immediately resulted in the Confluence server making an HTTP GET request with an unusual user-agent string (one associated with curl in this case) to a rare external IP. This behavior caused the models Device / New User Agent, Anomalous Connection / New User Agent to IP Without Hostname, and Anomalous File / Script from Rare Location to breach. The subsequent file downloads, C2 traffic and crypto-mining activity also resulted in several models breaching.

A non-exhaustive list of the models which breached as a result of the unusual behavior brought about by the attacker:

  • Device / New User Agent
  • Anomalous Connection / New User Agent to IP Without Hostname
  • Anomalous File / Script from Rare Location
  • Anomalous File / EXE from Rare External Location
  • Anomalous File / Internet Facing System File Download
  • Device / Initial Breach Chain Compromise
  • Anomalous Connection / Posting HTTP to IP Without Hostname
  • Compliance / Crypto Currency Mining Activity
  • Compromise / High Priority Crypto Currency Mining
  • Device / Internet Facing Device with High Priority Alert

GitLab server compromise

GitLab is an application providing services ranging from project planning to source code management. Back in April 2021, a critical RCE vulnerability (CVE-2021-22205) in GitLab was publicly reported by a cyber security researcher via the bug bounty platform, HackerOne.[7] The vulnerability, which arises from GitLab’s use of ExifTool for removing metadata from image files, [8] enables attackers to remotely execute code on vulnerable GitLab servers by uploading specially crafted image files.[9] Attackers were first observed exploiting CVE-2021-22205 in the wild in June/July.[10] A surge in exploitations of the vulnerability was observed at the end of October, with attackers exploiting the flaw in order to assemble botnets.[11] Darktrace observed a significant number of cases in which attackers exploited the vulnerability in order to install crypto-mining tools onto vulnerable GitLab servers.

On October 29, an attacker successfully exploited CVE-2021-22205 on an Internet-facing GitLab server within the network of a UK-based education provider. The organization was trialing Darktrace when this incident occurred. The attacker installed several executable files and shell scripts onto the server by exploiting the vulnerability. The attacker communicated with the compromised server (using unusual ports) for several days, before making the server transfer large volumes of data externally and download the crypto-mining tool, XMRig, as well as the botnet malware, Mirai. The server was consequently observed making connections to the crypto-mining pool, C3Pool.

In this example, the attacker’s exploitation of the vulnerability in GitLab immediately resulted in the server making an HTTP GET request with an unusual user-agent string (one associated with Wget in this case) to a rare external IP. The models Anomalous Connection / New User Agent to IP Without Hostname and Anomalous File / EXE from Rare External Location breached as a result of this behavior. The attacker’s subsequent activity on the server over the next few days resulted in frequent model breaches.

A non-exhaustive list of the models which breached as a result of the attacker’s activity on the server:

  • Anomalous Connection / New User Agent to IP Without Hostname
  • Anomalous File / EXE from Rare External Location
  • Anomalous File / Multiple EXE from Rare External Locations
  • Anomalous File / Internet Facing Device with High Priority Alert
  • Anomalous File / Script from Rare Location
  • Anomalous Connection / Application Protocol on Uncommon Port
  • Anomalous Connection / Anomalous SSL without SNI to New External
  • Device / Initial Breach Chain Compromise
  • Unusual Activity / Unusual External Data to New IPs
  • Anomalous Server Activity / Outgoing from Server
  • Device / Large Number of Model Breaches from Critical Network Device
  • Anomalous Connection / Data Sent to Rare Domain
  • Compromise / Suspicious File and C2
  • Unusual Activity / Enhanced Unusual External Data Transfer
  • Compliance / Crypto Currency Mining Activity
  • Compliance / High Priority Crypto Currency Mining
  • Anomalous File / Zip or Gzip from Rare External Location
  • Compromise / Monero Mining
  • Device / Internet Facing Device with High Priority Alert
  • Anomalous Server Activity / Rare External from Server
  • Compromise / Slow Beaconing Activity To External Rare
  • Compromise / Beaconing Activity To External Rare
  • Compromise / HTTP Beaconing to Rare Destination
  • Compromise / High Volume of Connections with Beacon Score
  • Anomalous File / Numeric Exe Download

Log4j server compromise

On December 9 2021, a critical RCE vulnerability (dubbed ‘Log4Shell’) in version 2 of Apache’s Log4j was publicly disclosed by researchers at LunaSec.[12] As a logging library present in potentially millions of Java applications,[13] Log4j constitutes an obscured, yet ubiquitous feature of the digital world. The vulnerability (CVE-2021-44228), which arises from Log4j’s Java Naming and Directory Interface (JNDI) Lookup feature, enables an attacker to make a vulnerable server download and execute a malicious Java class file. To exploit the vulnerability, all the attacker must do is submit a specially crafted JNDI lookup request to the server. The fact that Log4j is present in so many applications and that the exploitation of this vulnerability is so simple, Log4Shell has been dubbed the ‘most critical vulnerability of the last decade’.[14] Attackers have been exploiting Log4Shell in the wild since at least December 1.[15] Since then, attackers have been observed exploiting the vulnerability to install crypto-mining tools, Cobalt Strike, and RATs onto vulnerable servers.[16]

On December 10, one day after the public disclosure of Log4Shell, an attacker successfully exploited the vulnerability on a vulnerable Internet-facing server within the network of a US-based architecture company. By exploiting the vulnerability, the attacker managed to get the server to download and execute a Java class file named ‘Exploit69ogQNSQYz.class’. Executing the code in this file caused the server to download a shell script file and a file related to the Kinsing crypto-mining malware. The Kinsing-infected server then went on to communicate over HTTP with a C2 server. Since the customer was using the Proactive Threat Notification (PTN) service, they were immediately alerted to this activity, and the server was subsequently quarantined, preventing crypto-mining activity from taking place.

In this example, the attacker’s exploitation of the zero-day vulnerability immediately resulted in the vulnerable server making an HTTP GET request with an unusual user-agent string (one associated with Java in this case) to a rare external IP. The models Anomalous Connection / Callback on Web Facing Device and Anomalous Connection / New User Agent to IP Without Hostname breached as a result of this behavior. The device’s subsequent file downloads and C2 activity caused several Darktrace models to breach.

A non-exhaustive list of the models which breached as a result of the unusual behavior brought about by the attacker:

  • Anomalous Connection / Callback on Web Facing Device
  • Anomalous Connection / New User Agent to IP Without Hostname
  • Anomalous File / Internet Facing System File Download
  • Anomalous File / Script from Rare External Location
  • Device / Initial Breach Chain Compromise
  • Anomalous Connection / Posting HTTP to IP Without Hostname

Round-up

It is inevitable that attackers will attempt to exploit zero-day vulnerabilities in applications running on Internet-facing devices. Whilst identifying these attempts is useful, the fact that attackers regularly exploit new zero-days makes the task of identifying attempts to exploit them akin to a game of whack-a-mole. Whilst it is uncertain which zero-day vulnerability attackers will exploit next, what is certain is that their exploitation of it will bring about unusual behavior. No matter the vulnerability, whether it be a vulnerability in Microsoft Exchange, Confluence, GitLab, or Log4j, Darktrace will identify the unusual behaviors which inevitably result from its exploitation. By identifying unusual behaviors displayed by Internet-facing devices, Darktrace thus makes it almost impossible for attackers to successfully exploit zero-day vulnerabilities without being detected.

For Darktrace customers who want to find out more about detecting potential compromises of internet-facing devices, refer here for an exclusive supplement to this blog.

Thanks to Andy Lawrence for his contributions.

Footnotes

1. https://devco.re/blog/2021/08/06/a-new-attack-surface-on-MS-exchange-part-1-ProxyLogon/

2. https://www.volexity.com/blog/2021/03/02/active-exploitation-of-microsoft-exchange-zero-day-vulnerabilities/

3. https://www.zerodayinitiative.com/blog/2021/8/17/from-pwn2own-2021-a-new-attack-surface-on-microsoft-exchange-proxyshell

4. https://www.rapid7.com/blog/post/2021/08/12/proxyshell-more-widespread-exploitation-of-microsoft-exchange-servers/

5. https://www.kaspersky.co.uk/blog/confluence-server-cve-2021-26084/23376/

6. https://www.bleepingcomputer.com/news/security/atlassian-confluence-flaw-actively-exploited-to-install-cryptominers/

7. https://hackerone.com/reports/1154542

8. https://security.humanativaspa.it/gitlab-ce-cve-2021-22205-in-the-wild/

9.https://about.gitlab.com/releases/2021/04/14/security-release-gitlab-13-10-3-released/

10. https://www.rapid7.com/blog/post/2021/11/01/gitlab-unauthenticated-remote-code-execution-cve-2021-22205-exploited-in-the-wild/

11. https://www.hackmageddon.com/2021/12/16/1-15-november-2021-cyber-attacks-timeline/

12. https://www.lunasec.io/docs/blog/log4j-zero-day/

13. https://www.csoonline.com/article/3644472/apache-log4j-vulnerability-actively-exploited-impacting-millions-of-java-based-apps.html

14. https://www.theguardian.com/technology/2021/dec/10/software-flaw-most-critical-vulnerability-log-4-shell

15. https://www.rapid7.com/blog/post/2021/12/15/the-everypersons-guide-to-log4shell-cve-2021-44228/

16. https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/

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
Sam Lister
Specialist Security Researcher

More in this series

No items found.

Blog

/

Email

/

June 26, 2026

How Darktrace Transformed Cybersecurity at Our Health Center: A CIO’s Perspective

Default blog imageDefault blog image

How Darktrace Transformed Cybersecurity at Our Health Center: A CIO’s Perspective

In my role as CIO, I bring years of experience leading IT for healthcare organizations. I’ve seen firsthand the unique cybersecurity challenges that nonprofit health centers face: limited budgets, small IT teams, and the constant pressure to prioritize patient care over technology investments. Yet, the threat landscape for health is relentless, and the stakes for protecting patient data and ensuring operational continuity have never been higher. It’s a balancing act.

The search for a better solution

Like many nonprofits, organizations I work at start with Microsoft’s security stack. The discounted pricing for nonprofits makes it an obvious choice, and Microsoft Defender provided a solid foundation for endpoint and email security. However, I quickly realized that relying on a single vendor, even one as robust as Microsoft, left gaps in our defenses. Cybersecurity is never one-size-fits-all, which is why my preference was to layer an additional solution on top of our native security to improve our security posture.

Teams needed a solution that could layer seamlessly on top of Microsoft, without adding complexity or draining limited resources. That’s when I found Darktrace. I had heard of their reputation after seeing how other organizations used Darktrace to secure their infrastructure and was impressed by their AI-native, agentless approach and agreed to a proof of value (POV).

Our goal was to elavate Microsoft with an additional layer of intelligence- one that could seamlessly integrate, operate autonomously, and support a small team without increasing overhead. We turned to Darktrace because its AI-native, agentless approach offered a fundamentally different way to detect and respond to threats, learning our environment in real time and filling gaps that traditional tools can miss. With a quick POV, we were able to validate how effectively Darktrace works alongside Microsoft to deliver a more complete and resilient security architecture.

Why Darktrace stood out

From the start, Darktrace differentiated itself in several critical ways:

  • Deep visibility: Unlike other solutions that rely simply on host-based monitoring with endpoint agents, Darktrace operates passively at the network layer and integrates via APIs for email and identity security. This gave full visibility into network traffic that we previously didn’t have, going beyond our existing endpoint-based tools without adding additional maintenance overhead for our small IT team.
  • AI-native from the ground up: Darktrace wasn’t just layering AI on top of an existing product; it was built with AI at its core. Their autonomous detection and response to threats immediately reduced the need for constant human supervision. In a world where cyber-attacks are increasingly sophisticated and subtle, having an AI that learns our environment and adapts in real time is invaluable.
  • Comprehensive coverage: We started with a POV focused on email security, but quickly expanded to full deployment across our entire infrastructure. Darktrace’s products now protect our email, network, and identity layers, providing visibility and defense against lateral movement and abnormal behavior that traditional tools often miss.

Integration and workflow: Smooth and simple

One of the most impressive aspects of Darktrace is how easy it was to integrate into an existing environment. For network security, it was as simple as plugging an appliance into our top-of-rack switch – no downtime, no complex configuration. For email and identity, API integrations meant we could be up and running in hours, not weeks.

This simplicity extended to day-to-day operations. Our IT team received regular security reports, and any time we had questions or needed to adjust policies, Darktrace’s support team was there with white-glove service. Their responsiveness- even in the middle of the night- gave us confidence that we had true partners, not just a vendor.

Real-world impact: Threats stopped, time saved

The results spoke for themselves. During the time with Darktrace, I did not experience any security incidents. The team slept better at night knowing that Darktrace was monitoring for anomalies and proactively blocking suspicious activity, alerting us even before we noticed anything was wrong.

A memorable example was during an Electronic Health Record (EHR) upgrade, when my team forgot to adjust the policy in advance. Darktrace’s autonomous response was so effective that it blocked our upgrade activities- proof that nothing, not even internal changes, could slip by unnoticed. This level of vigilance meant that ransomware, data exfiltration attempts, or insider threats would be detected and contained before causing harm.

While I can’t share specific ROI numbers, the value was clear: we’ve avoided costly breaches, reduced the time spent investigating alerts, and eliminated the performance drag of agent-based tools. With Darktrace layered on top of Microsoft, I’ve hit the right balance of maximum protection with minimal spending. The cost of Darktrace / EMAIL was competitive, especially when factoring in the included Managed Detection and Response (MDR) service, which provides expert human oversight on top of the AI.

Key differentiators over the competition

  • Extending visibility beyond the endpoint: Traditional host-based monitoring solutions, such as EDR, play a critical role in securing individual devices. By adding a network detection and response (NDR) layer, we gained visibility into activity across our wider digital environment, surfacing threats that move laterally, operate between devices, or bypass endpoint controls. Darktrace also stood out for its ability to learn our normal patterns of behavior and identify subtle deviations in real time, not just known indicators of compromise. Because this is delivered through passive, non-disruptive monitoring, we were able to strengthen our defenses without adding complexity or impacting performance.
  • Layered security without complexity: Darktrace elevated our Microsoft foundation without creating conflicts or requiring us to disable existing protections. This layered approach maximized our security posture without adding operational burden.
  • Expert partnership: Beyond technology, Darktrace’s team acted as true partners, guiding us through deployment, providing ongoing support, and helping us interpret findings. This partnership was as valuable as the technology itself.

Advice for other nonprofits

If you’re an IT leader in a nonprofit, my advice is simple: look for solutions that are easy to deploy, intelligent in their response, and cost-effective. Don’t settle for more endpoint based tools that overlap with what you already have. Seek out a layered approach that covers your blind spots – especially at the network and email layers- at a price point that suits your organization.

Most importantly, don’t be afraid to evaluate new solutions. Even if you’re inundated with vendor pitches, you owe it to your organization to explore options that could save you time, money, and sleepless nights.

For organizations I work at, combining Microsoft’s security stack with Darktrace’s AI-native, platform struck the right balance between protection and practicality. We gained enterprise-grade security without sacrificing performance or stretching our budget. In the end, that meant more resources for what matters most: delivering care to our patients. If you’re facing similar challenges, I encourage you to consider how Darktrace could transform your security posture, and give your team the peace of mind they deserve.

For the organization I work in, combining Microsoft with Darktrace delivered a clear step-change in our security posture. Microsoft provided the foundation, while Darktrace’s behavioral intelligence added visibility into the unknown, surfacing emerging threats based on deviations in real-time activity, not just known indicators.

The result was enterprise-grade protection without added overhead, allowing us to stay focused on patient outcomes, not security operations. For organizations facing similar pressures, this layered approach offers a smarter, more efficient path to securing modern environments.

Continue reading
About the author
Mice Chen
Chief Information Security Officer

Blog

/

/

June 25, 2026

Shadow AI Detection: The First Step Toward Securing AI

shadow aiDefault blog imageDefault blog image

Why shadow AI is emerging  

Imagine you’re an employee under pressure, deadlines stacking up, repetitive tasks piling higher by the day. You find a free AI tool online that promises to automate the work in seconds; no approvals are needed. It feels like a simple win, paste in some data, write a quick prompt, and move faster.

But in that moment, something changed.  

Sensitive customer information is entered into a tool your organization doesn’t monitor, doesn’t govern, and can’t see and suddenly, that data is no longer where it should be, and no one knows where it’s gone.

This is the reality of Shadow AI: employees using unsanctioned AI tools to move faster, while unintentionally creating risk that exists entirely outside visibility and control.  

This is not just a one off case, research across businesses indicate that nearly half of employees report using unsanctioned AI tools, often prioritizing speed and productivity over security. Additionally, 51% of employees report connecting AI tools to work systems or apps without IT approval, creating significant operational risk where the average cost of security incidents in organizations with a high level of shadow AI usage can reach $670k.

While shadow AI is often top of mind for security professionals, it is just one component of how AI use can increase risk. Understanding and managing shadow AI use should be considered as part of a broader, comprehensive risk management strategy that aims to secure AI systems, including human and agent identities, interactions, human-AI partnerships, and behaviors operating across the digital enterprise from visibility and governance through detection, response, and recovery.  

Effective risk management calls for a layered and interdisciplinary strategy. It requires addressing issues across governance and visibility; identity, access and agent control, data security and privacy, secure MLOps / LLMOps, runtime security, behavior-based detection, autonomous response and recovery.  

This blog explores a specific governance and visibility use case linked to shadow AI and reveals the challenges it presents as well as the defensive strategies that security teams can adopt.

Why shadow AI is hard to detect  

When it comes to AI, what organizations can easily see does not always reflect the full scope of AI activity occurring within the tools, applications, and workflows used across an enterprise. As a result, organizations using traditional rule-based methods to flag unusual activity may struggle to distinguish unsanctioned AI usage from legitimate operational behavior, particularly as SaaS applications, APIs, and orchestration layers increasingly have AI embedded into normal business workflows. Identifying threats using previously observed intelligence or depending on hard to maintain allow and block lists does not provide a dynamic enough strategy to manage risk. Also, many organizations are focusing on identifying Shadow AI in their governed infrastructure, like gateways, endpoints, or SASE, which is foundational. But, organizations require visibility and Shadow AI detection across all networked infrastructure from on-prem, hybrid, data centers, and cloud infrastructure that may not have endpoint agent visibility. This uncovers the utilization of MCP, data flows, and autonomous agents across these domains.

For example, employees interact with AI assistants across approved SaaS platforms every day. However, browser extensions and other types of plug-ins can route prompts that include enterprise data to embedded AI services in ways that are not visible to the security team. AI enabled workflows may invoke multiple APIs, orchestration layers, and cloud services behind the scenes, making it difficult for traditional security tooling to determine where data is processed, stored, or retransmitted. Because much of this activity occurs within trusted browser sessions and encrypted SaaS traffic, conventional network monitoring, DLP, and application allowlisting controls often lack the context needed to accurately identify or govern these interactions

Identifying AI tools in the environment is one part of the equation. Understanding the behavior surrounding their use is where the real challenge lies. An AI application is not inherently risky, but the way users or other assets interact with it may be. Sensitive data exposure, abnormal access patterns, and misuse of AI-assisted workflows often appear legitimate in isolation and only become visible through behavioral analysis across the broader environment.  

What Shadow AI visibility does and doesn’t show

Comprehensive Shadow AI visibility allows organizations to answer several important questions:

  • What types of AI are we using? What AI platforms, agents, MCP clients/servers, and services are active across the enterprise?  
  • Who is using AI services? Which users, business units, or systems are interacting with those AI services?  
  • Is our data safe? Is sensitive or regulated data being exposed through prompts, workflows, or integrations?  
  • Are AI systems behaving as expected? Are AI systems behaving anomalously or operating outside approved governance processes?  
  • Are our AI systems under attack? Is an attacker attempting to manipulate prompts, influence agent behavior, or abuse AI-enabled workflows?

Answering these questions is foundational to broader AI governance efforts. However, it is limited to helping teams understand initial interactions and fails to offer insight into dependencies and outcomes that are critical to securing AI across an enterprise.  

Deeper visibility that includes the ability to understand dependencies and outcomes are not always available in AI security point products. Answering the questions below requires understanding runtime behavior and operational outcomes:  

  • What actions did the AI interaction trigger?  
  • What systems, applications, or data did it access? Did the AI operate beyond its intended permissions or scope?  
  • Could a low-risk interaction lead to high-risk outcomes?  
  • What is the risk and context understanding of an anomalous activity to assist in prioritization of analysis and autonomous response action?

The distinction between these two sets of questions offers two different layers of AI security. The first set of questions focuses on discovery and interaction visibility. The second set focuses on providing visibility that includes the context and outcomes that are critical for managing follow-on risks associated with obfuscated downstream activities.  

Together, these layers help organizations move beyond simply identifying AI usage toward understanding how AI behaves operationally across the enterprise.

How organizations are addressing shadow AI

Most organizations still approach shadow AI as an application control problem, relying on policies, browser restrictions, and allow/block lists. However, AI adoption is evolving faster than most governance processes can realistically keep pace with. New assistants, plugins, and embedded AI features appear continuously, creating pressure to enable business productivity while simultaneously containing risk.  

Existing governance processes were designed for a more traditional SaaS adoption cycle, where new applications could be reviewed, approved, and monitored over longer time horizons. AI adoption operates differently. New capabilities can appear overnight inside existing platforms employees already use, making it difficult for security and governance teams to maintain an accurate understanding of enterprise AI exposure. This means that many organizations are experiencing significant operational overhead, particularly in large environments where AI usage is decentralized across teams, departments, and third-party services.  

Where should organizations start when securing their AI systems?

Shadow AI identification is an on-going critical component for AI Risk/Governance Boards as well as security organizations. As organizations seek AI certifications like ISO 42001 AI Management Systems, visibility into all AI adoption from enterprise use to custom innovation and development is crucial. Shadow AI identification provides organizations with the visibility needed to decide whether an AI tool should be brought into governed environments to reduce data loss (DLP) risks or whether policies should be established and enforced to restrict their use.

As organizations rapidly innovate and adopt AI, they are taking on more and more risk. Organizations need to have a strategy in place to mitigate the assumed risk, especially with third-party adoption. Visibility, monitoring, governance enforcement, behavioral-based detection of non-deterministic systems, and autonomous investigation and containment becomes critical to mitigating the risk of AI systems.  

How Darktrace secures AI and shadow AI

Attackers are using AI to move faster, scale tactics, and make threats more adaptive and convincing. Internally, organizations are grappling with new forms of risk created by generative AI, autonomous agents, shadow AI, and increasingly complex digital environments.

Darktrace helps organizations protect both people and AI in a world where AI is now central to how business gets done. Darktrace / SECURE AI helps organizations discover and control shadow AI by surfacing unsanctioned or unexpected AI activity where it appears – including MCP detections, distinguishing misuse of legitimate tools and unapproved services, and applying policy to contain data exposure while guiding users toward sanctioned options.

Stay up to date on AI security

Sign up for the Secure AI Readiness Program here: This gives you exclusive access to the latest news on the latest AI threats, updates on emerging approaches shaping AI security, and insights into the latest innovations, including Darktrace’s ongoing work in this area.

Ready to talk with a Darktrace expert on securing AI? Register here to receive practical guidance on the AI risks that matter most to your business, paired with clarity on where to focus first across governance, visibility, risk reduction, and long-term readiness.  

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