Cloud Breaches Rarely Start With “Hacking”
When a cloud breach hits the news, people expect zero-days or exotic malware.
What usually caused it is much simpler.
Someone logged in.
With a tool you already trust.
Most cloud breaches don’t break security controls.
They walk straight through them.
Attackers Don’t Need New Tools
They use the same tools engineers, admins, and DevOps teams use every day.
Why?
Because cloud environments are built on APIs.
And APIs don’t know intent, only permissions.
If access is valid, the tool works.
Tool #1: Cloud CLIs (AWS CLI, Azure CLI, gcloud)
These are often the first tools used after access.
What attackers do with them:
1. Enumerate accounts, projects, and subscriptions
2. List storage buckets and databases
3. Pull IAM roles and policies
4. Search for secrets and keys
From logs, this looks like normal admin activity.
Because it is.
Real-world pattern:
A compromised developer laptop.
Cached credentials.
CLI configured months ago.
No alerts until data starts moving.
Analogy:
It’s like giving someone your office badge, they don’t need to pick locks anymore.
Tool #2: Terraform and Infrastructure-as-Code
IaC isn’t just for building environments.
It’s great for understanding them.
Attackers use it to:
1. Read infrastructure layouts
2. Identify critical services
3. Spot overly permissive roles
4. Recreate environments elsewhere
Sometimes they don’t destroy anything.
They copy it.
That’s harder to detect than sabotage.
Tool #3: Cloud Consoles (Yes, the Web UI)
Not everything happens in a terminal.
Attackers love cloud web consoles because:
1. They blend into normal admin behavior
2. They generate familiar audit logs
3. They require no malware
Common actions seen:
1. Creating new access keys
2. Adding temporary users
3. Modifying logging settings
4. Changing storage permissions
Nothing looks suspicious in isolation.
The problem is sequence.
Tool #4: API Tokens and Service Accounts
Service accounts are everywhere.
And often trusted far too much.
Attackers use them to:
1. Access internal services
2. Pull data without interactive logins
3. Move laterally between workloads
These accounts don’t “log in.”
They just work.
Which means they often bypass human-focused detection.
Tool #5: Data Movement Tools
Once access is stable, data leaves quietly.
Common choices:
1. Cloud-native sync tools
2. Object storage copy commands
3. Backup and snapshot exports
No malware.
No exfiltration tunnel.
Just data moving where permissions allow.
What This Looks Like in Logs
Cloud breaches don’t scream.
They whisper.
Patterns teams often miss:
1. CLI usage from unusual locations
2. IAM enumeration without corresponding deployments
3. Short-lived access keys created but never rotated
4. Service accounts accessing resources they never touched before
5. Logging settings modified early in the timeline
Each event is “allowed.”
Together, they show intent.
Why Traditional Detection Struggles
Most tools ask:
“Is this action permitted?”
Attackers ask:
“What can I do with what I already have?”
Cloud security fails when it focuses on access, not behavior.
Practical Defensive Moves
You don’t stop cloud breaches by banning tools.
You limit how much damage they can do.
Effective steps:
1. Enforce least privilege on IAM roles
2. Monitor what tools are doing, not just who is using them
3. Alert on unusual enumeration patterns
4. Treat service accounts like high-risk identities
5. Log and review control plane activity regularly
Visibility beats assumptions.
A Simple Way to Think About It
Cloud breaches aren’t smash-and-grab jobs.
They’re account abuse at scale.
If one identity can see everything,
someone eventually will.
