Microsoft 365 Community Identity platform, 17 Sep 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: How attackers can use applications for sustained persistence and how to find it - September 2021

Description

This month’s in-depth topic: Hiding in the Clouds: How attackers can use applications for sustained persistence and how to find it. In this session - What is application consent and why should you care (terms, user experience, applications and service principals, threats), Key permissions to look for (what permissions, what impact), How to investigate consent grants (discovery, IOCs, investigation), and Best practices to protect yourself from app consent attacks (policies, consents, risky OAuth apps, overprivileged apps, go-dos, resources). This session was delivered by Microsoft Program Managers Mark Morowczynski and Bailey Bercik. Recorded on September 16, 2021. Q&A last 10 minutes and in chat throughout call.

Stay connected:
• Twitter https://twitter.com/microsoft365dev and @azuread
• YouTube https://aka.ms/M365DevYouTube (Developer channel) and https://aka.ms/m365pnp/videos (Community channel)
• Blogs https://aka.ms/m365pnp/community/blog
• Recurrent Invite https://aka.ms/IDDevCommunityCalendar

A

Mark and I'm here with bailey and we are program managers in the identity division here at microsoft, so we work on active directory directory federation services and azure active directory and billy, and I work on a team that works with customers on their deployments of azure active directory and we take the learning and feedback from those deployments and we work it back into the product to make it easier and better for everybody else, so bailey and I actually spend most of our time, uh probably eight of our time talking more to the it pro side of the house.

A

So I know this is a developer focused call, so we're gonna talk about what is application consent and why you should be caring about this if you haven't started so already like, I said uh you guys are developers, so you probably have seen this if you've been spending some time in the space, but if not we'll get a good level set for everybody and we'll show why you really should be caring about this as there's some emerging attacks that are starting to use this, then we're going to cover some key permissions to look for and how to investigate these consent grants you may have in your environment and then bailey is going to talk about some best practices.

A

Everyone should be doing to protect yourself from these consent. Attacks and she's also going to be doing all the demos throughout the talk. So she has definitely has the hardest job between the two of us, but okay, let's let's, uh let's get into it here.

A

So what is application consent so if you've never actually heard of this there's a good chance. You have probably seen this um so if you think about it on your mobile phone, when you've added an application- and let's say the application is gonna- add some sort of uh funny filter or you know that kind of stuff. You know taking your picture and it's the application needs to ask for a set of permissions to be able to do that. So it's probably going to ask for the ability to access your camera.

A

It's probably going to ask for the ability to write to your photos, so you can save that funny picture you just took, and it's probably going to ask for the ability to read the context of your phone. That way, you can send that funny picture to your friends and family right from the application.

A

The azure id permission and consent model works in a very, very similar way, so we're going to have some sort of application that wants to access organizational data, and this organizational data is going to be accessed through some sort of resource apis and what the application can do with those apis are going to be determined based on the permissions which it can be granted through. The process here called application consent which can be done by either an administrator or an end user, and actually bailey will talk about that in the best practices section around.

A

What some of the configuration you can do around this, but to uh go down a little bit deeper here and kind of align ourselves with some of the oauth terminology. If you haven't heard this before that, application is actually called a client which can be a mobile web or you know running in some sort of service, it doesn't actually have to be a like a thick client type of application.

A

It can really be anything, and this is the thing that's going to be requesting access to the data on behalf of that user, and the thing that client is going to be trying to talk to is actually called an oauth spec is called the protected resource, so this is what's actually exposing that data or functionality to that client application. This is usually going to be a web api and the microsoft at any side.

A

This is going to be the microsoft graph and what the application has the ability to do is going to be determined based on that permissions. It's been granted to so you can see here. As an example, um you know ability to use what read a user's onedrive files do microsoft, graph, microsoft graph there is that protected resource read is the permission and the client wants to be able to read the files. So what does it actually look like? So this picture here on the right is what the end user experience looks like.

A

So we hear we have a contoso test application. uh It wants the ability to read uh the contacts, read the calendar and be able to read the user's profile and the end user. Here has the ability to accept this grant or actually deny this grant dean. I see you have a question about finding out consent to what has been consented to a long time ago, and if you just hang tight a little bit, we will cover exactly how you can go. Do that a little bit later in the talk? Okay.

A

So what actually from a consent terminology? Here we have a few different terms. We want to go over with you, so the first one is that consent prompt, which we just showed you. That's that actual dialog box and the act of saying yes to that consent. Prompt is called a consent, grant now there's two different ways to consent: there's end user consent and there's administrative consent. Administrative consent is usually done because of one or two reasons.

A

The first reason is when an admin consents to an application, they are consenting to it for all users in the organization. So the end users will no longer see that consent grant dialog box. So a really good scenario for this is um the native mail app on ios. So if an end user goes to connect their mail app to the uh their office, 365 mailbox, the application is going to ask for permissions to like read mail send mail things like that, and the user can say: yes, they can do a consent grant from that.

A

But as an organization we can say you know we're okay, with this application being used, so the admin can go in and consent to it for all users in the organization now the next user that goes to use that native mail app for the first time. They will not see that consent dialog box, because the admin has already consented to it. It will just work for them. So that's that first scenario. The second scenario is when an application is asking for high privilege operations.

A

So we don't let end users consent to things like being able to read and write to everything in the directory, or maybe you read and write to everyone's mailboxes or if the application is asking for application permissions. We don't let end users consent that, because those are very, very powerful permissions, so some permissions may require an admin to get involved to determine if it's, okay and their consent to it. Okay, so the thing I decided about here is admin application permissions and the other thing to know about here is delegated permissions.

A

These are the two different types of permissions and we want most of our applications if possible here, since it's a developer calls to use the delegated permissions, because the permissions the application has is what the user has and what the application has the ability to do. It doesn't actually give it more permissions than it already has, and this requires the user to be signed in and present to be able to make those calls.

A

These are the types of permissions that the non-administrative users can consent to or, like I said, the um if it's a higher level privilege permission, the admin can consent to it. But the key thing here is that effective permissions line, which, like I said, is the intersection of what the user can do and what the application can do.

A

So if, let's say the application has the ability or it asks for ability to read all mail and the user goes to use it, and it's that, on behalf of user calls here, it's not going to let that user read mail from every single person's mailbox, because that user doesn't have the ability to read everyone's mailbox. They can only use that application on their mailbox. So that's the effective permission is what the user has and what the application has you're, not giving the application more permissions.

A

Now this is frequently called scopes: oauth 2 permission grants or app plus user commissions, depending on what type of documentation you're looking at, but the second one here is application permissions, and this is very, very powerful because these applications can run with what, uh without a user being signed in or present, these always require admin consent and whatever permissions that admin consents to. That is what that application has the ability to do so if that application is asking for the ability to do directory, read, write all which is basically like a global admin.

A

Right like it can do whatever it wants in the directory and admin consents to it. That application can do that. So these are very, very powerful permissions. We want to make sure, as developers we're using delegated permissions whenever possible, but sometimes you do need to use application permissions. This requires an admin to consent to this now. This is sometimes also called roles, app roles or app only permissions.

A

So this is kind of a summary of what I just kind of talked about in the previous slides. We have our delegated permission model, which is what we want most of our developers to use. This is good for those mobile apps, the web apps, the single page apps. This requires a user can consent to this.

A

If your configuration is stuff that way or admin can do it for all users, most importantly requires users to be signed in and present, and it's accessing that data on behalf of the user and again that effective permission model there at the very bottom. This is a nice little graphic, for this is the combination of what the user has and what the application has. It doesn't grant the user more permissions when they're using the application application. Permissions is good for something that runs. You know without a user present runs as a service.

A

Only admins can consent to this, and whatever permissions that are consented to this application, that's exactly what that application has the ability to do so. These are very, very powerful with that. I think bailey has a demo lined up for us.

B

Yes, I do so. Let me pull this over and show you guys what this actually looks like in your environment, both from the perspective of an end user and also from the perspective of an admin. So for your end user. This is what that consent. Prompt, looks like, and so you may have been familiar with this. um You know, as mark was mentioning earlier on your cell phone or something as an end user typically, but if you have never, you know seen this screen before.

B

This is what it looks like inside of azure id and to show you the differences between the delegated and the application permissions. Here we have a delegated permission for signing in and reading the user's profile.

B

So you know that it's a delegated permission because it mentions that the signed in user must be present, which mark mentioned earlier denotes the difference between delegated and application permissions now for delegated permissions, you as an admin, can control whether end users can consent to those independently without your approval and I'll get into that toward the end near the best practices section. But the reason why, in this particular scenario for this particular tenant, the end user has to enter a justification to request that their admin approves.

B

It is because there's an application permission here, so this one right here the create chat and channel messages with anyone's identity any time stamp. This is something that does not require a signed and user present. So, as you can see right here, it says without a signed in user and as mark mentioned again with the effective permissions, because I, as a user, can't use anyone's identity, this would be the effective permissions. Overlapping would just be what I, as a user, I'm able to do now on the admin side.

B

This is what that exact same application looks like, and let me just put them side by side, so you can see the two differences here, but so as an admin, this is me logged in, as my admin account within the same tenant. This is for the exact same app would grow shipping info, and you can see that it looks a little bit different on this side, particularly or excuse me. I think that this was not when I pim elevated up well, no worries if the demo gods aren't playing nicely.

B

I have some slides to just show you exactly what this looks like here. So as an admin. This is what it should look like if I was able to properly pim elevate- and it wasn't just my normal account, but so you'll see that it'll say instead, permissions requested for review for your organization.

B

So, as mark mentioned earlier, when an admin consents to an app like this, it is on behalf of the entire tenant. So, as you can see right here, it mentions that no one else will be prompted to review these permissions uh because they will be granted for all users within your organization.

B

So it's an important distinction to be aware of, and now you know what those both look like and we'll dive into how you can set those up for particular apps and for particular users later in the session.

A

All right, uh quick question here uh from from daniel: they asked what constitutes a user being signed in this means. They have an active session that they're logged in that they're. You know they're, they have an access token and they're they're using it okay. So what actually happens when you click accept on that consent? Dialog box there's a couple of things here, so we have so a little bit of work to do on the azure id side.

A

This is a little more complicated than it probably should be, but there's two places where uh applications will live so the first one here is the app registrations, and this is the definition of the application itself. So this you can kind of think about this as it's kind of the back of the house. Configuration of the application so like is this application going to be a single tenant, app or a multi-tenant app? Is this application accessible from azure id users, or is this going to be accessible for azure users and people that have microsoft accounts?

A

So that's the stuff that is, you know your xbox, your outlook, outlook.com, that kind of stuff and for those who didn't see the announcement. Yesterday, we announced that you can remove your password from your microsoft account, so you should go. Do that. I did that uh yesterday and I think bailey did that for hers as well. Those are those those are those those types of accounts, so that's going to be in the definition of an app in enterprise apps.

A

That is where we're going to have the service principle, and this is the representation of the application in that tenant. So when you consent to an application, that's a multi-tenant app! You will see that in the enterprise app section, this is kind of the front of the house type of configuration. So this is where you'll set your conditional access policies as your it administrators in the environment, so just to kind of hammer this home.

A

If you have like so we have this timekeeping app here and bailey, and I um work there and we have that line of business app here. So we're going to have an app registration for the timekeeping app and we're also going to have a service principle for that timekeeping application. Then we sell it to another company and when they consent to it they will have a timekeeping app in their enterprise apps, but they will not see anything in the ability in their app registrations. It's only going to be in their enterprise app.

A

So if you go back and look at this in your tenant today, so any of those line of business apps you will be creating in your azure id tenant. You will see an app registration and a service principle in your enterprise apps, but for things like exchange online, you will not see anything in app registrations that lives in the microsoft tenant.

A

You only see that in the enterprise apps- and this is really really important to understand, because service principles is the security principle um and there are many many ways that service principles can be granted access and we just saw two of them right. We saw the app only permissions, as well as the delegated permission grants, but service principles can actually be assigned roles from a directory perspective, as well as an azure perspective.

A

So, just like an end user, a service principle can hold a role. A service principal can be an owner of a group, an application and other service principles, so they have very, very powerful permissions in this regard. They can make configuration changes to an application, and these service principles can also be added to azure key vault acl. So these are very, very powerful permissions. We want to make sure that we're keeping track of our service principles and we want to make sure we're managing these just like we would manage users all right now.

A

This is more for the it pros in the audience, but usually at this point there is somebody that is like grandpa simpson, and they didn't want to go to the cloud at all, and now they realize that they have a bunch of mystery applications in their tenant and they do not know where they came from. There's a bunch of assignments to these applications because people were able to consent to it and they don't understand that and they don't understand what permissions these applications have, what power it has in their environment.

A

They feel like they kind of lost control of their uh infrastructure and environment and um they're, not totally wrong. There's some good stuff in here that, if you didn't know about this- and you didn't know what to do, it can kind of feel like you've kind of lost control, but we actually have some really good guidance on how to kind of maybe regain that if you weren't paying attention to this from the beginning and things you should do from a best practice perspective. But the other thing is this: isn't like a unique cloud.

A

App specific thing like you could ask these same questions about your on-prem applications and people standing up applications to talk to your on-prem, active directory and, and things like that. So this isn't like a cloud problem. That's actually just appeared.

A

You probably had this problem along, but because everything is in a central place, you can actually get your arms around this pretty easily and you really really want to because as we're starting to see some phishing and malware campaigns based on that- and I see the chats going pretty quickly- I'm sorry I can't keep up when I when bailey goes to the demos.

A

I will come through and try to answer some of these things for everybody here, but the traditional malware campaign is, is you know, we've seen it for a long time right is we're trying to get a user to run. Some sort of you know attachment some sort of macro here, and you know before it's like invoice attached. You know open it up and then they kind of pivoted to a covid theme thing right.

A

So we've seen this so it's the same type of stuff where it's they want you to run an application that does the the dropper on the the device it goes and does the command and control the whole nine yards. This is not a new thing that people have been doing for some time, but the new thing here is actually people are moving to a consent based phishing attack and um a lot of people haven't started to see this yet as well as not really prepared for it.

A

But here you can see a very similar type of style where we want you to see this kova 19 bonus uh documentation. You can open up, or here we see that this application is called office, 365 access that icon looks kind of familiar, but it's a little older, but maybe that's okay, and if you look through those permissions, the application is asking here it wants to read our contacts. Read our profile read our mail. It wants to be able to read onenote notebooks, that's kind of suspicious.

A

It wants to be able to read and write to your mailbox settings, and the key thing here is when a user consents to this, and this is a delegated permission. So it's what the user has access to and what the application has access to they're able to like now suck all that mail out, because they, the user, can read their own mail.

A

You know, and the real scary part here is when we start to do uh configuration changes to the mailbox settings so because a user can go add a forwarding rule to their mailbox and the user can send this application. The application also has the ability to you know: ask for that permissions. The user has those permissions, and now the application can now add. You know persistence mechanisms to go ahead and add that into the mailbox. So this is a really really scary thing.

A

If we didn't know about this, and people are starting to move from those typical malware where we're having the thing we'll run the macro in the workstation and does the c2s channel to actually doing permissions that delegate permissions model where there is nothing on the device from a a malware perspective, because it's all some sort of cloud application. So this is something we're starting to see um happening to some customers. We want to make sure people are aware of this from a security perspective.

A

Okay, so now that you understand this, what are some of those permissions? We should look for. I think this is some of the stuff that dean was asking about. So the first thing here is any permissions that have wide-ranging permissions. um Your mail star, uh you know directory, read, write all anything like that. We want to make sure we understand what the application is asking for and why it needs to be able to do those just because an application has these permissions does not make it malicious.

A

It may make it over privileged, but it doesn't mean it's bad, okay, so as administrators and developers in the uh in order, we want to make sure we're using lease privilege wherever possible, and we want to make sure when any time an application is looking for these types of permissions. We understand why it needs this. Maybe this is some sort of e-discovery app right and you discover app needs to go, read and read a lot of data across a lot of different services.

A

It's probably going to have a lot of permissions that doesn't make it bad. It just means it has a lot of permission, so we want to make sure we understand any of these broad scopes or permissions like directory. Read, write all or anything like that now. The other thing to think about here are low impact permissions from an organizational perspective so stuff, like user.read email profile.

A

These are just kind of the basic permissions and you need to understand what you're granting access to these applications to do, and are you, okay with that as an organization again, this doesn't make it back so just to give you an example here these are some load permissions. We had a customer. Some application wanted to be able to do some of this stuff. Like basically read the gal. Okay, read the gal and the end user has the ability to do this.

A

They consented to the application and they went on their merry way and several months later, their executive was browsing some site where this application gets used, and they were very very surprised to see that their first name last name email and their internal gal picture was on this website and their first reaction was you've been hacked and they hadn't been hacked right. The end users have the ability to read the gal like they can do that and they granted this the permission. Users end users had the ability to consent applications.

A

The application asked for some low permissions, they consented to it. They went on their way and it did it so they didn't actually get broken into or hacked or anything they just let their end. Users do this. That may or may not be right for you and your organization, and this is the stuff to kind of think about and have a discussion about of what we want. People do.

A

We want end users to consent to applications, and if so, what permissions are they okay with and are we okay with as an organization, I have some customers. The answer to this is no, nobody can consent to anything. Everything needs to be reviewed by an admin of some kind to look through and look through the application, which is, you know, good from a security perspective, but you know they have a very long backlog and it's very slow to get through other companies. I work with their answer.

A

Is let people consent we don't want to be in the way of the business if they want to use that boomerang app that, like resend your mail back to you at like the end of the day or whatever like let them let them like. Why are we gonna hold up the business? Let them do this, so it really is up to you to decide as an organization if you want people to build consensus applications.

A

So just my point here is just because they're low impact doesn't mean they're, like you know, you could run that scenario where someone consented to something and your debt data was accessed and you may not have wanted to so. This is something you want to think about from an administrative perspective.

B

All right, and since earlier I had a little snafu with my um with pim elevating up, I'm just going to fall back to the slide. So I'm sorry, I didn't make the proper sacrifices to the demo gods this morning, but I'm going to keep it moving for y'all to make sure that you're still getting the content you need. So since my admin didn't consent to that application that I showed you previously.

B

I do want to show you what this might look like in your tenant and what an over permissioned app may look like, and so, for example, here this is an app that is malicious because I believe mark mentioned earlier that sometimes these will try to hide in plain sight. So, as you can see, woodgrove is the name of the fictitious tenant fictitious company that my users work at, and this is a woodgrove app with three o's in it.

B

Trying to blend in and admin must have consented this, and so I'm gonna show you what that app may be able to do in your environment, and so particularly, I think that somebody, I was responding a little bit in the chat as we went about, seeing which ones are application versus delegated permissions, and it's a lot easier to see within the azure portal, because it'll be clearly laid out, and you can see that this column here, if I were able to scroll up on the screenshot it'll say granted.

B

Admin consent, yes or no, and all of that so right here. I really want to focus on user read, write all because that's something that is very powerful for an application to do, and I think a lot of folks don't fully understand that it can literally do anything that falls within the scope of those permissions.

B

So I want to pick on lisa again who's, my user, that I was showing you toward the beginning on that application, consent screen, and so I'm just on her my account page where you can see her name, her job title, email address and all that jazz and so for the purposes of this, I just want to show y'all in microsoft graph how this might work, but also toward the end, there's a sample malicious app that if you want to go scare, some people with it and you're able to go play around with that.

B

But since this is easier to showcase, I figured we would do it here. So within graph explorer, I'm able to go and get some information about lisa, and so, as you can see here, I have her display name her. You know job title all of that stuff. That was featured prominently on her, my account page and so right.

B

Here I want to change up her display name and I'm going to pick a very silly name for her to have, but just to demonstrate that you know you could really name her whatever you want to name her. It could be, you know, satya nadella, any sort of uh figure within your organization or public figure that the name could be changed too.

B

So when I go through and I actually make that change, it'll showcase in graph explorer, but more importantly, it'll also show on her my account page and everywhere else where that data is being used, and so this is a little bit of a silly example, but I really want to drive home what that could look like if you do have an app that is consented to, and this of course was a very high level permission and mark mentioned earlier- that some of those lower level permissions could also be nefarious, and just because an app has user read write all doesn't necessarily mean that it's bad.

B

It's just something that as a developer, you may want to be thinking about you know. Do I really need that permission in order to achieve the task that this app is trying to do, and so with that, I think mark is going to walk you through how to investigate those illicit consent, grants and what they may look like.

A

Yeah, we had a lot of comments in the chat about how do I uh look for this stuff, so I think we've sufficiently scared everybody, uh even before we got to your your demo, there bailey's okay. So how do I look for this stuff? There's a couple places you can look.

A

The first place is, if you just have a handful of apps in the office 365 portal, you can look in the security and compliance center audit logs. If you see anything that says, is admin consent set to true. This means somebody with either global admin uh or cloud app admin or app. Admin has granted that access to um probably a large set of data. So you want to probably start with that, but you can look at that in office. 365., the other place to see it.

A

I saw some people mention this in the chat is in the azure id portal as well. So in the actual enterprise apps section, you can look through permissions. You can also see this in your auto logs and make sure you're sending your audit logs off to some sort of uh seam of some kind. um This only works, if you probably have a handful of apps for most of the customers that we work with, they have a lot of apps, so you need some sort of way to actually script this.

A

So if you go to aka dot, ms azure ad permissions, we have a powershell script that will help enumerate all this pull out all the stuff and show you what uh what applications have what permissions and who's consented to? What? So, that's a really nice way to start with that, and then, lastly, if you're into more of the like app gallery like mcads like if you're in these deeply like in the tunneling of the apps, all kind of stuff, mcads will also show you this. The casb type of stuff is what I was thinking of.

A

So mcas will show you this. This is a different uh different license than what you have in azure id just to kind of call that up all right. So, let's take a look at what we should start doing once we get into there. So what should you start with? The first thing is you want to start with? We have a tab in this output, and bailey will show you this here is the high risk apps, as well as user, assign count account tab, so any application that you don't recognize. That's like not a microsoft application.

A

With these very high permissions. You probably want to start with to make sure we understand specifically what is that application and then, if you can figure out who consented to it, because that means an admin has consensus to this application and it's very very powerful. So we want to probably start with that and and the user assigned count all users means all users can access this, because an admin can send it to it. So we want to probably start with that.

A

The second place to look for, then, is uh look at the high risk user tab and do a quick scan to see if there's anyone that has access to that sensitive info so stuff that you know. If somebody called you and said this account is compromised and your stomach just kind of drops and you'd be like. Oh, no, that's bad! Like look for those people right, so anyone that is your executives. Anyone that's in finance people that maybe have access to sensitive information like you know, mergers and acquisitions, and things like that.

A

Look for those users see what applications they've consented to or what applications they have. um That's another good place to start and then also then start looking at the actual delegated permissions. You know, looking for those read write all permissions, um those are ones again not making. It doesn't mean that they're bad, it just means they have a lot of privilege. So we want to make sure we look at those and we understand those.

B

And so let me show you what that looks like in that output. So if you were to run that powershell script, this is what that looks like, and here's that high risk apps tab that mark mentioned earlier, but this actual output has a lot more than that, so you're actually able to see those permissions by user- and these are you know some folks at microsoft that play around with that demo tenant of woodgrove.

B

We have the creator of the wood group, who has probably the most listed here and also those high risk users, so there I am one of those higher risk users uh within that demo, tenant and so you're really able to play around with a lot of the same data that you would get via other means as well. But if you are someone who's really into pivot tables, this I've already cleaned up a little bit and made it a little bit prettier, but you're actually able to go, buy those specific permissions.

B

So you could see for group read write all all of the different apps that have been granted that permission. Also, you could see permissions by risk rating. So, whether or not those are lower versus higher permissions and where they come from, and then also all of the raw data is here as well.

B

If you know you would like to display this or visualize it better for the purposes of being in your organization also, since this is all on github- and this is a developer audience if you guys would like to make some changes to that script, or if there are some things that you would like to see improved by all means, we would love for it to be collaborative um and to improve what we have going here.

A

All right, you've taken a look at this and you're looking through applications.

A

What else should you look for here so, as billy called out here, apps trying to blend in so she had that app that had too many o's in it things misspelled. This is they're. The typical types of you know, spam type of stuff. That's trying to masquerade so apps, trying to blend in um things where your things are suspicious. You know such as they're consenting to applications and weird hours. People are consenting to stuff that you should normally consent to.

A

This is just the typical spam type of stuff, so these are some of those indicators that compromise to look for um looking away from the other daily activities. All this is just kind of like the red, traditional blue team type of like what should you look for from like an attack perspective now, a really interesting thing here is the date and time so I would talk about. This is sustained persistence.

A

So, let's say an attacker compromises, a user account they get their password. They didn't have mfa on they log in as that user, and they go in then and start consenting to applications, and then that user changes their password. You guys do ir that's good. Those applications are still there and they still have access.

A

So um this is a good thing to add. If you know an account has been compromised, look right around that date and time to see if they've consented to other applications around that time. So that's kind of a good ioc to look for, but okay. How should you investigate this? So this is a tip from our dart team, our dart team. If you've never heard of our dart team, they um you're in good company. That's good uh dart team is the folks that microsoft they come through incident response and some really gnarly situations.

A

So um one of the things they've suggested here is when you're trying to determine the scope of an attack if you're able to scope it down to the specific application that the application had was consented to. So, if you know it's just exchange, or just one drive uh scope that down that actually makes the search run much much faster. Okay, so an attack is confirmed. You want to start your incident response process, so the first question everyone here should be asking is: does our incident response process cover this scenario and for a lot of customers?

A

The answer is no, we didn't even know this was a thing. We don't even know what to do about this and that's actually. Okay, um but if you're gonna go to ak dot, ms slash ir playbooks, we have some incident response playbooks for this exact scenario as well as some other stuff from password spray, and things like that. Take a look at that and start pulling these in and start thinking about this.

A

um What you want to do about this scenario and start working it into your stuff, so you uh don't reinvent the wheel, use what we've already given you then to stop and remediate disable the service principle. You can revoke the consent, grant revoke any roles and disable sign in for that account. But the good thing here at the very end I want to call out is look for those persistence mechanisms. That example, I showed you where the application had the ability to make mailbox changes.

A

The user has the ability and the app has the ability it can do that. So we've seen that where an application creates those mail forwarding rules, and then you know, if you reset the account like I talked about, but you didn't clean up this application, it can go in there and keep updating those mail forwarding rules. So you want to look for those persistent mechanisms. We call this out in that ir playbook there, um but take a look at that.

B

All right, and so now I know that we've had a lot of questions in the chat about some best practices and some things that you all could be doing. So I think that this is probably going to be the most pertinent section for some of those, and then um I've tried to answer some of the questions as we've gone, but we can also I'll.

A

Take a look to try to answer while you're going yeah.

B

Or thank you mark, and so first to get into some steps that you can do to protect your organization. So usually this is, for you know more of that. It pro side, but as a developer, it's important to know that this exists as well, and so what we typically recommend folks do is that there are three different options for user consent.

B

So I saw some questions in the chat about you know: why can a user consent to certain things or how can I you know, restrict that, and so there are three different options that we allow within the portal. So one um where you cannot allow users to consent, which mark mentioned that there's a customer that just has it where nope lock it down. That's the way we want it or you can have it where users can consent to any app that has those delegated permissions.

B

So if you also are in an organization where anything that obstructs business you know is bad, so we just want for everyone to be able to do their jobs. That's an option that's available as well, or we typically recommend the goldilocks option in the middle. So allowing users to consent to apps from verified publishers and when I say, verified publisher, those are apps that are verified through our microsoft partner network, and so we know that those apps are coming from uh the creators that they say they are coming from.

B

Something else that you can do for this is to use mcas. So within mcas you can automatically revoke an app or a specific user from an app when that risk is detected there.

B

If that's available to you within your organization, another step that you could do and so for the it pros that you work with you can this is enabled by default, but just because it's enabled by default doesn't mean that somebody may have turned it off within your environment, but it's called risk-based step-up consent and essentially what it is is that when a risky consent request is detected, it'll be stepped up, so it'll require that admin approval instead of just allowing that user to approve, even if within on the previous slide, where I showed you they are allowed to do so.

B

So the warning will be shown to users and admins, but again only that admin can actually grant it and then audit events are going to be logged. So I believe somebody in the chat also asked about hey. You know is this able to be viewed? Who consented to what at what time? And yes that is available, so you can go back and look at all of that information. If something were to happen, something else you can do is detect those risky oauth apps.

B

So earlier I showed what that script looks like when you run it, but here again is the ak dot. Ms link for that, where you can audit those apps and view those consented permissions. So if some of these options below like azure, monitor and mcas are not available to you, I do know of some customers who set up like a recurring calendar event, so that they go on ahead and run this script regularly.

B

So if that's something that would pertain to your organization, that's a good option as well, but something even better is to use azure monitor. So, with azure monitor, you can set alerts to automatically notify you whenever an app meets those certain criteria.

B

So, for example, if an app has those very high permissions or if an app was authorized by over 50 users, uh something to stay on your radar and to be in the know about something else is to use something. A hunting solution like mcas, and so with this you'll be able to see permissions uh higher level. Permissions be able to see if apps are also authorized by those external users, and it just gives you some additional functionality there.

B

Now. This is probably the most relevant slide to all of you, since this is a developer focused call. So I want to spend a little bit more time on this one and so you're, probably or to back up a little bit. We've all been there where we're trying to get something to run, and we just use the highest level permission possible because we just want it to work.

B

So we've been trying to make it easier for folks to determine whether apps are over permissioned or if there is a lower level permission you could be using, and so since bit bill.

B

2019 we've actually increased the number of permissions that we have by over 60 and with that we have over 20 new identity and access permissions, and I believe d in the chat was the one asking about teams permissions and so with that we have over 25 new teams permissions available and specifically, if you are looking to um do some work with enabling apps to access only the teams that they need.

B

uh We have an ak, ms link for you there as well at rsc hyphen teams, which will go into some more detail about that, and so also it's important to know that you know I'm sure that all of you, as developers, know this already, but just to really drive it home to only ask for what is absolutely necessary and those directory star. Permissions are going to be virtually never least privileged in any use case, but to make it a little bit easier on y'all. We do have two really great resources here.

B

One is our graph best practices. If you go to that aka, ms link, we have some great information for you there on best practices, and then we also have our identity platform checklist as well, but I think the coolest thing for you all that I really want to draw your attention to are our free workshops both for it pros and developers, and so kyle marsh on. Our team is absolutely incredible and he hosts these free workshops.

B

I believe once a month, but that link the upcoming id lob. It pro a little bit of a word salad there, but he regularly updates, I believe, monthly, with different workshops that you can attend completely for free, and so you could just register for it and encourage other folks within your organization to register, for it there's one: that's targeted more developers where he actually ties in and goes through the code and then there's one also more so for it pros.

B

So if you have some it pros that you work with or that you know of who may be interested as well. Please share this with them and if, for whatever reason, the time zones or um the dates that kyle is hosting these don't line up for you, we also have a lot of that guidance captured in our youtube series at aka.mslash identity, developer series, um where you'll be able to watch and recap some of those clips.

B

You know on your own time, so I think that for this audience this is probably you know one of the most key slides that I can share with you with all of these resources here, but whether you're on the it pro side or developer side- or you know just as an end user.

B

Something important to note is that if you see something say something so if an app looks suspicious and if you're either you know the end user consenting to it or the admin seeing it you've reported to microsoft that we can do something about it, because this will be sent on to some teams internally, and we can, you know, make some changes that, hopefully other folks don't see the same app in the future.

B

Now, to sum everything up with some go dudes, because I know that we've covered a lot today, so first off, something that you can take home with.

B

You is that you can inventory those applications and their permissions either using the portal or some of the tools we mentioned earlier or that powershell script if you're looking for a cheaper option there as well, if it's available to you automating the threat response by implementing risk-based step-up consent, which should be enabled by default, but if it has been flipped off, you talk to your admins about getting it flipped on and creating some mcas policies.

B

If that is something you know within your licensing structure, something else that you could do is to educate your organization on consent tactics, and so I know that I showed you a very cheap version of how you can use an over permissioned app to do some nefarious things, but mark actually has a really great example on his github, a great sample, app that you can use to scare. Some people really drive this point home as well.

B

Something else you could do is that typically we're talking to an I.t pro crowd, where we would say, educate your developers, but since this is a crowd of developers, I would really encourage you to check out these three links, especially the one at the bottom, the upcoming id lob.

B

It pro link for those free workshops, uh they're a fantastic resource, and I highly recommend you check them out and something else that we have on the secops side is that we recently published a security and operations guide that doesn't just cover application consent, but it covers many other things within azure id from privileged.

C

B

Management to governance and so much more mark, and I did write the application management section of it. So it covers a lot of the things that we've shown you today, but it also has so much more so if you're interested in checking that out, we recommend that you follow that link and also share it with other folks in your organization and before we wrap up.

B

I do want to leave you with some other resources that didn't necessarily get worked into the deck today, but we have some steps for securing your identity infrastructure, also, some more information about that azure, ad consent framework, um some more information about detecting and remediating illicit consent, grants and then finally, some information on managing consent to application and evaluating those consent, requests, and so with that we'd like to thank you for your time and turn it back over to stephen in case he has anything to close it out with, but we will be answering some questions as well.

B

If you have them.

D

Yeah go ahead and ask your questions. If you'd like I just posted on the chat window, a place where you'll be able to find the recording, we're also going to post a link to a copy of the powerpoint from today's call.

B

And I'm catching up on the chat, but does anybody have a question? I would like to come off mute to ask it.

E

I have a good question.

B

E

Yeah, so I have wcv service uh that that was a basic authentication, but the thing is we have to authenticate and the iwc service with azure ad. So how can we do that? Maybe.

A

I actually don't know because we're not on the developer team, so I think that's a good question to maybe so we a couple slides back. We talked about the developer, training stuff, I would say, attend that and maybe ask that question there. I actually don't know I mean I'm guessing. There's it's gonna be based on whatever oauth flow and library you're gonna use, but I I I don't think bailly and I are the right people to answer this question. I.

E

Mean here's I looked into like.net core base and then asp.net based like those those are dotnet frameworks. We can actually authenticate with, as we really do with msl library, but with wc service uh you're, not finding any luck actually doing that. So there's I'm really looking for it.

E

A

Is not we and I are not the right people to help you with that? Okay,.

F

So I have not a question but more more a comment with all this and I I put something into chat regarding this. um It was a picture of kind of of a workflow that we developed for this, that that may be useful for others here with graph. You can actually pull all your azure applications over graph and we we take like snapshots of those from day to day, and we monitor for changes right.

F

So we'll you know it's it's actually more frequent than day to day it's like every half hour, we'll look at all the azure applications, and then we compare them to what everything we've seen before and when we detect a new application.

F

We extract all the users that it are assigned to it and all the permissions that are requested.

F

We take the the app url out, which is and and obviously the name I mean we send- that to all the office 365 admins for review right so like we, let the users have the rights, but we don't have um anything configured right now to not allow them to to approve an app, but the only reason we we have that wide open right now is because we have that automation in place, and I think that for some organizations like doing that over graph is out of reach, and I think that this has been a critical thing for a while, like you said that we had a russian mail app, that's where this maybe a couple years ago, and that's kind of where this all started for us, where we realized that this was a problem pretty early on.

F

But I think that now that this is becoming a more commonplace thing and there's there's other token related attacks that are going on, and things like that, like. I think that outside of azure, monitor like there should be some type of base reporting, like the other security alerts that microsoft sends to admins.

F

I think that when a new app is added to a tenant, even if it's a first party app like, I think that those notifications should really be sent to everybody sent to the office 365 admins, so that everyone's aware um and not be tied to like e5 subscriptions or other products. If that makes sense, so you want more.

A

Alerting for app consent, permissions yeah.

F

I just don't think it's realistic, like the powershell script is great and for especially for organizations that don't have developers or engineers right it's great.

F

But how do you as for some organizations who are just you know, have basic administrators that don't really do how do they take that and because it's still very manual we're taking something: that's very critical for organization security at that point and making it a very manual thing that that those people are going to have to remember to run and, like you know, to really be aggressive, which you kind of need to be you'd want to run that you know multiple times a day and it's just like a lot of overhead.

F

I feel like that for something so critical that really should be kind of automated yeah. That makes sense.

B

Well, I think that if you use something like azure monitor you know or mcas, then you would have that functionality, but if you're you know not able to use those, then that script would be another more budget-friendly option mark. I don't know if you have anything else to add there yeah.

A

So mks is kind of that to kind of help with some of that I just also pasted in a chat some of the app governance stuff around that I think, is kind of where you're getting at some of this, but it is part of mcas today.

G

F

The only other comment I'll say really quick is you talked about first party applications, um one of the ways that we deal with these third-party applications is we do one of two things we either completely disable sign in to them.

F

Sometimes we completely delete them, but more often than not, we actually keep them um and we just disable sign in to them, because if you delete it, another user can come along and just add it right back right. So you don't necessarily want to remove it. You want to kind of keep it in your tenant, but disable signing against it. And sometimes you know if it's an app that only a certain set of users are going to use.

F

Then we leave it enabled obviously, but we only there's a user assignment required toggle right, so you'll only allow certain users to actually authenticate with that application, but what I've noticed is that user assignment required the microsoft first party applications don't include that as a toggle.

F

So like something like the azure portal and I'll just put like a quick, a quick note into chat, a quick picture into chat, um the azure portal itself doesn't actually have that option and none of the microsoft first party ones do, and I know that there's other options where you can turn off access to this. Just an example with azure portal, like you, can turn off access to azure portal in your azure attendance settings.

F

But you can't do it in a very granular way, like you can with third-party apps and only allow certain people to access the microsoft first party apps and that's another oversight. I feel that would be nice to have changed at some point. Does that make sense see yeah? Couldn't you use conditional access for that?

F

Well, in our kind of, but in our scenario we have so the way that it. I don't want to derail this and stop other people from asking questions.

F

So I will probably not dive into that, but it would just be nice to be able to do it at the app level in a simple way like you can for third party, because other, if you have an an azure role on your account that tenant setting still allows you access to the azure portal, when there are people that have azure roles, that we don't want, having access to the azure portal. So anyway, that's where that's coming from so all right.

G

Will there be more resource-based consent, other than teams and sharepoint in the future? I think they're.

A

Working on stuff around sharepoint and onedrive, but I I'm not sure again.

C

Really not the right people to ask that, but we could take that back to some people if there are no other questions.

D

Or feedback, I just want to thank everyone for joining today's call. I hope it was really informative and I want to thank mark and bailey for participating today and thank you all for being so engaged looking forward to seeing you in the next call. Next month october, 21st bye, everyone.