Security operations · 4 MIN READ · SIMON WONG AND EMILY HUDSON · FEB 1, 2022 · TAGS: Cloud security / MDR / Tech tools
The Expel Phishing team spotted something …fishy… recently.
We came across a less common but well crafted Amazon Web Services (AWS)-themed phishing email that targets AWS login credentials. These emails have been reported in the past by security practitioners outside of Expel, but this is the first time our security operations center (SOC) encountered this technique.
Now that we’ve seen this tactic in the wild, we wanted to share what we learned about this attack and how our SOC analysts triage malicious emails here at Expel.
Expel’s Phishing team reviews hundreds of emails a day and thousands of emails on a weekly basis; the vast majority of malicious emails we encounter are credential phishing attacks that are Microsoft themed.
Why are they often Microsoft themed? We think it’s because Microsoft and Google have dominant market share and both tech giants have highly reputable brands. Their cloud platforms and offerings are reliable cloud infrastructures, which cover most businesses’ needs – like email, communications, and productivity applications.
So this attack was interesting to us. Similar to Microsoft and Google, AWS is a popular cloud platform. If attackers were to obtain AWS credentials to an organization’s cloud infrastructure, this can pose an immediate risk to their environment.
On January 26, 2022, our customer’s user submitted a suspicious email for review. We picked it up and immediately turned the email into an investigation based on some highly suspicious indicators (we’ll dive into those below) that were surfaced to our analyst by one of our bots, Ruxie™.
Based on these leads, we decided to dig into the submitted email for a closer look.
How we triaged
The way we triage emails here at Expel can be different from other managed security service providers. We use our platform, the Expel Workbench™, to ingest user submitted emails. From there, based on detections and rules created by our team, the Expel Workbench gives context for why the email is suspicious. This context provides decision support for our analysts as they review the email.
That way the analyst can focus on applying what we call OSCAR (orient, strategize, collect evidence, analyze, and report), and perform analysis with decision support from our bots. We walked you through how Expel analysts use OSCAR in a previous post here.
Here’s what we can capture from our initial lead by applying OSCAR.
- By orienting, we notice that Ruxie™ surfaced a suspicious link that isn’t related to Amazon. And within the screenshot we noticed some poor grammar – there’s no space in between “account” and “requires.” We’ve also noticed these bad actors are always cordial by making use of words like “kindly.”
The image below is a screenshot of the suspicious email.
Suspicious email submitted to Expel Phishing
- Let’s strategize next! There are two common phishing tactics we see when it comes to phishing. One is suspicious hyperlinks and the other is file attachments. In this case, Ruxie informed us that there’s no attachment. But there’s a suspicious hyperlink that needs to be reviewed.The image below shows the suspicious link surfaced by Ruxie in the Expel Workbench.
Expel Workbench initial alert
Next step: let’s collect evidence.
Wow, these bots are really helping us out here! Without the need to download the email file and open it in an email client for analysis, our bots do all the heavy lifting for us.
Here Ruxie™ surfaces the URL, recognizes that there is a partial base64 string which looks to be an email address, and sanitizes that email address. Awesome!
Ruxie actions in the Expel Workbench
Can you still analyze malicious emails? Absolutely!
We’ll show you how to do this by using free tools like a simple web browser sandbox and the built in developer tools, which is one of our favorite methods of analysis. We recommend using Browserling, as this provides you with a safe environment to analyze suspicious hyperlinks.
We’ll be using Mozilla and it’s developer tools as the web browser in this example. Follow these steps to access the developer tools:
- Navigate to the malicious domain.
- Let the landing page load. Note that this page is convincing if you’re not careful, since the threat actor has cloned the page.
Fake AWS sign-in page
- Enter the faulty credentials: firstname.lastname@example.org
- Navigate to the browser’s developer tools.
Mozilla developer tools navigation
Here is a side-by-side comparison of the two pages. As you can see, they’ve cloned the AWS login page. If a user isn’t careful in reviewing, they’ll fall victim to this attack.
Left: Real AWS login page. Right: Fake AWS login page
There are few important HTTP methods, like “GET” request, you can use when you’re attempting to get data from a web server.
But what about when you’re investigating where credentials are being stored? You’ll want to follow the “POST” request traffic. This HTTP method is used to send data to the web server and most commonly used for HTTP authentication with PHP. After entering phony credentials we see the “POST” request is storing the credentials to the same domain. Now we can scope using this indicator as evidence to identify potential account compromises.
Mozilla developer tool
In addition to our awesome bots (can you tell we love our bots here at Expel?), we also have automated workflows that are built into the Expel Workbench™ that can help our analysts be more efficient by reducing cognitive loading for triaging emails.
By running our domain gather query we observed no evidence of traffic to the malicious credential harvesting domain, which suggests no signs of compromise! Whew!
Last but not least, we can now record that there was no evidence of compromise in our findings as a part of the investigation.
Ruxie analysis that displays any POST requests made to the fake AWS webpage across the customer’s environment
Although tech is great and can help us be more efficient at running down investigations related to credential harvesting, it’s not always necessary and we can still achieve the same goal manually. The technique we just walked you through in this post can be applied to triaging any suspicious credential harvesting email.
How you can keep your org safe
AWS users are just as vulnerable to credential phishing attacks as Microsoft users. And if an AWS user falls victim to phishing emails and social engineering techniques, putting their credentials in the hands of an attacker, there’s a chance you’ll be dealing with a cloud breach.
Here are a few ways you can remediate if your AWS account was compromised:
- Reset Root/IAM user credentials.
- Disable, delete, or rotate access keys.
- Audit permissions and user activity through the use of CloudTrail.
- Enable AWS multi-factor authentication on user accounts.
We hope you found this post helpful! Have questions or want to learn more about how the Expel Phishing team works? Let’s chat (yes – with a real human).