AI-Assisted Cloud Intrusion: Admin Access in 8 Minutes

Cloud Security Alliance AI Safety Initiative | March 2026

Key Takeaways

The following findings summarize the key technical and strategic dimensions of the Sysdig-documented incident and their implications for cloud security operations.

Background

The cloud security industry has observed a consistent compression in attacker dwell times over successive years of threat research. What was once a window measured in days, a period that successive industry threat reports have documented narrowing steadily [2], has been reduced to minutes. The CrowdStrike 2025 Global Threat Report documented an average eCrime breakout time of 48 minutes, with the fastest recorded breakout occurring in 51 seconds [2]. This window — within which defenders must identify and eject a threat actor after initial compromise — continues to narrow as adversaries adopt automation and AI-assisted tooling. The Sysdig Threat Research Team’s observation published on February 3, 2026 exemplifies this acceleration: an attacker using AI-assisted tooling achieved full administrative control of a target AWS environment in approximately eight minutes from the moment of credential acquisition [1].

This benchmark matters because it closes the window further than detection and response programs at most enterprises can currently match — industry metrics suggest median time-to-detect for cloud intrusions is typically measured in hours rather than minutes. The conventional “assume breach” posture, in which defenders accept that initial compromise will occur and focus energy on minimizing blast radius and dwell time, implicitly assumes that defenders have a meaningful window in which to operate. An eight-minute escalation to administrator access renders most manual investigation and containment workflows impractical, given the time required for alert routing, triage, and authorization. The attacker in this documented incident had created a backdoor IAM user with AdministratorAccess policy and compromised 19 unique AWS principals before a human analyst at a typical enterprise SOC could plausibly have reviewed a first alert — a sequence that, based on typical cloud IAM event MTTD data, routinely takes 30 minutes or more.

The incident also introduces the concept of the AI-assisted attack chain — not as a theoretical concern but as a documented operational capability. The attacker did not merely use AI tooling to automate repetitive steps; the evidence suggests AI was involved in active decision-making and code generation throughout the intrusion. Code comments written in Serbian provide a linguistic fingerprint pointing toward the operator’s likely origin, while the code itself exhibits structural patterns associated with LLM-generated output [1]. The invocation of Amazon Bedrock’s AI models during the intrusion further blurs the line between the attacker’s AI tooling and the victim organization’s own cloud-hosted AI infrastructure.

Security Analysis

The 8-Minute Attack Chain

The Sysdig Threat Research Team reconstructed the attack’s progression with CloudTrail telemetry, revealing a tightly sequenced kill chain in which each step completed within seconds of the last. At time zero, the attacker obtained valid AWS credentials belonging to an IAM user with Lambda invocation and Amazon Bedrock permissions. These credentials were sourced from a public S3 bucket that contained RAG pipeline data — a finding that reflects a broader pattern in which organizations building AI workflows on cloud infrastructure inadvertently expose the credentials those workflows require [1].

Reconnaissance began within six seconds of credential acquisition. The attacker enumerated resources across more than ten AWS services, including Amazon Bedrock model configurations, OpenSearch Serverless, and SageMaker — a breadth of reconnaissance that strongly suggests AI-assisted automation. As Sysdig noted, rapid enumeration spanning diverse service categories is an inherently suspicious pattern, distinct from the narrower access patterns of legitimate users performing a specific task [1]. By approximately one minute and thirty-five seconds, reconnaissance had yielded a sufficiently complete map of the environment to proceed to exploitation.

The privilege escalation step was the most technically significant element of the chain. The attacker identified an existing Lambda function named EC2-init whose execution role carried elevated IAM permissions. By invoking UpdateFunctionCode — a permission the compromised IAM user held — the attacker injected malicious code into the function without requiring direct IAM write access. This code, modified three times in rapid succession to refine its behavior, enumerated all IAM users and their access keys, created new administrative access keys, and read S3 bucket contents. The attacker’s ultimate target was an IAM user named frick, and within eight minutes of obtaining the initial credentials, a new backdoor IAM user called backdoor-admin had been created with full AdministratorAccess policy attached [1]. The entirety of this progression — from a low-privilege credential to unrestricted AWS administrative access — unfolded in less time than most organizations’ alerting pipelines require to surface a notification.

The lateral movement phase extended the operation beyond this initial escalation over approximately the next two hours. The attacker assumed six IAM roles across 14 distinct sessions, ultimately compromising 19 unique AWS principals [1]. This role-chaining behavior served a dual purpose: it extended the attacker’s access to additional services and data, while simultaneously distributing the activity across enough identities and session contexts to frustrate correlation-based detection systems.

LLMjacking as Secondary Objective

A distinctive characteristic of this incident — and one that distinguishes it from conventional credential-abuse attacks — was the attacker’s parallel objective of unauthorized AI model access, a pattern Sysdig has previously documented and termed LLMjacking. Having obtained Bedrock permissions through the compromised IAM user, the attacker invoked nine distinct foundation models without authorization: multiple Claude variants, DeepSeek R1, Llama 4 Scout, and Amazon Nova [1]. The attacker employed cross-region inference to increase throughput beyond the limits of any single Bedrock endpoint, and actively queried the GetModelInvocationLoggingConfiguration API to determine whether their model invocations were being logged — a clear evasion behavior directed specifically at audit coverage of AI model usage.

The LLMjacking activity is financially motivated as well as operationally significant. Access to frontier foundation models through legitimate cloud accounts carries substantial per-token cost. An attacker who can invoke high-tier models at scale by billing the victim organization gains both the economic value of compute access they did not pay for and the operational value of AI reasoning capability applied to their attack or to other commercial purposes. This economic dimension has grown as frontier model API access has become increasingly valuable; Sysdig has observed a corresponding growth in threat actor targeting of cloud credentials with Bedrock and SageMaker permissions [1], suggesting these AI service access rights have become a valued commodity.

In parallel with the model invocations, the attacker attempted to provision GPU compute instances. A request for a p5.48xlarge instance — among the highest-density GPU configurations available on AWS — failed due to capacity constraints. The attacker then successfully launched a p4d.24xlarge instance at a published cost of $32.77 per hour [1]. The instance was terminated after approximately five minutes, suggesting either that it completed its intended purpose or that the attacker abandoned the effort after encountering an obstacle. The combination of high-cost GPU provisioning and AI model invocation indicates a threat actor with ambitions beyond mere credential monetization — one who views cloud AI infrastructure as a target in its own right.

Defense Evasion and AI Attribution Indicators

The attacker employed three distinct evasion strategies during the operation. IP rotation was designed to impede the accumulation of geographic or network-based correlation signals that security information and event management (SIEM) systems commonly use to link activity from a single threat actor. Distributing the intrusion across 19 principals — rather than consolidating all subsequent activity under the newly created backdoor account — fragmented the activity record in a manner that makes retrospective reconstruction more labor-intensive. Role chaining, in which each subsequent lateral movement step assumed a different IAM role, similarly increased the effort required to trace a complete attack path through CloudTrail logs [1].

Several artifacts within the attack evidence indicate active AI assistance in the operation. The Lambda injection code exhibits exception handling patterns that some researchers associate with LLM-generated output — specifically the exhaustive, defensive handling of error conditions that generative models tend to produce — though this pattern alone is not definitive. More diagnostically, the attacker’s code referenced a GitHub repository at https://github.com/anthropic/training-scripts.git and used placeholder AWS account IDs (123456789012, 210987654321) that do not correspond to real accounts [1]. These are characteristic hallucination artifacts: an AI coding assistant interpolating a plausible but fictional repository URL and inserting standard placeholder account identifiers rather than querying the environment for actual values. Session names followed a consistent structured pattern reflecting the attack’s operational stages and included the literal string “claude-session” — a naming convention consistent with sessions established by or named after a Claude-based AI assistant [1].

These artifacts do not confirm a specific AI model or toolchain used by the attacker, and they should be treated as indicators rather than verified attribution. However, taken together, they constitute a coherent picture of an operator who was using an AI coding assistant to accelerate and guide the attack, and who did not thoroughly review the assistant’s outputs for hallucinated references before deploying them into the target environment.

The 555 Benchmark and the Defender’s Dilemma

Sysdig has articulated a 5/5/5 Benchmark as a target posture for cloud security operations: defenders should aim to detect an attack within five seconds, triage it within five minutes, and respond within five minutes after that — a total of approximately ten minutes from initial indicator to containment action [1]. The benchmark reflects the empirical reality that cloud attacks proceed at machine speed and that defenders who rely on human-paced investigation workflows are structurally unable to interrupt attacker operations before significant damage is done. Against an eight-minute credential-to-admin-access window, meeting even the five-second detection target demands that security telemetry pipelines ingest and process CloudTrail events in near-real-time — a requirement most organizations’ current detection architectures do not satisfy.

This framing clarifies a defender’s dilemma that cannot be resolved through faster human investigation alone. Even with detection occurring in seconds, the full benchmark cycle — detection plus triage plus response — totals approximately ten minutes, meaning the response phase arrives after the eight-minute admin-access threshold has already been crossed. In practice, the response step cannot occur without the prior triage step, and triage requires context loading, analyst assignment, and an authorization decision — a sequence that is difficult to complete before an attacker has achieved administrative access without substantial automation. The implication is that the relevant defensive capability is not faster human investigation but pre-authorized automated response: policies that trigger protective actions, such as credential suspension or least-privilege policy enforcement, directly upon detection signals rather than pending human review. The CSA’s cloud detection and response use-case research has similarly emphasized that cloud threats at machine speed require machine-speed response, with human oversight applied to policy setting rather than individual incident decisions [3].

Recommendations

Immediate Actions

Organizations operating cloud environments with AI/ML workloads should treat the IAM permissions associated with those workloads as a high-value attack surface requiring the same controls applied to any privileged credential class. The combination of Lambda UpdateFunctionCode permission with a Lambda execution role that carries PassRole or IAM write capabilities is a privilege escalation path that requires no vulnerability in AWS infrastructure — only credentials belonging to an IAM entity with those two permissions. AWS Identity and Access Analyzer can enumerate overpermissive configurations of this kind, and its findings should be reviewed and remediated as a priority.

Three remediation actions warrant immediate attention. Security teams should audit all IAM entities with lambda:UpdateFunctionCode or lambda:UpdateFunctionConfiguration permissions combined with iam:PassRole or iam:CreateAccessKey, as these combinations are documented privilege escalation paths that should be restricted to specific, justified use cases. Amazon Bedrock model invocation logging should be enabled, with alerts configured for high-volume model access, cross-region inference calls, and GetModelInvocationLoggingConfiguration queries — the last being a reliable indicator that an attacker is probing audit coverage before engaging in LLMjacking. Finally, all S3 buckets used in RAG, fine-tuning, or AI pipeline workflows should be inventoried for public access configurations, with credentials, configuration files, and objects containing authentication material subject to explicit block-public-access controls and periodic automated scanning.

Short-Term Mitigations

Lambda functions should be governed by execution roles scoped to the minimum permissions required for the function’s documented purpose. Role versioning and aliasing can constrain which function code versions are authorized to assume elevated roles, reducing the blast radius of a UpdateFunctionCode exploitation. Where Lambda functions do not require IAM permissions beyond their immediate operational need, Service Control Policies (SCPs) at the AWS Organizations level can enforce an upper bound on Lambda execution role permissions regardless of individual role configurations.

IAM role chaining — the sequential assumption of roles to accumulate effective permissions — is detectable through CloudTrail’s AssumeRole event logs. Detection rules that alert on unusual patterns of role assumption, particularly when a single session chains through three or more roles within a short interval or when role assumption is conducted from IAM users that do not normally assume roles, should be implemented in cloud-native security platforms. Sysdig’s disclosed detection rules for this incident are directly applicable starting points, pending adaptation to each organization’s environment: “Lateral Movement using Roles for Privilege Escalation,” “High Number of Bedrock Model Invocations,” and behavioral rules covering IAM, Lambda, and Organizations enumeration patterns [1].

Comprehensive threat detection for AI pipeline resources should extend to SageMaker, OpenSearch Serverless, and Bedrock configurations, which are commonly surveyed during AI-environment reconnaissance but frequently excluded from legacy cloud security monitoring scope. These services should be treated as first-class assets in cloud security posture management programs.

Strategic Considerations

The eight-minute admin-access benchmark should prompt a reassessment of whether current cloud detection and response capabilities are calibrated to the actual threat tempo. Security operations teams should measure their median time-to-detect and time-to-respond for cloud IAM events specifically — not as an aggregate across all alert types — and compare that figure to the 5/5/5 Benchmark. Where gaps exist, the path to improvement lies in automated response playbooks with pre-authorized actions, not in hiring or training initiatives alone.

The LLMjacking dimension of this incident is a harbinger of a broader economic dynamic. As large language models and GPU compute access become increasingly monetizable commodities, cloud credentials with AI service permissions are likely to attract escalating adversary attention as frontier model access becomes increasingly valuable. Organizations that have deployed Bedrock, SageMaker, or equivalent managed AI services should treat those permissions as equivalent in sensitivity to credentials with billing and financial management access — because unauthorized access to either can result in unbounded financial loss. Quota limits, resource tagging with automated anomaly detection on AI service spend, and billing alerts calibrated to expected usage patterns are low-friction controls that provide meaningful early-warning capability.

At the architectural level, enterprises should evaluate whether their AI pipeline designs create unnecessary credential concentration. RAG pipelines that retrieve data from S3 frequently require read access across multiple sensitive data stores; if the credentials used by those pipelines are co-located with the data they access, a single misconfigured bucket can expose credentials to the entire pipeline’s data scope. Separating retrieval credentials from configuration and deploying short-lived, role-based credentials through AWS IAM Roles Anywhere or similar mechanisms removes the specific static credential exposure pattern that enabled this attack’s initial access, though organizations should note that dynamic credential mechanisms introduce their own trust boundaries that require ongoing security review.

CSA Resource Alignment

This incident engages multiple dimensions of the CSA’s ongoing AI safety and cloud security research programs, and organizations responding to the threats it describes will find directly applicable guidance across several frameworks.

The CSA’s MAESTRO framework for agentic AI threat modeling provides the most directly applicable structural lens for understanding the attacker’s use of AI assistance. MAESTRO’s Layer 1 (Foundation Models) and Layer 3 (Agent Trust Boundaries) threat categories address precisely the risks demonstrated here: an attacker leveraging foundation model capabilities to accelerate an attack chain, and the blurred accountability boundaries that emerge when AI-generated artifacts are injected into operational infrastructure [4]. The LLMjacking activity — specifically the attacker’s querying of logging configuration to avoid detection — maps to MAESTRO’s evasion threat category within the model interaction layer.

The CSA Cloud Controls Matrix (CCM v4) addresses the IAM privilege escalation path at the center of this attack through its Identity and Access Management (IAM) domain. CCM control IAM-02 (User ID Credentials) and IAM-09 (User Access Authorization) articulate requirements for least-privilege enforcement and periodic access review that, if applied to Lambda execution roles with the rigor typically reserved for human user accounts, would likely have removed or constrained the escalation path exploited in this incident [5]. The CCM’s Infrastructure and Virtualization Security (IVS) domain is also relevant to the GPU compute provisioning activity, which represents an unauthorized workload instantiation at significant financial cost.

The CSA’s AI Organizational Responsibilities publications address the governance dimensions of AI service access, including responsibilities for monitoring authorized versus unauthorized use of organizationally managed AI endpoints — a control category directly implicated by the LLMjacking activity documented here [6]. The principle that organizations bear responsibility for the AI inference costs incurred through their accounts, and therefore must monitor invocation volume and patterns against expected baselines, is a natural extension of the financial controls organizations already apply to other cloud resource categories.

The CSA’s Zero Trust guidance is relevant to the cross-principal lateral movement phase of the attack. A zero-trust architecture that evaluates each API call against the originating identity’s behavioral baseline — rather than treating a valid access key as an unconditional grant of its nominal permissions — would generate anomaly signals as the attacker’s session patterns diverged from those of the original IAM users. The integration of behavioral analytics into IAM authorization decisions, which is the operational expression of zero trust for cloud environments, is described in the CSA’s cloud-native zero trust implementation guidance [7].

Finally, the CSA’s Cloud Detection and Response research — including the four CDR use cases published in collaboration with Orca Security — documents the operational workflows through which security teams can build response programs calibrated to cloud attack tempo [3]. The detection rules disclosed by Sysdig for this incident are directly applicable to implementation of CDR use case patterns, and organizations that have not yet integrated cloud-native detection rules for IAM enumeration, Lambda modification, and Bedrock invocation anomalies should treat this incident as motivation to do so.

References

[1] Brucato, Alessandro, and Michael Clark. “AI-assisted cloud intrusion achieves admin access in 8 minutes.” Sysdig Threat Research. February 3, 2026. https://sysdig.com/blog/ai-assisted-cloud-intrusion-achieves-admin-access-in-8-minutes/

[2] CrowdStrike. “2025 Global Threat Report.” CrowdStrike, Inc. 2025. https://www.crowdstrike.com/en-us/resources/reports/global-threat-report-executive-summary-2025/

[3] Mokris, Keith. “4 Use Cases for Cloud Detection and Response in the SOC.” Cloud Security Alliance / Orca Security. 2022, updated 2025. https://cloudsecurityalliance.org/artifacts/4-use-cases-for-cloud-detection-and-response-in-the-soc

[4] Cloud Security Alliance. “MAESTRO: Agentic AI Threat Modeling Framework.” AI Safety Initiative. 2025. https://cloudsecurityalliance.org/blog/2025/02/06/agentic-ai-threat-modeling-framework-maestro

[5] Cloud Security Alliance. “Cloud Controls Matrix v4.0.” CSA CCM Working Group. 2021, updated 2024. https://cloudsecurityalliance.org/research/cloud-controls-matrix/

[6] Cloud Security Alliance. “AI Organizational Responsibilities: AI Tools and Applications.” AI Safety Initiative. 2025. https://cloudsecurityalliance.org/artifacts/ai-organizational-responsibilities-ai-tools-and-applications

[7] Cloud Security Alliance. “Zero Trust Guidance for Critical Infrastructure.” CSA Zero Trust Working Group. 2024. https://cloudsecurityalliance.org/research/topics/zero-trust