CybrCTF: IAM Escape Room

Ano1X8
5 min readOct 27, 2024

--

As promised, the final challenge to the amazing course IAM Privilege Escalation on https://Cybr.com

This course was a fantastic learning experience, and wrapping it up with this capstone project made it even more enjoyable. It perfectly reinforced everything we learned along the way.

Let’s get into it

Again, well worth the subscription!

As we’re waiting to get our keys and configure our profile, let’s take a look at the brief:

Remember, ethical

Great, pretty straight forward and definitely something I’ve experienced working as a (security) System Admin. Insider threats are no joke and I’ll avoid sharing personal stories/opinions, because that could be another write-up.

Now that we have our keys, let’s configure our profile and get to enumerating:

5 users: Emma, Harper, Jim, Kevin, and Mike. Sticking to my methodology, let’s see if we can find any policies, then move on to groups.

Permissions Boundary Error — Not allowed to list-attached-user-policies

Nothing useful and now moving onto groups:

Groups & Group Policies
Listing to see Users in which Groups

There we go, we found 2 groups: Developers and Infrastructure; let’s first take a look at Developers and see what it entails:

DefaultVersionID v1

Perfect, we’ve seen this before, let’s enumerate this a bit more and see what we’re allowed/not allowed to do:

2 Version Ids for Developers & iam:SetDefaultPolicyVersion / PutGroupPolicy

Taking a look at the v2, I did leave some info out for screenshots sake, but we have what we need here, for now with those 2 pols, and we still have another group to enumerate:

Infrastructure Group, with info left out

Diving a bit deeper and sorting for higher privileges/permissions, we come across exactly what we’re looking for.

Boom!

Now, we know where to go, I think we’re pretty good here with enumerating, so now, let’s start chaining our attacks together.

I kind of skimmed over it before, but now since we can see everything in front of us, here’s a breakdown of what we just found and what we’re going to do:

First, let’s go back to the SetDefaultVersionID, since we saw v2 grants us higher privs, and we can set it ourselves no problem, we’re then essentially granted the ability to PutGroupPolicy, which is straight-forward as that, adding our custom Allow * policy and it’s gameover at that point. From there with our upgraded policies, we’re going to create access keys and login as a user to the Infrastructure group; pretty cheeky huh, I talked and you read enough, let’s get in:

Setting VersionID to v2
Putting our Allow * policy into Developer Group
Policy we Put to Group

So now what? We still need to find our way into the Infrastructure group in order to access the right S3Buckets (I intentionally left the wrong bucket out of the 1st photo). We know whom belongs in which group, we know we need to be in that Infrastructure group, and we know we have free range, why don’t we just create new keys for our users already in Infrastructure.

CreateAccessKey; either Mike or Emma will do, since they’re both in Infra

Awesome, now that we have our new keys, let’s configure a new profile, verify whom we are, and get to some secrets:

Secrets Found!

An incredibly fun challenge that put every lesson to the test and wrapped up an amazing course that I learned a lot lot from.

In my previous write-up, I included a link of major cloud breaches and it’s absolutely not far off to think there orgs running with some serious misconfiguration/overly permissive problems, paired with not deleting default versions and failing to audit their environment; which unfortunately affects them, you, just about all involved.

Now, I promise I wouldn’t get on my digital soapbox, so let’s just hop to preventing something like this from happening.

Mitigations:

Be mindful when using DefaultVersionID, make sure you’re managing versions, getting rid of ones that maybe you started out with and no longer using, especially with higher privs/perms; remember this is essentially what allowed us to kick off our attack.

Handling misconfigurations/too many privileges, as we saw with PutGroupPolicy, we literally just handed ourselves keys to the kingdom, literally, with CreateAccessKey, we were able to create new keys with a user in the group we’re needing to use, in order to gain permission to list/download from buckets.

Audit!

Monitor!

Insider threat(s) is a unique/dynamic situation that ranges in a wide variety of reasons as to why an employee would want to steal/alter information…again, not going on a rant here.

Instead, I want to thank Cybr.com very, very much, I enjoyed every minute of this course and next up is IR in AWS and then going to start taking AWS certs.

Incredible sources that helped me throughout this course:

https://cybr.com (obviously)

https://cloudsec.cybr.com/aws/aws-native-security-services/

https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/

--

--

No responses yet