Microsoft Breach: What Happened? What Should Azure Admins Do?
ฝัง
- เผยแพร่เมื่อ 21 ส.ค. 2024
- Microsoft disclosed the details of their breach at the hands of Midnight Blizzard. In this video, we explain and demonstrate what happened, and provide some analysis on what the real impact of this breach could be.
Resources mentioned in this video:
Microsoft’s blog post detailing the breach: ghst.ly/493ZQir
SpecterOps blog, “Microsoft Breach -- What Happened? What should Azure Admins Do?” ghst.ly/4bmXHzW
SpecterOps blog, “Microsoft Breach - How Can I See This In BloodHound?”ghst.ly/3HLRjVg
BloodHound CE: github.com/Spe...
BloodHound Attack Research Kit (BARK): github.com/Blo...
Having an AUDIENCE for this video that asks questions and clarifies things is GREAT.
Thank you for that feedback, Dave, and thank you for watching our video
Man...I had a blast! thank you so much for your brilliant explanation Andy! keep coming!
It's my pleasure, thank you for watching. I hope the information was useful.
thanks guys. very very comprehensive overview
It's our pleasure, thank you for watching
Amazing video! Always love to hear from Andy :)
Great session, thanks for uploading it.
It's our pleasure. Thank you for watching the video
Awesome explanation.
Thank you
Really enjoyed this vid, I manage some Azure Tenants and all cloud providers are a whole discipline in themselves, so much to look over and keep an eye on
For next video would appreciate it for us old ppl that you have a SLIGHTLY BIGGER terminal font :)
Thank you for that note, Dave, I will make sure terminals are easily legible the next time we make a video
Can you elaborate on what you said at 30:55, that disabling user consent would not have prevented SVR from granting consent to the malicious OAuth applications?
This is regarding the attack path step that Microsoft describes as:
"They created a new user account to grant consent in the Microsoft corporate environment to the actor controlled malicious OAuth applications."
This is a great question because it may seem as if disabling users' ability to consent to foreign applications would have stopped the attack path in its tracks. But the very next statement Microsoft makes is this:
"The threat actor then used the legacy test OAuth application to grant them the Office 365 Exchange Online full_access_as_app role"
What matters in this statement is not the particular app role that was granted. What matters is that this statement is saying the originally compromised service principal had the ability to grant app roles at all. Service principals can only do this by making POST requests to the appRoleAssignedTo MS Graph API endpoint. That action implies that the originally compromised service principal was either already a Global Admin, or had an Entra ID role or MS Graph app role that easily allows promotion of itself to Global Admin, as we detail in this blog post: posts.specterops.io/azure-privilege-escalation-via-azure-api-permissions-abuse-74aee1006f48
So, to finally answer the question:
Blocking users from consenting to foreign applications would not have stopped the attack path, because at this point in the path, the adversary already had full control of the entire tenant. They could have simply toggled that setting off, or promoted the new user they created to an admin role that allows that user to consent to foreign apps even if the toggle is set to on.