Home » Security Bloggers Network » Attacking Microsoft Graph with Postman

Attacking Microsoft Graph with Postman

by Dana Epp on October 18, 2022

It’s no secret that Microsoft’s Graph API is a powerful tool for developers. With it, you can access data from across the Microsoft ecosystem, including Office 365, Azure Active Directory, and more. But what if you want to attack the Graph API as part of your API security testing? In this article, we’ll discuss how to use Postman to send malicious requests to the Graph API and wreak havoc on your applications. Stay tuned!

Why care about the Microsoft Graph as an API hacker?

The Microsoft Graph is a cornerstone of Microsoft’s cloud solutions, providing access to data from across the Microsoft ecosystem. This makes it an attractive target for API hackers. By attacking the Graph application programming interface, you can access sensitive data and disrupt the flow of business operations.

So if you’re looking to add some drama to your day, you might want to take a crack at the Microsoft Graph. And you can even get paid to do it!

Getting Paid Through Microsoft Bug Bounty Programs

The Microsoft Azure Bounty Program is a rewards program that offers cash prizes to security researchers who identify vulnerabilities in Microsoft’s cloud. The program is designed to incentivize researchers to find and report bugs and offers rewards of up to $60,000 for serious vulnerabilities.

The Microsoft M365 Services Bounty Program is similar, inviting researchers to identify and submit vulnerabilities in specific Microsoft domains and endpoints. Qualified submissions are eligible for bounty rewards up to $30,000.

So if you’re interested in hacking the Microsoft Graph, these bounty programs might be just what you’re looking for. The rewards can be substantial, and the programs are open to anyone who can identify a vulnerability and report it.

How to start hacking the Microsoft Graph

So I’ve got great news for you. Microsoft is a big supporter of the OpenAPI specification and the use of Postman in its own work. As such, they publish a Postman collection in a public workspace which you can directly access from within Postman.

TIP: For everything I will show you today, I want you to use the desktop version of Postman, and NOT the web browser version. There is a simple reason for this. Cross-Origin Resource Sharing (CORS). You can’t use Postman for the web due to the CORS restrictions Microsoft has for the Graph. There is a way to get around this using the Postman desktop agent, but it’s a real headache to set up and configure. So keep it simple, and use the desktop version of Postman.

OK, all set? Let’s go get the Microsoft Graph collection into Postman!

Getting the Microsoft Graph collection into Postman

Alright, so let me first show you how to find the Microsoft Graph Postman collection:

Open up the desktop version of Postman
Click the Explore menu item
Click inside the search field, and select to search in the Public API Network
Now select to search for Collections.
Type in Microsoft Graph

It will look something like this:

Select the one published by Microsoft Graph, and which is not a forked collection. For me, that was the first one in the entry. YMMV of course.

Once selected, Postman will load the collection for you and show you all the API info.

But there’s a catch. As of the time of this writing, Postman cannot send API requests to a public workspace. So you have to fork Microsoft’s public workspace into your own.

WARNING: You want to be careful here. When you fork the collection you will probably want to put it into a PRIVATE workspace (if you own Pro edition), or PERSONAL if you do not. This makes it harder to leak sensitive information that may belong to the Microsoft Cloud tenant you will be attacking. No one wants to accidentally share variables or environments with their peers (or the public) that might expose access tokens and whatnot to others the workspace is shared with.

For this exercise, I will create a PERSONAL workspace called “Hacking Microsoft Graph” and then go back to the Microsoft Graph collection and click the “Fork” button. I’ll label it, select the new workspace I created, and then click Fork Collection.

You’ve now got your own fork of the Microsoft Graph collection in Postman.

Let’s have some fun with it!

Authenticating to Azure Active Directory

So before we can go to town on Microsoft Graph, we first need to authenticate to the Microsoft Cloud. They use Azure Active Directory (AAD) as the identity backplane and offer the ability for you to create a custom application registered in Azure AD to grant you appropriate permissions to it.

You don’t want to be attacking the Microsoft Graph with a production tenant. If you follow the Microsoft Azure Bug Bounty Program guidelines, you should have set yourself up with a developer tenant. If you don’t have one, you can sign up for one here to get a tenant pre-populated with data. Or sign-up for a free trial to Azure here and do it yourself.

For those testing within a tenant with multiple uses, or maybe even production use (which I don’t recommend), you may have to adjust access controls. If your tenant has conditional access policies configured you may find it can block the authentication flow from Postman. You will need to adjust accordingly to allow Postman access.

A tip if you haven’t signed up for a tenant yet. When submitting a vulnerability to Microsoft the Microsoft Security Response Center (MSRC) likes it if your account and/or tenant name includes the label “MSOBB“. This helps them to identify that the tenant is being used for security research.

Be nice and follow MSRC guidelines when possible. It will help you down the road when you are talking with them.

So let’s go about setting up our custom app in AAD so we can use it with Postman to make requests to the Microsoft Graph.

A few things about what you are about to do. You will create a custom app called Postman for your tenant. This application can read users in Azure AD, and doesn’t require a signed-in user to do so. This is sometimes called application access. The second thing it can do is read mail on behalf of the user. For this, a signed-in user is required. This is called delegated access.

So let’s go:

Go to portal.azure.com and sign into your developer tenant with an administrator account.
Under Azure Services, select Azure Active Directory.
On the left menu, select App registrations.
On the horizontal menu, select New registration.
Set the Application name to Postman.
From the dropdown menu under the Redirect URI section, select Web.
Set the Redirect URI to https://oauth.pstmn.io/v1/browser-callback
Select Register.
On the left menu, select API Permissions.
On the horizontal menu, select Add a permission, select Microsoft Graph, and then select Delegated Permissions.
Type Mail., expand the Mail options, and then select Mail.Read.
Select Application permissions, type User., and then select Application Permissions.
Expand the User options, and then select User.Read.All.
Select Add permissions.
On the horizontal menu, select Grant admin consent for and then select Yes.
On the left menu, select Overview. From here, you can get the application (client) ID and directory (tenant) ID. Record them as you’ll need these for Postman.
On the left menu, select Certificates and secrets.
Select New client secret, enter a description and then select Add. Hover over the new client secret Value and copy it; you’ll need this for Postman as well.

Setting up your Azure access in Postman

Remember when I told you to record the client id, tenant id, and client secret value for Postman? Now’s the time to use it.

You are going to want to fork the Microsoft Graph environment in Postman so you can configure that with your personalized custom app settings so Postman can access your Microsoft Cloud tenant.

Go back to the Microsoft Graph workspace, and select the Environments tab on the left.
Select the M365 Environment env.
Click the Fork button.
Give the label a name, and make sure you are forking into your own workspace.
Click the Fork Environment button.

It will look something like this:

Now in your own workspace, insert the values you grabbed from the Azure Portal into the CURRENT VALUE fields for:

ClientID : This is your application (client) id of your new app.
TenantID : This is the Directory (tenant) ID of your new app.
ClientSecret : This is the client secret you generated for your new app.

Make sure you hit the Save button to commit the new environment settings.

Go back to the Collections tab. On the top right you will see a dropdown that says “No environment“. Change that to your forked M365 Environment. This will tell Postman to use your configuration settings to access the Microsoft Cloud.

OK. Everything is set up. Let’s go fetch a delegated access token from Azure AD!

Getting your first delegated access token

The first time you connect with Postman using delegated access, you will need to fetch a new access token.

Click on the Delegated folder in the collection.
In the Authorization tab in the middle of the screen, find the Redirect URI and set it to https://oauth.pstmn.io/v1/browser-callback.
Scroll down to the bottom, and click Get New Access Token.
At this point, you will see a popup window to sign into Azure AD. Sign into your tenant with your Microsoft creds.
When prompted, click the Proceed button, and then the Use token button.

Postman will store the access token and you can use Postman for delegated access.

Go ahead, give it a try. Expand the Users folder, select the Get my profile GET endpoint, and click Send. It will return your profile registered in Azure AD.

You have successfully made a Microsoft Graph call with delegated auth in Postman! Sweet!

Getting your first application access token

The first time you connect with Postman using application access, you will need to fetch a new access token. Guess what? It’s a similar process.

Click on the Application folder in the collection.
In the Authorization tab in the middle of the screen, accept all the default settings.
Scroll down to the bottom, and click Get New Access Token.
Notice this time it didn’t require you to log in. That’s because it’s using the app creds you set up in the environment.
When prompted, click the Proceed button, and then the Use token button.

Postman will store the new access token and you can use Postman for application access.

Go ahead, give it a try. Expand the Users folder, select the Get users GET endpoint, and click Send. It will return all the users registered in Azure AD.

You have successfully made a Microsoft Graph call with application auth in Postman! Oh ya!

You have API access to the Microsoft Graph. Now what?

At this point, you can start exploring the attack surface of the Microsoft Graph. It’s pretty vast. The Microsoft Graph is the gateway to data and intelligence in Microsoft 365. You can get a much deeper overview here.

The thing to note is that the Microsoft Graph exposes REST APIs and client libraries to access data on the following Microsoft cloud services:

Microsoft 365 core services: Bookings, Calendar, Delve, Excel, Microsoft 365 compliance eDiscovery, Microsoft Search, OneDrive, OneNote, Outlook/Exchange, People (Outlook contacts), Planner, SharePoint, Teams, To Do, Viva Insights
Enterprise Mobility + Security services: Advanced Threat Analytics, Advanced Threat Protection, Azure Active Directory, Identity Manager, and Intune
Windows services: activities, devices, notifications, Universal Print
Dynamics 365 Business Central services

When we set up your custom app, we limited the permission scopes it had access to. To fully explore the attack surface you should invest some time reading the detailed Microsoft Graph Permission Reference. This will allow you to adjust the delegated and app permissions to expose you to all the relevant API endpoints the Graph provides.

From there, find what interests you and follow your methodology. If you are confused about what to do, maybe check out my Beginner’s Guide to API Hacking. And if you get stuck and aren’t sure whether to move on or not, maybe read up on When to Give Up on an API Target.

Still with me? Good. Let’s discuss how to find more “interesting” endpoints exposed in the Microsoft Graph.

Exploring the Microsoft Graph

So it’s pretty awesome that Microsoft openly shares its Postman workspace with the community. But here is a deep, dark secret they won’t usually tell ya in mixed company. The Postman collection they publish doesn’t expose all of its endpoints.

Whaaaaaaaaaaaaaaaaaaaaaaaaaaat?

Don’t fret. They aren’t being nefarious. It’s just not easy to keep the collection up to date when their agile development practices are publishing changes so frequently. Never mind the fact they have both a /v1.0 endpoint AND a /beta endpoint.

But… never fear. Microsoft also publishes the Microsoft Graph Explorer that can expose things not found in the Postman collection. In fact, there is a hidden feature in the Graph Explorer that will allow you to not only find endpoints but also export them to a new Postman collection.

That’s a total win for us.

What is the Microsoft Graph Explorer?

The Microsoft Graph Explorer is a web-based tool that allows you to explore the Microsoft Graph. It provides a way to visually interact with the different endpoints and resources that are available through the Microsoft Graph. You can use the Microsoft Graph Explorer to test different calls and get a sense of the type of data that is returned.

It’s kinda like Postman, but dedicated to the Graph endpoints. But it’s always up to date.

Using the Graph Explorer to build a custom collection

It’s simple really. Head over to https://developer.microsoft.com/en-us/graph/graph-explorer. You will immediately be dropped into a sample tenant with some data.

Earlier this year, Microsoft added an interesting little tool. Beside the Sample queries tab is a new tab called Resources. When you click on it, you will even notice a Switch to beta toggle.

Switch it.

You are now seeing all beta endpoints exposed to you. Even better, click on the 3 vertical ellipses beside a resource you are interested in.

Notice the “Add to collection” menu item? Guess what that does? Yep. Find all the resources you wanna test, and adds them to your collection.

When you are ready to download your custom collection click Preview collection and then Download Postman collection.

At this point Graph Explorer will export a customized Postman collection to you that you can manually import.

If you do this on a semi-regular basis, you could run diffs on the collections and detect new and modified endpoints as Microsoft works on them.

Who knows what you might find!

Conclusion

So, what have we learned today?

First and foremost, the Microsoft Graph is a powerful API that should be taken seriously. It exposes many endpoints that can be used to access sensitive data. And we can use Postman to access it. And don’t forget, you can proxy Postman through Burp so you can manipulate Microsoft’s Postman requests as part of your API hacking methodology.

Second, we’ve learned how to use the Microsoft Graph Explorer to find hidden endpoints not found in the Postman collection for both production and beta.

And finally, we’ve learned how to export these endpoints into our own custom Postman collection for future reference and testing.

With this knowledge in hand, go forth and hack! Just remember to stay in scope of Microsoft’s bounty programs! Good luck!