Modern Identity Providers Under Attack: Tactics, Techniques, and Mitigations | Anurag Khanna

Yep. Okay, this works. Hey everyone, morning. Uh, thanks for showing up. Uh, this is modern identity providers under attack. Uh, my name is Anurra. I work for a company called Crowd Strike. Now you know where the team's comment comes from. Uh, I do instant response for them. So uh you like the product, you have some issues. I'm not your guy. I do incident response. I work with organizations when they are under attack, they are being breached. Uh I have a team of consultants working across Asia-Pacific getting into situations where thread actors have access to environments both e-crime and nation state threat actors. Uh and that's what I do. I also teach for an organization called SANS teaching

their incident handling course. Uh, I moved to Australia a few years ago. I'm still picking up the Australian accent. I don't know if I'll be able to do that or not. Still working on that. Uh, but I also like to talk fast. So, if you're thinking I'm talking fast, you want me to slow down, just let me know. Uh, these slides are a lot texty. There's a lot of text here. And whenever I show this slide to anyone for a review or feedback, I'm told remove all this text. You don't need it. This is a reference deck. The same deck is available at that link. Maybe you don't think you need it now. Maybe later you'll think that you

need those uh slides. So don't read the stuff on the slides. That's the reference stuff. You can take that with you. Keep that. Use that. If you have to stay with me and we're going to go through this pretty quickly. Uh I have what 65 slides 35 40 minutes. So I'll go click click click happy at times. Just stay with me and we'll be okay. Okay. Okay, these views are on my own. Uh, as I said, I work for Crowd Strike. I'm very fortunate to have a position where I see a lot of different very interesting attacks. A lot of this comes from that. Uh, but these are my own views. Uh, my company may not or may not

agree with those views. So, let's get going. Uh, I do a lot of active directory stuff. Uh, I used to talk about a lot of active directory, but last few years I realized thread actors have moved on. They still attack Active Directory. Still a very effective technique to track to attack Active Directory. Uh but what thus are now doing more and more is targeting new modern identity providers. Now we're talking about stuff like Entra ID, AWS has one, octa, a lot of these new service providers who tend to provide lot more secure identity systems are being targeted. A lot of nation state threat actors do that and also a few e-rime threat actors do that notably

scattered spider. They started this trend of targeting a lot of these new modern identity providers. And if you go back and start doing some research you'll realize a lot of nation state threat actors from Russia from China and some other countries they do target identity providers a lot. That's where this slide tech comes from. That's the point of uh view which I have and that's the perspective uh this talk brings in. Now these are some of the ways how thus get initial access and you would have heard about this a lot. Password spraying, password guessing, credential stuffing. These are very common ways of how thus get in. You would think everyone has MFA. I I'm

sorry to say this but that's not true. A lot of investigations which we do they tend back to the initial excess which is single factor authentication VPN due to multiple various different reasons. I'm not going to talk about this stuff here. We know this stuff. I want to talk about something more modern, more newer, something a little bit more complex at times. We're going to talk about the newer protocols or widely used protocols and how they can be broken, how they are attacked, some other ways authors target both intra ID and other identity providers. So that's the stuff we're going to talk about. We're going to talk about conditional access, SAML, OOTH, trusted relationship, cross tenant sync,

and a lot of these different things that have been in news very recently for a lot of big breaches or a lot of famous breaches that have happened. Let's talk about conditional access policy. Conditional access policy is a Microsoft way of implementing a security control where some conditions need to be met before you can log in. Now these conditions should be you should be coming from a specific IP address. You need to provide a multiffactor authentication. You need to be coming from a specific computer system or a user agent. So all those conditions when are met that's when a user can log in. This is a key security control in entra ID and other similar

identity solutions also implement such controls. Thread actors have figured out ways to bypass these controls. How do they do that? I'm going to pick up some of the common things which we see thread actors abuse or leverage while targeting or bypassing conditional excess policies. One common thing which happens is there are often gaps in conditional excess policies. They could be for different reasons. We often see some administrators not come under cap because the organization is scared that there will be account lockout that will happen and at sometimes they lose access to enter ID and they'll not be able to administer it. So those accounts sometimes exist. These are sometimes break glass accounts. Sometimes just an

administrator thinks they are smart enough to not use an MFA. Then there is legacy authentication protocols that may not support multiffactor authentication and hence they have to be excluded. Sometimes some devices do not support that. So they have to be excluded. All these things is something which the threadctors bypass. I worked on several instances where there was only one account which didn't have MFA and that was the account the threadctor used to come in. It's a very common thing which we see across a lot of incidents. Another common things which thing which a lot of organizations do and here is a balance between usability and security the old debate where they say this IP address or an

range of IP address is what we trust often this is the office IP addresses so when a user is coming from an office IP address they don't have to pro provide a multiffactor og for a new MFA essentially the policies are different if you're coming from a trusted IP Thread actors figure this out and sometimes they come through those IP addresses. Maybe first they get in an organization's on-prem systems and then target the identity provider. In other circumstances, when they already have access to the environment and now they want to maintain persistence and make sure they don't lose access, they add their own IP addresses as trusted IP addresses. which means now everyone else need to needs to provide an MFA but when

a thread actor is coming from their own IP address they don't. So that's another way how this is abused. Another thing to keep note of is conditional access policies are typically applied only at the time of sign in. So when I'm trying to sign in conditional access policies get applied and things are checked. I have to provide a multiffactor o. I should be coming from a specific region. I should be using a specific system. All those things come into picture. Once the token has been issued, the session ID, the cookie, whatever you call it, has been issued, the token now contains the information. And now you do not have to adhere to or have to follow

the condition access policies. So a lot of times thus will figure out ways of stealing tokens that have been legitimately issued to users and use those to then access modern identity providers. I'm going to have some recommendations on how do you detect this stuff? How do you respond to this stuff? I'm not going to talk a lot about this just because of the the limited time we have. But these are the some of the things you can do. Strongly recommend that there are no trusted locations that are configured in Entra ID or similar identity providers. uh that will force the users to provide MFA even if they are coming from the office but that's the the cost of having

a secure system. Now we're going to talk about SAML security assertion markup language or SAML is very often used in how authentication happens using these modern identity providers. These are SL tokens that are issued and these SL tokens and then are trusted. They contain information about the user and then they can be used to login or to authenticate a user. This is how a SL authentication flow works. A user is trying to login into what we call a relying party. A relying party could be Microsoft 365. It could be Slack. It could be an application which the user is trying to log into. When the user tries to go to the relying party, relying party says you need to

authenticate. But you know what? You don't need to authenticate to me because my authentication happens through an identity provider to which I trust. So there's a trust between the relying party and the identity provider. The user goes to the identity provider provides a valid username and password. The key to note here is the user is providing the credentials to the identity provider not to the relying party and the identity provider issues a token. This token is then presented to the relying party. And since the relying party trusts the identity provider, it trusts the token. It says, "Yep, you have logged in. Please log in." Now, we're going to make it more complex. This is how it looks like. I again have

three parties. I have a user a user here I have a relying party identity provider there's a trust between the relying party and the identity provider the user accesses the relying party as last time the relying party tells the user you know what you need to go to the identity provider and login there so the user provides the credentials to that identity provider identity provider signs a token using a certificate or a key which it has a token signing certificate. It issues that token that token goes back to the user and the user then provides that token to the relying party which the relying party trusts. This happens when there is a there is one identity provider.

This can be a multi-step process where now I can have another identity provider which is known as chained SL authentication. What I'm doing now here is I had one identity provider and there is a federation trust between the relying party and the identity provider IDP. I'm adding another identity provider in the m mix. Now what happens the relying party says you know user you have to go to this identity provider but this identity provider says you know what user you have to go to another identity provider. Think of this in a situation where you're trying to log into say a Slack or an M365. You are redirected to an entra ID. Entra ID says you know what I don't

have the information. You have to go to your on-prem active directory in ADFS system. Provide your credentials there and then the token gets issued at the delegated IDP. Now let's talk about how this is abused. This is the again the chain authentication normal flow that we talked about this I'm not going to go through this this is a multi-step approach now we have where we have two IDPs one IDP is delegating to another identity provider the entire thing this entire sample flow which we have been talking about relies on those tokens that are being issued and the fact that only the identity provider can issue a valid token That's the entire flow is based on that

assumption. So if someone can break that trust of who can sign that token which is being issued using a private key which only that entry provider has this entire thing can break. That's what happens in a lot of different attacks that target SML. The relying party I'm going to go a slide back here. the relying party which is in this case say a slack or in this in this case the primary IDP because the primary IDP is now relying on the delegated IDP. What they care about is that they receive a valid token that is signed by the private signing key or the token signing certificate of the identity provider. How do they validate it's right or valid? Because they have

the public key of that part. They just open it up if they can. they know it's a valid token. So this entire system relies on the fact that those keys are not known to anyone else. They are confidential. Only the IDP or identity provider knows that. If a thread actor can figure out a way of forging those tokens, they can break this entire trust and break this entire authentication. That can happen in multiple ways. One way that happens is what is known as the golden SL attack. This one is very famous infamous what came out four or five years ago and has been used by a lot of different threads notably in the breach that happens in solar winds four

or five years ago and after that it became like a thing which thread actor started doing in a golden sill attack what happens is a thread actor this is our thread actor here they target the identity provider let's say ADFS server is my delegated identity provider in this is they target the delegated identity provider and somehow they are able to steal the token signing key or the token signing certificate. Once they have stolen that certificate, they can now forge their own tokens. So what this does is now offline offsite in my home bakery I create a token because I have the token signing certificate which I have stolen from the identity provider. Once I've done that, I can just relay

that token back to the relying party. This relying party could be another identity provider or it could be the relying party itself depending on how the trusts have been set. If I can do that, I can login into the relying party or into the IDP in this case. So the entire thing breaks. Another way how this can be done is by adding federation trusts. Remember this one going few slides back. We had a user, a relying party, a primary IDP and delegated IDP. A system administrator configured the delegated IDP. What if an attacker who got access into your environment, they configure their own delegated IDP? So in this case what happens is a thread actor

who already has access to the environment they go in and they change the configuration to add their identity provider as a delegated IDP. You would think the thread actor will have to set up infrastructure and set up an ADFS or another identity platform. They don't. They just need the certificate and now there is a trust to an external party which is federation trust which they have configured and they have the private key. They have everything they need to start logging in and authenticating into these systems. This is very similar to the golden ticket attack. We just talked about the golden SL attack. The fact here is that the thread actor has added their own federation settings into the identity

provider. This is how it looks like now. The thread actor has changed. This is the same one. This is how it looks like. The thread actor has added their malicious configuration of their IDP into the identity provider, the relying party. And now the thread actor has the private key of that certificate. They can forge those certificates and start relaying those certificates and start accessing this information. Uh this happens very often in entry id environments because it's typically easy to set up these federations. Once you are in entra ID, you have the privileges you need. You can just go in and set up that federation. And once you have that set, you can start accessing the environment.

What user can you be? You can be any user. You can be the administrator. You can be a normal user. You can be finance user. whatever you want because now you hold the information that you can use to create a token as any user in the environment. So this is another way of breaking SL or attacking SL. How do you detect this stuff? The first part which was the golden SL attack. It is kind of difficult to detect because you don't know if you have been breached, your configuration has been stolen by a thread actor. So if you see loginins happening into your relying party and you figure out you are not issuing those tokens that's one way

to do that which is easier said than done. The second attack which you talked about where federation configuration was added. What organizations need to do is look through those federation configurations and look for any changes that are happening in that environment. If they see any changes that are happening in the environment that's when they know that malicious stuff is happening and they need to be careful about it. There are some audit logs that can be reviewed in entry ID to see some of the stuff the federation configurations being added. So this is SAML. We talked about how SML can be broken. We're now going to talk about OOTH. OOTH is another very commonly used protocol and

has been in use of late with a lot of different SAS service providers being targeted. Let's talk about OOTH. Oth is for authorization and there's a layer over oath called OIDC or open ID connect which does the authentication. Sometimes you see that box where sign in using Google you use that and you're logged in. That's where OIDC is coming into picture. What oath is used for is a third party getting access to your information. Let's say you want Slack to have some access to information or you're using a app and you want that app to access your Google information. That's where oath comes into picture where now apps have access to different information. When OOTH is being used or OIDC is being

used a flow the flow looks something like this. A normal user a valid user goes to the identity provider and they provide their user information. The IDP creates what we call a jot a JSON web token. The token is signed with a private key. Private key of the identity provider. We again talking about federation trusts here. That jot is then sent back to the user and the user takes that signed jot sends it to the application. The application validates that if the jot is valid the access is granted. A very simple flow and you would have guessed how this is broken or how this is attacked. This is how a JWT looks like. There's a header,

there's a payload and a signature. I'm more interested in the signature part of it because if I can forge the signature, I can make a party trust me and then I can get access to information which probably I should not have. So again the trust is the problem here. The entire system rests on the integrity of the private key that is being used to create those jot tokens. As you would have guessed, these jaw tokens can be forged. A very famous attack happened a couple of years ago where a thread actor Chinese nation street thread actor figured out a way of forging these jot tokens and accessing Microsoft 365 emails. Uh this was a very famous one.

There was a report that came out from the CSRB, the cyber safety review board. I do recommend you look at it if you are interested in this sort of stuff. In this case, what happened? a consumer level signing key was stolen and it was incorrectly being used to validate tokens that were issued for enterprise emails and that was a misconfiguration or vulnerability but under the hood what happened here was a key that was being used to sign those J tokens was stolen from Microsoft environment no one knows how if you know let me know the the report goes into details of possibilities but it never comes to a conclusion So there was never a public blog which

said this is how the key was stolen or we know what happened here. But what happened was someone figured out the key or stole the key a Chinese nation street actor and started using that to access emails emails across Microsoft 365 platform for a lot of different enterprises. This is how the attack looked like. Now the thoractor has stolen a key which they're now using to forge oath tokens and they are relaying those forge tokens to a party and accessing that. In the specific case we are talking about it was Microsoft 365 email infrastructure. Does anyone know how this was detected by Microsoft? It was not detected by Microsoft. Let me just rephrase my question. Does anyone

know how it was detected? It was detected by an analyst like you and me sitting in an office. They wrote a rule. The rule was called the big yellow taxi. It was looking for anomalous activity in their Microsoft 365 environments and they figured out someone logging in using a token which should not have happened and that's how this entire attack was detected which then became a big incident. A lot of organizations had been impacted. So this is forge jot tokens. It is also very difficult to detect such kind of attacks. Let's talk about trusted relationship compromises. A a similar concept was supply chain attacks uh which has been talked a lot that is kind of has now

changed into or taken shape of what we are now calling trusted relationship compromises. It has a wider scope than just supply chain attacks. Let's talk about some this some of these trusty relationship compromises. What we are talking about here are pre-existing trusts between organizations and that trust could happen multiple different ways. We're going to talk about some of these attackers target those trusts because you trust a partner, you trust a party because of a relationship and now the threat can target the party itself or figure out a way of targeting the end system or the the target because of that relationship. So let's talk about that. We're going to talk again about OOTH applications. OOTH application is something that uses

OOTH2.0 framework to access information. Think about a third party calendar app which you are connecting to say a Google calendar. Think about a Slack bot that needs access to your workspace in Slack. All those are examples of how applications work. O application is registered application. We're going to talk about entra ID but do remember this happens in a lot of different platforms uh like Salesforce. There has been some news about that recently. The way this happens is there is something known as an application registration. I'm taking the Azure example here but very similar concepts exist in a different different identity providers and different applications and different SAS providers. What we have here is what we call an application

registration. App registration exists in the parent tenant. What do I mean by parent tenant? If I'm a company and I'm providing a app, I created an app and I'm going to give that app to users or sell that to different users. My tenant is the parent tenant. What app registrations do is it's a global quit, a globally unique ID of the application that is going to be used as a framework across all the tenants where that application is going to get used. This is typically only one in the parent tenant. What it does need is it needs an identity to work with. That identity is called service principle. So we have two things here. We have app registrations

which is like a framework of what the app can do. And then we have a service principle which is an identity that is going to be used to access information. These are called service principles. The identity is called service principle. Service principle is a local representation of the application. It exists in the parent tenant as well as all the different tenants where that application is going to get registered. I with a friend create wrote this paper back in 2021 long time ago. I've been doing this for a while. I talked about Azure applications and how this can be breached and no one gave attention to this. That's probably my best work and no one talks about it. No one looked at

that and I was like yeah this is not good. Anyways 5 years down the line exactly the same attack happens. I'm not saying others didn't talk about it, but that's how the security community works. And once a big attack that happened using that, now we see a lot of different attackers pick up that TTP and use that TTP to attack a lot of organizations. So this has kind of become a theme. So we have going back, we have Azure applications and service principles and as I said not only an entra ID thing, Salesforce is another example which I put here. A lot of other organizations use similar concepts where there's an app registration in the parent tenant

and service principles in all the tenant where the app is going to get used. This is how it looks like. Again, there's an app registration in the home tenant. There's a service principle also. This app registration then has a reference from the service principles that exist exist in consumer tenants. So I have an application which I want to sell or provide as a service. So I create that application in my home tenant. Everyone else is now going to register that app. You would have seen that oath registration of the app and once they have registered that app there are service principles in their tenants which then refer the application registration which I have done. These

service principles have access to information. What information that depends on what kind of permissions are provided to the service principles. What kind of attacks can happen here? A thread actor can steal the application secrets from the app registration. So if a thread actor can figure out a way to target the company that created that app and there were secrets that they were able to steal, secrets that were able to that were registered with their application registration. What can they do? You would think they could only access the home tenant. It turns out they can access any of the tenants where that app is implemented. So if I have an application which has been deployed in 5,000 other tenants,

these application secrets if stolen can be used to access all those 5,000 tenants. So the attack surface is very wide, very big. What kind of access would the thread actor have? Thread actor would have the exact same access as the service principle. A lot of these applications have very widespread permissions in tenants. They can read all the emails. They can read calendars. They can download data, access data, all that stuff. Now the threector can do and they don't have to go back to the home tenant. They can start directly accessing the consumer tenants here. So the attack surface is very wide. Uh there's a blog that recently came out in August 21 about Murky Panda, a nation

street protector, Chinese nation street protector which was targeting a specific company and this became a very widespread news in last 6 months. So have a look at that if you are interested in this kind of stuff. Another attack which do is they can add their own application or service principle secret. So if they can get into an organization into a tenant either they can create a service principle their own special service principle call it exchange or something which is easy to easy on the eyes of administrators and add their own secrets and then start accessing the environment. or if there's an existing existing service principle they can add their own secrets and then use that to

access the environments. This is another way of doing another way of maintaining persistence. So adding service principle secrets or creating a new service principle both of these attacks are very common. They work very well. A lot of thuctors do that especially the moment they gain access to an environment they do something like this so that at a later stage they can come back uh and access the environment. They don't have to use a user now. They don't have to do multiffactor authentication. All those things just go away. They can directly access the environment. How do you protect against these? Protect your application credentials. That's a big one. Especially if you are a SAS or you create such applications

and sell it out or provide it to users. It is very important that those application credentials are safe, secure and a thread actor cannot access it. Then there are things like least privilege. Don't allow an application to read your emails because when that happens, bad stuff happens. Monitor for any new secrets getting added. You can do hunting. Enumerate all the applications registrations. Enumerate all the service principles. Do you even need those? Do they need do they need the kind of permissions they have? Are there multiple secrets configured? Do they need those? So all those things are something which you can hunt for in an environment. The last one is how you can detect this stuff. If a thread actor has created

service principles or have stolen information and now they're coming into your environment, you can look for login coming from unknown IP addresses or something you don't expect and that's how these attacks are detected. It is not easy to detect this kind of stuff. My recommendation always is not get hacked rather than get into detection. I know it's not a great recommendation but some of these attacks are like that. Okay, let's talk about a bit about delegated admin permissions. Delegated admin per permissions are a feature from Microsoft where someone can be added provided a DAP role. These DAP roles are typically provided to Microsoft cloud solution partner where a cloud solution partner is helping an organization to

set up their environment. Uh they can remotely manage the environment. They used to have admin permission like full admin permission and Microsoft has now moved to what they call granular delegated admin privileges gab still they are privilege access into an environment in this case what's happening if you have used a CSP or you have any relationship with a CSP a Microsoft service provider they may have access into your environment because they helped you set it up they resold it a lot of those things and then they can access the environment because of that DAP relationship their user account doesn't show up in your entry ID which means they have access to your environment they just

don't show up in that list when you are hunting for that information and seeing what users are configured do they have secure passwords do they have MFA you're not looking at those DAP accounts which have access to your environment what can a thread actor do the threadctor can target the CSP the moment they target a CSP a CSP may have access into a large number of environments because of they being a CSP and now the threedector can access multiple of these tenants which have the DAP access or DAP relationship. This is how the attack looks like. Thread actor figures out a way of targeting the CSP partner tenant. Once they have access to the CSP partner

tenant, they start accessing the consumer tenants through this relationship, the DAP relationship. And once they are in the consumer tenant then they can go for adding their applications adding their service principles and directly gaining access to the environment. Again you would appreciate that the attack surface here is also very wide. Another attack which I thought of I discussed with a few friends. It seems like it could work but I have not seen this in the wild. Likely it has not happened in the wild is a thread actor creates their own CSP and say this is my tenant. I'm a CSP and then once they have access into a victim tenant they start adding DAP relationships with

their their tenant and that way they can have access into a lot of environments continued access. This is a persistence method. likely this has not happened because Microsoft does have certain controls in place on who can be a CSP. So it can only happen with a CSP account and Microsoft has controls in place so who can be provided a CSP account. What can happen is if I have access into an existing CSP and I have access to another tenant I can then go into that tenant and add that relationship to the CSP tenant which I have access to. So kind of a trusted relationship attack which we were talking about. This works because a trusted party here a CSP can

access multiple tenants often with privileges and they can use this method of attack target a large bunch of tenants. How can you reject it? Look at the configurations. Remove DAP relationships if you don't need. A lot of organizations don't need that. They just exist because you don't touch stuff. It works right. Another way of how thoractors are abusing this stuff is what we call cross tenant synchronization abuse where there's a source tenant. Again, this is a feature from Entra ID where you have a source tenant and a target tenant and once cross tenant synchronization is configured, you can push accounts from the source tenant into the target tenant. So what a threadctor can do is

if a threadctor has access to a source tenant and there's an existing CTS relationship they can push some of these accounts into the victim tenant and now they have access to the victim tenant. They can create their own account and push that or any accounts existing accounts they have they can push those also. The same trust can be used to backdoor a victim tenant also. In this case, an attacker gains access to the target tenant, not the attacker tenant. In this case, they already have access into the victim tenant. And now they are configuring a CTS policy where they are saying, "Yep, this attacker tenant, which I have access to, can synchronize users into this target tenant at will

whenever they want." Again, a persistence method if a thread actor already has access to into a intra ID platform. Let's talk about tap temporary excess passwords. I think I'm going into the coffee break. I'll try to move fast. So tap uh tab is a time limited password often used in enter ID if because you want the initial registration to happen and you don't want to provide a username and password. You have no way of doing that. So you just send a tap link. The user clicks on that, they get in.