Today Active Directory Security is mission-critical to organizational security worldwide and thus mission-critical to Cyber Security worldwide. On this blog, former Microsoft Program Manager for Active Directory Security, and today, CEO of Paramount Defenses, shares valuable technical insights on Active Directory Security.


Saturday, December 23, 2017

Just ONE Question to Microsoft & Preempt re Security Advisory 4056318 and Active Directory Privilege Escalation in Office 365 / Azure AD Connect

(About the Flaw in Azure AD Connect Software That Can Allow Stealthy Admins to Gain Full Domain Control)



Folks,

On Dec 12, 2017, Microsoft issued Security Advisory 4056318 in response to a flaw that Preempt discovered in Microsoft's Azure AD Connect software that lets its customers synchronize directory data between their on-premises AD and Azure AD.


This is rather important, as evidenced by this headline - Microsoft launches privilege escalation attack on itself with Office 365 !

Indeed, Microsoft may just shot themselves (and their customers) in the foot by making one HUGE careless mistake!

I thought I'd share a few thoughts.



First, a quick SUMMARY

Here's the summary of the flaw -
Preempt (a startup, more on which below) discovered that when organizations run Azure AD Connect to integrate their on-premises Active Directory with Azure Active Directory, if they select Express Settings during installation, then the domain user account MSOL that is created for Azure AD Connect is granted the Get Replication Changes All extended right on the domain root (, so that it can sync content, including passwords,) YET this account is NOT afforded special protection under the umbrella of AdminSDHolder, AND AS A RESULT, this results in a non-administrative / non-privileged domain user account possessing what is clearly tantamount to administrative / privileged access in Active Directory, thus paving an Active Directory Privilege Escalation path.

What I've shared above is the essence of this issue. In short, if you run Azure AD Connect and select Express Settings, you will have introduced in your environment a privilege escalation path leading from a delegated admin to Domain Admin (equivalent) !




The VULNERABILITY

Herein lies the flaw/vulnerability -
Since this MSOL account is not protected by AdminSDHolder, its ACL (access control list) is neither protected nor locked-down, and thus it could easily contain many ACEs (access control entries), some Explicit, and others Inherited from its parent, that could in effect end up granting numerous non-privileged users sufficient Active Directory effective permissions (e.g. Reset Password, Modify Permissions,Modify Owner) on it so as to be able to obtain control over this account and then misuse the Get Replication Changes All effective permissions that this account has on the domain root by using tooling like Mimikatz DCSync to instantly compromise the passwords of every single account in the Active Directory, including those of all Active Directory privileged users!

Thus, this one little Active Directory ACL misconfiguration automatically enables this scenario - Massive Cyber Security Breach !

By the way, if you want to know who can reset the MSOL account's password today, all you have to do is touch a button.





A QUESTION to MICROSOFT

You do realize that a single such mistake could instantly jeopardize the security of thousands of organizations worldwide, yes?


Question: Since WHEN did we become SO careless?! How could this have passed basic vetting? I had just asked a question a few weeks ago, with the hope that y'all would start taking this seriously - How Well Does Microsoft Understand Cyber Security ?!

This stuff is very important, and I know you're capable of much better than this, so can we please be more careful next time?!

(It appears to me that you may likely not have the right set of folks working on Active Directory Security. If you need me to help you identify the right set of Microsoft employees that should be working on AD Security, or help you out generally, let me know.)





PREEMPT ISSUES ITS OWN GUIDANCE

Preempt, in addition to having found this flaw and reported it to Microsoft, also issued its own guidance for organizations.

Here it is - Advisory: Flaw in Azure AD Connect Software Can Allow Stealthy Admins to Gain Full Domain Control.

You'll want to read it, as here are the parts they discussed - Understanding Stealthy Admins, Details on the Azure AD Connect Account Flaw, Who is Impacted, How Stealthy Admins can be Exploited, How Organizations can Protect Themselves, Free Preempt Inspector Tool for Determining if you are at Risk. They even made two videos, and uploaded them to YouTube .

They also shared that Microsoft has acknowledged the issue and released a Microsoft Security Advisory and a PowerShell script that address the flaw by adjusting the permissions of the Active Directory domain accounts to address this issue.

Finally, they issued guidance on how organizations can protect themselves -
  1. Review all stealthy administrators in your network
  2. For each stealthy admin, decide whether added permissions are indeed necessary
  3. Protect your privileged (known and stealthy) users by adding protection

Their guidance ends with:  FREE TOOL: Download Preempt Inspector to see if you have stealthy admins in your organization.

Their simple, well-intentioned guidance is spot-on. Can the same be said about their tooling? Well...  (keep reading.)




SOME GUIDANCE FOR PREEMPT

Since Preempt has been so helpful to a company I so love i.e. Microsoft, by discovering this flaw and sharing it with Microsoft, perhaps the gentlemanly thing to do here would be to return the favor by sharing a few thoughts with them -

  1. As you'll hopefully agree, if there exist such "Stealthy Admins" in Active Directory, then it is paramount that organizations be able to accurately identify all such "Stealthy Admins", because even just ONE such account could be used to gain complete command and control over Active Directory, and consequently over the entire network.

  2. This notion of "Stealthy Admins" that you likely seem to have introduced, as likely did CyberArk the notion of "Shadow Admins", does sound very catchy, but it is not actually new. What you seem to be referring to as "Stealthy Admins" is actually what thousands of organizations have, for almost two decades now, known simply as Delegated Admins.

  3. I thought I'd share that in 2016, we had informed the Chairmen, CEOs and CFOs of the world's top 200 organizations, as well as MSRC that due to one specific deficiency in Active Directory, there likely exist hundreds of such stealthy / shadow admins (and thus thousands of privilege escalation paths) in most Active Directory deployments worldwide?

  4. Did you know that most vendors in the Active Directory space do not seem to know that to correctly identify stealthy / shadow admins in Active Directory, one needs to be able to determine Active Directory Effective Permissions ?

  5. Finally, I do recall having read a few articles on this very subject on the Internet (; if you merely replace the term "Delegated Admins" with "Stealthy Admins" in these articles, they may all sound very familiar) -

    1. From way way back in 2013 - Active Directory Privilege Escalation  (+ again in 2017)

    2. From way back in 2014 - Using Password Resets to Escalate Privilege in Active Directory   (+ again in 2017)

    3. From back in 2015 - How to Identify and Minimize Privileged Users in Active Directory

    4. From 2016 - 10 Examples of Delegated (Stealthy) Admins in Active Directory

    5. From 2017 - How to Correctly Discover Stealthy Admins in Active Directory + 50 More

Thus, Preempt's focus on Stealthy Admins in Active Directory is spot-on, but the Bible on the subject has already been written.




A QUESTION TO PREEMPT

Finally, since Preempt's experts seem to be proficient at finding flaws, thought I'd ask most respectfully ask them a question -

The Question: Preempt, are you SURE that your free tool Preempt Inspector, which you've been recommending to organizations worldwide as a means to identify all Stealthy Admins in Active Directory deployments, can in fact accurately identify Stealthy Admins in Active Directory?  (or could there potentially be a(n equally big) flaw in it?)


Again, I ask this most respectfully, and I only ask this because
as you'll hopefully agree, accuracy after all is paramount.



The answer, in days to come
(; it'll be very similar to this.)


That's all for now.

Best wishes,
Sanjay.



PS: By the way, Microsoft's guidance in its Security Advisory 4056318 is INSUFFICIENT, in that even if you enacted it exactly as specified, you may still be left exposed. If you want to know why, please feel free to tune in here in a few days, or to ask us.

No comments:

Post a Comment