Threats Against Cloud Application Identities And What You Should Do About Them

okay thanks everyone uh for uh kind of sitting about and you know waiting for the beer and listening to me and so i'm here to talk to you about emerging threats against cloud application identity so this is very specific to non-human identities and kind of what what you can actually do about them so we can protect them in some way shape or form a quick intro so yeah my name is johanna i'm a senior product manager in the identity and network access engineering division i specialize in identity threat signaling hence we see a lot of the cloud application identities being attacked okay really quickly we'll go through um threats that we are seeing so i can go

through some attack paths that we that we see quite commonly uh against these non-human identities um how to detect uh contain mitigate and remediate and also some best practice on on how to protect these okay so cloud application identities have many many different names so we call them workload identities they can be service principles they can be application identities they can be up registrations all of these different names they all mean the same thing so what we're focusing on today is i'm sure you know there's lots of identities in this space we've got our human identities which are assigned to a human and then machine identities you see we've got devices iot but we've also

got what we're talking about today which is our workloads and app services so where are these used so this is a very very standard oauth 2 client credential flow this is a grant type so it's commonly used for server to server interaction so it integrate services from a server to a api for example this is just a web service needing uh you know directory data most importantly there's absolutely no human identity involved at all with this process why are we actually talking about this so unfortunately there has been a significant increase in the number of application identities being attacked 85 of all identities across public cloud are non-human so the attack surface is quite large

so this is what we are seeing we are seeing 34 of organizations have already suffered a security incident by a malicious application that's quite a lot and it's growing significantly every month uh we've had 26 million user logon credentials actually stolen through malicious apps that's 26 million accounts that have unfortunately been compromised we've got 600 plus malware infected sites that we are identifying every single week and then 74 organizations are completely unaware of the number of digital keys and certificates that they actually have for their application identities if you don't know they're there you normally can't protect them and 48 of compromised instances attributed to no password or weak passwords for user accounts or more significantly api

connections so this is why there is such a problem and so there's a number of different kind of buckets we put these attacks into so we've got um what we call a compromised application identity so this is a legitimate application that has been compromised normally what happens is an attacker adds a credential to this already functioning application that is normally over privileged we then have malicious applications so malicious applications are just as kind of it says on the tin this is an application that is purely for malicious intent it serves absolutely no other purpose within a tenant or environment and then unfortunately we still have a lot of misconfigured applications within environment this also includes putting

your credentials in public github again not something that we would advise um and even putting the wrong uri so actually your data goes to the wrong place is common so these are just some attack graphs so these are kind of what the the typical attack graph that we see for each of these so we've got a compromised app so this is normally starts off with some kind of compromised admin account so this can be uh for you know talking about um azure ad kind of side of things can be a cloud application uh privilege or a global admin the account is then impersonated great they now put a credential on your application they then impersonate the application

which cause an api the api nine times out of ten what we see is absolutely over privileged i cannot express that enough something doesn't need directory read write all don't give it read write all okay so this is for a malicious application as i said this is an application that serves absolutely no other purpose but to be malicious so it this normally starts off with a phishing email uh and then the user can sense to an app so we do have uh the concept of consent based attacks this is where a user clicks on a button and says yes attacker you can access all my emails and impersonate me as a user that's where it goes on to impersonate a

user it's also used to phish other users so you'll see in the next slide which was a real world example of what we saw actually they sent emails out as that user that they that they compromised because the permission the user gave was yes you can send as me it then uses all the api calls that that uses giving them access to and this is one that we saw so this was actually during the pandemic and the attackers were sending a covert 19 bonus spreadsheets who didn't want to open that the user then selected it looked like an excel spreadsheet looked pretty pretty standard and but then when they clicked on it actually it was requesting permissions

but what the attacker did is they made it look like office 365. so the user was like oh well you know that's definitely something we've got it's fine i can click on this it's safe and so what they did is they ended up actually giving permissions to all of these things on the side here so as you can see read your mail read all your onenote read and write to your mailbox settings so they actually ended up putting um a forward on to the mailbox so they could exfiltrate all of the emails um yeah and have full access to all your files as well so this attacker got quite lucky the user selected accept the attacker has now got

a malicious application that is registered within that tenant and can just exfoliate this data thank you okay so this is a misconfigured app this is normally leaked credentials so we do have a service where we scan a public github and day davey turned that on we had to notify three thousand tenants that they had valid credentials so this is quite a big problem um we do alert on it uh some action is sometimes taken some companies ignore us uh so yeah they discover leak credentials impersonate the application we do see a lot of enumeration uh directory enumeration uh with this method and then they start calling the apis that they've got permissions to through delete credentials

i understand this is a bit noisy but this is um one of our kind of very regular attack vectors and this is what they do and as you can see here the on the application side this is very very much in their playbook to go after and make sure they attack non-human identities so what you can kind of see here um is it's als most of them still start off with on-prem kind of some kind of compromise there they do do password sprays directly to admin accounts in the cloud uh you know still less than 50 percent of global admins have mfa so it still works and it's cheap which is why it's done they sometimes do quite sophisticated uh

models like attacking on-premise some idps if anyone wants to know more about how they do that i can talk about that after this but the whole purpose of this is to either get a credential to a privileged account normally a global admin or as i say a cloud application admin and once they do that then they move across they either add a credential to an existing application or what they do is they create an application within the tenant and then they consent as admin they have global admin you've lost trust in your tenant they can consent to directory read write all and so what they do is they give themselves permissions it's normally mail so mail.read write or

the reason why they do this is because there's actually a lot of functionality that they can do with that permission even when you've deleted the application so you can find a malicious application in your tenant you can find a credential that shouldn't be there delete it but they've actually got persistence and the way they've got this is like i said just before is adding a mail mailbox forward you can delete that application the mailbox rule is still there and it still functions we've seen this numerous times where data is being leaked they've deleted a malicious application then they wonder why data is still getting leaked and we find out that they've actually gained persistence and

this is one of the reasons why it's so popular at the moment but not all is lost you can detect a lot of these behaviors that attackers are doing so some really simple ones signing in audit logs your location where they're coming in from what are your applications doing frequency most applications actually have very predictable steps they're calling a specific api they're calling it regularly they're calling it you know six o'clock every night it tends to be quite repetitive and your credential type as well when anything is being added to an application if it shouldn't be being added at that time there's no change of question for it you might want to start looking as to

who added it the user agent so anything unexpected on there the resource if it's constantly accessing group.read and then all of a sudden it starts accessing something completely different that it's not normally accessing you might want to just have a quick look permissions does the identity need these permissions as a stated directory rewrite all is a very easy solution to get an application working but it's actually uh very very damaging as well there's also things like automated threat detection so we've got like defender for cloud apps for example there's lots of vendors that kind of do that looking for some anomalous detections within within the the silence and also secret scanning there's a state we do secret scanning in

uh public github you can actually build your own tools uh to to kind of scan your repositories as well if you need to but if you do find something obviously please do follow the you know instant response basics just stay calm involve your legal team because if it's a non-human identity most likely it is a loss of data that is happening be careful when sharing information publicly i think that goes with kind of anything and and get help when needed uh you're not on your own when it's an incident and so when we kind of uh started seeing a lot of these we noticed that there's a gap a lot of sock teams don't know what

to do or they don't have any guidance on what to do when they see this kind of attack happening so we have created some incident response playbooks it's in a flow kind of scenario here and it does it is for azure ad but it can be applied to kind of any any application technology that you've got and so what it goes through is an incident uh investigation process goes into whether the app's malicious or compromise because it's a bit of a different um method to recovery containment and assessing business impact and also the recovery process as well please make sure you have a process for non-human identity compromise we see it a lot where there's a user one

but actually there's nothing for non-human identities and so what do you do when you find this so there is some containment in recovery that can be done so if it's compromised um you know this is a business application that is already in use by your organization credential rotation this does have downtime so it's really important to make sure that your business knows that that is going to go down it can lead to significant amounts of money loss which is why it might need to start telling your business owners most likely an admin account has been compromised uh with this kind of attack so it's starting to make to look at well who had who added that credential is

that account compromise how did that get compromise are there any other accounts that are compromised so you start kind of going off into the uh you know you may have lost trust within your tenant kind of scenario and then as i've stated please do search for persistence uh it's really really important just deleting the credential and deleting the app unfortunately is not enough and then if you spot a malicious app it's a little bit easier because you can just uh disable it or delete it completely it's malicious it doesn't need to be there it shouldn't be there again search for your persistence but then again look at who added the application and most importantly who

also did the consent for that application and if it's misconfigured rotate the keys and please reconfigure correctly we do have some best practice as well so um you know these are good kind of security principles so use strong credentials we do recommend using certificates above keys in this in in the application scenarios uh useless privilege as of i've stated uh good life cycle management we do see attackers going after applications that are currently not really being used uh so they they do deliberately attack these ones please identify your app owners nothing worse than being an incident and you have no idea who to contact especially if it's business critical restrict and monitor your consent settings so users it is okay for users

to allow consent for some things reader profile is fine a user can consent to that there's no no reason to block that but just have a look at the consent settings and making sure they're appropriate make sure you are monitoring your application permissions as well and monitor for anomalies that are happening within these non-human identities okay most important slide some go do's so please start monitoring it is not good enough just to um download logs you need to actively be monitoring those logs looking for anomalies within them we do have guidance on that in our secops guide for for uh non-human identities so that's what you can look at instill best practice across your workload identities this is very much

for developers as well developers need to understand least privilege just as much as the admins do create your incident response plan for workload identity compromise as i say we do hit a lot of problems where yes they've got them for users but when it comes to non-human identities uh yeah the sock teams are a little bit stuck and yeah please make sure you audit apps and consent permissions within your tenants um we have a script here that can do it for you um i'm sure there's other vendors who can do the same but yeah please please make sure that you do that on a regular basis and thank you very much [Applause]

thanks really good talk i was interested with the the obviously their non-human identity so if something happens um you're saying for example deleting the app might not be enough you know with that persistence what's been the sort of the average i guess threat of opportunity people have had you know days months et cetera et cetera yeah we've i mean we've seen years we you know it's it's there a lot in in they only kind of we've seen a lot of kind of customers unfortunately only realize where they see data being leaked now data can be leaked out of a tenant but never used for years and years the only you're seeing attackers you only use it when they actually need to

and so we have had i think the longest i've had is 14 months that they'd been pulling data out but no one knew how did they eventually realize then after that sort of 40 months period it was um a compete scenario that they were buying another company with and their finances were leaked

on the on the slider you had for um the uh number of incidents and all of that near the beginning is that across all cloud or was that specifically for like azure uh so it was a mixture so that came from the microsoft defense report but also the google cyber report as well okay thank you

all right thank you very much