Okay, so FLAWS2 Defender path isn’t like a challenge, more like a walkthrough. Just has a set of instructions that explains how security works in AWS and what exactly was compromised.

We’re given a set of credentials for “security” and the first thing we are asked to do is download the CloudTrail logs.

This account has access to “flaws2-logs” bucket which obviously contains the logs for flaws2 challenge.
aws s3 — profile defender sync s3://flaws2-logs .

This downloads those log files into the current directory.

Of course, these can be accessed through the AWS dashboard too.

Next I’m asked to add another profile with the “security” profile as it’s source. The purpose for doing this was that it’s a common practice to keep a separate account for keeping Cloudtrail logs which also has some access to other accounts. The interesting thing about this “source profile” is that it’s like a temporary profile and since this account has this `sts:AssumeRole` privilege I can request access for certain roles for this temporary account that I’m about to create.

For creating this temporary account, I simply have to add another section inside “~/.aws/credentials”.

It doesn’t have access to those logs bucket, however it seems to have similar access to S3 buckets as the attacker account.

Now back to those logs (those json.gz files), after unzipping and taking a look at those I think those are from way back when this challenge was created. The “EventTime” here is from 2018.

The website says,

These are logs basically about how AWS works, and not any actions anyone did.

So what it means is that these logs just describe what has happened with this accounts, like what services/roles were configured or used stuff like that.

Next part is tracing the attack back to its origins. This time I’m looking at all the “ListBucket” events.

By the way, I have to say this “jq” tool is really powerful. It makes looking at these JSON files so convenient.
Anyway, looking at these logs, it’s quite clear who was trying to “ListBuckets”.

So, it turns out “level3” role was used by someone to perform this action. According to the response from aws-cli, this role is supposed to be used by ECS to call AWS services, but the IP present in the logs is not an “AWS IP”.

I found these IP ranges from AWS docs, there were a ton of ranges. So I did not bother to check these and decided to believe in FLAWS. I’ll probably look into it later on.

Normally, you’d see the resource (the ECS in this case) having made AWS API calls from it’s own IP that you could then compare against any new IPs it may have made.

This seems like a pretty standard approach, I should keep this in mind.

These are the actions I performed while I was solving the attackers path. Although these aren’t my logs, but someone did something similar, back in 2018.

Here, the “Principal” is set to \*, which now I know, means that these actions can be perfomed by everyone because the ECR is public.

To prevent something like this from happening “CloudMapper” must be used to identify all the public resources.

The next part was just doing the same thing but using Athena, which essentially uses SQL queries to query these logs.
With this, I’ve completed this FLAWS challenge. I may mess around with AWS services for a while to better understand things and actually try to use these techniques on my own deployments.