17 techniques observed across 2 entries, derived from entry metadata and body evidence, never asserted without a published entry behind it · pinned to MITRE ATT&CK v19.2 · compare on the matrix · Navigator layer (JSON)
Initial Access TA0001
T1190Exploit Public-Facing Application×2
Adversaries may attempt to exploit a weakness in an Internet-facing host or system to initially access a network. The weakness in the system can be a software bug, a temporary glitch, or a misconfiguration.
Adversaries may abuse the <code>cron</code> utility to perform task scheduling for initial or recurring execution of malicious code. The <code>cron</code> utility is a time-based job scheduler for Unix-like operating systems. The <code> crontab</code> file contains the schedule of cron entries to be run and the specified times for execution. Any <code>crontab</code> files are stored in operating system-specific file paths.
T1059.004Command and Scripting Interpreter: Unix Shell×1
Adversaries may abuse Unix shell commands and scripts for execution. Unix shells are the primary command prompt on Linux, macOS, and ESXi systems, though many variations of the Unix shell exist (e.g. sh, ash, bash, zsh, etc.) depending on the specific OS or distribution. Unix shells can control every aspect of a system, with certain commands requiring elevated privileges.
T1059.006Command and Scripting Interpreter: Python×1
Adversaries may abuse Python commands and scripts for execution. Python is a very popular scripting/programming language, with capabilities to perform many functions. Python can be executed interactively from the command-line (via the <code>python.exe</code> interpreter) or via scripts (.py) that can be written and distributed to different systems. Python code can also be compiled into binary executables.
Adversaries may abuse the <code>cron</code> utility to perform task scheduling for initial or recurring execution of malicious code. The <code>cron</code> utility is a time-based job scheduler for Unix-like operating systems. The <code> crontab</code> file contains the schedule of cron entries to be run and the specified times for execution. Any <code>crontab</code> files are stored in operating system-specific file paths.
Adversaries may modify the SSH <code>authorized_keys</code> file to maintain persistence on a victim host. Linux distributions, macOS, and ESXi hypervisors commonly use key-based authentication to secure the authentication process of SSH sessions for remote management. The <code>authorized_keys</code> file in SSH specifies the SSH keys that can be used for logging into the user account for which the file is configured. This file is usually found in the user's home directory under <code><user-home>/.ssh/authorized_keys</code> (or, on ESXi, `/etc/ssh/keys-<username>/authorized_keys`). Users may edit the system’s SSH config file to modify the directives `PubkeyAuthentication` and `RSAAuthentication` to the value `yes` to ensure public key and RSA authentication are enabled, as well as modify the directive `PermitRootLogin` to the value `yes` to enable root authentication via SSH. The SSH config file is usually located under <code>/etc/ssh/sshd_config</code>.
Adversaries may abuse legitimate extensible development features of servers to establish persistent access to systems. Enterprise server applications may include features that allow developers to write and install software or scripts to extend the functionality of the main application. Adversaries may install malicious components to extend and abuse server applications.
Adversaries may abuse the <code>cron</code> utility to perform task scheduling for initial or recurring execution of malicious code. The <code>cron</code> utility is a time-based job scheduler for Unix-like operating systems. The <code> crontab</code> file contains the schedule of cron entries to be run and the specified times for execution. Any <code>crontab</code> files are stored in operating system-specific file paths.
Adversaries may modify the SSH <code>authorized_keys</code> file to maintain persistence on a victim host. Linux distributions, macOS, and ESXi hypervisors commonly use key-based authentication to secure the authentication process of SSH sessions for remote management. The <code>authorized_keys</code> file in SSH specifies the SSH keys that can be used for logging into the user account for which the file is configured. This file is usually found in the user's home directory under <code><user-home>/.ssh/authorized_keys</code> (or, on ESXi, `/etc/ssh/keys-<username>/authorized_keys`). Users may edit the system’s SSH config file to modify the directives `PubkeyAuthentication` and `RSAAuthentication` to the value `yes` to ensure public key and RSA authentication are enabled, as well as modify the directive `PermitRootLogin` to the value `yes` to enable root authentication via SSH. The SSH config file is usually located under <code>/etc/ssh/sshd_config</code>.
T1036.005Masquerading: Match Legitimate Resource Name or Location×1
Adversaries may match or approximate the name or location of legitimate files, Registry keys, or other resources when naming/placing them. This is done for the sake of evading defenses and observation.
T1564.001Hide Artifacts: Hidden Files and Directories×1
Adversaries may set files and directories to be hidden to evade detection mechanisms. To prevent normal users from accidentally changing special files on a system, most operating systems have the concept of a ‘hidden’ file. These files don’t show up when a user browses the file system with a GUI or when using normal commands on the command line. Users must explicitly ask to show the hidden files either via a series of Graphical User Interface (GUI) prompts or with command line switches (<code>dir /a</code> for Windows and <code>ls –a</code> for Linux and macOS).
T1222.002File and Directory Permissions Modification: Linux and Mac Permissions×1
Adversaries may modify file or directory permissions/attributes to evade access control lists (ACLs) and access protected files. File and directory permissions are commonly managed by ACLs configured by the file or directory owner, or users with the appropriate permissions. File and directory ACL implementations vary by platform, but generally explicitly designate which users or groups can perform which actions (read, write, execute, etc.).
T1552.001Unsecured Credentials: Credentials In Files×1
Adversaries may search local file systems and remote file shares for files containing insecurely stored credentials. These can be files created by users to store their own credentials, shared credential stores for a group of individuals, configuration files containing passwords for a system or service, or source code/binary files containing embedded passwords.
Adversaries may attempt to get information about running processes on a system. Information obtained could be used to gain an understanding of common software/applications running on systems within the network. Administrator or otherwise elevated access may provide better process details. Adversaries may use the information from Process Discovery during automated discovery to shape follow-on behaviors, including whether or not the adversary fully infects the target and/or attempts specific actions.
Adversaries may attempt to get a listing of software and software versions that are installed on a system or in a cloud environment. Adversaries may use the information from Software Discovery during automated discovery to shape follow-on behaviors, including whether or not the adversary fully infects the target and/or attempts specific actions.
Adversaries may use stolen application access tokens to bypass the typical authentication process and access restricted accounts, information, or services on remote systems. These tokens are typically stolen from users or services and used in lieu of login credentials.
T1071.001Application Layer Protocol: Web Protocols×1
Adversaries may communicate using application layer protocols associated with web traffic to avoid detection/network filtering by blending in with existing traffic. Commands to the remote system, and often the results of those commands, will be embedded within the protocol traffic between the client and server.
Adversaries may use an OSI non-application layer protocol for communication between host and C2 server or among infected hosts within a network. The list of possible protocols is extensive. Specific examples include use of network layer protocols, such as the Internet Control Message Protocol (ICMP), transport layer protocols, such as the User Datagram Protocol (UDP), session layer protocols, such as Socket Secure (SOCKS), as well as redirected/tunneled protocols, such as Serial over LAN (SOL).
Adversaries may transfer tools or other files from an external system into a compromised environment. Tools or files may be copied from an external adversary-controlled system to the victim network through the command and control channel or through alternate protocols such as ftp. Once present, adversaries may also transfer/spread tools between victim devices within a compromised environment (i.e. Lateral Tool Transfer).
Adversaries may leverage the resources of co-opted systems to complete resource-intensive tasks, which may impact system and/or hosted service availability.
deep-diveThree unrelated AI platforms, three intrusions, one pattern: gateways and orchestrators concentrate the credentials and execution privilege attackers want
Where this entity is cited
deep-dive1
trending-vulnerabilities1
Source distribution
github.com2 (33%)
cisa.gov1 (17%)
microsoft.com1 (17%)
osv.dev1 (17%)
vulnerability.circl.lu1 (17%)
Co-occurring entities
Derived: referenced by the same focused operational entries (weekly summaries and report roundups don't count); ×N counts the shared entries.
LiteLLM is a widely deployed proxy/gateway that lets an organisation front many LLM providers behind one API and,
via the Model Context Protocol (MCP), let connected AI agents call external tools through it. Its MCP Streamable
HTTP endpoint supports an OAuth2-passthrough mode for upstream MCP servers; the flaw sits in what happens when the
gateway's own key check fails. Instead of rejecting the request, the fallback path replaces the failed validation
with an empty UserAPIKeyAuth() object, which the rest of the request pipeline treats as a legitimately authenticated
session (BerriAI, via OSV.dev). An attacker who sends any
fabricated Authorization: Bearer value (no valid LiteLLM key required) therefore establishes a working MCP
session and can list and invoke every MCP tool and connected service the gateway exposes
(BerriAI, via OSV.dev). CISA's KEV addition on 2026-09-02
confirms this is under active exploitation, not merely disclosed
(CISA Known Exploited Vulnerabilities catalog, 2026-09-02).
Fixed in 1.84.0; where an immediate upgrade is not possible, BerriAI's own guidance is to block /mcp/ and related
MCP endpoints at the reverse proxy or API gateway in front of LiteLLM
(BerriAI, via OSV.dev).
This is a distinct code path from two other recently covered LiteLLM/MCP-surface flaws: CVE-2026-42271
was a command injection through MCP stdio test endpoints, chained with the Starlette host-header bypass
CVE-2026-48710 in a real production intrusion Microsoft documented in August. CVE-2026-59822 hits the Streamable
HTTP transport's OAuth2 fallback logic instead, a different mechanism on the same class of MCP-facing attack
surface, not a re-run of the earlier bug.
Triage: an MCP session that never completed a valid key check but is nonetheless treated as authenticated is the
tell; any environment logging MCP-gateway auth decisions should flag sessions where the presented Bearer token does
not match an issued LiteLLM key yet the request pipeline proceeds past the auth stage.
LiteLLM's MCP Streamable HTTP endpoint could allow an unauthenticated attacker to establish an authenticated MCP session using an arbitrary Bearer token. The MCP auth handler supported OAuth2 passthrough for upstream MCP servers, but the fallback path could replace failed LiteLLM key validation with an empty UserAPIKeyAuth() object. This allowed requests with a fabricated Authorization header to reach MCP tooling without a valid LiteLLM key.
If upgrading is not immediately possible, disable MCP routes or block access to /mcp/ and related MCP endpoints at your reverse proxy or API gateway.
AI gateways, retrieval platforms and workflow orchestrators have become a new layer of enterprise infrastructure sitting between users, applications, data and models, and that position concentrates credentials, data access and execution privilege in one runtime. Microsoft Threat Intelligence confirms three separate real-world intrusions exploiting exactly that concentration: a LiteLLM gateway, a RAGFlow retrieval-augmented-generation deployment, and a Kestra workflow orchestration environment. The initial-access paths differed by product, and credential theft and durable persistence recur across all three, but resource monetisation was specific to two of them: Microsoft states the LiteLLM and Kestra objectives each included compute monetisation, while the RAGFlow intrusion's objective was narrower, intercepting newly configured LLM provider credentials and model metadata, with no miner deployment observed (Microsoft Threat Intelligence, 2026-08-26). The June 2026 disclosure of the LiteLLM chain itself is already tracked in this store; what is new here is confirmation that the chain reached real production environments, alongside two further distinct AI-workload intrusions with no vulnerability overlap.
Case 1: LiteLLM gateway, credential harvesting to database exfiltration to cryptomining
Microsoft assesses with high confidence that initial access exploited the exposed LiteLLM gateway surface via CVE-2026-42271 (CVSS 8.7, affecting LiteLLM >= 1.74.2 and < 1.83.7, fixed in 1.83.7, BerriAI GHSA-v4p8-mg3p-g94g), a command-execution flaw in LiteLLM's MCP stdio test endpoints, chained with CVE-2026-48710 (CVSS 6.5, affecting Starlette <= 1.0.0, fixed in 1.0.1, Starlette GHSA-86qp-5c8j-p5mr), a host-header validation bypass that can strip the authentication requirement in vulnerable configurations, the combination yields unauthenticated remote code execution in the gateway process itself. From that foothold, the observed chain ran six stages. First, the payload read /proc/1/environ (the environment block of the gateway's PID-1 process in its container) filtering for provider API keys, the LiteLLM master key, database connection strings and other credential-shaped values, and exfiltrated them using whichever of Python's urllib, curl or wget was available. Second, a masqueraded ELF binary was retrieved and launched with Linux-service-style arguments; a parallel shell-based delivery path provided redundancy. Third, the payload fingerprinted the host, checked for passwordless sudo, and swept for competing miners or remote-access tooling. Fourth, it loaded the Linux MSR kernel module with write access (RandomX/XMRig CPU-tuning behaviour) and rewrote crontab entries to remove rival miners before installing its own. Fifth, using the harvested DATABASE_URL, it connected directly to the LiteLLM-backed Azure Database for PostgreSQL instance and dumped the LiteLLM_ProxyModelTable and LiteLLM_VerificationToken tables (model configuration, upstream provider keys and proxy-issued virtual keys) base64-encoding and exfiltrating the output in chunks to an out-of-band endpoint. Sixth, it established durable access via an SSH key written to a service account, immutable-flag protection on its payload directories, and periodic callbacks confirming continued execution.
Case 2: RAGFlow, a persistent hook inside the application itself
Microsoft assesses with high confidence that the RAGFlow intrusion also began with exploitation of the exposed application surface, but states explicitly it has only low confidence in which specific vulnerability enabled the resulting code execution; telemetry could not isolate the precise execution sink from inside the RAGFlow Flask service process. Several publicly documented RAGFlow vulnerabilities provide plausible technical context without being confirmed as the cause. What followed exploitation was distinctive: the payload located the RAGFlow install from inside the container, identified the tenant LLM configuration code path, and modified the application's own startup/import sequence so a hidden hook would load every time the service started, persistence implemented as a backdoored application component rather than a separate process, surviving container restarts as long as the modified filesystem state remains. The hook then wrapped the tenant LLM configuration flow itself, capturing provider type, model name, API key material and endpoint metadata every time a user configured a new LLM connection from that point forward, and exfiltrated it over outbound HTTP with errors suppressed so the application kept functioning normally. Unlike the LiteLLM case, Microsoft observed no miner deployment or interactive shell here; the objective was narrowly future-credential interception.
Case 3: Kestra, workflow execution as the shell-access primitive
Microsoft assesses with high confidence that the Kestra intrusion exploited CVE-2026-49869 (CVSS 10.0 Critical, affecting Kestra prior to 1.0.45 and 1.3.21, fixed in those releases, Kestra GHSA-5vc5-wxxq-3fjx via the CVE Program), a pre-authentication bypass that lets an unauthenticated, network-reachable attacker skip the login mechanism entirely, define a malicious workflow using Kestra's Process runner, and trigger shell-script execution on a worker node. Two closely timed workflow-origin shell sessions followed: the first performed shell initialisation, the second executed the main follow-on actions. Because the worker had access to the mounted Docker socket, the attacker queried container metadata and enumerated the Config.Env arrays of every other container reachable through that socket, a single compromised orchestration worker exposing the environment-embedded cloud keys, database passwords and API tokens of unrelated containers on the same host. A cryptominer (XMRig, RandomX-tuned) was then deployed, and a later workflow-origin event retrieved and executed a remote script via a curl-pipe-shell pattern with no file ever written to disk, storing its output through Kestra's own key-value interface rather than a standalone file.
The pattern that matters more than any single product
Initial access differed (command execution from a gateway process, SSRF-then-RCE against a web application, and workflow-engine authentication bypass) but credential collection and durable access converged in all three; resource monetisation converged in two of the three (LiteLLM's cryptomining, Kestra's XMRig deployment on the compromised worker), while the RAGFlow intrusion pursued only future-credential interception with no miner or interactive shell observed (Microsoft Threat Intelligence, 2026-08-26). Microsoft's own framing is the operational takeaway: these platforms should be monitored according to their control-plane role, not as isolated applications, because a gateway, retrieval or orchestration service can concentrate credentials, database access, workflow execution and container privileges in one runtime. Correlating an unexpected shell or interpreter spawned from an AI-workload process with subsequent secret access, application-file modification, Docker-socket use, outbound callbacks and resource-hijacking activity exposes this class of attack earlier than any single product-specific indicator (Microsoft Threat Intelligence, 2026-08-26).
Microsoft assesses with high confidence that initial access likely occurred through exploitation of the exposed LiteLLM gateway surface. Relevant public vulnerability paths include CVE-2026-42271, an authenticated command-execution issue in LiteLLM MCP stdio test endpoints, and the route described in public research that chains this flaw with CVE-2026-48710, a Starlette host-header validation bypass, to achieve unauthenticated remote code execution in vulnerable exposed deployments.
Telemetry showed the payload reading /proc/1/environ, filtering for keywords such as master, API key, token, password, and UI-related fields, then sending collected values to attacker-controlled infrastructure.
Microsoft assesses with high confidence that initial access likely occurred through exploitation of CVE-2026-49869, a critical authentication-bypass vulnerability in Kestra. Exploitation could allow an unauthenticated remote attacker with network access to bypass the login mechanism, define a malicious workflow using the Process runner, and trigger worker-side shell-script execution.