Hiding In The Clouds

all right uh welcome to hiding in the clouds how attackers can use applications for sustained persistence and how to find it i'm mark and i'm here with carissa and we are program managers in the identity division at microsoft so we work on active directory our adfs as well as azure active directory and we work on a team that helps customers deploy azure active directory and we take those learnings and feedbacks from those deployments we work it back into the product to make it easier and better for everybody else so for this talk um of course you know the next slide is um i'm talking about this thing called application consent and application permissions and things like that which

some people may not be aware of so first we want to make sure you understand what do we mean by application consent and really why you should care about this if you haven't started looking at this already then we're going to talk about some key permissions you should be looking for in your environment as well as how to go investigate these consent grants in your environment and then lastly we're going to cover some best practices you can do to protect yourself from these application consent type of attacks so if you haven't started looking at your applications and your data access you really need to so on average there's about 140 apps in an organization but this number can

can vary greatly depending on the size of your organization chris and i work with some very large and complex customers and they have thousands and thousands of applications so 140 is kind of an average number but it really you'll know your environment better than anybody else this could be less than this or much much larger than this and 87 of users can consent to applications today and the act of consenting to an application isn't bad in itself but as administrators here and defenders here at b-side charlotte we want to make sure that we understand what we're allowing people to do and that we're okay with it from an administrative side of the house because we want people to be able to do

what they need to do to do their job but we also want to make sure we're not putting the organization at risk so the act of consent is not bad itself and we're going to get into some of this but we want to make sure we're doing it in a way that we're okay with and then also 80 of employees are using non-approved work apps this is the shadow it type of stuff that's been around for a little bit again this doesn't mean it's malicious maybe for example that the cloud storage provider that we want our business to use is is either one drive or dropbox and then this other business unit is using is using box and

they're not doing it because they're bad they're just using it because that's what they prefer to use or they didn't know they should be using something else so we want to make sure that we have um some guardrails around this type of stuff and we're letting people use those approved apps for work so from an application consent perspective um if you haven't heard of it or looked into an azure id that's okay we're gonna cover a bunch of that here today but you probably have seen this in your day-to-day life as on your cell phone so let's say you install some new application and that application lets you put some funny faces and things like that

on pictures so it's gonna ask for your access to your camera it's going to ask for access to your photos and it's also going to ask for access to your contacts because it wants to be able to send those photos that you just made directly from the app to your friends and family and you as the owner of that phone can make a choice to say i'm okay with it having access to this or i'm not the application azure d permissions model works in a very very similar way so there's going to be applications that need access to organizational data that organizational data is going to be accessed through these resource apis and in our case here in azure idea it's

going to usually be going through microsoft graph and that permission that are going to be granted are going to come through this thing called an application consent and end users can consent to some of these things or an admin can consent to and we'll kind of cover the differences of that here in a little bit so to kind of align that previous slide to some of the openid connect protocols like more of an enterprise type of spec we have a few different pieces we have that client application which can be a mobile app it can be a web app or it can be a something that runs in the background and this is what's going to be

requesting access to data on behalf of that user then we have that resource application which is usually a web api in our case like i said microsoft graph that's going to expose this data or functionality to that client application and then we have those permissions this is what that client application is going to be performing on that data that's owned by some sort of resource application this picture that you see right here is that application consent dialog box so here we can see that this application is a contoso test app it's trying to read user and share contacts share calendars and sign in to read that user profile and as an end user you can click accept i can consent to

this application or as an admin you can do some other things as well but uh chris is going to show you a demo of that here in a little bit but this is the application consent dialog box if you haven't seen it if you haven't seen it that's okay chris is going to show you a demo of it here in a little bit so in terms of consent uh terminology that consent prompt that dialog box that we just showed you is that consent uh prompt and it's asking for those types of permissions for the user to consent to that and the act of saying yes is a consent grant now here's where we go a little bit different from that

phone example here is with a concept of called admin consent or administrative consent which is where an applica an administrator is going to consent to that application there's a few reasons why you would need to do that the first reason is maybe this application is asking for a lot of privileges and we're going to cover permissions and things like that here in a little bit but let's say this application is a application that's used to enhance your search in sharepoint or in exchange so it's going to ask for the ability to read and read all mailboxes in the organization or read all sharepoint sites in the organization end users do not have the ability and we

don't want them to have that ability to can say that that is okay for my organization at that point for these high permission privileges we need to get an admin involved to say we understand what this application is doing and we are okay with it so they're going to consent to that so it's we need someone that has more privileges to say that this high privileged operation is okay for our environment the second example is that when an admin consents to an application they're consenting to the application for all of the users in the organization so a good example of this is the the native mail client in ios when you go to connect it to your

mailbox in exchange online you'll get that same type of consent dialog box up it will show you this is made by apple the app is verified we're going to cover some of that here in a little bit and then user can say yes i'm okay with this they click okay and the application works that's fine but now as an organization we can say you know what we're okay with this application being used um so i'm gonna go in there as an admin and consent to it so all of my users in my directory can now use this application so the next person that goes to sign in with the native mail client ios they will not

get that consent dialog box because an admin has consented to it for the entire organization so there's different types of permissions for applications that we're consenting to the two types here are delegated permissions and application permissions delegated permissions is what we want most of our applications to be using this requires the user to be signed in and present for that application to make those calls on behalf of the user these are the types of permissions that i just talked about that the end user can consent to as well as if an admin consents to it because it has higher privileges or it's we're going to consent to it to for all users in the organization that's the

delegated permissions now the effective permissions of those delegated permissions is where people tend to get a little bit tripped up if they don't understand this correctly so let's say that application is asking for the ability to do um you know read all mailboxes or read all sharepoint sites and we've consented to that as an admin but the user has the ability to only look at their mailbox or their sharepoint sites when they use that application the effective permissions is the intersection of that user's underlying permissions and the permissions that the application has been granted to you so say that another way we're not elevating those end users permissions they don't get to see all the mailboxes now or all the sharepoint

sites because they don't have that ability themselves so it's the intersection of what that user has access to do and what the application has access to do now this is sometimes referred to as scopes oauth2 permission grants or app plus user permissions the second type of permissions here is application permissions and these are very very powerful permissions because these can run these applications can run without the user being signed in or present at all and whatever permissions that we've consented to that an admin has to consent to for application permissions that application has the ability to do so if an application is asking for the ability to read and write to everyone's mailbox or do directory read write all

and an admin consents to it that application has those permissions and has the ability to do those types of things and we're going to show you a demo of that later just to kind of hopefully really hammer that home that this could be a very very privileged operation if we're not careful to what we're allowing people our applications to do they may have some adverse effects in our environment now this is sometimes called roles app roles or app only permissions okay so i know this has been a lot so the next slide here is just kind of giving you a hopefully a nice recap for you so delegated permissions is what we want applications to be using this is going

to be those mobile apps those web apps or those spa apps which are you know single page applications end users can consent to it an administrator can consent to it for all users in their organization and the effective permissions model is the intersection between what the application has the ability to do and what the end user has the ability to do but there's nothing in there we're not elevating the user's permissions to do something they didn't already have access to do the application permission model those run without a user being signed in at all so these like your service or daemon accounts only it administrators can grant access to applications to do this we want to be very very careful

about that and whatever permissions you grant to an application that application has the ability to do so we want to make sure we're very very careful and clear about what those applications has the ability to do in our environment and with that i think chris is going to do a demo here of the application consent experience yes all right so thanks mark so i'm gonna do a demo experience as if i am a user and an admin so you can see what that permission experience is and so first i'm going to be signing in as lisa smith into um the wood grove tenant so i sign in and it's accessing the wood grove shipping application and there are some

permissions that i don't have um the rights to yet so it's saying that approval is required and you can see in this permission box that there's you can uh look into the type of permissions there are some that are specific for users there's some that are specific for the applications and i would need to enter a justification of why i want to request this application and then i would just hit request approval and this will be sent off to the admin now if i were actually signed in as an admin there's a slightly different experience as mark was mentioning so now i'm signed into the woodgrove tenant as an admin and go to the link of that same

woodgrove shipping application and now here you can see that permission is requested to review for your organization i see that is an unverified application i'm looking at the permissions that it's asking to do and then in the end i can either accept or cancel it and if i accept it i'm going to be accepting it on behalf of the entire organization and then no longer will any of the users receive that pop-up because now um it's registered and good to go so with that i'm going to hand it back to okay so what actually happens under the covers when we click uh yes consent to this thing so in azure id there's two areas if you haven't looked

at it yet there's the app registrations and there's the enterprise apps the app registrations is the definition of the application so the way to think about this is this is kind of the back of the back of the house type of configuration of that application so is this application going to be a single tenant app only used by your company is this application going to be a multi-tenant app that can be used by multiple different companies is it going to be only for azure ad users is going to be for also msa users this is all the type of configuration that you'll do you'll set in the app registrations the enterprise apps has what's called a

service principle and we'll talk about that here in the next slide but this is very very important because this is the representation of that application this is you can think about this as kind of the the front of the house this is do you have to do mfa to actually get into this application this is who has access to that application that's all configured there in the enterprise apps so to make this clear here an example let's say i'm tenant one and we make a time keeping application chris and i make that and we sell this to other companies so in our tenant there will be an app registration for that timekeeping application but we

also use that application as a company so we will have that as a service principle in the enterprise apps and when we sell this application to other companies when they go to add it to their azure id tenant what they will see is a service principal in their tenant they will not see the app registration they will only see a service principle so to make this real if you check your tenant and you look for exchange online or sharepoint or salesforce or workday or any of those types of applications what you will see is a service principle in enterprise apps you will not see an app registration but if you are moving like a line of business

application that's only going to be be used by your company and you're moving that up there you're going to see a app registration for it as well as that service principle the service principle here is really really important so the service principle is really important because this is also the security principle for the application and this can have be granted access to things as you can see here so we already talked about the two permissions the delegated permissions model and the app only permissions model but these things can also have beyond acls for azure key vault service principles can hold role assignments in azure service principles can hold role assignments in the directory service principles can own groups

other applications and other service principles so the service principle you can kind of think of it like a service account you may be an on-prem active directory if you're familiar with that but this is very very important because this has access to things in your environment and we just released um last week actually in the azure id signing logs you will now see all the sign ins for things like service principles and manage service identities which is a type of service principle and those have access to things you can see exactly today in your environment what these things are doing and what they have access to do in your environment so i know somebody here is probably

thinking at this point they're thinking exactly like grandpa simpson that this cloud is nothing but trouble i knew it from the beginning so i have and now in my tenant when i go look at this stuff i have all these mystery applications i have no idea where they came from with a bunch of users assigned applications i have no idea how anybody got assigned to these applications and there's a bunch of permissions that i do not understand what's happening in my environment this is all the cloud's fault and we have some stuff that will make this easier for you we have some scripts that we'll give you at the end of this talk you can run it in your environment

we'll cover all that but i dare you to ask these same questions about your on-prem environment if you don't have a very good application inventory which lots of customers do not have i dare you to ask these same questions about you about those on-prem apps do you know where all those apps have come from do you know who has what assignment to what applications do you know what permissions these applications need so this is the point here is that this is not a unique challenge to the cloud you probably have this problem already on prem you may just not be realizing it and the reason you want to start looking at this and go to the next

slide chris is because we're starting to see some malware campaigns around this so traditionally from a malware campaign right we have this invoice attachment we have some sort of macro we're trying to get the person to run and in this covet 19 type of campaign we're starting to see these people are you know just the utmost scum of the earth they're trying to impersonate the cdc they're preying on people's fear and they're still trying to get people to to run these attachments and these macros and this is the traditional type of fishing that you probably as you know administrators and you know defenders or even like attackers you know internal attackers trying to to get people to do

stuff this is the type of thing that you're probably used to seeing but from an application consent um that's something as a new thing we're starting to see you can go to the next slide karissa um where we're not seeing this like in effect this the most common types of attacks we still see are going to be the traditional phishing the traditional password reuse the traditional like legacy authentication is open nobody's using mfa so they're getting password sprayed but we're starting to see this as an evolved threat where instead of trying to get you to download that excel document or run that word document run that macro they want you to consent to an application so here you can see

this office 365 access application and that logo like looks kind of familiar but it's probably not quite right and we can see that it wants to read your contacts and read your profile that looks like some applications that i've done before if i'm not paying too close attention it also wants to be able to read all my onenote notebooks i also wants to be able to read and write to all my mailbox settings it has full access to all my stuff so if i'm not paying attention this i'm granting this permission or this application very powerful permissions to my account and we've seen a few customers get hit with this type of phishing attack and

that this is where we talk about you know the title says sustain persistence um your traditional types of malware tools here aren't going to work because there isn't anything run on the local workstation right this is in the service this application has now requested access to things that has access to this person's mailbox so even if you go in and you find this application as bad and we're going to show you how to do that and you remove it you need to do a little more digger deeping to eradicate this because if this application had the ability to create mailbox forwarding rules those forwarding rules are still going to be on those mailboxes even after you

removed that application okay so we want to make sure this is why it's really important to understand what people have consented to in the environment what those permissions that those applications have the ability to do and when we do find something that's malicious we are looking in the right places we're not just running a scan of that local workstation go yeah it looks fine oh yeah we deleted the app you have to do more than that you need to be able to look to see what that application had the permissions to do and did it make any changes in other places like mailbox forwarding rules did it make any changes into one or things like that those are all things that are

really important that we want to take a look at okay so hopefully at this point if you didn't know about application consent and you didn't care about it then you hopefully care about now so let's talk about some of those key permissions that you should be looking for in your environment so this is really for your reference but any of these really types of highly privileged permissions we want to make sure we understand and just because an application is asking for the ability to do mail read write all or directory read write all or any of these types of permissions that are just very very privileged doesn't mean the application is bad it could just mean a few different things

one the application might need this if you have an e-discovery application you're using it's going to need a lot of permissions in your exchange online mail environment to be able to search through things and search through sharepoint and find those types of things for legal discovery that's okay the point though as defenders and um you know application administrators we want to make sure we really understand does that application really need those permissions and if it's okay then that's okay it can do that but we want to make sure the other scenario here is that um and we'll talk about this a little bit later as well is that developers are just kind of lazy and they don't actually

sometimes do the work to understand what permissions they need and this is not a new problem i'm sure everybody here has had some business unit buy an application and say please set this up for us and you get that install guy and it says it needs to uh domain admin enterprise admin and scheme admin and you're like what in the world is this application doing it does it really need those application permissions no it does not need those directory permissions at all they just don't know they didn't do the work to figure out what the permissions need so you're going to see the same types of thing here so any of those types of permissions like this

we just want to be really really careful about what we let them do because it might have those very privileged permissions and it can do some damage and we'll show you that here in a demo a little bit all right some other low impact permissions too that you need to think about as administrators is that you know this is basic stuff any user can see their own email their profile user.read and that's that's okay but we had a customer where some they want some end user wanted to use this like directory application and they the directory application asks for these types of permissions the end user had the ability to say yes it went to the consent prompt

is that yes you can do that and it went on their normal way they did their job what they needed to do then six months later one of their executives went to this directory website and saw their internal profile picture their first name last name and email address and they said we've been hacked well no end users have this ability this is basic stuff that's in the gal right like people's profile picture is in the gal people's email address is in the gow anyone can read and see this type of thing but if you don't realize that other applications will have this ability to do this even though this is a low impact permission you need to understand

what they can do in your environment so when you think about policies and chris is going to talk about this a little bit later these are the things to think about are we okay with an end user letting some application you know see our profile pictures and see our email addresses it's not dangerous but maybe for some customers it is other customers it's not so these are things to go ahead and think about and now at this point chris is going to show you this really cool demo about showing you what application permissions can actually do in your environment yeah so thanks mark so in the previous demo you saw that i tried to access a demo that i didn't

have um rights to so now we're gonna look at um what an application that is actually in our environment and the type of permissions it has so i'm going into the woodgrove immunity passports application and here inside the portal i can look at the api permissions that are allowed for it and if you look through there's a few concerning things here one is if you look at the top of the name of the application there's three o's so it's that's definitely not how my tenant is spelled so i should be watching out for those type of misspellings the second thing to look at is like look at how many different types of permissions this application has

there's a ton of application permissions and you can see there's some delegated permissions as well and one of the main ones i'm going to point out as mark said is the user read write all like it may not be dangerous but we should be aware that this application has this because a user does not need to be signed in for the application to change things and i'm going to illustrate that with using the graph explorer which does have user read write all privileges and just to show you what that can do so i'm looking here at lisa that was the user profile that i signed in earlier and i can see her information here and what i'm going

to do is i'm just going to change this to whatever i want and i'm going to patch it okay i'm going to rerun the query and now lisa's profile has mark morrow as a display name so what does that mean for lisa and her profile so i'm going to pull up lisa's profile

and normally it looks like this right this is her my account where she does all her self-service management of her of her passwords and privacy and so i'm going to refresh it

one more time for good measure and now lisa smith has turned into mark morrow again this is just showing like what you can do with that privilege and that is a very high privilege for an application to have especially when a user does not even need to be present right so that's a very uh hopefully concerning demo and again just because it has those permissions doesn't make the application bad it just has those permissions to do those types of things in your environment so we want to make sure we understand what those applications are and why they need those types of permissions so at this point i'm guessing if you did not know about any

of this stuff you may be a little worried about what's in my environment and how do i like go deal with this so let's talk about like how you can go investigate these types of things so the first place here is if you only have a few applications in the office 365 portal you can look for some indicators of compromise you can go through the security and compliance center look at those audit logs if you see anything that says admin consent set to true that means a global admin had to go in there and approve permissions okay so again those are going to be those very privileged permissions and you know if you were an attacker and

maybe you tricked a global admin to consent to a lot of permissions though that that application now has the ability to do those types of things so we want to make sure we look at that you can also see this in the azure ad portal under the enterprise apps permissions that chris has showed you as well as in those audit logs but i'm guessing that most of you will probably not have a few apps you will probably have lots of apps remember the average app is like 140 or whatever you probably have much more than that so we have a script for you if you go to ak that ms slash get azure av permissions this is a github

repository of a script that you can run in powershell and this will dump out all of the applications and their permissions in your directory this is probably the easiest and fastest way to go ahead and do this if you also have uh microsoft cloud app security which is part of the our casb solution that can also be used to look for a high privilege permissions so once you run this script and chris is going to show you this here in a demo what should you look for so first of all look for anything that has those all principles this means it's applying to all users in the tenant so any of those non-microsoft apps like exchange online

is going to have the sharepoint online those are things that you would expect to have those types of permissions but any other types of applications you want to make sure you understand again what is this application and why does it need these permissions then start looking for any of those permissions that have those from the previous slide anything read write anything start at all those are all types of permissions that we want to make sure we look for so here in the slide there's an application called uipath spo bot file and it wants the ability to do files read write all that may be okay that may not be okay i don't know what that ui path

spo bot is doing but we want to make sure we understand that as administrators and defenders a few other things we should be looking for as well we want to look for those high profile high impact users these are those types of users that if someone said did you see it happen to so-and-so's account somebody says oh no but they probably don't use the word no they probably use an adult adult word right because those are the people that have access to very sensitive data we want to be very very sure what those people have consented to their their targets first types of spear phishing and things like that so look for those ones you know who those people are in your

environment go look in this spreadsheet to see what have they consented to then we have the traditional types of you know malware types of hiding things so things that are trying to hide right this app is called email it needs file read write all for all principles on microsoft graph that seems kind of suspicious apps that have misspelled names here so this one we got that driver's edge with the elite speak in there chris also showed you that in her sample we had wood grove but it was spelled with three o's instead of the normal two trying to blend in or just any of those weird hacker sounding names intelligence this thing wants data rewrite all for all principles again

very very privileged what is this application why does it need that and then some other things to consider here as well so this is just a general indicators that compromise stuff to look for this is going to be suspicious activities outside of like normal office hours deviations from their normal behavior based on you know why is this person in one department doing something in some other app they have no business doing um date and time of applications being created so we've seen this as well where the application was created a few days ago and now it's being used think of this just like how people defenders do this for domain names right this domain name

was created three or four days ago now we're getting a bunch of you know suspicious looking emails from it that's pretty suspicious same thing with applications if we can see the application date time was created a few days ago looks very suspicious we want to go ahead and take a look at that as well and chris is going to show you the output of this script yes so if you go ahead and follow the guidance from that github link you will get and run it in your powershell in your environment you're going to get a csv file that looks kind of like this and basically it's just gonna be a bunch of columns it's gonna show your

permission type object id display name it's also gonna show you like um like mark said like look at the the consent type if it's going to all principles or not the type permissions it has and if you're a data nerd like me then you might want to just like quickly put it into some pivot tables this way you can quickly see by permission and the name of the application you can see how many have application permissions or delegated permissions you can also start filtering out by directory read write all or user read write all things like that so i definitely recommend doing this it's a great tool to learn your environment very valuable in in in protecting

yourself from these type of consent attacks yeah so go ahead and run that script um we're continuing to make improvements to it so use that same uh same url we'll continue to add things to it so okay so at this point you've run that script you've looked at that output and you find something that does not look great so how do i start investigating this type of stuff so first um if it's an office 365 type of application so like one of those ones that's maybe made changes to mailbox rules and things like that you can use the security and compliance console here to search through those logs and you can look for those indicators to

compromise in those keyword settings there if you know the scope of the attack so it's it's just exchange or it's just one drive selecting that location will cut this way down in terms of search time you don't have to search for everything in office 365 so that's a good tip there for you when you're starting to investigate so you've taken a look there and now you're you've confirmed an attack has happened it's time to start your incident response process so the first question i want everybody to think about here is does your ir process cover this scenario of application consent and if it doesn't that's okay this is the time to start thinking about it to talk about it

to work with that with your different teams because if you don't realize what's happening with these applications and how those permissions works and what those things can do your traditional ir process will probably not cover this and like i said earlier when you run your tools on the local workstation and you don't see anything you're not going to see anything because it didn't actually take place on that workstation there was no macro that ran all those traditional tools where we work through those types of you know time-based analysis don't work greater on that client because it didn't happen on the client it happened on the server side so we want to make sure that our ir process covers this scenario

and the time to start going through this is now not when you've had an attack again this isn't something we're seeing happening all the time but it's starting to emerge so this is the time to go build this into your ir process so what should you do again here disable that malicious service principle service principles are very important here we want to revoke the consent for those applications you can revoke any of those role assignments remember service principles can have roles so maybe the application did that you can disable a sign in for this and then we want to remove any of those persistent mechanisms that the application may have added remember if it adds those mailbox

forwarding rules and you you don't check for that and you just remove the application you have not removed the attacker those mailbox rules are still going to be forwarding mail and those things that they did so we want to make sure we're looking into that to make sure we fully remove it we don't just remove the app or disable the application we need to go see what they actually change and remove those types of persistent mechanisms as well and with that chris is going to cover some best practices we can do to go forward here yeah so thanks mark so one of the first best practices that we're recommending to protect yourself from app consent attacks

is to set up some policies and inside the azure portal you can decide who can consent to applications within your organization so as you can see in the screenshot on the left you have three buttons you can prohibit all your users from consenting to applications whatsoever you can also allow all your users to consent to applications both of these we don't think are the best decisions unless it's very specific to your environment what we do recommend is the middle one which is to allow users to consent to apps that are from verified publishers and they're for selected permissions that you decided as an organization are considered low impact and safe so another option shown on the right hand side in the

right hand side screenshot there is if you have mcas which is microsoft cloud app security that mark mentioned earlier you can set up app permission policies which will automatically revoke an app or a user from a specific app based on certain detections in your environment so the second best practice that we recommend is to use and track risk-based user consent so what is this step up consent when a risky request is detected the request will be stepped up to require admin approval so as you saw in my demo users and admins will see this warning but the admins will have the ability to approve it on behalf of the entire organization so when this happens

also an audit event will be logged and as we all know like logs are only as useful if we use them and check them and take action on them so as admins you want to have a process in place with your requests coming in don't just let them hang there it's important to assign owners to clarify which factors could be considered should be considered um to grant or deny permissions and then once that admin grants consent no other users will see that warning for that particular app and it will be now in your environment so number three is to detect risky oauth apps so now that you've protected yourself from any illicit apps you might

encounter in the future you can't forget about the apps that might already be there so there's a good better best approach to this but most importantly we just want you to do something about it and to monitor it on the regular so the script i showed you go do that it's a great place to start it does require like i said a little bit of manual work and looking through the data but you'll get to know your environment by combing through the apps and the permissions and identifying anything that might look over privileged or questionable so better yet we recommend using azure monitor to set up alerts that will automate that process for you so

you can set up notifications that when an oauth requires super high security permissions or um is authorized for a big chunk of users you'll get notifications and emails for that and then the ideal option is to do some risky app hunting with a cosby solution such as mcas you can filter and find apps that are potentially very risky or that users consented to not knowing the potential risk so some of the things you can filter on are high permissions not common use or authorizations by external users and the fourth one is for developers so developers check your app it might be and it probably is over privileged we're seeing new permissions and we're putting out new

permissions all the time here at microsoft so it makes it really easy to scope with granular scope your app to granular permissions and one of the common things that we see with line of business apps especially is that devs are not following least privilege so this is by no means a new problem as you heard mark mentioned earlier but we really want to encourage developers to follow these privilege and only ask for what is necessary take a look at the guidance that we put here in the deck those are super helpful links to get started and then in terms of teams it's becoming more and more popular we want to make sure that apps can only

access the teams they really need so take a look here at the team's specific permissions we've included a link as well and last but not least we highly recommend this developer guidance it's a identity identity developer series but we recommend it for all it pros and all devs to watch so i you will not regret it i watched it and you'll learn so much from this video series i don't have a developer background but i made i learned a ton about api calls you know to microsoft graph permissions and scopes access tokens client credential flow all of this is super valuable and we recommend it both to it pros and devs alike and finally make sure to report

suspicious apps back to us you can report them directly on the consent screen as you see in the screenshot here or using mcas all right so let's recap with some go do's so do inventory your applications and their permissions it's always important to know what's in your environment so this is not a waste of time and you know we've shown you some great tools to do so automate threat response where possible educate your org on these consent attacks as mark mentioned this is not something that we're seeing a ton of yet but it is starting to happen and we want people to be aware of it and then lastly educate your developers to make sure they follow the best

security practices will leave you with some helpful resources and then before we open up to questions and answers so thank you for attending b-sides and we really look forward to your feedback on our session