← All talks

Bypassing Browser-Based MFA for Outlook Web Application by David Storie at BSides Toronto 2023

BSides Toronto22:33119 viewsPublished 2023-11Watch on YouTube ↗
About this talk
Presented on Oct 21 2023. Microsoft Azure and Entra ID have become mainstays in modern corporate environments. As cloud environments grow, so too does the complexity. Many organizations have implemented Multi-Factor Authentication and employ Conditional Access Policies (CAPs) within their Azure tenant to enforce MFA requirements. We'll walk through a technique we developed to bypass Browser-Based MFA to access Microsoft Outlook Web Application by leveraging an overly permissive Conditional Access Policy.
Show transcript [en]

hello testing hey good morning everybody uh my name is uh Dave story and what I'm going to be doing is uh discussing a browser based uh multiactor authentication bypass that we uh developed at Lis uh on one of our operations um so my name is David store as I said uh I am a principal adversarial engineer and the red team practice lead at a organization named Lis uh do all manner of uh security testing um I was former staff member of of uh c3x if any of you here participated in that uh may have developed the game that you played in or uh been the one hacking against you um I was assisted men for about eight years

prior to moving into offensive security I've done a whole variety of of security testing including web apps uh shout out to pentester lab uh Network pent testing all manner of things my current focus is uh red teams and purple team assessments these days uh and if you uh want to follow me for once every three month posts on Twitter or x uh my handle is C1 Dave so um just before we get started I'm going to note that uh this is all documented on our blog uh as far as if you wanted to see like the post requests and all that fun technical uh stuff uh it's all documented on our on our blog at labs. l.com today what we wanted you

or what I wanted to do is walk through the process of how we developed this bypass um and so what we're going to do is we're going to walk through the process of how we developed an overly abuse or excuse me a bypass for an overly permissive conditional access policy uh we frequently call them caps uh not to be confused with the currency and Fallout um and so uh we want to discuss what are conditional access policies uh what purpose do they serve how might we bypass them uh and how we developed our bypass and then we'll do a little demonstration which I will forewarn is pre-recorded because I dare not tempt fate um so before we get started it's

kind of important to address what the current state is of initial access and so for those of you who may not be uh you know on the blue team or red team side of the house initial access is our term for how we get our foot in the door okay so uh it's 2023 payloads are getting harder to get into environments which is great um there's been better fishing uh controls uh EDR is getting better at picking up inial ass payloads that's fantastic um passwords are getting stronger we're seeing more and more organizations use password filters and so the days of summer 2023 uh being somebody's password are fleeting thankfully and we're seeing an increase

adoption of MFA awesome okay MFA has become more and more uh ubiquitous we'd love to see it we're seeing better alerting and detection on anomalous Behavior right if we're logging into a VPN from uh an area where the person wouldn't normally log into a VPN they're triggering alerts and then on the other side of the coin we're seeing a much bigger increase in adoption of cloud services right so you know you would probably the majority of organizations these days at least the ones that we service have some sort of cloud presence and so uh we decided that it was worthwhile to invest efforts into try to uh figure out how we might bypass some MFA um to get into these environments

and so before we can dive into uh how we developed our uh bypass we kind of need to understand the technology that we're up against first right and so we're up against conditional access policies Microsoft calls a conditional access policy an if then statement right and so in it's very simple as terms if you're trying to access this resource then you need to do this right so a very simple example if you want to get access to your email you have to do an MFA challenge right and so this is a very important note and this is part and parcel to our bypass right conditional access policies are enforced after the first factor of authentication okay once

you have your authentication material conditional access policies do not apply right that's important and so um conditional access policies will evaluate a variety of signals right and this is Microsoft's terminology for like telemetry and there are a whole whack of signals that can be done um there's a talk in the afternoon uh by Don and he's going to be walking through conditional access policies probably in much more detail than I ever could especially in how they relate to you know using it in a defensive standpoint but you know some signals that might be evaluated for the purposes of of this talk our source IPS you know the group that the person is a part of

who you're trying to access um the device that's trying to access it the application and then and then there's kind of quote unquote risky Behavior right and so what we have in the screenshot here is an example of a conditional access policy uh Microsoft gives you a whole bunch of pre-canned ones to pick from they're fantastic but what we've done is if you notice we've unchecked the uh mobile apps and desktop clients right so all the other three applications are going to require MFA except for the one and so this is uh one one thing that we see is that people slap in MFA they go to it in their web browser they get prompted for their MFA

token jobs are good uh and you know on with their day that's not necessarily always the case there are a variety of ways to authenticate to Microsoft azure me and so uh they're frequently relied upon to control access to resources I as I had just mentioned and so they're really intended to strike a balance between accessibility and Security in the cloud right all your Cloud resources are kind of out there they're behind login. microsoftonline.com and there needs to be some mechanism to control how it is that you're going to access that and so uh authentication is usually controlled with either cookies or tokens and so uh if you're working with tokens they're typically come in pairs you have

your Bearer token uh sometimes referred to as access token and then you have your refresh token which is a longer living token meant to kind of refresh your bare token and so uh applications and resources are another important concept with with caps and so a resource is what it is in a in Azure that you are trying to access right so you could be a trying to access Microsoft graph we could be trying to access Microsoft 365 uh exchange online the Azure Services management API Etc um if you are have done any manner of pen testing or maybe on the defensive side I'm sure you know about Microsoft graph heavily abused uh by Red teams for a long time if we can

get a barar token to your graph API we can dump uh your Azure tenant with Azure hounds um Black Hills information security just released something two days ago I think it was it's called graph Runner again it's an exploitation toolkit meant to AB to take advantage of of Microsoft graph or graph excuse me and then the application represents the client that is trying to authenticate right so think of an application as whatever uh you know whatever uh program you're trying to use to access that right so these are generally represented by guids when we're doing it when we're programmatically authenticating so uh some notable ones that we like to use is is azure active directory Powershell

Office 365 online and Microsoft Office and so these are the associated Goods with them all right so how can caps be bypassed so bypasses didn't quote because that's kind of a misnomer in this case we don't generally bypass a c cap we find a way to satisfy the cap in an unintended way or a way that had not previously be considered have a really silly example of this is is hey if you're coming from our Wi-Fi network then you don't need to uh do MFA you know you're in the office we trust that you say who you are but maybe you you you know the assisted Men set it up so that the guest Network uses the same IP

address range right so we go we hop on the guest Network and then we are sitting behind the you know the allow listed IP address space and so remember conditional access policies are only evaluated after the first stage of authentication and so this kind of flips the proc you know the concept of MFA on its head because we'd say that MFA is something that you have and something that you know and once you have a token or cookie you reduce MFA to just something that you have right and so you're going to see an uptick I think in in uh session cookie theft over the next little bit especially as more and more people adopt in clouds um uh the

gentlemen from op I'm sure will tell you that they that access Brokers love dealing with cookies if memory service lapsis would buy buy cookies to access to people's networks right and so um typically how we would evaluate if we can bypass a conditional access policy is by using what we would call an MFA superer uh which is effectively we have a set of valid credentials we're going to use a tool that programmatically goes through and checks a variety of different resources uh in the in the in the tenant and see if we can authenticate um this is tool is one called uh MFA sweep it's by Bo bolock he works for Black Hills information security it's kind of the

original MFA sweeper and as you can tell what it's doing is it's going through and trying to see if I can authenticate to various resources within uh within the Azure tenants right and so it's kind of going through a variety of different signals to see if it's able to bypass stuff so yeah we have good access to graph and we have uh good access to the service management API but if we try to access 0365 with with the windows user agent or any other variety of user agents we get you know get said no ews and active sync kind of two traditional like Legacy protocols also are blocked right so um the one thing that I would

note about uh MFA sweepers is that they are good from a conceptual perspective right so they're not all inclusive there are a whole variety of signals that can be tested against and this is testing a really small subset so if any of you guys out here do any programming you can kind of figure out a nested for Loop right so like test this application ID against these endpoints and then test it with this set of user agents etc etc right so there are a lot of different ways that you know you could try to authenticate against Azure um and so one thing I would say is it if you guys are using MFA sweepers in your environment

if you all if anybody in here's blue team or manages an Azure tenant uh just be sure you know just because you guys are seeing only two yeses here doesn't mean that there's only you know we can't get into 0365 some other way um so you know these are not all-encompassing they're you know at this stage kind of a proof of concept if you will uh they demonstrate the capability to try to bypass MFA so um I will note that we've run uh bo bollock tool before in engagements and come up with all Nos and then we've run our own internal tooling and come up with all yeses and receive be tokens right okay so that's enough of the Caps

what brings us here today so uh we find ourselves bypassing conditional access policies on a fairly regular basis on engagements right if we're doing pentest or not and so uh we needed a way to use them in a meaningful manner I discussed earlier that if we get graph uh if we get uh tokens for graph bear tokens excuse me then we are able to run Azure hound and then dump information about the tenant through Azure Hound um we found ourselves with tokens for Office 365 and we wanted to access somebody's mailbox uh there's a tool out there called token tactics and at one point it had an open a mailbox in browser uh this was quietly patched but we you know had

a taste of what that could do and we wanted it so uh really what brings us here today is we wanted guy based access to O AA for number of reasons quick and easy search uh we can intercept emails right if someone's getting an email saying hey there's suspicious activity you know maybe it just finds its way to the recycling bin and they're none the wiser uh potentially retrieve authentication material maybe you guys have aert that's being distributed through your email um we can access the G we can do browser base uh and then the nice browser picture illustrates the point right in the red team and pentesting game you really have to show impact and I think that you know a

picture of us you know navigating to your AA from not trusted space is impactful so our high level research process is as follow uh determine uh the end goal so we want to bypass MFA we assess the viability of achieving the goal it's been done before we could probably do it again uh what do we need in order to do the research we need burp suite and a test uh Microsoft 365 tenants if anybody in here doesn't know Microsoft will just give you a free E5 tenant for you to play around on look into it it's awesome 25 users cost nothing so if you guys are into Cloud hack give it a look and then you know

really what we're going to focus on is what's the primary driver for research and that is we want to get into AA so here's our five-step process um I'm going to gloss through this because uh I'm conscious of time and so uh we first off we need to identify the endpoint what it is what is it that controls access to ow when we access it in a web browser in our case it's a cookie and it's known as the open ID connect token cookie the way that we found this is easy open up burp do a legitimate authentication go all the way through from putting in your creds to the endpoint and getting the O browser and

then just start deleting cookies in the final one and see which one prevents you from getting access to your mailbox right it's not particularly sophisticated but it worked and so uh step two what's the viability of authenticating with tokens instead of a username and password or converting tokens into a cookie and so when we do this uh when we steep through it we saw that there were things that looked like they were tokens returned from Microsoft when uh we entered username and password specifically stuff that resembled a bearer token which starts with EJ and then the refresh tokens which starts with zero. a and so we you know in our mind we're good to keep proceeding uh and so we do we keep

researching uh this and so the next step is we need to identify only the steps that are required for authentication this part sucks there's no uh there's no sugar coating it it's very repetitious you you know you start you start with your full process of going from start to finish start deleting requests and see which ones are required and when we do that uh we end up we you see that there are now three important AP or web requests to get to uh users mailbox we have a post or two post requests and a get again all this stuff is detailed in detail on our blog if you were interested in seeing what the post

requests look like you know go take a look there uh we wanted to highlight the process as far as um the research was concerned step four is refine the process okay so let's make it as succinct as possible and we only want to pass as many cookies as is absolutely necessary and so this is what it looks like at at the end of the day we've got a refresh token and our bear token and they go into code and ID token post parameters respectively if we get a successful request we are then uh issued an open ID code V1 cookie and an open ID code uh token cookie and then those two combin to reach our end goal cookie

which is the open ID connect cookie so at this point we know we 100% have a bypass working we've refined it and so now you know we're ready to use it in operations and then the fifth step is to automate the process to make it as accessible to everybody on your team who didn't have as much time to research it as we did right and so when doing that you want to consider the language uh we chose python because it handles web requests well it does cookie parsing really well it handles Json well and it's high level and really portable so uh here is the aformentioned demonstration and so we're going to try to log in to outlook. office.com through

our test tenant using our alexw so we try to log in and we are styed with the MFA prompt what we'll do is we'll go to Python and and open our the youngsters are making me call this no cap kit at our work but for this for this purpose we're calling it cap kit okay and so we get our authentication token so what's happened here is is we the python has done all of the automate excuse me automated everything that we just discussed we're going to put in the value for it we have it kind of pre-baked and we set the cookie and we are now uh able to get into the email yeah um this one has had audible gasps

on readout calls before and it's like a you know many organizations will consider AA to be a crown jewel or email to be a Crown Jewel and so it's important you know the reason why we wanted to do this talk was to just drive home the importance of making sure that your conditional access policies are as strict as they possibly could be right so let's talk about defending this attack because that's really why we're here um is is you know anytime we're able to get a token for outlook. Office 365 or outlook. office.com we have mailbox access okay as as best we know this is not patchable so Microsoft is not going to come swoop in and save save

us um we are simply taking valid authentication material and converting it to a different authentication material so tokens to cookies and so what we really need to do is make your conditional access policies as restrictive as possible right um it's easy for US security people to say that but you know the reality is the business is the business and uh sometimes you know the money maker loves an old school um you know client that uses active sync or something like that and so you know audit your uh policies to make sure there are no unintended ways to bypass it um this is what it looks like in the audit logs and so this is uh token

tactics so we see the application is Microsoft Outlook this is the token tactics default that can change the resources Office 365 and so really if you are expecting MFA and you're seeing any single Factor authentication successes in your in your logs something's been bypassed here right so that's cause for concern you're going to want to dig into that one a little deeper and so thanks to acknowledgement again uh besides Toronto you know they all these people volunteer their time to put on a conference for us thank you guys uh because you know without them we wouldn't be here today so thank you all um bo bollock uh of MFA sweeper Steve borash and Bobby cook for token tactics

and then the Laris team Andy Gil leay uh Brennan Ben and Lee so anyways um I don't want to gloss over but thank you all to the bsid Toronto Team without you guys we wouldn't be

here all right all right questions am I up on time

okay you can customize them too that's the nice thing about if you're looking at security logs you can kind of customize the the the fields that you have I've removed a couple to try to make it as you know for brevity but this is the result of an MFA sweeper so you see all the failures there and then the success means that I've swept through these end points and then got it success someplace else I would think not and that would certainly be something that you would want to look into I mean um I don't uh do the blue team thing so I can't speak to it at scale but I would suspect it's probably pretty rare especially for a

variety of different resources saying hey this person tried to access this resource and failed this resource and failed oh but this one was successful probably indicative of a MFA sweeper some of them are a little um not obsc friendly if you will like they'll have uh user agents for Python and stuff and so it's like well I mean if Python's authentic you know that's probably something that you want to dig into a little bit yeah yeah that's still very

prevalent uh you I think it's more relevant if you if you do a third party IDP in fact that's probably where we see it more is if you guys are using a third party you know we're not going to name names but um if you guys are using a third party you know please absolutely audit it and make sure that you guys don't have any unintended um unintended ways to bypass it because yeah the to your point the IDP sometimes has an app that goes in there and may not cover all the endpoints uh the Microsoft uh default uh conditional access policies are are very good for what it's worth but if you have a third party IDP I

would certainly recommend looking into it

Don um it it we have to get a token right and so it's really a conditional access policy bypass and so it's not it's um you need to be able to grab the token I couldn't do this on every on every tenant correct yeah yeah or or we have their password right maybe we fish them and they put their creds into a a credit harvesting page maybe we called them said hey this is gim for it we need you to log in here and do whatever right um yeah the you would have to have you know kind of the the first set of credentials to continue if

that yeah yep yeah and so and so what you'll also see as well as like an uptick in like evil Jinx and the and the man- in-the-middle proxying stuff um I think that there's a lot more like work to roll that out if effectively personally but um session cookie theft is going to become very prolific uh I think in the future if I had a crystal ball if it's I mean it's already

but uh so generally not ews it's um usually uh so we would we have to get a token for what it Scopes to so it wouldn't be ews we would try to you know usually use uh an unintended app to authenticate against office throughout 36 5.com so it's still the the modern uh Authentication Protocol but we're not doing it via the web because we're doing it programmatically and usually we change the application ID uh from what it would expect which is the web browser to something like you know uh to um like Azure active directory Powershell that's when that becomes possible correct that's exactly right and so that app ID satisfies the conditional access policy for single

Factor authentication which is how we're able to get the token no problem yeah anybody else this this feels like it's a too concise paraphrase but essentially didn't actually second Factor token system itself byass system depending exactly yeah yep so for the purposes of brevity with the naming of it we went with we went with the bypass of of the browser based OAB but you're absolutely correct right we bypassed the the process that was expecting MFA it means that in the future say oh I bypass MFA question is which part of it right yeah and so that's in the talk title it's called browser based MFA that's why I called it that because I'm a stickler for details

myself but in in the attempt to try to get it all on one slide um that's why we went with that understanding absolutely yeah absolutely and it all comes down to conditional access policies again we have another talk on conditional access policies this afternoon if this stuff is interesting you please stick around I'm sure Don will do a fantastic job if you guys have any other questions come find me in the LOB I'll be around thanks to everybody excellent thank you thank you