Abusing Holes in Conditional Access

I'm Brandon Colley, senior security consultant with TrustedSec, recently Microsoft MVP. Yay, me. And spoken at several different conferences, wrote wrote a whole bunch of articles. And what I do on a day to day basis and what I've done for probably the last three or four years now is evaluate Active Directory environments of several different customers. I've probably also seen about a 100 different Entra environments, which probably means that I've seen a couple thousand conditional access policies. So that's what this talks about. I've told people earlier that I've talked to in in the hallways, this is basically me standing on a series of different sized soap boxes and just yelling and complaining about stuff that I see on a regular basis. Also, feel free to to take pictures of me if you want, but all of these slides are on my GitHub, which there's a QR code later. And I think I think they're shared for everybody later as well. So took a picture of me. Alright. So what we're going to talk about? So we're going to do like some, like, first things first. Basically, the first question everybody wants to know about conditional access. I already got asked it once today. We're going to talk tackle that. We're going to talk about MFA and why you're not protecting as many of your administrators as you think you are. Trusted locations for the win or not for the win. Then we're gonna talk about how stacking conditional access policies basically yields them useless. We're gonna do some demonstrations around device platforms, couple more things involved in in that. That whole section really expanded over the last couple couple months. So and then we're gonna talk about finding the gaps. So basically, we're gonna show you a whole bunch of misconfigurations, how attackers are abusing them, and then hopefully, how you can find these in your own environments, a couple tools that that I've got. And then I'd usually say if we have time, but I'm going to do it anyway unless they kick me off stage. We're going to do some attack demonstrations using road tools, and we're going to do like a top to bottom, like you got you got owned type thing. So sound good? Yes. Awesome. Cool. Alright. So first question, everybody wants to know, how many conditional access policies should I have? Two eighty five. And yes, 244 is the or two two forty five is the only number that I will agree with that is too many because I've just talked to some gentleman earlier who said he's got a pretty good way to manage up to a 180, which normally I think is absolutely crazy. I think 80 is even crazy. Here in the middle, we've got the zero trust architecture that Microsoft they they published it, and then they removed it, and then I think they republished it. And so I I don't know if it's out there anymore. But basically, it breaks everything down into personas. So they have 11 different personas, and they have multiple different templates across those. So basically, if if you've implemented every single one of those, you've got around 66. If you've got exceptions and you have a different policy for each one, it it could potentially be higher. So some of the smaller organizations are gonna probably sit closer to this, like, 10 to 18 range, which is how many Microsoft template policies are out there as far as best practices go. So that's that's just a lot of of words to say. It depends. Right? Like, that's my consultant answer to it depends on on it. And the one thing that I think we should agree on so if if we disagreed about that and we disagree about this, like, this is the one I'll actually fight you about, Rich, is you need to name things like you mean it. I am sick and tired of seeing policies that are named allow Cliff access to exchange from this workstation. Right? Like, that stuff is garbage, and it doesn't even do what it says it does half the time. Half the time, it's like some weird MFA policy that that barely applies. So, this is just one framework. I don't care what framework you use, but something that seems to make sense, something that you can serialize and, keep track of. I have to point straight at this. Okay. So this is the point of the presentation where I usually say, yes, AI made a lot of these slides. It's all my content. But it had some sense of humor when it put all these asterisks in here by itself and it said terms and conditions apply because I think that's perfect. So first soapbox is MFA for administrators. Administrators. Everyone should have a policy in their environment that says MFA is required for administrators all the time no matter what. However, require MFA for admins really depends on who you consider an admin. And Microsoft, by their design and their template and the Microsoft managed policy, only by default covers 14 administrative roles, which is too fewer than if you have zero conditional access policies in your environment and you are running security defaults, which does 16 policies. So to make things even more complicated, Microsoft added a little privileged flag to permissions and roles, and there's 28 or probably more by now because they add them. There were, like, over a 125 now different policies. So or not policies, different roles. So it gets complicated. And most notably, you'll see down here, Intune administrator, which I'll pick on a little bit or a lot of it here in a second, is not one of those 14. Either is Cloud Device Administrator and Hybrid Identity Administrator. And Hybrid Identity Administrator basically controls your your Entra Sync configurations. So those seem pretty gosh darn important. And the reason I'm gonna pick just a little bit on this Intune administrator slide, I don't if you guys heard about the big Stryker breach that happened back in in March. You guys, you were gonna raise your hand and say, it wasn't technically an Intune administrator? No. I think it was a global admin that got popped in this specific instance, but it didn't even have to be because an Intune admin could do all of the same damage that a global admin could do in that case. So part of the reason why this is important, and this is part of the the first attack demo that I'll show. So this is the output from a tool called Find Me Access. Has anyone run this tool before? A couple hands, a couple people. No. So so what this tool does is it it basically sprays a valid authentication across, multiple different endpoints. So it tries all different resources against all different client IDs. And so it authenticates, like, hundreds or thousands of times. And so this is the output for my global admin. The the bottom one that does say true is is intended. And I think last time I ran it, it it actually showed false or it got fixed or whatever. So that's that's normal. But this is what it looks like when it runs as long as this part actually works. What? What, Rich? How do I get that? How do you get the tool? Yeah. You Google it and find GitHub, and it's a it's a GitHub repo. It's so it's a GitHub repo. There's links at the end. You little *******. So this talk is being recorded for all of you. Yeah. I know. I know. I know. Know. But we need this. Okay. Need this. And need that. Need You need what? This. Then go get it. What are you you you run you run git clone and then you type the thing. So so anyway, long story short, that just showed basically it's brought it's spraying like crazy. And what happens is when your MFA policy doesn't cover your Intune administrator like it does the global admin, this thing lights up like a Christmas tree. Now the only reason that Azure management API showed as false is because I kinda threw it a bone, and I and I used the the built in Microsoft policy that applies only to the resources of Azure API and admin, what is it, admin portal. So so, basically, we're blocking, like, two or three of these resources that are available, but you can still authenticate via single factor authentication on all of these other endpoints, including Graph. So what do we do instead? There we go. You you fix so we're gonna fix the 14. We're gonna actually create a policy that does what what it should be doing. And so instead of just targeting the admin portals, the Azure API, we're gonna target all resources, so that's gonna block all that garbage that we just saw. And instead of just enforcing MFA, we're gonna be really good stewards, and we're gonna enforce pass keys on all of our admins or some sort of Windows Hello or something stronger than gosh darn SMS, which I know is going away. Yes. Going away. We'll see. Also, we need to fix this this problem. So on the next slide, I've got this list of the 46 roles that I can consider to be tier zero and tier one. If you guys saw the AD panel, we talked a lot about tier zero. So we actually broke this down, and I have a document that I'll share at the end as well. A couple little caveats here that I wanted to add is specifically for Intune, they now have that what's it called? Multi admin yeah. Multi admin approval or MMA MAA. Not MMA. Right? So using that, it helps lock down that Intune role a little bit more. Also, if you are one of, like, the superheroes that actually use admin units in your tenant, applying these policies directly to the role will not apply to any role that's added to something that's not the full directory space. So in those sort of cases, if you have admins that are using admin units and have control under specific resources, then you have to do those by name or by group. I think group works too. Okay. So this is the list of tier one that you guys can all take pictures of and and stuff. This comes from a document that I'll also share at the end. Again, all of this stuff is is shared. We we at TrustedSec, me and about three other guys did like a brain trust where we went through and looked at every single role and what it could do and came up with our own tier list. And so this is what that what came out of that. There's a a pretty decent write up about it as well. Tim, did you have a question? Yeah. I noticed you missed one. View. Is it AI administrator? No. Which one? Oh. See, I think we specifically called that out in the blog of why we can did not add that in here, but I'd like to talk to you about it. Not now. I don't wanna get schooled by Tim while I'm on stage. Alright. So I'm gonna shift to my next soapbox with it, which is the trusted locations. And this is another fun little AI trust is doing a lot of lifting here. So I really don't like trusted locations for many, many different reasons. And mostly, it's because everyone's doing it wrong. And that's for multiple different reasons is, first and foremost is, who knows how to subnet and use, like, CIDR, Note 10. You can actually do it on a piece of paper. No calculators and stuff. Yeah. I see hands going there like, oh, no. No. I'm always in my hand. So this is good for you. Memorize that ****. This listen. I I tried to do it in a previous version of this presentation. I actually have, like, one of the old school AI arts where I told it, hey, diagram how to actually do this. And it was just a dude looking at like a a chalkboard, all questioning, and there was just **** everywhere. It was crazy. So so anyway, it's hard. It's it and so you might have done it wrong, which I would have done it wrong. I used to be an admin for fifteen years. I certainly did this wrong. And I'll jump over to, like, the stale trust part of that as a quick little story is what I mean by stale is you've set this, and I and when you configure a name location in Entra, it has a time stamp on it of when it was created and when it was modified. And that's one thing that I usually look at, and it's almost always two plus years ago or with the same date. Right? So nobody's looking at this stuff. Nobody knows when they last updated. And I realized that a lot of times, networks don't change on a fairly regular basis. But the only time as an admin that I ever looked at, like, sites and services or, like, an SCCM distribution points was when stuff broke. So this is just a it's never updated. Check it out. Also, wireless bleed is a fairly common thing where your guest network uses the same network sub subnet or context as your production, which poo poo on you. But this bottom one is a true story about this APT28 that breached a target from basically renting a common space in a completely different building and was able to infiltrate a customer. And then also VPN sprawl. Like, endpoints are everywhere, so you can be pretty much wherever you want to be. And what I usually end up seeing with trusted locations is that people use it in place of MFA. So a rule like this, it it exists where you sign in and it says, hey, are you in a trusted spot? Like, are you inside the castle? If that's the case, you're cool. You don't need MFA at all. Right? But if but if you're outside, then that's the only time that you need to. And I actually dug into this a little bit. The reason I think policies like this still exist in a lot of networks is because of single sign on. Back when all of this first started, before hybrid join was was a major thing, before the primary refresh tokens, the PRTs really came out and solved this problem for us is we didn't want our our users to have to to MFA, to log in, and then MFA, and then log in again, and all this stuff, and there's a mutiny. And so that's why some of these policies exist. This is an example of kind of what one of those looks like. And and I see this quite often where we have we have a decent grant rule where we're saying, like, require multifactor authentication. And sometimes they'll do, like, an or with it too, where they'll say, or it can be a compliant device. I don't have so much problem with that as I have a problem with setting up a a network exception to this, which gives your trusted location far more power than it really needs. And so what we need to do in this case is change the way that we're thinking about and using trusted locations. Instead, we wanna do a block rule, and so we're gonna block everything that can't MFA. So we're gonna still we're gonna still enforce MFA on people. PRTs are gonna take care of the rest for the most part as long as you're running fairly modern operating systems, And you can create an exclusion list instead. And so this is gonna apply only to those excluded objects, and then we're gonna add that ex exception of the trusted locations. Ideally, you've got, like, one per account set up for this, and you can really narrow it down to this service can log in only from this location. But this is a much better way to run locations in an Entra tenant. And so this is an example of that as well, where we have our specific users that are included, which is this MFA exclusion. So these are the ones that can't MFA. We have a block rule, and then we allow it only for those trusted locations. And, now is where I'm gonna pick on conditions because and so far, we've only done the trusted location as a condition. But but what happens when we've got multiple different conditions inside of a policy? And this is another thing that I see super frequently. This example is maybe a little bit overkill, but one thing that I see, and I actually just saw it on Twitter this morning, somebody else, I think Nathan McNulty shared something where he said, like, stop putting user risk and sign in risk in the same policy because what what happens with that is your authentication has to meet all of these in order for the block to actually apply. So you're you're really doing nothing. All all a login needs to do is not fulfill one of these in this example. And I threw, like, the countries too, so, like, blocked countries was in here as well. So these are all great things to do. Like, those are Microsoft recommendations. Those would be my recommendations, but not all in the same policy. These all need to be broken up. And so another thing that I tend to see stacked in production, and this is the example of that allow rule, what's this called? Allow Brandon to use Linux or something. Yeah. So here, we've got a trusted IP, and then we're also using a device platform. So this doesn't really do what what it says it does or we think it does because it have to we have to meet both of those criteria. And also in Entra, there's no such thing as an allow policy, so stop writing policies that say allow. I hate that stuff. See, I told you it's a bunch of soap soap box stuff. Okay. So this is a new slide that I added as well. So this was something that that took me by surprise a couple months ago. And it's something that I've I had seen in environments before where when when you're using device platforms and you have selected everything that's in here, it is not the same as not as as choosing any device or just not configuring it at all. Right? So a lot of people think, well, if I checked all of them, it's fine. And even worse is this is spread across multiple different conditional access policies. So you've got for some of your iOS and your Android, we want them to be compliant, or we want them to have some sort of like an app policy on those devices. And then we never want Linux, so always block Linux. But there's no overarching policy that covers any of the unknown types types of operating systems. And the reason that this is is such a a crazy oversight or vulnerability or or whatever is because device platforms work solely based on the user agent. So device platforms is the only condition that the client can control exactly who they want to be. Right? So if you're not familiar with a user agent, it looks like this when you authenticate, and it's gonna show you, like, hey, I'm coming from, in this example, it's SunOS. Anybody remember SunOS? Right? Like so so that's not one of those ones that we listed earlier. It's not a Linux. It's not a Android. It's completely unknown. So if we control and we can spoof and manage that, then we can bypass conditional access in that kind of a way. And this is an example of how easy it is to be a hacker. Right? If you want to be a hacker and you want to change your user agent, all you got to do is use Developer Tools in Internet Explorer or Edge or whatever it's called now. And you can just easily just change device emulation. You don't even have to be super tricky about about hard coding it. User agents exist in a whole bunch of different tools from an attack perspective as well. So like Find Me Access, the one that we we saw earlier that Rich yelled at me about. Give me this tool. That that does user agents as well as all of that too. So it sprays the crap out of I know. I told you we're gonna fight. So so this is an example of yeah. That's right. This is just an example of of when trying to log into Outlook, I got blocked because I was using, what is it, an iOS, an iPhone. And then as soon as I changed my user agent to be an Android based, it went ahead and it let me authenticate. So what we wanna do instead is block unknown or unsupported devices. So this is kind of a multiphased approach. So we've got a policy that that you've got that applies to basically everybody and everything. So we've got a a block policy that applies to all users, all resources, and then we go into device platforms, and we select only those that we want to support. And then you can layer that with your extra controls where you wanna go ahead and if you wanna allow macOS, but you wanna make sure that it's a certain version or it's under compliance or what however you want to manage it, then you manage that in a secondary policy. So this is going to block that case that we talked about, as far as how to exploit and leverage, application or sorry, user agents. Alright. So so far, we've covered some of my my favorite misconfigurations. We talked about policy sprawl and how easy it is to have too many conditional access policies, whatever that means to you. We talked about the admin MFA. We walked through how trusted locations does not necessarily mean safe locations. And then that took us down the rabbit hole using conditions, and we and we fought back against the device platform. So so what do we do about it? So here's our our attackers our our defenders toolkit. It says attackers too because I am gonna talk about some attack toolkits too. So first of all, what's built in? Right? So you guys might be familiar with the what if tool, which is still my favorite one to geek out on because it gets you all the controls to to try and test things and and see what's going to apply, where help you find out where those gaps might sit. I also don't know if you know about the security alerts or the coverage tab. Those are all in the dashboard for conditional access. They show you a couple different things, like security alerts is going to show you at the bottom of that overview. It's going to give you a drill down that shows, like, what events happen and and what percentages are covered and which ones aren't. The coverage tab is going to show coverage across applications, so it's going to show you if you don't have certain apps covered. And then probably my favorite one is the the policy impact. So I call this one the the your policy doesn't have to remain in report only mode forever type type thing. So policy impact will show you, like, essentially forecasting what this policy would have done over the last seven days, and it's gonna show you, like, what authentication attempts would have been blocked and and stuff like that. So it kinda gives you a little bit of a better view of of what might have happened. I'm not that's I'm not advocating for not using report only mode, by the way. So you can still use that. It's not forever. Okay. Community tools. Is Merrill in here, the audience? I know he's here here, but I don't know if he's here here. Sam says yes. Hi, Merrill. Merrill does awesome work. So I'm gonna show you ID PowerToys, the, conditional access documenter tool that he's got. That's a really cool one. I'm gonna say this the way I wanna say this, Merrill, is Meister. Right? So Meister is a fantastic, if not the best tool. I kind of gave up on writing my own tools, which other than this one, which is the Invoke CA review tool. It's just a quick little PowerShell script that I'll I'll show you guys too. It's another option. But CA Documenter is gonna basically create you a a PowerPoint, and it's gonna be one page for each policy you've got, and it's gonna be highly visual. So things like this are gonna help with some of the either the the not so technical people. This may be a good executive report. This might be something to go ahead and print out on a periodic basis to help identify Drift. But it's going to show you just a really highly visual example of what you've got in your environment at any given time. Super easy to run as well. And I have the links on the last page. Meister. So this is an example of what a pass check looks like. It does several different conditional access policy checks, but it also does a whole bunch of of, intra hygiene. It's it's getting into a lot of the other m three sixty five spaces and all of the other tools that kinda sit sit beside that as well. It's just constantly being updated. It's a fantastic tool. So this is an example of a past check. This is what I did well in my lab. This is what I did not so well in my lab. And the the point on this one that I'll add is that not only does it tell you that you failed a check, why you failed a check, it'll give you feedback of of what exists in your environment, but it also is gonna direct you to Microsoft's website for if there's a learn article that exists. And if if there isn't or if in addition to, it's gonna add some of their own documentation too. So probably the coolest thing around, especially mine. Like, so my my tool doesn't do nearly as much stuff. But basically, I wrote this. This is just an ad hoc PowerShell. It's about I used to say a 100. It's it's probably less than 200 lines of PowerShell now, and it it's documented somewhat decently. It's easy for for admins to read. And and part of the reason I wrote this tool was because I used to be an admin, and I wanted to vet basically anything that I ran in my environment. I'm not going to download something or tell AI to build me some code and just run it. Right? Like, I want to look at it and see what it's doing. So I wrote it so you can actually understand what it's doing. You can modify it, do whatever you want to do with it. But basically, what this does is it breaks all the policies. So it's going to read all your conditional access. It's going to break them down into 13 different categories that are loosely based on Microsoft's best practices, but also with a little bit of my flavor in it, I guess. And it's going to show you where each of your policies might be doing this sort of thing. It's not terribly intelligent, so it's not going to say you did that well. It's going to say you're trying to do that in this policy. Right? So if you see gaps in here, that means that you have no policy that is doing something that you probably should be doing. It also has a little bit of intelligence in there that I've been that I started to write where it's gonna look to see if any of your conditional access policies target anywhere beyond those 14 default administrative roles. It's also gonna start looking at if you have policies that are using strong authentication types instead of the default MFA. So it is a little bit of of extra stuff on the end too that I it's not in the screenshot. Alright. Cool. We're doing great on time, I think. So it's fifteen minutes. So now we're gonna do oh, ten minutes. This says fifteen minutes. Is that with questions? Okay. Alright. So I'm just gonna keep going. So let's see. This is what an attack is gonna look like using Roadtools, and it's going to exploit device code authentication. So we're gonna talk about all of this piece by piece. So first, we're gonna initiate the flow as the attacker. So this is just a Kali Linux box that's installed road tools on it. We're going to go ahead and and run the auth command that generates a device code. C code? I don't know. I don't I want to say token, but that means something different now. So anyway, it's a code. Then what I did is I created this this beautiful, well crafted phishing invite where I changed the Microsoft Teams link to just go directly to Microsoft's device login page. And then I changed the passcode to be my device logon code. Super crafty. Right? So, basically, what I'm doing here is I'm gonna fish or I'm gonna coerce social engineer my target into joining this super important meeting that said, hey, Bill's asking finance questions. Can you join us real fast? And they'll say, oh, yeah. Okay. Of course. Yeah. And what they'll see is click the link. They're going to copy and paste that code, enter the code to allow access. This is gonna kick off the authentication. So at this point, if MFA is required, if a passkey is required, whatever it is, it's gonna prompt the user for that information. They're gonna legitimately authenticate to Microsoft using the attacker's device code. They're gonna get this as basically their only indication that something may be odd. Right? They're are you trying to log in to Active Directory PowerShell? No. I'm trying to log in to Teams. Now I think we can adjust what this actually says, but that's basically the last the last attempt to save the user. Because if they click accept on that, they've authenticated. That authentication is transferred back to the users the attacker's machine. And now we have at the very top, we have tokens were written. So now we've got our our valid authentication token. Then we can run the road tools gather. And in my tenant, that took four seconds. And once that's gathered, it's all in a local database, which is less time than the user who clicked the link and said, okay, where's the Teams thing? I know Teams can take a while to boot up, but Teams never showed up. And before they even know to contact the help desk about an incident or change their password or whatever, we've already got all the data. And so from the attacker's perspective, now we're going to open up the GUI, and you can check out a bunch of enumeration details. So road tools will look at as a regular user account, it can view all of this information. So it can see tenant config, all your users, all your groups, all your roles, all your service principles. The the bottom right hand corner here too shows a couple escalation path opportunities. So it's gonna look to see, hey. Can can we invite a guest to the tenant? Maybe we can do some sort of persistence. Is is certain protocols available? Can I run graph against this? Maybe I can use that token to authenticate and run more and and do some more pervesque type stuff. So we've got a lot of opportunity here from the attack perspective. In addition to that, we can run since this is a conditional access policy talk, so under the covers, Row Tools uses a older version of Graph. And I don't know if anyone's aware that a normal user can't view conditional access policies unless they use the old version of the Graph API, in which case they can see this. So road tools is gonna spit out a static HTML page where a regular user can view all of the details of your conditional access, and they can see where they might be able to attack, where the where those holes might exist. It's also gonna output all of the named locations as well. So we can't really do anything to protect against you know, we we can't control if Microsoft turns off the old graph endpoint. But what we can control is the device code flow. Right? We can't prevent phishing, but Microsoft now has in the ability that you can stop authentication flows. And so this is what the that sort of policy looks like, where we've got a block policy applying to everyone, everything, except if you have, like, Teams phones or some of those other specific devices require device code flow. So you can exclude those from this policy. But then you go in and you select off flow and and device code, and that's gonna prevent this sort of phishing. This was new to me last year ish or so was kind of where it really started taking traction. And about every couple months, I hear a whole lot more news articles that say, like, yep. It's still happening. And so I went back to see when this was first a thing, and it's been it's been going on for five years. So Device Code Flow has been a a method of phishing for the last five years. And approximately a year ago is when Microsoft enabled the ability to do this. So if you're not doing this, very highly recommended as as a remediation step. So to save ourselves a little bit of time and do some questions here in a second, this is just gonna be my my recap slide. Basically, attackers aren't breaking conditional access. Right? There's no zero days that are happening. We're exploiting misconfigurations that exist. We're finding gaps that exist in environments. And we're looking at these misconfigurations that that tend to compound because Intra and and even Active Directory are these breathing, living organisms that that continue to change. Microsoft's continuing to roll out new policies, changing ways that things work. So I say all of this, and my advice to you beyond some of the the screenshots that we've got of some of the recommended policies and and fixes for misconfigurations is this is this is a testable thing. So run some of the code that I had showed you all. Run Meister. Run mine if you want. Run your own. Basically test. And to take take a step out of Jake's talk earlier, basically hack yourself. Right? If you've got the ability to run road road tools with permission, right, go ahead and run it. See what it looks like. See what you can see. Right? That way, you understand what the attacker can see. And then this is not a set it and forget it thing. So either get a pen test, get an assessment, assess yourself on a regular basis because things are changing very rapidly. And with that, I've got a whole bunch of references that you guys can click on later when the PDFs come out. And then this one's probably the most important one, the QR code that puts malware on all of your phones. So just kidding. This takes you to my GitHub. So if you go to my GitHub, you click on slides repository, it'll have this talk as well as a couple of the other talks that I've given in the last last couple months. So also, can follow me. I'm tech Brandon everywhere on the socials, on most of the socials, primarily primarily Twitter and LinkedIn and GitHub. So, yeah, with that, let's do questions. Michael, I told you I wasn't gonna answer any of your questions. I'm just teasing. Alright. Easy one. Don't worry. Like, speaking of misconfigurations, be honest, please. Have you ever locked yourself out of a tenant? I I have not locked myself out of a tenant. However, I'm almost positive that I have numerous very vulnerable tenants out there. So somebody else might be sharing one of my test tenants. But because I have terrible hygiene and I forget what I do all the time. But no. Because I don't apply very many conditional access policies unless I'm testing it very directly, and then I turn it back off. Yeah. Good question, though. Yeah. Don't get yourself locked out. Any other questions? We got time? There's one more upfront. Just a question on your Is that something that you came up with? The c zero one. So question question on your naming convention. The c a zero one, I know there's a couple different frameworks out there, Microsoft, a couple others on GitHub. Where did you pull yours from? And is it totally self made, hybrid? That that one specifically came straight from one of the Microsoft pages. It might it might be one of the ones in the links. I honestly don't know if I have that one there or exactly where I pulled that screenshot from, but that one did come directly from one of Microsoft's documents. Yep. Alright. Anything else? Are you all hungry and thirsty and ready to dance at the jelly roll thing? Cliff says yes. Alright. Well, if there's no other questions, then I'm not gonna take any personal questions. I'm just keezing. If you have questions, come up to me anytime. I'll be around tonight, tomorrow. So thank you all for coming. Really appreciate it.