The 8-Minute Admin: How AI-Powered “LLMjacking” Crushed AWS Defenses in Record Time

An adversary successfully infiltrated an Amazon Web Services cloud environment, escalating to full administrative privileges in a mere ten minutes. According to threat researchers, this rapid incursion was catalyzed by artificial intelligence, which facilitated nearly every phase of the breach.

The Sysdig Threat Research Team documented the incident on November 28, noting not only the unprecedented velocity of the assault but also pervasive hallmarks of automation. Analysts concluded that the perpetrator weaponized Large Language Models (LLMs) for reconnaissance, privilege escalation, lateral movement, and the generation of deleterious code. Furthermore, an instance of “LLM hijacking” was observed, wherein the compromised account was utilized to access cloud-based models and their associated computational resources.

The investigation revealed that the antagonist secured administrative dominion in less than ten minutes, compromising 19 cloud identities while exploiting generative model services and GPU clusters. The malicious code contained Serbian-language comments, fictitious account identifiers, and references to non-existent source code repositories—discrepancies that strongly imply the code was synthesized by AI.

The initial point of ingress involved exposed test credentials discovered within public Amazon S3 buckets. These credentials belonged to an Identity and Access Management (IAM) user possessing read and write permissions for cloud functions and restricted access to LLM services. The same repository contained datasets for model fine-tuning, which were subsequently weaponized during the campaign. Specialists emphasize that access keys must never reside in public repositories; temporary credentials offer a more robust security posture than persistent ones, and the latter, if necessary, must be rotated with rigorous frequency.

Initially, the intruder attempted to garner elevated privileges through common administrative aliases, albeit unsuccessfully. Subsequently, they executed a code injection within a cloud function, exploiting permissions to modify code and configurations. The function’s logic was rewritten iteratively in an attempt to assume a privileged identity, culminating in the compromise of a full administrative account.

The malicious script systematically enumerated users and access keys, generated new credentials, and scrutinized the contents of various storage buckets. The presence of sophisticated error handling and extended execution timeouts further corroborated the use of a generative model. The latency between credential theft and function invocation was remarkably brief.

As the assault progressed, the attacker harvested account identifiers and attempted to assume roles across all discovered environments. This phase included the appearance of extraneous identifiers containing placeholder digits—a signature characteristic of AI “hallucinations,” wherein a model generates plausible but factually erroneous data.

Upon attaining expansive access, the criminal exfiltrated secrets from the Secrets Manager, system configuration parameters, event logs, source code, and storage data. The focus then shifted to the Amazon Bedrock service, where the adversary invoked various models disparate from the account owner’s typical usage. Experts categorize such anomalous invocations as a significant “red flag” and advise organizations to restrict authorized models via rigorous service control policies.

The antagonist further engaged machine learning virtual machines, utilized cloud storage for script hosting, and attempted to instantiate a model training environment. One script referenced a non-existent repository, echoing previous generative anomalies, and attempted to establish a public compute server on port 8888 to serve as a clandestine backdoor. However, this instance was terminated within five minutes of its creation.

Sysdig underscores that AI-driven offensives are becoming increasingly prevalent, and the total automation of cloud intrusions is likely imminent. Primary defensive measures center on the stringent governance of identities and permissions. It is recommended to adhere to the principle of Least Privilege, restrict the modification of cloud function code and role delegation, eliminate public access to sensitive storage, and implement comprehensive logging for all model interactions.

Amazon clarified that the underlying service infrastructure remained secure and operated as intended; the incident resulted from a client’s misconfigured public storage. The corporation urges users to maintain private storage settings, apply minimal permissions, safeguard credentials, and utilize monitoring services to mitigate the risk of unauthorized activity.