On March 8, my AWS administrator account was compromised and someone used its role to launch an EC2 instance with full privileges. I deleted the exposed access key and the activity stopped. I did not find credentials in my terminal history or AWS credentials file, and I have not noticed anything suspicious on my Mac or in my other accounts. I also have not used pirated software. In the past, I stored credentials in a Windows Notepad file that was uploaded to Google Drive, although the problem only appeared after I started using AWS from my Mac. I have since deleted the old IAM users and roles and enabled MFA. I would like to continue using AWS for learning on the same computer, but I am worried that creating another role or user capable of launching EC2 instances could lead to another compromise. What is the safest way to use the AWS CLI and prevent this from happening again?
4 Answers
If you must create an access key, never give it administrator permissions. Grant only the specific actions and resources needed, and consider conditions such as an allowed source IP where practical. Store secrets in a proper secrets manager or secure vault, not in text files, code, environment dumps, or cloud-synced notes. Also check old Git repositories and their full history, backups, shared drives, shell files, configuration files, and browser extensions for remnants of the key. Removing a secret from the latest file does not remove it from repository history.
Using AWS Systems Manager to access an EC2 instance is generally safer than placing long-lived AWS keys on the instance, provided the instance has a narrowly scoped instance role and the Systems Manager permissions are restricted. Do not put administrator credentials in application files or use access keys to let an instance access AWS. For learning, use a least-privilege role, permission boundaries where appropriate, MFA for privileged actions, and alerts for unusual regions, instance launches, or spending spikes.
That helps clarify the distinction. I was concerned that using Systems Manager itself was unsafe, but the bigger issue is the scope and lifetime of the credentials and the permissions attached to the instance role.
Treat the old credentials as permanently compromised and rotate or revoke every related key, session, and secret. For normal CLI work, use AWS IAM Identity Center or another SSO-based login that provides short-lived credentials instead of creating permanent access keys. Enable MFA, preferably with a phishing-resistant hardware key or passkey, and avoid using the administrator identity for everyday tasks. If you only need to experiment, create a separate account or sandbox with spending limits and tightly restricted permissions.
I had enabled MFA, but I was still using long-lived access keys rather than SSO or temporary credentials. I will switch to a short-lived login and keep the learning environment separate.
Use CloudTrail and the billing and security dashboards to reconstruct what happened. Look for the first suspicious API call, source IP, user agent, region, credential type, and any other resources created. That can help distinguish a leaked key from a stolen session or a compromised local environment. Check for unexpected IAM users, roles, policies, access keys, Lambda functions, startup scripts, security-group changes, and resource-based policies. If you cannot explain the exposure, treat the computer and every location where the credentials existed as potentially unsafe and rotate credentials from a trusted device.
A credential scanner can search repositories and other files for leaked keys, but scanning is only part of the fix. Any key that was ever exposed should be revoked rather than merely deleted from the file.