Modern Identity Providers Under Attack: Tactics, Techniques, Detections and Mitigations

If you can please welcome Anna Rag Kana with modern identity providers under attack. >> Thanks everyone. That's a lot of people and I'm sure you had a choice to either sit here and watch me talk about identity providers or go to a bar or a pub with mates. For me, the choice was easy. I had to be here. I didn't have an option. For you guys, you had a choice and you chose this. So heads off to everyone who's sitting here. Uh this probably is not going to take 55 minutes. I am sure people want to go out, get some drinks, chill out, have a chat. Uh let's see how this goes. I'm going to talk about

identity providers. I'm going to talk about modern identity providers, things like Octa, AWS, the big one, the elephant in the room, Entra ID. Maybe talk about a couple of others. As you would expect, I'm going to focus on Entra ID because that's Microsoft. I love Microsoft. They do a lot of good work. And that's not because other identity providers do not have the same issues. It's primarily because Entra ID is the most commonly used identity provider in enterprises. So that's how we're going to talk about and go through this. A bit about me. I work for a company called Crowd Strike. Uh I used to ask everyone, have you heard of Crowd Strike? I stopped asking that since last year

July. I don't have to do that and I don't happen I don't know what happened in July. I have no memory of that entire month. Uh I also teach for an organization called SANS. Uh picked up some certifications while uh through the journey and these talk slides are available on that link. So you don't have to take notes, you don't have to take pictures. They're already up there if you want it. maybe decide that after the talk is done and you can download it from there. Okay, let's get going. Oops. The disclaimer first. My company may or may not agree with what I'm going to talk about. Uh this is all my work. Most of this is publicly available in

different places. Uh I'm not dropping a zero day. I don't have to. Protectors don't use zero days like they do but they don't have to most of the times. uh most of the times they're just using what is already available to them in how systems work and that's what we're going to talk about. Almost everything I'm going to talk about is not a vulnerability, it's a feature. At least Microsoft wants you to believe that. Uh we're not going to talk about how exploits are written and how zero days are dropped out. We're going to talk about living of the land techniques. How do thread actors abuse what's already available to them? So my company may or may not agree to this

stuff. Let's get moving. How do thus get access to modern identity providers? The good old stuff. Password spraying, password guessing, credential stuffing, MFA fatigue attacks. That was very common. Uh it is still very common. It still gets people uh threat actors through into an identity provider. But you're sitting here and you're thinking that's not what I'm here for, mate. That's not what I left my drinks on the table and came here and listening you talk about this stuff. Give me something new. That's what we're going to do. We're going to talk about new stuff, novel techniques, things that are not that common but are becoming very common. We're going to talk about conditional access policies. I'm sure

everyone uses them. I love them. They kind of work. We're going to talk about SL authentication. Uh that's the bedrock of how most of the authentication works these days. Then we're going to look at oath trusted relationship. We used to call it supply chain attacks. Trusted relationship maybe sounds more interesting, more newer. We'll talk about that. Talk a bit about cross tenant attacks and abusing what we call temporary excess passes. Uh I do incident response for crowd strike where I run a team of incident response consultants across Australia, Singapore, India. Uh work very closely with my global counterparts. So I'm very fortunate to have a vantage point which gives me visibility into what are thus

doing. A lot of this stuff is what thus are doing right as we speak and talk. A lot of sophisticated nation state thus are doing it and also what I like calling advanced e-crime threat because it sounds cooler that way. They are doing the same stuff, the same attacks. So that's what we're going to talk about. Okay, let's talk about conditional access policies. Conditional access policies are Microsoft Enter ID's way of making sure that authentication is limited to whoever is authorized for that authentication. It's like a bouncer standing in front of a bar or a pub and saying, "Okay, you want to get in? What's your age? Do you meet these requirements? Do you have an ID? Check

all that stuff and then giving you a ticket or a token and allowing you to get in." That's what conditional access policies do. They kind of work but thread actors are finding ways to bypass those conditional access policies or as we call them caps. How do they do that? There are a few ways how thread actors are doing it. Caps conditional access policies often have gaps. There are accounts that do should not have MFA. H that didn't sound right. Every account should have an MFA. There are accounts which system administrators and IT people think should not have a multiffactor o caps are used to enforce multiffactor authentication. Uh we're talking about break glass accounts. I have to have one

account which I can use to login when I break something or Microsoft breaks something. I get that butctors love that. They figure out that there will be an account which have will have a exception in a cap which will not need a multiffactor authentication and they abuse that and they get in through using those accounts which are excluded. There are legacy authentication protocols like who wants to have a phone and try to login into M365 and then have an MFA prompt. Maybe I'm using a old legacy client which doesn't support MFA. So I need to create exceptions and most of this stuff is being checked using user agents. The fingerprint of the browser or the client that is trying to

login. So a cap says if you're trying to login using a modern modern endpoint tool, a modern application, you'll be forced to do an MFA. But say if you're coming from a mobile phone, that's fine. and user agents are what predators can easily change and you know they want to be whatever they can and they just get in. So that's another way how MFA is being bypassed. Conditional access policies are even bypassed. Another thing which a lot of organizations are using are called trusted locations. Usability and security battle which we have already always been facing. In some case usability wins. So if you're in an office, I don't want you to force to do MFA because I know that IP address.

That's my office's public IP address. If you come from that IP address, you are trusted. Thus know that they abuse this in a couple of ways. One, I get into the organization. I've compromised the system which is coming from that IP address of the organization. And now I'm not being forced to meet the CAP requirements, requirements like MFA. So I can do a password spraying attack get in. Other way thread actors use this is for persistence. In this case I'm already in entra ID and I'm going to add my IP address as an attacker in a conditional access policy and make it a trusted location which means now when I want to come in I don't

have to meet MFA requirements. Probably I already know the password. All good I'm in. I have a cons consistent continuous access into your entry ID. uh environment. The other interesting part of conditional access policies or that bouncer who's standing in front of your pub while checking your ID is once they have issued that ticket to you maybe a band which you have put on your wrist and you are in they don't recheck that stuff you have that band all good I've already verified you that's how conditional access policies also work I check you when you are trying to get into the enter ID portal but once you are in I'm not going to check you again which means if a threat

actor can steal a token a token from the system of the user or by performing fishing attacks the old classic fishing attacks using a tool like e evil genex they can steal that token and then replay that token or use that token to access the applications that rely on entry ID this is a very common attack this is an attack which we see a lot of thread actors do including e-rime thread actors thread actors who are doing business email compromises as well as nation street thread actors this does work. How do you defend against these stuffs? Review your condition access policies. Make sure that you don't have trusted IP locations. I said, "Make sure you don't

have trusted IP location." I sent it to a friend. I asked him to review and he's like, "No, that can't happen. Just review them." I'm like, "Don't have them." Like, we get on a bit of a tel. So, I had to just change it and say, "Please monitor it. Please review it." My suggestion, don't have trusted IP locations. Make sure everyone has to do an MFA. enforced MFA every time they are trying to log in. Protect against token attacks, protect against fishing. You can enable continuous access evaluation where tokens which have been issued are rechecked to make sure that they are valid token. Uh doesn't work for all the applications but certain Microsoft applications this is a newer capability

that has come out. Strongly recommend this is enabled. So that's conditional access policies. Now we are getting into something. We're going to talk about SAML. Security assertion markup language is the bedrock of how authentication happen. >> SAML is what we use. Old school active directory. Keraros was everything. Everything was based on Kerbaros. Now most of the organizations are dependent on SL. SL tokens. A lot of this stuff all of this stuff works with cryptography. So you have public keys and private keys. Private key signs. Public key then verify that the signature is what it claims to be. All good. That's what we're going to break. First, to break SL, we need to understand SL. This is a very high level

diagram of how SL works. There's a user. There's a relying that's my user. That's my relying party. And that's an identity provider. The user wants to access the relying party. The relying party says, "You can't log into me. I don't know who you are. You know what? I trust that identity provider. Why don't you go to the identity provider? Authenticate to the identity provider. Identity provider is going to issue you a token. Present the token to me and then I know who you are because I trust that identity provider. And once you have provided me a token, I have verified who you are. I'm going to allow you access to my resources. That's like short of how SL

authentication works. We're going to make it more complex. That's how SL works. So the user is trying to go to the relying party trying to access the relying party. The relying party says hey user go to the identity provider. You need to first authenticate to the identity provider. The user then goes to the identity provider provides them credentials. If the credentials are correct if the user has provided valid credentials maybe met MFA requirements if that's enforced which it should be a token is issued that token is a sample token. That token is then relayed back to the user. User takes that token go to the relying party. relying party verifies that token. If the verification is successful,

access is granted. How does this verification happen? There is a federation trust between the identity provider and the relying party. This is where our private key and the public care part comes into picture. A private key is used to sign a token. When the token is provided to the relying party, relying party uses a public key opens that up or verifies the signature and says, "Yep, everything inside this sample token I can trust because I trust that IDP and nothing has been changed." This federation trust needs to be established beforehand. It is a pre-existing federation trust which the administrator has already established. That stuff has been done. So, how do thusives abuse this? Oh, before we go there, let's talk about

chained SL authentication. I'm here adding another identity provider. Stay with me here. We talked about how this stuff works. The user goes to the relying party. Relying party says, "Go to the identity provider. This identity provider says, you know what? I can't validate you. I can't authenticate you. I trust another identity provider. So, you need to go to that identity provider." So we're adding one more step here. This is known as delegated identity providers. There are two federation trust now we are talking about. So this is how it looks like. Same process again. You guys know this now very well. The user goes to the relying party. Reling party says go to this identity provider. This identity

provider says go to this identity provider. A token is created by delegated identity provider. Sent to the primary IDP. The primary IDP verifies the signature. says, "Yep, you have been authorized. You have been authenticated by someone I trust. I'm going to give you another token signed by my private key." You are then you can provide the token to the relying party and authentication happens. That's sill authentication with another trusted third party here. Now, we're going to look at how do thread actors break this or what attacks do happen. Before I talk about the attack that happens, let's talk about a fundamental weakness in this design. Again, it's not a weakness, it's a feature. But looking

at how thread actors exploit this, what is happening here is this primary IDP, the primary IDP is trusting what it is being provided by the delegated IDP because it trusts the private key signatures from the delegated identity provider. the relying party is trusting a signature of the primary IDP. So the issue here is everyone is trusting those SL tokens that are being signed. That is the underlying trust which everyone is following and that's how this authentication is happening. If an attacker can break that trust or figure out a way to manipulate that trust, they're golden. That's what they can do. They can forge a token. What they need to make sure is they forge a valid token. In order to

forge a valid token, they need the token signing certificate of the IDP. Rest of the stuff they can master. Rest of the stuff is just who the user is, what kind of rights they have and some other information about the user which is very easy to get. What is difficult to get is the token signing certificate because that is what is needed to forge the token. If as an attacker I can forge the token, I'm in. I'm golden. That's where our first attack comes into picture. The golden SL attack. The probably the most infamous attack. A lot of people would have heard about it, read about it. This is known as the golden sill attack inspired from the

golden ticket attack. Inspired from the golden ticket from that movie Wonka Wonka. >> I've not seen that movie, but I love the movie somehow. I don't know. Okay. So, what happens here? The thread actor targets the identity provider. Give me an example of this identity provider. ADFS is a very common one. Active directory federation services that allows a entry id to then talk to an on-prem environment or a service to talk to an on-prem environment. Uh that's ADFS. So if a thread actor can target ADFS or similar identity provider, they can then steal the token signing certificate. Once they have steven stolen the token token signing certificate they can forge a valid SL token send that valid SL token forged

valid SL token to this identity provider which is in this case a relying party and since that token is valid everything is good it works so that's the first one that's probably the more famous one let's say it's not that easy to steal that token signing certificate maybe it's a software as a service or maybe an application where you don't have access to the underlying operating system of this delegated identity provider. What do you do in that case? Do you even have to steal the token signing certificate? We're going to talk about adding a federation trust. So if as a thread actor I was able to get into the primary IDP, I can make configuration changes to that

IDP. Maybe I got into entra ID, I became a global administrator or highly privileged account. Now I can make configuration changes to the pri to the primary IDP entra ID. The configuration changes here the thread actor makes is they add a federation trust. When they add a federation trust they're essentially adding a delegated identity provider and saying you know what here is a delegated identity provider which you should trust. When someone tries to authenticate just send them to the delegated identity provider. If delegated identity provider tells you all good it's all good. Essentially, a thread actor doesn't even have to spin up a delegated identity provider. So, it's not like I if I'm a thread actor, I have to spin up an ADFS,

then I have to make configuration changes and then the ADFS server which I control. I'm going to use that to create a token. I just need to change the configuration essentially just put that public part in that configuration. Tell it you trust all the stuff. Now, I have the private key. I'm going to start forging tokens using the private key on my laptop right here and start passing those to the relying party. This is a very common attack. A lot of thread actors do. Scattered spider is one that comes into mind publicly known that they used to love this attack. Did I say used to? I don't know. They still probably love this attack. They're

going to probably back. Uh so this is a very common attack which threat actors are doing here. They're adding a federation trust and then using a malicious IDP federation configuration and forging tokens. How do you protect against these? Use HSN's pro protect your keys. Don't let protectors in your environment. Uh whenever someone asks me how do you protect against golden ticket attack and golden samurai attack uh my usual answer is don't get hacked. That is not a great plan, not a great strategy, but that's probably the only way to protect against such weird attacks that happen. Protect your keys. Don't monitor the federation settings of your IDP. If you're using entry ID, monitor anyone trying to change those

settings or if you have added something, make sure that's valid and it's working. It's not a test federation, which then you lose access to when someone brings up a system up. These are some of the Microsoft Enra ID logs that can be reviewed. Okay, let's move on. Let's talk about something which has been in news a lot recently. Targeting OOTH 2.0. It's kind of like SAML but it's different. OOTH is for authorization. Essentially, think of a third app, third party app getting access to your data. That's what OATH is for. Oath doesn't do authentication. In order to make OOTH do authentication, we added OIDC. With OIDC and OOTH together, now we have authentication. Oath uses jot tokens, JWT tokens, JSON

web tokens, JSON web tokens. We're going to call it Jot tokens. That's what is used. But the underlying principle remains the same. The jaw tokens are signed. If you trust the signature, all good. That's what we're going to talk about here. This is how the oath authentication work. It is more complex than what I'm showing here. Let's keep things simple. Let's say this is how it works. In this case, what a user does is the user goes to an IDP. The IDP takes user's information, signs it, creates a signed jaw token, passes it back to the user. The user sends it to the application. The application verifies it using the same private key, public key

pair. And if the application can verify it, all good. They are provided access. You would have probably guessed what kind of attack we are talking about. This is how a JSON token looks like. Uh there is header, payload, signature is what we are after. That's the most important part. rest of the stuff I can manage. So the entire system here is also resting on the integrity of the private key. The fact that the private key is what I trust and I'm hoping it is not compromised. And that's exactly what happened. An attack happened on Microsoft Storm0558. That's a Chinese nation detector. They probably changed their name now. I think Antique Typhoon or something. That's what they are called now. Uh that's

from0558. They targeted Microsoft and they figured out a way of creating those signed chart tokens and relate those tokens to then get access to enterprise applications like Microsoft 365 including Outlook and email of a lot of government organizations in the US. CSRB did a report on this. I definitely highly recommend you read that. Brilliant work, amazing work. Uh that's probably one of my favorite attacks that has happened in recent time. In this case, a consumer level signing key. So they stole a consumer level signing key. There was an understanding that enterprise should be different. Consumer should be different because consumer is consumer, enterprise enterprise. Somehow that consumer key also worked in the enterprise and the thread actor was able

to get access and read and access a lot of emails. This is how it worked. that stuff IDP the director doesn't have to go to that IDP now they can mint their own tickets in their home right in their kitchen and then just pass that to Microsoft and Microsoft happily accepts it and use it does anyone know how that key was stolen anyone in this room knows how that not the key the signing certificate was stolen >> yeah test >> uh last I read Microsoft doesn't know that they came up with a hypothesis and said, "Oh, it was stolen like this." And then CSRB said, "There is no evidence that it was stolen like this. Uh, it's a

mystery. If you know how it happened, have a chat with me after the call. I buy your beer. All your beer today is on me. No one knows how it happened." And that's probably the most important thing you are safeguarding. So that's what forgery. How do you protect against this? I don't know. I'll tell you how the organization that detected it detected it. It goes back to everyone who's sitting in this room, everyone in this room, the security analyst. The security analyst created a rule. The rule was called the big yellow taxi. The big yellow taxi was a same rule which was looking at the logs that were getting generated and based on the logs it detected anomalous login coming

from IP addresses they didn't expect and that's how they detected it. Hats off to the analyst who wrote that rule and picked this stuff up. And then Microsoft did Microsoft did a lot of stuff to make sure that this is not happening again. Okay, that's oath compromise. Are we going to come back to Oath app compromise? If you're thinking that I was saying this has been in news, why was I saying that? We'll talk about that, but stay with me. Let's talk about trusted relationship compromises. These are partnerships that are turned malicious. These they're very similar to supply chain attacks but in this case we're talking about two organizations who have a relationship with each other. One

organization gets compromised and the access they have into the other organization is then leveraged to target that organization. So there are pre-existing technical trusts between different organizations that are getting targeted here. We're going to talk about a couple of these. We're going to start by talking about oath applications. uh oath applications are applications uh where app is registered and then you register it in your tenant and then that app has access to your tenant as the app itself or as a user. Uh think of me providing access to an app to my Google calendar. Now that app can read my Google calendar. Uh this is a very common way how a lot of these new enterprise applications

work. These are called oath applications. uh they're very common in Microsoft enter a lot of you would be using it uh a lot of big organizations have these apps they are being registered and they are getting being provided access to a lot of data they have two parts one is called the application itself and other one is called the service principle the application itself also known as the app u application itself also known as the app registration is in the parent tenant the home tenant so I have a tenant I create an application registration it's like the blueprint of the application. Uh that's where it resides. Uh it can be identified using a GU ID, a globally

unique ID, also known as the app ID. It's created in the tenant of the organization. Uh so if we're talking about an acme cop, which is providing a app and selling an app to all everyone, this is in the tenant of acme. It does need an identity to work with. So in itself, it can't do anything. It's just an application a blueprint that has been created. Now you need what we call a service principle. Service principle is an identity that is used in conjunction with that application registration and then does a lot of interesting stuff. So this is our service principle. It's a local representation of that app. So if you want that app, you need a service

principle in your tenant. And that's how these things work. On the service principle, you can define what access the app can have. uh they can read all the emails, they can read all the my calendar information, they can delete mails and all that interesting stuff is defined at the service principle. Service principle also has an object ID. Uh I I put that image there because I was one of my mate talked about this in 2021 and no one paid attention to it and I'm like yeah this was an interesting attack and no one was interested and five years later everyone now is publishing blogs on this and talking about this and my white paper is still

there no one is reading that okay let's talk about this and this is not only an entry id thing as I said anyone heard of this company Salesforce they have been in news recently for all the wrong reasons. Uh a lot of that stuff is very similar to what we're talking about. There are app registrations and the service principles. Salesforce calls them connected apps and the service principles are called the oath sessions or apps authorization. It'll make more sense as we talking through this. So how does this attack happen? This is how multi-tenant apps work. Here's my home tenant. I create an application registration in my home tenant. I may have a service principle there. We're not focused on that part

right now. We are focused on the application registration. Then in my consumer tenants, I create service principles. So this is a company B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B B or a customer one consumer one going to Acme op and saying, "Oh, I want to use your app. I'm going to pay you $100,000, a million dollars depending on what it is, and I'm going to provide you access to my tenant because that's how this stuff works." And this is the service principle. And there's another

company that goes to Acme and says, "Hey, I also want to use your service." So all these consumer tenants now have service principles. These service principles have rights or access permissions to a lot of data which is in this home uh in the cons customer consumer tenants. This is the design of how this is supposed to work. All good till the time a threadctor comes in. They target the home tenant. They don't target the home tenant. They actually target the company that is managing the home tenant or the home company or the company that created that app which may start with a d end in a T. I don't know what I'm talking about but you get what I'm talking about. But

what is happening here is they are able to get what are called application secrets. There are secrets that are registered in this application or that's how application has been registered. Once you have access to those secrets, you can access all these consumer tenants. So if an attacker steals the application registration secrets, they can use those secrets to access the consumer tenant as the service principle. Which means not one consumer tenant. I can access all the consumer tenants of that app because I was able to get those application registration information from the home organization. Pretty scary attack. Very scary attack. It's a very common one. Crow published a blog. That's my standard marketing stuff for Crowsh.

That's Murky Panda. A very prolific Chinese nation state thread actor that has been used recently. If you search for it, you'll find a lot of blogs and a lot of publications that have happened on them. Uh they have been doing such attacks. So that's attack one. Attack two. What else can I do? I can add my own application secrets in the application or add my own secrets in the service principle and then impersonate the service principle or the application. Depending on where I'm doing that, I may be able to access one tenant or multiple tenants or I can create my own service principles if I do need to have access to the environment. We're talking about

persistence. We are talking about continuous access. We're not talking about initial access here. So that's o how do you protect against this stuff? protect your application credentials or ask your vendor to protect their application credentials or review what they're doing. Interestingly, uh Google published a blog this morning hats off to Mandant for publishing this blog. uh they have a section talking about how this can be detected and monitored and they come up with an interesting strategy of saying okay look at who's logging in from where they then look at their session ids and then say if IP addresses change and if those IP addresses are locations which they don't commonly come from and then figure out

if that's malicious or not that's a lot of work but that's how this stuff works so that's application attacks let's talk about delegated admin permissions that's partner betrayal that does hurt. Seen a lot of attacks that has happened this way. Microsoft has a model where they allow the CSPs the cloud solution providers to help organizations manage their cloud entry environments. What they used to do if you provided DAP roles the initial idea was you'll the partner or the CSP in this case will get full admin access to your environment. uh think of IT organizations that are helping other IT organizations, Microsoft partners helping other organizations. That has since changed. They have come up with granular

delegated admin privileges which still have enough rights to get abused. So in this case, what a thread actor can do is they can target the CSP, the cloud service provider. If they are able to target the CSP, they can access all the trusted relationships that the CSP has or all the downstream entry id environments that are being manage managed by the CSP. Let's talk about a couple of attacks. A thread actor figures out a way of getting into the CSP partner tenant. Maybe the CSP didn't do security properly. Maybe they didn't have MFA. Yep, there are accounts that don't have MFA. uh I get into a lot of calls with a lot of organizations who get breached and

the first question I often ask is do you have multiffactor authentication uh they say yes and then say you know what but we have a program where we are shifting everyone to MFA but we have a VPN which still doesn't have an MFA but no one uses it yeah thread actor knows no one uses it so they're not going to use it all that stuff still happens so in this case the thread actor gains access to the CSP partner tenant Once they have access to the CSP partner tenant, they can access all these consumer tenants for which DAP roles have been assigned or this CSP is responsible for managing those accounts. The challenge with this is once a DAP

role has been assigned, it needs to be manually removed or deleted. A lot of organizations may hire someone to set their entry ID environments and then forget about it till the time the thread comes in and starts abusing it. So that's attack number one. Let's talk about attack number two. That's me dreaming about an attack. I've not seen this happen before. I hope it doesn't happen, but we live in strange worlds. So in this case, what the director does is they create their own tenant, which is a CSP tenant. This has not happened probably because it's not easy to get the CSP status. You have to go through multiple steps to for Microsoft to say, "Yep, you are a CSP

now." And you can have delegated admin access. If this happens, a threadctor can create their own CSP uh own CSP account and then go to other victim environments and create those DAP roles for them and then able to manage all these environments. So like a persistence backd dooror across multi multiple environments that can still happen here. I'm going a slide back. If I have access to a CSP partner tenant and I get into a company which is not a DAP doesn't have a DAP relationship with this tenant, I can still add those DAP relationships and continue that access or have that persistence access. But this I've not seen this happen before. I've not seen a publicly

document case documented case of this attack. But this does work. A lot of organizations never review or limit DAP assignments. goes back to the old mindset a lot of us have which is don't fix it. If it's not broken, it works. Just don't touch it. You touch it, something bad will happen. A lot of organizations still do that. How do you prevent these? Make sure your part CSPs have MFA. That's easier said than done to enforce your CSPs to have security features in place. Uh you can look at your own logs and see if someone is doing a delegated admin access into your environment. That's one way to do it. Uh which is pretty effective. That's

what uh forensic analysts will also look at once they see these attacks happening in your environment. Let's talk about cross tenant synchronization abuse. Very similar to what we have talked about in this case. This is again a feature not a weakness where a source tenant can push accounts in a target tenant if they have a cross tenant synchronization configured on these two tenants. So what a thread actor can do that's a complex slide busy slide. So what distractor can do is they can gain access to a a tenant with a CTS relationship with a victim and once they have that they can then push accounts into the victim environment and then use those accounts to access. The

interesting part here is I didn't create those accounts. I don't have those accounts in my environment but those accounts are being now used by a thread actor to access my environment. That's what makes this attack difficult to detect or the way it is. Another attack that can happen using the same B2B synchronization is backdooring victim tenants where an attacker once they get access to the victim tenant, they create a B2B relationship, a trusted relationship with a tenant which they control and they go away. They have now put their persistence in place which they can then abuse a few days later, a few weeks later where they come back and they're like, "Yep, now I want to access

to this environment. I'm going to push those two accounts and use that access into my victim tenant to access the tenant. Uh this is a persistence attack setting up persistence and using abusing it at a later time. Okay, let's talk about another attack that happens in Entra ID called temporary access pass. It's a feature in Entra ID where temporary access passes can be created and then handed over to the users. A lot of organizations do that for initial onboarding of users. you're trying to onboard users. So you don't have you you have not provided them a valid credential. You don't have MF in first because it's going to be difficult to figure that out while the

user is logging in for the first time. So they create what we call a tap, a temporary access pass, a link that they send to the user. The user clicks on it and the user is in. You can have a tab which works only once or have a tab which works multiple times for multiple days. The interesting about thing about tap is if I create a tab for a user, I don't have to change their password. I don't have to change their MFA. I can just bypass all those configuration and keep accessing the environment. So you would have guessed that is what thus abuse. So what protectors do in this case is they get access into into an

environment and they maybe they change the tap policies or the tap policies are already very flexible and relaxed and they start creating those tabs and using those to login even if a password is not changed or an MFA is enforced it doesn't matter here because I have a tap which just bypasses all the security controls you have in place. So that's another way how thread actors are bypassing uh MFA requirements and other configurations. How do you detect against this? You can monitor it by looking at some logs that are being generated. You can limit who can create a tab. You can limit for how long a tab can be created. Just maybe allow one-time taps or figure out

another way of onboarding users. This is another one. Adding MFA to a dominant account. I've seen this happen a lot many times more times than I would like to see stuff like this. where a thread actor is trying to login in and they are being hit by MFA. They are being kicked out by MFA and they are just trying different accounts till the time they stumble upon an account which is a new account which no one has used till now. This configur this organization has a configuration where when you try to login the first time and you provide a valid credential then you are forced to set up MFA. Okay, you have logged in please set up

an MFA because that's your corporate policy. uh you need to set up MFA and then only you can log in. So what the thread actor does is either they try different accounts till they stumble on an account which doesn't have MFA and they configure an MFA but that MFA now runs on my system my phone as an a thread actor or once they are in the environment they're looking for accounts that are dominant. They figure out an account which no one uses and they add an MFA to that account. Maybe the organization figures out they have been compromised. They do what we call an eviction event. They look at all the accounts in entry ID and say which ones

don't have MFA. We don't want any accounts which don't have MFA and the thread actor is sneaking there and saying my account has an MFA. That'll work for me. So this stuff is really interesting and this does work. How do you detect this? Uh disabled dominant accounts easier said than done but you should be looking at dominant accounts every week every Fortnite and just disabling the ones which are not being used removing the ones which are not being used. you when we are doing eviction events it is really challenging but what we need to do is look at all the MFAs that have been configured for all the accounts and then make sure they are valid MFAs

make sure that one account one phone number is not configured to a number of accounts make sure that there's there's only one phone number configured to every account so stuff like that it does get into a place where you have to do a lot of manual work unless you have done a lot of pre-work to this another feature of Microsoft enter ID is SPR, self-service password reset. A lot of organization organizations use it because when people forget passwords, they want to reset those passwords. No one wants to pick up a phone, call the help desk, get on a video call, provide them then identity card or ID, government issued ID. I hope you have those policies in place. Uh because it's

just a matter of time thread actors do the social engineerings and engineering attacks and get in. So what most of the organizations do is they set up SPR. If you forget your password, go to this portal, provide them a couple of things. Uh maybe an email, maybe a phone number, and then you'll be issued a temporary password or you'll be provided a link where you can reset the password. The directors get into the environment, they change those phone numbers, or they get into personal email addresses of people and steal those uh codes that are coming back to those users or they do a SIM swapping attack. uh it has become very common to see SIM

swapping attacks especially with scattered spider and similar thread actors. It used to be not that common. So SMS used to be okay. It's no more okay as a second factor. There are similar attacks in AWS. So I talked about entra ID a lot because I see that a lot because Microsoft does a great job of providing a product which everyone wants to use entra ID but similar attacks work in say octa in AWS. So there are similar things. I've just put a a table of what similar attacks do work in AWS. That's modern identity providers. If you are interested in talking about the good old Active Directory, I love Active Directory. I'm going to be talking about

that tomorrow for 4 hours. Who wants to hear about Active Directory for four hours? Yeah, everyone. Right. Uh okay. So I'm going to talk about active directory for 4 hours tomorrow morning. Uh it's probably for 3 hours. The reason I have this here is if you want to be in this workshop or you want to play along, there's a link here which has a virtual machine which you can download, bring up a couple of machines, set them up. We're going to talk about active directory. We're going to talk about Kerberos in depth in detail. Talk about features in Kerberos and how they work and how they can be broken. We're going to talk about golden

ticket Kerber roasting. a lot of interesting stuff that's going to happen tomorrow. Do remember this presentation deck is available at that link and I'm the only one standing between you and the bar. So, I'm going to get away and I'll see you tomorrow. Thank you everyone for joining.