AWS Phishing: Four Ways
Dec 24, 2210/20/23: I’ve published a fifth phishing threat - AWS SES Phishing
I’m a bit obsessed with the real world threats against cloud-native environments.
Phishing is in many ways a generic risk. The Verizon 2022 DBIR pegs it as the second most common cause of breaches. It’s also in the top three MITRE ATT&CK initial access techniques observed across all incidents in Cyentia IRIS.
There are a variety of common phishing tactics. Ichthyology: Phishing as a Science creates a three category taxonomy for phishing:
- Action phishing: tricking a target into providing information that is in itself valuable, or to take a particular valuable action
- Exploit phishing: delivering an exploit targeting unpatched machines or 0 day vulnerabilities
- Credential phishing: harvesting credentials for online services, which can then be maliciously accessed as a direct source of information, or as a method of pivoting from one service to another
However, the cloud opens the door to more specific, and in some ways more sophisticated, risks. This post serves to compile four AWS-specific phishing vectors.
Remember, if you get an AWS-themed phishing email you can report them to AWS online or via email at stop-spoofing@amazon.com. Phishing is a general risk that primarily resides on the customer side of the shared responsibility model. This post does not describe any vulnerabilities in AWS itself.
Credential Phishing
I lied, this one isn’t really AWS specific. As with any major service, attackers will attempt to spoof AWS sign-in pages in order to steal credentials. Better phishers can also capture TOTP or SMS MFA.
Common, commodity lures are shown in the following gallery and among the Further Reading. They include “Account Verification”, “Account Suspended”, “Security Notification”, “Billing Notification”, and “Support Case”.
Beware, search advertisement hijacking of the AWS console by credential phishers has also been observed recently (h/t Jared Perry):
Prevention & Detection
General phishing mitigations apply.
- Use WebAuthn. Everywhere. Like the teams at Figma, Gitlab, Palantir, Cloudflare, and Panther.
- Configure your email provider with Advanced phishing and malware protection (Google) or the Microsoft Defender for Office 365 Security Operations Guide (o365).
- Consider layering in a modern email security platform, or if that’s not an option, a legacy Email Security Gateway.
- I’m not a fan of phishing simulation (see some research on its efficacy), but if you’re going to do it you could do much worse than following in the Behavioral Engineering footsteps of the Paranoids.
Further Reading
- Ichthyology: Phishing as a Science
- Expel: Attack trend alert: AWS-themed credential phishing technique
- Summit Route: AWS Phishing Emails
- Rhino Security Labs: MFA Phishing on AWS
- https://twitter.com/chrisdoman/status/1271053073591517189
- Cado Security: An Ongoing AWS Phishing Campaign
- https://abnormalsecurity.com/blog/amazon-web-services-phishing
- https://www.mailguard.com.au/blog/amazon-web-services-aws-account-suspended-email-phishing-attack
- https://twitter.com/boyney123/status/1410854049050660867
- https://twitter.com/yoimbert/status/1422123596131012614
Device Authentication Phishing
AWS SSO implements OpenID Connect device code authentication, leaving it vulnerable to device code phishing. This is the form of authentication you’ll encounter when interfacing with AWS SSO from a CLI. An attacker who knows the AWS SSO URL of the victim organization can initiate the flow, and just needs to convince an authenticated user to accept the associated prompt. At this point the attacker can retrieve an SSO access token, valid for 8 hours. This attack is not preventable with MFA, including hardware MFA.
Prevention & Detection h/t Christophe! with inspiration from AADInternals
- Block and alert on
device.sso.{region}.amazonaws.com
links on your e-mail gateway. - Alert when different source IPs generate
sso:ListApplications
andsso-oidc:CreateToken
events for the same user within a short time interval. - Alert when the volume of
sso:ListAccountRoles
events is unusually high for a specific user.
Further Reading
- Phishing for AWS credentials via AWS SSO device code authentication
- AWS SSO Phishing
- On-device WebAuthn and what makes it hard to do well
- OAuth 2.0 Device Authorization Grant: Section 5
CloudFormation Stack Phishing
CloudFormation supports “Launch Stack” URLs of the form https://console.aws.amazon.com/cloudformation/home?region=region#/stacks/new?stackName=stack_name&templateURL=template_location
.
Per AWS:
Anyone who follows that URL is directed to the Create Stack wizard in the AWS CloudFormation console, with the specified stack name and template location, as shown in the following screenshot. Users can still specify parameters or other stack options. If they are not already authenticated, users are directed to the AWS Management Console sign-in page and then redirected to the AWS CloudFormation Create Stack wizard.
Attackers can leverage this for phishing by sending a premise that attempts to trick an authorized user into deploying a malicious Stack. This attack is particularly pernicious, as the UI by default only shows the stack name and template URL - both of which can easily be made to impersonate trusted sources.
Prevention & Detection
- If you are not using Cloudformation, consider disabling it with an SCP.
- If you use Cloudformation, consider limiting template sources via the
cloudformation:TemplateUrl
Service Specific Condition. - Reduce or elimate the number of users who “daily drive” an account with permissions to create resources in production contexts.
Further Reading
ACM Email Validation Phishing
AWS ACM supports a common model of Domain Control Validation - “Receive a CA-provided challenge at (hopefully) a administrator-controlled email address corresponding to the domain, and then respond to it on the CA’s web page.” rfc8555
AWS documents this procedure as follows:
Before the Amazon certificate authority (CA) can issue a certificate for your site, AWS Certificate Manager (ACM) must verify that you own or control all of the domains that you specified in your request.
…
ACM sends email messages to the three contact addresses listed in the WHOIS database and to five common system addresses for each domain that you specify. … To validate, you must act on one of these eight messages within 72 hours.
…
Email messages are sent to the following three registered contact addresses in WHOIS:
- Domain registrant
- Technical contact
- Administrative contact
Messages are additionally sent to “five common system addresses” based on the MX record:
- administrator@your_domain_name
- hostmaster@your_domain_name
- postmaster@your_domain_name
- webmaster@your_domain_name
- admin@your_domain_name
The email will be sent by no-reply@certificates.amazon.com with the subject “Certificate request for {domain}”, and in the case of phishing the “AWS Account ID” will reference an attacker-controlled account. Approving this request will grant an attacker a valid certificate for the relevant domain
Prevention & Detection
- Tightly control access to the email distribution lists or addresses associated with your domains.
- Educate any employees with access to those email inboxes of the risks of Email Validation phishing.
- Consider exclusively using DNS Validation in your organization, and then block and alert on emails matching the ACM Email Validation sender and subject line links on your e-mail gateway.
- note: Because the certificate issuance request will originate in the attacker account, IAM or SCP controls are not viable to prevent email validation.
- Speak to your AWS TAM or Support to understand other options that AWS may offer for hardening ACM certificate issuance.
Further Reading
Intentionally Omitted
There are a few adjacent risks called out during review of this post that bear a mention:
- Attackers can also use AWS (like any other provider) to host phishing. e.g dagrz calls out s3 bucket websites as a phishing vector back in 2016, Scammers Use Amazon Web Services in Phishing Campaign
- Attackers use SES in compromised accounts to send phishing emails. e.g Kaspersky’s stolen Amazon SES token used in Office 365 phishing, Compromised Cloud Compute Credentials: Case Studies From the Wild
- An attacker who succeeds in subdomain takeover can use the reputable domain in targeted phishing.
Thank you to Christophe Tafani-Dereeper for the extensive review and recommendations, as well as Scott Piper and Chris Farris for their early feedback!