Earlier this week, one of our employees received a phishing email to their personal inbox that attempted to lure them into providing their AWS login credentials. While the employee immediately recognized this as a phishing email, and we do not believe this was a targeted attack or a case of spearphishing, we began an investigation due to our interest in cloud-related cyber activity. 

We were ultimately unable to identify the goals of the attacker in this case (for reasons that will be explained shortly), but we wanted to make available the relevant details and indicators so that others could check if they were affected. Additionally, we decided to take this opportunity to discuss how AWS customers can defend themselves against similar phishing attempts. 

Overview 

The phishing email simply contained a PNG image that when clicked would take the victim to https://giraffe-viola-p262.squarespace[.]com/ and then through a series of redirects to a PDF viewer. The sender’s email address was admin@alchemistdigital[.]ae, and the domain is listed in open-source threat intelligence as known for distributing malware. The email message itself was sent via Amazon SES, meaning that the threat actor was using an AWS account for this purpose (one we can assume to be owned by them or compromised by them).

The PDF file was hosted on a file sharing site (e.pcloud.link) with a built-in PDF viewer. The ”Invoice Summary” link in the PDF would lead the user through a chain of redirections, starting with a link to https://cli[.]re/j9PQ88, which uses a common link shortener service, leading to https://console.aws.consoleportal[.]tech/IgXlrDYW, an attacker-controlled domain, before reaching the final credential harvesting page (https://signin.aws.consoleportal[.]tech/signin). As of today, Google Chrome browser detects this as a phishing page, but this should not be relied on as a sole security measure, especially if other browsers are being used.   

The credential harvesting page that we were ultimately directed to was a visual clone of the current AWS sign-in page, and the page’s URL was also designed to mimic the legitimate AWS login page: 

https://signin.aws.consoleportal[.]tech/signin?redirect_uri=... 

Compare this to the genuine login page:  

https://signin.aws.amazon.com/signin?redirect_uri=... 

This page loads a JavaScript script hosted at https://d35uxhjf90umnp.cloudfront[.]net/index.js, which might be attacker-owned, or perhaps associated with the same AWS subscription that the threat actor is using for SES – we have yet to confirm this possibility. 

We attempted to feed credentials to the phishing page associated with a honeypot environment we set up, but interestingly the page would throw a 400 error unless we entered the email address of the originally intended victim. While discussing the idea of setting up the employee’s personal AWS account as a honeypot, the login infrastructure of the attacker had already been taken down, so we were unable to fully investigate the intent of the attacker.   

It’s unknown to us what caused the phishing page to be taken down when it did, but the original email had already been promptly sent to stop-spoofing@amazon.com as an early step of our investigation, and Chrome was already blocking the page (as mentioned above), so it’s possible AWS or Google had been involved in the take-down.  

Which actions should security teams take? 

Phishing emails are a very common occurrence, and while our colleague didn’t click through this time, it’s never an employee’s fault if they do take the bait and the organization is compromised as a result– organizations must be secure enough so that one employee’s honest mistake doesn’t have disastrous results. So how can AWS customers protect themselves from this scenario? 

Secure Configuration 

For starters, AWS account root logins should be disabled via an SCP, as we’ve described in our guidance Using Service Control Policies to protect security baselines. AWS Organization Management accounts will still allow root logins, so you should ensure you have phishing-proof MFA for those accounts, meaning you should use FIDO security keys as opposed to solutions that involve entering a code which an attacker could replay. 

User authentication should be done through SSO solutions instead of IAM users or root logins to access cloud environments. This will help you more easily enforce additional authentication requirements, along with other user management benefits.   

Least privileges strategies should be used to not only minimize the risk if a user is compromised, but access should also be limited to critical accounts to a minimal set of employees, such as the root user of an AWS Organization Management account.  

Cloud Logging

Cloud logging services such as Amazon CloudTrail should always be enabled. They are an essential tool for assessing the impact of compromised credentials within cloud environments. They allow security teams to identify affected resources, understand the scope of the breach and implement effective remediation strategies to bolster their security posture and prevent future breaches. 

Related infrastructure 

The phishing domain (consoleportal[.]tech) currently resolves to CloudFlare, but by using Validin’s historic DNS search, we were able to pivot on the domain to find 2 unique IP addresses to which it previously resolved (as of 2024-08-02): 

• 162.0.216[.]98 (Namecheap) 

• 185.170.198[.]250 (Hostinger) 

We then searched for other domains that resolved to those same IP addresses and thereby identified 3 additional domains that also appear to be utilized for AWS phishing based on their sub-domain format, such as signin.aws.{domain}, portal.aws.{domain}, console.aws.{domain}, etc.: 

• officequalcomm[.]com 

• webportal[.]tech 

• docshare[.]tech 

These IP addresses resolve dozens of additional domains that appear suspicious, but we have yet to confirm that they are malicious.  

Additionally, using Validin’s lookalikes search feature, we were able to identify several domains mimicking amazon’s login page. While these domains are not necessarily operated by the same threat actor, we do believe they are likely to be utilized in phishing campaigns, and the subdomain format appears to be a strong indicator of malicious intent: