When AI Infrastructure Becomes the Target: Attacks Observed on LiteLLM, RAGFlow, and Kestra

1. Basic Information

• Article Title: When AI infrastructure becomes the target: Securing gateways and control points
• Publisher: Microsoft Security Research
• Publication Date: 2026-08-26
• Source: Microsoft Security Research
• Related Sources: CVE-2026-42271, CVE-2026-48710, CVE-2026-49869
• Related Malware, Threat Groups, CVEs, and Products: XMRig, CVE-2026-42271, CVE-2026-48710, CVE-2026-49869, CVE-2026-45312, CVE-2026-28797, CVE-2026-24770, CVE-2025-68700, LiteLLM, RAGFlow, Kestra, Azure Database for PostgreSQL, Docker
• Severity: High

2. Executive Summary

AI gateways, RAG systems, and workflow platforms—which act as central control points holding model keys, database credentials, and container permissions—were compromised and abused for credential theft, persistence, and cryptomining.

3. Attack Flow

LiteLLM Compromise

1. Command execution is achieved through an externally exposed LiteLLM gateway. Microsoft evaluates this as consistent with a chain of CVE-2026-42271 and CVE-2026-48710, though it is not definitively confirmed.
2. The attacker reads /proc/1/environ, which holds the environment variables of the PID 1 process inside the container, to gather model provider API keys, master keys, and DATABASE_URL.
3. Python, curl, and wget are used as alternatives to place an ELF binary in /tmp and execute it with a service-like name.
4. An XMRig-based miner is deployed, and competing miners are removed.
5. The attacker connects to the LiteLLM PostgreSQL database using the retrieved DATABASE_URL to harvest and exfiltrate model configurations and virtual keys.
6. Persistence is established using the service account's authorized_keys, cron, hidden files, and immutable attributes.

RAGFlow Compromise

1. An OAST callback originates from the HTTP client of the RAGFlow application itself, and code execution is observed within the same service context a few days later.
2. The attacker places a hidden Python hook under the application path to alter startup and import routes.
3. The TenantLLM configuration handling is wrapped to steal API keys and model information for LLM providers registered after infection.
4. Microsoft does not confirm the specific CVE that caused the initial breach, even with low confidence.

Kestra Compromise

1. Microsoft assesses the authentication bypass vulnerability CVE-2026-49869 as a high-confidence initial vector.
2. A worker spawns a shell from a malicious workflow.
3. The Config.Env of other containers is enumerated via a mounted Docker socket to harvest potential cloud keys, database passwords, and API tokens.
4. XMRig is deployed, and subsequent script outputs are stored in the Kestra KV API.

4. Threat Actor Position and Execution Location

• External attackers targeting internet-accessible AI management planes and APIs.
• Operating within the application and worker execution contexts of LiteLLM, RAGFlow, and Kestra after compromise.

5. Visibility for Victims and Administrators

Victims

• Regular AI users have difficulty noticing the compromise. In RAGFlow, configuration operations continue normally while new API keys are being stolen.

Administrators

• Observable indicators include the launch of shells, Python, curl, and wget under AI service processes, execution from /tmp, access to the Docker socket, and outbound traffic following API key registration.
• CPU load from cryptomining and modifications to authorized_keys, cron, or application startup files may also be visible.

6. Success and Failure Conditions

Success Conditions

• Attackers can reach vulnerable or improperly exposed AI management planes.
• AI services have access to model keys, database connection strings, virtual keys, and environment variables of other containers.
• Outbound communication from service containers, execution in /tmp, and the use of Docker sockets are not sufficiently restricted.

Failure Conditions & Risk Mitigation

• AI management planes are kept private, with authentication, patching, and source IP restrictions applied.
• API keys are not constantly held in the process environment, utilizing dedicated secret stores and the principle of least privilege instead.
• Outbound traffic is denied by default, temporary directories are configured with noexec, and Docker sockets are not mounted to block subsequent activities.

7. What Happens Upon Success

• Theft of model provider API keys, LiteLLM master keys, virtual keys, and database credentials.
• Persistent access to the AI infrastructure and other containers.
• Unauthorized use of computing resources for cryptomining.
• Continuous theft of newly registered LLM credentials in RAGFlow after infection.

8. Observable Logs

• Email: Not directly related.
• Proxy/SWG/DNS: External access to AI management planes; communications to OAST, C2, raw IPs, and mining pools. Correlating communications to sslip.io, OAST domains, and non-standard ports with asset context.
• Endpoint/EDR: Bash, sh, python, curl, or wget spawned by AI service parent processes; references to /proc/1/environ, execution from /tmp, chmod, chattr, and modifications to authorized_keys, cron, or RAGFlow startup files; Docker socket enumeration, XMRig deployment, and MSR module loading.
• Identity/IdP: Subsequent use of stolen model keys, virtual keys, and service principals.
• SaaS/Cloud: Abnormal usage and billing of model provider APIs, unusual connections to Azure PostgreSQL, and Kestra workflow/KV operations.
• Network: Outbound connections from AI services to raw IPs, OAST, C2, and Monero pools.

9. Attack Success Determination

• Attack Attempt Observed (Success Unconfirmed): Scanning of the AI management plane, SSRF-like OAST callbacks, or vulnerability payloads confirmed, but no child processes or access to secrets observed.
• Initial Execution Confirmed: Shells or Python spawned with AI services/workers as parent processes, or execution originating from malicious workflows.
• Information Theft or Session Compromise Confirmed: Collection and external exfiltration of /proc/1/environ, LiteLLM database, RAGFlow LLM configurations, and Docker Config.Env.
• Subsequent Compromise Confirmed: Persistence via authorized_keys, cron, or application hooks; XMRig execution; or discovery of secrets in other containers.

10. Investigation Playbook

• Trigger: Shell/interpreter spawned from AI service parent processes, access to /proc/1/environ or Docker sockets, or detection of vulnerability exploitation against management planes.
• Initial Verification: Check target products, versions, exposure status, and authentication settings. Align parent-child processes, container IDs, workflow/API audits, and outbound communications on the same timeline.
• Endpoints: Inspect /tmp, authorized_keys, cron, immutable attributes, RAGFlow startup and import paths, and XMRig artifacts.
• Authentication/Cloud: Check usage history of model provider keys, LiteLLM virtual keys, database connection info, and service principals; revoke exposed candidates.
• Subsequent Operations: Investigate unauthorized use of other containers enumerated via Docker sockets, databases, and model provider sides.
• Containment: Isolate and patch the management plane, and recreate containers from trusted images. Rotate potentially exposed keys, tokens, and database credentials, and restrict outbound traffic.
• Judgment Categories: Separate into scanning only, app-origin execution, access to secrets, external exfiltration, and persistence/resource abuse.

11. Defense and Detection Ideas

• Single Event: Prioritize events where shells, downloaders, or interpreters are spawned by AI service parent processes and reference /proc/1/environ, DATABASE_URL, or LiteLLM table names.
• Timeline Correlation: Correlate management plane access -> app-origin shell execution -> access to secrets -> outbound communication -> persistence/miner execution as a series of events on the same container and host.
• Hunting: Inventory external exposure of AI gateways, RAG, and workflow platforms, Docker socket mounting, and secrets held within process environments.
• Lack of Logs: Assessing success is difficult without process lineage within containers, file modifications, outbound DNS/HTTP traffic, workflow audits, and model provider API audits.
• Priority Mitigations: Make management planes private and apply rapid patches. Use managed secret stores, team-specific virtual keys, and least-privilege databases. Implement default-deny outbound traffic, unexposed Docker sockets, and temporary directories with noexec.

12. Facts / Inference / Hypothesis

Facts

• Microsoft observed compromise activities across LiteLLM, RAGFlow, and Kestra environments, including credential theft, persistence, and resource abuse.
• In LiteLLM, /proc/1/environ and PostgreSQL model configuration/virtual key tables were collected.
• In RAGFlow, hooks were placed in TenantLLM configuration handling to collect API keys registered post-infection.
• In Kestra, workflow-origin shell execution, enumeration of Config.Env via Docker sockets, and XMRig deployment were observed.

Inference

• AI infrastructure must be treated as Tier-0 equivalent control planes where secrets, execution privileges, and data connections concentrate, rather than simple applications.
• Relationships between execution from AI service parent processes, access to secrets, and outbound communications serve as long-term effective detection axes, beyond product-specific IOCs.

Hypothesis

• Orderly exception handling and fallback mechanisms align with AI-assisted development, but Microsoft does not present them as evidence of specific authors or development methods.

13. MITRE ATT&CK Mapping

• T1190 Exploit Public-Facing Application (High): Management planes of externally exposed AI workloads serve as initial entry points. Confidence in individual CVEs varies by product.
• T1552.001 Unsecured Credentials: Credentials In Files (High): Searching for secrets from process environment variables, database configurations, and container environment variables.
• T1059.004 Command and Scripting Interpreter: Unix Shell (High): Gateway/workflow-origin shell execution observed.
• T1098.004 Account Manipulation: SSH Authorized Keys (High): Modifications to authorized_keys for LiteLLM service accounts observed.
• T1496 Resource Hijacking (High): XMRig/RandomX-based cryptomining observed.

14. Unknowns / Further Investigation

• Specific CVEs used for initial entry in LiteLLM and RAGFlow have not been definitively identified.
• The number of victim organizations, threat actor attributes, and the scope of subsequent use of stolen keys are not publicly disclosed.

15. Impact and Considerations for Global Enterprises and SOCs

As the external exposure of proof-of-concept and internal AI infrastructures increases globally, organizations should avoid treating LiteLLM and similar tools with lower priority than standard web applications. SOCs should monitor parent-child processes, access to secrets, container boundaries, and key usage on model provider sides as a single unified attack chain.

16. Summary by Target Audience

• For SOCs: Correlate shell launches from AI service parent processes, /proc/1/environ reads, Docker socket usage, outbound communications, and persistence; track up to unauthorized model key usage.
• For Administrators: Make management planes private and patched; apply secret stores, least-privilege databases, outbound traffic controls, and Docker socket isolation.
• For Users: The underlying infrastructure can be compromised and registered API keys stolen even without direct actions by AI service users.