Suspected AI-Assisted AWS Compromise - App Weakness → Machine-Speed Secrets Sweep → Multi-Account Persistence → CI/CD Abuse → RDS Exfil → Infrastructure Extortion in 72 Hours
Sygnia's incident response team published a case study describing a single financially motivated actor who went from a weakness in an internet-facing application to broad control of a large AWS estate in roughly 72 hours. There was no custom malware and no zero-day: every action mapped to techniques defenders have tracked for years. Rather than encrypting anything, the actor demonstrated control of the cloud infrastructure itself (denying S3 bucket access, scaling ECS services to zero, adding network ACL deny rules, purging SQS queues) and used that as extortion leverage. The AI angle here is an inference, not a proven fact. Sygnia assesses that AI-assisted or agentic workflows played a role based on attacker-created scripts and structured reporting artifacts it describes as "consistent with AI-assisted generation", a self-documenting payload embedded in a malicious commit, and parallelism that is hard to reconcile with a single human operator. No specific model, agent framework, or vendor was identified. The victim organization, the incident dates, and the initial-access vulnerability were all withheld.
Sygnia does not name the application, the vendor, or a CVE, and does not name the victim. What the report does say is that the actor obtained an access key to one of the victim's AWS accounts through weaknesses in an internet-facing application, after which the intrusion followed a familiar shape: access, discovery of exposed credentials, expansion into cloud infrastructure. Because the entry credential was a legitimate long-lived AWS access key, every API call from that point forward was made by an authorized principal. The undisclosed entry point is the least interesting part of this chain, and treating it as the story would miss what follows.
What it yielded: a long-lived AWS access key for one account in the estate
Why it worked: a valid access key makes the attacker a legitimate AWS principal from the first call
Detection gap: no anomaly raised on first use of the key from new infrastructure
Discovery was not a phase in this intrusion, it was a subroutine. Each time the actor obtained a new credential they validated it and repeated the same loop from the new permission scope: what can this identity do, what can it reach, and which trust relationships lead somewhere better. Sygnia describes the actor analyzing identity relationships, privilege assignments, and trust relationships to identify multiple paths for privilege escalation. The same pass swept for secrets across environment variables on ECS containers and EC2 instances, objects in S3, AWS Systems Manager Parameter Store, and AWS Secrets Manager.
Secrets sweep surface: ECS / EC2 environment variables, S3 objects, SSM Parameter Store, AWS Secrets Manager
Loop: new key → validate → re-run full enumeration from the new permission scope
Detection gap: high-volume read-only enumeration spread across accounts raised no correlated alert
Sygnia's list of where secrets were found is the whole lesson in one sentence: environment variables from ECS containers and EC2 instances, CI/CD runner environments for both GitHub and Bitbucket, plaintext secrets stored in S3 buckets, API keys in application databases, secrets in AWS Secrets Manager, and parameters in SSM Parameter Store. The same credential material sat in several of those layers at once, so no single control gated it. Rotating an entry in Secrets Manager did nothing about the copy pasted into an S3 object or baked into a container's environment block. Harvested credentials became the connective tissue that let the actor keep restarting the discovery loop with a wider scope each time.
Why it worked: secrets sprawl - identical material duplicated across storage, config, and runtime layers
Effect: every recovered secret fed step 02 again with a wider permission scope
Detection gap: bulk GetParameter / GetSecretValue reads were not baselined per identity
Persistence here was part of the extortion strategy, not a backup plan. Sygnia is explicit that the more durable and distributed the access became, the more credible the actor's ability to disrupt, damage, or influence recovery. The actor created additional IAM users and access keys, established reverse shells on EC2 instances and ECS containers, modified deployment files so that a redeploy would reintroduce the foothold, and created application users with elevated permissions. None of it needed malware: execution rode cloud-native primitives (scripting, cloud administration commands, container and serverless execution), which is why endpoint tooling had so little to say about it.
Runtime persistence: reverse shells planted on EC2 instances and ECS containers
Redeploy persistence: modified deployment files, so a clean rebuild reinstated access
Application persistence: application-layer user accounts created with elevated permissions
The actor used the source-control and CI/CD layer in both directions: runner environments were harvested for secrets, and repositories plus deployment files were modified so the pipeline itself would carry the changes into the cloud. That is the persistence class that survives credential rotation, because reintroduction happens through an approved deployment. Sygnia labels this CI/CD pipeline abuse and maps it to T1677, which MITRE publishes under the name Poisoned Pipeline Execution. This is also where the cover story appears: multiple attacker-created artifacts were framed as a "pentest" or a "red team" exercise, in branch names and commit messages, including references suggesting approval by a CEO who did not exist. Sygnia offers two readings and commits to neither: the framing may have been meant to mislead investigators, or it may have been meant to influence AI-assisted tooling by presenting the work as an authorized penetration test in order to reduce refusals.
Method: repository and deployment-file modification, carried into the cloud by the pipeline
Cover story: branch names and commit messages framed as an authorized "pentest" / "red team", approved by a non-existent CEO
Why it worked: pipeline changes execute with the pipeline's own privileges and outlive key rotation
This is the observation the whole case study turns on. Sygnia reports that in one observed second, four different access keys belonging to four separate accounts were used from the same source IP address and the same user agent, and calls that pattern very hard to explain as manual activity. Alongside the raw concurrency, the actor kept operational context across many credentials: which key belonged to which workstream, what each one could reach, where it had already been used, and when to abandon it. That state management is what turned a linear attack path into overlapping waves. Sygnia's own caveat is worth repeating: the pattern points to automated, centrally orchestrated, potentially agent-driven execution, and no more than that.
Implication: parallel workstreams under central orchestration, not one operator at a keyboard
Detection primitive: correlate CloudTrail across accounts on sourceIPAddress plus userAgent, never per account
Why it worked: each account's trail showed only its own slice, so the shared client fingerprint stayed invisible
RDS databases were queried for user data, transaction information, and other potentially sensitive records, showing the actor wanted data as well as infrastructure control. Sygnia treats the volume and specificity as evidence of rapid environment-specific adaptation: several hundred unique SQL queries across dozens of databases, rapidly enumerating schemas and identifying relevant data. Writing that many targeted queries against unfamiliar schemas is normally slow, careful work. Sygnia is careful here too, calling this not definitive proof of autonomous AI-agent activity but consistent with AI-assisted or orchestrated operations that can process context and customize actions at speed.
Targeted: user records, transaction data, other sensitive business data
Signal: schema enumeration followed immediately by targeted extraction, database after database
Detection gap: no baseline on query volume or novel query shapes against production RDS
There is no clean cloud equivalent of an on-premises encryptor, so the actor built leverage a different way. Sygnia describes mostly reversible impact actions performed as a demonstration of capability: denying access to S3 buckets, limiting ECS services or containers to a maximum capacity of zero, creating ACL rules to block network access, and purging SQS queues. An HTML file was also dropped into S3 buckets carrying the same "red team" framing seen in the repositories. The unsettling part is that every one of these is a routine cloud administration call. The impact ran through the control plane, with valid credentials, using APIs the platform team uses daily.
Also dropped: an HTML file into S3 buckets, framed as "red team" work
Leverage model: control of the infrastructure itself as the extortion lever, no encryption involved
Why it worked: destructive control-plane calls look identical to routine operations without behavioral baselining