When credentials are stolen, the breach hasn’t happened yet.
That moment is just access.
What follows is quiet, and methodical, until it isn’t.
Attackers don’t rush.
They verify, explore, and expand using tools your environment already trusts.
Step One: Testing the Credentials Without Noise
The first tool used is often the simplest one.
A browser.
Attackers log in the same way employees do:
1. Email portals
2. VPN dashboards
3. Cloud consoles
4. Internal web apps
No brute force.
No scanning.
Just a successful login from a new place.
Practical example:
A stolen O365 account is tested by opening Outlook Web Access.
If it works, the attacker waits.
Detection signal:
First-time successful login from a new location followed by no activity for hours.
Step Two: Email Becomes a Recon Tool
Email access is rarely abused immediately.
It’s searched.
Attackers look for context, not clicks.
In Order to provide you with insight into what kinds of things attackers typically search for in an inbox, below are some examples of words that frequently appear in nearly every email attack:
1. Invoice
2. Password
3. VPN
4. Admin
5. Reset
After completing their searches, attackers monitor ongoing email threads to find new victims and then use trust as leverage to commit fraud.
Step Three: Cloud CLIs Confirm What’s Possible
Once credentials are proven valid, attackers switch to command-line tools.
Not custom malware.
Official CLIs.
AWS examples:
aws iam list-attached-user-policies --user-name dev-user
aws s3 ls
aws ec2 describe-instances
Azure examples:
az role assignment list --assignee user@company.com
az storage account list
These commands are normal.
The timing isn’t.
Red flag:
Enumeration without corresponding deployment or maintenance activity.
Step Four: Creating Persistence Early
Using stolen passwords is ineffective for attackers because they know they must create backups. The way to back up your access to AWS accounts is through the creation of AWS Access Keys.
AWS access key creation:
aws iam create-access-key --user-name dev-user
Access keys are created so that attacks still have access, even if the password has changed. Access keys are often overlooked by customers, but accessing AWS via access keys allows attackers to continue to access AWS accounts, regardless of the password setting.
Detection signal:
One method of detecting this backup method is to monitor for automated processes or tickets for creating the access keys.
Step Five: Built-In OS Tools Do the Heavy Lifting
Once inside endpoints or servers, attackers avoid dropping binaries.
They use what’s already there.
Common PowerShell discovery commands:
whoami
net group "Domain Admins" /domain
Get-ADComputer -Filter *
Nothing malicious on its own.
But the sequence matters.
Red flag:
Discovery commands executed from non-admin user workstations.
Step Six: Lateral Movement With Familiar Protocols
Credentials get tested everywhere.
Common movement paths:
1. SMB shares
2. RDP
3. PowerShell remoting
Seen in the wild:
net use \\fileserver\share
mstsc /v:dc01.company.local
Or:
Enter-PSSession -ComputerName server01
Detection signal:
One account authenticating to multiple systems in a short window.
Step Seven: Service Accounts Expand the Blast Radius
Human credentials are temporary.
Service accounts are forever.
Attackers hunt for them next.
Where they’re found:
1. CI/CD logs
2. Environment variables
3. Configuration files
Examples:
cat ~/.aws/credentials
printenv | grep KEY
Service accounts don’t “log in.”
They just authenticate.
Which makes them easy to miss.
Step Eight: Data Leaves Without Looking Like Theft
No tunnels.
No custom exfiltration tools.
Just legitimate copy operations.
Examples seen repeatedly:
aws s3 sync s3://prod-data ./backup
az storage blob download-batch --source sensitive-data
Looks like backup activity.
Because it is.
What This Looks Like in Logs
Credential abuse doesn’t trigger alarms.
It builds timelines.
Common patterns:
1. Login → account enumeration → creation of new credentials
2. Admin tools accessed via end-user devices
3. Service account being used to access a newly acquired resource
4. SMB, RDP, or API usage slowly increasing
5. Accessing data with no legitimate business context
Each event has been verified against the security policy and subsequently "Lines" can be draw to tell a story.
Why Traditional Defenses Miss This
Most controls ask:
“Is this allowed?”
Attackers ask:
“What can I do with what’s allowed?”
When access equals trust,
tools become weapons.
Practical Defensive Moves That Actually Help
Instead of blocking tools, limit damage:
1. Enforce least privilege everywhere
2. Alert on unusual sequences, not single events
3. Treat service accounts as high-risk identities
4. Monitor enumeration behavior explicitly
5. Log internal authentication, not just perimeter access
Friction slows attackers.
Visibility exposes them.
A Simple Way to Think About It
Stolen credentials don’t cause breaches.
Unrestricted use does.
If one login can see everything, someone eventually will.
