It starts with a misconfigured S3 bucket.
Not a zero-day. Not a nation-state exploit. Just a forgotten public bucket — the kind that shows up in every cloud audit and gets a "medium severity" tag before someone closes the Jira ticket and moves on.
Except this time, there's no human on the other side waiting for a pentest report. There's an AI agent. And it doesn't close tickets — it chains 11 automated actions in under four minutes and walks out with the environment's IAM credentials.
Nobody typed a single command.
Before you assume this is hypothetical: in early 2024, researchers at UIUC handed GPT-4 a browser, a terminal, and a list of CVE descriptions. The agent autonomously exploited 87% of real one-day vulnerabilities it was pointed at. By 2025, open-source agent frameworks made the same capability accessible to anyone with an API key.
I've spent the last year building AI-augmented detection pipelines that process hundreds of thousands of security alerts a week, enriching them with MITRE ATT&CK context. The kill chain I'm about to walk you through is constructed from real attack techniques I've seen telemetry for — stitched together to show what an autonomous agent does when it doesn't have to wait for a human.
Most security teams are not ready for it.
What an AI Attack Agent Actually Looks Like
Forget the Hollywood version of hacking.
Modern AI attack agents look more like your company's internal automation platform. They have tools. They have memory. They have goals. The agent doesn't learn how to hack — it already memorized every public writeup, every CVE description, every cloud privilege escalation path ever documented. You don't teach it. You point it.
That changes the math on every detection rule you've ever written.
The 4-Minute Kill Chain
Here's how the chain unfolds when nothing in your defense stack catches it. Mapped to MITRE ATT&CK:
T+0:00 — Initial Access (T1530: Data from Cloud Storage Object)
The agent's recon module finds the misconfigured S3 bucket via passive subdomain scanning. No exploit needed — the bucket policy allows s3:GetObject to "*". Among the downloaded files: a .env containing AWS access keys.
T+0:47 — Discovery (T1580: Cloud Infrastructure Discovery)
With keys in hand, the agent runs sts:GetCallerIdentity, then enumerates EC2, Lambda, RDS, and S3. All in under 60 seconds.
T+1:20 — Privilege Escalation (T1078: Valid Accounts)
The compromised role has iam:PassRole and lambda:CreateFunction. The agent recognizes this as a known escalation path — creates a Lambda with an AdministratorAccess execution role, invokes it, and uses elevated privileges to create a new IAM user.
T+2:15 — Persistence (T1136.003: Cloud Account)
New IAM user. New access key pair. The original compromised credentials are no longer needed.
T+3:40 — Exfiltration (T1537: Transfer Data to Cloud Account)
The agent begins systematically copying S3 objects to an external bucket it controls. By the 4-minute mark, the storage footprint is gone.
The SIEM fires its first alert at T+3:55.
Fifteen seconds after the exfiltration completes.
Why Your Detection Stack Misses It
Most alerting rules were written around human-speed attacks. A human attacker moving through this same chain would take hours — pausing to read docs, to make decisions, to drink coffee. Your anomaly detection was trained on that pace.
An AI agent doesn't pause. It already memorized the docs.
The entire chain above looks, at the log level, like a single burst of automated API activity. Without context, it's indistinguishable from a CI/CD pipeline. When you're processing hundreds of thousands of security alerts a week, the most consistent failure mode isn't missing the malicious activity — it's that the malicious activity is buried under the legitimate automation.
The four specific gaps:
1. API call velocity is unmonitored for non-service accounts.
Most teams track what API calls happen, not how fast. An IAM user making 200 API calls in 90 seconds should scream. It usually doesn't.
2. Lambda-based escalation is underdetected.
The iam:PassRole + lambda:CreateFunction path has been documented for years. CloudTrail logs it. Nobody's watching.
3. Cross-account S3 transfers aren't blocked by default.
AWS doesn't stop you from copying your data to an external bucket. That requires an explicit SCP. Most mid-size teams don't have one.
4. The agent uses legitimate APIs the entire time.
No malware. No exploit signatures. The attack stays within authorized bounds — until it doesn't.
Five Detections That Actually Catch This
These are the rules I'd write tomorrow morning if I were running detection engineering for any cloud-native shop.
1. IAM credentials used from a new source
A long-term access key — previously seen only from a CI runner or dev workstation — suddenly making calls from a new IP, ASN, or region. P2 alert. No exceptions.
2. Lambda creation followed by invocation within 60 seconds
Legitimate developers don't create a Lambda and immediately invoke it in production outside a CloudFormation or CI/CD context. High-confidence escalation signal.
3. IAM user creation by a non-IAM-admin role
Any role not explicitly designated for identity management should never be creating IAM users. P1 alert. Maps to T1136.003.
4. Cross-account S3 PutObject to an unknown destination
When data starts moving to a bucket whose ARN doesn't match any known internal account — fire immediately. This is your last line.
5. Burst API call rate anomaly per principal
Rolling 5-minute window. Any IAM principal exceeding 3 standard deviations above their baseline — especially with diverse action types (enumeration signal) — triggers automatic credential suspension.
These five rules, properly tuned, catch the attack between T+0:47 and T+1:20. Before the escalation. Before the persistence. Before the exfiltration.
What's Coming Next
The 4-minute chain is already yesterday's news.
Research labs are publishing work on agents that maintain access across weeks, adapt to defensive changes, and deliberately throttle their own speed to mimic human timing. The agent learns your SIEM has a 200-calls-per-5-minutes threshold. So it makes 190. Forever.
The speed of attack is decoupling from human cognitive limits. The speed of defense, in most organizations, is still very much dependent on humans reading dashboards, triaging alerts, and writing tickets.
The only viable answer is autonomous defense at the same layer of abstraction as autonomous offense — SOAR playbooks that suspend credentials and isolate instances in under 30 seconds, behavioral baselines that update in real-time, detection-as-code pipelines that don't require a human to write a new rule every time a new technique emerges.
What You Should Do This Week
1. Scan your S3 buckets for credentials.
Run a search across every bucket for .env, credentials, config, and *.pem files. Twenty-minute job with the AWS CLI. It will terrify you.
2. Wire GuardDuty findings to a human.
Most teams have it enabled and never look at it. Route findings to Slack, PagerDuty, or SNS — somewhere with a human on the other end.
3. Test the Lambda escalation path.
Create an IAM role with iam:PassRole + lambda:CreateFunction in a non-prod account and try to escalate. If you succeed, your CloudTrail should fire an alert within two minutes. If it doesn't, you have a detection gap.
I'm a Detection Engineer and Security Compliance professional working at the intersection of AI-augmented SOC pipelines, cloud security, and MITRE ATT&CK-based detection engineering. MS Cybersecurity candidate. CySA+ | Security+ | BTL-1.
Originally published on Medium.
Top comments (0)