Story behind weaponizing the Intune Conditional Access bypass & Making Friends over Christmas

Thank you for uh bes having me today. Um I prepped this talk in English but uh I I intend to do the self intro in Cantonese because it's more u friendly and and and warm and so forth and some of some of the jokes in as well but all the technical details I I intend to speak in English. So don't worry about that. Um reverse engineer a rumor um the story behind weaponizing into access bypass. So uh it is a a big mouthful or thing uh or word to say but um we'll get into what those means but basically um in December last year um there was a rumor in the security community that somebody is able to um

bypass some Microsoft 365 restriction before that um how many in the audience works in the offensive role like pent testing already maybe quite a few okay cool um how many how many how Norally would you um deal with Microsoft 365 in like work in general like use Exchange or or or so forth? No. Yeah. Should be a lot of people use by the way. Anyhow, um so we were one of the most uh earliest ones to to weaponize this and publish a PC uh in the uh in the community. So we feel you know it's um it's good to talk about the story, right? Um I've talked about this topic like elsewhere a couple times but

every time I go through the vulnerability how to defend against this and so forth but actually the discovery process was quite interesting on its own. So like I this time I intend to talk about like how does the the discovery process work but it's a bit technical a bit o too but the reverse engineering co has nothing to do like with binary reverse engineering in case you're wondering right um part two was like the the the drama with regard to releasing a PC during Christmas is also quite fun which I never talked about it on stage before and also thank uh thank you for the you know organizers is putting me uh at this spot. So, I hope I

don't delay lunch forever too much. Maybe um you guys are confident in my pres skills. Hopefully.

[Music]

Microsoft 365 authentication stack

intimidated

logos. sponsor Microsoft Microsoft.

[Music] Okay. So, let's set the set the stage for, you know, what we're going to talk about today. Um this uh LinkedIn post was the sort of like the end end results uh of our research that went viral. You can see like 100 180,000 views. Um um the the video uh which is like a 30 secondond demonstration wasted 200 hours of people's life which makes me a little guilty. The post drop itself was on 27th, so like two days after Christmas. And um you can see this guy Benjamin, he um did a YouTube video um like demonstrating our tool and so forth, which is pretty cool. And um like a little more um reaction piece um we got

on NID news um which is a purpose by Microsoft themselves like Amazon or some and um there were um detection rules written for our thing like 3 days after you know it was published showed. So people were taking notice which is pretty cool as well. But um um how do we get to that point right the the full timeline was um first rumor um happened on the 11th November it's like mid November and um end of December was the pros rock and went viral obviously um the fun part was you know the juicy bits we get get into but the rumor itself first right um if you do like offensive stuff in Azure Microsoft 365 and so on

you might have used like um ro tools graph graph runner that kind of tools before that deals with the graph API right so um in uh 11th of November there was like a a a Twitter post by our flag if you don't know our flag they they own cobalt strike so it's like a parent company of cobalt strike they have a a pay wall out OST you know temples so we we saw you know um somebody saying, "Oh, okay. They they uh they they allow this pay wall tool to be used by their customer to bypass like the intuitive restriction." I I'll go into what those means afterwards, right? But the first rumor was first news was

11 November, but we didn't buy the tool. We don't know like anyone who does. So, right. So, what the Twitter post said was bypassing caps, right? But but what are caps? So um enter ID is the authentication stack of um Microsoft 365 and Azure. And um caps means condition access policies which sort of like this game show on your game shoulder you force your user to sign in with specific conditions for example um from a company device company IP with two FA so forth. So um the hole is sort of like the specially designed for your users's use case and the yellow hole block the bad guys and and like throw them in the water and so forth,

right? Um and if you deal with the M365 entra authentication stack, you know like uh very often that the the wall have holes uh where the attacker can get through. But um I won't go into details on country access holes or gaps but this is like a a passion area of mine. So we can talk um like off offline if you want to talk about access gaps. Anyhow so um more pictorially you you can think of um the enter ID the Microsoft authentication server as like a check. It does two checks whether you present the correct rant. uh it can be like a user username password um MFA or cookies or um access tok uh access refresh token

that's the grant and the conditions is sort of like a wall you need to fit through as well and um besides um like the IPs and device and so forth um you need to you can potentially be blocked due to like a client um wrong client for example you request a a token for Azure CLI Azure PowerShell or office.com But the company doesn't allow um that client to sign in in specific conditions and so forth. And then um if everything passed, everything looks good, you be issue your um session token and be locked in and um otherwise would be access denied, right? So this is um like a simple represent representation of how access policy

work. But what is like a enroll device, right? So think of this as like a company device, right? um like a blank factory reset device needs to go through enrollment um to be called enrolled or company managed. So there's a process that um involves the user signing into Microsoft and um they can get you know some tokens in that process and um I don't want to go into details into like what what a compliant or join and so forth are but there are some differences right and um we um go back to the original post it says roune allows red teamrs to bypass caps by um faking compliance registration and you know get secrets from application and so

forth. So it this uh enrollment process is what the the bypass lies in. So um a month later after like the initial news of the pay wall tool um it was blackhead Europe time um it was 20th of um no it was 11th of December right uh happened in London this um Japanese um consultant called um Yuya um went on stage talk about unveiling the power in tune and so forth and uh he he worked at secure work by the way does amazing work as well in this in this field um So um Doug Jen um here on on on the screenshot was the person who did the first um like pay raw version um for for our flag and he he

also is the author of road tools by the way so he's very cool but he so the other guy went on stage to talk about like how to do the bypass so he cannot pay all this anymore so he he disclosed like okay it's out of the bag now um you can you can try to you know uh uh PC it yourself if you want to right. [Music] So he disclosed the client ID as well as um like the com in tune company portal. So these these are the two like um kind of hints on like where the actual bypass is right. So a quick recap recap of what we've talked about so far. um blackhead

EU um talk was about um using the intrude company portal um and that client ID to bypass the um requirement to sign in from like a company um device right so um it can be used to bypass compliant and hybrid joint um requirements can be used to enroll new devices and more most importantly the access tokens can be used to access graph API such as like your graph runner or ro tools maybe that the red teams love Right. At the time, um, we didn't have the slice. We only have like the, uh, the company portal like app name as well as the client new ID. So, how do you PC a bypass just with this two sort

of um, information in mind, right? So, the what is like the end goal of what we're trying to do is to be able to run our offensive tools in restrictive client environments, right? And how is to um perhaps authenticate to the the M3 M every M365 stack with like a specific way right to with a compliant device cap without using a compliant device but it has to deal with the authentication process and like the how would you know I imagine that like the red teams using a Microsoft zero day on the next engagement you you feel you know very cool and and and so forth and the knowns and unknowns we know the client ID we

know the client application's name. So those are the like the known variables so far and um unfortunately here I have to get a little bit deeper and technical into like how works because you you you deal with the authentication um process. So um you need to understand a little bit about like how authentication works. Um there are different grants um defined in all of 2. Um the primary one I'm going going to get into is authorization code but there are others like refresh token um device code that you know I won't go into and um on on stage in um conference talks I like to say oh IFM uh during my research um so here is what it is um the

all of authorization frameworks actually written by some guy in Microsoft interestingly but to make this SK art um diagram better um I'll I'll explain that later. Anyway, but the most important error code that is relevant to us is um what is ooth off 2 is um you have an application, think about Jira or or um uh Confluence um that everything is Jira. Um or think about your SAS application like um some kind Salesforce. Yes. So, so you want to sign into your SAS application but the SAS application doesn't handle the like the user identity another entity handles the user identity for example like your Google your entry id that's Microsoft or or Facebook or whatever so um there's a

process where the application directs the user away from from itself to the identity provider and then the identity provider will redirect back to the application right there's like a back and forth um process in in itself and um in the uh sign in URI uh there is a redirection URI that is defined and um uh this redirect URI must not be changed and otherwise the provider would never redirect the user back well I've tried it many many times it wouldn't work because it's in the RFC right so we are going to see like how a sort of login URL looks like um the most important bit is in red like redirect URL URI is defined like as like office.com landing

v2 and um it it must cor correspond to the client ID of office.com otherwise like Microsoft wouldn't allow you to go through right and um respond type is code that means we're going through the authorization code flow and the scope I won't go into really but um so that is sort of like the um SPR photo uh that that is pictorially the user goes through the um browser to to get into to to to be redirected to Android ID they complete the authentication, get a password to FA code, whatever. And then um uh interestingly in the first in the first step um the um user would get a special authorization code in a get parameter like code equals

and um and then the user would be redirected to um the redirect URI here we say is legitserver.com and then the the SAS application would redeem the session cookie with the user right so what we can imagine the problem would be if I send the user fishing link right with like the correct client ID but the redirect redirection I said as my uh attacker server if the user completes the authentication in the IDP um the IDP will throw an error the redirection is wrong I won't give you the authorization code otherwise the user can otherwise I can collect the authorization code and and means like correct or valid section token the user So again the message after LTFM is redirect

URI is not is not arbitrary. Uh Microsoft doesn't publish their first party apps redirections. So this is actually the main thing that we need to find out uh in the process. Um and then we head into the research setup that we need to you know how how do I PC this? What do I need? Right? Right. I need an entry ID like um like a a tenant, right? Pretending to be a company. And I need the correct license to to to be able to set it up that so that um there's a condition access rule requiring um compliant device for all power apps to sign in, right? Um and and and then I could, you know, do whatever I want to

until I get it or I give up, right? So the first first approach because um they say is uh device registration whatever bypass the first thing I try okay device code always also has device in it the name has device in it does it work well it does not um unfortunately um you can specify client ID when initiating a device code login but um unfortunately it was blocked um said your client sign was successful but your admin required the device to be you know um registered in our um domain to to to access this resource. And so then you know here we go we know um it has to something to do with the company portal app. So how do

we you know PC the attack from like like the app itself. Um the first thing I did was using the app as is. So I downloaded from um MS um app store and trying to sign in and indeed I did sign in. So on the access log we can see the first one failure. It means that like the device code attempt was you know failed but the um using the app as is a normal user would um it got through and the client ID matches that of the sort of the um the rumor client ID right but we didn't know how it worked un unfortunately because um me using the company portal app does you know it

doesn't do anything useful in a red team so I need to extract the the authentication flow for me to analyze uh in in order to write my tool tools, right? And um the but I didn't want to do the man in the middle between the app itself and um and Microsoft because it's very troublesome. I'll go into why later. But anyhow, the the third approach I did was trying other known redirections like native client which is also in sort of the um uh MS documentations but it did it didn't work unfortunately. uh it was shown like the redirect redirection URI native client was um not configured with the application it's basically a URI mismatch right the client is not allowed

to sign in through this redirection so unfortunately right so the f the fourth which the the last and the hardest one was to try to get TLS layer HTTP proxy working um uh for a you know fake client device so if you do pentesting for um mobile apps or or like for fake clients like C or Java clients. You you you must have done some of this before. So you set up the system proxy as the burpuite uh proxy and then you install burp sweetes um certificate to the system you know root city store and then um listen on I think yeah local host would work because it's a like a local local application and um install suites um

certificate um and as a local machine root um certificate and then okay I do a I did a um curl from powershell and it end up on um on burp and is on HTTPS so I know okay TLS was working and also I tried Firefox uh is also like using the birth certificate so I know the proxy was working from the shell as well as from like a clan application okay now onward to um company portal it did not work it just refuse to sign in whatever I do after I've set up the proxy it's like login error but I won't tell you the error but you can share the error with Microsoft right No, I won't. So,

uh, what happened? Uh, well, my speculation was there is probably some sort of sec, uh, certificate pinning or some sort of mutual TLS check or like some sort of proxy detection, one of those, right? So, I was pretty like down and and pretty, you know, frustrated at that point. And some some of my friends, uh, colleagues at work suggested a couple of, um, like honorary mentions, right? For example, I tried the Linux Microsoft company portal app which didn't work at all. Like it it just didn't work flat out. It was on like Ubuntu 3204 didn't work. I tried to start a developer developer console which like my friend suggested like try to press like F12 or control shift J to

see like if the JavaScript console pops up. It does not. Uh so there are no logs to review for for this. And so Google so I thought you know I'm not the only one who wants to um do come portal app through a proxy. There are like legitimate organizations that has you know TRS inspection and and like um SSL script paying. So so their company polic will break as well. So um as expected some some some guy put up a post regarding how to fix company polo app login ising issues in win 10 win 11. So after the like reboot your PC uh reinstall your company portal app like I scroll down and there there it is the

the the error message in the in the bottom um the redirection URLs the the ms-fx- web thingy it's like what what what is that right so I followed the um event error code and went to the uh Windows event viewer on on like my local machine and sure enough the the full URI is there in the event log. So um so what what do I need to do was like extract the redirection UI and and and craft specially crafted um um login lane for for users so that I could get my correct scope for my tools. Right. But before that um I reviewed the log um interestingly I the the whole tenant does not have a have a company device.

It was impossible to sign in from a company device because there's none right. Um so you can see the um grand control says not satisfied because the um company device is required um domain join device is required um so failed but successful um in authentication somehow right um so then I crafted my special you know special source that's Germany UI to to to sign in and then um I was able to you know talk to the graph API in in in non non-cloud people terms that means I could do who am I in the cloud after this? So that means the application was working. Um I could you know write a tour of this. So um uh then

we just um weaponized the the thing in in a week because we um I I spent like one day on on the um on the discovery bit and um the the tool was released a week after but of course not. So um in our red teaming we needed a generic like a token manipulation tool or authentication tool. So I wrote it wrote a generic like authentication tool already but I added the bypass into my tool um with help of our French HP of course codebase was 85% there and um so yeah um bit of demo time um cool to see it works let's see right so you can see here um if I sign in um

it will Okay, you cannot, you know, access from here because you're not um joined. And I run the uh run the tool. I use the special UI generated. And I go back to the same browser session and it says, "Oh, I trying to sign in." And I pop open the JavaScript console to copy the the the the error message and and paste it there to redeem the correct, you know, access and refresh token here. And those tokens could be used to run graph runner um ro tools and whatever graph API your favorite graph API API um exploitation tool right so let's get back to the so that little that little video there was the one that people

watched um 240 hours total so I'm pretty proud of like production afterwards um so back to that page yeah right so the like the technical bits um up to this point is more or less done. So the the in my opinion second half of the story is the more fun part of the story actually. Um let's talk about like vendor disclosure and so forth right. Um do we need to do responsible disclosure before publishing this? So um fortunately the uh person Mr. Mr. TR already told Microsoft and as expected Microsoft tell him to you know go home it's a feature we won't bother this so I don't need to disclose twice and be told off twice like the second

time but um third gen was the person like wrote wrote tools as well as disclosing like the client ID for me to reverse entry so I want to be nice and I asked him like uh we plan to release uh blog post and the tour of your your news is that okay yeah sure um let me know what's up a nice So um the timeline so far um 11th November was the first first news and then on 12th December um disclosure of the vulnerable ID by um by third gen um two days later in research done a week later code rewritten and and repo was out and so at 20th of December I didn't want so I I I put it out but I don't

want to promote this because it was like right before the long holidays I don't want the blue team around the world occurs me and and also um I was worried like people won't watch uh read LinkedIn like right before holiday come on right but we want to put it out there anyway to time stamp you know our release um so unfortunately um it caused some trouble um was the drama right after bossing days this uh the WhatsApp chat um for you know our internal team and um on 27th night my boss said, "Hey, Sunny, there are couple of people who are sharing this without crediting us, right?" So, they even have the same screenshot that that you know

my my GitHub page use. I'm like so angry. Um and um there was one um influence came away like thousands of likes and whatever for for for like sharing sharing our our our research but didn't even you know um credit us. So I talked to him nicely. Hey K um thank you for covering our tool. Um I released a week ago without social media because of holiday season and so forth. That said, would you be kind enough to credit us? Thank you. And he was like ah totally understood. No problem. Um great tool by the way. And um um he did you know take a jab at me and saying ah researchers they they release things in hot day season. And um

so um he also reshared our our our post as well which is actually quite nice. Um and it was a very stressful night on 27 because um from the rumor of something big and being able to PLC that quickly before everyone else and then you know p pushing out to community uh it's like a lot of our our effort and somehood went into it. So we want it to, you know, be properly received. And um uh so you can see like the the um impressions and so forth. And um what happened like a while afterwards, two months later, Microsoft shadow patched it without any crediting, any research in the in the commission again. It's like they

quietly reduced the scope for the token it could get from company portal. So it used to be um like user read read all and um like group read all some something like that. So so you could enumerate groups users and so forth with that but now you could only you know read the the one user you get and the service principle endpoint. So it's like sort of useless from like direct usage um kind of um kind of standpoint and also my tools um binary was uh become my way by defender. I I felt pretty proud that day as well. And um um what happened now? So does that mean you know after the shadow patch the

attack has become useless? Um I would say the attacker will still need to enroll the malicious device into like the the um the the tenant. So you need as a defender you might need to look out for like um malicious device that is registering your you know AAD or entra ID that you don't recognize and watch out for like the company uh portal device ID being used like in a specific way by my tool basically and yeah so there was like the detection blog post written by the guys at Cusera and you can have a look um to to see if it fits for you as well. Um anyhow the uh last live before lunch um I think

threat actors and kos monitor like the popular company blocks um it's a bit of a moral conundrum for us as well because uh when we publish something um like we see it in the wild like a year later or they the ransomware groups and so forth they use stuff that we we write and sometimes like a half uh half written passion project that solves some of your problem might be useful suddenly weaponized is for in case you know there's something that comes out. So, and the first thing third thing I would say don't be shy to talk to people who are apparently famous in the in the community and ask for like what you think you deserve and you know make

friends along the way. So, that would be thank you and Q&A.

[Applause]