 So as mentioned, I am currently a senior scientist at security risk advisors, which is actually a new job for me and very excited about that. So I do a lot of research innovation and focus on cloud security, engineering and architecture. Before that, I was an OTHU 65 cis admin. So that's kind of my area of expertise a little bit more so than any other things. And I'm also grad student computer science. So basically, I'm just a masochist and have no free time as well as being a blue team village organizer. So here at DEF CON, you'll probably see me around quite a lot if you stop into blue team village to our discord or wherever else. And so I'm going to just hop right into it. So the title of this talk is exploiting the OTHU 65 do two factor loophole or misconfiguration. So I'm going to talk a little bit about what the scope of this actually is. This applies to office 365 on azures on an Azure tenant on which all basic authentication is not fully blocked and we'll touch on that a little bit later as well. And this is happening on tenants where two factor authentication or two factor verification with duo is implemented. And it's applies to configurations, most likely implemented prior to August 2020 for their abouts, which I will get into So for a quick background in order to understand kind of what's going on here. There are a couple of OTHU 65 authentication types. So Microsoft being Microsoft uses its own terminology. So what it refers to as legacy auth is is basic authentication and these are protocols that send username password in header. In plain text, essentially, unless they're unless they're sent via HTTPS or some other protocol. Modern authentication refers to slightly different methodology with client server authentication uses access and refresh tokens. And importantly, modern authentication is a requirement in order for two factor verification or any other MFA service to actually work. So that's a very important point. And then we also have some email protocols that may be familiar to people pop IMAP SMTP are all legacy authentication protocols, although there is support for modern being built into them. The second one active sync is going to be the most important one here. And then there are other ones like Mappy RPC and these are used for services like Microsoft Outlook. So what is this misconfiguration. So first thing I want to clarify duo is not actually not actually part of the misconfiguration. This is entirely on the office 365 side of the equation duo's documentation explicitly notes that Modern authentication is required in order for this duo to be triggered. So that is a very important point here that they actually do make clear. The second part of this is conditional access policies and Azure Active Directory. So O 365 as a tenant use it's essentially backed by Azure Active Directory and all access is run through Active Directory. And the configuration that duo requires in order to work with O 365 actually involves conditional access policy and what's called a custom control. That basically enforces an action triggering the duo authentication to a selected set of users cloud apps or actions and conditions if configured. And then finally we'll you know you can write a policy to either perform an action or deny access period. And this access grant is where the duo integration actually happens and what sends it off to to do to be to go through that second factor. So let's take a look at what that looks like. So essentially under when you're configuring conditional access policy you have all of those previously listed assignments and access under the configuration in Azure Active Directory in the security portion. Under conditional access. So importantly when you have conditions you have options to kind of scope an action a grant or deny by something that you select one of those things being client apps. So this was in preview before August 2020, which is kind of why this is this misconfiguration has happened probably as widely as it has. So you'll notice that first of all, so this year right here is actually the current one. And I'll show you a little bit what the previous one looks like and why that would be an issue, but you'll notice that Active Sync is listed separately and in the new configuration it's listed as legacy authentication client. So there are some exchange Active Sync clients that are actually integrated with modern authentication, but that is not necessarily not necessarily the case and it doesn't really indicate that it's always going to be under modern off if it has a basic authentication workflow. So, if not checked in this as an is this example, this duo policy, which operates under the condition of whatever users you select conditions client apps all these three, or just the top two which would be makes sense to most people. It essentially means that Active Sync would not be triggered to to be pushed out to to duo. And then another previous configuration that people have used is actually creating a second conditional access policy that explicitly blocks legacy authentication clients. However, in the previous configuration, the only one that this actually applied to would be other clients the way it actually appeared because those are the commonly listed ones like pop and I map. So Active Sync is kind of this weird protocol that's hanging out separately and is a bit misunderstood when someone like a systems administrator who may not be as familiar with it is configuring this policy. So, if we leave out Active Sync what does this look like. So if you go into iOS mail the regular mail application not outlook for iOS. And you go and you you hit, you know, Microsoft Exchange account, you sign in. If you sign in with a company account, you'll get a pop up from Microsoft you enter your password. This window will will trigger the duo prompt to actually happen. So it's essentially this is reaching out, even if Active Sync is not actually triggered. So there is basically iOS has support for supporting modern authentication and triggering that duo prompt right in its own application. So after signing the duo prompt would show up cool, enter your password and Bob's drunk or whatever that weird expression is. That's the normal workflow. That's how people normal users would actually expect to be able to configure the mail on the Apple iOS application. However, if you actually cancel out of that previous window, or configure manually, you can actually configure the the Active Sync basic authentication side of the equation and wind up skipping the prompt entirely. And that is literally how this that how this exploit actually works. It's essentially fail out of the the duo to factor prompt or skip it configure manually for Active Sync. And because we have that whole where conditional access policy was not actually applied to to that conditional access policy. Then this is what we wind up with the ability to do this. And honestly, you know, this is something that when researching, you kind of go through this from this perspective of an end user who is just going to be able to all they want to do is sign it for their email and they're not going to notice whether or not they're you know being prompted for for duo or not, they'll probably be happy not to be prompted for it. But that is essentially how to do it on iOS and it still works actually tested it this week. So, and this is also important to note because Active Sync is a protocol something that you can build right into an application, or you know run a script and password spray on these two instance and AWS if you want to basic authentication, literally it's just a basic coded header edition that states what the authorization is it's basic goes using password. That's it pretty easy. In addition to that Active Sync gives clients access to email context calendars and other things not just email, but it also has no ability to reverse authorization, aside from that initial authentication so it essentially grants access to everything which is why it can be such a lucrative exploit if you would like it to be, or why you should be a little nervous if you don't want it to be. So why does this happen. Prior to August 2020 on the left side this image shows that Active Sync was actually not listed or explicitly mentioned as being a legacy authentication protocol. So, when, when customers have configured things like this second policy is mentioning to actually block. Basically authentication they may have gone right to the other clients notices that had pop I map and thought that that's all that they have that that was needed to block, and that's not necessarily the case. The updated version of configuration makes it a lot more clear fortunately. Another thing is that client apps was in preview before August 2020 and previously, it actually stated that conditional access policies by default applied to browser based applications and applications that utilize modern authentication protocols, which meant it only applied when it was able to apply and did not impose any kind of automatic block or implicit deny behavior. In August 2020 that actually changed. So when you apply a policy, even if it's, you know, if you select Active Sync and it does not. And, and your client is using basic authentication, it at least sees that it's supposed to be enforcing with modern authentication and prompting and it actually fails out that behavior is is newer. And then the behavior of the client apps condition as well was updated in 2020. So previously, you know it wouldn't implicitly block anything or apply to to for all those four options on the right hand side. And as of after 2020, it actually checks all of them by default. So if a configuration was done after August 2020 with similar steps, everything would be checked checked off by default and this whole would not exist because of that. So I know I'm really probably pretty sure on time at this point. So just a quick note for for actually finding this in a client if you're Office 365 administrator and have access to the Azure Active Directory blade in Azure. If you actually search for client app exchange Active Sync you'll actually see it and that is only going to show you the basic authentication side of Active Sync clients. It fully reauthenticates so you actually see frequent frequent authentication actions, which is actually pretty cool. Just a quick note on this though, the few minutes. Thank you. So note about this I just dropped a quick little splunk query in here that should catch motion to everything and give you kind of a breakdown of who's using it. But the sign in logs are actually more accurate when they're you access through the, I think the keep my say UAC United Unified Activity Log. That's it. Unified audit logs in PowerShell and also in logs as their configured propagator to Splunk rather than in the portal because in the portal it shows you in the list before you click details. It will show you the client app and it'll say conditional access success, even if conditional access was not applied, as you can see in that graphic there. This is really important because if your system is just looking really quickly they're going to think that conditional access is working when it is actually not even being applied. So very important point right here. So the first thing you can do to fix this is tweet conditional access policy, just include everything. Again, it's much easier now that this has been reworked by Microsoft to actually do an implicit deny on the applications that don't meet the protocol for what this is. And the end behavior is a client can authenticate ActiveSync and it looks like they can load an account but they can't view anything and we'll get a message saying, hey, you don't have access to anything, which is actually pretty cool too. And then you can also just disable legacy authentication altogether. Please do it. Please kill legacy off. It is bad. That's kind of a universal truth. But realistically, we know that many clients are still using it. You're always going to have that person who just has to use Thunderbird or Pine or whatever and they're probably a VIP. So just make sure to do due diligence. If you're enrolling users into Factor via Duo, you're going to want to make sure that your conditional access policy covers everything. Basic is off is disabled for new tenants 365 tenants and existing tenants that have zero use of basic off. So if you've got one user, your tenant has not disabled basic authentication. Plenty more resources on this. Happy to answer questions. And that's it. That's all I got.