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

Monday, June 26, 2017

A Simple Trillion $ Active Directory Privilege Escalation Example (Day 6)

Dear Microsoft,

Today is Day-6 of our advanced Active Directory security school for you. I was going to talk about effective permissions today, but perhaps a concrete example might help everyone first, so today I'll present a very simple, realistic illustrative example.

This example is representative of what you may find in most Active Directory deployments today so it merits undivided attention.

Hacker trying to elevate privilege in an Active Directory deployment

It may seem a bit long and I know that these days everyone prefers a 30-second exec summary, but this illustrates a MASSIVE cyber security challenge that thousands of organizations worldwide likely face today, so you'll want to read it completely.

I only hope that someone at Microsoft has the intellectual capacity to fathom the ramifications of what I've shared below.

A 1000 Paths to Escalate Privilege to a Domain/Enterprise Admin within Active Directory -

Quick Background

It is a well-known fact that if someone can escalate their privilege to that of an Active Directory privileged user (e.g. a Domain Admin, Enterprise Admin etc.), he/she would in effect have gained complete command and control over your IT infrastructure.

Microsoft's guidance does a decent job at describing the default administrative groups in Active Directory; it communicates that all members of (and) all domain security groups considered to be privileged by default in Active Directory are afforded special protection via AdminSDHolder, a process that involves stamping a special protected ACL on all such accounts and groups.  


Most organizations have thus focused their Active Directory privileged user audit and security efforts on identifying (and protecting) all AdminSDHolder protected accounts, and have a fairly good idea of the count and identity of such accounts.

But if you look just ONE level deeper, you'll likely find...

...1000s of privilege escalation paths, leading to these privileged users.

Now, A Simple, Real-World Example

Microsoft, here's an actual real-world example with real data in the Active Directory deployment of a fictional organization. 

To keep it really simple, let's just begin by taking a look at their Domain Admins group -

The Domain Admins Group in Active Directory

As you can see, they've really locked their Active Directory down and have only 2 Domain Admins accounts in Active Directory.

In fact, let us assume that the entirety of their other default administrative groups in Active Directory, i.e. and e.g. Enterprise Admins, Administrators, Schema Admins, Account Operators, Server Operators, etc. also only have the same two members.

Based on the above, if an IT Auditor were required to report on the number of privileged users in their Active Directory, such as to demonstrate regulatory compliance, he/she'd say that this organization only has 2 privileged users in their Active Directory -
  1. The default Administrator account, and
  2. Steve Ballmer, the Domain Administrator
In fact, not only may this organization's CFO actually be signing-off on this to demonstrate regulatory compliance, but the organization would from this point on be operating on an assumption that they have only 2 privileged users in Active Directory.

Today, at most organizations worldwide, this is the extent of identifying and certifying the number of privileged users in Active Directory i.e. their IT departments do their best to identify all default administrative accounts protected by AdminSDHolder.

Keep reading...

Elementary, Watson!

One day, Mr. Watson, the organization's CISO has a visitor, Mr. Holmes, a friend. Mr. Watson gives an overview of what he does, and as the conversation flows, he shares with Mr. Holmes that in security there is such a thing as privileged users, and that their organization only has 2 privileged users in Active Directory, because the Domain Admins group only has 2 members!

Mr. Holmes

At which point, Mr. Holmes asks Mr. Watson - "But is there anyone who can change the Domain Admins group's membership?"

Slightly taken aback, Mr. Watson says - "Well, er, we never did think of that! Why do you ask?"

To which Mr. Holmes replies - "Its Elementary, Watson!

Here's why this is Elementary:  If someone can change the membership of the Domain Admin's group, he can easily control who is now and who is no longer a Domain Admin, so obviously he/she is also equivalent to being a privileged user, isn't he?!

A Simple Question, A Not So Simple Answer

Immediately after the meeting, Mr. Watson (CISO) called Mr. Ballmer, and asked - "Steve, I know we only have 2 members in the Domain Admins group, (i.e. you + the Admin account) but how many people can actually change the group's membership?"

To which Steve, the Domain Admin responded - "Er, that's a good question Sir! To be quite honest, I've never actually thought about it because I've always assumed it would just be us, but let me try to actually figure it out and get back to you!"

Steve, the Domain Admin, figured he'd begin by taking a look at the ACL of the Domain Admins group, because to answer the question, he'd need to figure out if anyone else had the ability to modify the Member attribute of the Domain Admins group -

The ACL on the Domain Admins Group

Sure enough, there were a few non-default permissions in the ACL protecting the Domain Admins group. (This was the same ACL as on AdminSDHolder, which had been customized, stamped on the Domain Admins group.) For instance, there were Special permissions granted to the IT Contingency Support Team, and Write all properties granted to IT Global Admins etc.

There were Allow permissions (and perhaps a few Deny permissions as well), there were permissions granted to individual users, security groups (which could have nested groups), well-known SIDs, relative SIDs (e.g. Self) etc. and while some were straight-forward, many were marked Special, and there were some granting Full-Control etc. In short, this didn't seem simple.

Where and how should he begin, and how might he be able to answer this simple and elemental question?!

For a moment, he sat there trying to figure out how to answer this question, as he had never really given it much thought before.

Small digression...


What a co-incidence that a world-renowned expert of Black Hat Conference Presenter fame recently (on June 13, 2017) shared light on this most basic super simple fact with the world! i.e. in Active Directory, admin rights are granted by more than groups -

I'm sorry but that snapshot above (which was sent to me by someone) was just too funny (and pertinent) not to include in here, considering that its 2017 and its been retweeted 326 times & liked 468 times thus far. Like kids say these days ROFL LMAO ;-)

A helpful tip for all such experts (including those who made BloodHound): You're off to a good start, (and (is it just me or do you too find it funny that) you're just realizing all this 15+ years after Active Directory was shipped! ;-) ) so let me help you a bit, like I helped one of your Twitter friends understand this stuff recently. If you want to do this correctly, you have a million miles to go.

In fact it's right there (two tabs to the right) in the snapshot above, but even Microsoft's experts don't get it, as evidenced here.

Oh one other thing - when it comes to Active Directory Security, I learnt that the folks at that Black Hat Conference don't seem to know much. They're so new to this stuff which is why I for one will never be applying to present at that conference again.

End of Small digression...

Aha!  (It is "Who has what Effective Permissions",  Not "Who has what Permissions")

He figured he'd Google the term "Active Directory Permissions Audit" and when he did, he mostly came across numerous advertisements from various vendors, all claiming to help him "Find out who can do what in Active Directory", so he requested trials from all of them, only to come to the realization that all they were doing is helping find "Who has what Permissions in Active Directory", which was hardly useful considering just how many complexities there are in determining who can actually do what in Active Directory, such as correctly taking into account conflicting permissions, precedence orders, overlapping permissions, inapplicable permissions, group memberships, well-known SID inclusions (e.g. Domain Users etc.) and numerous other factors, and that none of these solutions from these vendors could help him answer this simple question.

So much so for these (clueless) vendors trying to help organizations find out "who has what permissions in Active Directory!"

As he was giving it thought, his eyes seemed to notice (almost as though for the first time ever) that there was an Effective Permissions tab as well, and he thought that perhaps that might be something relevant and important given that there's an entire tab for it, so he figured it may have something to do with what he was trying to figure out, so he clicked on it to view it -

The Effective Permissions Tab

Aha! It is upon reviewing this tab he realized that indeed, in order to answer this simple question correctly (i.e. accurately), he would need to take all the permissions specified in the object's ACL into account TOGETHER (and not separately), and that he would need to determine who has sufficient "effective permissions" to modify (i.e. write) the "member" attribute on the group.

[ Quick background on why one needs to determine effective permissions to answer this, and all such questions - a user could be directly or via (direct or nested) group membership(s) allowed a specific set of permissions in one or more ACEs, but could also be denied the same or a subset of those permissions directly or via (direct or nested) group membership(s) in one or more other ACEs that exist in the ACL, and whilst some of these grants may be explicit, others may be inherited, and while some might apply to the object, others may not, and thus in order to determine the user's actual resulting access, one would need to collectively (i.e. TOGETHER) consider the cumulative impact of all the permissions specified in all the ACEs in the ACL. ]

Er, No Solution?

Once he had determined that he needed to determine effective permissions, he figured that he would just use Microsoft's Effective Permissions Tab to do so. It is when he tried to do so that he realized that this tab could at best determine (an approximation of) effective permissions for one user at a time. Since they have 1000s of users in their Active Directory, there was no way he was going to manually enter 1000s of names one-by-one into this tab, then make a note of each individual user's effective permissions.

Upon doing some research online, he realized that all of Microsoft's native tooling related to any sort of effective permissions calculations in Active Directory, such as dsacls, acldiag, accesschk, scripts on TechNet, PowerShell etc., (as well as this ridiculously stupid and dangerously inaccurate free tool) were all substantially inaccurate/inadequate, and thus hardly useful.

So he called the CISO and said - "Mr. Watson, it appears that to answer your question, we need to be able to accurately determine something called effective permissions on the Domain Admins group, but it appears there's no solution to do so, i.e. there appears to be no way to do so easily and accurately, so I'm afraid I don't think we'll be able to figure this out."

Mr. Watson

Mr. Watson replied - "Mr. Ballmer, its 2017. 100% of all major recent cyber security breaches have involved the compromise of a single Active Directory privileged user, and there are a 1000 cyber security companies out there, and you're telling me that there is no way to figure out something as elemental as how many people can control our Domain Admins group membership?!"

The Domain Admin replied - "Well, Microsoft does not have any tooling that can do this accurately and efficiently, nor does any cyber security company covered by what's that company again, yes Gartner. In addition, all the vendors in the Active Directory space merely have simple permissions audit solutions which cannot solve this problem, and no major cyber security or IT company including Dell, EMC, RSA, Palantir, Tanium, Cisco, HP, Centrify etc. and I could name 992 more, seem to have any solution to this problem."

Mr. Watson replied - "Well, look harder, because we have got to be able to figure this out! Can you imagine that we, a multi-billion $ company, don't even know how many individuals can change the membership of our Domain Admins group!"

So Mr. Ballmer did, and just as when he was just about to give up, he chanced upon this, and here's what happened next...

Click, Done

He launched Gold Finger, selected the Effective Permissions Calculator, pointed it to Domain Admins and clicked ONE button -

Gold Finger Effective Permissions Calculator

He realized that even if he did not know a thing about Active Directory technical stuff, he could still have been able to do this by selecting the Effective Access Calculator and done the same -

Gold Finger Effective Access Calculator

In less than 15 seconds, he had uncovered for the first time ever, that although they only had 2 Domain Admins, there were in fact 6 individuals in total who could change the membership of the Domain Admins security group -
  1. The Administrator account
  2. Erica Lockhart
  3. Larry Page
  4. Steve Ballmer (himself)
  5. Ted Schlein
  6. Victor Lombardi
(Technically speaking, here's what the tool did: convert this to this.)

It was partly shock and partly awe, so he immediately called the CISO and informed him that there were a total of 6 individuals who could change the membership of the Domain Admins group, and thus that they may have been operating under a false assumption all this while, and in fact may also have furnished inaccurate evidence to demonstrate regulatory compliance.

There was silence for a moment on the phone.

Mr. Watson asked the Domain Admin - "Well, is there anyone that stands out in particular?!"

Mr Ballmer replied - "While all four are surprising, one in particular is most surprising - Ted Schlein, he's a junior IT operator!"

Wow, they had just discovered that amongst others, a junior IT operator could control the Domain Admins group's membership.

Mr. Watson was a quick learner, so he asked "Well, can you find out how many people can reset Mr. Schlein's password?"

Slightly taken aback, Mr. Ballmer says - "Well, er, I've never thought of that! Why do you ask?"

To which, this time around, Mr. Watson replied - "Its Elementary, Ballmer!

Here's why this is Elementary:  If someone can reset the password of a Domain Admin, he can instantly become the Domain Admin and login as the Domain Admin, so obviously he/she is also equivalent to being a privileged user, isn't he?!


This time around the Domain Admin, Mr. Ballmer, pointed Gold Finger at Ted Schlein's account and clicked a button -

Gold Finger Effective Permissions Calculator

In less than 15 seconds, he had discovered, again, for the first time ever, that 28 more individuals possessed sufficient effective access on Mr. Ted Schlein's domain user account in Active Directory so as to be able to reset his password -
  1. Administrator
  2. Chris Warner
  3. Costas Dimitriou
  4. David Parker
  5. Ed Newman
  6. Eric Boyle
  7. Erica Lockhart
  8. Frank Murphy
  9. Gabriel Peterson
  10. James Walsh
  1. Jeff Bezos
  2. Juan Batista
  3. Julia Walker
  4. Kid Zuckerburg
  5. Larry Page
  6. Laura Michelson
  7. Marc Benioff
  8. Michael Karp
  9. Patrick Sullivan
  10. Quincy Lawson
  1. Ray Lane
  2. Ryan Johnson
  3. Satya Nadella
  4. Steve Ballmer
  5. Susan Williams
  6. Ted Schlein
  7. Troy Williams
  8. Victor Lombardi
  9. Vincent Smith
  10. Yaris Constantinou

In other words, they had just discovered at least 28 more individuals who were 10 seconds away from gaining sufficient access to an account that had sufficient access to instantly obtain complete command and control over the Domain Admins group!

(Technically speaking, here's what the tool did: convert this to this.)

Mr. Ballmer called Mr. Watson - "Sir, I think you'll want to see this in person!"

Privilege Escalation Paths

As I said, Mr. Watson was a quick study, and by now had figured out that if 28 more people (than they knew about) could reset the password of a user who could change the membership of the Domain Admins group, there were at least 28 privilege escalation paths to becoming a privileged user in their Active Directory.

He figured that if this simple logic was iteratively applied on to these 28 accounts, the number of paths could possibly be in the hundreds, and with each additional level of iteration, they would likely substantially increase. In fact, if one were to consider all the IT assets stored in Active Directory, by extrapolation, there could be 1000s of privilege escalation paths in Active Directory!

Privilege Escalation Paths in Active Directory

So he asked Mr. Ballmer, the Domain Admin a simple question - "With this tool that you've found, it appears you can do this one object at a time, but we have 1000s of users, so is there an easy way to quickly (efficiently) and accurately figure out who can reset whose passwords in Active Directory, because if we could do so, we may find 1000s of privilege escalation paths?"

Impossible? Done

It turns out that in the whole wide world, with trillions of $ being protected by Active Directory, there is all of ONE way to do this.

Mr. Ballmer used the tool selector in Gold Finger to select the Administrative Access / Delegation Audit Tool, selected the report Who can reset user account passwords?, set the scope to be the entire domain and clicked ONE button -

Gold Finger Administrative Access / Delegation Audit Tool

In seconds, Gold Finger had accurately and efficiently determined effective permissions / effective access on all domain user accounts in their Active Directory and revealed possibly the most valuable intelligence/insight they had seen in years - the complete and accurate list of exactly who can reset whose passwords in their Active Directory, and how they can do so.

To view the actual output of this effective access assessment in this small domain, please click here.

(Technically speaking, here's what the tool did: convert this to this.)

To make a long story short, if you have or possess the ability to accurately assess access entitlements of an entity in a system, which as it pertains to Active Directory means if you have the ability to accurately determine effective access provisioned in Active Directory, then you'll be able to uncover thousands of privilege escalation paths in Active Directory deployments.

In this puny Active Directory alone, there were hundreds, such as this one -
  • Ted Schlein, a Junior IT Operator, can change the Domain Admins group membership
  • Kid Zuckerburg, a Junior IT Analyst, can reset Ted Schlein's password
  • Larry Page, an IT Support Admin, can reset Kid Zuckerburg's password
  • James Walsh, an IT Web Administrator, can reset Larry Page's password 
So, the path is:  James Walsh > Larry Page > Kid Zuckerburg > Ted Schlein > Domain Admins group

For a limited time, you can do this for free (one object at time though), courtesy Gold Finger Mini, which we had recently decided to make available for free to help CEOs, CIOs and CISOs see for themselves just how bad the situation really is.

In most real-world, production Active Directory environments, you'll likely easily find 1000s of such privilege escalation paths.

The Weakest Link

For now, the CISO wanted to know what the weakest link might be i.e. is there a link wherein the starting point might be rather easily compromisable, and one that could within minutes easily lead to one gaining privileged access in Active Directory?

So they analyzed the effective access entitlement data that the tool had generated within seconds and guess what they found?

Here's likely the shortest privilege escalation path that could also possibly be the weakest link in this Active Directory -

  • Larry Page, an IT Support Admin based in USA, can change the Domain Admins group membership
  • James Walsh, an IT Web Administrator based in USA, can reset Larry Page's password
  • Kevin Mandia, a temporary contractor based in India, can reset James Walsh's password 
So, the path is:  Kevin Mandia > James Walsh > Larry Page > Domain Admins group

It is possibly the weakest link because it begins with a temporary contractor's account, one that is located in a foreign country and possibly not as protected as the Domain Admin's account, and possibly one that is much more easily compromisable, and leads right to Domain Admin, and merely involves the enactment of 3 simple common tasks that all intermediate accounts involved in the escalation chain already have sufficient access to enact!

[ By the way, in case you're wondering how Mr. Mandia ended up with such access on Mr. Walsh's account, it turns out that someone meant to grant the IT Helpdesk Backup Team Send As permissions on Mr. Mandia's account, i.e. in the ACL (here) protecting his domain user account, but accidentally ended up granting the IT Helpdesk Team Reset Password permissions (which is right below the Send As permissions in Microsoft's ACL Editor UI), resulting in a situation wherein Kevin Mandia, a member of the IT Helpdesk Team ended up getting sufficient effective permissions to be able to reset Mr. Walsh's password. ]

Also, one doesn't need admin credentials to uncover such excessive grants; any domain account will do. In fact, intruders could use Microsoft's free tools (e.g. acldiag) to find low-hanging fruit i.e. any obvious and glaringly apparent excessive permissions. In fact, if you assume breach, then an intruder could take his sweet time to engage in unaudited read-only activity to analyze Active Directory ACLs, and over some time try and find various privilege escalation paths.

Here's a closer look at Kevin Mandia's domain user account in Active Directory -

Kevin Mandia's account viewed in Active Directory Users and Computers

As seen above in Microsoft's UI, Mr. Mandia is a temporary contractor based half way around the world, in Bangalore, India.

So, in effect, if perpetrators could compromise the domain account of this 1 temporary contractor located in Bangalore, India, they could obtain control over the foundational Active Directory of this fictional $ multi-Billion U.S. organization, in minutes!

Think about it for a minute - Microsoft suggests that organizations assume breach. Based on what's been going on, if credential-theft and other techniques can be used to compromise Domain Admin accounts, imagine how much easier it is to compromise a regular domain user account (or his computer), especially one belonging to a temporary contractor! All that the perpetrators need to do is to compromise Mr. Mandia's credentials or his computer and that's it, because the rest is child's play.

To visualize this, imagine that an APT is able to compromise Kevin Mandia's account in Bangalore at 12:30 pm local time (IST), which is 3:00 am (EST) in New York. By 3:02 am (EST) New York Time, they would have enacted 2 legitimate password resets and a group membership change to effectively gain Domain Admin privileges. By 3:05 pm New York Time (EST), they would have removed all existing members from the Domain Admins group, and completely locked down access on/to it, and in effect, they would have gained complete command and control over the Active Directory in less than 5 minutes!

This, while the organization has been operating on the assumption that they only have 2 privileged users in Active Directory.


Once the CISO had visualized this, he called the CEO and said - "Sir, I think we may have a problem."

To which the CEO's immediate response was "Before you describe it, tell me, is there a solution?"

(To know the answer , please keep reading.)

There's an old saying - "To the wise, a hint is enough.

If you're smart, I needn't say a word more; if you're not, I could go on forever and you still wouldn't get it, so this example ends here.

(But the answer is below.)

One Quick Point

To those who might say, well all that's involved here is a password reset, allow me to widen your horizons a bit, because a password reset is merely one of numerous ways in which you can exploit excessive/unauthorized permissions in Active Directory to gain all sorts of privilege -

  1. Password Resets - Password resets are the most obvious and easiest way, because if you have sufficient rights to do so, all you have to do is click a button to compromise that user's identity and elevate privilege.

  2. Membership Changes - Membership changes are the 2nd most obvious way, because if you have sufficient rights to do so, again all you have to do is click a button to be a member of that group and elevate privilege.

  3. ACL Changes - ACL changes on objects are the most powerful way, because if you have sufficient rights to do so, again all you have to do is click a button to control all access on that object and elevate privilege.

  4. GPO Linking - GPO linking is one of the easiest ways to compromise computers, because if you have sufficient rights to do so, all you have to do is click a button to gain privileged access to the computer (and thus to almost everything on it) and elevate privilege.

  5. Kerberos Delegation Bits - Modifying bits that control an account's Kerberos delegation settings could enable you to impersonate a user across the network, and if you can do so, you could easily (set up to) impersonate a privileged user.

  6. Disabling Smart-card Authentication - If you have sufficient access to disable Smartcard authentication on a domain account, you could weaken security as when you do so, the account will now only be protected by a random password, and if you also happen to have sufficient access to reset its password, you'll have elevated your privilege to that account.

  7. Tampering a Service Connection Point - If your organization relies on a 3rd party solution (e.g. this one) to enhance and/or strengthen access, and to properly function that solution relies on service connection points (SCP) in Active Directory, then if you can tamper with that solution's SCPs (e.g. modify its keywords), you could instantly render it useless, thus weakening the security of all IT assets that service helps protect.  

I've shed light on just a few. The more time you spend on this stuff, the more you'll learn and the more ways you'll find.

Oh, and if you think these band-aids will solve the problem, request us, and we'll show you how easy it is to circumvent them.

The Root Cause

At the root/heart of everything I have shared above lies a deep and vast ocean of Active Directory security permissions.

A Vast Ocean

In fact, at the heart of everything I have shared above is a very simple fact - in most foundational Active Directory deployments worldwide, IT departments have been provisioning all kinds of access to fulfill various business needs for years now, and given the complexity of Active Directory's security model and the intricacies involved in access provisioning, such as the fact that when you use groups (as you should), their underlying memberships can change, and above all the fact that while it is easy to precisely provision access, it is very difficult to precisely assess resulting access (because the means to precisely assess resulting access don't exist, as described here) so obviously today there's a dark ocean of security permissions in Active Directory, and together they effectively end up granting an alarmingly vast amount of excessive/unauthorized access on literally everything in Active Directory.

Here's a clarified glimpse of what one drop in the ocean looks like -

ACL on Ted Schlein's Active Directory User Account

What I've shown above is merely a portion of the access control list (ACL) protecting Ted Schlein's account, here.

As you can see, there are numerous access control entries (ACEs) each one specifying one or more types of over a dozen Active Directory security permissions, some of which may be allowed while others denied, and some of which may be specified explicitly while others may be inherited, and of the ones inherited, some may actually apply to the object while others may not, and each such permission is specified for a security principal which might be an individual user, a security group (which may additionally have others security groups nested in it), a well-known security principal (such as Authenticated Users), relative SIDs (such as Self) etc. and it is the entirety of all this taken together that determines who can do what on an Active Directory object, in this case Schlein's account.

In most Active Directory deployments today, there are thousands, if not hundreds of thousands, of such ACLs, and in so many Active Directory deployments, there are as many as 100+ ACEs in each ACL, so there are millions of ACEs in Active Directory that whilst specified individually, ultimately collectively determine the resulting effective access across Active Directory.

Dear Microsoft, in light of this complexity, how are IT personnel reasonably supposed to make any sense out of it?!

What the World Needs

Today, the entire world (i.e. thousands of business and government organizations worldwide) operates on Active Directory.

What the world needs is the ability to accurately and efficiently convert this (protecting this) into this so that we can tractably and easily make sense of this ocean and achieve least-privileged access in our foundational Active Directory deployments, which today are paramount to cyber security.


To summarize, today via the above, I just wanted to make the following points -

  1. A 1000 Ways to Become Domain Admin - Even in Active Directory deployments wherein credential-theft attacks may no longer be possible, there are still a 1000 ways to elevate privilege to Domain Admin, as shown above.

  2. An Ocean of Active Directory Security Permissions - This is made possible because there exists an ocean of security permissions in each Active Directory that ultimately governs effective access on everything stored in Active Directory.

  3. Perpetrators May Be On to It - As evidenced by recently introduced free tooling, notably BloodHound which incidentally is substantially & laughably inaccurate, the hacking community has started focusing on weaknesses in Active Directory. 

  4. This Impacts all Active Directory Deployments - Today, irrespective of size, this problem is present in every Active Directory, and organizations that do not care about addressing it might end up being sitting ducks for perpetrators.

  5. Today, an Easily Addressable Problem - Organizations that operate on Active Directory and wish to address this serious problem now actually have the ability to do so. Whether or not they choose to address it is entirely their call.


(This part was added later, inspired by a buffoon who left a most ridiculously immature and stupid comment.)

The only reason we had to use Gold Finger in this example is because it is the only tool (that we know of) that can so easily demonstrate the presence of 1000s of privilege escalation paths in Active Directory. This is NOT meant to promote Gold Finger.

Let me repeat that - we have no particular interest in promoting Gold Finger. In fact, in 10+ years as a company, we have NOT once marketed our products, sent a single unsolicited email to anyone, made a single unsolicited phone call, or pitched our product to ANYONE. Not once. During the same period, almost 10,000 organizations have knocked at our doors, unsolicited.

So to that buffoon I'd say - "Buzz off !"  (Why don't you focus on the problem, instead of on the tool used to shed light on it?)

Mature organizations have to assume that there may be nefarious entities out there, some possibly (heavily) state-sponsored, who could have clandestinely developed (and could use) similar tooling. To not assume so would be to be incredibly naïve.

All we care about is organizations addressing this risk (, because left unaddressed, it will remain a huge security risk (and we can demonstrate it to any organization that requests us)), and of course they can use any means they like, to address it.

Again, let there be NO mistake whatsoever about this. I should not have to repeat this again.

I will say this much though, and stand by it - "For all the marketing noise and grandiose claims that the 1000+ cyber security companies and major tech / defense companies out there make, we do find it laughable that not one of them has a solution for such a profoundly elemental and fundamental problem!"

That's it for today. More in the next few days to come. Stay tuned.

Best wishes,

PS: As to that Jr. IT Operator, Ted Schlein, his name and title were inspired by this supposedly brilliant cyber security visionary, who failed to understand even such simple stuff, a decade ago, and passed on helping out. Hey in a way, I'm thankful to him ;-)

PS2: Microsoft, in essence,  this  to  thisGet it?!    (To gain a deeper understanding of how all this works, you'll want to read the one patent that governs the determination of effective access in Active Directory deployments across the world - this one.)

No comments:

Post a Comment