AWS Security – Account Breaches
This article 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.
To meet AWS Accounting requirements, new and existing tools have been provided, and basic security steps that we need to put in place.
Amazon monitoring tools have associated costs we wish to avoid. You may explore AWS CloudTrail, (see YouTube videos), however, a basic setup that we can afford, that meets AWS requirements, is to enable GuardDuty in the region of concern, then disable all the options one by one – namely, S3, EKS … through to Lambda. This leaves us with core protections.
The other Amazon requirement is to set a Billing Budget Alert. This can be done from the Account dashboard.
The remaining security approaches are highlighted below in terms of an account breach.
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 experiences concerning multiple site breaches since 2025, and may help others facing a similar situation.
This article does not provide example code, but new code may be developed with the assistance of AI. This takes time to implement and test. This includes ability to remove Postfix, only using the AWS-SDK for email admin/alerts from a Linux instance; Removal of AWS credentials from an EC2 instance (e.g. ~/.aws/credentials_; Protection of application config files such as .env, via Nginx or Apache2; An approach for IAM Roles being unique and segregated when attached to EC2 instances (i.e. not the same IAM Role on different instances), with restrictions on policies and Lambda functions for both S3 Buckets and SES.
Cloud security is complex and constantly evolving. The observations here may not cover every situation. (I have no AWS certificates or qualifications.)
What a Breach Actually Looks Like
A breach may commence with odd behaviour, such as an email requesting DKIM access to another domain from another AWS Account ID.
If spam emails are sent to the public, it may be an email service provider who alerts Amazon to complaints. If one is not reviewing the SES Dashboard each day, it becomes apparent we need automated monitoring.
Once a breach occurs, things happen fast, but the breach can in itself take up to 24 hours to deploy fully. We can review CloudTrail logs to see bad activities, but again, without monitoring alerts, this does not really help.
It is reasonable to close an account after a breach, but Amazon uses Global Credentials, meaning account closure does not stop ongoing costs incurred from more breaches. If, for example, SES is using the sending quota each day, SES has to be shut down first.
A full closure of all services is needed before removing an account. Then, the account should stay open while submitting any support tickets for Account Credits on unauthorised use. The biggest problems with closure is that many configurations need manual cut and paste to your local PC so that you can restore on a new account. This takes more time than downloading files and databases. The other problem is when you have a fully paid Reserve Instance that you do not want to lose. By incurring cost loss, one is driven to come up to speed with security measures in a world of higher risk and threat.
Some breach warning signs include:
- unexpected AWS notification emails
- services appearing you 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.
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 risk and a passkey. All clients must renew their old passwords, and removee anything they do not use any longer. Tight policies must be in place, rather than open ended policies with full access – e.g. IAM Roles, and Lambda.
WordPress WP Mail SMTP may store a password encrypted in the database rather than visible in the wp-config.php. One can introduced use of tokens in WordPress contact forms with AI help. We can develop hooks in wp-content/mu-plugins, such as intercepting Contact Form 7 emails and diverting 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 not 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 or permanently 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 a breach is noted by AWS Security, be aware that they will block particular services, but not necessarily the services causing public intrusion and costs. So, if you stop an instance, it may not start again.
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.
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 will be exposed again due to bot activity.
Bot activity can be reduced in the Linux servers themselves.
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. CloudTrail has a cost for additional features. It is now activated by default for “basics”. You may try to identify a bad actor’s IP address or other details in these logs and provide to AWS Security.
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 should be safe to use AWS GuardDuty’s core monitoring. You can review your billing costs during the month.
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.
While this may seem a major step, 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 – use the SDK to send admin an email.
- website contact forms – try adding tokens and attach an “assumed” role so only the WordPress contact Form can send email copies to the public. DO you need to send email to the public? Some apps require it.
- 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 difficult to manage OAUTH2 when certificates expire if you do not have an MS primary account login. You could configure tight SES configurations that relay application emails to MS Exchange. For example, configure the SES domain and email identities for support@app.mydomain.com to go through the SES relay to support@mydomain.com where domain.com is primary on MS Exchange. This means you are not configuring MS Exchange on AWS Linux. WE need to think about these scenarios.
Restrict IAM Permissions
Avoid giving services full administrative access. e.g. policies for AdminAccess, S3FullAccess and so on.
Instead, create policies that allow only the required actions. You can restrict policies to the SES verified domain and email addresses, rather than using “*”.
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.
All use of Roles, Policies, Lambda Functions and SES needs careful consideration.
A common mistake is to open an S3 Bucket to the public. These must be private. A website may still use S3 files and images through AWS-SDK scripting that works in conjunction with the attached EC2 IAM Role. AI can assist in the development of such bash scripts and PHP programs.
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.
