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

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 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.


Monday, July 31, 2017

A Trillion $ Question to Microsoft regarding "Identities" and Cyber Security


Dear Microsoft,

Today is Day-11 of our advanced Active Directory Security School for you, and today I'd like to ask you a very simple question that concerns the most elemental and fundamental aspect of cyber security in Windows-based networks worldwide - Identities.

Identity is fundamental to Cyber Security

Identity is an elemental and fundamental aspect of cyber security, as each one of the 3-As of cyber security i.e. Authentication, Authorization and Auditing, require the ability to be able to uniquely identify entities i.e. people, computers, service accts etc.

The importance of identities is evidenced by that fact that an entire field of IT security is devoted to it, i.e. Identity Management, and that numerous multi-million $ companies such as Ping Identity, Centrify etc. exist only to help make identities more secure.

So, ...



Identities in Windows Environments

Now, as you know, at the foundation of over 90% of all business and government organizations worldwide lies Active Directory, and in these organizations, the Identities of their employees, contractors, executives, privileged users and other stakeholders are all represented by ...

A Domain User Account in Active Directory
... none other than their  unique  Active Directory domain user accounts !

(For completeness, it must be mentioned that computers have identities too represented by their domain computer accounts, and that strictly/technically speaking, it is a domain account's Security Identifier (i.e. SID) that uniquely represents its identity.)


That's right. In Active Directory based IT infrastructures, it is domain (i.e. Active Directory) accounts that represent identities.

In fact, at thousands of organizations worldwide, it is Active Directory domain user accounts that represent corporate identities, and in Active Directory deployments worldwide, today hundreds of millions of identities are represented by these accounts.





Uniqueness Is Imperative

Now, of vital note here is that, as you know, the keyword above is unique, because the entire premise of cyber security in Active Directory based networks rests on each user having a single, irrefutably uniquely identifiable domain user account!




After all, you likely don't have two domain user accounts at Microsoft for say, Satya Nadella, right? Yes I know that to address certain needs, some users like privileged users have multiple (e.g. alt) accounts, but they are always explicitly labeled as such.

In fact, here's why it is so important that users have only (one identity, i.e.) one domain user account -
  1. Security - Uniqueness is required to eliminate ambiguity. Ensuring secure access to securable resources in a network requires that resource owners be able to uniquely identify the entities/individuals for whom access is to be specified.

  2. Accountability - Accountability necessitates uniqueness. Should a user be able to authenticate him/herself using an account other than one assigned to him/her, he/she could engage in malicious activity, such as obtaining unauthorized access to, divulging and/or destroying various IT resources, that could not be irrefutably tied/traced back to him/her.

In fact, ensuring security requires that, ideally speaking, no user (except for a known few explicitly authorized administrative personnel) must ever be in a position that provides him/her access to more than one uniquely authenticatable domain account.

Now there are generally only two ways in which one could obtain access to an additional account - 1) a user could create a new domain user account in Active Directory, or 2) a user could reset the password of an existing domain user account in Active Directory. For now, let's assume that the second way is not that important (although it is), and lets just focus on the first one.

It turns out that the seemingly simple and mundane task of being able to create domain user accounts in Active Directory is actually very important to cyber security, because, as explained above, if someone could create a domain user account in Active Directory, he/she could instantly obtain and be in possession of an additional, separate uniquely authenticable identity.

Incidentally, the very least one could do with an additional domain user account is use it to scour the entire IT network for vulnerabilities, perform network logons on to most computers, and access anything and everything (e.g. files on servers, databases, SharePoint portals, ) to which Domain Users and Authenticated Users have read access (and you would be surprised to know as to just how much these two well-knowns (-RID and -SID) have access to in most organizations today.)

Of course, a proficient individual (intruder/perpetrator) could use an alternate domain account to engage in all sorts of nefarious activities, and the smartest ones could possibly find and exploit privilege escalation paths to take over the entire network.

In fact, if you consider even just the recent critical vulnerability that you just patched i.e. CVE-2017-8563 (Windows Elevation of Privilege), note that its exploit vector too involved/required that the perpetrator create a domain user account in Active Directory!





A Simple Trillion Dollar Question -

So, in light of the above, as you'll hopefully agree, it is absolutely imperative that organizations know at all times as to exactly who can create new identities in their environment, i.e. who can create new domain user accounts in their Active Directory?!


So, and speaking of which, here's yet another a very simple Trillion dollar question for you, Microsoft -

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)

[ My apologies for harping on "exactly" ; it is just that when it comes to cyber security, accuracy is paramount. ] 


Make no mistake about it - organizations that do not know the answer to this most fundamental of cyber security questions concerning identity management in Windows based networks cannot be considered secure from a cyber perspective.


Now, in case this seems like a simple question, consider what it might take to accurately answer this question at an organization that may have numerous (say even 20+, if not 100s of) organizational units and containers in their Active Directory domain(s).

Here's a hint - In all likelihood, even you*, the $ 550+ Billion Microsoft, that may be spending billions to so convince the world to get on its recent Cloud offering, don't possess the ability to help organizations answer this simplest of cyber security questions.


(In light of which, this might now 
make sense, esp. paragraph 7.)


I, and the whole world, look forward to your answer.  (Also, since you're likely not going to answer it, I'll answer it on Day-12.)

Best wishes,
Sanjay


* Not just you, not a single one of dozens of multi-million/billion $ IT, cyber security, tech and defense companies focused on identity management and cyber security can help organizations answer this simple cyber security question. Well, except one.

PS: August 05, 2017 Update - I've answered the question here.

Sunday, July 30, 2017

Regarding Cyber Security, Kaspersky Labs, Russia & the U.S. Government

Folks,

In light of the recent controversy surrounding whether or not Kaspersky Labs, a Russian cyber security company's, anti-virus software should be running on computers in the U.S. Government, thought I'd re-post a recent post concerning this subject.

As you may have heard, according to Reuters, earlier this week the U.S. Congress, and specifically a U.S. Congressional Panel has asked 22 government agencies to share documents on Kaspersky Labs, saying that its products could be used to carry out "nefarious activities against the United States."

While I am not going to comment on this specific topic/issue, I just wanted to say one thing:


The only thing I will say is that the U.S. Congress and all U.S. Government Agencies, including all U.S. intelligence agencies should know that today, computer software other than Kaspersky Labs' anti-virus software, that was highly likely written in Russia and that may very likely still being supported from within Russia, is very likely still running in possibly the highest privileged security contexts across potentially many parts of the U.S. Government.


If this is true, then if someone could compromise a specific location in Russia, they could... <you can complete the sentence.>


By the way, this is neither something that we uniquely know nor is it classified information. This information is freely available in the public domain and can be easily deduced by some basic online sleuthing, by anyone with merely an Internet connection.

Interestingly, I should also mention that this very piece of computer software may also be running (for years now) in the highest privileged security context in not just the networks of the U.S. Government, but at thousands of organizations worldwide today.


Just one more thing; as a cyber security professional, I find the means by which whoever hacked the DNC and John Podesta's emails absolutely laughable - I mean what an amateur job it was, and yet its impact on global security may have been colossal.

I mean, here we worry about how someone could write a few lines of code targeting Active Directory and potentially be in a position to proverbially shut the motor of the world, (considering that the whole world runs on Active Directory,) and there some kid just phishes John Podesta into obtaining access to his Gmail account and thereby to vast amounts of private email, which he/she then purportedly passes on to WikiLeaks, who ends up releasing it in the public domain. and that according to the CIA, that ends up influencing the U.S. Election.

Finally, and I have said this before, the idea of setting up a joint cyber security unit with Russia may not be a good idea.


Before I put my pen down, let me just say, and I cannot stress one point enough - if potentially untrustworthy code is running in the highest security contexts in your IT network, it likely is not your network anymore (i.e. you're likely not the only one who has access to (and/or can access, control access to, as well as divulge, tamper and destroy) almost everything in your network.)

Best wishes,
Sanjay


PS: To the respected folks in our govt., please know that we already informed the highest cyber security officials concerning the likely presence of Russian code earlier last year. However, if there is still a need to identify it, pls let us know; we're here to help.

PS2: That's all for now. We will continue with Day-11 of our advanced Active Directory Security School for Microsoft tomorrow.


Wednesday, July 26, 2017

An ACE Up the Sleeve: Designing Active Directory ACL Backdoors

Folks,

Earlier today, two fine gentlemen gave a nice presentation titled An ACE Up the Sleeve: Designing Active Directory ACL Backdoors at the Black Hat Conference 2017.


Here's the abstract of their presentation -
"Active Directory (AD) object discretionary access control lists (DACLs) are an untapped offensive landscape, often overlooked by attackers and defenders alike. The control relationships between AD objects align perfectly with the "attackers think in graphs" philosophy and expose an entire class of previously unseen control edges, dramatically expanding the number of paths to complete domain compromise. 
While DACL misconfigurations can provide numerous paths that facilitate elevation of domain rights, they also present a unique chance to covertly deploy Active Directory persistence. It's often difficult to determine whether a specific AD DACL misconfiguration was set intentionally or implemented by accident. This makes Active Directory DACL backdoors an excellent persistence opportunity: minimal forensic footprint, and maximum plausible deniability. 
This talk will cover Active Directory DACLs in depth, our "misconfiguration taxonomy," and enumeration/analysis with BloodHound's newly released feature set. We will cover the abuse of AD DACL misconfigurations for the purpose of domain rights elevation, including common misconfigurations encountered in the wild. We will then cover methods to design AD DACL backdoors, including ways to evade current detections, and will conclude with defensive mitigation/detection techniques for everything described."

I didn't have to be there to know that this would be a well-received and fascinating presentation.  Nice work, gentlemen!



The World of Active Directory ACLs

I'd like to welcome them to the important world of Active Directory ACLs. Even though they may have recently discovered this fascinating world, they're still far ahead of thousands of organizations worldwide, which only goes to prove what I've said here.

Active Directory ACLs

Given how much time they may have spent on Active Directory ACLs (even in just the last few months), they'll likely get this.

Let me tell you that they are a 100% correct that within the ocean of Active Directory ACLs that exists in every Active Directory deployment worldwide, there are a million (pl)ACEs for a intruder/perpetrator/insider to hide within, oh, and for anyone who knows how to find them, there are also thousands of  exploitable Active Directory privilege escalation paths to find.

They may also have shown you how to design Active Directory DACL backdoors, including ways to evade current detections, assuming by current detections, they're referring to the use of existing tooling like dsacls, acldiag, PowerShell scripts, <fill in the blank with your favorite Active Directory ACL analyzer/permissions audit tool> to analyze Active Directory ACLs, you know the tools most IT personnel having been using for years at 1000s of organizations because Microsoft never educated them better.

Fortunately, and they may not know this, organizations that possess the right tooling can now easily identify and eliminate all such insecure (pl)ACEs leaving no place left to hide in Active Directory ACLs i.e. there'll be zero ways left to evade detection.

   Zero!      нуль, nul, صفر , 零,Null, μηδέν, ʻole, אֶפֶס , शून्य, ゼロ,제로, nihil, sero !


So, what is the right tooling ?  Well, I will be penning a post titled something along the lines of  No more (pl)ACEs To Hide : Identifying Active Directory ACL Backdoors and/or How to Thwart Persistence In Active Directory in a few days, so you'll just have to wait for it, but if you're curious, I'll give you a big hint; it has to do with this - Active Directory Effective Permissions.

Over all, these gentlemen are spot-on and 100% right, and I sincerely commend their efforts to help organizations become aware of the vulnerabilities that lie deep within the thousands of ACLs inside their foundational Active Directory deployments.  

Best wishes,
Sanjay



PS: A Helpful Reading List - For everyone who'd like to get into the fascinating world of Active Directory Security/ACLs -

 
  1. Best Practices for Delegating Active Directory Administration

    (especially the Appendices, and the other guides + the free LDP tool.)

  2. Defending Active Directory Against Cyber Attacks (Microsoft)

  3. Defending Active Directory Against Cyber Attacks (Paramount Defenses)

  4. Advanced Active Directory Security School for Microsoft


Tuesday, July 25, 2017

Active Directory Effective Permissions - Paramount to Cyber Security

Folks,

If you're into Cyber Security, and you could read only one piece this year, you'll likely want to read this post - its that important.

[ Some Context: Here is the associated press release - Paramount Defenses Skips Black Hat Conference 2017 to Educate World About Importance of Active Directory Effective Permissions to their foundational cyber security. ]

Today, I'll shed light on Active Directory Effective Permissions, a most vital topic that Microsoft (for reasons best known to them) apparently completely forgot to educate the world about, for a decade, even though it is paramount to cyber security worldwide.

Privileged Access in Active Directory

It is Active Directory Effective Permissions that determine who has what privileged access at 1000s of organizations worldwide.


(By the way, I find it astounding that even 17 years after Active Directory was shipped, 1000s of Microsoft's major organizational customers still don't seem to know about something so fundamental to their foundational cyber security - Effective Permissions.)


This incredibly important post is a bit long so for enhanced readability, it is comprised of the following 12 sections-
  1. This is Paramount
  2. A Simple $ Billion Example
  3. Active Directory Effective Permissions
  4. Their Importance
  1. The Effective Permissions Tab
  2. A Huge Challenge
  3. What Organizations Need
  4. The Solution
  1. The Answer
  2. A Note About Microsoft
  3. About Black Hat Conference
  4. Summary





This is Paramount

Let's begin by understanding why this is so relevant and paramount to the foundational cyber security of every organization.


Consider this. In an Active Directory deployment (the foundation of IT and cyber security at most organizations in the world,) do you know what is the only way to answer each & every one of the following 10 basic and elemental cyber security questions? -

  1. Exactly who has what level of privileged access where and how in Active Directory?

  2. Exactly who can create new user accounts, security groups, OUs, SCPs etc. in Active Directory?

  3. Exactly who can delete existing user accounts, security groups, OUs, SCPs, etc. in Active Directory?

  4. Exactly who can reset the password of which user accounts (including privileged users) in Active Directory?

  5. Exactly who can modify the membership of which groups (including all privileged groups) in Active Directory?

  6. Exactly who can modify the ACL of the AdminSDHolder object to control all privileged access in Active Directory?

  7. Exactly who can modify the contents of the Configuration and Schema partitions to gain control of Active Directory?

  8. Exactly who can manage all accounts, computers, groups, OUs, DCs, SCPs, Trust relationships etc. in Active Directory?

  9. Exactly who can compromise everyone's credentials by replicating secrets from Active Directory via Mimikatz DCSync?

  10. If any Active Directory integrated defense-in-depth measures such as these i.e. Smartcard authentication, MFA, Auditing, Random Password Manager, Password Vault etc. are in use, exactly who can disable them to render them useless?

The answer: Active Directory Effective Permissions.  (Not "Who has what permissions in Active Directory.") 


Organizations that do not have exact answers to these 10 simple questions cannot
be considered secure, so let's talk about Active Directory Effective Permissions.





A Simple $ Billion Example

This paramount cyber security concept is best understood via an illustrative example, so let's consider a real-world scenario -

Data Center

A fictional multi-billion dollar organization operates a high-security data-center, in which reside its high-value servers, including most of its file servers, web servers, app servers and Domain Controllers (DCs). Responsibility of managing all servers in the data-center is entrusted to the Data-Center Operations Team, an on-site team of highly trustworthy and proficient IT personnel.

To facilitate the privileged access this team needs, the organization created (and is using) an Active Directory security group called Data-Center Operations Team, and added it (via group policy) to the local Administrators group on all servers and DCs.

In effect, anyone who is a member of this highly privileged Active Directory (domain) security group Data-Center Operations Team has system-wide admin access and can thus control virtually everything in this multi-billion dollar organization's network.

Cognizant of this fact, the organization has worked really hard to minimize the number of individuals in this highly privileged Active Directory security group, and has been able to reduce its memberships to just 6 individuals -


Here are the members of this highly privileged Active Directory security group -

  1. David Parker, IT Manager
  2. Erica Lockhart, IT Administrator
  3. Larry Ellison, IT Administrator
  1. Michael Karp, IT Security Analyst
  2. Pamela Fitzgerald, IT Auditor
  3. Patrick Sullivan, Senior Operations Analyst
Speaking of which, for enhanced security, the organization also uses additional security measures to secure and defend all of its privileged user accounts (e.g. Enterprise Admins, Domain Admins etc.) which currently totals 15, including these 6 accounts.


Now, a Billion $ question begs itself - Although this highly privileged and mission-critical domain security group currently only has 6 members, "Exactly how many individuals can change the membership of the Data-Center Operations Team group?!"

This question is paramount because anyone who could change this group's membership could instantly take over everything.


The answer to this simple yet paramount question
lies in Active Directory Effective Permissions...





Active Directory Effective Permissions

First off, as you may know, to find out who can change the membership of the Data-Center Operations Team security group, you have to find out who all actually have sufficient access so as to be able to modify the group's Member property/attribute.

Next, some very quick theory. As you know, literally everything in Active Directory is an object, and each object is protected by an access control list (ACL) that is comprised of zero of more access control entries (ACEs), each one of which Allows or Denies one or more of a dozen types of security permissions to a specific security principal (user, group or well-known SID), and together i.e. collectively (, and not individually) these security permissions impact the resulting access on the object.

With that theory in mind, let's take a quick look at the ACL protecting the Data-Center Operations Team security group, with the intent of finding out who all actually have sufficient access so as to be able to modify the group's Member property -

The ACL protecting the Data-Center Operations Team domain security group in Active Directory

As you can see above, there are numerous ACEs in the object's ACL, each one of which either explicitly or via inheritance, Allows or Denies, one or more of a dozen types of security permissions to various security principals. In fact, observe that -
  1. There are numerous Allow and Deny permissions, some of which are explicitly specified on the object, whereas others are inherited down from the object's parent object, and their actual impact is determined by a precedence order.

  2. There are numerous types of Active Directory security permissions that are specified, such as Write - Member (Property), Write - Group Membership (Property-Set), Write All Properties, Modify Permissions, SpecialFull Control etc.

  3. There are numerous security principals for whom these security permissions are specified, including individual users('s accounts), security groups, and well-known security principals (e.g. Domain Users, Authenticated Users, Self, etc.)

  4. Of the numerous security groups for which access is specified, they could have other security groups nested in them (, and some could also possibly be circularly nested,) and thus could easily end up impacting access for many users.

  5. Of these various access control entries / security permissions that exist in an Active Directory object's ACL, not all of them may actually be applicable to the object, as they may exist solely to facilitate inheritance to downstream objects.

[ Note: For detailed observation, you can download the entire ACL protecting this object here. ]

Considering the above, how do we find out who all have sufficient access to be able to modify the group's Member property?

As observed above, there are numerous security permissions that are specified in various ways (Explicit/Inherited, Allow/Deny) for numerous users and groups (which could in turn contain other groups) in an Active Directory object's ACL, and (theoretically) each one of these permissions could overlap or conflict with each other, thus collectively impacting the actual resulting access.


To see this in action, let us attempt to evaluate the impact that just even two following randomly selected ACEs in this object's ACL can have on the resulting access of a randomly chosen user, Peter Thiel  -
ACE # 13:   Allow    IT America Admin Team             Write All Properties                                                   Inherited 
ACE #  9:    Deny    IT Operations Support Level 3    Write Property - Group Membership Property Set    Inherited

In case it helps, Peter Thiel's (domain user account's) domain security group memberships are displayed below -



As you can see, Peter Thiel happens to indirectly be a member of each of the domain security groups for which permissions are specified in these two ACES, so both these ACEs will end up impacting the actual access that Peter Thiel has on this group.

If you were to consider the first ACE shown above solely by itself, you may errantly conclude that Peter Thiel can modify the membership of this group, because Peter Thiel is a member of the IT Helpdesk Operators group, which is turn is a member of the IT American Admin Team group, which is allowed blanket Write All Properties, and that includes Write Property - Member.

However, if you were to also consider the second ACE shown above, then you will correctly conclude that Peter Thiel cannot in fact modify the membership of this group, because Peter Thiel is also a member of the IT Helpdesk Team group, which in turn is a member of the IT Operations Support Level 3 group, which is denied Write Property - Group Membership Property Set, and it so happens that the Member property is a member (pun unintended) of the Group Membership Property Set.

In essence, it turns out that even though Peter Thiel has Allow Write All Properties specified on the object indirectly, he also has Deny Write Group Membership Property Set specified on the object indirectly, and since the inherited Deny access will override the inherited Allow access, he will effectively have the ability to modify all properties except the Member property on the Data-Center Operations Team security group, and as a result, he will not actually be able to modify the membership of this group.

Now, it must also be mentioned that if there were to be even one other ACE that would explicitly end up allowing Peter Thiel Write-Property - Member whether directly or indirectly, that explicit Allow would override the inherited Deny, in which case, he would in fact be able to modify the group's membership. In such a case, it must further be mentioned that if there were to be even one other ACE that would explicitly end up denying Peter Thiel Write-Property - Member whether directly or indirectly, that explicit Deny would override the explicit Allow, in which case he would not in fact be able to modify the group's membership.

So you see, there could easily be well over a 100 ACEs in the object ACL, and each and every single one of these that specifies either of Write-Property - Member attribute, the Write Group Membership Property Set, Write All Properties or Full Control access, whether it be an Allow or a Deny and whether be explicitly specified or specified via inheritance, will likely directly or indirectly (i.e. via nested group memberships or well-known RIDs and SIDs ) impact whether or not Peter Thiel can change this group's membership, and they will also undoubtedly impact the complete list of users who will actually be able to change this group's membership. In other words, there could easily be over a 100 ACEs in the object's ACL and the permissions they specify collectively impact the resulting access on the object!

Thus, the only way to correctly (i.e. accurately) find out what access the ACEs in an ACL actually end up entitling on the object, and to whom, is to collectively take them into account and determine the resulting i.e. effective access they end up granting.

Consequently, the actual set of permissions / access that a user ends up being granted (i.e. allowed) on an Active Directory object, in light of having correctly considered the collective impact of the entirety of all security permissions specified in all of the ACEs in the object's ACL, are known as the user's effective permissions on that object.

As seen above, it is a user's effective permissions that determine what access a user actually has on an Active Directory object.





Their Importance

Active Directory Effective Permissions are extremely important because as illustrated above, it is "what effective permissions does a user have" and not "what permissions does a user/group have" that determines whether or not a specific user has a specific type of access granted on an Active Directory object.



Consequently, it is Active Directory Effective Permissions that gate every single LDAP operation that can be performed on Active Directory content.

Privileged Access in Active Directory

In other words, they control everything, including who can create, manage and delete all domain user accounts and security groups (including all privileged accounts and security groups), containers, OUs etc. in and across Active Directory.

In fact, in a Microsoft Windows Server based IT infrastructure, from user authentication to secure network-wide authorization to organizational IT assets, not a leaf moves without (access to) Active Directory being involved, and not a single access to Active Directory, whether it be read access or modify access, is possible without users having sufficient effective permissions to do so.

If users did not have sufficient effective permissions in Active Directory, the entire organization would come to a stand still. By the same token, if someone had sufficient effective permissions in Active Directory, he/she could control the entire network!






The Effective Permissions Tab

The importance of Active Directory Effective Permissions is perhaps best conveyed by the fact that in addition to the tabs for Permissions, Auditing and Owner(ship), the fourth tab in Microsoft's native security tooling is for Effective Permissions -

Effective Permissions Tab

In other words, for Microsoft to have dedicated an entire tab for Effective Permissions, they must be at least as important to cyber security (if not more so) as Permissions, Auditing and Owner(ship), which we all know are important for obvious reasons.

Unfortunately, as important as effective permissions are to organizational security today, Microsoft’s Effective Permissions Tab for Active Directory is not only not 100% accurate, it is substantially inadequate (; and has been so for a decade now.)

Here's why -
  1. It is not always 100% accurate, since it self-admittedly does not take all relevant factors into account

  2. Most importantly, it can only determine (an approximation of) effective permissions (granted to) ONE user at a time

  3. It cannot show which underlying permissions in the object’s ACL entitle a specific user to a specific effective permission

As to its accuracy, as shown in the snapshot above, in reference to the example considered in the previous sections above, for the user Peter Thiel, it is indicating that Peter Thiel has Write all properties effectively allowed. This is inaccurate because as illustrated in the example above, in reality, Peter Thiel has the ability to write (to) all properties except the Member property, and this fact is evidenced by the following snapshot -

Insufficient Access
As seen above, the Add and Remove Member buttons are disabled (grayed out) for Peter Thiel because he does not in fact have sufficient effective permissions to modify the Member property on the Data-Center Operations Team security group.


As to its limitation of only being able to determine an approximation of effective permissions for one user at a time, this single limitation renders this tab virtually useless, because due to this limitation, the only way for an organization to determine exactly who all have a specific type of effective permission on a specific Active Directory object, would be to have IT personnel manually enter the identities of every single one of thousands of domain accounts one by one, and make a note of each user's effective permissions, and that is neither practical nor realistically feasible.


As to its inability to be able to identify and pinpoint the underlying security permissions in the object's ACL that are entitling a specific effective permissions for a specific user, this ability is essential if organizations are to have any hope of being able to lockdown any excessive effective permissions/access that may have been identified on a specific Active Directory object. After all, if you don't know which ACE / security permission / security group membership you need to tweak to eliminate or lockdown an excessive effective permission, how are you going to mitigate the identified risk?


In short, in reality, the substantial deficiencies inherent in Microsoft's Effective Permissions Tab make it virtually unusable. The same is true of most other tools from Microsoft that claim to do effective permissions, including dsacls, acldiag, accesschk etc.

Further, whilst numerous vendors claim to offer solutions that can help find out "who can do what in Active Directory" or "who has what effective permissions", not a single one of them actually determines effective permissions, let alone being able to determine them accurately. They merely perform basic permissions analysis. Finally, this one tool that claims to be able to do effective permissions is not only dangerously inaccurate, it has the same deficiencies as Microsoft's Effective Permissions Tab.





Huge Challenge

(This section is for all amateurs who might say - "What's the big deal here? I imagine I could this with some PowerShell?")

As we saw above, merely evaluating the collective impact of just 2 ACEs alone can be complicated. In many real-world Active Directory deployments, there may be over a 100 ACEs in the ACL of each Active Directory object, and correctly collectively considering the entirety of all security permissions specified in each of these ACEs can be extremely difficult.


In fact, the accurate determination of effective permissions in Active Directory poses a HUGE challenge for the world.

Here's why -
  1. Active Directory's security model, albeit extremely powerful, is substantially more complex than the traditional Windows file and folder security model. For instance, while there are only a few generic permissions in the file and folder security model, there are almost a dozen generic permissions in Active Directory's security model, and in addition there are also almost five dozen special permissions known as Extended Rights, all of which substantially increases its complexity.

  2. The problem size is substantially larger, in that there are far more ACEs in an Active Directory object's ACL than there are in a file or a folder's ACL. In many Active Directory deployments, there may easily be over a 100 ACEs in each Active Directory ACL, considering that a substantial amount of access provisioning is done in Active Directory to facilitate administrative delegation and to configure access for various Active Directory integrated applications and services.

  3. The existence of and thus the need enumerate of a possibly large number of domain security group memberships, especially those that may be deeply nested as well as those that may be circularly nested, further increases the complexity of the process of performing accurate access evaluation and conflict resolution.

  4. The inclusion of numerous arcane details that are unique to Active Directory, such as including the impact of object ownership on effective access, dynamically evaluating relative well-known RIDs etc. further complicates the process.

Consider this - Imagine trying to determine effective permissions on an Active Directory organizational unit, in whose ACL there exist 150 ACEs, 100 of which specify varying levels of access for security groups, 75 of which (i.e. security groups) contain nested security groups, 50 of which contain deeply nested security groups, and 25 of which deny various forms of access and 10 of which are circularly nested, and you'll get a sense of just how difficult this process can be to perform, let alone automate.





What Organizations Need

In light of the fact that Active Directory Effective Permissions are vital and in fact paramount for organizational cyber security, today, organizations absolutely need the ability to be able to accurately and efficiently determine effective permissions in their Active Directory deployments.


After all, considering that the foundational Active Directory deployments of most organizations have been in operation for years now, in most deployments today there very likely exists rampant unauthorized / excessive effective permissions / access, so organizations need to identify and lockdown all such unauthorized / excessive effective permissions / access, especially that granted on mission-critical content, such as all high-value (privileged and executive) user accounts and security groups, the Domain Controllers OU, the domain root, AdminSDHolder, various parts of the Configuration and Schema partition etc.

Here are 3 simple needs that organizations have regarding determination of Active Directory effective permissions -
  1. Accuracy - First and foremost, the ability to be able to accurately determine effective permissions in Active Directory

  2. Efficiency - Secondly, the ability to be able to efficiently determine effective permissions in Active Directory i.e. ideally be able to determine the complete set of effective permissions granted on an object, as well as the identities of all users who have these effective permissions granted, without having to enter each user's identity one at a time.

  3. Source-Identification - Finally, the ability to be able to identify which underlying security permissions in the object's ACL are entitling a specific user to a specific effective permission on a specific Active Directory object.  

If these 3 simple needs could be fulfilled, organizations could swiftly attain and maintain least privileged access (LPA) in and across their foundational Active Directory deployments.





The Solution - An Adequate Active Directory Effective Permissions Calculator

Given just how important it is for all organizations to be able to adequately determine effective permissions in Active Directory, it was clear to me about a decade ago that if the world didn't have an adequate solution for this, in years to come we would all be facing a major cyber security challenge.

So, about a decade ago we decided to take on this huge challenge and started working to build an adequate solution to address it, because we had understood back then just how important and essential this was going to be for the world, in years to come.

(The intention was never to build a cyber security company per se, but rather a desire to take this huge challenge head-on, and to see if we could solve it, and further to see how well we could solve it i.e. just how easy could we make it for everyone. The company and its products are merely an outcome of the successful pursuit of this desire to address this challenge for the world.)

Today, it is my privilege to share with you the outcome of over half a decade of innovative, industrious and committed research and development, so allow me to share with you Gold Finger for Active Directory, the world's only accurate Active Directory Effective Permissions Calculator / Tool that also delivers on everything organizations need to address this huge challenge -

Gold Finger Active Directory Effective Permissions Tool / Audit Tool / Calculator

At the touch of a single button, Gold Finger can -
  1. First and foremost, accurately determine effective permissions on Active Directory objects

  2. Secondly, it can determine the complete set of effective permissions granted on an object, as well as the identities of all users who have these effective permissions granted, without having to enter each user's identity one at a time.

  3. Finally, it can also identify which underlying security permissions in the object's ACL are entitling a specific user to a specific effective permission on a specific Active Directory object, thus helping making remediation very simple. 
I suppose the only thing more remarkable that Gold Finger's abilities is its simplicity of use. All you need to do it launch Gold Finger, point it to an object in Active Directory, and click a button.

When you click that button, under the hood and completely transparent to you, over half a million lines of code go to work, and within minutes, if not seconds, determine the complete set of effective permissions entitled on an Active Directory object, the complete set of individuals to whom each of these effective permissions are entitled, and the underlying security permissions in the object's ACL that entitle every identified user to every entitled effective permission on the object.

On a humorous note, the only downside of its remarkable simplicity is that it makes the solving of such a difficult technical challenge look so simple that people often wonder what the big deal is! I mean you just click a button, and you're done ;-)


In order to appreciate just how difficult and complex this problem is to solve, perhaps its worth taking a look under the hood...


Under the hood, when you click that button, Gold Finger begins by locating Domain Controllers, identifying the object, retrieving its access control list, and then it initiates the computation of accurate effective permissions analysis on the object, which involves so many technical functions such as but not limited to discovering and analyzing the Schema, resolving SIDs, correctly expanding all relevant security group memberships many of which could be deeply nested, identifying and resolving circularly nested security group memberships, analyzing individual permissions in each ACE (of which there could technically be over a 100 in an ACL), evaluating the impact of each one of them in light of numerous factors such as and not limited to precedence orders, applicability, suitability, inclusion in property sets etc. as well dynamically evaluating any and all well-known RIDs (e.g. Domain Users) and SIDs (e.g. Everyone), mapping Self SIDs to the security principal if applicable, etc. and a whole lot more, and ultimately arriving at its output, and presenting it in a fashion that is as intuitive and user-friendly as it could possibly be.

In contrast, all that most of the currently available Active Directory Permissions Analysis/Audit solutions in the world do today is merely retrieve an Active Directory object's ACL, and report the identities of the security principals encountered in the ACL along with the security permissions specified for that security principal in the ACL. (Some of them may expand a few security group memberships.) In effect, they do about 1% of what needs to be done to do this correctly (because they don't know better), yet they have thousands of customers who too don't know better, and happily proceed to act on dangerously inaccurate data.


Now, consider this - Active Directory environments can be so diverse in nature (from a small 100 object single Active Directory domain/forest for a small business to a globally dispersed Active Directory forest with possibly dozens of domains and 100s of 1000s of objects) that it is extremely difficult to build a product / solution that can automate this process such that it can just work in any Active Directory environment!

One of our many customers worldwide, a prominent 3-letter acronym government agency has 250+ ACEs in the ACL of every object in their Active Directory, and Gold Finger accurately determines effective permissions on these objects within minutes.

There is only one other thing I'd like to mention - while this tool can automatically determine effective permissions and effective access on individual Active Directory objects, its big brother, the Privileged Access and Delegation Audit Tool (i.e. this one) can accomplish the monumental feat of automatically being able to do so on 1000s of objects i.e. an entire Active Directory domain!

Thus, as you can see not only is this paramount to global cyber security today, it is by no means an easy problem to solve, let alone automate. In fact it is almost impossible, and at Paramount Defenses, we go to great lengths to make what is considered impossible as easy as touching a button.






The Answer

This post would not be complete without providing the answer to the paramount cyber security question posed above, which was - "Exactly how many individuals can change the membership of the Data-Center Operations Team group?!"

The Answer: 27.

So, while this vital security group only has 6 members, today there are 27 individuals who can change/control its membership.

In fact, here is the complete set of effective permissions entitled on the Data-Center Operations Team security group.

Now, in case you're wondering how I figured it out, it was actually rather simple; I just clicked one button -

Gold Finger Active Directory Effective Permissions Tool / Audit Tool / Calculator

Specifically, I launched Gold Finger, pointed it to the Data-Center Operations Team domain security group in Active Directory, and clicked the Run button. That's it. A few moments later, as shown above, I had the results. (Here is the exported output.)

So, as you can see, without the ability to determine effective permissions in Active Directory, and of course, do so accurately, we would never know just how many individuals can control the membership of such a vital security group, and who they are.

Without this valuable insight, the organization would have continued to indefinitely operate under the false assumption that only 6 people could control the entirety of their high-business impact (HBI) servers in their highly secure data-center, whereas in fact in reality there are 27 individuals who can do so today!

(Oh, and we haven't yet evaluated and included the number and identities of individuals who have effective modify permissions on this group, and the number and identities of individuals who can reset the passwords of those 27 individuals and who have effective modify permissions on each one of those 27 accounts. Yet at the very least, we've been able to answer the question.)

That is what we mean when we say that most organizations today are operating in the dark. There are many many more individuals that possess all kinds of privileged access in Active Directory than those that they think they know about.





A Note About Microsoft

Folks, as former Microsoft Program Manager for Active Directory Security, I care deeply about Microsoft as well as the foundational cyber security of all organizations worldwide, so I wanted to share a few thoughts.



By now, you've hopefully comprehended just how important Active Directory Effective Permissions are to organizational cyber security. They are absolutely paramount to Active Directory Security, and Active Directory Security is absolutely paramount to the organizational security of thousands of organizations, and to the security of Microsoft's ecosystem.

If this is the case (and this is the case,) how could Microsoft have completely forgotten to educate its global customer base about such an important and mission-critical aspect of cyber security for an entire decade?! It is absolutely astounding!

Last year, when they finally provided some earnest guidance on the importance of defending Active Directory, while they spoke at length about security permissions in Active Directory, they again completely forgot to tell the world about the fact that to attain and maintain least privileged access in Active Directory, you need to determine effective permissions in Active Directory!

It is in light of the above that I asked this question - How Well Does Microsoft Really Understand Cyber Security?

I find it partly amusing and partly concerning that on one hand Microsoft may not even have educated its customers about such a vital aspect of cyber security for an entire decade (most likely because this paramount aspect of cyber security wasn't even on their radar), yet on the other hand, it is wooing and wants the world to entrust their cyber security in its recent Cloud offering!


One cannot emphasize enough just how paramount Active Directory Effective Permissions are to global security today. In most organizations worldwide, due to almost complete ignorance about the value and importance of effective permissions, we have a situation wherein most organizations are operating in the proverbial dark, and there in all likelihood exist thousands of excessive / unauthorized effective access grants, which pave thousands of privilege escalation paths in Active Directory, which can today be easily identified and exploited by any insider / intruder who knows how to determine effective permissions in Active Directory, even if with marginal accuracy.

Fortunately, since organizations worldwide can now accurately and efficiently determine Active Directory effective permissions, they can now finally secure and defend the very foundation of their security, their foundational Active Directory deployments.





A Note About the Black Hat Conference 2017

Folks, as some of you may know, the famed Black Hat Conference is on in Las Vegas, Nevada, USA.

Black Hat Conference

The Black Hat Conference is supposedly one of the top cyber security conferences in the world, and given how vital cyber security is today, thousands will be attending, and numerous cyber security experts will be presenting at Black Hat this year.

YET, not a single one of these top cyber security experts knows much about Active Directory Effective Permissions, or how to calculate them, or their paramount importance to Active Directory Security and thus to organizational security, or has a solution.

NOT one of them!

This, when in fact Active Directory Security is at the very foundation of cyber security of almost all organizations worldwide whose employees (from IT Security Analysts to CISOs) will be attending the Black Hat Conference in Las Vegas this year!


( Last year I learnt just how much (or should I say how little) the Black Hat Conference Review Board seems to know about Active Directory Security, when I had a chance to communicate with them about a presentation I wanted to do on Active Directory Security last year to help raise awareness, which they declined. They allowed a presentation titled "Active Directory Beyond the MCSE" by a respected MCM, but they declined a presentation titled "From Zero to Enterprise Admin Within Minutes" by former Microsoft Program Manager for Active Directory Security. In light of this, I will let you be the judge of how much they seem to know. The loss was solely theirs, and I will NOT be applying to present at the Black Hat Conference again.

In retrospect, I can't blame them, because as I have said and proven, over the years, Microsoft has provided ZERO guidance on this to the world, so how're Black Hat's experts supposed to know about this paramount aspect of cyber security? So hey Black Hat Conference Review Board, here's Active Directory Security 101 to get you guys ramped up - Active Directory Security. )


By the way, this year there will be a presentation titled "An ACE Up the Sleeve: Designing Active Directory ACL Backdoors."

Here's its description -
"Active Directory (AD) object discretionary access control lists (DACLs) are an untapped offensive landscape, often overlooked by attackers and defenders alike. The control relationships between AD objects align perfectly with the "attackers think in graphs" philosophy and expose an entire class of previously unseen control edges, dramatically expanding the number of paths to complete domain compromise.
While DACL misconfigurations can provide numerous paths that facilitate elevation of domain rights, they also present a unique chance to covertly deploy Active Directory persistence. It's often difficult to determine whether a specific AD DACL misconfiguration was set intentionally or implemented by accident. This makes Active Directory DACL backdoors an excellent persistence opportunity: minimal forensic footprint, and maximum plausible deniability.
This talk will cover Active Directory DACLs in depth, our "misconfiguration taxonomy," and enumeration/analysis with BloodHound's newly released feature set. We will cover the abuse of AD DACL misconfigurations for the purpose of domain rights elevation, including common misconfigurations encountered in the wild. We will then cover methods to design AD DACL backdoors, including ways to evade current detections, and will conclude with defensive mitigation/detection techniques for everything described."

Finally a talk at the Black Hat Conference focused on weaknesses in Active Directory DACLs !  Kudos, but/and I just have one question - What took you guys so long?!  I mean, are these "experts" just now realizing all this in 2017  i.e. 17 years after Active Directory was shipped!  We have been saying this for years now, and 've already solved this problem over half a decade ago !

The respectable "experts" giving this presentation on Active Directory Security are absolutely right that "Active Directory ACLs are an untapped offensive landscape, often overlooked by attackers and defenders alike, and that while ACL misconfigurations can provide numerous paths that facilitate elevation of domain rights, they also present a unique chance to covertly deploy Active Directory persistence." That said, what these respected experts (may or) may not yet know is that at the root, crux and heart of all this actually lie Active Directory Effective Permissions.

So, to help these experts, newbies, and the entire world, in a few days, on this blog, I'll share just how easily organizations can now find and eliminate each one of these backdoors, leaving NO room to hide, or as they persist. Interestingly, the solution to that too involves (surprise!) Active Directory Effective Permissions.  Speaking of which, I doubt there will be any mention of Active Directory Effective Permissions in the ACE Up the Sleeve presentation, again thanks to 0 guidance from Microsoft!

As for that BloodHound tool, although it has gained much popularity especially amongst pen testers, it is massively inaccurate because it makes the same classic mistake that people have been making for years now i.e. it tries to find out "who has what permissions in Active Directory" when in fact what it should be trying to do is find out "who has what effective permissions in Active Directory."  The fact that it can still find so many holes only shows and proves just how bad the situation is out there!

Technically, comparing Gold Finger to Bloodhound is like comparing a Lamborghini to a prototype of the world's 1st car.

The one other very important thing to note is that while Bloodhound primarily aids attackers in attacking Active Directory, Gold Finger primarily aids organizational IT personnel in defending Active Directory, and in fact today Gold Finger may be the only solution that can help organizations identify and eliminate any backdoors or paths that attackers could find using Bloodhound.


Alright, enough of this. Actually, the Black Hat Conference doesn't deserve much mention here, but since the one presentation on Active Directory is completely focused on Active Directory ACLs, and since so many organizations are tuned-in to Black Hat this week, I figured they ought to know about a matter of paramount importance to the very foundation of their cyber security.


While I'm at it, let me tell you that not a single one of the world's top cyber security companies, including Microsoft, Cisco, IBM, Google, Amazon, EMC, Dell, HP, CA, Centrify, Palo Alto Networks, Blue Coat, FireEye, CyberArk, Beyond Trust, Leiberman Software, Thycotic, Checkpoint Software, Palantir Technologies, Kasperky Labs, Tripwire, DarkTrace, Lockheed Martin, BAE Systems, Tanium, BAH, etc. etc., likely has a clue about this or a solution to help organizations determine Active Directory Effective Permissions (, when in fact likely at their very foundation too lies Active Directory.)  Not a single one of them!





In Summary

I've been sharing my thoughts and perspectives for years now, on the Cyber Security Blog, the Active Directory Security Blog, and recently on the Paramount Defenses Blog. Of all the posts I've penned thus far (, and I've penned well over a 100 by now), this is possibly the most important one yet.

It is so because what I shared today directly impacts the foundational cyber security of thousands of government and business organizations in the world, and AFAIK, nothing is more important than securing and defending the very foundation of security.


It is Paramount (; and thus the name, Paramount Defenses.)


Make no mistake about one fact - no Active Directory deployment can be secured without possessing the ability to determine effective permissions / effective access in Active Directory, and no organization (not matter how big or powerful it may be) whose foundational Active Directory is not secure, can be considered secure from a cyber perspective.

That's all for today, Day 10 of this.

Best wishes,
Sanjay


PS: If you liked this blog post, you may like reading (each one of) these + stuff here, thinking about this, and checking this out. If you only have time to read one of them, I would read this one or this - A Trillion $ Active Directory Privilege Escalation Example.