AI strengthens the attack chain in AWS environments

Cybercriminals breached an Amazon Web Services (AWS) environment in less than eight minutes , combining credential theft, privilege escalation, lateral movement, and GPU resource abuse, aided by large language models. It was an attack so fast that defenders had virtually no time to react. According to new findings from Sysdig ’s Threat Research Team , the attackers turned a single exposed credential ( on a public S3 bucket ) into full administrative control , demonstrating how AI- powered automation has shortened the cloud attack lifecycle from hours to minutes.

The operation, observed in November 2025, combined a cloud misconfiguration with large language models (LLMs) to compress the entire attack lifecycle.

“The world of cybersecurity today is brand new,” said Ram Varadarajan, CEO of Acalvio. “In this threat landscape, organizations must accept that the speed of breach has shifted from days to minutes. Attackers can now go from initial access to full administrative control in a matter of minutes.”

Defending against this class of attacks requires “ AI-focused technology ” that can think and respond at the same speed as attackers.

See also: NSA: New Zero Trust Implementation Guidelines (ZIGs)

How are new attacks on AWS – Cloud carried out through AI?

The breach began with valid AWS credentials left exposed in public S3 buckets. These buckets contained AI-related data, and the associated IAM user had permissions that allowed them to interact with Lambda and have limited access to Amazon Bedrock.

“This user was likely intentionally created by the victim organization to automate Bedrock tasks with Lambda functions across the environment,” Sysdig researchers said in a post.

With read access to the entire environment, the attacker enumerated AWS services, then escalated privileges by modifying an existing Lambda function. By injecting malicious code into a function that already had an overly permissive execution role, the attacker was able to create new access keys for an administrative user and retrieve them directly from the Lambda execution output.

Jason Soroko, a senior partner at Sectigo, said the root of the problem was frustratingly familiar. “We need to look beyond the modernity of AI assistance to recognize the common mistake that enabled it,” he said. “The entire breach began because the victim left valid credentials exposed in public S3 buckets. This failure represents a persistent refusal to master the basics of security.”

See also: Shai-Hulud & Co.: The software supply chain as a weakness

The Lambda code showed signs of being created by LLM, including comprehensive exception handling, iterative targeting logic, and comments in non-English languages.

Lateral movement, LLMjacking, and GPU abuse

Once administrative access was gained, the attacker moved laterally across 19 different AWS principals, assuming multiple roles and creating new users to spread activity across identities. This approach enabled persistence and made detection difficult. The attackers then shifted their focus to Amazon Bedrock, enumerating the available models and confirming that model invocation logging was disabled.

The researchers reported that multiple fundamental models were invoked, a pattern consistent with “LLMjacking.”

The operation then escalated to resource abuse. After preparing keys and security groups, the attackers attempted to launch powerful GPU instances for machine learning workloads. While most powerful instances failed due to capacity limits, one GPU instance was eventually launched, with scripts to install CUDA, deploy training frameworks, and expose a public JupyterLab interface.

Part of the code referenced non-existent repositories and resources, which Sysdig researchers attributed to LLM hallucinations.

Experts say the most troubling finding isn’t that AI introduced a new attack technique. It’s that AI removed indecision. “When you break this attack down to its core elements, what stands out isn’t a groundbreaking technique,” ​​said Shane Barney, CISO at Keeper Security. “It’s how little resistance the environment offered once the attacker gained legitimate access.”

See also: Mandiant: How ShinyHunters abuses SSO to steal cloud data

He warned that AI compresses reconnaissance, privilege testing and lateral movement into “a single, rapid sequence,” eliminating the wait time that defenders have historically relied on.

To reduce exposure, Sysdig researchers advised implementing the principle of least privilege on IAM users, roles, and Lambda execution roles, strictly restricting permissions like “UpdateFunctionCode” and “PassRole,” and ensuring that sensitive S3 buckets are never made public. Enabling Lambda versioning, enabling Amazon Bedrock model invocation logging, and monitoring for large-scale enumeration activity are also critical, they added.