This article documents lessons learned after recovering from an AWS account compromise. It is written for individuals and small operators running cloud services without dedicated security teams.
AWS Security
AWS Security – Lessons Learned After an Account Breach
This article documents lessons learned after recovering from an AWS account compromise. It is written primarily for individuals and small operators running cloud services without dedicated security teams.
Security is a major concern today. Automated bots and AI-assisted tools constantly scan cloud services looking for weaknesses.
Many people running small cloud environments do not have the same monitoring systems or security teams that large organisations have. When something goes wrong, it can feel similar to a home break-in — stressful, confusing, and unfair.
If you experience a breach, remember that these attacks are extremely common and often automated. The important thing is to focus on recovering and strengthening your systems. Keep a check on your emotions as we don’t want to give attackers any added satisfaction.
Cleaning up after a cloud breach can feel a bit like cleaning up after a flood. It takes time and patience.
The notes below are based on real experience and may help others facing a similar situation.
This article does not provide example code, but new code has been developed with the assistance of AI. This takes time to implement and test. This has included ability to remove Postfix, only using the aws-sdk for email alerts; No AWS credentials listed on the system; Protection of application config files such as .env via Nginx or Apache2; IAM Roles unique and segregated when attached to EC2 instances (i.e. not the same Role on different instances), with strong restrictions on policies and Lambda functions for both S3 Buckets and SES. These are too detailed to provide here, the intention being to provide an overview.
Cloud security is complex and constantly evolving. The observations here are based on practical experience and may not cover every situation. I have no AWS certificates or qualifications.
What My Breach Actually Looked Like (Real Example)
In my case the breach initially appeared as an AWS Email regarding DKIM for another domain and account number I did not own. I contacted security support immediately. I was up till midnight responding to subsequent support emails. The focus had been on IAM, and the next morning while I was in my brother’s car, SES had been breached. This is when I took my own steps to deactivate and delete SES configurations.
So, the first signs were unusual notifications and activity that did not match anything I had configured. I reviewed CloudTrail logs, which showed activity. There was no awareness at this point that I had also been billed for a domain name on another account that I did not own.
This was scary and disturbing. How was I to know what detailed actions to take? I spent several hours manually backing up everything on my account.
I closed the account as per reasonable practice, but did not realise breaches can continue, and, I had not deleted all services on the account. Further, I learnt I had to keep the account open to lodge tickets, such as a request for credit refunds. It was only through requesting a forgotten password that I could find a link to take me to a payments section on the old account – where I could lodge a ticket to reopen the account. This was an ongoing and difficult process that took almost 30 days, just within the allowable time-frame.
Some warning signs included:
- unexpected AWS notification emails
- services appearing that I had not created
- unfamiliar activity appearing in CloudTrail logs
- increased billing due to new or existing resources being launched
This is common with automated attacks. Bots constantly scan the internet for exposed credentials or misconfigured systems. Once access is obtained, resources may be created quickly and often in regions the account owner does not normally use. Even old credentials/keys can be scraped from years before, then checked to see if still active.
These access methods and attacks appear to use more sophistication, perhaps as a result of AI intelligence, yet some of the activity still seems really weird.
Because AWS credentials can operate across multiple regions depending on permissions, attackers may deploy services across several regions within a short time.
I did not ignore anything, and worked hard for two days. It took many hours to develop new security steps for a new AWS Account and my apps. This was valuable as it is now applied to other client accounts.
How AWS Breaches Commonly Occur
Most AWS account compromises follow a small number of common patterns.
Exposed Access Keys
AWS access keys may accidentally appear in:
- GitHub repositories
- configuration files
- .env files
- public backups
- misconfigured web servers
- other security breaches
Automated bots continuously scan the internet looking for exposed credentials with emphasis on targeting major players like Amazon, Google, MS.
Weak or Reused Passwords
If the same password is used across multiple services and one of those services is breached, attackers may attempt to log into AWS using the same credentials.
Enabling Multi-Factor Authentication (MFA) greatly reduces this risk. I also use a passkey. I have asked all my clients to renew their passwords, and removed anything they do not use any longer. I have put in place tighter policies – e.g. IAM Roles, and Lambda.
WordPress WP Mail SMTP may store a password in the database rather than wp-config.php. I have introduced use of tokens in my WordPress contact forms. I have also developed a hook in wp-content/mu-plugins to intercept Contact Form 7 emails and divert through the AWS-SDK so that no keys are used with the plugin. These sorts of things take hours/days to develop and test, but a security breach gets the energy going.
Overly Broad IAM Permissions
Sometimes users or applications are granted full administrative access when they only need limited permissions.
If those credentials are exposed, attackers may gain control of the entire account.
Public Configuration Files
Web servers sometimes allow downloading sensitive files such as:
.env
.aws/config
application configuration files
If these contain credentials, attackers can gain programmatic access to AWS.
Old or Forgotten Credentials
Credentials created years ago may still remain active even though they are no longer used.
If these were exposed in the past, automated systems may eventually discover them.
Unused credentials should always be deleted.
Typical AWS Attack Pattern
Most automated AWS attacks follow a predictable sequence.
Credential Exposure
│
▼
Attacker Access
(API or Console)
│
▼
Privilege Escalation
Create IAM keys/users
│
▼
Resource Deployment
High CPU / GPU instances
│
▼
Cost Accumulation
Because these attacks are automated, they can begin within minutes of credentials being discovered. It is too fast to always immediately block, so up front prevention is now needed. We were reasonably safe prior, I believe, to 2025.
Working Through a Breach
The following suggestions are based on practical experience rather than official guidance.
Large organisations typically have dedicated teams monitoring their cloud infrastructure. Individual operators generally do not have that level of oversight.
Because AWS credentials can operate across multiple regions and services depending on their permissions, it is safest to assume that all credentials may have been exposed once a breach occurs.
Immediate Actions to Take
Secure the Root Account
Ensure the root account:
- uses a strong password
- has Multi-Factor Authentication (MFA) enabled (+passkey)
- has no active access keys
The root account should rarely be used for daily tasks.
Disable Email Sending Services
If you use Amazon SES, consider temporarily disabling:
- sending rules
- verified email identities
- SMTP credentials
- SES-related Lambda functions
Compromised email services may be abused for spam.
Review IAM Users and Roles
Remove anything you do not recognise:
- IAM users
- roles
- access keys
- unused policies
Only keep what is required.
Do not keep old SDK scripts – for instance, SDK2 and Node16x. Delete them. AI can help migrate, for example, from Node22 to Node24.
Stop Running Compute Resources
Stop all EC2 instances until you understand what is happening.
If instances contain important data, create snapshots before making major changes.
Unexpected compute activity is a common sign of compromise. You can view monitoring graphs, and the SES Dashboard.
Review DNS and Email Configuration
If SES was used for email relay, remove related DNS entries temporarily while investigating.
Backup Before Deleting Resources
Before removing services, keep local copies of:
- policies
- configuration files
- scripts
Manual backups can make rebuilding easier later. It takes time to collate this data.
Rebuilding Safely
In some cases, it may be easier to rebuild services in a new AWS account. I chose a new account.
This can involve:
- creating a new AWS account using a different email address
- enabling billing alerts immediately
- rebuilding EC2 servers
- restoring files and databases
- updating DNS records
- development of new, tight IAM roles, policies, Lambda functions and
- integration with new PHP scripts on WordPress if you wish
When rebuilding servers, ensure sensitive configuration files cannot be downloaded through the web server.
Examples include:
.env
configuration files
credential files
If these files are accessible, credentials may be exposed again.
Other AWS Services to Review
Depending on your environment, also review:
- S3 buckets
- EFS storage
- CloudFront distributions
- Certificate Manager
- WAF configurations
- Route53
Attackers sometimes create additional resources that are easy to overlook.
Monitoring and Investigation
AWS will typically send many automated security notifications during an incident. It can help to keep these organised in a dedicated email folder.
You may also be asked to review CloudTrail logs, which record actions performed within the account.
Monitoring tools such as CloudWatch alerts, CloudTrail logging, and billing alarms can help detect unusual behaviour early. Some monitoring costs too much for our size of systems. It may be safe to explore use of AWS GuardDuty.
Even simple alerts can provide early warning of suspicious activity. It takes time to develop our AWS skillsets within reasonable scope for our own abilities and time available.
Billing and Cost Recovery
A breach may result in unexpected charges.
AWS Support may assist with billing reviews if fraudulent activity can be clearly identified. Providing CloudTrail information can help when requesting credits.
However, outcomes vary depending on the circumstances. It is reasonable to request credits.
After the Incident
Once recovery is complete, some users choose to close the compromised account entirely and continue with a new one. I did.
While this may seem extreme, it can provide peace of mind that no old credentials or services remain active.
Building a More Secure Setup
Use IAM Roles Instead of Access Keys
Where possible, attach IAM roles to EC2 instances instead of storing credentials in applications.
Roles provide temporary credentials and reduce the risk of key exposure.
Separate Services
Keeping systems separated can limit damage if something goes wrong.
For example:
- internal system alerts – remove postfix, and use aws-sdk, e.g. did SSL renew?
- website contact forms – try adding tokens and attach an “assumed” role so only the WordPress contact Form can send email copies to the public.
- application-specific services
These can operate with different permissions or roles.
Now that MS Exchange is an example of the need for OAUTH2 instead of SMTP, we may need to review our email sending methods. It can be untenable to manage OAUTH2 when certificates expire if you do not have an MS primary account login. You could configure very tight SES configurations that relay application emails to MS Exchange.
Restrict IAM Permissions
Avoid giving services full administrative access.
Instead create policies that allow only the required actions.
This follows the principle of least privilege.
Rotate Credentials
If using SMTP credentials or API keys, rotate them regularly and delete unused keys.
Old credentials are a common source of compromise.
Old login passwords must be reset.
Remove Unused Resources
Delete:
- unused Lambda functions
- outdated runtime versions
- unused IAM users or policies
Unused resources increase security risk.
WordPress Considerations
If running WordPress:
- remove unused plugins
- keep plugins updated
- avoid plugins with known vulnerabilities
- use reCAPTCHA or similar protection for forms – e.g. Cloudflare
Old plugins that appear harmless can still introduce vulnerabilities. Check plugin reputation.
Software Maintenance
Systems should be kept updated.
Examples include:
- Linux operating system updates
- supported PHP versions – do not use php7.4
- updated application software
Old software versions are common targets for automated attacks.
Basic AWS Security Checklist
Before running services in AWS:
Account Protection
- enable MFA on the root account
- remove root access keys (that is, no public/secret keys)
- use strong passwords
Identity and Access
- use IAM roles where possible
- apply least-privilege permissions
- delete unused credentials
Monitoring
- review CloudTrail logging
- review CloudWatch alerts
- review GuardDuty
- create billing alerts
- add tighter Linix security services such as nftables, fail2ban, rate limiting even though this takes time and care for workable configurations
Infrastructure
- restrict security groups – e.g. SSH to your own IP address
- monitor regions you do not normally use
- remove unused services
Common AWS Security Mistakes
Many breaches occur due to a few common mistakes.
- No MFA on the root account – (a colleague had a client without MFA)
- Access keys stored in source code or documentation
- Giving full administrative access unnecessarily
- Leaving old credentials active
- Ignoring billing alerts or other alerts
- Running outdated software
- Allowing configuration files like .env to be downloaded
The AWS Shared Responsibility Model
AWS secures the cloud infrastructure itself.
Customers are responsible for securing:
- credentials
- configuration
- applications
- operating systems
Understanding this model is essential for running secure cloud services.
How to Lock Down a New AWS Account in 15 Minutes
When creating a new AWS account, spending a few minutes on basic security setup can significantly reduce risk.
Enable MFA on the Root Account
Immediately enable MFA using an authenticator app or hardware key.
Delete Root Access Keys
Ensure the root account has no API access keys.
Create an Administrative IAM User
Use an IAM user with MFA for daily work instead of the root account.
Enable Billing Alerts
Create a budget alert so unexpected costs are reported immediately.
Enable CloudTrail
Create a CloudTrail log so all activity is recorded. Review if costs are associated with this.
Restrict Security Groups
Only open network ports that are absolutely required.
Avoid Long-Term Access Keys
Use IAM roles where possible instead of permanent credentials.
Check S3 Public Access
Disable public access to S3 buckets unless it is explicitly required.
This cannot be understated. AI can help to write PHP scripts for websites to access bucket files with expiration time and unique URL’s.
Monitor Unused Regions
Attackers often deploy resources in regions you do not normally use.
Keep Systems Updated
Regularly update Linux, PHP, and application software.
Final Thoughts
Recovering from a cloud breach can be stressful and time-consuming.
However, many incidents ultimately lead to stronger systems once security practices are improved.
Most AWS compromises occur due to a small number of preventable issues such as exposed credentials or missing MFA.
Taking the time to implement basic security practices can significantly reduce the risk of future problems.
