AWS Phishing: Four Ways

Dec 24, 22

10/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.

A Figure from the DBIR showing phishing as the second most common cause of breaches
source: Verizon DBIR 2022.

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”.

Account requires verification phishing email screenshot Page spoofing AWS signin for root user Amazon $1000 payment spam email screenshot Spoofed support case Phishing email requiring account validation Spoofed support case Payment error email Page spoofing AWS signin
Some sample AWS Credentials phishing emails, see:Further Reading.

Beware, search advertisement hijacking of the AWS console by credential phishers has also been observed recently (h/t Jared Perry):

screenshot of a google search result containing a phishing page ad for the term 'aws console'
Google Search Ad Hijacking

Prevention & Detection
General phishing mitigations apply.

Further Reading

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.

screenshot of device code ui
Device Code confirmation prompt.

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 and sso-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

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.

screenshot of launch stack wizard
Launch Stack URL UI

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
screenshot of an email verification email from ACM
ACM Email Validation h/t https://romandc.com/zappa-django-guide/aws_acm/

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:

  1. 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
  2. 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
  3. 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!