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.


Tuesday, August 15, 2017

Microsoft, How Can Organizations Prevent an Active Directory Denial-of-Service (DoS) Attack Involving Organizational Unit Deletions? (Day 13)


Dear Microsoft,

Today is Day-13 of our advanced Active Directory Security School for you. Frankly, I don't know why we're calling it "advanced" when in reality all of this stuff is so "basic". (Yet, likely thanks to you, organizations worldwide are still clueless about this stuff.)

Last week, I helped you understand just what it takes to answer one of the most seemingly simple questions in organizational cyber security - "Who can create user accounts in Active Directory?"   Today, I'd like to ask you another simple question.




Another Simple Question -

Microsoft, today I would really like you to help your customers understand yet another fundamental aspect of cyber security.


How do organizations find out "Who can Delete an Organizational Unit in Active Directory?"


In case you're wondering why they might want to know this,
allow me to paint you a very simple picture...





Houston, We Have a Problem!

Let's assume that on a Monday morning at 9:00 am, in the foundational Active Directory of a multi-billion dollar organization that has thousands of employees, someone intentionally deleted the top-most level organizational unit (OU) in their primary Active Directory domain, you know the one that stored thousands of its domain user accounts, computer accounts, security groups etc.




What do you think the ramifications of this simple malicious action might be on the organization?


Allow me to enlighten you - if this were to happen, not a single one of the thousands of the organization's employees will be able to logon, let alone go about their every day work, such as accessing or sending email, accessing internal documents, websites, SharePoint portals, applications, databases, and in most cases, even the Internet, etc. etc. until a Domain Admin equivalent admin is successfully able to perform an authoritative restore of that domain, and that is something that could take hours.

Simply put, an insider/intruder would have been able to launch a massive Denial-of-Service (DoS) attack on Active Directory!

Now, I don't have to tell you how much one day of downtime would cost a multi-billion dollar organization that has thousands of employees. This would in effect be a massive organization-wide denial-of-Service attack most easily executed in ONE second!

Oh, and this best-case scenario assumes that the organization has an up-to-date backup of their Active Directory from which they could perform an authoritative restore. If for any reason, they do not have an up-to-date back-up, you can multiple the cost by 100x, because in that case they'd essentially have to rebuild the entire network from the ground up, re-provision access on/to all IT assets that are being protected by domain security groups from this domain and that are stored on domain-joined hosts (i.e. servers, desktops, laptops etc.), etc. etc. The list is long, and this could easily take weeks to recover from. Weeks!

If you know of any company that could survive weeks of downtime in today's fiercely competitive day and age, let me know.






Ah, The Protect Object from Accidental Deletion Feature

Now, perhaps you might say that there is a feature called "Protect from Accidental Deletion" which is designed to help prevent such scenarios. To which, I'd say, you're hearing what I'm saying, but you're not listening to what I'm saying, the difference being that you're not paying attention to my words, as you always should, because I make each word count.


Note that in the scenario above, I didn't say someone accidentally deleted an OU. I said, someone intentionally deleted an OU i.e. this wasn't accidental, and who ever did so, was only able to do so because they had sufficient access to be able to do so.

In other words, someone very well knew that they had sufficient access to be able to enact the administrative task "delete an organizational unit" on a top-level OU, and they proceeded to enact that task at the most opportune time - 9:00 am on Monday!

(By the way, that Protection from Accidental Deletion Feature may have been one of the lamest features you've ever delivered.)

Get the drift?!





Wait, This is Simple! (Or Is It?)

Next, perhaps you might say that, well this is easy - we would suggest that our customers simply proceed to find out who has "Standard Delete" permissions on this top-level Organizational Unit (OU). That's it - this is simple!


Well, you could make that suggestion, but then you'd (again) be giving them dangerously inadequate and inaccurate advice!

As I have pointed out many times by now, first of all, it is not "who has what permissions in Active Directory" that matters but in fact it is "who has what effective permissions in Active Directory" that matters, so that rules out the first part of your answer!

Perhaps, after all these lessons over the last few weeks, perhaps you may now tell the world - "Well, we now suggest that our customers proceed to find out who has "Standard Delete" effective-permissions on this top-level OU.  That's it - Simple!"


Simple?!


First of all, if you don't mind me pointing out, you Microsoft, cannot say "This is simple" because you the $550 Billion Microsoft Corporation don't even have the ability to adequately and accurately determine effective permissions in Active Directory!

(You can't, but I can, because of this.)

Secondly, although you're a step closer in finally helping your customers understand that it is not "who has what permissions in Active Directory" that matters but in fact it is "who has what effective permissions in Active Directory" that matters, in this case, there's a lot more to it than merely trying to figure out who has who has "Standard Delete" effective-permissions on an OU.

Know what I'm talking about, or are you yet again clueless?






Hint - Think a Little Deeper (Pun Intended)

Okay, I'll give you a hint. In Day-12's lesson, I showed you that in order to answer a simple question as "Who can create domain user accounts in Active Directory", one might possibly need to determine effective permissions on hundreds if not on thousands of objects in Active Directory!




So, obviously, this being Day-13's lesson, the question's a little harder, as is the answer. Here's a hint - to answer this question, an organization might technically need to determine effective permissions on at least as many objects as there are in that OU!!!

So for instance, if an OU contains 10,000 domain user accounts, 10,000 domain computer accounts, 10,000 domain security groups, 100 service connection points and 100 published print queues, in order to answer this one question the organization may have to accurately determine effective permissions on at least 30,200 objects!

Let me repeat that for you. Technically, to answer this question, an organization may have to determine effective permissions on at least every single object that resides in that single ONE organizational unit!  (Now imagine if they have 100s of OUs!)





The Correct Answer - Coming Soon

Confused? Perplexed? Clueless?!  Don't worry, I'll answer the question in Day-14's post right here on this blog in a few days.


BY THE WAY, it is in light of everything I've been sharing that I said that you might find the videos shared here LAUGHABLE!

By the way, if you the $550 Billion Microsoft Corporation don't even know the answer to this question, how can we expect thousands of organizations worldwide to have the answer to this most basic and fundamental of cyber security questions?!

Best wishes,
Sanjay



PS: Sorry for the slight delay in continuing school. I had to write A Letter to Donald Trump regarding North Korea last week.

No comments:

Post a Comment