Background
It’s important I point out upfront that nothing I am demonstrating I can take credit for. Evidence of this used in the wild was talked about as mentioned here on Twitter.
In Azure AD a user (unless mitigated which we’ll talk about at the end of this post) can create and register a new app that will basically function as a redirector of sorts that asks a targeted user to grant certain permissions as defined in the app, then ask for the user’s consent to those permissions and then finally takes the OAuth token generated by this process and forwards it along somewhere else. That somewhere else in this case is an attacker-controlled host.
Limiting the Scenario
In this post, I am operating under a compromised user account that has no special access or rights in Azure or Azure AD. This user, Alice, has no subscriptions or Azure roles assigned. This is also why mitigating this attack is quite important IMO since it requires practically nothing other than the compromised user existing in Azure AD and the ability to register new applications.
The Plan
Assume you’ve grabbed a user’s creds and used them to gain access to the Azure portal.
We’re going to register a new application in AAD, set the redirect URL to our host (DO, AWS, Azure etc.) which is going to run an OAuth ‘listener’. Once the user consents to the application, our listener will grab their OAuth token, relay it to the Microsoft ‘/token’ endpoint which will give us back the Access, ID, and Refresh tokens for the target user. The Access token being the one we’re most interested in.
Once that has been accomplished, and I’m intentionally not going too much deeper here to leave more exploration up to the reader, we will take our acquired token and use the Microsoft Graph API to confirm everything works by pulling some basic information about the user we targeted.
Execution (The Application)
Starting in Azure portal, log in as the assumed compromised user. Navigate to Azure AD > App Registrations and click the + New registration button.
On the Register an application page, here is where you will start defining the application. For the Name field, pick something non-suspect as this is the name everyone else will see under registered applications.
Another decision to make is the Supported account types section. If you have a reason to want to leverage this compromised user’s Azure tenant to attack another (Multitenant) or even against any free/personal Microsoft account, you can do that too (Multitenant + personal Microsoft account). I’ll choose the latter for this example.
Next, I’m making the decision to set a client secret. The reason, I think, is depending on AzureAD and the application registration configuration, some apps are considered public or private when it comes to managing how the OAuth token gets passed around. I ran into an issue where setting this secret fixed things up and to be honest as of writing this, I’m not 100% sure why I had to but I’ll explore it more.
Click + New client secret and give it a name. Once created it will display the secret. Write this down somewhere for later.
Next, go into the apps API permissions section. Here is where we are going to select (another exercise for the reader) what we wish our app (and ultimately the token we receive) to be able to access from the targeted user.
Click + Add a permission, select Microsoft Graph (or anything else you want to try out) and pick the APIs of interest. Avoid selecting ones where administrative consent is required. Here’s what I selected:
In my attack scenario, I’m targeting users who by falling for the phish will expose access to their email. With this API permissions set, as the attacker we can read their contacts, emails and even send emails.
We are done configuring the application. Before moving on, make sure to note down your applications client ID which can be found in the apps Overview section.
When we construct the URL to deliver in our phishing email you will need the client ID, redirect URL and the API permissions you selected earlier.
Execution (The OAuth Redirector)
For this step, I’m using a great utility that you can find on my GitHub here.
It is a fork so once again, all credit due to the author.
This tool is an OAuth server script written in Go. I leave it to you to setup your environment correctly.
On Digital Ocean to keep things simple, I spun up a Ubuntu 18 VPS and hosted this script at https://ograb.invokethreat.cloud during this example.
The script is commented well for what you need to change. I made a couple of slight modifications that I want to point out:
The target variable I have set to google.ca and is kinda silly. Realistically, this will be the final redirect location after you, as the attacker, have achieved the token grab. In a real engagement, you would likely want to redirect the user to something such as O365 or Outlook login pages. Or you could even take this further and use that redirect to bring the target user to a second credential grab such as a clone of Outlook login page. Again, let your creativity fly here 😉
The other modification I made that does not come part of the script is the postData variable. If you look closely, I’ve added the client_secret string including the secret.
Delivery
We are ready to phish our target user. How you do that…you guessed it! I leave that up to you. Here is an example of the link you would ultimately want the target user to click on:
When the user clicks the link, if they are not already authenticated they will be brought to the MS default login page. Once they authenticate, they will be brought to your malicious app and asked to consent. Notice how at the beginning of the URL, it is originating from a Microsoft domain and very much helps with the lure.
Also, notice the consent being asked of the user. The consent will list out the APIs you select in your app registration. Because of this, another consideration should be made here to minimize alerting the target user to something suspicious. Use only the APIs you need to achieve your objective.
Now once the user has gone through the authentication and consent process, your OAuth server should have captured their token.
Finally, to confirm you’ve captured everything correctly, a simple check to the MS Graph API to return account information about this user will help:
and output upon success should look something like this:
Detections and Mitigations
A lot of what you can/cannot do at your organization will be hard for me to dictate so I thought I’ll just list out some of the things I’ve observed playing around with this and also some resources that I’ve come across.
Remove users ability to register applications
From my understanding, if you do not have an Azure AD P1/P2 license (will confirm this), your only option is to enable/disable registrations for all users. While you’re at it very little users would actually need Azure portal access, so get rid of that too.
Leverage the Consent operation in the AAD Audit Log
It might not be much but its a start. The users who are phished with something like this need to consent to the malicious app and Azure AD Audit Log records this action:
Note: test2 was the app name while I was working on this
Leverage Hunt Query-Fu
I was crawling through some Azure Sentinel stuff on GitHub and there are a few queries I noticed that can help with detection of OAuth/App Consent behavior:
Again these are forks so all credit due to the authors.
I’m sure there’s more that can be used to enhance detection capability as well as mitigations without having to disable something like app registration for every AAD user. This is just some stuff I found for the time being and will update this post with more info as it comes in.
Closing
This attack, which I only leveraged for the very first time on a recent engagement, is not all that new. It’s an OAuth token grab that in this scenario is focused on Azure and the AAD app registration feature. There’s not exploit. There’s no real hack going on. These are features.
Which IMO, makes it pretty nasty. You may also notice I didn’t give away anything devastating here. You can phish a single user (obviously you could do more) and get back an OAuth token which you can create an access token out of to do some stuff with.
I have a feeling that the possibilities here could run pretty deep.
I’d like to thank @Antonlovesdnb for helping me explore this further and defensive guidance. Also a shoutout to @dafthack for spitballing ideas about ways to abuse this. Cheers to you both.
Finally, I wanted to link to some awesome work others have done on, or related to, this topic:
I hope this post was interesting and of some use.
Lee started in IT and security world in 2010 in Toronto, Canada. When Lee isn’t tip-toeing through enterprise’s Active Directory environments he’s running the DerbyCon Toronto Community Chapter, the Canadian Collegiate Cyber Exercise (C3X), and as an instructor teaching Canadian offensive and defensive professionals ways to up their game. Lee has spoken at multiple events and conferences such as BSides and SecTor. In his spare time, Lee is an executive chef at a restaurant in his mind.
