 Hi there, my name is Bailey Bursik, and I'm here with my co-worker Mark Morzinski, and we're from the Microsoft Identity Product Group, where we work on Active Directory, Active Directory Federation Services, and Azure Active Directory. Our team is one that works with customers who are deploying Azure AD and we take those learnings and feedback from those interactions and inject them back into the product to make it better. Today, we're going to be talking about modern authentication for the security admin. Since we work mostly with identity people during our day-to-day, we have some conversations with the security folks, and we've noticed that a lot of security folks don't have the same identity background and haven't gotten the opportunity to dig into some of these modern auth protocols. We're really excited to share some of these with you today. To kick it off before we get into what SAML, OAuth 2, and OpenID Connect are, and then share an attack that we've been seeing on the rise, we're going to first talk about why you would even want to move to modern auth in the first place. When we're referring to modern auth, we're referring to what's happened after its predecessor with basic or legacy auth, which if you're familiar with basic auth, essentially, you're not able to allow for users to MFA, so with modern auth, you can actually have MFA'ing instead of just relying on the username and password. There's also more tools to protect those resources, so including some monitoring there. I have a few examples up on the slide, but in terms of a real-world example, if you have your entire fleet as Windows 10, for example, but then an attacker is trying to use a Windows 7 device and is trying to slip through the cracks there, you're going to have some additional monitoring there to determine that that's irregular or abnormal. And so that enhanced monitoring is going to be there with those modern auth capabilities. And the last big selling point for modern auth is that those user credentials are not exposed to the client. And as we walk through a few of the flows today, you'll see what we mean by that. And so to get into our first flow with SAML, so SAML stands for Security Assertion Markup Language, and it's essentially an XML-based authentication standard for SSOing to web-based apps. And this one of the three has been around for a while, so there's a lot of web apps that already have it, and since there is a lot of libraries that have been older than the two other protocols we're going to share with you, it's easier for devs to implement, so there's also no server-to-server comms with SAML. And so in addition to it being around for a while, if you have certain older on-prem IDPs, they may not support OpenID Connect or OAuth, and also it would prevent you from having the additional overhead of having customers consenting to an application. And so you'll see that later with the other flows, but if this sounds like something you'd be looking for, then a SAML flow may be correct for your particular use cases. So to walk through what that would look like, and as an example, I have Azure Active Directory as the IDP since we come from that product group, but feel free to mentally substitute that for Okta or Google or whatever you use as your IDP. And so in this example right here, we have an end user who's trying to access a web app via their browser. And then also it's important to note that there's a federated trust between Azure AD and that particular web app. So first in this flow, we're going to have the user open a browser and access that particular web app. And then after that happens, and the web app is going to redirect the SAML authorization request back over to the browser. Once that happens, the browser is going to relay that information over to Azure AD. And then that user is going to get authenticated within Azure AD. And important, as I mentioned earlier, that an advantage of modern auth is that those user creds are not shared, just a SAML token is going to be sent back to the browser. So the browser isn't going to get the user's username and password. They're just gonna get like a yes, this user is good to go. And so those tokens are going to be sent back to the browser. And then that SAML token is going to be redirected from the browser to that web app. The web app is then going to validate that SAML response and token. And then it's going to return that requested webpage to the user. So again, with those credentials not being sent directly to the web app, if that web app for whatever reason got compromised, the username and password of that particular user would not be compromised. So important to note. And what I just showed you was a service provider initiated SAML flows. You might hear the terms service provider initiated or identity provider initiated when we're talking about SAML flows. And so to give you an example of what an identity provider initiated flow may look like within Azure AD that may be like starting from the My Apps page or if you used Okta that might be starting from their end user dashboard. But essentially it's just beginning at a different point in that SAML flow. And so other than that, from your perspective as security admin, you may not need to go much more deeper into this particular one. But as a defender, what do you need to look for and what should you care about with respect to SAML flows? So first of all, and the biggest one that I think that has been on everybody's mind is Golden SAML attacks. So since Solorigate happened, this has been much more top of mind for a lot of customers that we've spoken with. And so as a defender, it's really important to ensure that those bad actors aren't able to compromise those different certificates. So what happens in a Golden SAML attack, bad actor compromises, the SAML assertion that you saw in that previous flow and then is able to forge those SAML requests. So essentially then they're able to SSO into any service as any user, which is particularly scary. Some other things that you may want to look out for as defenders. The assertion consumer service URL, also called the ACS URL, you may hear it referred to as the reply URL, which is required for some apps. That is what routes the user to the app that they're supposed to go to. So if this is compromised, then a bad actor could be routing your end user to a malicious app. And so it's important that that's validated that hasn't been changing. And on the next slide I'll go through some ways that you could reduce your risk of these different things to look out for. So the third thing that we've noticed is that if the SAML logout rule is too complicated. So if the logout rule is too complicated, the user may not be successfully logged out. And so you could imagine that if the user is on a shared machine or a shared device, then the next user who would come up to that or the next person would be able to have that previous user's access. And then the last thing that we've noticed that you may wanna take note of is token monitoring. So swapping those SAML tokens for session tokens and you can reduce your risk of that by ensuring there's some sort of inactivity timeout or a maximum token lifetime to reduce the possibility of those types of attacks. And just monitoring those tokens in general is going to be a great best practice. And so overall with these different things that we've seen, what can you do? So in case of something like the golden SAML attack, protecting your IDPs like you protect your domain controllers is really important because if they can get a hold of, or if a bad actor can get a hold of your IDPs and they can issue claims, it's absolutely anybody which is particularly scary. The next one is to protect your certificates. So use good cert hygiene, use an HSM, monitor for any changes, any configuration changes and any addition of certificates. And if this is a lot that you have here I wanna let you know that we have some updated guidance our Azure AD SecOps guide. So if you go to aka.ms slash Azure AD SecOps you're going to see a guide that Mark and myself contributed to but several other folks within the identity org have written sections on where we go through what to monitor, what to look for and certain risk levels to be aware of with different areas in Azure AD. We cover everything from apps to PIMs to other things but you will see some related content to those particular same old flows. So just worth noting. And with that, I'm gonna hand it off to Mark to talk about two of our other flows today. All right, thanks Bailey. So the next one we're gonna talk about here is OAuth2 and before we get into the details Bailey and I found this tweet that we thought really landed a message home that we wanted to make sure landed with this audience. So I'll just read it out here but how do developers mess up OAuth2? You only need to understand the OAuth, OIDC, JWT which is JSON WebToken, JWKS standards, nuances of HTTP redirects, nuances of RSA versus ECDSA. Remember to validate that JSON WebToken is signed using an expected algorithm. Check the expiration to have a chance of getting it right. So this Twitter user here, Little Joe Tables there is not wrong. There is a lot going on in these minor authentication protocols. And one of the takeaways that we wanted to make sure this audience got was that if your developers are starting to move to these minor authentication protocols they should not be trying to roll their own implementation of OAuth and OpenID Connect. There's a lot of things to keep track of here. They really need to use a library because well, first of all it's a waste of their time to like write their own implementation when they can use a library. But if they don't get all these things correctly it really can lead to some drastic security mistakes and things like that. So we wanna make sure we're using libraries and we'll cover some of that here in a little bit. But hopefully as we talk through this the rest of these sections here this whole thing this like word soup that Little Joe Tables had here which is totally accurate will start to actually make a little bit more sense. So let's dig into here what we mean by OAuth too. So if you haven't heard of OAuth before OAuth is an authorization framework. So it's not about authentication it's about authorization and it's really just a delegation protocol. And you may have seen it phrased as getting the right of access from one component of a system to another. So that example on the right here is what the OAuth Consent dialog box looks like from an Azure AD perspective. So here we can see that there's an application called Contoso Test App and it's asking for the ability for the user to read that user's contacts, calendar and profile. If you haven't used Azure AD that's okay. You've probably seen this on different other web properties and if you haven't seen that at all I'm sure you've probably seen this on your mobile phone when you install an application right and the application might be asking for the ability to maybe read your contacts you access your pictures or access your counter very very similar type of thing that you probably experienced on your mobile phone. Now OAuth is built to leverage HTTP and it uses tokens and scopes to kind of communicate this information. So let's take a look at a little bit of the components here of OAuth. So if you take a look at the OAuth RFC you're gonna see four key components. That's the resource owner, it's the protected resource, the client and the authorization server. And this kind of seems a little weird it's not used to what we're kind of looking at but as we talk through this and then we have some slides to kind of lay this out visually from a sample hopefully this will start to make a little bit more sense for you. But the first one here the resource owner this is just the person and they're gonna be at a browser and we have browser in quotes here because it doesn't have to be like edge or Chrome or Safari. It can also be like a mini web browser instead of an application or something like that but they're gonna be some sort of web flow and this owner resource owner or user has access to an API and they have the ability to delegate that access to that API and what they're really delegating access to is that protected resource which is the next component. This is usually gonna be a web API and this is the thing the resource owner has access to. So in that previous slide you saw that that protected web API that was being asked to get access to was the ability to read the calendar and contact. So we're trying to get to that protected resource. The thing that's trying to get to that protected resource is the client. Now this isn't client like has to be a thick client like on a desktop or anything it could be a web app but this is really going to be that piece of software that is accessing that protected resource on behalf of that resource owner. So in that previous example that was the Contoso test app that Contoso test app is going to consume this protected resource it's going to consume that web API and the way it's going to do that is it's going to do that through something called access tokens and it's going to get an access token from the authorization server and this is the protrusted protected resource that's going to issue access tokens to the client that the protected resource sorry this is the authorization server trusted by the protected resource and it's going to issue those access tokens to the client that client's going to take those from the authorization server and take those to the protective resource. One of the key things to learn here of all these four components is that the user never is exposing their credentials to the client. They're only going to expose those things to the authorization server when they do authentication there. This is one of those patterns that Bailey talked about, why I want to move to modern authentication. It's better from a security perspective. We're not exposing those users credentials to that client piece of software. Let's take a look at this from an example, lay this out a little bit. Very similar to Bailey's diagram here, we have our user in the lower left. That's the resource owner by the actual OAuth RFC, and that user is using some sort of application. That's going to be the client, and that client is going to want to access some sort of protected resource. In our case here, that's going to be the Microsoft Graph that wanted to be able to read about that user's contacts and calendars and profile. It's going to be using the Microsoft Graph. The way it's going to do that is it's going to need to talk to the authorization server to get that access token. In our case here, that is Azure Active Directory, and if everything works right, like it's supposed to, that client is going to get an access token, which will show up here on the lower left. And that client is going to take that access token, and it's going to give it to the protected resource so it's able to access the data it wants to access. So let's take a look inside what's inside this access token. So this access token is frequently called a bearer token, or if you're actually reading the OAuth RFC, it's just called a token. And the reason it's called that is because whoever has that token, right? So whoever bears that token, whoever carries that token, has the right to use it. So we want to make sure we're protecting those tokens as much as we can. We want to make sure we're using HTTPS or ever possible. Now in the OAuth RFC, it does not define a token format or a message signature, but one of the more commonly used formats you're going to see with these access tokens is a JOT token or a JSON web token or a JWT. And in this JSON web token, it defines the ability to sign in and code. And all this is defined in RFC 7.1.19 if you want to look more info about JSON web token specifically. We're not going to go into too many more details about those specifically, but it's a very, very common access token format. Now the key thing to understand about access tokens is that the authorization server is going to issue that access token and the protected resource is going to consume that access token. And those are the only two people in this entire diagram flow that need to be able to use those tokens. Now the client's job is going to take that access token and take it to that protected resource, but the client has no need to actually look at that token or understand what's inside that token as long as the authorization server issues the access token and that protected resource which trusts it can consume the access token. Our stuff will work. We're good to go. The client does not need to go in and look at those tokens or making changes or any of that kind of stuff. It just takes the token from the authorization server and takes it to the protected resource. And then what's inside that token when the protected resource is going to get it is going to define what it can do like the ability to do user.read or anything like that. That's going to be inside that access token. So this is what an access token looks like when it's encoded. Again, this is what the client's going to see and the client has no need to actually inspect this or look at this. It just needs to take this and take this over to that protected resource. So let's look at what it looks like when it's actually decoded. So PowerPoint isn't the best tool to kind of look through an access token. So this is like a JSON file. So we bolded a few things here to kind of make this stick out for you a little bit. So the first one here is the very top. You see the type is that JSON web token. This is coming from Azure AD. And we can tell that because you can see that kind of towards the upper middle, you see the field of ISS. This is who issued the token. And you can see sts.windows.net. That's Azure AD. And we can see the app display name is going to that line of business workshop demo. So those are some things in the token. There's lots of stuff in here. We're not going to cover all of them, but this is what it looks like when it's decoded. So another question really is, how do I move this token from one field to another? So there are many, many different flows as part of OAuth. And one of the things as defenders that we want to make sure that we're doing is we want to make sure we understand these flows and what is the right flow for the job? I've seen for multiple customers that I work with that sometimes the devs just don't know and they'll just pick a flow that they think is right and they really should be using a different flow. And I've had this where the hawkamist doesn't do this and they've really just picked the wrong flow. So what I've seen some customers do this that is actually really successful is the defenders and the app development teams and things like that kind of agree on these are the different types of application behaviors that we have in our environment. And then as a new application comes in, this is the right flow for the job. So let's kind of talk about these flows. The first flow is the authorization code grant, which is the majority of your app types will use this. And I have about four or five slides will kind of walk through this flow. It's kind of has the most steps in it, but the other flows kind of behave in a very, very similar way. But once you kind of understand that flow, you'll be able to pick up the rest pretty, pretty easily. The next flow is the implicit grant flow. And this should only be used for single page apps, right? So it's where everything kind of lives in the browser and we kind of want you to move to authorization code flow if possible. And the reason for that is that client piece, the client component also needs to authenticate to the authorization server and an implicit grant flow because everything takes place in the browser. There's no shared secret from that client. So we kind of want to move you to the authorization code grant flow as possible. Another very, very common flow that you'll probably run into is the on behalf of grant. So this is when that client application is going to call that protected resource, like call a web API. And then that web API needs to call another web API. So very common I've seen with customers where they're maybe calling some base API and API needs to query another database somewhere else for more additional information. The on behalf of grant would be the flow you'd want to use for that. The third one here is the device code grant. So this is when we have those input constrained devices where we don't have maybe a web browser. We don't actually maybe have a mouse and keyboard. So IOT types of stuff. Maybe we have like just an SSH window or something like that. That's when we use one use a device code grant. So for IOT printers, things like that, this is a really, really good flow to use. The next one here is the client credentials grant. So this is really for those service to service calls. There's no resource owner in the picture. There's no user in the picture. So this is for like service accounts in daemons. That's when you'd want to use that. So those are the main five flows we want people to be using. Now I'm also going to include this six flow, which is a legit flow, but we really don't want to use it, which is called the resource owner, password credential grant, or sometimes this will be referred to as the ROPC flow. And if you look at those terms we just learned, which is resource owner, user, and password credentials grant, you're basically just having the user give their username and password to the client app, which was one of those patterns that we don't really want to follow that Bailey talked about moving to modern authentication. We don't want to do this. So you're very, very sure if you're going to use an app that does ROPC flows because you need to really understand the risks that you're going to be exposed to. And one of the customers that I work with didn't quite understand that. And they had a bunch of apps that were being using ROPC flow once they really took the time to learn these flows. They realized they don't want to do this at all. And they moved to the authorization code grant flow. So let's take a look at what this actually looks like here from a authorization code flow. So we have those same resources that we just showed you before where we have our user who's the resource owner. We have the application, which is considered to be the client. We have that protected resource, which is the Microsoft graph. We have our authorization server. In our case here, this is going to be Azure Active Directory, but this could be Octa, Google, and the other type of identity provider that does OAuth. And what's going to happen here is that application or the client is going to request authorization to the resource owner. So that application is going to request authorization to the user, and it's going to redirect to the authorization endpoint against Azure Active Directory. And here, this is where that user is going to provide their credentials. They're going to authenticate against the authorization server. And once they authenticate, that's where we see that dialogue box that you saw before. And once they click accept to that, the authorization server is going to redirect the user back to the client and give them a special authorization code. Now, the client is going to take that authorization server, I'm sorry, take that, take from the authorization server, that authorization code, I'm saying the same authorization word like six times and I'm getting like tongue tied there. So, okay, we have authorization code and it also has its own credentials, right? And it's going to use those client credentials. It's going to present those as well as authorization code it just got from that user to the authorization server that everything works out like it's supposed to. Now the client is going to get an access token and it's going to use that access token and it's going to go against the protected resource and it's going to be able to access that resource on behalf of that user. So that dialogue box that we saw with the Contoso test app was asking the user can I read your contacts and calendar profile? The user clicked yes, this is what's going to end up happening is that client piece of software is going to get an access token and it's going to go against the protected resource which in our case here is the Microsoft graph. Okay, so a few key points I want to make sure we understand from an OAuth flow perspective. So the first thing was that user or the resource owner never provided their credentials to the client app. The only place that those client credentials their username password was used or however they're authenticating was against the authorization server which in our case here was Azure. This is a really, really good pattern. We did not expose those credentials to the client piece of software. This is really, really good from a security perspective. The second thing here is that the user has the ability to delegate those permissions that are needed for the client and we can make sure we're following the principles of least privilege, right? Those permissions that that client asked for with the ability to read contacts and read counter because that's all it really needed to do. It didn't ask for to read everything else about the user. It didn't ask to read all users in the directory. It didn't ask to read right into the directory. It was able to be scoped down to only what that application needed to do. And this is a tremendously good security practice as defenders that we wanna make sure all our applications are following. That's gonna be in our go-dos coming later. We wanna make sure we're using least privilege or however possible. And then the client access the protected resource with the access token. And the reason that works is because that protected resource, in our case here is Microsoft Graph, trust the authorization server. So you have to have that kind of set up ahead of time but that's how that access token works. So this is really, really good flow. Authorization code flow is what we wanna be using but let's take a look at this ROPC flow. And this is one of those patterns that we don't wanna be following. So it's a real simple one. The user gives their username and password to that application. And an application logs in as that user to the authorization server to get that access token. There's no delegation here. There's no MFA here, right? This is just the application authenticating as that user to the authorization server. And this is basically just basic off, right? So Bailey talked about, we don't wanna be on basic off. We wanna move to that modern authentication. This is not really a good pattern from a modern authentication perspective. There are very specific scenarios where you'd wanna use this but this is very, very risky. So we wanna make sure we understand fully what's about to happen to us because our users are gonna give their username password to this client application that we better trust because that client is most likely gonna cash that username password as well. So now those credentials are gonna be stored there. So we really, really don't wanna use this pattern unless we really, really have to. Maybe it's a specific line of business app that you guys write as defenders or something like that and we really know what we're gonna get ourselves into. We're okay with it, but you really, really wanna make sure everyone's aware of what's gonna happen when we use our OPC code file. Okay, so let's look at OpenID Connect. So OpenID Connect is actually a standard that's built on top of OAuth2. So OAuth2 was designed this way to be extended like this and OpenID Connect, it basically extended OAuth2. And now this will also perform the user authentication, right? OAuth2 is authorization, sometimes abbreviated as OAuthZ. OpenID Connect is off end. OpenID Connect uses JSON web tokens as well as JSON objects, signing and encryption. And basically you're gonna have a very, very similar pattern as you saw with OAuth2, except for when you get an access token, you're also going to get an ID token. So one of the ways that you can kind of visualize and think through this is that that client piece of software is going to be that relying party, kind of like how Bailey talked about from a sound perspective, where that identity provider actually the app trust the identity provider, very similar way here, the client is now the relying party. And in this claim is gonna be who issued that token, who's the subject of the token, who the token is for, how long the token is good for, it's all gonna be an OpenID Connect. So let's take a look here, how this actually works. So it's gonna be very, very similar to our previous flow. And again, we have our same components as before, we have our resource owner who's the user, we have the client, which is the application, we have our protective resource, which is the Microsoft Graph, we have an authorization server, which is Azure Active Directory. So again, our application is going to ask the user to get redirected to the authorization endpoint that's gonna ask for that consent. So redirects the user to Azure Active Directory. And we should see this is when the user gets authenticated and gets prompted. So this is just like before, the user authenticates, they click accept. Now the authorization server is going to redirect the user back to the client piece of software with that authorization code. That client now is going to do this. This is again, same thing as authorization code flow, right? So now we're gonna send the client credentials as well as the authorization code to the authorization server. And if everything works out, we're now gonna get that access token like we got before, but now we get an additional token, we get that ID token. And now the application is gonna use that access token to protect, to access that protective resource. And now we have an ID token over here from the application perspective, and it's able to request additional access tokens to kind of keep accessing that resource if it needs to. So the open ID connect flow is very, very similar. Hopefully that makes sense to you now at this point. It's very, very similar to the OAuth2 flow. Instead of just getting an access token, you also get an ID token. All right, so what should we be looking for as defenders from this? So the first thing is, you wanna make sure you're asking your independent software vendors like ISVs or people you're buying your software from, you want them to support open ID connect wherever possible. We don't wanna use these legacy protocols. We wanna be able to use things like MFA. We wanna be able to use some of those additional things that Bailey talked about where we can detect things because we have more information as defenders, which is really, really good. It's harder for the attacker to kind of guess all that different stuff. We really wanna use this. And I know a lot of people feel that like, well, yeah, I'm just a random company. Like why would they listen to me? Bailey and I work with some very large customers and some actually some very small customers. And the voice really, really matters. So when you're buying software, ask for this and tell them that you want this. You don't wanna do these legacy protocols anymore. You wanna make sure you're using open ID connect wherever possible. Okay, the next thing, if you're not sure if it's a good idea to roll your own library, reread that tweet and ask your devs if they know all those different parts of it because you just really don't wanna do this. This is kind of, to me it feels like it's very much like kind of like rolling your own cryptography where you'd be like, oh no, no, we're not gonna do that. We're gonna use, well-known things and use our libraries. We wanna make sure we do the same thing from this. It's a waste of time from your developer's perspective. And also there's bug fixes, there's updates to things or secure things, like you just don't really wanna roll your own. So if you're using Azure AD or any other Microsoft identity stuff like Azure AD B2C, the MSAL library is what you wanna use. We have them for Python, .NET, Java, mobile stuff, all kinds of stuff, use these libraries. It handles a lot of these problems for you automatically. The third thing is, we don't wanna use the ROPC flow. Hopefully at this point I made that very clear unless you absolutely have to and you have a lot of trust in that client application because you're basically doing basic auth. Your users are giving up their user and password to this piece of software and it's probably gonna cash that. So we really, really don't wanna use that. Fourth thing here, we wanna make sure we're using HTTPS wherever we can for this because whoever has that access token has the right to use it. So we wanna make sure we're protecting those access tokens. Sometimes like I said, they're called bare tokens in documentation or just tokens. We wanna make sure we're protecting those. We wanna make sure we're using HTTPS. And then lastly here, we wanna make sure we're focusing on these privilege when it comes to application consent. That's a great, great practice in general. So when your line of business apps are being used to open ID connect, you wanna make sure they're not asking for too many permissions, which is pretty common, right? From like, oh, I don't know what I'm gonna need. So I'm gonna ask for the ability to do directory read write all and just do everything. We wanna make sure we're following these privilege. And we also wanna make sure that when we purchase software, it's also following these privileges. This is not a new problem around these privilege with applications, right? Anyone that's been in this field for a little bit, someone buys a piece of software, they go, okay, can you please set it up and install it for us? And it's like, it needs domain admin and it needs scheme admin and you're like, we're not doing any of this stuff. This is way too many permissions. Very, very similar thing with this. We wanna make sure we're enforcing these privilege with this. And then last here at the very part here, there's an emerging attack when it comes to application consent that Bailey's gonna talk about. So this is some stuff we're starting to see. We wanna make sure his defenders were really, really aware of that. So with that, Bailey's gonna kinda talk about that and then close it up with some go-dos. Thank you, Mark. So diving into some of those application consent phishing attacks that you've been seeing on the rise. And before I go into what that attack actually looks like, I wanna go through some vocabulary that may be new to some folks who are listening. So I'm gonna disambiguate between delegated permissions and application permissions. And so if you haven't heard the term delegated permissions before, we're basically talking about permissions that are used by an app that have a signed-in user present in order to make calls on behalf of that user. And these can be consented to by non-admin users, but some higher privilege permissions do require that admin consent in Azure AD. It may be different for your identity provider. And then those effective permissions, so you can see I have this little bend diagram at the bottom. And that's referring to the intersection of the user's underlying permissions and what the application has been granted consent to do. And so essentially if we were to think about it, if a user were to consent on behalf for an app to read email, they're not consenting for that app to read every user's email, it would just be theirs because I as a user cannot read your inbox, for example. And so when we're talking about application permissions, that's a little bit different. So those are used by apps and they run without a signed-in user present. And these are typically going to be your higher level permissions and they always require admin consent. And so some of these can include app roles and app-only permissions, but you could think of these as delegated. As an user, I can consent to these. Application, as an admin, I have to consent to these. And if an admin consents to delegated permissions, that consents to it on behalf of the entire tenant, which is important to know as well. And so what is the attack that we've been seeing come on the rise? And so this is something and I have some screenshots of what this may look like to end users. A lot of COVID-19 themed emails or it could be a malicious web app. So for example, it'll be a very normal looking O365 access looks legit for my day-to-day or perhaps a link like this that I would have to approve. And so essentially what we've seen happening is that if a user then consents and they go through those flows that Mark and I showed you earlier, then the attacker can gain access to their mail, forwarding rules, file, contacts, you name it, based off of the permissions that that app has been granted. And so how do you find that illicit consent? So speaking from an Azure AD perspective, and so I imagine it would be a similar process with whatever identity provider that you have, but what you would look through is that first going to that Office 365 portal. So if you search through those audit logs, you can actually look for indicators of compromise there. And so if you look at particularly that is admin consent flag, if that's said to true, and that indicates somebody with that global admin access may have granted access or granted that permission on behalf of the entire tenant, which is particularly scary because if an admin felt for one of those consent prompts that I showed earlier, then that's for every user in the entire tenant. And so not just your everyday user with the smaller scope of effective permissions. You can also check in the Azure AD portal. So if you go into the audit logs there, or if you go through, go over to the enterprise apps tab, you can flip through the permissions tab for each individual apps. But I imagine that as defenders, you may have a lot of apps to go through and that may not be a good approach for you. So we have a PowerShell script up on the screen. And so if you go to aka.ms slash get Azure AD permissions, it'll actually spit out a report of all the granted permissions in your environment and different apps. And I'll walk through what that looks like in a moment and that's totally free. But, even better solution would be using something like MCAS or another CASB solution. But this PowerShell script is really awesome because as I pull up an example here, if you go through and you start with, just checking out the higher risk apps or apps with higher user assignment, that's something to monitor that if, you know, there's something that you wouldn't expect to be seeing, also be sure as you go through these and if you see anything that looks really bland. So a customer of mine actually had this attack happen to them and it was where an end user was consenting to something that had a very generic name, but it seemed very similar to a video conferencing app that they normally used every day, but it actually put their entire company directory up online because they consented for the app to be able to read the entire directory, which as an end user, I can see who's in my work. And so all of that personal information was published online. So something to note, in addition to just your everyday users, it's really important to monitor those high-risk users. So we have that in a tab for you as well if you run this report. And so that's where, you know, those who have higher privilege or higher access. So for example, any executives, anyone who may work in finance, someone who, if the content that they had access to got leaked, it may be, you know, a front page news story or something for your organization. So might wanna look into those. And also reviewing permissions for those delegated applications. So, you know, especially those read permissions like my customer fell victim to write permissions, start off all, reviewing those to make sure that they're appropriate. When I say reviewing to make sure that they're appropriate, I don't want you to have a takeaway from this thing that, you know, if an app asks for a user read write all, it is objectively a bad application. That's not what I'm saying here. What I'm saying is to look at the different permissions that are assigned to a particular app. Does this look legitimate? Is this app something that actually needs that level of permission? And then making a judgment call there as a defender while balancing, you know, the business impact there. And so I have a few more actionable steps that you can take as well within Azure AD. This also applies to any IDP that you may be using. So in terms of application consent, my customer had this very bottom one checked. So allowing end users to consent for any app without restrictions there. And so we actually advised this center one here, the little Goldilocks recommendation of allowing end users to consent to apps from verified publishers. And so that would, the publisher verification process is something that on the next screen, I'll be able to show you one where it's unverified. But if they are verified, that means that, you know, Microsoft has confirmed that that is who they say they are and that you can have a little bit more trustworthiness to that application. And something else that you can do is by, you know, setting up a policy with MCAS, you'd be able to automatically revoke an app or a specific user from an app if risk is detected. So something else to note there as well. Now, if you've selected that little Goldilocks option, you know, you might say, hey, do I have an ad, does an admin have to consent to all of these on behalf? And the answer to that would be no. So risk based user step up consent is enabled by default within Azure AD. And essentially the way it works is that if I as a user request for something to be stepped up to my admin, that or rather, excuse me, I as an end user want to consent to an app and then it will require that admin approval. So in order for the end user to get access, I as an admin will have to go through and say, yes, that end user may consent to it. And so the admin has the ability to prove or deny, the end user just gets a warning and an audit event is going to be logged as well. So you'll be able to have all of that tracked as to which admin said yes to that user having access and whatnot. And so a third thing that you could do is detect risky OAuth app. So Mark went through that OAuth flow earlier, but something you can do here is by, you know, running that PowerShell script. And even better thing to be doing would be to use something like Azure Monitor where you could set up alerts that'll notify you when an OAuth app meets certain criteria. So if they have that high permission set or if it was authorized by, you know, 50 or more users or whatever you want to set for yourself, and then that way you'll be able to be in the know as to what's going on. And the last thing that, you know, you have the budget for it or the ability would be to have a hunting solution, like a CASB solution like MCAS, because then you're going to be able to have some fancier detection and monitoring there and additional hunting capabilities. Now, I think also it's important that if you see something say something. So at the bottom of these app consent screens, it'll have a, does this app look suspicious, report it here, and that'll send it over to our team over at Microsoft and we'll be able to take action on it. So if you see something like this and if this app like data extractor doesn't seem like something legitimate that your user should be seeing, feel free to report it to us and we'll be able to do something about it. Now, some further app consent resources that if you are not already aware could be really valuable for you to take note of. So we have some incident response playbooks at aka.ms slash ir playbooks. So if you haven't updated yours lately, that would be a great place to start. We also have a sample malicious app consent or app with a consent prompt, it's written in Python. And so you can go to Mark's GitHub to be able to go check that out. If you want to go scare some people and demo to them why this is really valuable they should go look at it. And then if you felt like this app consent section was really short and you wanted to learn a little bit more about it, there's actually a full length hour long talk available on YouTube at aka.ms slash b-side CT for Connecticut 2020 on app consent. And so you can watch an hour long version of this instead of about a 15 minute bit on app consent. So if we look a little bit different, we had a slight glitch but so we are back on the recording. And so to get into our go-dos that we have mentioned throughout the talk today, if perhaps this was a lot of content also know that this entire talk is recorded and I believe will be on YouTube. So feel free to go back and replay any bits if you want to have a little bit of a recap because I recognize this is a lot of technical content that we're throwing at you. So the first go-do that we have for you today is to start moving your apps to modern auth. So at the very beginning of the talk we talked about the advantages of modern auth over basic auth in that you can MFA, you have additional monitoring and all the good stuff. And also that your user's credentials are not going to be exposed. So moving those apps to modern auth, if at all possible use open ID connect or a was two, if that's not possible, SAML is also a good option especially has been around for so long. The second thing that we recommend that y'all do is protect your IDP like your domain controllers. So also protecting and monitoring your certificates and all of this kind of bubbles up into those golden SAML attacks that we've been seeing especially if you're organizing. So Laurier had happened, what do we do to help reduce our risk of something like that happening to us? Protecting your IDP like your domain controllers. The next thing to kind of look into is ensuring that you have an activity timeouts and maximum token lifetimes. And then if you would like more information on some things to do in terms of security and operations, if you go to aka.ms slash Azure AD sec ops, we have a guide for you on things to monitor different risk levels and things that you can do within Azure AD. And if you don't use Azure AD, it's still a good guide to get you started on some best practices that you can apply to your own identity provider. The third thing that we really want to stress is that you should use the correct a was two or open ID connect flow for the job. So Mark went through several different flows, look into those and determine what's best for your situation. Also encourage your developers to use a library and not to roll their own. Just like as Mark mentioned, how you wouldn't want them creating their own cryptographic algorithm, you don't want them to roll their own libraries. And so also in addition to that, moving away from ROPC, if at all possible, because again, the whole purpose of using Modern Auth, one of the big selling points is that you are not exposing that user's credentials. And so if you already have apps using ROPC, try to move over to a different flow. The fourth thing is to ensure least privilege is being followed by internal and ISV apps. So if you do end up running that PowerShell script to go see all of those permissions, or if you do check up on permissions in your environment, call upon your vendors to see if they can make an app be lesser permissioned or use the least privilege possible if you believe that app is over permissioned. Also your internal developers look into if they can use a lesser permission to do that particular action. Also look at current consented apps for those that are suspicious, the ones that have really generic names like O365 access or just mail. We've seen other ones with more hackery sounding names, but oftentimes these apps are trying to hide in plain sight. So you're gonna see a lot of really bland generic names on there. Within that also updating your instant response playbooks for this type of attack. And if you wanted to that YouTube link that I shared earlier to go watch that full bit of content on those app consent phishing attacks. And the very last thing is to go deeper on OAuth2 OpenID Connect, SAML, JSON web tokens. This is going to be the new NTLM Kerberos tickets. So if you are a subject matter expert on NTLM Kerberos, all of that, just know that the next wave of stuff that you're gonna need to know is OAuth2 OpenID Connect and some of the stuff that we've talked about today. So really set aside some time to go through those flows and make sure that you were able to accurately defend on those. And so as we close out, Mark, was there anything else that you wanted to share today? No, I think that's it. I mean, I just really can't stress that last one. Like you're gonna be seeing more apps that use these protocols, not less as you go forward. So this is really worth the time. I mean, we went very quickly through, I mean, this is some very complex topics that you may not have been exposed to. So we have quite a bit of time here, I think for us to be in the chat to answer questions. This is a very hard talk to do with no audience faces or anything like that. So we have no idea if you follow it. So we'll be in the chat here to answer any questions. But yeah, please make sure you spend some time understanding this stuff because you're gonna really want to do this. I know some of the best security people, they really understand NTLM, they really understand Kerberos, tickets, Kerberos and all that good stuff. This is gonna be the next wave of that stuff. So you really wanna make sure this is a good investment of your timing career to help protect your environment using this stuff. So with that, we have some time for Q and A. Bailey and I will be in the Discord. You can also reach us on Twitter. She's at Baileyversic and she's shooting up the Twitter followers chart. I'm at Mark Morrow. But feel free, if you watch us later, if you have any questions, feel free to ping us and we're happy to answer anything we can.