For years, the informal security posture of a lot of small and mid-sized orgs has been a version of the same two sentences: "We're not worth the effort" and "We'd notice before they got far."
Both just got significantly less true.
On July 8th, incident response firm Sygnia published findings from an active breach investigation. A lone attacker — one person, working alone — used AI as a force multiplier to compromise a large AWS environment in approximately 72 hours, then tried to extort the victim. What used to take a coordinated team three to four weeks took one individual less than three days.
The attacker didn't use a zero-day. They didn't have insider access. They started with a single stolen AWS access key — the kind that leaks through a misconfigured web app, an exposed .env file, a developer's laptop hit by a basic infostealer. One key. 72 hours. Everything gone.
What the attack actually looked like
Sygnia's report describes how the attacker chained nearly two dozen distinct techniques in parallel across the environment. The sequence: credential discovery, secrets harvesting, cloud enumeration, deployment pipeline abuse, runtime modification, database access, and operational disruption. Not one after the other. All of it moving fast and simultaneously.
The entry point was an AWS access key extracted from a vulnerable internet-facing application. From there, AI-assisted workflows let the attacker sweep the environment — finding other credentials, mapping IAM roles, poking at source code repositories, walking the CI/CD pipeline for anything sensitive embedded in build configs or environment variables.
Then the damage: S3 buckets locked down, ECS services throttled, network access control lists rewritten to block traffic, SQS queues purged. The attacker wasn't just stealing data — they were disabling the environment to maximize extortion pressure.
The forensic evidence that AI was involved is circumstantial but convincing. Attacker-built scripts showed characteristics consistent with AI generation. The sheer volume of parallel activity across 24 distinct techniques would be difficult for one person to coordinate manually — the kind of throughput that implies something automating the repetitive work. And the artifacts the attacker left behind were labeled "pentest" and "red team," organized and annotated like someone had an AI assistant helping structure and name each step of the operation.
Why this breaks the "we're not a target" logic
The old model of cyberattacks required human expertise and time. Reconnaissance took hours. Writing environment-specific scripts took more hours. Adapting to a new infrastructure on the fly, pivoting from one system to another, coordinating across multiple attack surfaces simultaneously — that required a team with real skills and a long window of undetected access.
AI removes most of those bottlenecks. Reconnaissance gets automated. Script generation gets automated. Environment adaptation gets automated. What one person can accomplish in 72 hours with AI-assisted workflows now matches what a small professional attack team could do in weeks without it.
"Not worth the effort" only works as a defense when effort is still a meaningful constraint.
It's less meaningful now. A single motivated attacker with decent AI tools can run what looks like a team operation. Your size doesn't protect you the way it used to.
The specific things that got chained together here
What's useful about Sygnia's report is that it's not abstract. The attacker exploited a combination of:
- A single exposed AWS access key from a vulnerable internet-facing app
- Secrets embedded in source code repositories — the kind that developers commit and forget
- Overly permissive IAM roles that let that initial key reach far more than it should have
- CI/CD pipeline credentials that opened access to the deployment environment
- No detection fast enough to interrupt the chain before the attacker finished
None of these are exotic. Every one of them shows up in typical small org cloud environments. The difference is that previously you'd have weeks before a threat actor finished working through that chain. Now you have hours.
What to tighten up before you're the case study
Rotate every AWS key that touches production — then figure out where the old ones live. This week. GitGuardian, Trufflehog, or a manual grep through your repos and CI configs. GitGuardian's free tier covers most small org codebases. Anything that shows up in that scan is a live attack vector right now.
Scope your IAM roles down. The reason one key led to full-environment compromise is that it had — or could reach roles with — far more permission than needed. Go through your IAM users and roles, find anything with broad access that hasn't been used in 60 days, and either delete it or scope it down. AWS IAM Access Analyzer shows you what's actually being used versus what's granted.
Get your CI/CD secrets out of environment variables and into a secrets manager. GitHub Actions secrets, CircleCI env vars, Bitbucket environment settings — these are common holding places for AWS credentials that get forgotten and never rotated. Anything stored there that has production access should be in AWS Secrets Manager or a similar system with rotation policies, not sitting in a CI variable from 2023.
Enable CloudTrail in every region if you haven't. At the speed this attack moved, you need logs that tell you what happened before your team notices something is wrong. CloudTrail costs next to nothing for a small AWS environment. Without it, you'll be trying to reconstruct a 72-hour attack timeline from memory.
The timeline problem
The Five Eyes advisory from last month warned that AI-assisted attacks were months away from becoming common. Sygnia's report suggests the window was shorter than that.
The detection and response timelines most small orgs operate on — "we'll notice in a day or two," "we'll look at the logs at the weekly security check-in" — were designed for threat actors working at human speed. That's not what you're planning against anymore.
This is the kind of exposure audit we run for small teams: what's deployed, what credentials have access to what, what an attacker would actually do with a leaked key. Usually takes a day. Costs considerably less than what comes after a 72-hour cloud compromise.