How To Easily Identify & Thwart Sneaky Persistence in Active Directory

Folks,

This is my umpteenth Trillion $ post.

A few weeks ago, a presentation titled An ACE Up The Sleeve - Designing Active Directory DACL Backdoors at the Black Hat Conference 2017 (which we skipped) apparently made waves and caught the attention of the world, including that of Microsoft.

In this presentation, a whitepaper on which can now be downloaded from here, its authors have presented what may seem like a ground-breaking revelation to those uninitiated to the subject, but what actually is merely just Active Directory Security 101.

I must say that for someone likely new to the subject, the authors of this presentation at least seem to have (correctly) figured out that entire kingdoms can be owned if you get deep enough into the ocean of a subject that is Active Directory Security.

What surprised me far more is to see Microsoft apparently struggling for an answer to this; here's proof - in the last ONE month alone Microsoft's ATA Team has posted TWO blog posts in response to this presentation, on Sep 18 here and on Oct 11 here.

I find it surprising because when I was at Microsoft, as Program Manager for Active Directory Security, I authored Microsoft's official 400-page whitepaper on the subject, titled Best Practices for Delegating Administration in Active Directory, and that was a decade ago. Even if you read just the Appendices of that Microsoft whitepaper, you'll know far more than most folks out there.

Today I'll show how everyone can easily thwart sneaky persistence in Active Directory, and the key to it is literally Everyone ;-)





First Some
Theory

Their exhaustive whitepaper on this material was 64 pages long, and full of detailed technical material. All those details may have been necessary to explain all this to a majority of cyber security folks out there, both on the good, and on the bad side.

However, for those of us who have been doing this for 17+ years, we can get to the crux, and the bottom of it, in ONE minute.


So to help everyone understand the basis of this rather simple solution, here's some very quick Trillion $ theory -

• Active Directory stores and protects the entirety of an organization's building blocks of cyber security, from all of its domain user accounts to all of its domain security groups, and all these blocks are protected by Active Directory's solid, incredibly powerful and sophisticated security model (, which it had better be, considering that today it helps secure trillions of dollars of wealth, worldwide.)
• Speaking of security, simply put, each Active Directory object is protected by an access control list (ACL), which contains one or more access control entries (ACEs), each one of which specifies (i.e. Allows or Denies) one or more Active Directory security permissions (of which there are 11 generic permissions, and 80+ special permissions, (i.e. Extended Rights and Validated Writes)) for a specific security principal, either explicitly or via inheritance.  
• These Active Directory security permissions include List Child, List Object, Read Control, Read Property, Write Property, Create Child, Delete Child, Standard Delete, Delete Tree, Write DACL, Write Owner, Validated Writes and Extended Rights (of which there are 80+), and they govern everything from the ability to create, delete and modify Active Directory objects, to the ability to modify both the owner of and the permissions on the objects themselves, as well as the ability to view Active Directory objects. Further, each Active Directory object has an owner, and the owner implicitly has the ability to modify permissions (i.e. Write DACL aka Modify Permissions) on the object. 
• Finally, because each of these security permissions can be specified for both users and groups, and a user could be a member of various such groups, it follow that multiple permissions specified in an Active Directory ACL could impact the actual permissions a user has. Since permissions can overlap as well as conflict, a precedence order governs which security permissions will prevail over the others, and the resulting set of permissions a user ends up with on an Active Directory object is generally referred to as the user's Active Directory effective permissions. 
• Thus, theoretically, anyone who has sufficient Modify Owner or Modify Permissions effective permissions on an Active Directory object, could control and thus possibly allow or deny literally anyone or literally Everyone (the well-known security principal S-1-1-0) any permission on the object.
• Now, and so, as it pertains to controlling an object's visibility, there are in fact 2 modes, the List Child mode (default mode) and the List Object mode in Active Directory that govern object visibility. In the List Child mode, an object will only be visible to a user if he/she effectively has List Child permissions on its parent object. In the List Object mode, an object will only be visible to a user if he/she effectively has both List Child permissions on the parent object AND List Object permissions on the object itself. (By effectively, I mean effective permissions.)

Now, taking all of that theory into account, here's the essence of this attack vector -

If a user were to specify  Deny  Everyone  List Child  permissions explicitly on an Active Directory Organizational Unit (OU), then literally no one (including privileged users) would be able to see the contents of that specific OU. 

That user could then possibly hide objects in that OU, such as a domain user account that he/she may have full control over, and that may directly or indirectly be a member of an Active Directory privileged group, or that may have powerful modify effective permissions on various other objects in Active Directory (e.g. AdminSDHolder.)

Since no one would have visibility into that OU, no one (including privileged users) would be able to see them, and thus not only could these hidden objects be around for a long time (i.e. "persist"), they could also be used at-will to (re-)obtain privileged access in Active Directory!

That right there, is the essence and the crux of this most simplistic attack-vector called "sneaky persistence in Active Directory."





Next, Just 2
Questions

Before I show you how to easily mitigate "Sneaky Persistence in Active Directory", I'd like to pose just two questions, one to the authors of that presentation/white-paper, and one to the experts at Microsoft, because these questions are very important -

1. Question to the authors - How did the attacker get Modify Owner / Modify Permissions effective permissions on the domain user object and the OU he/she wished to hide, to begin with? I ask because by default, ordinary (i.e. non-privileged) domain user accounts do not have these effective permissions either on themselves or on OUs, to begin with.
   
   One of a few possible answers could be - He/she was a member of a privileged Active Directory security group, or a member of a group to which these permissions had been delegated, and thus had these effective permissions.
   
   The point being that it should be made very clear that not just any domain user account can enact this attack-vector. Only those individuals who have either sufficient modify permissions effective permissions, or sufficient modify owner effective permissions on the relevant objects in Active Directory, or the Take ownership privilege on DCs, can do so.



2. Question to Microsoft - If a user does not have sufficient List Child effective permissions on an Active Directory object, then should he/she be able to view its child objects? I ask because in your latest blog, you're publicly wondering as to - "So, this made me think - is there a way we can identify all the objects to which I don't have permissions?!"  
   
   If the answer is NO, which it absolutely should be, and IS, then you shouldn't even be wondering if there might be a way to do so, because there shouldn't be a way to do so, and if you may have found a way to do so, then shouldn't that technically be an error (or what some might casually call a bug) and a security issue that should be fixed?! 

I could ask 50 such questions to the authors and to Microsoft, and perhaps I may, but for now I'll leave it at this.

Finally,
The Answer

Now, and finally is the answer, and its so unremarkably simple that I can't believe I'm having to spend my precious time on it.

Here's the PREMISE for the answer -

The objects in question appear hidden to us due to one and one reason only, i.e. in the ACL of their parent object is a very specific ACE -  Explicit   Deny   Everyone    List Child   This object only / This object and all child objects 

In light of the above, here's the ESSENCE for the answer -

Consider this - one may not be able to view the hidden object, but one can definitely view and inspect the ACL of the parent object, because by default Authenticated Users have amongst other permissions, blanket Read Permissions on all objects in Active Directory.

So, literally all that one needs to do is perform some very basic Active Directory permissions analysis (which you could do with PowerShell, dsacls, or any professional-grade Active Directory Permissions Analyzer) to identify all such objects (typically OUs and Containers) in whose ACL Everyone is explicitly denied List Child permissions!

Once you've identified all such objects, all you'll need to do is remove these ACEs from their ACLs, and you'll instantly be able to see all such hidden objects i.e. there will be no more sneaky persistence in Active Directory! 

You see, that's how elementally and unremarkably simple this is. That's it, and that's all there is to it!


In fact, since seeing is believing, let me SHOW you how easy this is to do step-by-step -

1. Consider the following fictional Active Directory domain -
   
   
   
   
   Might there be any "hidden" objects in this domain? We don't know, and if there are any "hidden" objects in it, we certainly won't be able to see them! So let's figure this out, shall  we?! 



2. Its time for some basic Active Directory permissions analysis so I launch this tool, select the report "Who has what permissions in an Active Directory tree?", set Find settings as follows, set scope to be the domain, and click a button -

   Find  Explicit  Deny  List Child  permissions, granted to a specific security principal, Everyone

   
   
   The tool then goes to work, analyzing every single ACE in the ACL of every single Active Directory object in this domain, identifying all such objects in whose ACL there exists an ACE that matches the exact permission combination we're looking for, and once its done, if there are any such objects, it will have identified all such objects, within seconds.
   
   
   
3. Oh look, it found ONE object in this Active Directory domain, in whose ACL there exists the exact specific permissions we're looking for i.e. Explicit  Deny  List Child  permissions, granted to a specific security principal, Everyone -




Specifically, if you see the Where pane, you'll see that this exact ACE was found in the ACL of the Africa OU, whose DN is "ou=Africa,ou=Corp,dc=root,dc=local", and if you see the What pane, you'll see the exact ACE in that OU's ACL!



4. Let's confirm this finding by viewing the ACL of the Africa OU object -
   
   
   
   We now have visual confirmation that indeed there is an Explicit  Deny  List Child permissions, granted to Everyone.
   
   Now that we've found at least one such object, we know that there likely may be "hidden" objects in our Active Directory, because if there exist any objects that may be child objects of this object, then certainly they're currently hidden from us.
   
   



5. Let's take a quick look by focusing on the Africa OU in the Active Directory Users and Computers Snap-in -
   
   
   
   
   As we can see above, visually, this OU certainly appears to be empty i.e. there do not seem to be any objects in it.
   



6. If there indeed are any these "hidden" objects in this OU, then to unhide these "hidden" objects, all we need to do is remove the ACE that is specifying an Explicit  Deny  List Child permissions to Everyone -
   
   
   
   
   



7. Having removed this ACE, let's refresh the Africa OU in the Active Directory Users and Computers Snap-in to see if there in fact exist any "hidden" (child) objects in it -
   
   
   
   
   Viola' ! Sure enough, we can NOW see that there in fact was ONE "hidden" object inside the Africa OU, and although it is not clear what the Schema class of this object is, we can see its name, which is Amateur Bad Guy.
   
   The most likely reason we cannot see much about this object is that whoever hid it in there may also have specified some form of deny permissions to prevent everyone from being able to read its properties, and perhaps even from viewing the permissions protecting this object. (That sounds very much like what's described in that whitepaper!)
   

Ah, let's stop right here for a moment, because right up there we've just thwarted sneaky persistence in Active Directory!

You see, with the right tooling for the task, it took us just 4 seconds to find all suspect objects in our Active Directory, i.e. those in whose ACL there were Explicit  Deny  List Child permissions granted to Everyone, 6 more seconds to verify this in ADUC, and then a mere 4 seconds to remove that ACE. A quick refresh of ADUC took another 6 seconds, and we're still at 20 seconds, and we've been able to find all "hidden" objects (which in this illustrative example, was 1 object) in this Active Directory domain!

In comparison, consider this...

In the whitepaper, regarding Defenses, the authors state - "Some defenders may believe the detection of these types of backdoors is a lost cause... ...the primary method for detection and investigation remains properly tuned event logs for DCs...  ... one interesting defensive tool is the use of AD replication metadata." etc.   Seriously?!

Oh, and the most amusing part is to see Microsoft try even harder, and I'm quoting this verbatim from here - "This does sound like an issue...  ...so, this made me think - Is there a way we can identify all the objects to which I don't have permissions?" 😉

Microsoft, when you say such things, it makes us wonder - How well does Microsoft understand Cyber Security ?

Again, wasn't this SO easy? To reiterate, literally, all we had to do is identify all objects in our Active Directory in whose ACL there is an Explicit  Deny  List Child permission granted to Everyone! The rest is easier - remove these ACEs, and you're done!




The rest of it is just about taking control over that "hidden" object, and below I have shown just how easy that is too -

8. Now, let us attempt to take a look at the Properties, and in particular the ACL of this Amateur Bad Guy object in ADUC, which can be viewed by clicking on the Security Tab -
   
   
   
   
   As one can see above, whilst attempting to open the Security tab, we are notified that we do not have sufficient access to view the permissions protecting this object, which is what we had suspected. Specifically, the message states that -
   

   "You do not have permission to view the current permissions settings for Amateur Bad Guy. It can not be determined if you have the permission to make changes. Permission changes will be allowed but it can not be guaranteed that the changes will successfully apply."
   
   




9. When the Security tab is opened, the Permission entries field seems empty.
   
   
   
   
   This indicates that the amateur bad guy may have specified a permission denying say Full Control to Everyone, as that would also include denying the ability to view the object's Security Descriptor, and thus its DACL (Permissions), SACL, Primary Group and Owner fields.




10. So, let us attempt to click the Owner tab to see if we can see the object's owner.
    
    
    
    
    Sure enough, we are unable to see the object's owner, which is consistent with our hypothesis that the owner of this object may most likely have denied Full Control to Everyone on this object. However, as evidenced by the following message, if we have sufficient effective permissions or the appropriate privilege, then we could take (or change the) ownership of this object.
    
    Specifically, the message states -
    

    "You can take or assign ownership of this object if you have the required permissions or privileges."

    
    Now, because I'm logged in as a Domain Admin, I do have the "Take ownership" privilege, so I should be able to take ownership of this object, and/or assign someone else as its owner, so I am going to assign ownership to the Domain Admins group.
    
    



11. I proceed to click the Other Users and Groups button, and specify that Domain Admins be the new owner of this object -
    
    
    
    
    I then click OK again.
    



12. As one can see below, I have been successfully able to change the object's ownership to Domain Admins -
    
    
    
    
    As one can see above, the object's ownership has now changed from Amateur Bad Guy to Domain Admins!
    



13. Now, since I'm a member of the Domain Admins group, I'm effectively an owner of this object, and thus I now have implicit Modify Permissions security permissions on this object, so I should now also be able to view the permissions protecting this object -
    
    
    
    
    Indeed, as seen above, I can now see the object's permissions, so let's see what we find, shall we?
    
    



14. Ah, there it is. There is the ACE specifying Explicit  Deny  Full Control permission granted to Everyone on this object!
    
    
    
    
    It is this explicit deny ACE that was preventing us from seeing the properties and permissions on the domain user account object of this amateur bad guy.
    
    So I proceed to remove that ACE! With that ACE no longer being there, we should now be able to clearly see the object in ADUC, so let's see if we can do so.
    
    



15. As one can see, now we can clearly see the object in ADUC -
    
    
    
    
    There you go. We now have Full Control over this object!
    
    

So, there you have it. We easily identified and thwarted "sneaky persistence" in Active Directory. Could this have been easier?

Two quick points -

1. A smart attacker could have made Everyone a member of some security group and granted the Explicit  Deny  List Child to that security group instead. In that case, to find all such objects, all you need to do, is that in the Fields setting above, in the granted to part, change the granted to a specific security principal part to granted to all security principals.


2. If you are primarily interested in searching for hidden user objects, and you have a large Active Directory domain, you can substantially speed-up and optimize the entire process by merely specifying and applying a simple LDAP filter such as (|(objectClass=organizationalUnit)(objectClass=container)). This will result in the tool only retrieving the ACLs of all OUs and Containers, and avoid retrieving the ACLs of every single object in your Active Directory (of which there could be thousands of user accounts, computer accounts, security groups etc.) which is unnecessary, because you can only instantiate user accounts under OUs, Containers and any other object classes permitted by your Schema.

Finally, to be completely objective, I just wanted to mention that since Active Directory permissions audits are relatively easy to perform (compared to say this or this), you can use any permissions analyzer of your choice. I only illustrated the above with our tooling because it is the easiest way I know of to perform such analysis. This isn't a plug for our tool; this is too easy for us.





Now, Consider This...

You see, most folks would stop there. But that is where experts begin, and here's a preview of what they'd focus on next...

You see, since this Amateur Bad Guy domain user account that we just uncovered doesn't really belong to any specific employee or contractor, there are three things I'd really want to know -

1. Who might have planted this? Active Directory audit logs could possibly have this answer, but this could easily have been planted months/years ago, so another way to answer this question might be by answering the next question.


2. Might there be any suspect backdoors left in the ACL of this object that could allow whoever planted this hidden account, the ability to regain control of it, and if so, whom do they lead to?


3. What effective privileged access might this account have in Active Directory? This is vital to know because if someone went through the trouble of hiding this account, it must likely have privileged access somewhere in Active Directory.

In my next post, I'll show you how to answer each one of these three questions. I'm not doing so in this post only because this has already been a long post, and perhaps its best to keep its focus on to identifying any hidden objects in Active Directory.




Okay, I'll give you a very quick preview of my next post!  See, I figured I'd try and find out who all might have Modify Owner effective permissions on this Amateur Bad Guy's account, so I used this tool to figure it out in seconds, and look what I found! -

The details will follow in a few days :-)







"Real" Dangerous Sneaky Persistence in Active Directory

Folks, sneaky persistence based on merely "hiding" objects is rather easy to identify and thus thwart, and thus is generally a trick used by those new to the subject, because as I've just illustrated above, this can be easily identified and uncovered.

"Real" sneaky persistence in Active Directory is what experts use, and it involves exploiting the sheer complexity of the ocean of Active Directory security permissions that exist in Active Directory ACLs to, as they say, hide in plain sight, wherein none of it is obvious, and detecting it substantially more difficult.

Let me give you an example - imagine that in the ocean of (i.e the millions of) Active Directory security permissions that exist in an Active Directory, within the ACLs of thousands of Active Directory objects, a proficient perpetrator could add merely 3 ACEs, each one granting a completely unsuspected group completely normal seeming security permissions, but in reality, if you could connect the dots, you'd have found a privilege escalation path that begins from a completely uninteresting and unsuspected unprivileged domain user's account and leads directly and unhindered to unrestricted privileged access in Active Directory.

You may not believe this, but in most Active Directory deployments worldwide today, there already very likely exist thousands of such paths, and its not even because they may have been purposefully paved. In fact, they exist today primarily because of what is described in this trillion dollar document.

That is "real" sneaky persistence, and its very dangerous, because its extremely difficult for most IT personnel to detect!

In fairness to the authors of this presentation/whitepaper, I should also mention that they may have very briefly alluded to "real" sneaky persistence in two paragraphs in the section "Stealth Primitive - A "Patsy" User."  Unfortunately, their claim that their toolset (Bloodhound) can walk these types of relationships back, but that this task is not trivial using other toolsets is inaccurate. In fact, their own tooling (self admittedly) doesn't take "effective permissions" into account, and thus may be quite inaccurate.

I am not going to go into the details of "real" sneaky persistence in this post, because that is a topic best addressed in its own stand-alone blog entry, so my next blog entry in a few days, will be on that. Oh, and even though "real" sneaky persistence is almost a 100 times more difficult to identify, I will also show you just how easily organizations can now do that as well.

You see, all it too needs, is An (ingenious ability to find the right) ACE up the (entire populace's) Sleeve.





A Quick Note on Their Backdoor Case Studies

If you read the whitepaper, you'll find that the second-last section is Backdoor Case Studies, in which they've done their best to bring everything they've learnt about the subject, together, to show how sneaky persistence can be used to plant backdoors.

In fact, here are a few topics on which they've shared a few backdoor case studies - a DCSync Backdoor (which I've already shown how to easily identify here), subverting LAPS, Exchange Strikes Back and abusing GPOs and Constrained Delegation.

They're absolutely right in that there are very many ways in which one can plant such backdoors in Active Directory!

However, without getting into the details today, let me also say that every single backdoor one could plant using these (or any) strategies can be instantly identified by merely being able to audit effective permissions on Active Directory objects, and further that all such backdoors can be instantly identified by performing an Active Directory Effective Privileged Access Audit.

In days to come, in a follow-up post, I'll explain why I say so. The short of it is that once you can accurately determine exactly who has what effective permissions on an Active Directory object, and the "who" part is solely a list of individual user accounts, then any and all such hidden access will immediately come to light, and be instantly identifiable, leaving no place to hide!

To reiterate, any and every backdoor someone could ever hide in Active Directory can be identified by possessing the capability to determine effective permissions in Active Directory. After all, there's a reason there's an (although almost useless) Effective Permissions Tab in Microsoft's tooling, and that reason very simply is that effective permissions are paramount to security.

Speaking of which, in that 64-page technical whitepaper, there was not a single mention of the term "effective permissions", even though half its content is focused on explaining that there are various security permissions that can be allowed or denied and be explicit or inherited, governed by precedence orders etc. all of which actually leads to, well, "effective permissions!"

But if in over a decade even Microsoft didn't realize this, can one expect a few passionate enthusiasts to get it that easily?!

A Quick Note to the Black Hat Conference Board

Gentlemen, two years ago, i.e. one year prior to this year, when this presentation was made at the Black Hat Conference 2017, for the first, only and last time, I had submitted a proposal for a presentation which was titled - "How an intruder could own a Microsoft Active Directory deployment within minutes  / Zero to Enterprise Admin within Minutes!"

That presentation involved demonstrating how "real" sneaky persistence could allow an intruder to go from zero to root within minutes. You turned down my presentation, but you allowed this basic presentation that year, and this presentation this year.

I just showed you how to solve this problem in 1 minute! In days to come, I'll also be sharing with the world how to easily solve the problem of Active Directory botnets in 1 minute, which was the topic of the second presentation on Active Directory Security at your Black Hat Conference this year.

I'm beginning to realize that you folks too may not yet know enough about Active Directory Security, and now it all makes sense. I am glad though that at least you allowed one or two presentations on Active Directory Security at your conference this year.

In general, since the distinguished folks on your selection board are supposed to be amongst the best in cyber security, it may be worth considering learning more about Active Directory Security yourselves, so next time, you can make better decisions.







This Impacts the Whole World

Before I sign-off, let me ask a question - "Do you know who's running on Active Directory today?" The Answer - Who's Not?

In other words, what I just shared above impacts the foundational cyber security of over 85% of all organizations worldwide.

You see, from the world's biggest Cloud Computing companies, to the world's biggest Internet, Defense, Banking, Oil and Gas, Manufacturing, Healthcare, Transportation, Hospitality <etc.> <etc.> companies, literally everyone's running on Active Directory.







Summary and Gratitude

In summary, identifying and thwarting simple sneaky persistence in Active Directory is literally a matter of/involving "Everyone" (pun intended), and hopefully the above should help everyone. In a few days, I'll also shed light on "real" sneaky persistence.

You see, sometimes it just takes common-sense, and as goes an old Chinese saying - "Why use Cannon to Kill Mosquito?!"

That said, the focus on Active Directory Security, and in particular on the ocean of unauthorized access grants that exist in billions of Active Directory ACLs worldwide today, is spot-on and very important, because its what's protecting trillions today.

I would thus like to most sincerely thank the authors of this presentation and the Black Hat Conference for finally bringing the important subject of Active Directory Security to the CENTER-STAGE, because amongst all the areas in cyber security, when its comes to organizational cyber security, today Active Directory Security is possibly the most important, i.e. it is Paramount.

My next post on "Real" Sneaky Persistence should be out in a few days - here.

Best wishes,
Sanjay.

CEO, Paramount Defenses.

PS: Of all the challenges I've helped solve for Microsoft's global ecosystem, on a scale of 1 to 10, this one's a 1 and that's a 9.

         Here's a 2, a 3, a 4, a 5, a 6, a 7, an 8 and a 10.

The World's Best Active Directory Permissions Analyzer

Folks,

Hope your 2017's off to a great start. As I had indicated a few days ago, starting January 26th I'll be sharing some valuable insights on Active Directory Security; until then just wanted to get some very basic stuff out of the way; this one being the 6th.

Active Directory Permissions Audits - An Essential Need

It goes without saying that today virtually every organization that operates on Microsoft's Active Directory has an essential need to be able to audit Active Directory security permissions because Active Directory security permissions ultimately protect the entirety of the organizations IT resources. A few examples of such essential Active Directory permissions audits include -

1. Who has what security permissions/rights in Active Directory, which ones and where?
2. Who has what security permissions/rights on a specific Active Directory object and how?
3. What security permissions/rights does a specific user or security group have in Active Directory?
4. Where does a specific user or group have any kind of modify permissions/rights in Active Directory?
5. Who has what security permissions/rights on critical Active Directory objects such as the domain root object etc.?

Now, let me be the first to tell you that if you truly know Active Directory Security, then you know that it is not "Who has what permissions" but "Who has what effective permissions" that matters (and the difference is colossal and could be the difference between security and compromise), but for now let's just play along and assume that this is what organizations need to audit.

To fulfill these essential needs, IT admins worldwide use various means, such as writing advanced in-house LDAP/ PowerShell scripts, using free MS tools like dsacls, acldiag, LDP etc., or relying on some 3rd party audit tools many of which aren't reliable.

In doing so, here are some issues/challenges they could run into -

1. In-house scripts are prone to human-error, need to be maintained and could be maliciously modified by someone
2. The use of PowerShell, and/or utilities like LDP requires a certain level of technical Active Directory expertise
3. Many 3rd party tools, whilst inexpensive, may or may not always be sufficiently trustworthy (e.g. built in Russia etc.)

In our experience, we found that what is ideally needed is a dedicated and reliable (tamper-proof) permissions audit tool that can help all these IT personnel easily & trustworthily fulfill their essential Active Directory security permissions audit needs.

So we built possibly the world's best (most capable) Active Directory Permissions Analyzer that could help IT admins, analysts, auditors and other stakeholders easily and trustworthily fulfill their essential Active Directory security permissions audit needs.



Gold Finger Active Directory Permissions Analyzer

The Gold Finger Permissions Analyzer is the world's most capable and trustworthy Active Directory Permissions Audit Tool -

Gold Finger Active Directory Permissions Analyzer

If you can touch a button, you can now easily, comprehensively and above all, trustworthily fulfill all your Active Directory security permissions/rights audit and compliance reporting needs. Active Directory permissions audits could not be simpler.

Capability Overview

Here's a quick overview of the tool's top 5 features/capabilities -

1. Rapid Analysis and Enterprise Scalability – Analyze entire Active Directory domains within a matter of minutes.
2. Rich Analysis Criteria – Find permissions based on grant type (allow/deny), inheritance (explicit/inherited), permission type (e.g. Write Property), security principal (any user, security group or well-known security principal) and scope.
3. Group Membership Inclusion – Automatically include the impact of group memberships when analyzing permissions.
4. Real-time Schema Availability – Specify any class, attribute or extended right defined in your organization's AD Schema.
5. Complete Flexibility – Customize analysis scope via use of custom LDAP filters (e.g. (&(objectClass=user)(title=C*O)).)

Design Goals

Here are the 5 main design goals we set and met for Gold Finger -

1. Trustworthiness - When it comes to security, Gold Finger sets the bar and gold standard for trustworthiness.
2. Ease-of-use - It can be installed in 2 minutes on any machine* and requires no Active Directory knowledge to use.
3. Customization - Every report can be completely customized using LDAP filters as well as scope and depth control.
4. Complete Flexibility - IT personnel can search for any kind of Active Directory security permission, including specific permissions and extended rights, as well as permissions granted anywhere to a specific user/group etc. 
5. Data output - IT personnel can effortlessly export the raw data for archival, rich analysis etc.

Example Reports

Here are 10 real-world examples of the kinds of Active Directory security permissions audits you can perform with Gold Finger -

1. Identify all security principals that have any kind of modify permissions granted anywhere in the Corp domain.
2. Identify all security groups that have All Extended Rights granted anywhere in the Corp domain.
3. Identify all users that have the Reset Password Extended right granted on any domain accounts in the Executives OU.
4. Identify all security principals that have Delete permissions granted on any organizational unit (OU) in the Corp domain.
5. Find out if the Temporary Contractors group is granted any security permissions anywhere in the Corp domain.
6. Find out which security permissions, if any, are granted to John Doe anywhere in the Production OU.
7. Find out which users are explicitly granted the Create Child - User permission anywhere in the Headquarters OU.
8. Find out who has Deny permission granted anywhere in the Corp domain, and whether they are Explicit or Inherited.
9. Determine whether John Doe has Write Property - Member permissions on any administrative group in the Corp domain.
10. Determine who has Send As permissions granted on the CEO's mail-enabled domain user account.

Trusted Worldwide

Today, our Gold Finger Active Directory Permissions Analyzer is used worldwide by the world's top organizations to easily, efficiently and trustworthily fulfill the entirety of their essential Active Directory security permissions/rights audit needs.

For more info and free trials, please visit - http://www.paramountdefenses.com/active-directory-permissions-analyzer.html

Best wishes,

Sanjay

PS: This is about 1% of what we do, so this is as much as I'd like to say about it.

How to Easily Dump/Export Active Directory Security Permissions/ACLs

Folks,

Today, I'd like to take a small break from some important technical stuff  and cover some very simple stuff, which is to share with you the easiest way in the world to dump/export Active Directory security permissions/ACLs, because this is elemental.

But first a very quick overview of Active Directory security permissions and ACLs might be helpful.

If you want to get straight to the details, you can skip to section 3 below.




1. A Quick Overview of Active Directory Security Permissions and ACLs

As you may know, every object in Active Directory is protected by an access control list (ACL), which is comprised of zero or more access control entries (ACEs), each one of which allows or denies a specific set of security permissions (of which there are many in Active Directory) to a specific security principal (user, group or well-known security principal.)

Active Directory Security Permissions specified in an Active Directory Access Control List (ACL)

Together, the security permissions specified in an Active Directory object's ACL serve to protect that Active Directory object, and specify who is allowed or denied what security permissions onto that object (which of course includes all its attributes.)

Since even a quick overview of the various permissions in Active Directory could take a few paragraphs, here's a pointer to a very quick overview of the Active Directory Security Model and Active Directory security permissions, which as you may know, include over a dozen generic permissions, dozens of extended rights and several validated writes. Alternatively, you can refer to Appendices C, D and E of Microsoft's official whitepaper on administrative delegation, which I wrote back in 2003.

In essence, Active Directory ACLs and the security permissions specified within them control access to the entirety of Active Directory content, and thus lie at the very foundation of cyber security in a Microsoft Windows Server based IT infrastructure.




2. The Need to be able to Dump/Export Active Directory Security Permissions/ACLs

IT personnel responsible for administering Active Directory deployments, delegating and maintaining administrative authority in Active Directory, provisioning secure access for applications and other stakeholders to Active Directory content, auditing Active Directory security etc. often have a need to be able to dump/export Active Directory Security permissions/ACLs.

In fact, here are 5 specific use-cases -

1. Perform security analysis to identify who is specified what access across an Active Directory domain

2. Identify the list of all security principals that have any sort of access granted in an Active Directory domain

3. Determine what security permissions are granted to whom, where and which ones in Active Directory

4. Obtain a detailed, fully-sortable view of all security permissions/ACLs in an Active Directory partition. 

5. Export/dump an Active Directory object's ACL for detailed offline-analysis, comparison, audit and archival.

Today these needs are elemental to the foundational cyber security of virtually every Active Directory deployment in the world.





3. The World's Easiest Way to Dump/Export Active Directory Security Permissions/ACLs

Today the easiest, fastest and most reliable way to dump/export Active Directory security permissions/ACLs in Active Directory is via this specialized Active Directory ACL Viewer and Exporter tool - 

Gold Finger Active Directory ACL Viewer and Exporter

Click, Done. If you can click a button, you can export Active Directory security permissions/ACLs in seconds. It's that simple.

Active Directory Security Permissions/ACL Dump

Here's some sample output (; you can click the image below to enlarge it + download complete CSV file from here) -

Active Directory ACL Dump
 

The Active Directory security permissions/ACL dumps generated by the tool are very easily sortable by virtually every relevant field, including object type, object name, distinguished name, permission type (Allow/Deny), security principal, each of the 13 individual generic Active Directory permissions (RC LC LO WO WD SD DT CC DC CR SW RP WP), attribute/class, inheritance, applies to and inheritance flags (CI (Container Inherit), ID (Inherited), IO (Inherit-Only) and NP (No Propagate)), making it very easy to sort the data by any field, and easily perform rich and efficient ACL/security analysis.

In fact, with this dedicated tool, if you can click a button, you can instantly -

1. Obtain a highly-detailed, fully-sortable view of the access control list (ACL) of any Active Directory object.

2. Analyze an Active Directory object ACL by being able to sort it by any field (e.g. Type, Security Principal etc.) 

3. Sort an Active Directory object's ACL by any of the 13 generic permission types (e.g. Create Child, Delete etc.)

4. Export/dump an Active Directory object's ACL for detailed offline-analysis, comparison, audit and archival.

5. Export/dump the ACLs of any, some or all Active Directory objects in any Active Directory partition.

Right below, I've shared 7 real-world examples, complete with their ACL dump output so you can see the data for yourself.





4. Seven Real-World Examples of Active Directory Security Permissions/ACL Dump

Here are 7 real-world examples of Active Directory ACL dumps, with actual outputs, that you can perform with this tool -

 

1. Dump the security permissions/ACLs of all objects in the domain: output

2. Dump all protected ACLs in the domain: output

3. Dump the security permissions/ACLs of all privileged users and groups in the domain: output

4. Dump the security permissions/ACLs of all users in the domain whose title contains the word Cloud: output

5. Dump the ACLs of all objects in the domain that are owned by the Builtin Administrators group: output

6. Dump the ACLs of all organizational units that are immediate children of the Corp organizational unit: output

7. Dump the ACLs of all organizational units that are up to 2 levels deep in the Corp organizational unit: output

To view the actual ACL dumps for each of the examples above, simply click on the associated output links above.




5. Seven Design Goals

Here are 7 design goals we had when developing our dedicated Active Directory Security Permissions/ACL Dump Tool -

1. Ease of Use - Ability to dump Active Directory permissions/ACLs at the touch of a button.

2. Complete Flexibility - Ability to use LDAP filters to customize scope of objects whose ACLs are to be dumped.

3. Scope and Depth Control - Ability to specify the scope and depth of objects whose ACLs are to be dumped.

4. Easily Analyzable and Sortable Results - The results retrieved should be rich and easy to analyze and sort.

5. Zero Dependencies - The tool should not require any configuration changes or special permissions.

6. Easy installation - The tool should be installable on any domain-joined machine in under 2 minutes.

7. Advanced Features - It should be able to perform special retrievals such as to be able to -

a. Export/dump all ACLs marked protected

b. Export/dump the ACLs of all objects that are owned by a specific user/group

c. Export/dump the ACLs of all objects with a specific Primary Group

Its specialized features embody these goals and make it substantially more capable than other tools (e.g. dsacls, acldiag, etc.)

In addition, because all of our tools are professionally built to the highest standards of security, reliability and trustworthiness, organizations do not need to worry about the accuracy, integrity or security risks associated with amateur/custom-built scripts.



Summary

Today, our Gold Finger Active Directory Security Permissions/ACL Viewer and Export Tool is used in 6 continents worldwide, by so many of the world's top business and government organizations, perhaps because its the easiest, most reliable and trustworthy way to dump Active Directory ACLs.

To learn more + to get a free trial, visit - http://www.paramountdefenses.com/active-directory-acl-permissions-viewer.html

Of course, because we know first-hand that there's a lot more to Active Directory Security Audit than performing Active Directory ACL dumps, we also offer the world's most capable Active Directory Permissions Analyzer and the world's only accurate Active Directory Effective Permissions Tool, Active Directory Effective Access Audit Tool and the world's only Active Directory Administrative Access and Delegation Audit Tool.

In essence, we offer the world's most comprehensive suite of Active Directory security, access and effective access audit tools, all available in a single user-interface, with zero dependencies, two-minute installation and Windows-integrated security.

More information on our Gold Finger Suite is online at - http://www.paramountdefenses.com/goldfinger.html

Best wishes,
Sanjay