Get Phished by a Public AWS Systems Manager Automation Document

You've probably heard the buzz about AWS unveiling the new Nova models at re:Invent 2024. Among them, the Nova Premier model stands out as the crown jewel—even though it’s still in training.

Curiosity piqued, you start searching online and stumble upon a post from someone sharing a link to the AWS Console. The link appears to be a secret but public AWS Systems Manager document, purportedly used by internal staff to grant access to selected alpha testers for the Nova Premier model.

The URL looks legitimate, as it's point to a real AWS Console URL, with the document ARN pre-filled:

https://us-east-1.console.aws.amazon.com
  /systems-manager
  /automation
  /execute
  /arn%253Aaws%253Assm%253Aus-east-1%253A123456789012%253Adocument%252FAWSBedrock-SetupNovaPremier
    ?region=us-east-1

You notice the automation runbook is named AWSBedrock-SetupNovaPremier, which seems credible since many Automation documents start with AWS-.

Without thinking twice and because of your desire for the unreleased alpha Nova Premier model, you clicked the orange Execute button - and you will soon regret it.

Guess What You Are Phished

Imagine you’re an AWS user excited about the new Nova Premier model. You click on what you believe to be a legitimate link to gain early access. Unbeknownst to you, this link executes a malicious SSM document that could:

• Grants unauthorized access to your AWS resources.
• Exfiltrates sensitive data.
• Deploys malware within your AWS environment.

By the time you realize something is wrong, the damage is already done.

I successfully created a proof of concept that allows a victim AWS account to execute a public AWS SSM Automation Document created by the attacker account, that creates an IAM user:

How Did the Attack Happen?

The attack leverages the trust users place in AWS Console links and Systems Manager documents. By crafting a URL that mimics a legitimate AWS-owned AWS Systems Manager Automation Document, attackers can trick users into executing malicious code. In this case, the link points to an SSM document that appears official but is actually designed to compromise the user's AWS environment.

What could have avoided the attack?

1. Awareness is Key: Phishing can occur even with valid AWS console links. Just because a link appears to be from the AWS Console doesn’t mean it’s safe. This technique can also be applied to EC2 AMIs or Lambda Layers as both resource could be shared publicly.

2. [SSM Specific] Check the Owner: Always verify the owner of an SSM Document before using it. Ensure it’s either "Amazon" or your own AWS account ID.

3. [For AWS] Enhanced Warnings: AWS Console should display a prominent warning when a user attempts to execute an Automation document that is not owned by AWS or the underlying AWS account.

4. [For AWS] Prefix Blocking: Consider blocking creation of documents that start with the AWS prefix - on top of the fact that documents with the AWS- prefix are already blocked according to AWS documentation

5. Refine permissions to execute SSM Automation Documents, or even avoid granting such permission in the first place.

That's it!

Hope this article does remind you to triple check any AWS Console URLs before you make any action on it!

Disclaimer: Nova Premier has not yet released at the point of writing, and this article does not encourage any phishing/illegal activity. The PoC was created for illustration purpose only.