Hybrid Identity Explained: 3 Setups & Their Security Risks #shorts

There are three types of hybrid setups, and I'm going to go through them now because we kind of need to understand how they work to be able to figure out what happened here. So, what could possibly go wrong here? If you think of a compromised company, well, one way, which we saw in like the SolarWinds attack, for example, was that if the ADFS server is compromised, you don't need to be domain admin. You just just need to be local admin on the ADFS server, then you can dump the token signing certificate and the related private keys and secrets. And with that, you can just sign your own tokens. Which means that yeah, it's not a bad good situation,

right? Because then you sort of just fly your way into whatever you want to fly into because yeah, you sign your own tokens as a threat actor. But, this is not what we saw in this specific attack, right? We saw a password reset. That's what we're looking for. This would not be a password reset. It would just be someone who's magically authenticated. So, let's talk about the second method for hybrid, which is pass-through authentication. And in that case, the user goes directly to Entra ID. Entra ID asks who they are, and they provide their username and password, and that is then sent to a queue, which is then pulled by a AD Connect server, which lies on prem.

So, what could possibly go wrong in this setup if someone compromises that AD Connect server? Well, there are some like AAD internals as an implementation for this, and there's multiple ways to do it, but essentially, you can patch the logon user W function and say something like, you know, if I don't care about the username, but if the password is banana, then say that the login is successful. And then you have a backdoor password. You can can log into whatever account you want. Then again, this was not a login, right? This was a password reset. So, let's move on to the third and final method of hybrid cloud, which is password hash sync. Um so, what could go wrong in this third

variant? Well, if like to be able to do this, you need to have a few accounts and a few secrets, right? So, you need one account which is able to do that DC sync. You need some kind of a service account, which is going to be relevant soon, but the actual account that is running the service. And you need an account in Azure who is able to write the hash for users, right? It needs to be able to create users. It needs to be able to do quite a lot of interesting stuff. Because if it doesn't have that those permissions, then it's not able to sync it all the time, right? So, what happens if someone steals that

sync secret? That's not a great situation, right?