Hiding in the clouds: How attackers can use applications for sustained persistence and how to find it

let's get started with our next talk from mark marzins marinsky michael epping sorry if i butchered your names i owe you guys a beer so um let's uh let's get started with hiding in the clouds how attackers can use applications for sustained persistence and how to find them so michael's going to be driving the slides and some of the demos and i'm going to do my best to watch the chat as well as watch the discord so if anyone has any questions they can uh post it there and i'll try to keep an eye on it might be all set yep good to go okay cool so uh hi everybody so uh welcome to hiding in the

clouds how attackers can use applications for sustained persistence and how to find it i am mark marzinski i'm here with michael upping and we are program managers in the identity division at microsoft so we are responsible for active directory active directory federation services and azure active directory so um let me go to the next slide there michael so uh we work on a team that is working with customers on their deployments of azure active directory and we take those learnings and uh the feedback from those deployments we work it back into the product to make it easier and better for everybody else so if you have office 365 i know people in b-sides sometimes don't

spend a lot of time in the identity space like michael and i do if you have office 365 you have azure active directory so uh mike and i have worked with a lot of customers on this issue so i think we have some good stuff here we're gonna share so what we're first gonna cover here is what is application consent and why you should care about it if you aren't already and then i'm going to talk about what are some of those key permissions you should be looking for and then michael's going to go into how to find um some of the stuff in your environment and then lastly we're going to cover some best practices and things

you can go do so there's a lot of stuff in this talk we're going to make the slides available at the very end and uh hopefully we have lots of good things you can go back and do in your environment to protect yourself so okay why should you care about applications if you haven't been doing so already so on average the organization will have 140 apps but this can why be a number that varies greatly depending on the size of your organization so some of the customers that michael and i work with are extremely large and it's not uncommon for them to have thousands and thousands and thousands of applications one of the customers i'm working with

um is modernizing their applications to move to azure ad as their identity provider and they think it's going to take them from anywhere from seven to nine years to move all their applications to modern authentication so 140 is just kind of like a low number but you probably know better than anyone how many applications you have in your environment and 87 of users today can consent to applications and the the active consenting to an application which we'll get into here shortly isn't necessarily necessarily bad or malicious but there is some things that allows an application to do in your environment which you may or may not want them to do as blue teamers right so michael and i

um are really all about this blue team defense there's a lot of good stuff in here that you may not be aware of but you need to as a as those architects those security folks and those blue team defenders that just because you can send to an application means an application can do stuff and you may or may not want that depending on your environment and your organization and your business model risk tolerance and things like that and then 80 of employees are using non-approved apps from work you've probably heard this before this is the shadow it type of thing where um you know and again doesn't mean that they're they're malicious um it could be just

like we want people to use box or onedrive and this business unit is using dropbox because that's the link that they got and they didn't know any better and now we have application you know corporate data on these different things that there shouldn't be so if you haven't started to look at your applications and data you really really should so let's talk about what we mean by when we say application consent so you're probably pretty familiar with this um on your mobile phone right so you so you add an application to your phone um from the app store or wherever and it says it's asking for a bunch of permissions that it wants to be able

to to do so wants to be able to maybe access your camera because it's gonna take your picture and you can then modify it and put funny faces or whatever you're gonna do on it and it also wants it access to your photo library so you can edit past photos and it also wants access to your contacts so that way you can send that funny photo directly from this application to your to your co-workers or friends and family and things like that so uh the application consent model um in azure id and and most cloud apps so michael and i are going to talk about um azure id perspective but this applies to any oauth or open id connect

applications as well so it's not specific to azure id but this is what we're going to talk from from our point of view so this consent model of application consent and permissions is a very very similar model in azure directory so we have an application and it's going to want to have access to organizational data and that organizational data is going to be exposed via resource apis and there's different permission levels for those apis and we're going to get into all this here in a little bit and those permissions can be granted through the process called application consent and we have two different types of consent we have admin consent and we have end user consent

but let's talk about some of these different terms so this is kind of like a high level thing but let's kind of dig in to align ourselves to that open id oauth type of spec so the first thing here is we have a term called a client application this is going to be a it could be a mobile app it could be a web app it could be an application that's running in the background that's going to be requesting that data on behalf of that user and then we have the resource application which is going to be usually a web api that exposes this data or functionality in our in our case here um at azure id it's going to be called

the microsoft uh graph and then we have permissions which is what the client application is asking to be able to perform on that data owned by that resource so here we have a screenshot of this and you may have seen this in your environment where we have an application here called contoso test app and this application wants to be able to read users and shared contacts their calendars and sign in and read their profile this is going through the microsoft graph so another example is like onedrive some application wants to read the user's onedrive files all through the microsoft graph so this is kind of the dialog box that you'll see here as an admin or an end user and michael's

going to show you a demo of this here in a little bit to kind of go over um you know walk you through this if you've never seen this before but let's talk about some consent terminology so that dialog box that we just showed you is called the consent prompt um and then we have the act of saying yes it's called the consent grant so it's pretty straightforward now here is where we differ a little bit from that phone type of model that you may or may not be used to i'm guessing here everyone is probably used to that model so the process of administrator consent is when someone with administrative permissions is going to

be granting access to an application and we do this because of two different reasons the first reason is the application may be asking for permissions that are highly privileged and we don't want end users to have the ability to say that's okay because they don't maybe understand what's being asked they don't understand what the risk is to the business they shouldn't be able to to do this so maybe the application is asking for the ability to read and write to all mailboxes and maybe that reason is because it's an e-discovery app right we don't want end users to be able to say like that's okay that's that's quite a bit of permissions an admin will have to go in there and

say that this is a this is a very privileged operation um an admin is gonna have to say it's okay before we can add that to our to our directory the other reason why you want to do this as an administrator is because when an administrator does a consent grant for an application they're actually consenting to this for all of the users in their directory so then users will not see the consent dialog box when they go to use that application as an end user so the best example i can think about this for is the native mail client in ios so if you're going to use it with exchange online a user you know opens up

the mail app they put their username and password in they do the whole authentication flow and then the application prompts them for that consent grant experience and it wants to be able to like read to their mailbox right to their mailbox some you know basic stuff right just whatever it can do and the user can say yes they can do that and then they go ahead and click through and now the native mail app on their ios device now gets mail but we could say as administrators or defenders we can say you know what we trust this application and we're okay if people use that and we want to improve that end user experience we're going to go in there as

administrators and do an administrative consent for this application now the next person that goes to use that native mail app for the first time they will not have to consent to the application because as administrators we've already done that consent okay so there's two different types of permissions that we're going to consent grant applications can have and we can send to that the first one here is what we want most applications to be using which is the delegated permissions model and this requires for an application to work the user must be signed in and present for the application to make calls on behalf of that user so this is what most end users can consent to and if

it's a higher privileged permission this is what requires an admin to get involved to consent to this application now this is where people tend to get a little tripped up because of the effective permissions model of this delegated permissions this is the intersection of the users underlying permissions and what the application can be congrated to so what do i mean by that let's say this application is the best search application ever right it's the best thing ever for searching sharepoint sites and it's asking for the ability to read all sharepoint sites so user consents to this let's say it has the permissions to do this they can send to that application or they're going to use an

application [Music] they are not getting the ability to search all of sharepoint the effective model is the intersection of the application and that user so if the user only has the ability to read certain sharepoint sites when they're using that application they too only have the ability to use that search on the sharepoint sites that they have so what i'm trying to say is they're not grant you're not granting people more permissions than they normally would have using the delegated permission model it's still what the user has and what the application is able to do now this is sometimes called scopes oauth 2 permission grants or app plus user permissions and we really really want to use

applications to have the delegated permission model now the second type of bishop model is called application permissions and these are used by apps without anyone being signed in or present so these can run fully in the background no user required and whatever permissions that you grant to an application in the application permission model that is the permissions that application has the ability to do so if there's some application that is asking for the ability to do directory read write all that application has the ability to do directory rewrite all there is no intersection like whatever we grant this it can do so these are extremely powerful permissions that we want to make sure we understand why applications

need those permissions and why it has to have this permission model we really really want to use that delegate permission model because with intersection um application permissions are also always always required admin to consent to end users cannot consent to this and this is sometimes called roles app roles or app only permissions okay so we have this nice slide here that kind of is a summary of everything i just talked about in those previous two slides so just to kind of recap because this is kind of a lot of information if you've never looked at this before we have two types of permissions we have delegated and application permissions and that delegated model is going to be

for those mobile apps those web apps or those spa you know single page applications and users can grant or can consent to this or admins can consent to this for all users in the organization and this requires a user to be signed in and present and that effective permission model is the combination of what the end user has as well as what the application has the application permission model is when runs as a service and only can be consented to by the administrator or whatever permissions we grant that is what that application has the ability to do so they're very very powerful so we want applications to use the delegated permissions not application permissions if we can

help it and with that michael's going to show you a quick demo of this consent framework yep so i'm going to switch over here to my browser so what i'm going to show here first is i'm a standard end user and what i'm going to do is i'm going to go to an application that has an sso experience with office 365. so this application's never been created in my directory before i'm a normal end user i want to sign in with my office 365 account um but in my tenant my normal end users are not allowed to consent to permissions on behalf of themselves so what you see here is kind of the standard consent experience where

it shows like what permissions it's asking for uh you know we can see that it's asking for some permissions to read the user's groups to read the user's profile a couple other types of permissions but the user doesn't have the ability to actually go and consent to this for themselves there's also a feature where you can have a workflow where the user can enter a justification say like i need this for work and click request approval and this will send a notification to your administrators and then the administrators can go and decide if they want to grant that access but out of the box this feature is not turned on so typically your users are going to kind

of run into a brick wall here and maybe they need to open a help desk ticket or maybe they just never actually get to use that application in this case i have the feature turned on so i'll click i'll click the request button and that's going to generate a request send it to my administrators but at this point i don't i don't get access to the application so over on my administrator side if i go over to the admin consent area we should see that that request came in uh so we can see that there's this app that's being requested who's requesting it um but really what i want to show is what does the experience

look like when an administrator actually decides that they are going to go do the admin consent so i'm a global administrator in this browser window so i'm going to go in here and specify which account i'm signing in with and here i am able to see the same permissions so it's roughly the same experience but i have this new checkbox because i'm a global administrator that's consent on behalf of your organization so like mark talked about basically what this is going to do is it's going to uh codify this app as something that's allowed or my end users are allowed to use in our environment so any subsequent end users who come to use this application they're not going

to see the consent screen they'll be able to just sign right in because this is an approved app just like that ios mail app use case so in this case i'm going to hit accept and the admin consent at this point should be complete and users no longer will see the consent screen all right um so yes uh that's if you've never seen consent before that's the consent experience so let's talk about um what happens when you click consent but before we get to that michael bill made a comment that microsoft is using a mac slapping face so um good good eye bill so there's a few people on our team that use uh mac laptops

mike and i happen to be both of them and we have lots of customers that actually have macs in their environment and we do a lot of stuff with them to help improve the mac experience as well um from a like identity side so i actually just posted in the chat we have this new apple sso plug-in that will help cut down on the prompts uh you're getting on those ios and mac devices so i just pasted that chat in there and if you have any questions about azure id in general or mac on azure 80 in general michael and i are both very uh able to answer those questions you can post into discord and we're happy

to answer those after this talk as well okay so we click consent what actually happens under the hood so the first thing is uh in azure id there's two parts there's called there's a application registrations and there's enterprise apps and we're doing some work to kind of make this a little bit easier for you but um hold on go back go back michael we've got a lot to go through so um what actually happens okay so the application registration is the definition of an application you can think of this as like this is the the back of the house configuration of the application so this is like is this application gonna be a a single tenant application like only

for us is this gonna be an application that's a multi-tenant application is it gonna be able to use azure id credentials do you want to be able to use azure credentials and and microsoft accounts so this is all going to be part of the definition of the application itself which is only going to live in one tenant and then in the enterprise apps is where you're going to have the service principles and this is the representation of that application in the tenant so you can think of the enterprise apps area as the front of the house so this is where you can apply like conditional access policies to the application to say in order to actually get to this

application you need to do mfa you need to come from an applica or a device that's either in tune managed or all kinds of stuff like that so that's all going to be in the enterprise app space so to give you an example of this let's say michael and i are working on a time keeping application so in our tenant tenant one we're gonna have an app registration of the timekeeping application and then we also use that application to keep track of our time on the projects that we work on so we're going to have that service principle in the enterprise apps of our tenant and then we sell this application to other companies so they can do

timekeeping as well so in 10 and 2 10 and 3 10 n they will have a service principle in their enterprise app of this application they will not see anything in app registrations for this app specifically so if you go look in your um azure ad directory you will find enterprise apps for things like exchange online salesforce workday things of that nature you will not see anything in app registrations but let's say you are moving your line of business application so there's an application that you made just for your tenant or maybe it's an application that you're selling to other companies um you'll see that app in the app registrations as well as seeing it

in enterprise app so um this is confusing let us know in the chat we're happy to talk a little bit more and help and discord but this should hopefully explain why when you look at your tenant you don't see those sales force in exchange online and sharepoint things like that in your app registrations you only see that in your enterprise apps okay so service principles are really really important because applications can be off authorized to access data you can go to the next slide michael so a service principle in this model is a security principle so service principles can be granted access to things so we already covered the two um ones you're probably thinking of

which is that app only permissions as well as the delegated permission grants but service principles can also be on azure key vault acls service principles can hold role assignments in azure service principles can hold directory role assignments in the directory and service principles can be owners of things like groups um application and other service principles so service principles are very very powerful things we want to make sure we have a good understanding of what applications have been consented to in our environment and what are those permissions because they can do lots and lots of things in their environment so you go to the next slide so i know somebody here right now is probably thinking just like grandpa simpson and

they're like i know that the cloud was a problem from the start and now i have all these applications in my tenant i don't understand how any of them got there because people have been assigned to them i don't know who got assigned to them so i have like some people can access applications some people can't and i have all these permissions that can do things in my directory and i have no idea how this happened like i know this is the cloud's fault and we should never done the cloud to begin with and uh it's not as bad as it seems we have some stuff we'll give you that will help make this easier and there's some

knobs you can turn that will make this easier as well but i dare you to ask the same questions about your on-prem apps as well it's actually usually for most customers it's worse because there isn't a central place where applications are coming through it's worse because we don't know who's accessing what applications it's worse because we actually don't know what permissions those applications have asked for an application may have asked for something like domain admin and what permissions is it using can you even tell you you don't know so things like that so it's actually probably going to be worse on-prem but um in the cloud we have some stuff that's going to help you

um with this so why are we talking a lot about this in all this because we're talking about all this stuff about this application it's like why should you care about any of these things that we just said let's get into the malware part of this as well as that sustained persistence so typical malware campaigns have been right where we have the the subject is we're trying to get you to you know entice you to open this mail we have some sort of like attachment and we want you to run this because we can run that macro in our environment and you know we have that spoof stuff and now we're starting to see those covid19

theme campaigns so these people are trying to impersonate the the cdc they're trying to prey on people's fear and again we still want them they want you to run that that word document that attachment so they can run that macro and they're trying to take it take advantage of people's fear with covet 19. so this is what they've been doing but what we're starting to see people move to is instead of this traditional fishing where we eventually try to run a macro they're trying to get you to consent to a malicious application which this has a few different things that we want to make sure we think about but this is kind of an example we've seen right so this covet

19 bonus attachment go ahead and click on that and now we have this application consent grant that we've seen for other things and this application is called office 365 access that logo looks a little bit kind of okay but looks a little odd to me and let's look you know it's asking for some stuff read my profile read my contacts and then if you start looking through these consent prompts it wants to be able to also read your mail it wants to be able to read all my notebooks and it wants to be able to read and write to my mailbox settings which can have all kinds of access right and just it's a quite a bit of

permissions and if a user clicks on this remember that this is a delegated permission request it has the same ability for these permissions and what that end user has the ability to do so this end user has the ability to update their mailbox rules and change forwarding rules like that's something that end users have the ability to do and need to do and now this application has this ability to do this as well and this is where that sustained persistence comes into the mix because if you click accept to this then user clicks accept and there's no we're not doing any other proper stuff we'll get to here and shortly um this application has the ability to

do that so let's say you find this application is bad and malicious and you go there and you remove it you delete it great it doesn't remove the persistent mechanisms that it's in so if it added a mailbox forwarding rule to say anytime mail comes in with payment or whatever send it to this external domain it doesn't clean those rules up so from a sustained persistence model just because you they got you to click on this application and you remove the application you still need to remove those existing things that made changes to in your environment and this gets even worse if it's from an application that has admin permissions because permissions that you can grant you

as an admin can be equivalent to just like an admin account so let's say an attacker got a hold of an admin account and they knew they were only going to have access to this account for 5 10 15 minutes and they went in and they granted consent to a application that has the ability to do things like directory read write all and then they lost access to that account that application basically has the same permissions as an admin so it can be very very um powerful in your environment so you want to look for this okay so what are those key permissions you should be looking for in your applications so anything that's like a star mail.star

mailbox settings star contacts people file star anything that's that directory read write all that type of stuff anytime you have read write all you really want to make sure we understand what those permissions are used for now just because an application is asking for the ability to read all mail or maybe do like some of these permissions membership read hidden things like that doesn't mean it's bad it just means that it has a lot of permissions and something like i talked about earlier which is like an e-discovery app it's probably going to need the ability to read and write to all the mailboxes maybe if it's a governance tool it's going to need to be able to read those

hidden group memberships it's going to have a lot of permission so just because an application is asking for these types of permissions doesn't mean it's malicious it just means it has a lot of power and we want to make sure we understand exactly why the application needs these types of permissions because usually it doesn't and people just don't know we'll get into that a little bit here uh shortly but these are really really key permissions to look for want to make sure if you have any applications in your environment that have these permissions you as defenders really really want to understand why does it have those permissions and does it really need that okay some other lower level permissions

that i want everybody to think about is user.read open id email and profile these are like very very basic permissions that are considered low impact that people can just go ahead and use but the question you have to ask is are you okay with end users consenting to these applications to begin with so the example i have for you is we had a customer that some end user wanted to use like a directory application or whatever and it asks for these permissions and basically like wants to read the gal right any end user can read the gal wants to read the gal user click yes the user and user had those permissions it uses that delegated

permission model the application read the gal and about six months later one of their executives was using that same directory application and they were very very surprised to see their first name their last name their email address and their gal profile picture was on this directory site and what was the reaction we've been hacked we've been hacked our data's been pushed this site what's going on here they haven't been hacked right this is just basic information that end users have the ability to do they can read the gal they need to be able to do that but you as a as an organization from a risk perspective need to make those decisions are even though the permission impact here

is low this is just basic stuff end users can look at do you want them to be able to consent to this type of information because you may not want them to be able to do that because people don't understand the impact and with that michael's going to show you a demo here to kind of really hammer home what applications can do in your environment from a permission perspective okay so just from a getting started standpoint one of the things you can do in the azure id portal is actually go and look at the permissions that have been assigned on your applications and check and see if they've been admin consented so looking at this application that we

have in one of these lab tenants we already can see that this thing has some suspicious stuff going on you can see that it's kind of got a misspelling in it so that's probably not good uh so this might be something that is concerning and if we start looking at the permissions uh there's a couple things we notice there's a lot of permissions that have read write all uh so there's a lot of write permissions in here including directory read write all which is very dangerous um this is kind of like being a global admin in in uh in the application and then if we look at the type of permissions again we're seeing those application

permissions so delegated are the ones that we want to try to use if we're giving application permissions these are very broad permissions so for example mailbox settings.read write basically gives the application the ability to set things like rules like mailbox rules on any mailbox in the tenant so let's take a look at what that looks like if i'm an application so going over here i actually set up a demo app in my lab that has that setting mailboxsettings.readwrite as an app permission so this app that i'm going to demo with has the ability to go touch any mailbox and set mail forwarding rules on it essentially so you know we're not 100 sure how the

setting got put in maybe an administrator got tricked maybe an admin consented to this because they didn't really know what they were doing or uh something happened where this app got an application mailbox setting.read permission so not ideal so if we pop open postman i'm going to pretend to be the application here so what i'm going to do here first is get an access token so what i've just done is i've gotten an access token in the context of the application no user signed in there's no no user interaction no administrator interaction i'm going to take this access token and in the context of the application i'm going to create a mail forwarding rule so i've got a user here uh so same demo

user i've been using so luke michael epping.com and i'm going to make a call to microsoft graph api to set a forwarding rule on his inbox so again no user interaction here like luke's never signed in nobody signed into this thing this application just has permission to do this so i run the graph api command and it's done there's a mail forwarding rule so what does this look like from an end user perspective so if i go back to luke and go to his mailbox view outlook settings and rules we can see that there's a mail forwarding rule here i can set any parameters on this i want i can make it look sort of official try

to try to encourage the end user not to modify this make it look really legitimate but if i go back to postman and i look at the actual contents of the rule we can see here that it's forwarding to my gmail address and i just use help desk as a placeholder so essentially what we have here is an application that has permissions to modify mailbox rules on a user account with no human interaction so once the permission is given this application can do this at any time to any mailbox so even if i delete this application this mail forwarding rule that's being used for data exfiltration is not going away okay so let me just fire my slides back up

so how do we actually investigate these illicit consent grants so we have these in our environment already but we need to actually go discover them uh so at this point like maybe an administrator and your tenant has already consented to something maybe it already exists what do we do about it so there are multiple ways to investigate this uh some that are like really easy to do in a one-off scenario but if you have a lot of applications in your tenant like hundreds or potentially thousands in the case of a really large uh azure ad tenant we need something a little more automated but the first thing is you can use the office 365 portal

um there's an audit log tool in the office 365 portal that you can lose you can use to look for all sorts of things you can look for applications getting added to the directory consents being done you can use the security and compliance center audit logs to look for admin consent actions uh you know any actions taken by your global administrators it's very powerful so there's a lot you can do there in the azure id portal like i showed you there's an enterprise app section where you can go and look at the permissions that are on any of the applications in your directory there's also audit logs in azure ad azure id retains audit logs for 30 days

but there's ways to export these to like sim tools splunk whatever so you can invest so you can keep them for longer to do investigations past the 30-day mark but then if we want to actually investigate what exists at the point in time we've written a powershell script so basically what this powershell script allows you to do and i'll i'll demo it in a little bit but what it allows you to do is actually pull a list of all the permissions that are in your directory currently and export them to an excel file and you know parse through it you can do pivot tables you know any sort of data analysis that's available in excel

and really comb through this and hopefully what the excel the excel file also helps you do is prioritize and then finally there's casb solutions as well so in uh at microsoft we have microsoft cloud app security which is our casb product there's other ones out there on the market but these also allow you to investigate so with microsoft cloud fc security you can create policies to investigate risky app consents and even revoke or block them so start with high risk users and apps that have lots of users assigned to them the reason for this is in really really large tenants you may have a ton of applications and you want to prioritize like what's most risky so mark showed the slide

earlier where he outlined like permissions that we we say are relatively high risk uh ideally you'd investigate everything but sometimes there's a lot going on in an environment and you want to start with what's most high risk so in the script in the excel output we've tried to help you do this prioritization so that you have a list of applications that have lots of users assigned to them uh they're they have riskier permissions they have application permissions you know like all the red flags we're kind of looking for uh so in the excel file you'll see there's a high risk users tab and also a high risk apps tab uh definitely use these uh and start

with those applications but don't stop there like you really want to get a handle on this for your entire environment and you want to look for write permissions that that's one of the other things to keep in mind is read permissions can be dangerous but the right permissions are like really really dangerous you want to look for things like applications that have right permissions or delegated right permissions that have a lot of power over a user like things like modifying the user's mailbox and things like that okay so let's take a look at the excel file this is just an export from my lab tenant uh but basically what this excel file consists of is a big bucket of data about every

consent grant that exists in the tenant and then we have a few tabs that we auto-generate that have pivot tables and pivot charts on them and we've done some classification for you so that you can see what applications are considered to have low risk permissions how many have uh delegated permissions to all principles so this is an admin consent and then how many have individual user consents and then how many have application permissions so for example there's some you know graph api permissions that have been granted to all users in this tenant and some application permissions these are things we probably want to look into if you're better at pivot tables than i am when i wrote the script

all the raw data is there so you can do any of your own analysis but hopefully this is something to help you get started so like i mentioned we have we also have these high-risk user and uh high-risk apps tabs so there's some logic built into the script to basically look for users who have lots of permissions uh you know lots of consent grants in the environment and then flag them so that you can investigate these users well you know and help you prioritize in this environment i don't have a ton of users but there could be a bunch in here at different risk levels like medium low but really like the high risk users are

the place to start and then probably even more important is high risk applications so again those applications that have lots of users assigned so if you see this all users thing again this means that there was an admin consent done which means that any user in your tenant can access this application and you use any of the effective permissions that that app has or the application has some application permissions so can act without a user signed in at all um and then for other applications there may be a subset of your users who are allowed to sign into that application so we just have a nice descending table to hopefully make it easier to prioritize

okay so some other indicators of compromise to look for uh apps trying to blend in i i've seen apps before that look like sharepoint but they have like a one instead of the i um you know you saw in our lab tenant we have wood groove instead of wood grove uh you know apps will try to blend in they'll try to look like a legitimate application they'll try to look like one drive they'll try to look like sharepoint they'll even use like very similar logos all sorts of stuff like that um so keep an eye out for things like that uh keep an eye out for suspicious activity like if you're analyzing your sign-in logs for your applications

um you know look for things like users signing in at odd times of the day uh users signing in from odd locations uh you know you know your environment and you should really know like what the typical usage pattern in your environment is and then be able to flag things that fall outside that usage pattern so deviation from the user's normal behavior is the user logging into all sorts of applications that they really shouldn't be like do you have a user in finance who's doing lots of stuff with graph api that might be like a little unusual are they accessing like azure id powershell that might be a little unusual um so you know your users you know what

they're generally getting up to keep an eye out for for users doing things that you normally wouldn't expect and date and time of applications being created so if you know that there was a compromise look at your look at your logs and see was an application created in my tenant around that time or just previously to some sort of incident and use that as part of your investigation look at who added the application what permissions were granted to it all those sorts of things so you also need to determine the magnitude and scope of the attack so one of the things that you can do and this is a tip from microsoft start team i believe so and

that's one of our incident response teams but basically what you can do is use the office 365 content search or audit log and content search tool and you can scope it to a specific service so like if you have a breach go in here do an audit log search see everything that a particular user was up to around the time of an incident and scope it to a specific service if you're able it makes the the search tool execute much more quickly if you can scope down what you're looking for and if you have a confirmation of of an attack start your your incident response process so does your incident response process cover app consent scenarios so

all the stuff we've been talking about are these things factored into your incident response so do you disable the malicious service principle are you revoking the oauth consents that are done there's powershell commands you can use to revoke the oauth consents um are you revoking the service april assignment with powershell are you disabling sign in for accounts that have accessed the application or accounts that may have consented to the application or done an admin consent to the application and are you then investigating persistence mechanisms so if the application has the ability to modify mailbox settings like i showed maybe you need to look at like are there any weird mailbox rules on some of the

mailboxes you need to investigate what may have been done with the permissions that were granted to the elicit uh the illicitly consented application okay back to you mark yeah so let's cover some best practices but that big one there at the very end michael talked about is removing the persistence is is super super key sometimes customers discover there's an app that's malicious and then they're like i dumped the memory we ran everything on the box we did timeline analysis like it looks clean and it's like it's not on the box right it's in the service so that's uh super super important to realize okay uh what are some best practices we can do for this

so the first one here is you can set policies so any app consent policy that the user is going to get um get prompted with you can you have three different choices and it's a little hard to see depending on your bandwidth here but the the bottom uh there it goes the bottom one is allow users to consent for any application um so any user can consent to any application permissions that delegate permissions um they can just consent to it the top button is don't allow users to consent anything an admin has to go in and approve everything the the goldilocks one is kind of this middle one that which which is now the default

in which we recommend but i've seen customers set to the the bottom one which is allow anyone to consent to anything because they didn't understand what was going on and this is if there's a low permission which you can define which are those low impact permissions and the application is from a verified publisher so that's they've the application vendor has connected their tenant to their microsoft partner network so you get the little like blue check box in the uh in the app if it's one of those you can let people consent to it which means like hey we're we're we trust this application it's not some fly-by-night thing we're okay with it so you can set those

but pick a thing and make sure you set it so you understand what people can do in your environment to begin with then also if you have a cloud app security you can go ahead and use this to automatically revoke any applications when app risk is detected so that's the first thing you can do the second thing is this step up consent so when risky consent is being asked for the admin will have to go in and approve this this is on by default so somebody uh chris asks in the chat is there a way for admins to be able to like review the configuration before actually going forward this is exactly what this is this is that middle ground

you can do um for that and only administrators would be able to consent to an application if it's not one of those from a verified publisher or if it's not one of those application permissions that's considered like low impact the other thing here with this is an audit event will be logged as well so this is really really useful if you see somebody maybe clicked on an application that was considered risky and it showed up in the audit log but you know they weren't able to consent to that maybe they just got a phishing email right and maybe they're getting other phishing emails right so just because a user wasn't able to consent to this

application and is pending an admin that is really good information for us as defenders to take a look at because now maybe that domain is suspicious maybe the email address itself is suspicious we can maybe look at other people that have gotten that mail right so make sure you're looking at your autolog for these types of events all right next is how do we detect these applications so those those two configurations things we just talked about is going forward right this is what the new applications are gonna get now how we look at what's already happened in our environment so the first one there michael already walked us through this which is that really really nice script

um i i pasted the link in the chat but you can get it here as well and this dumps out all those permissions you can look through them do the pivot tables all that kind of good stuff um that's a good place to start the issue with that is you have to do it all the time right like some admin has to go in and run this and look at this and then make a decision and you have to keep doing it over and over again a better thing you can do is using azure monitor or a seam tool of your choice where you're piping those audit logs to it and you take a look at

but an azure monitor you can automatically send notifications when an app is requiring high permissions an app has been authorized by more than whatever amount so let's say it's that good example there is that apple um mail app right a bunch of people are consenting to that they can let's take a look at that that's something we're okay with as an organization let's go ahead and do admin consent for everybody improve our end user experience you can do that with azure monitor and then the best is something like a kasbi solution michael kind of talked about that earlier um microsoft's one is called mcas but it doesn't really matter you can use whatever you want

and then again it has stuff that's like apps authorized by external users that high level stuff you can revoke it when things are people are acting odd so that's kind of like the best solution you can do is that mcas but um the script is great to do script that automate yourself even better use azure monitor or seem to go through and look through that stuff all right uh next thing here is start getting in front of this with your developers which are going to be your internal developers as well as the external vendors that you're probably working with so we are adding new permissions all of the time to microsoft graph so we want to make sure we're using

least privilege right this is not a new problem i'm sure everybody on this on this call here has had an application that the business unit bought and they're like please install this for us and you look at this thing and it like wants enterprise admin domain admin and scheme admin you're like what in the world is this thing doing i thought this was just like sending mail or something right so developers are going to do this because they just don't know right they they don't know what permissions they need so they're going to be like give me everything just in case right we we don't want them to do that so anytime you see directory star that is not using least

privilege but i think everyone here probably knew that already so we have some links here if you go to akita ms slash graph best practices as well as ak ms identity platform checklist there's some good stuff here for your developers um those that are using teams teams has grown quite a bit uh in the in the last six months go to akms slash rsc teams there's lots of app specific guidance for creating apps in teams but if you have uh another good thing to use here is if you go to ak ms identity developer series it's about a two and a half hour youtube video that goes into how to how to do development with azure id covers like

the libraries you should be using which is you want to use the msal library it covers this permission model to cover some stuff from your developers so you want to make sure your developers take a look at that but you as defenders should also watch this this is really go in-depth in some of the stuff we talked about as well as some other things we didn't even talk about which is like the libraries and things like that that people can be using so go watch that it's really really helpful but again for your um applications you want to make sure they're using least privilege and also when you have third-party isv apps they're going to be using sometimes

those higher permission models i've had several of my customers push back on some third parties and say we're not granting you those permissions that's way too much your app doesn't need that you need to be using lower permissions no different than when someone wants domain admin or enterprise admin you push back same thing for this okay um last thing here if you see an application and it looks suspicious you can report it through mcas or this consent screen as well so that check box right below for an admin there where it says um the thing's still coming through for me but it says does this app look suspicious report it here you click on that you can

report those applications that you think are phishing or suspicious to us and then we will um go take a look at them and take action on them and remove them for everybody and things like that so um if you see something please please say something all right got a few minutes left here so what are our go do's so first go back at a bare minimum run that powershell script look at your applications you have go ahead and you know look for those dangerous permissions look for those high privileged users and set those um the right types of risk-based step up for your things for going forward so you can do that by default um in the wrist space part

but you know those three radio buttons the block everything allow everything or do the middle one go take a look at this make sure everyone agrees on what are those permission models we want to do and make sure we're um understanding what that's going to do in our environment then go explain to people this consent phishing and how the end user can send frameworks and the admin consent frameworks because people don't typically understand that now i didn't we don't want to scare you that like this consent phishing is a humongous problem that everyone's getting hit with and we should go stop everything we're doing and take care of this that's not the case the most common attacks we see

are password spray where people have an easily guessable password using legacy authentication protocols people have reused their password like that stuff is still the um most common the traditional phishing are the most common things that we see still from an identity attack perspective but this is something that's emerging if we want to make sure people are aware of this and we want to make sure those incident response plans we have um take this into account because it's not just as easy as just deleting the application gotta go look to see what it did and what types of permissions it had in our environment then we want to make sure we go ahead and educate our developers on the best

practices around using least privilege um so we have some links for you there and here i'll paste this right now in the chat here is a link to all the slides that michael and i just covered today and then lastly here we have some other resources for you um that we couldn't talk about that we just ran out of time because we could do a whole day on our day there's lots and lots of good stuff here but here is some the consent framework here's how you can investigate consent grants manually we have some links to some security steps here so lots of good stuff here that we're just putting here in the resources that you guys can take a look

at um after the talk and with that we have about i don't know five or ten minutes left for any questions we've been trying to keep an eye on the chat as we go but um um we'll be watching discord um this is me on twitter i'm matt mark morrow michael happening there's someone impersonating him so he's underscore michael apping um we can fix that okay so the link requires a login let me fix that real quick while michael if you're able to watch any of the questions that come in let me fix that right now the one question i see is is there a way to implement a review process where an admin tier 2 engineer will review and a

configuration manager to approve which i think is a good question uh so if i'm reading the question correctly i think what you would want is for the engineer to review the permissions and then make recommendations so your tier two engineers like if they have help desk permissions or things like that they should be able to run the script um they won't have permissions to go like admin consent to things or revoke permissions but they can execute the script and review what is in it so nothing stopping you from implementing a process where like your tier 2 engineers might run the script do some analysis you can delegate permissions to them like view permissions to them in mcas if

you have if you're using mcas as your cosby solution um so you can do things like that to give them the ability to investigate and then make recommendations to someone who's got uh you know the higher powers to go actually make modifications all right i just updated that link so hopefully now you can get to the slide deck um maybe give another minute or two but you should be all set let me check discord here no questions over there

yep i haven't seen any other questions and someone can give us an act that the link works now um when you try it that's that'd be helpful it should be good okay works for them okay cool

all right cool thank you thank you so much michael and mark that's a great talk