How to Find New Attack Primitives in Microsoft Azure

Microsoft’s cloud services revenue grew 46% in the first quarter of 2022, and its cloud market share has increased by almost 9% since 2017. With Azure finally being used in earnest by the mainstream, now is the ideal time to get involved in Azure abuse research. There are many undiscovered abuse primitives out there, a lot of misconfiguration debt built up, and growing numbers of adversaries starting to target Azure more seriously.

Why spend time looking for abuse primitives rather than bugs or software exploits? Abuses have a much longer shelf life than bugs and zero-days, and they’re cheaper to maintain. More importantly for attackers, they exist in nearly all implementations of the software in question and are much harder for defenders to detect and block. That’s why it’s vital for researchers to uncover new abuse options so they can be fixed or mitigated.

Here’s my five-step process for researching a specific system within Azure and trying to find new attack primitives. Following this approach will help you save time, stay on track, and produce better results.

Step One: Begin With the End in Mind

First, you’ll need to gain an understanding of how your system of choice works, how it interacts with other systems in Azure, and how it can be abused. Beyond that, think about what your final product will be — a blog post? A conference session? Defensive remediation guidelines or updates to an open source tool? Determine what’s needed to create these assets. Consider producing audit code as well, so defenders can check for these dangerous configurations, and abuse code, too, so others can easily verify how these configurations can be abused. These are the “success criteria” for your research that will help you maintain focus, avoid unnecessary rabbit holes, and ensure a valuable end result.

Step Two: Study the Intent and Design of the System

Once you know exactly what you need to discover, begin research just like anyone else would — doing Google searches and reading official documentation. Look for anything that seems abusable (like the ability to reset passwords and permissions required), dig further into those, and take notes as you go.

Use LinkedIn to identify any product architects or other Microsoft staff involved in creating the subject of your study. Review their LinkedIn and Twitter feeds and look for the resources they’ve authored or reposted (blog posts, conference presentations, etc.). Delve into community resources like forums or GitHub repositories associated with this service, as these user groups are generally much more open in their discourse around problems and weaknesses than the Microsoft folks. Keep taking notes on the system. Once you can speak intelligently about the architecture and intent of the system and write a highly accurate, nontechnical brief about it, you’re ready to move on.

Step Three: Explore the System

Documentation can only take you so far — it doesn’t keep up with changes in Azure and there are almost always hidden connections that go undocumented. It’s tempting to jump straight into this step, but without the context on the system that you built through research, you’ll probably waste a lot of time.

Start exploring the system with the easiest interface — often this is the Azure portal GUI. If you bring up the Developer tools in the Chrome browser, you can see all the API requests that the browser is making. Copy them to PowerShell and you’ll have a good start to building your own client. Use the official CLI tools in Azure (az binary, the Az PowerShell module, and Azure AD PowerShell module).

When you’ve explored enough that you can build your own basic client to interact with the system, it’s time to proceed. This provides a foundation for a more mature client, and for automating the process of testing abuse capabilities.

Step Four: Catalog Abuse Capabilities

Now you can use your client to enumerate all the permissions that that system can assign, and test the abuse primitives you already know about against each of those permissions (e.g., can you promote yourself to global admin or change a global admin’s password?). Keep an eye out for other abuse primitives that might present themselves during your research — and test them as well to reveal any discrepancies between what the official documentation says and how things work in reality.

Realistically, you’ll need to automate this process. When I went through this research methodology examining the Azure Graph API, I had a list of about 175 permissions and a dozen abuse primitives to test against each of them … you do the math.

Step Five: Share Findings

The final step is to help others learn from your work. Write a blog post, do a talk and/or share your code. The point is to help others save time and expand or add on to your work. Think of it as writing the blog post you needed at the start of your research.

To learn more, watch a talk I gave on this topic (and access the accompanying deck). Inspired to start researching Azure abuses? Here are some useful websites to find technical content around Azure security: The Lazy Administrator, Good Workaround!, AZAdvertizer, Thomas Van Laere, and Microsoft Portals.