In the conversations I’ve been having about Midnight Blizzard (and cloud-centric app compromises in general), people get the bits around MFA, privilege abuse, and the like. The missing piece is usually how control of App 1 in Tenant X gets you into Tenant Y. This might help (buckle up, slightly nerdy):
If you have control of App 1 in Tenant X, you can add credentials to that app. If App 1 has already been instantiated in Tenant Y, you can use those credentials to authenticate as the Tenant Y service principal assigned to the instantiated app, even though the credentials were added to the app registration in Tenant X. Read that sentence again carefully.
But how? Isn’t the instance of App A separate in Tenant X vs. Tenant Y?
Not really. Look at the App ID for the app in Tenant X vs. Tenant Y and you will see that they are identical. So while it’s true that Tenant Y doesn’t know about the credentials added to the app registration in Tenant X, it doesn’t mean those creds can’t be used to authenticate into Tenant Y as the service principal, using those creds.
If that service principal has any sort of elevated Entra ID and/or API permissions, then it’s easy to see how that can be leveraged to continue an attack in Tenant Y from that point.
Microsoft and others have already covered how to protect, detect, and respond to these attack vectors, so I won’t belabor it here. The DART guidance attached here is super helpful too.
Note: This is not an inherent design flaw in Entra ID; you will have the same/similar challenges securing modern cloud-native apps in any identity provider. App registration and consent is how OAuth apps work, for example…it has nothing to do with Entra ID, per se. And, as has already been highlighted in various blog posts, it is 100% possible to prevent, detect, and respond here—you are not powerless to effectively defend against this kind of app misuse.
