On December 22, 2019 I received two phishing emails made to look like they came from AWS. This post will describe what I know about the attempted phishing and conclude with mitigations against phishing attempts to compromise your AWS accounts.

Neither email was very well crafted, and both were detected by gmail’s spam filters. When clicking on their links, they did show a well done copy of the AWS console login page, and the URL’s had been crafted to look like the real console login pages, with domains console.aws.amazon.com.console.home.2185421.niestas[.]de and signin.aws.amazon.com.redirect.https.254535.patrickniesters[.]com.

I reported both emails to AWS, which can be done by forwarding them to stop-spoofing@amazon.com, as described here. I also submitted both of those links to VirusTotal here and here, which at the time were not detected as phishing pages by any engines. Both sites were quickly taken down somehow, although from the VirusTotal history of those IPs, they continue to be used for other phishing campaigns.

I don’t normally get spam to the email address that received these, and this was the first phishing email I’d ever received to that email or that was made to look like an AWS email, so this was an interesting event. Unfortunately, I don’t know how this email address was targetted. I also don’t know what the goal of the attacker was. Maybe they were going to spin up EC2s to mine bitcoin, or maybe they would spin up AWS Marketplace resources which would more directly profit as explained by Daniel Hood in his recent article How to Embezzle Money Using Amazon AMIs. Or maybe there was some other purpose. I would have liked to have created a honeypot account with SCP restrictions to mitigate the costs to myself and monitor what the attacker attempted to do, but the campaign was shutdown before I was able to.

I did try logging into the phishing page with some fake credentials and found the page was setup to only allow logins with AWS root credentials, and did not ask for a 2FA code. The attacker could have easily requested a TOTP code though and quickly logged into my legitimate account with that. Using a U2F device (which is not phishable) as an MFA is in many cases preferred, but because AWS only allows a single mutli-factor device associated with the root user, most companies do not setup a U2F device for their root users, for fear of the single U2F being lost or broken.

Mitigations

General phishing mitigations and training have been written about by others many times before, so I’ll focus only on the AWS specific mitigations. To avoid the root account being phished, I recommend denying root login access entirely via an SCP. You can setup employee access to your accounts from an Identity Provider (such as Okta), where you can ensure your users use U2F authentication. Then in your AWS accounts, you can use SCPs to protect your Identity Provider integration. As a break glass account recovery plan, you could always remove the SCP that denies your root login, but that can be managed through a two person rule which can mitigate phishing risks by having two sets of eyes involved.

If your users are phished or their credentials are somehow compromised, GuardDuty is an effective solution for detecting unexpected logins and activities. Additional custom monitoring and IAM restrictions, such as restricting access to only those coming in over a specific VPN IP address, can also all help detect and mitigate phishing attacks against AWS environments.