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.

Thursday, November 20, 2014

CVE-2014-6324: Elevation of Privilege Vulnerability in Kerberos in Windows - Microsoft, are you Kidding?


Earlier today, Microsoft released a critical emergency security patch MS14-068 to help organizations patch a vulnerability in Kerberos that could allow elevation of privilege.

This is a very serious vulnerability because it could allow an attacker to elevate unprivileged domain user account privileges to those of the domain administrator account. An attacker could then use these elevated privileges to compromise any computer in the domain, including domain controllers.

Quoting from here -

"This vulnerability stems from the way in which Windows Kerberos validates the PAC in Kerberos tickets. Prior to the update it was possible for an attacker to forge a PAC that the Kerberos KDC would incorrectly validate. This allows an attacker to remotely elevate their privilege against remote servers from an unprivileged authenticated user to a domain administrator."

Microsoft, seriously, are you kidding?

You are arguably the 3rd most powerful company in the world, you know that virtually the entire world is operating on Microsoft Windows, more importantly, that most business and government organizations operate on Microsoft Windows Server, and you go 14 long years without someone internally finding this vulnerability!

I mean, this isn't your ordinary vulnerability. After all, it allows a perpetrator to forge a Kerberos PAC!

With all due respect, you've got to better than this. With the entire world running on Microsoft Windows, you bear a great onus, and that is to ensure that you minimize the existence of such highly damaging vulnerabilities in Windows.

I don't care if you have to spend a $ billion to enhance your internal security research. You're a $400B company, so a petty $B is nothing in contrast. My humble suggestion to you is to take this stuff very seriously and go to the greatest lengths to ensure that such critical vulnerabilities are identified and eliminated ASAP.

From our side, we're doing our best to help organizations worldwide address the world's #1 cyber security risk to Microsoft Windows environments, Active Directory Privilege Escalation, and by the same token, we expect you to do the best when it comes to ensuring that such code-based vulnerabilities are identified and fixed.

Best wishes,

PS: Folks, this blog post is short by intention, and aimed at helping organizations understand that this is a very critical vulnerability and that they should apply this patch immediately.

Tuesday, July 29, 2014

A Demo of How a Trusted Insider or an Advanced Persistent Threat (APT) Could Easily Compromise Any Active Directory Deployment in the World within Minutes


At Paramount Defenses, we know a thing or two about Active Directory Security, yet out of respect for organizations worldwide, we have NEVER directly demonstrated how a trusted insider could enact the #1 threat to Active Directory deployments today.

However, it appears that a recent inaccurate claim related to Active Directory security seems to be distracting organizations from arguably one of the world's top cyber security threats to not just 95% of the Fortune 1000 but to 85% of all organizations worldwide, so we felt it was necessary to demo just how easily a malicious insider could compromise an(y) Active Directory.

Today I'm going to show you how just how easily a malicious insider could compromise an(y) Active Directory deployment in the world, within minutes, without so much so as owning a machine, let alone using sophisticated techniques like Pass-the-Hash.

The Set Up

For the setup, lets consider a fictional multi-national organization that operates in multiple continents, and has 1000s of employees and contractors, as well as computers, and of course, millions of IT resources stored on these computers.

Let's assume that the accounts of 1000s of employees and contractors are all stored in Active Directory, and that a majority of the 1000s of computers are all domain-joined as well, and finally that there exist 1000s of domain security groups that collectively serve to protect the entirety of their IT assets.
An Active Directory Deployment Spanning 4 Continents

Let's also assume that in order to manage all these resources, the organization has delegated administrative authority amongst its global IT team, which is comprised of numerous IT personnel.
Members of the IT Team that have been delegated varying levels of access in Active Directory

Let us further assume that this organization has delegated administrative authority amongst its IT admins based on the principle of least privilege, and thus currently has only 1 Domain Admin account, other than the default Administrator's account.

To keep it simple, assume that account management tasks have been delegated to the Account Management Team, computer account management tasks to the Host Management Team, security group management tasks to the Access Management Team, and that help desk related tasks including Password Resets have been delegated to the global Help Desk Team.

Finally, let's assume that their Active Directory has been around for at least a few years, and that they've been delegating access in Active Directory for years now, as a result of which there's a fair bit of delegation done in the Active Directory.

Let us also keep in mind that although they've done their best to delegate authority based on the principle of least privilege, they have no way of verifying delegations, and thus can only hope that their delegations adhere to the principle of least privilege.

In summary -
  • The Active Directory is spread across 4 continents - America, Europe, Asia Pacific and Australia
  • There are 1000s of domain user accounts in Active Directory for employees and contractors
  • There are 1000s of domain computer accounts in Active Directory, one for each machine (laptop, desktop, server)
  • There are 1000s of domain security groups in Active Directory, and are used to provision access company-wide
  • There is 1 Domain Admin (; realistically most organizations have 20+ Domain Admins)
  • The Account Management Team is delegated all account management tasks
  • The Access Management Team is delegated all security group management tasks
  • The Host Management Team is delegated all computer management tasks in AD, and via GPOs
  • The Help Desk Team is delegated password reset operations across the Active Directory
  • Delegations are extensively done, but the organization does not have the means to audit/verify these delegations, so they do not know if delegations adhere to the principle of least privilege.

Objective - Obtain Domain Admin Credentials

The objective is to obtain Domain Admin credentials, because if you can do so, you can in effect, control the entire Active Directory, and by extension the entire IT infrastructure (using GPOs, Security Groups, etc.).

As you may know, in addition to obtaining access to any IT resource in the organization, there are some other things you can do once you're a Domain Admin - immediately lock everyone else (including all admins) out before you start to wreak havoc, disable auditing, prevent everyone else from logging on, etc (The list is long.)

In this fictional demo deployment, there is only 1 Domain Admin account, apart from the Administrator account -

As you'll hopefully agree, most organizations have many more Domain Admins than 1, so we're being very kind to this fictional organization in this demo. (With each additional Domain Admin, the attack surface increases exponentially.)

Attacker and Starting Point - An Ordinary Domain User Account

Assume that the attacker is a temporary contractor who happens to be on a 3-month contract with the organization. His fictional name is Kevin. All he has is a domain-joined laptop given to him to by the company and a regular domain-user account.

He has NO administrative rights whatsoever anywhere in the Active Directory, or on any domain joined or non domain joined machine, except the ability to install software on his assigned laptop.

He also has NO knowledge of security concepts like Kerberos, NTLM, Hashes, Firewalls etc. Consequently, of course, he does not have the skill to use advanced techniques like PtH.

[A Side Note to PtH Users ]

Unlike you, our attacker is a complete non-techie. He has no hacking skills, has no clue what a hash is, so of course, has no idea as to how to use Pass-the-Hash etc. He technical skills are limited to using MS Office.

Oh, just one more thing. The Domain Admin does understand how PtH works, so he NEVER logs on to any other machine except his dedicated Domain Admin laptop, which is always with him, and he only uses it to carry out Domain Admin related responsibilities. He does not check his mail on it, browse the Web, or any Intranet site from that laptop. The only tools on that laptop are ADUC and some of Microsoft's AD related utilities like ntdsutil, dsacls, LDP etc. No freely downloaded tools whatsoever. He of course also never Remote Desktop's into any machine using his Domain Admin creds.

So even if you compromise a machine on the inside, you can sit and wait and wait and wait and wait for him to logon to the machine you 0wn on the network, and you might get old waiting, because he's NOT going to logon to your machine, so you're not going to get him via a PtH attack.

Sorry :-(


Let's assume something has upset Kevin, our contractor; could be anything; the motive is relatively inconsequential. Lets assume that he decides to get even, and he figured he's going to do so by become the most powerful individual in the company, the Domain Admin.

  • Side note- Contrary to popular belief, the most powerful individual in an organization is not the CEO. the most powerful individual is he/she who ultimately controls access to the entirety of the organization's IT assets - the Domain Admin.

In other words, we now have a malicious trusted insider in our environment!

Attack Methodology

So we have a malicious insider who knows nothing about cyber security.

All he knows is that once when he had forgotten his password, he was asked to call Help Desk, and when he did, they reset his password and assigned him a temporary password, with which he could instantly logon. So he figures that if he could reset someone's password, he could then logon as that individual. For instance, anyone who can reset the CEO's password can then logon as the CEO.

Finally, he knows that there is a local IT admin on-site (details below), who has previously assisted him with issues he may have had on his laptop.

Oh yes, and he knows one other thing - he knows the name of the Domain Admin, only because the Domain Admin was recently honored by the company in its monthly newsletter for all the great work he's been doing, as a result of which he actually made the company newsletter's front page with a headline that read - Honoring Steve Ballmer, Our Domain Admin!

Now, his ultimate target is the Domain Administrator Steve Ballmer, so he figures, why not try and find out who can reset Steve Ballmer's password, and let's assume he finds that another delegated IT admin named Kid Zuckerburg can reset Steve Ballmer's password, why not try and figure out who can reset Kid Zuckerburg's password and iterate this process over and see where it leads to.

You never know, he may find that ultimately that path ends at his local IT admin.

So, all he needs to do is find out who can reset whose passwords, until he can find someone whose account he can easily compromise. Once that's done, all he needs to do is a couple of password resets, each one taking just a few seconds, and he will have obtained Domain Admin credentials within a matter of minutes, without having to compromise a single machine.

Some Quick Theory

In case you find yourself wondering - "but wait, trying to find out who can reset a domain user account's password is by no means an easy task."

You're absolutely right. It is NOT an easy task. At a minimum it requires -
  1. Read access to the target user's account in Active Directory
  2. A tool, such as ADUC, with which you can view Active Directory content and look at AD ACLs
  3. The knowledge and expertise to examine an AD object's ACL and accurately determine effective permissions.
  4. Access to a tool, such as ADUC, that allows the user to perform password resets 
Its worth noting that of these 4 requirements , requirement #3 i.e. accurately determining effective permissions on Active Directory objects is not only the most critical one to fulfill, it is the most difficult one to fulfill.

The ACL on the Domain Admin, Steve Ballmer's Account

Even the most experienced of IT personnel (such as Enterprise Admins) do not know how to do this correctly a 100% of the time, and each time they attempt to do so, it can easily take anywhere from 30 minutes to an hour to figure this out.

So, how is our attacker, who doesn't even know what a hash is, let alone what effective permissions are, possibly going to fulfill these 4 requirements?

Keep reading.

Oh, Just One Other Thing - Smartcards

In case you find yourself saying - "but we use Smart-cards, so this doesn't apply to us." I have some not so good news for you. It unfortunately still applies, because someone can easily disable the requirement to use smart-cards by modifying the userAccountControl attribute on the user account. Once that's disabled, the account's back to relying on passwords.

The Cast

Before I walk you through a step-by-step demo, lets get introduced to the IT personnel involved in this fictional demo. Kindly note that all names are fictional and that any resemblance to real individuals bearing these names is completely coincidental.

That said, here's the cast -
  • The Attacker - Kevin Mandia, is a temporary contractor who works for a fictional company called Mundane
  • The Domain Admin - Steve Ballmer, an IT Analyst, is the most powerful individual in this organization
  • The Delegated Admin - Kid Zuckerburg, a Jr. IT Analyst, is a member of the Account Management Team
  • The Help-Desk Operator - Larry Page, an IT Support Analyst, is a member of the Help Desk team
  • The Local IT Admin - Ted Schlein, a Jr. IT Operator, in addition to being a member of the Help Desk team, is also a local on-site IT admin at the attacker's location

(The titles of these fictional employees can be verified by viewing the Setup snapshot above.)

Now, to the demo...

The Demo - Ordinary User to Domain Admin in Minutes

Our attacker, Kevin, who is now a malicious insider, figures that what he needs to do is analyze who can reset whose passwords. He has no idea how difficult it is do so, but he figures that since these days there's a tool to do just about everything, there must be a tool to do password reset analysis as well, so he launches his favorite Web browser and performs an online search to see if there's any such thing as a "Password Reset Analysis Tool"

He happens to across this tool -

  • Note that this tool is designed to assist employees in assessing the risk to their own accounts. However, in this case, a trusted insider is unfortunately going to misuse it, thereby breaching the trust we (Paramount Defenses) impose in employees of organizations worldwide. It only takes 1 trusted insider to breach the trust that we, and their organization, imposes in them.

Anyway, he first downloads and installs the free edition on his laptop (which is a domain joined machine) and then tries it out, all of which takes about 2 minutes. He figures he'll need a 007 edition license, so he acquires one, in another 2 minutes.

Now, there are 3 parts to this attack vector - 
  1. Privilege Escalation Path Identification - This is the most difficult part, and without appropriate tooling, this part can take even an expert hours to accurately perform, per account. With the right tooling however, it only takes seconds.

  1. Starting Point Compromise - This part involves compromising the initial starting port in the privilege escalation path. This can be accomplished in various ways, one of which is described below. This may not always be necessary, for instance, if the attacker happens to be a delegated admin with sufficient delegated rights in Active Directory.

  1. Privilege Escalation via Password Resets - This is the easy part, and usually only takes a few seconds.

Before we Begin - Ordinary User Verification

Prior to beginning, the attacker Kevin uses whoami to verify that he does not have any administrative privileges -
As one can see above, he is not a member of any administrative group whatsoever.

Part 1 - Privilege Escalation Path Identification        (Time involved: 5 minutes, Effort required: Minimal)

Clock Start Time:  2:00 pm

Our attacker Kevin downloads and installs the tool and the license on his laptop, then launches it to begin -

  • Technical Note - It is important to note that when launching the tool on a Windows Server 2008 machine or beyond, he will need to set the Compatibility Mode to Windows XP Service Pack 3 -

Before proceeding, he quickly verifies his licensing details by clicking on Help, then on About -

 He then proceeds to select the second report "Who can reset a colleague's account's password" -

He then clicks the search button located to the right of the drop-down to access the inbuilt Account Locator -

Now, he enters the word "Steve" as the only thing he knows is that the Domain Admin's name is "Steve Ballmer". The locator finds and displays the Domain Admin's account, and he select's it -

That's it. The tool is now ready to find out within seconds, exactly who can reset Steve Ballmer's password (i.e. the Domain Admin's password) -

He clicks the Gold Finger button (i.e. the big button with the golden hand on it) which is the equivalent of the Run button) and within seconds, the tool determines and displays the list of all individuals who can currently reset the Domain Admin's account's password -

He finds that only 2 other individuals can reset the Domain Admin's password, one of whom happens to be a delegated admin, Jr. IT Analyst, Kid Zuckerburg, so he figures it might be worthy finding out who can reset Mr. Zuckerburg's account's password.

So he proceeds to locate Kid Zuckerburg's account using the inbuilt Account Locator -

He is now ready to find out who can reset Kid Zuckerburg's account -

He click's the Gold Finger, and within seconds, learns that 19 individuals can reset Kid Zuckerburg's account. Their identities are displayed by the tool -

Curious to see the entire list, he scrolls down a bit, and finds that amongst others, Larry Page, another delegated IT support admin, can reset Kid Zuckerburg's password -

So he proceeds to locate Larry Page's account using the inbuilt Account Locator -

He is now ready to find out who can reset Larry Page's account -

He click's the Gold Finger, and within seconds, learns that 22 individuals can reset Larry Page's account. Their identities are displayed by the tool -

He finds that the 2nd name on this list is that of none other than the local IT admin at his location, Ted Schlein, who in addition to being a local IT admin is a member of the Help Desk team -

This is a very valuable find, because what it means is that if somehow, he can compromise Ted Schlein's account, he would in effect be just 2 minutes (i.e. 3 password resets) away from becoming a Domain Admin!

Why (, or how so) ?

Very simple - thus far he has found that -
  1. Kid Zuckerburg (a Jr. IT Analyst) can reset Steve Ballmer's (a Domain Admin) password,
  2. Larry Page (an IT Support Analyst) can reset Kid Zuckerburg's password, and
  3. Ted Schlein (a Jr. IT Operator and a local on-site IT admin) can reset Larry Page's password. 
So, if he can somehow compromise Ted Schlein's account, he can login as Ted and reset Larry's password. He can then instantly login as Larry and reset Kid's password. He can then login as Kid and reset Steve's password. That's it. Once he has reset Steve's password, he can login as Steve and be a Domain Admin! (By the way, it takes about 5 seconds to reset someone's password.)

In other words, he has now found his starting point - it is Ted Schlein, his local on-site IT admin!

By the way, a quick note about Logon Names (UPNs). The astute reader would have noticed that our malicious insider is going to need to know the UPNs of these delegated admins to logon as them. Although he does not know the UPNs, the tool displays the UPN of each user, so determining the UPN is just a matter of scrolling the results in the Account Locator -

With that out of the way, on to the 2nd part.

Clock End Time: 2:05 pm

Part 2 -Starting Point Compromise          (Time involved: 3 minutes, Effort required: Minimal)

Clock Start Time: 2:06 pm

It's time to compromise the initial starting point. There are many ways of doing so, but since we have assumed that the attacker has no IT security knowledge, we'll use one involving just a little bit of Social Engineering.

The attacker, who is a contractor, and now a malicious insider, places a surveillance clock on his desk such that the hidden camera in the clock can take a video of the keyboard.
He then walks upto Ted Schlein, the local on-site IT admin, tells him that something doesn't seem to be working right on his laptop, and requests him for some urgent technical assistance with his laptop.

Ted Schlein comes over, and in order to troubleshoot the non-existent technical issue, logs in using his own domain account and password. He finds no problems, so he lets Kevin know that all is well and moves on.

Little did he know, that the attacker, albeit technically unsavvy, managed to capture a clear enough video of Ted Schlein entering his username and password via that surveillance camera he had set up.

Clock End Time: 2:09 pm

That's it - he know has the creds of Ted Schlein, and its about 2:10 pm.
  • Note: This is merely an illustrative example. A minimally tech savvy attacker can employ various other means to learn about the local IT admin's password. Examples include shoulder surfing, keystroke logging etc. A tech savvy hacker can additionally employ hacking skills and tools to get the local IT admin's credentials, because he has both network access as well as physical access to the local admin's machine.

Although he is ready to launch his attack, he waits for an opportune time say around 6:30 pm, as he knows that most IT personnel would have left for the day, and in all likelihood be stuck in traffic somewhere.

From 2:10 pm until 6:30 pm, he goes about his work as usual.

Fast forward 4 hours and 20 minutes, and its time to complete the attack.

Part 3 - Privilege Escalation Via Password Resets       (Time involved: 3 minutes, Effort required: Minimal)

Clock Start Time:  6:30 pm

The attacker Kevin logs off his account on his own laptop, and then immediately logs back in using Ted Schlein's credentials. Since he knows the logon-name (UPN) and password, the logon succeeds, so now he is logged on as Ted Schlein -

Now, all he needs to do is reset Larry Page's password.

Note that ordinarily he would have had to use an administrative tool like Active Directory Users and Computers, but Gold Finger Mini has an inbuilt password reset capability (provided for testing purposes), which can be accessed by pressing Alt-R (for Reset).

So he launches Gold Finger Mini, then uses the inbuilt Account Locator to find Larry's account and select Larry's account. To select Larry's account, he selects it and then clicks the Select button. (When he clicks the Select button, the account is selected and control is passed back to the main window) -

He then presses Alt-R to access the Password Reset dialog -

He enters a password of his choice for Larry's account, such as WeRunOnADToo! -

He then clicks the Reset Password button, and lo and behold, Larry's Page's password has been reset! -

That took all of 5 seconds. He instantly logs off as Ted Schlein, and then logs back on as Larry Page, using Larry Page's account and password -

Same drill, next account. Time to reset Kid Zuckerburg's password. First locate the account, using the inbuilt target locator, then  press Alt-R to access the Password Reset dialog -

He then enters a password for Kid Zuckerburg's account, such as LikeThis,Kid!

He then presses the Reset Password button, and he just successfully elevated his privilege again -

He instantly logs off as Larry Page and logs right back on as Kid Zuckerburg -

Its time to perform the last step in privilege escalation to that of Domain Admin. Its time to reset Steve Ballmer's password, so he locates his account and accesses the password reset window -

He enters a password for Steve Ballmer's account, such as WhoNeedsPtHWhenUCanResetPwds?!

He presses the Reset Password button, and voilĂ , he just became a Domain Admin! -

Time to log-off as Kid Zuckerburg and logon as Steve Ballmer, the most powerful individual in the organization, the Domain Admin!

Clock End Time:  6:33 pm

Folks, our malicious insider has just escalated his privilege to that of a Domain Admin!

End of Privilege Escalation; End of Demo.

Attack Summary

In just minutes, without having to compromise a single machine, or use any sophisticated techniques like Pass-the-Hash, a malicious insider with virtually no security know-how and no administrative access of any sort, just escalated his/her privilege to the most powerful individual in the organization, the Domain Admin.


This attack vector demonstrated the risk posed by Active Directory Privilege Escalation based on the exploitation of unauthorized access grants in Active Directory, which is arguably the world's #1 cyber security risk today.

This risk stems from the fact that there exist large numbers of excessive access grants in Active Directory deployments, which without sufficient tooling/expertise, are very difficult to identify, whether by organizational IT personnel or by a malicious insider.

These excessive grants exist because although Active Directory makes it very easy to precisely delegate access, it lacks the ability to help organizations precisely verify/audit delegated access, and as a result, most organizations end up delegating access in the proverbial dark, i.e. on a best-effort basis, without any verification/proof.

Over time, the state of delegated access constantly yet subtly changes, due to administrative churn, group membership changes, ACL changes and other factors, causing currently implemented delegations to deviate from intended delegations.

Consequently, many more individuals than intended, unbeknownst to themselves or IT personnel, end up with excessive delegated administrative access entitlements in Active Directory, and it is these excessive delegated entitlements that can be easily exploited by anyone who can accurately identify them. Password reset entitlements happen to be the easiest to exploit.

The ability to begin the password reset analysis process on a high-value target, such as a Domain Admin account, and iterate it down until an easily compromisable low-value target can be identified, helps identify the easiest possible privilege escalation path from a low-value to a high-value target, which can then be exploited within a matter of minutes, without requiring that the targets to have logged on to a machine one owns.

Even though this risk provides a far easier way to compromise security, most malicious perpetrators still resort to sophisticated attack methodologies like Pass-the-Hash, because they're neither aware of this risk, nor have the means to quickly or accurately identify these excessive delegated access grants and thus perform accurate password accurate reset analysis, yet.

Without sufficient tooling, it is very difficult and time consuming to perform such analysis. However, as demonstrated above, with the right tools, such analysis can now be done within seconds.

In addition, because the analysis phase is read-only, even if using basic tools, an attacker could take his/her own sweet time to perform the analysis, because read-access is almost never audited. (Audit logs would start rolling over within minutes if organizations started auditing read access.)

Also, because so much read access takes place every day in the Active Directory, no solution, such as a firewall built to monitor Active Directory traffic and identify suspect situations could potentially identify this as suspicious activity.

Finally, once the analysis is over, and a path has been found, enacting the privilege escalation steps by resetting passwords also only takes a matter of seconds, so even if password reset operations are audited, realistically, by the time someone receives a notification, the perpetrator would already have completed the privilege escalation and would possibly be in a position to take aggressive counter-measures, such as deploying a pre-written script that would lock everyone else out, and thus prevent anyone from stopping the perpetrator. (As such, audit log analysis will only indicate that authorized IT personnel were involved in resetting passwords, and thus it would be difficult to determine whether something "fishy" was going on.)

 This risk is real, it exists today, and virtually every Active Directory deployment is vulnerable to it.

Risk Mitigation

Unlike other risks, not only can this risk be precisely assessed, it can also be quickly and reliably mitigated. In order to mitigate this risk, organizations only need the ability to efficiently assess and lock down effective access grants delegated in their Active Directory domains, AND the will to mitigate this risk.

Once organizations can efficiently and accurate identify effective access and the underlying permissions, their IT administrative personnel can use this insight to instantly and methodically start locking-down excessive access, and within a matter of days, measurably and demonstratably lock down access to the point that all existing access is based on verifiable least privilege.

When existing access is provisioned on verifiable least-privilege, 99.9% of privilege escalation paths are automatically eliminated, and once there are no paths left to exploit, with or without tooling, malicious perpetrators will have virtually no opportunity to escalate privilege in such a manner.

By corollary, until all existing access is provisioned based on verifiable least-privilege, there will continue to exist large numbers of privilege escalation paths, any ONE of which could be identified and exploited to cause significant damage.

It is important to note that 3 things are key here - completeness, speed (i.e. efficiency) and accuracy.

By completeness, we mean that it is not sufficient to merely lock down access on a subset of Active Directory content, such as focusing only on Domain Admin accounts etc. Organizations must at a minimum lock down access on all Active Directory administrative accounts and groups, including those of all delegated administrators and groups, and ideally they should lock down access to all content, because using this approach, virtually every IT resource stored in or protected by Active Directory can be compromised.

(For instance, the easiest way to compromise a set of confidential documents stored on a domain-joined server, is to find out which domain security group is being used to grant access to this set of documents, and then modify that domain security group (stored in Active Directory) to gain access to these documents, by adding one's own account (or another account) to this domain security group.)

Speed is important because with each passing day, the exposure only continues to increase, and the luxury of being able to take months to address is simply one that is not affordable.

Accuracy is key because without accuracy, organizations can end up making incorrect access control decisions, and incorrect access control decision can very quickly exacerbate the situation.

Doing our Bit to Help

From our side, we are doing out bit to help organizations mitigate this security risk.

Our Gold Finger solution makes the domain-wide assessment of effective access grants as easy as touching a button, thereby giving organizations instant, on-demand effective-access insight, accomplishing for them in hours, what could take years to do -

Gold Finger's patented capabilities fully-automate the accurate determination of effective-access in Active Directory deployments -

Gold Finger can consequently help organizations instantly and accurately determine effective delegated access across their entire Active Directory domain(s) within hours, delivering completeness, speed and accuracy, at a button's touch.

Gold Finger also helps identify the underlying permissions so organizations know exactly what to modify to lock down unauthorized excessive access, and most importantly, its patented algorithms deliver accurate results, so organizations can mitigate this serious risk in a timely manner.

There are certainly other choices available as well. These primarily include a handful of basic / amateur Active Directory permission reporters/analyzers that can help organizations try and solve this problem manually. The only disadvantage of all such tools is that they leave you to do the entire effective-permissions and effective delegated access analysis yourself, which unfortunately could take months or even years to do.

Finally, the most important point here is that timely, successful and adequate risk mitigation will require executive support from the highest levels of the organization. IT groups are thus encouraged to educate executive management about this risk, so that they can obtain the support they'll need to mitigate it. (Here's an Executive Summary for Executive Management)

Responsible Disclosure

Strictly speaking, there's nothing to disclose here. This should technically be apparent to those of ordinary skill in the art.

That said, as an organization, as we have indicated previoulsy, we have known about the possibility of this risk for over 8 years now. We informed Microsoft about it way back in 2007. We have also invested over half a decade of innovative research and development to help organizations mitigate this risk, and it is only after a solution had been available for over a year that we shed light on this risk last year.

We also had no particular interest in building Gold Finger Mini. Our focus always has been on Gold Finger so that we could help organizations mitigate this risk, and we only license the Gold Finger to organizations. We do not license it to individuals.

As for Gold Finger Mini, it was primarily built for senior executives who would find it difficult to believe the existence of this risk, and requested proof. So, we built Gold Finger Mini so they could instantly see for themselves, not just how much risk their organizations were exposed to but also verify that such password reset analysis could be performed by non-administrative users as well (i.e. using their own accounts.) Subsequently, based on feedback from numerous organizations, in order to help employees participate in the overall cyber security process, we made Gold Finger Mini available for use by organizational employees in 2012.

Even though Gold Finger Mini has been available since 2012, until today, not once have we demonstrated how easy it is for someone to enact this risk, were they to misuse a Password Reset Analysis Tool. If we did so today, it was only because, as indicated above, it appears that a recent inaccurate claim related to Active Directory security seems to be distracting organizations, and we wanted to help organizations see for themselves just how much easier it is for a malicious insider to potentially cause substantial damage via this risk, than it is with any other risk.

Wrapping it up

As demonstrated above, with the right tools, almost anyone could easily compromise any Active Directory deployment, within minutes, without so much so as owning a machine, let alone using sophisticated techniques like Pass-the-Hash.

Not just 95% of the Fortune 1000 run on Active Directory, but in fact 85% of all organizations worldwide run on Active Directory, and in all likelihood, today, most of them may be exposed to this risk. Sadly, all it takes is one insider, e.g. Edward Snowden.

See it for yourself -

Best wishes,

Friday, June 20, 2014

Active Directory Account Password Security 101 for Regulatory Compliance Auditors - The Difference Between Change Password and Reset Password


I hope this finds you well. Today, I just wanted to take a few minutes to shed light on a matter that impacts virtually every publicly-held organization in the United States, and possibly most organizations across the world.

A few weeks ago, yet another globally prominent multi-$B publicly held U.S organization licensed Gold Finger 007.

Given Gold Finger 007’s numerous capabilities (Active Directory Delegation Audit, Active Directory Effective Permissions Analysis, Active Directory Permissions Analysis, Domain-wide Kerberos Token Size Computation etc.), we always like to learn about what our customers are using Gold Finger for.

So when we asked them what they intended to use Gold Finger for, they informed us that they wish to use it to “audit who can change whose passwords in Active Directory, because their SOX Compliance auditors required them to furnish this information.”

That was a bit surprising. We figured they meant to say “who can reset whose passwords” so we asked them again whether the auditors required them to furnish a report of “who can change whose passwords”, or “who can reset whose passwords.

They confirmed that the auditors wanted to know “who can change whose passwords”.

That to us was a bit worrying.

Here’s why –

The Difference between Change Password and Reset Password

Folks, the difference between “who can change passwords” and “who can reset passwords” is paramount to understand for organizational security, yet it remains largely misunderstood, and thus is worth shedding light on -

Active Directory Password Changes

Every domain user account in Active Directory is protected by a password, and it is the knowledge of this password that allows the account holder to authenticate him/herself, and in effect stake claim to the identity represented by that domain user account.

When a user’s account is initially set up, he/she is provided with a temporary password (ideally via secure means), and then asked to immediately change that password to a new value, i.e. one that only he/she has knowledge of.

Only the account’s holder is supposed to know the account’s password. No one else is supposed to know his/her password, because anyone who knows the account’s password can authenticate to the system as that user by using that password.

Now, for security reasons, most organizations require users to change their passwords on a periodic basis, so as to protect passwords from password guessing attacks, and as such the system provides a facility to let users change their passwords.

A user can change his/her password by invoking the Security Authentication Sequence (“Alt-Ctrl-Del”), then selecting the “Change Password” option. The user is then required to enter BOTH the new password AND the current password.

(Note: The Windows Change Password dialog refers to the current password as the old password.)

If the current password entered is valid, the system accepts the password change request, and proceeds to change the user’s password to the new value. If the current password entered is not valid, the system denies the password change request.

Now, it is very important to NOTE that in order to change the password, the user is REQUIRED to enter the current password i.e. WITHOUT demonstrating knowledge of the current password, he/she CANNOT change the password.

In other words, if one assumes that ONLY the user knows the password to his/her account, then one can infer that NO ONE ELSE can change the user’s password, because NO ONE ELSE knows the user’s current password.

In summary, there is NO need to audit who can change whose passwords because (in 99.9999% of cases), ONLY the user account holder knows the current password of the account, and without knowing the current user’s password, no one can change the user’s password.

Consequently, in my humble opinion, regulatory compliance auditors should not be asking organizations to audit “who can change whose passwords” only because there is no material benefit in doing so.

Active Directory Password Resets

NOW, in case you find yourself asking – “But wait, what about the situation wherein a user forgets his/her password, then calls Help Desk for assistance, as a result of which a Help Desk Operator resets the user’s password, and grants the user a temporary password with which he/she can then login, and immediately after logging in, change his/her password to a value only known to the user.”

The answer is that, the Help Desk Operator, did NOT CHANGE the user’s password, but in fact RESET the user’s password to a new temporary password, then provided this temporary password to the user (hopefully via a secure channel) AND (hopefully) instructed him/her to immediately change his/her password to a value only known to the user.

You see, in order to account for situations wherein a user forgets his/her password, and is thus unable to login, the system provides a facility by which authorized administrative personnel can reset the password of a user’s account.

This password reset facility can also be used to take control of a domain user account in situations wherein IT needs to take over the user's account, such as those involving employee termination, security incidents etc.

It may be noted that resetting a user’s password does NOT require demonstrating knowledge of the user’s existing/current password. Instead, it only requires that the individuals performing the password reset have the “User Force Change Password” extended right granted on the domain user account. Anyone who has this right granted on a domain user account can instantly reset the domain user account’s password.

(Strictly speaking, in order to change a user’s password, the user too requires the “User Change Password” extended right on his/her own account, which by default is granted to “Everyone” and “Everyone” implicitly includes the user him/herself. By the way, just because the right is granted to “Everyone” does not mean that everyone (/anyone) can change the user’s password; only those individuals who can demonstrate knowledge of the current password can change the user’s account’s password.)

(BTW, the Rights GUID for User-Force-Change-Password is 00299570-246d-11d0-a768-00aa006e0529 and the Rights GUID for User-Change-Password is ab721a53-1e2f-11d0-9819-00aa0040529b.)

Now, by default many Active Directory administrative groups, including Domain Admins, Enterprise Admins, Built-in Admins, Account Operators and other are granted the “User Force Change Password” (also known as “Reset Password”) extended right on all domain user accounts, and thus many administrative personnel are by default, already have the ability to reset the passwords of most domain user accounts. In addition, many organizations develop and implement custom delegation models resulting in an even larger number of individuals being able to reset the passwords of most of their domain user accounts.

It is imperative to understand that ANYONE who has the “User Force Change Password” (i.e. “Reset Password”) extended right effectively granted on a domain user account can instantly reset that account’s password and login as him/her.

Of course, once someone can reset a domain user account’s password, he/she can instantly login as him/her, obtain access to everything that user has access to, read and send email, access, tamper, copy or divulge everything that user has access to.

As a result, it is paramount to know AT ALL TIMES, exactly who can reset whose passwords in Active Directory.

Consequently, instead of asking organizations to audit “who can change whose passwords” regulatory compliance auditors should be asking them to audit “who can reset whose passwords”, since the ability to reset someone’s password instantly lets the perpetrator logon as the target user, and access everything the user has access to.

It is also possible for a malicious individual to reset a user’s password, then logon as the user, engage in unauthorized access, then logoff, and when the actual user account attempts to login the next time around, after a few unsuccessful attempts to logon using the old password, the user would unsuspectingly call Help Desk, and in most cases, a Help Desk operator will simply reset the password again, without suspecting that someone may have reset the user’s password and logged on.

You can imagine the consequences of someone being able to reset the password of an administrative account or an executive account – depending on the (mal-)intent and expertise of the perpetrator, the consequences could potentially be disastrous.

So, if I may, I’d like to humbly request compliance auditors to understand this vital difference, and perhaps the next time around, ask for a report of “who can reset user account passwords”, not “who can change user account passwords”.

Finally, when requesting this information, it is imperative to ensure that the audit report being furnished is based NOT on simply permissions analysis, but on effective permissions analysis, because only effective permissions reveal who can truly reset whose passwords.

This Impacts 85% of Organizations Worldwide

As you may know, today Active Directory is the bedrock of cyber security at over 85% of organizations worldwide.

Our global intelligence indicates that in most of these organizations, no one has any idea as to exactly who can reset whose passwords, even those of high-value targets i.e. Executive and Administrative Accounts.

This is unfortunately a highly concerning and alarming situation.

For instance, a while back, an employee of a multi-$B international company requested a trial of, and ran Gold Finger Mini in their environment here in the United States. In about 2 minutes, he was able to find out that over 700 individuals in the world had sufficient effective rights to be able to reset the password of that organization’s CEO’s domain user account. What was shocking to us is that neither the CEO, nor most of these 700+ individuals knew that that they had sufficient rights to be able to reset the CEO's password.

Incidentally, this organization had outsourced the management of their Active Directory deployment to another multi-$B international company, and imagine my surprise when we learnt that there were some very prominent individuals on that 700+ user list, some of whom I know personally (; most are in Europe and others in Asia.)

For security reasons, both these companies shall remain nameless. (You know who you are.)

Wrapping it Up

A few weeks ago we informed our customer about this subtle yet important difference, and I am pleased to let you know that today they are performing an audit of "who can reset whose passwords" instead.

In summary, it is very important to know (at all times) exactly who can reset whose passwords. At a minimum, all organizations should know at least who can reset the passwords of all their Administrative/Privileged Accounts and their Executive Accounts (CEO, CIO, CFO and CISO) because it is the ability to reset passwords that is at the heart of the world's top cyber security risk today.

Well, my 10 minutes are up. (More next time.)

Best wishes,