Cybersecurity

AI Infrastructure Becomes a High-Value Control Point for Attacks

Microsoft Threat Intelligence identifies three breaches targeting LiteLLM, RAGFlow, and Kestra, demonstrating how attackers can turn AI gateways, retrieval platforms, and workflow engines into hubs for stealing secrets, executing commands, and exploiting computing resources. The company concludes that these components must be secured as critical infrastructure, not isolated applications.

2026-08-26
6 min read
9 views
فريق تحرير certi.news
AI Infrastructure Becomes a High-Value Control Point for Attacks

Microsoft Threat Intelligence provides a broad analysis of attacks targeting three environments associated with operating AI: the LiteLLM gateway, the RAGFlow platform for document processing and retrieval-augmented generation, and the Kestra environment for workflow orchestration. Despite differences in the intrusion paths, the objectives were nearly the same: stealing credentials, establishing persistent access mechanisms, and accessing computing resources for cryptocurrency mining.

The significance of the three cases lies in the fact that the attackers did not treat these tools merely as separate applications. Instead, they targeted them as control points where credentials, model-provider connections, command-execution capabilities, and access to databases or containers converge. According to Microsoft, this focus makes AI gateways and management and orchestration platforms high-value targets within enterprise environments.

Three Intrusion Paths, One Pattern of Outcomes

In the LiteLLM case, Microsoft assesses with high confidence that initial access occurred by exploiting an exposed gateway interface. The report points to public vulnerability paths, including CVE-2026-42271, associated with authenticated command execution in LiteLLM MCP stdio test endpoints, and a research path linking it to CVE-2026-48710, a vulnerability that bypasses host-header validation in Starlette. In affected configurations, this combination could make remote command execution available without valid credentials.

After the breach, the malware read the primary process environment inside the container, including /proc/1/environ, searching for model-provider keys, the LiteLLM master key, database connection strings, passwords, and tokens. Executable files disguised as Linux services were then downloaded, while the host, ports, and processes were inspected and mining based on XMRig or RandomX was prepared. A PostgreSQL connection string was also used to access LiteLLM tables that could contain model configurations, provider keys, and default keys issued by the proxy. Persistence mechanisms included modifying authorized_keys for a service account, changing cron jobs, and using hidden files and disguised service names.

In RAGFlow, the observed activity focused on intercepting language-model credentials that tenants added or modified. Microsoft first observed SSRF-like behavior, followed by command execution within the Flask service context and modification of the application startup path to load a hidden hook. The hook captured the provider type, model name, API key material, and endpoint data, and sent them externally. The report emphasizes that Microsoft cannot identify with high confidence the vulnerability that caused execution; it mentions CVE-2026-45312, CVE-2026-28797, CVE-2026-24770, and CVE-2025-68700 as possible technical context, not as a confirmed cause of this incident.

In Kestra, Microsoft assesses with high confidence that the exploitation was associated with the critical CVE-2026-49869 vulnerability, which could allow authentication bypass, the definition of a malicious workflow using the Process runner, and then the execution of shell commands on the worker. This path was used to access the Docker socket, inspect the container environment, deploy a mining worker, and execute operations to hide files. Workflow tasks were later also used to retrieve remote scripts and execute them directly, then store encrypted output through Kestra’s key-value interface.

What Changes in Practice for Defense Teams?

The most important conclusion is that risk assessments must begin with the role of the AI environment within the organization. The gateway may be a repository for model-provider keys and a database for proxy keys, while a RAG platform may contain tenant configurations, and a workflow engine may have permission to execute commands and interact with external services. Therefore, applying product-specific detection indicators in isolation is not sufficient.

Microsoft recommends treating AI gateways as top-tier secret stores, updating LiteLLM and similar tools, enforcing authentication on API and administrative interfaces, restricting administrative ports, and not exposing them directly to the internet. It also recommends using separate proxy keys for each team with spending limits, storing provider keys in a managed secret store instead of process environment variables, and rotating keys that may have been exposed.

Other controls include applying least privilege to the gateway and database, placing the database behind a private endpoint and a restricted firewall, and enforcing network egress rules that deny connections by default and allow only required destinations. Teams should monitor access to /proc/1/environ, the execution of shell, Python, or download tools by a gateway process, modifications to cron or SSH files, use of the Docker socket, and execution from writable temporary paths.

Limits of Inference and Review Questions

The three cases do not establish that every LiteLLM, RAGFlow, or Kestra deployment is exposed in the same way. Microsoft also clearly distinguishes between confirmed vulnerabilities in some paths and potential vulnerabilities in the RAGFlow case. Likewise, the presence of characteristics in some payloads suggesting the use of helper or generative tools is not evidence of their source or the identity of their developers. Accordingly, these findings should be used to build detection hypotheses and review configurations, not to attribute an attack to a specific actor.

Microsoft provides Advanced hunting queries for detecting behavioral chains, such as a gateway launching interpreters or download tools, reading the primary process’s environment variables, accessing LiteLLM tables, attempting to load the MSR module with writing enabled, and modifying SSH keys or cron. The practical value of these queries emerges when they are linked in a single timeline: a standalone shell process may be administrative, but combining it with secret access, an external connection, and execution of a file from a temporary path substantially raises the level of suspicion.

News source
Microsoft Security Blog
Open original source ↗
ف
Author

فريق تحرير certi.news

In the same category

You may also like

View all news