Compromised AI Gateway Highlights Growing Risk To Enterprise AI Infrastructure

A compromised AI gateway connected to Amazon Web Services cloud infrastructure has underscored the emerging security risks organisations face as they deploy generative AI into production environments.

Cybersecurity firm Darktrace has published research detailing an incident in which an attacker gained access to an AWS EC2 instance running LiteLLM, an open-source AI gateway, and used it to conduct unauthorised cryptomining.

The attack itself was not particularly novel. An externally exposed SSH service with port 22 open to the internet was targeted with brute-force login attempts, predominantly from a single external IP address. What made the incident notable was the nature of the system that was compromised.

AI gateways such as LiteLLM sit between users, applications and foundation models. They handle authentication, routing, logging and policy enforcement for AI services across an organisation. They also serve as the centralised point through which employees access AI tools, with the gateway directing usage to the most appropriate model based on factors like cost and complexity.

For IT teams, gateways help regulate and manage AI usage by limiting tokens and controlling model access.

A Single Point With Broad Permissions

Because of that role, AI gateways aggregate cloud permissions, model access and application workflows into a single control point. A compromise of such a system can have implications well beyond the affected host.

In this case, the compromised instance was associated with an IAM role that had access to Amazon Bedrock resources. A more capable attacker, interested in more than cryptomining, could have used that access to reach API keys for connected AI systems and cloud services, enabling far more damaging activity.

Darktrace’s research noted that while no evidence was found linking this specific incident to publicly disclosed LiteLLM vulnerabilities, it demonstrates why organisations should treat AI infrastructure as part of their critical attack surface rather than as a standalone application tier.

How The Attack Unfolded

Prior to the cryptomining activity, Darktrace observed a large volume of inbound connection attempts to the LiteLLM-Proxy EC2 instance over port 22 from external IP addresses. Many of these connections were short-lived, lasting only a few seconds, indicating scanning or failed login attempts.

The available telemetry did not confirm whether any inbound SSH connection resulted in successful authentication, preventing the activity from being confirmed as the definitive initial access vector. However, the combination of public SSH exposure, external inbound connections and subsequent miner activity pointed to SSH as the likely access path.

Before the first observed connection to a mining pool, the EC2 instance downloaded 3.42 MB of data over an HTTP connection to an external endpoint that appeared to host a ZIP file containing XMRig cryptomining malware.

Minutes later, Darktrace observed the instance connecting to the hostname pool.hasvault[.]pro over HTTPS on port 443. Repeated outbound connectivity to the same hostname followed – a pattern consistent with active cryptomining pool communication, where a compromised host receives work and submits results.

Detection And Escalation

The activity triggered Darktrace’s Enhanced Monitoring model for high-priority cryptocurrency mining and was escalated to the customer by the company’s Security Operations Centre.

Darktrace’s Cyber AI Analyst grouped the relevant events into a single investigation narrative, helping identify the repeated mining pool connectivity from the affected cloud asset.

The use of HTTPS over port 443 was significant because, when viewed in isolation, the traffic would not appear inherently suspicious. In this instance, the destination, volume of connections and lack of similar prior activity provided the behavioural context needed to flag the communication.

Suspicious Identity Activity Followed

The following day, Darktrace observed suspicious activity from a separate IAM user account that may point to a broader compromise.

The user was observed attempting a “GetSendQuota” event – an action the account had not performed within at least the previous three months. The source IP address for this command was geolocated in Vietnam, whereas activity for the user had mostly originated from Amazon IP addresses. The AWS CLI was also being used, which was unusual for that account.

Failed “InvokeModel” and “ListFoundationModels” commands were detected, suggesting attempted interaction with Amazon Bedrock services including model enumeration or invocation. An attempted “CreateUser” command was also flagged, with the requested username appearing to be low-meaning, potentially indicating an effort to establish persistence by creating a new account.

While the IAM activity may suggest a connection to the LiteLLM compromise observed the previous day, Darktrace noted there was insufficient evidence to conclusively link the two events.

A Broader Warning For AI Deployments

Even without a confirmed link between the two incidents, the IAM activity remains significant. It demonstrates the importance of incorporating both workload telemetry and control-plane telemetry into cloud compromise investigations.

The cryptomining activity indicated compute resource abuse, but the IAM activity suggested potential credential compromise or misuse involving long-term access keys, along with attempted cloud service abuse.

Darktrace’s researchers argued that as organisations deploy AI capabilities into production, these platforms are becoming part of the same attack surface that adversaries already target through exposed services, credential theft and cloud misconfigurations.

The firm’s analysis concluded that AI infrastructure must be secured as part of the wider cloud environment rather than treated as a separate technology stack. As AI gateways increasingly concentrate cloud permissions, model access and application workflows, defenders will need to focus less on individual alerts and more on understanding how behaviours connect across workloads, identities and services.

The incident serves as a reminder that even when the visible impact of a compromise is something as familiar as cryptomining, the underlying risk may be far greater depending on the role of the compromised asset within the organisation’s infrastructure.

Last Updated on July 10, 2026 by Nick Ross