Today Active Directory Security has become 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.

Gold Finger The Paramount Brief Gold Finger Mini World Peace

Wednesday, August 30, 2017

How Someone Could Launch a Massive Denial-of-Service Attack and Bring Businesses that Operate on Microsoft Active Directory to a Halt in Seconds


Folks,

This is a short post I'm penning upon the recommendation of several folks who read my last blog post. They felt that the sheer importance and impact of what was shared in that post may not have been be conveyed well enough by its title, thus this post.




How Someone Could Halt Business at Billion $ Organizations in Literally 1 Second -

Consider this. Its 9:00 am on a Monday morning at a multi-billion dollar organization. Thousands of employees show up to work, and proceed to log-on to their domain-joined Windows machines so that they can then go about their everyday work, email, etc.

There's only one little problem - no one is able to log on, and by 9:30 am its very clear that all fifty thousand (50,000) employees of this multi-billion $ organization cannot logon, and thus cannot go about their work!  In short, the business has come to a halt.


By the way, its not just employees who won't be able to logon; any and all IT services that may be running as Network Service / System on domain-joined machines and that rely on authorized access to other servers/services to work, will also stop working.

This was an especially important day for the company. It was the day they were going to announce and launch a new multi-billion $ product line, continue assisting millions of customers on a recent major issue, and announce their quarterly earnings.


Unfortunately, since no one can log on, not a leaf is
moving in the organization this Monday morning.

(Its a dark morning.)



By 12:00 noon, rumors of a "cyber breach" at the organization surface on Wall Street, and in minutes, its stock plunges 7%...


... the organization just lost a few Billion $ in market cap, and from the CEO to Shareholders everyone's shocked and worried.


By the time someone figures out what's wrong, its almost 12:30 pm. By the time the appropriate Active Directory admins are called in, and figure out what's going on and do what's needed to fix the problem, its almost 5:30 pm i.e. an entire day, lost.

Oh, and by the way, this assumes that the organization had an up-to-date backup of their foundational Active Directory. If the back-up happens to be days old or older, it could easily take many more days, if not weeks, before everything from accounts and group memberships to provisioned access etc. is effectively restored back to where it should be in their Active Directory.





So, What Happened?

By 2:30 pm, their Active Directory administrators had figured out that literally all that happened here was that ONE individual who was not even supposed to have sufficient effective permissions / effective access in their Active Directory to do so, had been able to DELETE the organization's top-level organizational unit (OU) in their Active Directory!

That's it?!


That's it!

In weeks to come, they would learn that a Junior IT Analyst who had recently become disgruntled over a petty issue with his manager, decided to prove a point, and he had been able to figure out that he had sufficient effective permissions in Active Directory so as to be able to perform a simple Delete-Tree operation on a top-level OU in the Active Directory.

So, that Monday morning, he arrived a bit early, and at 8:55 am he launched Active Directory Users and Computers, located the top-level OU in Active Directory, right-clicked and selected Delete, and within seconds over 50,000 domain user accounts, 75,000 domain computer accounts, 100,000 domain security groups etc., i.e. the entire contents of that OU, all got deleted!





So What Made This Possible?

Are you kidding me?! How could someone have caused SO much damage in literally one second, by clicking just one button?!


The answer (or rather the question's right here) - Who can Delete an Organizational Unit in Active Directory and its Impact?


Now, in light of the above, here's how thousands of organizations in the world, including Microsoft, can prevent this scenario from occurring in their IT infrastructures today - all they need to do is accurately identify (i.e. audit) who can enact this task in their Active Directory, and then proceed to revoke the access of anyone who is on that list but who should not be on that list.

The hardest part here is the former part i.e. accurately identify (i.e. audit) who can enact this task in their Active Directory, so here's trillion $ advice on how to correctly do so - How to Audit Who Can Delete an Organizational Unit in Active Directory



Alright, that'll do it for today. I just wanted to help folks worldwide, especially C-Suite folks, understand the real and profound consequences and impact to their business, of someone possessing excessive Active Directory effective permissions in their foundational Active Directory deployments. The above scenario is likely enactable at most organizations worldwide today.

Incidentally, I wouldn't even call this a "cyber breach", yet as illustrated above, its impact on business can be substantial.

Best wishes,
Sanjay


PS: If I'm shedding light on these (easily addressable) weaknesses in Active Directory (which is otherwise a highly robust and securable technology), it is only because even after 17 years of AD having shipped, organizations worldwide still remain vastly exposed to such risks, even though the probability of occurrence of such risks materializing has since increased dramatically.



PS2: If this scenario seems far-fetched, consider 3 alternatives (and I could share many more such alternatives with you):


  1. An entity hired hackers to breach the organization, who post-breach determined who had sufficient effective permissions to enact a top-OU-level deletion, then compromised the account of any one such individual to make this happen. They had also shorted the organization's stock over the past few days, and ended up making a $100 Million that morning.

  2. A lone-wolf intruder who controls at least one domain-joined machine figures out who has sufficient effective-permissions to delete a top-level OU, then uses various avenues such as using the archaic Pass-the-Hash technique to compromise one of these accounts, which then gives him/her the ability to delete this top-level OU, and then proceeds to do so. 

  3. An APT (e.g. a foreign government aided entity) writes malware designed to try and delete top-level OUs in Active Directory (whenever a user logs on to an infected machine) in the security context of whoever the currently logged-on (to an infected machine) domain-user account happens to be, and then proceeds to try and have as many computers in the target organization be infected with that specific malware. Should a sufficiently authorized individual end up logging on to their designated (but now infected) machine, the attempt will succeed.
In short, neither motive nor avenue matter as much as the need to identify and minimize who can do what in Active Directory ! (If you know that only 4 individuals in the organization can enact this privileged task, and the user accounts of these individuals are adequately protected, then irrespective of their motive or avenue, malicious entities won't be able to succeed in their efforts.)




PS3: If you have the time, you may enjoy the following which is a continuation of the above...


Who's to Blame?

In weeks to come, the organization set up a high-level committee to look into how this happened, to figure out who was to blame here, and to determine how to ensure that something like this could not ever happen again!


The #1 question that was raised was - "How did the organization's IT and Cyber Security leadership not know that this individual had sufficient access so as to be able to perform such a high-impact and privileged access operation i.e. delete a top-level OU in their Active Directory!"


Here's how the Q&A in that committee hearing went, led by the Committee's Chairman -

Chairman to CISO - "Were you aware that this individual possessed such elevated access in Active Directory?"

CISO to Chairman - "Sir, we care deeply about cyber security and this year alone, we've spent millions on cyber security. As to the security of our foundational Active Directory, I rely on our Active Directory Operations (Ops) Team to ensure its security, so perhaps I should defer the question to the Active Directory Ops Team."

Chairman to CISO - "Well, ultimately this falls under your umbrella, so and ultimately you're responsible, but okay, I will ask the Active Directory Operations Team."

Chairman to Active Directory Ops Team Director - "Were you aware of this individual having such access?"

Active Directory Ops Team Director to Chairman - "My role is managerial; I rely on our Enterprise Admins for this."

Chairman to Enterprise Admins - "Were you aware of this individual having such access?"

Enterprise Admins to Chairman - "Trying to find out who has what effective privileged access in Active Directory is very difficult. We've unsuccessfully tried do this for years. Recently, we had requested funds for the procurement of tooling that could greatly help in this vital regard, but our request was turned down due to 'lack of funds'."

A Domain Admin interjects - "Sir, actually for quite some time now, we actually didn't know that we were supposed to be determining "who has what effective permissions in Active Directory." All these years, we have been determining "who has what permissions in Active Directory" and apparently, that isn't how we're supposed to do this. We then attempted to accurately determine effective permissions in Active Directory, and realized that it is very very difficult, so we proceeded to identify tooling that could help us do so easily and accurately, thus the request to procure such tooling."

A 2nd Domain Admin interjects - "Sir, to be honest, we sort of knew we were operating in the dark, but we thought that at least we had a feature called 'Prevent object from accidental deletion' turned on, and we assumed that that would have been sufficient, but apparently not."


The Chairman, whose time is easily worth thousands of dollars per day, paused briefly, then continued...


Chairman to Enterprise Admins - "Gentlemen, how much did you need to procure such tooling that you believed could help you easily and accurately identify who has what privileged access in our foundational Active Directory for our multi-billion dollar publicly-held organization?"

Enterprise Admins to Chairman - "Sir, not much actually; I believe it was a few thousand dollars."

Chairman to Enterprise Admins - "Gentlemen, just so I understand this clearly, are you saying that if you had the appropriate tooling, you would have been able to identify that this individual had excessive privileged access, and thus could have taken steps to revoke such access, and thereby prevent this security incident from occurring?"

Enterprise Admins to Chairman - "That is correct Sir."

Chairman to Enterprise Admins (Shocked!)- "Gentlemen, do you realize that the lack of such vital cyber insight, which required only a few thousand dollars, has now cost us a few billion dollars of loss in our market cap?!"

Enterprise Admins to Chairman - <Silence>


Chairman to Enterprise Admins - "Who turned down this funding request?"

Enterprise Admins to Chairman - <Silence> (The Enterprise Admins turn to look at the AD Ops Team Director.)


Chairman to Active Directory Operations Team Director - "Who turned down this funding request?"

Active Directory Operations Team Director to Chairman- <Silence> (The Director turns to look at the CISO.)


Chairman to CISO - "Mr. CISO, Who turned down this funding request?"

CISO to Chairman - <Silence> ...


...and so it continued, and I'll let your imagination help you figure out how this all ended.


(Folks, this isn't Rocket Science. This is Cyber Security 101 and common sense, but I suppose, as they say, "Common sense isn't so common!" Even Microsoft does not seem to have fathomed the implications of possessing excessive privileged access in Active Directory, so how can we expect 1000s of organizations worldwide to know about what is likely their Achilles' Heel ?!)

Friday, August 25, 2017

How to Audit Who Can Delete an Organizational Unit in Active Directory?


Dear Microsoft,

Today is Day-14 of our Active Directory Security School for you. Today, I will answer the question I had asked on Day-13 by teaching you how organizations worldwide can correctly audit who can delete an Organizational Unit (OU) in Active Directory.


Microsoft, like my other posts, this one too likely impacts Trillions of $ worldwide, so you'll want to read it with utmost attention.


This post also demonstrates the extent to which your entire global organizational customer-base is operating in the dark today.



So let's proceed, shall we? By the way, if you haven't already done so,
before reading this post, you'll absolutely want to read this post.





Such A Simple Question

The simple question I had asked in my last post was -

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



Microsoft, you likely may not know the answer to this simple question,
so I'll help you and the world figure out how to do this correctly...





First, Let's Rule out the Incorrect Answer

Before I share the correct answer to this most simple of Active Directory questions, let me help the world rule out the incorrect answer, which incidentally may be how 99% of all organizations worldwide may have been answering this question thus far.

If you were to ask this simple question to most self-proclaimed Active Directory Security experts out there, or even to numerous highly-accomplished Active Directory experts and gurus, or to most vendors in the Active Directory solutions space that develop and sell "Active Directory Permissions Audit" solutions, or to thousands of folks who participate in tech forums such as Microsoft TechNet, here's the answer you're most likely to get -

"Oh, this is easy! Simply find out "who has what Standard Delete permissions on the OU", and that's it!"

Many will suggest that you can simply use tools like dsacls or acldiag, or simply write-up a PowerShell Script to do so, and the vendors will suggest using their Active Directory Permissions Audit tools. Sadly, and unbeknownst to them, they'd all be wrong!

acldiag on ou=corp,dc=root,dc=local

In fact, they're not just wrong, they're substantially and dangerously wrong, and yet (and sadly,) this is exactly how most IT personnel at most organizations worldwide may be answering this question at their multi-billion dollar organizations today!

Here's why...






Now, The Correct (And Not So Simple) Answer

This question may be simple, but the answer certainly is not. You see, to answer this question correctly, one needs to consider just what is involved in the deletion of an OU, and although its complicated, I'll do my best to explain it as succinctly as I can -



I. First, The Three Delete Permissions

To begin with, when it comes to deletion, there are three (3) Active Directory security permissions that influence deletions.


  1. Standard Delete - The Standard Delete permission controls the ability of a security principal to delete the Active Directory object in whose DACL the permission resides.

  2. Delete Child - The Delete Child permission controls the ability of a security principal to delete a child object directly underneath an object. If the ObjectType member of the ACE in which this permission is specified specifies a GUID of a specific Active Directory object class, the permission only controls the ability to delete child objects of the specified Active Directory class. If the ObjectType member of the ACE does not specify a GUID, then the permission controls the ability to delete child objects of any Active Directory class.

  3. Delete Tree - The Delete Tree permission controls the ability of a security principal to delete an entire (sub-)tree of objects regardless of the permissions specified on the individual objects in the tree. The root of this tree is the object in whose DACL this permission resides.



II. Second, The Access Checks

When a security principal attempts to delete an Active Directory object, he/she must have one of the following access rights -
  1. Standard Delete on the object itself, OR

  2. Delete Child permissions (for that object type) on its parent object

By the way, this isn't some secret; this is straight from Microsoft MSDN right here.

Further, and additionally, if a security principal's deletion request involves the Delete Tree operation, then if the security principal has sufficient (i.e. effective) Delete Tree permissions on the object that is the target of that operation, then he/she will be able to delete the entire tree of objects regardless of the permissions granted on the child objects.





III. In Light of the Above, Consider This -

With the above theory in mind, now let us consider what it might take to delete a top-level Organizational Unit (OU) that may have thousands of Active Directory objects (such as domain user and computer accounts, security groups and OUs) within it.



In order to be able to successfully delete this top-level Organizational Unit -
  1. If the user has sufficient Delete-Tree effective permissions on the OU AND he/she uses the Delete Subtree Control, he/she will be able to delete the entire OU irrespective of the permission specified on all the child objects in the OU.

  2. If the user does not have sufficient Delete-Tree effective permissions on the OU, then he/she will only be able to delete the entire OU if he/she has sufficient access so as to be able to delete the entirety of all objects contained in the OU (including the OU object itself), and by that I mean that in order to be able to delete the entire OU, he/she will need to have ON EACH OBJECT in the OU (including on that OU object itself), either OF 1) Standard Delete effective permissions on the object, or 2) Delete-Child effective permissions on its parent object.
In short, as one can see, in order to be able to determine who can delete an OU in Active Directory, irrespective of whether or not it is a top-level OU, organizations will have to determine effective permissions on EVERY SINGLE OBJECT in that OU!

Thus, to correctly find out who can actually delete a top-level Organizational Unit (OU) that may contains thousands of Active Directory objects, IT personnel will need to accurately determine effective permissions on thousands of Active Directory objects!




IV. Oh, The Most Important Part

Now, the most important part here is not that IT personnel will have to audit access on not just one Active Directory object (i.e. the OU itself,) but on thousands of Active Directory objects; that of course is very important. The MOST IMPORTANT part here is that IT personnel will need to determine Active Directory Effective Permissions on thousands of Active Directory objects!




I cannot stress this enough - to make this determination, today, all that most organizations may be doing is trying to find out "who has what permissions on an Organizational Unit('s object)" WHEREAS what they need to be doing is trying to find out "who has what effective permissions on all the objects in that Organizational Unit( including that OU object itself)."

I'll say that again. Today most organizations are likely merely performing a useless "Active Directory Permissions Audit" on the OU object itself to try and find out who has Delete permissions on the OU. What they need to be doing is performing an "Active Directory Effective Permissions Audit" on not just the OU object itself, but on every single object in that OU, to find out who effectively has the effective permissions I have mentioned in point 3 above!

The difference is HUGE, and in fact, the difference between having accurate and inaccurate insight could mean the difference between preventing someone from being able to enact a MASSIVE denial-of-service attack or letting them successfully do so!

Microsoft, hopefully now you and thousands of organizations worldwide can see why it is not only completely useless to perform an "Active Directory Permissions Audit" but also that infantile tools like dsacls, acldiag, PowerShell, or any one of many Active Directory permissions audit tools from any one of numerous vendors out there cannot help make this determination accurately!




Side-note: For folks on Twitter, such as one who said this regarding this - "That's it? Make sure your delegation is tight and...no big deal" (here), well this is also what one might consider a delegation in Active Directory, and so trying to find out who can delete a top-level OU would fall under making sure your delegations are tight.  
Thus, I'd really like for this gentleman to not just talk the talk, but walk the walk, because there is a mountain of a difference between the two, and since he makes it sound so easy, perhaps he should show the world how to make sure this delegation is tight!  (Even if he tried for a 100 years, I doubt he'd likely be able to do it.)






Click, Done.

We just established above that trying to find out who can delete a top-level Organizational Unit could be a massive challenge, since it would require organizations to determine effective permissions/access on potentially thousands of objects in that OU.

Now, thanks to you Microsoft, thousands of organizations worldwide don't even seem to know what "effective permissions" are, so obviously for them to possess the ability to determine "effective permissions" correctly is to expect too much from them, in which case obviously, trying to do the above would be almost impossible for them!


So, wouldn't it be nice if someone could make this almost impossible problem a little easier to solve for the whole world?


I think it would. How easy you ask?   Well, how about as easy as touching
a single button?! (Wait, isn't this supposed to be almost impossible?) ...


Here you go (; isn't it amazing what half a decade of laser-focused innovative R&D can do?) ! - 

Gold Finger - Active Directory Effective Access Audit Tool

What you're seeing above is a snapshot of the world's only accurate Active Directory Effective Access Calculator, a tool that can instantly and of course accurately audit and reveal exactly who can delete entire organizational units in any Active Directory in the world, even one that contains thousands of Active Directory objects in it, within a matter of minutes, if not within seconds!

If you wish to see the complete output of this effective access assessment on the Corp OU, you can download it from here.

In fact, not only can it accurately audit and reveal who can delete OUs, it can accurately audit and reveal who can enact 100+ administrative tasks that can be enacted on Active Directory content, such as exactly who can create, delete and manage OUs, accounts, groups etc. anywhere in Active Directory + how they can do so, which is what we need to know to tighten delegations.

This powerful tool is unique in is ability to correctly audit who can delete an organizational unit in Active Directory, in light of the technical details I've shared above, and irrespective of whether the organizational unit contains 100 objects or 100,000 objects.





A Picture Speaks a 1000 Words

The substantial complexity in trying to audit who can delete an OU in Active Directory is perhaps best illustrated with pictures -

If you take a closer look at the Status message in the snapshot of the tool displayed above, you will see that it indicates that during the process of trying to find out who can delete this one single top-level Corp OU, the tool analyzed 11528 ACEs!


That's a bit intriguing, because all we requested was an effective access assessment on a single object i.e. a single top-level OU named Corp, yet the status message indicates that the tool had to analyze 11,528 access control entries (ACEs) to make this one single determination! There couldn't possibly be that many ACEs in the ACL of a single Active Directory object!

This definitely merits a closer look!

In the interest of time, I'll make this super simple for you...


First, in one second, using Gold Finger's Active Directory Security Audit Tool, we find that there are 263 objects in the Corp OU:



Next, in less than five seconds, using Gold Finger's powerful and comprehensive Active Directory Permissions Analyzer, we determine that there are indeed a total of 11494 access control entries (ACEs) on the 263 objects that exist in the Corp OU -


(In fact, an instant Corp OU-wide ACL dump performed with Gold Finger's Active Directory ACL Exporter tool confirms this.)


Now, some basic Kindergarten math i.e. subtracting 11494 from 11,528 leaves us with 34 ACEs.


Hmm, if we consider the Corp OU's parent object i.e. the domain root, and use the Gold Finger Active Directory ACL Viewer to view its ACL, we see that there are exactly 34 ACEs in the ACL of the Corp OU's parent object, i.e. the domain root object -


(By the way, in case you want to view the entire ACL as exported from this nifty tool, it can be downloaded from here.)


Thus, if in the process of determining effective access to find out exactly who can delete the Corp OU, Gold Finger analyzed 11,528 ACEs to make this assessment, it must have analyzed 11,494 ACEs that exist in the ACLs of the 263 objects in the Corp OU (including the Corp OU's ACL itself) as well as the 34 ACEs that exist in the ACL of its parent object, the domain root, since 11,494 + 34 = 11,528!

In other words, to find out who can delete a single top-level OU, one needed to determine effective permissions on not just every single object in the OU, but also on the parent of the OU object!

Here's why -
  1. It needs to determine who has sufficient Delete-Tree effective permissions on the Corp OU object itself, because all users who have this effective permission on the OU will be able to delete the OU.

  2. It needs to determine who has sufficient blanket Standard-Delete effective permissions on the Corp OU object itself AND either Standard-Delete effective permissions on every single object in the OU OR Delete-Child effective permissions on the parent of every such object , because all users who have this combination of effective permissions in this subtree will also be able to delete the OU.

  3. It may optionally need to determine who has sufficient blanket* Delete-Child effective permissions on the Corp OU object itself, if this OU only had a single level of child objects in it, because then all users who have this effective permission on the OU will also be able to delete the OU.

  4. Finally, it needs to determine who has sufficient Delete-Child effective permissions on the parent of the Corp OU object i.e. the domain root object, since that will also influence who can delete the Corp OU (assuming all such users also have sufficient access to be able to delete all objects in the Corp OU except the Corp OU object itself!)
Note - Strictly speaking, there is one other case to take into account (, and our unique tool can optionally take that into account) but I'm not going to mention it here.

So you see, in order to answer what is seemingly such a simple question, one needs to accurately determine effective permissions on every single object in the OU as well as on its parent object!

Now, in the simple example we saw above, there were only about 260 objects in that top-level OU. In the real world, at so many organizations, there are thousands of objects in a top-level OU. In fact, at many large organizations there could be well over 50,000 to a 100,000 objects in a top-level OU!

At most of these organizations, let alone possessing the ability to accurately determine effective permissions in Active Directory, thanks to the lack of any guidance whatsoever from Microsoft, IT personnel may not even know that to make this seemingly simple determination, they need to be able to determine effective permissions on thousands of objects!

Oh, and this is how much effort it takes to make this determination on one OU. What if an organization had 50 or a 100 OUs?! (One of our customers had 20,000 OUs in their Active Directory.) To do so, you'd have to proverbially scale Mount Everest!





[A Small Digression...

The Protect Object from Accidental Deletion Feature

This discussion wouldn't be complete without a quick mention of your feeble Protect Object from Accidental Deletion feature, which is (more of a hack than a feature) designed to accomplish exactly what it states i.e. prevent accidental deletions of OUs.


I imagine that so many organizations out there must think that if this feature is enabled on an Organizational Unit, then that Organizational Unit cannot be deleted, PERIOD. That is a misconception that should be clarified for everyone once and for all.

You see, when you activate this feature on an Organizational Unit, all that the System does is that it introduces two access control entries, one on the object on which it is activated, and one on its parent object, and these are the ones -
Deny  Everyone    Delete, Delete Subtree      (This one is in the ACL of the target object) 
Deny  Everyone    Delete All Child Objects   (This one is in the ACL of the parent object)

It is the presence of these two explicit deny permissions that protects the target object from being accidentally deleted.

Now, of course, anyone who could change the permissions on either the target object or on its parent object could effectively undo, modify or remove these permissions, leaving the object vulnerable to deletion, whether it be accidental or intentional.

But more importantly, it doesn't even take that much to intentionally circumvent this feature!

Specifically, anyone who has sufficient Delete-Tree effective permissions on the parent** object of the object that is protected from accidental deletion could effectively delete the entire subtree rooted at the parent object, and as a consequence, this object (and if happens to be the root of a subtree, such as a top-level OU, then that entire OU) too would end up getting deleted!

So, if you truly want to know exactly who can delete an Organizational Unit, even one that is protected from accidental deletion, you'll also want to find out who has sufficient Delete Tree effective permissions on its parent*** (and technically, all the way up!)

For instance, let us consider another example in which we take a look at the Cyber Security OU (whose properties are displayed in the snapshot above) which as one can see in the snapshot above, is protected from accidental deletion.

As seen below, when a user Michael Karp tries to delete this Cyber Security OU, he is (consequently) unable to do so -



However, if we analyze Active Directory Effective Permissions on the parent OU of the Cyber Security OU, which is the Corporate Security OU, we see that although Michael Karp may not be able to delete the Cyber Security OU, he does in fact have Delete Tree effective permissions on its parent object, Corporate Security OU -


(Incidentally, this tool shown above is the world's only accurate Active Directory Effective Permissions Audit Tool.)

To see the complete output of the effective permissions audit on the Corporate Security OU, you can download it from here.

So, Michael Karp launches LDP and tries to delete the parent OU, i.e. the Corporate Security OU using the Delete Tree control, and he is successfully able to do so, as a result of which the entire Cyber Security OU (which was protected from accidental deletion) is now also deleted -


In the LDP snapshot above, here's what the four numbers indicate -
  1. Unsuccessful attempt to delete the Cyber Security OU (since its protected from accidental deletion)

  2. Unsuccessful attempt to delete the Corporate Security OU (i.e. the parent OU) using various standard delete options

  3. Successful deletion of the entire Corporate Security OU using the extended Delete Tree operation and control

  4. Confirmation that the entire Corporate Security OU no longer exists i.e. no such object!


So you see, this little (hack of a) feature does exactly what it says, prevent an object from accidental deletion!


... End of Small Digression.]






Scaling Mount Everest

Now, just prior to the small digression above, we had started giving some thought to just how much effort it might take to make this determination in an Active Directory domain that had numerous OUs (e.g. 20+), and I had had left it by saying that to do so, one would have to proverbially scale Mount Everest!

Consider that you needed to find out exactly who can delete every single OU in an Active Directory domain that had 50 OUs.


How would you do so? Well, you would have to manually perform the above process on every single OU in the domain (, and by now I shouldn't have to tell you that not only is that almost impossible, if attempted it could take months to do!)  OR ...

What if someone could fully automate performing this Herculean feat for the world, so all you had to do was touch a button?!

Here you go (; its amazing what else half a decade of laser-focused innovative R&D can do) ! -


What you're seeing above is a snapshot of the world's only accurate and fully-automated Active Directory Administrative Access / Delegation Audit Tool, a tool that can instantly and of course accurately audit and reveal exactly not only who can delete every single entire organizational unit in any Active Directory in the world, even one that may contain thousands of Active Directory objects in it, within a matter of minutes, if not within seconds, but in fact can accurately audit and reveal exactly who can perform virtually the universe of all administrative tasks that may be possible in Active Directory.

If you wish to see the complete output of the domain-wide OU deletion effective access audit, you can download it from here.

For example, not only can it accurately audit and reveal exactly who can delete every single OU in an Active Directory, it can also accurately audit and reveal exactly who can create, delete and manage every single domain user account, domain computer account, domain security group, container, OU, service connection point, print-queue etc. in Active Directory.

As it pertains to object deletions, simply put, whether you have one OU in your Active Directory or whether you have 100s of OUs, this tool can instantly, automatically and above all, correctly determine exactly who can delete each one of these OUs.


(Of course, if it couldn't deliver such paramount cyber security insight at the touch of a button, it wouldn't be called Gold Finger, i.e. a tool that can deliver informational security gold at the touch of a single button (i.e. at the tip of a finger), thus the name.)

But, this isn't about promoting the tool so I'm not going to say any more about it. The only reason I mentioned it, is to prove that if one truly cares for the world and puts one's mind to it, even such an incredibly difficult technical challenge can be solved. In contrast, you (Microsoft) couldn't even educate the world about the importance of effective permissions over an entire decade :-(






This Impacts of Trillions of $ Worldwide

Microsoft, as you obviously know, literally the entire world is running on Active Directory today. In effect thousands of organizations, many of whose market capitalization is easily in the billions of dollars, operate on Active Directory.


Consequently, today foundational Active Directory deployments help secure and protect trillions of dollars of wealth worldwide.

Now, at these organizations, the entirety of their domain user accounts, computer accounts, security groups etc. all reside in their foundational Active Directory deployments, within organizational units of course!

At most of these organizations no one has any idea as to exactly who can delete not just all their OUs, but even their top-level OUs in their foundational Active Directory deployments, and thus most of them may be minutes away from an intruder or a malicious insider being able to launch a crippling denial-of-service attack in seconds, by simply deleting their top-level OU(s)!

Were such an attack to be launched on them internally, organizations that have up-to-date backups may experience an entire day of downtime, and organizations that do NOT have up-to-date backups could experience days (if not weeks) of downtime!

Now, I don't have to tell you how much one day of downtime could 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 if you know of any company that could survive weeks of downtime in today's fiercely competitive world, let me know.

In essence, due to a complete global lack of ability to obtain accurate effective access insight into something as simple as who can delete an organizational unit in Active Directory, trillions of dollars of wealth across the world could be so easily impacted!





In Summary

Microsoft, in summary, here are the salient points I wanted to convey to you concerning this vital topic -


  1. Active Directory is the foundation of cyber security at 1000s of organizations worldwide, and in the Active Directory deployments of these organizations, all their building blocks of cyber security are stored in Organizational Units.

    In the Active Directory of most organizations, an excessive number of individuals may have sufficient effective permissions/access to be able to delete these Organizational Units, yet no one knows exactly who they are.

  2. Should someone be able to delete one of these Organizational Units, especially a top-level one, he/she would basically and most easily have inflicted a massive internal denial-of-service (DoS) attack on the entire organization within minutes, since no one (including of course all employees, contractors, senior executives including C*Os, as well as IT personnel) will be able to log-on or engage in their computing activities, until the Active Directory is restored using a backup.

    Organizations that have an up-to-date backup of their Active Directory may be able to recover within a day, but at organizations that do not have an up-to-date AD backup, it could take weeks to recover from such an attack. 

  3. Organizations thus must know at all times exactly who can delete their Organizational Units. This is not just a "nice to know" thing; this is an integral part of cyber security and thus a responsibility the organization has to its stakeholders, predominantly its shareholders as well as its customers, partners, employees and others.

  4. Sadly, thanks mostly to you Microsoft, IT personnel at most organizations worldwide don't even know how to correctly audit who can delete their OUs, so obviously they are far away from being able to identify and lockdown who could launch such a simple yet massive internal DoS attack that could cost them millions of dollars per occurrence.

  5. Let alone possessing the ability to help these organizations figure this out, you haven't even educated them about how to correctly do so, which is concerning, given that you're going all out to woo the world to embrace your Cloud offering!

    I felt that it was important for organizations worldwide to know why it is so important for them to know exactly who can delete their Organizational Units, esp. top-level OUs, so, above I have now educated them about how they can do so.

    I just find it concerning that even though here we are in 2017, i.e. 17 years after Active Directory was shipped, and yet someone is having to explain such a basic and fundamental aspect of Active Directory and cyber security to the world!

Given what it is we do here at Paramount Defenses, my time is very valuable, and while we're doing our bit to help secure and defend organizations worldwide, you, the $550 B Microsoft, need to do your bit by educating your customers about this stuff!


We are here to help them, but we cannot educate them all about such basic cyber security stuff - that's your responsibility.

Best wishes,
Sanjay


PS: To Satya and team at Microsoft, you may want to ask your IT folks if they know exactly who can delete your own OUs. If they too need help figuring it out, feel free to give us a call, and time permitting, we'll be happy to consider helping them out.


Aug 30, 2017 Update - I penned this today to help organizations better understand the importance of what is shared above.

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.

Saturday, August 5, 2017

How to Correctly Audit Who can Create User Accounts in Active Directory

Folks,

Earlier this week, I had posed a most simple question to the respectable $ 550 Billion Microsoft Corporation regarding possibly the most elemental and fundamental aspect of cyber security and identity management, and that question was -

Exactly how do/should organizations find out exactly who can create domain user accounts in their Active Directory? (and ideally also, where they can do so & how)

Now, of course, Microsoft's likely not going to respond (for obvious reasons), and because this is so important to organizational cyber security, I'll provide the answer today. Ideally Microsoft should have educated organizations about this 10 years ago!

I'll not only answer the question, I'll show you how to easily answer this question.




First, A Scenario to Visualize

To help visualize this problem, let us begin by considering a single Active Directory domain of a fictional organization. As is the case with most organizations, and as displayed above, this fictional organization has a fairly elaborate organizational unit (OU) tree hierarchy/structure, the design of which was dictated by a combination of their group policy and permissions inheritance requirements. In essence, assume that it is more than 6 levels deep, and includes 60+ organizational units (OUs).






Next, Just Enough Technical Background

Like everything else in Active Directory, even (domain) user accounts are objects, and thus the administrative task of creating a user account in Active Directory corresponds to an LDAP operation targeted at the parent object and involving the creation of an object of class User, and this LDAP operation is gated by a specific Active Directory security permission: Create Child - User.

In practice, the presence of either one of the following permission combinations on a candidate parent object in Active Directory would influence a user's ability to create user objects in Active Directory, the premise being that Create All Child Objects obviously includes Create Child - User and similarly that Full Control obviously includes Create All Child Objects -
1. Create Child - User 2. Create All Child Objects 3. Full Control

Oh, and speaking of candidate parent objects in Active Directory, while most people likely just assume that you can create user objects under organizational units, strictly and technically speaking, it is the Active Directory Schema that defines and governs (via an attribute in Schema Class definitions) the specific types of objects that may be created under specific types of objects.






Oh, and Debunking a Myth - Finding out Who has What Permissions in Active Directory is NOT the Answer

Most IT personnel and vendors in the Active Directory space are familiar with the above technical background, and if you ask them this simple question "How to find out who can create domain user accounts in Active Directory?", you'll likely get one of the 2 most common answers, depending on whom you ask -
  1. If you ask the vendors, their answer will likely be - "Sure, this is simple. All you have to do is perform a permissions audit in your Active Directory to find out who has the above specified permissions in your Active Directory, and that's it, you're done! Oh, and our amazing "Active Directory Permissions Audit Tools" can help you get the job done in no time!"

  2. If you ask most IT personnel, their answer will likely be - "Sure, this is simple. All we need to do is perform an Active Directory permissions audit to find out who has the above specified permissions in our Active Directory, and that's it, we're done! Oh, and tools like PowerShell Get-Acl, AclScanner, dsacls, acldiag, Bloodhound, etc. let us do this easily!

Guess what?! Unfortunately, both these answers are wrong.

In fact, they're not just wrong, they're dangerously wrong. Simply finding out "Who has what permissions in Active Directory" aka performing an "Active Directory permissions Audit", is not the answer and it is NOT going to give you accurate results, and the last time I checked, when it comes to cyber security, accuracy is paramount. Of course, if you don't care about accuracy, ... .

By the way, if you want to know why these answers are so wrong, you will absolutely want to read this.

To accurately answer this and all such questions related to "Who can do what in Active Directory", what organizations need to do is find out "Who has what effective permissions in Active Directory," / "Who has what effective access in Active Directory."





Active Directory Effective Permissions

One of the most important measures organizations worldwide can take today is understand the one paramount aspect of cyber security that impacts the security of just about everything in their IT infrastructures - Active Directory Effective Permissions.

I am not going to explain what Active Directory Effective Permissions are in this post, as I have already explained it thoroughly in that post pointed to by the link above, but you will definitely want to read that before proceeding any further in this blog post.

In order to find out who can create domain user accounts under a specific Active Directory object, such as an Organizational Unit (OU), all that we need to do is find out "who has sufficient effective Create Child - User permissions" granted on that OU.





Now, The Answer to This Trillion Dollar Question

With the above background and concepts in mind, we are now in a position to answer this simple cyber security question.

Theoretically, here is what it takes to answer this question -
  1. The first step is to identify all objects in Active Directory under which the Schema permits the creation of objects of class User. This step is needed because as noted above, we need to determine "who has what effective permissions" on all objects under which objects of class User can be created, so in order to be able to do so, we will first need to identify each one of these objects. It is these objects on which we will need to determine effective permissions.

  2. The next step would be to accurately determine effective permissions on each one of the Active Directory objects identified in step 1 above, to identify all users who have sufficient effective Create Child - User permissions on them.

  3. The final step, which is the simplest one, merely involves aggregating the individual results of step 2, as performed on each one of the objects identified in step 1, to ultimately arrive at the complete list of all individuals who can create domain user accounts in an Active Directory domain.  

So you see, there is a WORLD of a difference between what the world thinks the answer is, and what the answer actually is!

Keep reading...




A Herculean Challenge

Now, while the answer to this simple question seems simple, in reality, it represents a herculean challenge for the world today.

Here's why -
  1. To begin with, the actual technical process involved in accurately determining effective permissions in Active Directory is very complicated, expertise-reliant, time-consuming and error-prone. In fact, even just the expertise required to know how to correctly do this alone is extremely rare, and hardly anyone in the world could engage in this process repeatedly without making mistakes, and unfortunately, in cyber security, there is no room for mistakes. Thus, even if organizations were to attempt to try and do this manually, most organizations likely won't even have the expertise to do this correctly.

  2. Secondly, the capability (i.e. tooling) required to be able to accurately determine effective permissions in Active Directory is virtually non-existent (barring one tool.) In fact, not a single vendor in the Active Directory space or any cyber security company (barring one) in the world has ever built a tool that could accurately determine effective permissions in Active Directory. The only tooling available in the world is Microsoft's Effective Permissions Tab, which unfortunately is not only inaccurate, it is substantially inadequate, and here's why. Oh, and this little excuse of a tool is dangerously inaccurate.

  3. Finally, there could easily be hundreds if not thousands of objects in an organization's Active Directory domain under which the Schema permits the creation of objects of class User. Consequently, at many organizations, to answer this question, they would have to accurately determine effective permissions on hundreds, if not (on) thousands of objects, and to do that manually could take months, if not years, let alone the fact that the data would be obsolete within days anyway, considering that the state of permissions in Active Directory do change every so often.

In light of the above, how are organizations supposed to be able to answer what is such an elemental cyber security question?!





Where is Microsoft ?

In light of the above, if you agree that this is an important question for organizations to be able to answer today (and if not, I could share with you many more such questions, all of which involve a similar process to answer), then in light of everything I have shared above, is it not worth asking how, if in any way, Microsoft may be helping organizations answer this question?

Unfortunately, let alone helping organizations answer this question, for more than a decade now, Microsoft has not even shed light on what it takes to answer this question. Most recently, and in all likelihood, in response to this, when it finally provided some guidance on the subject, again it completely missed out on educating the world on how to correctly answer this question!

That's how much Microsoft seems to care about cyber security. Yet, it would love for the world to embrace its Cloud offering!






What is the World To Do?

I'm told last year almost $ 80 Billion was spent worldwide on Cyber Security. As you all know, over 85% of all organizations worldwide are operating on Active Directory, and yet, not a single one of these organizations likely has an accurate answer for such a simple, elemental and fundamental cyber security question!

What is the world supposed to do? How are thousands of organizations worldwide supposed to be able to answer this most basic, elemental and fundamental of all cyber security questions, and what's the point when, even after spending millions of dollars on cyber security, an organization can't even accurately answer "Who can create user accounts in Active Directory?"

A while back, we had a prominent 3-letter acronym government agency reach out to us. They had well over 10,000 OUs in their Active Directory domain, and (perhaps because someone had been able to create and misuse a domain user account,) they wanted to know if we could help them identify exactly who can create domain user accounts in their Active Directory.






We are Paramount Defenses

Please allow me to show you how thousands of organizations worldwide can instantly and accurately find out exactly who can create domain user accounts in their Active Directory, where, and how, at the touch of ONE button -

Gold Finger Administrative Access And Delegation Audit Tool

The Administrative/Privileged Access and Delegation Audit Tool, a part of our Gold Finger Active Directory Audit Tool Suite can instantly and accurately determine effective permissions/access across an entire Active Directory domain, whether it has a 100 objects or a 100,000+ objects, and reveal in plain English exactly who can create domain user accounts in Active Directory.

In fact, not only can it audit (identify and reveal) exactly who create domain user accounts in Active Directory, it can accurately and automatically audit exactly who can enact over 100 administrative tasks in an Active Directory domain, no matter its size.

With Gold Finger, here's what it takes to answer this simple, elemental and fundamental cyber security question -
  1. Launch Gold Finger
  2. Select Report #1 - "Who can create Domain User Accounts"
  3. Set the Scope to be the entire domain. (By default, it is already pre-set for you.)
  4. Press the Gold Finger button. 
That's it!

Within minutes, Gold Finger will automatically identify all such objects under which domain user account creations are permitted (by your unique Schema), then perform the herculean task of accurately determining effective permissions/access on each one of them, whether it be on 10 OUs or on 10,000+ OUs and containers, to correctly figure out and reveal the identities of everyone who can actually create domain user accounts in your Active Directory, as well as where (i.e. under which OUs) they can do so, and how they can do so (i.e. which permissions in the underlying ACLs entitle them to do.)   [Sample output - CSV, PDF.]

(The BIG advantage of knowing the HOW is that if there are users who can create domain user accounts but who should NOT ideally be authorized to do so, organizations can at once tweak the appropriate permissions/groups to revoke their access.)

So you see, all that IT admins need to do is click a button and sip their favorite beverage while it almost magically does it ALL.


A Note To My Friends at Microsoft: Gentlemen, I want you to think about this for a moment - imagine being able to automatically and accurately determine effective permissions on hundreds of thousands of objects in Active Directory in a single shot, and not just that, also figure out what administrative tasks they end up entitling and then present the results in terms of administrative tasks, so that IT personnel worldwide can easily comprehend them and act upon them. Imagine that!
In light of this, travel as far as needed, from Silicon Valley (the hot-bed of venture capital funded companies) to Israel (the hot-bed of cyber security companies these days) and across the whole world, and if you can find me even ONE company that can do anything even remotely close to this, let me know.


This tool is our flagship tool. It embodies our unique, patented effective-access assessment technology, and is the culmination of over half a decade of innovative, focused and disciplined research and development. Simply put, it is simultaneously both, the Rolls Royce and the Lamborghini of Active Directory Audit Tools.




Summary

Microsoft Active Directory is the very foundation of cyber security at over 85% of all organizations worldwide today. At these organizations, the need to know exactly who can do what, where and how, in Active Directory domains is paramount to cyber security, because the entirety of all building blocks of cyber security, from domain user accounts to domain computer accounts and from domain security groups to group policies are all stored, managed and protected in Active Directory.

There is only one correct way to find out who can actually do what in Active Directory, and that involves accurately determining effective permissions in Active Directory. In other words, it is not "who has what permissions in Active Directory" that matters, but in fact "who has what effective permissions in Active Directory that matters."

Unfortunately, the process involved in accurately determining effective permissions in Active Directory is extremely complicated.

Yet, to be able to answer so many vital cyber security questions, such as "Who can create domain user accounts in Active Directory", not only do organizations absolutely need to be able to determine effective permissions in Active Directory, but in fact, depending on the size of their Active Directory domains, may also need to determine effective permissions on possibly hundreds if not thousands of Active Directory objects, and do so often since Active Directory permissions do often change.

Sadly, Microsoft does not seem to have done much to help the world in this vital regard. In fact, they apparently even forgot to educate the thousands of organizations that operate on Active Directory regarding the importance of Active Directory effective permissions. Further, while there are almost a thousand cyber security companies in the world today, not a single one of them has a solution that can help organizations accurately find out the answer to even such basic and elemental cyber security questions as "Who can create domain user accounts in Active Directory?"

Fortunately, organizations worldwide that DO care about knowing the answer to not just this vital question, but also many other similar, equally important questions that impact their foundational cyber security, now do have an option and can now do so.


That'll do it for today, Day-12.

Best wishes,
Sanjay


PS: To anyone who wishes to see just how inaccurate virtually all Active Directory permissions audit tools out there including PowerShell Get-Acl, AclScanner, dsacls, acldiag, Bloodhound, etc.. are, all you need to do is compare its results to those of Gold Finger. The simple fact is that none of those tools can accurately determine effective permissions, which is all that matters.

PS2: In case you're wondering why this was a Trillion $ question, please read this.