Microsoft, Have 1000s of Major Organizations Been Furnishing Inaccurate Evidence to Demonstrate Compliance of Access Rights in Active Directory?

Dear Microsoft,

(This is my last post of being a tad tough on you. From the next post onwards, I'm going to be helping you out tremendously, because I am on your side.  As for this last tough post, I hope you've got the point I have been trying to make all this while.)


Today is Day-20 of our Active Directory Security School for you. Thus far, I've asked you a few basic/elemental questions (e.g. this one, this one, this one, this one, this one or this one) concerning Active Directory Security, and I don't think you may have an answer for even one of them, perhaps as they may seem to be difficult, so today I'll ask you a simple question.



Regulatory Compliance 101 and Active Directory

As you may know, for many years now, thousands of organizations across the world, such as all publicly-traded organizations in the United States, the European Union and in other legal jurisdictions, have, for various reasons, been required to and continue to be required to demonstrate regulatory compliance of access rights in Active Directory.

The reason for this very simply is that many critical organizational IT assets that fall under the purview of these regulations, such as the domain user accounts of key executives (e.g. C*Os), are all stored, protected and managed in Active Directory.


So, for illustrative purposes, let's take a closer look at just ONE such requirement, and ask ourselves whether 1000s of such organizations may have been furnishing inaccurate evidence to demonstrate compliance of access rights in Active Directory?

Specifically, let's consider just one specific ask, which is to determine and furnish evidence to demonstrate exactly -

Who can reset the password of an organization's Chief Executive Officer's (CEO's) and Chief Financial Officer's (CFO's) domain user accounts?

I hope I don't have to explain why something as basic as this would fall under the purview of most regulatory compliance asks.

(If someone could reset the password of the CEO or the CFO of an organization, he/she could instantly gain access to highly sensitive and confidential information, the knowledge (and the unauthorized use or unauthorized disclosure) of which could be used to substantially impact the organization's stock-price, and thus its valuation, and this could adversely impact shareholders.)




Who can Reset the CEOs Password?

Let's consider what it takes to find out who can reset the password of the CEO's domain (i.e. Active Directory) user account.

As I have indicated numerous times by now (1, 2, 3), to make this paramount determination, what organizational IT personnel need to do is find out exactly who has Reset-Password extended right effective permissions on the CEO's domain user account -

The keyword here is effective permissions i.e. and to be most specific, I mean Active Directory Effective Permissions.

It is impossible to accurately make this determination without being able to accurately determine effective permissions on the CEO's domain user account in Active Directory, and consequently, it is impossible to furnish accurate evidence in this regard to demonstrate regulatory compliance without having the ability to accurately determine effective permissions in Active Directory.

Now, let alone having the ability to accurately determine effective permissions in Active Directory, at most organizations, IT personnel don't even seem to know that in order to make this paramount determination, they need to determine effective permissions in Active Directory! In fact, all along, at most organizations, IT personnel have merely been finding out "who has what permissions in Active Directory" as opposed to finding out "who has what effective permissions in Active Directory."

Thus it logically follows that most organizations worldwide have not even been making this determination correctly, and thus it can be stated with a reasonably high degree of confidence that 1000s of organizations worldwide may have been, for years now, furnishing inaccurate evidence to demonstrate the regulatory compliance of access rights in Active Directory!

I do not know what the specific penalties for furnishing inaccurate regulatory compliance evidence might be, but the CFOs of these organizations (including yours) will likely know, as they are required to personally sign-off on all such furnished evidence.

Microsoft, if only you would've educated the world years ago about "Active Directory Effective Permissions" and their paramount role in literally everything related to cyber security in Windows environments, including of course regulatory compliance, you could've saved the world a lot of trouble. Thankfully, today these C*Os can now themselves audit who can reset their password!

Speaking of which, not just to demonstrate regulatory compliance but to maintain cyber security, ideally, all organizations must, at all times, know exactly who can reset the passwords of all domain user accounts in their Active Directory, and now they can.




Speaking of Auditors

By the way, I should mention that we've had so many organizations request our assistance in this regard, and when asked as to the reason, we've been told that their "regulatory compliance auditors asked to furnish a list of everyone who can CHANGE the CEO's & CFO's password!" We thought we may have heard incorrectly, so we asked twice, and the answer again was that their "regulatory compliance auditors asked to furnish a list of everyone who can CHANGE the CEO's & CFO's password!"

CHANGE Password or RESET Password ?!

Do these auditors NOT know that it is not who can CHANGE a user's password that matters but in fact it is who can RESET a user's password that matters, BECAUSE by nature, in order to CHANGE a user's password, you need to (i.e. are required to) demonstrate knowledge of the EXISTING password, which is something ONLY the CEO him/herself should know about.

You see, in contrast to a password change, a password RESET operation does NOT require one to demonstrate knowledge of the EXISTING password, but in fact only requires that you have sufficient effective permissions to be able to reset the user's password, which is governed by the Reset Password extended right on the individual's domain user account!

So, if any there are any auditors out there still asking for "Who can change the CEO's password?" they'll want to read this.

Like so many other things, I cannot stress this enough. The subtle yet profound difference between a Password Change and Password Reset is possibly one of the most misunderstood yet important areas of organizational cyber security today!





Just One More Thing - SmartCards!

Organizations that use Smartcards for user authentication may perceive this as not being too applicable to them considering that they may be operating under a heightened (but false) sense of security, given that they're using Smartcards (or some other means) for two-factor authentication for their domain user accounts, including thus for their executive domain user accounts.

Well, all such organizations should know that smartcard authentication on a domain user account can be turned off at the flip of a single bit on the domain user account, and the moment it is turned off, authentication on that account automatically falls back to being password based, with a random password being applied to the domain user account!

To all such organizations, I'd humbly recommend trying to find out exactly who can disable the use of smart-cards on all their domain user accounts. Oh and by the way, in order to make that determination, they'll need to determine effective permissions on each one of their domain user accounts. Yes, I'm aware that this determination is not at all easy to make and it could take weeks, if not months, but this is after all extremely important to organizational security, isn't it. (What if it took just minutes ?!)





Tip of the Iceberg

Demonstrating compliance of "Who can Reset the Password of the C*O's Domain User Accounts" is just the Tip of the Iceberg!

In reality, there is so much more that most publicly held organizations in most legal jurisdictions worldwide need to assess and demonstrate the regulatory compliance of, that requires the determination of effective permissions/access in Active Directory.

Unfortunately, because so many organizations worldwide may still not know about the subtle but profound difference between  "Who has what permissions in Active Directory"  and  "Who has what effective permissions in Active Directory", they very likely may have been furnishing inaccurate evidence all these years!




In Summary

Microsoft, given what it is we uniquely do, my time is extremely valuable, and over the past few weeks, I've invested a lot of my valuable time towards helping you understand why it is so very important for you to help thousands of organizations understand the paramount importance of being able to determine effective permissions (/ effective access) in Active Directory.

It is paramount to the foundational cyber security of your customers, and I'd still like to believe that you're not just all talk.

Today's post was meant to demonstrate that Active Directory Effective Permissions impact not just the foundational cyber security of organizations worldwide, but in fact also impact all related areas, such as demonstrating regulatory compliance.

In all seriousness, Microsoft, perhaps likely thanks to you, thousands of prominent organizations worldwide may very well have been furnishing inaccurate evidence to demonstrate compliance of access rights in Active Directory, and doing so for years!

Alright, that's all for today.

Best,
Sanjay


This post marks the end of my being tough on Microsoft. Next post onwards, I'm going to be helping them out tremendously.

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

Folks,

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,
Sanjay

5 Facts You Must Know about Active Directory Privilege Escalation

Folks,

Last month, we declassified the #1 cyber security risk to Active Directory deployments - Active Directory Privilege Escalation.

Active Directory Privilege Escalation based on identification and exploitation of unauthorized access grants in Active Directory deployments.

Today, I wanted to share with you 5 things that we all must know about Active Directory Privilege Escalation –

#5 – Domain Admin accounts only account for 1% of the attack-surface. Accounts of delegated admins, executive and regular employees, and all other Active Directory content (i.e. all group memberships, GPOs, OUs etc. ) accounts for 99% of the attack surface

#4 – We may not know it or realize it yet, but most Active Directory deployments worldwide are currently exposed to this risk today. In fact, most domain user and computer accounts, domain security groups, GPOs, OUs, SCPs etc are potentially at risk of compromise.

#3 – This risk is far more damaging and easier to carry out than even the risk posed by the Pass-the-Hash (PtH) attack vector, because unlike Domain Admins, the likelihood of a non-admin user logging on to the attacker’s machine is quite low. (Consider this - what is the likelihood that your organization's CEO will logon to your machine, whether for legitimate reasons, or even if social engineered into doing so?)

#2 – This risk exists because Active Directory lacks the ability to help IT personnel precisely assess and verify provisioned access. Active Directory does let us precisely provision access, but it is unable to help us precisely assess/verify/audit effective provisioned access.

#1 – The presence of an Auditing solution does nothing whatsoever to mitigate this risk. It merely helps detect its occurrence. By the time an associated event shows up in the audit log, it is already too late, because the damage has been done. (E.g. - if a malicious entity has been able to reset a Domain Admin's password, or the CEO's password, even though the event may show up in the audit log, by the time you react to it, the damage is already done.)

In days to come, I will share with you how organizations can assess whether they're at risk, and how they can mitigate this risk.

For now, perhaps its worth asking yourself a simple question – “Do we know exactly who can do what in our Active Directory, especially in light of the fact that anyone with a domain user account can find this out on any object within minutes?”

Best wishes,
Sanjay

PS: This is a very simple and fundamental problem that stems from the lack of verifiable implemented least privilege access (LPA) in a major foundational technology. Frankly, I’m really surprised that over 80% of organizations worldwide still do not realize this simple fact! The only thing more concerning is that based on our intelligence, the Chinese have most likely already figured this out.

How an Insider Could Easily Compromise the CFO's Account - An Example of Active Directory Privilege Escalation Based on Access Grant Exploitation

Folks,

Today, I will share with you a concrete example of how any insider could potentially compromise the user account of the Chief Financial Officer (CFO) of an organization by exploiting weaknesses in access grants provisioned in Active Directory, which is the basis of the Active Directory Privilege Escalation security risk that I declassified one week ago.

Chief Financial Officer

This specific example is a very realistic illustration of this risk, that today could be carried out in most organizations worldwide.


SUMMARY -

• Target: The CFO's domain user account which resides in the Finance OU in the Active Directory
• Attacker: John Doe, a temporary contractor working on some project, who has a domain user account

• Attack Methodology -
• Step 1 - Obtain a tool that can aid in performing Active Directory Security Analysis.
• Step 2 - Use this tool to a) locate the CFO's domain user account in Active Directory, and then b) analyze access provisioned in the ACL of the CFO's domain user account to identify the list of all individuals who can reset the CFO's password.
• Step 3 - Use the same tool to analyze security permissions on the user accounts of each of these individuals to identify who can reset their passwords. Iterate this process on this list of accounts, and continue iterating until the single weakest link i.e. an account that can be easily compromised by  the attacker, has been found.
• Step 4 - Begin by compromising the account identified as the weakest link. Then, login using that account and reset the password of the next account in the chain. Repeat this process until you have reset the password of a delegated admin who can reset the CFO's user account.
• Step 5 - Login using the final compromised delegated admin's account, and reset the CFO's password.
• Time Requirement - The exploitation process is very quick, since a password reset operation only takes 5 seconds, and a subsequent logon about 30 seconds. The only part that takes some time is the process of determining who can actually reset a target account's password.

• Compromising the Initial Account - The initial account can be compromised by any one of various means, an encyclopedia of which is known to most malicious individuals. Examples of such means include Password Guessing, Password Stealing (Keystroke Logger), Phishing, Hash Replays (Pass-the-Hash) etc.

DETAILS -


Step 1 - Obtain a tool that can aid in performing Active Directory Security Analysis

Since John already has a domain user account, he already has complete read access to Active Directory content. All he needs is an Active Directory Security Analysis tool to view Active Directory content, analyze Active Directory permissions and enumerate group memberships i.e. aid in the process of determining effective access in Active Directory.

The Advanced Security Settings Tab of the Active Directory Users and Computers Tool

There are many freely available tools that can aid the attacker in performing Active Directory Security Analysis, such as Microsoft Active Directory Users and Computers Snap-In, Administrative Center, dsacls, acldiag, LDP, LIZA etc.


Step 2a - Use this tool to locate the CFO's domain user account in Active Directory

Once John has installed a tool of his choice, he can launch it to view the contents of the Active Directory. Using the tool's inbuilt search abilities, he should easily be able to locate the CFO's account -

Locating the CFO's User Account in Active Directory

 

 

CFO's User Account in Active Directory

Once John has located the CFO's domain user account, he can access the ACL protecting the account. Since authenticated users have default read access in Active Directory, no special access is needed to access and examine AD ACLs.


Step 2b - Use this tool to analyze access provisioned in the ACL of the CFO's domain user account to identify the list of all individuals who can reset the CFO's password.

The next step is to analyze the object's ACL to identify the list of all individuals who can reset the CFO's password. The following is the access control list (ACL) protecting the CFO's domain user account -

Analyzing Security Permissions Specified in the ACL of the CFO's User Account

In order to determine who can reset the CFO's password, John will need to determine who effectively has Reset Password rights granted on the CEO's user account.

To do so, he will need to engage in the process of determining who has what effective access in Active Directory. Kindly note that this process is NOT the same as the one involved in determining who has what permissions in Active Directory.

In essence, all John needs to do is determine who effectively has Reset Password rights allowed on the CFO's user account. Anyone who is effectively allowed the Reset Password extended right, or All Extended Rights, or Full Control over the object will make the list. This is because All Extended Rights includes the Reset Password right, and because Full Control includes All Extended Rights.

As you can see above, there are many security permissions specified in the ACL, each one specified in an individual access control entry (ACE). Some ACEs grant permissions whereas others deny permissions. Some are explicitly specified on the object, whereas others are inherited. Some inherited ones apply to the object (CIID), whereas others merely exist to be inherited down to other objects (CIIO).

In order to determine effective access on the CFO's object, John will need to perform a process similar to the following -

1. Identify all relevant ACEs i.e. all ACEs that allow/deny Reset Password, or All Extended Rights or Full Control.

2. Then flatten all group memberships for which access is specified in all relevant ACEs, generating lists that enumerating the list of all individuals who are allowed access, as well as enumerating the list of all individuals who are denied access. (Ensure that any and all nested group memberships are completely flattened as well.)

3. Then, intersect these lists taking into account all pertinent factors, such as inheritance rules, ACE applicability, conflict resolution etc. to ultimately arrive at a list of all individuals who can reset the CFO's password.

Upon completion of these steps, John would have the list of all individuals who can effectively reset the CFO's password.


List of individuals who can reset the CFO's password

It is worth noting that even if John did not know how to do engage in this process with 100% precision, even with 80% precision, he could determine 80% of the individuals who could reset the CFO's password.


Step 3 - Analyze security permissions on the accounts of these individuals to identify who can reset their passwords.

If John is already a delegated admin, and his account is already on that list, he may not need to analyze effective access on any more accounts. However, if his account is not on that list, then he could continue the process to find a weakest link, which is described below.

Once John has put together the list of all the individuals who can reset the CFO's password, he would then proceed to determine who can reset the passwords of these individuals. This would give him a broader attack base, and one that would also usually constitute a set of weaker targets to compromise.

He could then iterate this process on this new list of accounts, and continue iterating until the single weakest link i.e. an account that can be easily compromised by the attacker, has been found.

Any ONE of a large number of IT admins may be the starting point for privilege escalation i.e. the weakest link

For instance, he might find that a total of 12 individuals can reset the CFO's password, but that a total of 36 individuals can reset the passwords of these 12 individuals. He could iterate further to find potentially 50 or so individuals who could in turn reset the passwords of these 36 individuals.

He only needs to iterate the process until he can find at least one account that is easily or readily compromisable i.e. until he has found the weakest link. For instance, he could stop identifying accounts as soon as he finds the account of a single local IT admin whose account he could compromise using various known means.

By engaging in this process, he would have in effect identified a privilege escalation path, which would start from an easily compromsable account and lead all the way up to the CFO's user account.


Step 4 - Escalate Privilege by Performing Password Resets

Once John has identified a privilege escalation chain, all he needs to do is act upon it at a day and time of his choosing and to his advantage. He would begin by compromising the first account using any one of several known means to do so.

Once he has compromised the first account, the rest of escalation is simply a matter of logging in using the compromised account, then resetting the next target's password, then logging off, and logging on using the next compromised account, and so on, and by the end of it, he would have effectively escalated his privilege to that of the CFO of the company

Final Privilege Escalation Step - Resetting the CFO's account's password

In most cases, John would only have to repeat these steps 2 to 4 times (i.e his privilege escalation depth would be 2-4.)


Step 5 - Login as the CFO

Once John has reset the CFO's account's password to one of his choice (e.g. Th@WasEasy!), he can instantly login as the CFO i.e. using the CFO's account -

Once logged in as the CFO, he would have whatever read and modify access the CFO's account may have been provisioned across the IT infrastructure. Since in most organizations, single-sign-on is in use, he could almost instantly access, copy, change or delete any information that the CFO's account might have access to.

(Imagine the financial and legal ramifications of John being able to access the organization's quarterly earnings numbers just 10 minutes before the official scheduled earnings release, using the CFO's account, and then leaking them on the Internet.)


Some Observations about Active Directory Privilege Escalation Based on Exploitation of Unauthorized Access Grants

As seen above, the process of identifying and exploiting unauthorized access grants in Active Directory is rather simple. Here are some noteworthy observations -

• Easier than the Pass-The-Hash (PtH) Attack Vector - This attack vector is much easier than the PtH attack vector because of the following reasons -
• Opportunity - The PtH attack vector may be easy to carry out against Domain Admins because the likelihood of having a Domain Admin logon to a machine the attacker controls is high. However, the likelihood of a specific non-administrative high-value account such as that of the CFO, CEO, CIO, CISO, IT Director, a Vice President, a manager etc. logging on to a machine controlled by the attacker is rather low. (Most folks usually logon to their own dedicated machines.) Thus, the likelihood of compromising a non-administrative account with PtH is low, whereas with this attack vector it is high.
• Lower Bar - In most organizations, there is already sufficient awareness about the PtH attack vector, and administrators are careful as to not to logon to machines they do not trust. However, most organizations still have no idea as to exactly who can reset whose passwords, so there are ample opportunities to escalate privilege by resetting passwords and thus the bar is much lower
• No Specialized Tooling Required - Unlike the PtH attck vector, this attack vector does not require any specialized tooling. It only requires some security analysis and the enactment of basic tasks, which can easily be carried out using Microsoft's native tools.
• Higher Probability - If a potential target never logs on to the attacker's host, the attacker will NEVER be able to use PtH to escalate privilege. However, with password resets, not only does the potential target not need to logon to the attacker's machine, the probability of finding at least one unauthorized individual who can reset the target user's account is substantially higher.

• A Vast Attack Surface - It is not just domain user accounts that are vulnerable. All Active Directory content, including security groups (and their memberships), computer accounts, GPOs, entire organizational units (OUs), service connection points (SCPs) etc. can all be compromised by simply determining who can manage them and then using this approach to take over the account of a delegated administrator who can manage that object.

• AdminSDHolder Protection does not mitigate this risk - Contrary to popular belief,  AdminSDHolder does not mitigate this risk for two reasons -
• Non-administrative accounts - AdminSDHolder only serves to ensure that a standard set of permissions in applied to all administrative accounts and groups. It does not provide any protection for non-administrative accounts and groups. So for example, executive (C*O) accounts, VP accounts, director and manager accounts are not protected by it, neither are regular employee and contractor accounts.
• Administrative accounts - Even for administrative accounts, it only serves to ensure that a single standardized set of permissions are applied to all accounts. It does NOT protect the groups to whom access is specified in the ACL of the AdminSDHolder object itself, or the users that belong to these groups. Thus, this attack vector can also be used against all administrative accounts and groups.

• Security Analysis is not Audited - The act of performing security analysis only involves read access to Active Directory. Read access to Active Directory is almost never audited because of the sheer volume of read access that takes place everyday in the course of normal business/IT operations. As a result, it is virtually impossible for IT personnel to know whether or not, and if so, when, someone might be performing such security analysis in their environments. This aspect gives attackers the luxury of time. They could take anywhere from hours to weeks to identify weaknesses, then act at a day and time of their choosing to exploit their findings.

• This Risk is 100% Mitigatable - This risk is 100% mitigatable. In other words, organizations can easily take steps to mitigate it, such that even if every user in the environment were to scour all their Active Directory ACLs, all they would find are tightly locked access grants i.e. least privilege access (LPA) implemented in their Active Directory. In order to mitigate this risk and attain an LPA state in their Active Directory, all that organizational IT personnel need to do is identify and eliminate unauthorized access grants in their Active Directory. This can easily be done by using any advanced Active Directory Security Analysis Tool that is capable of determining True Active Directory Effective Permissions (i.e. true/accurate effective permissions on Active Directory objects). Organizations that have abundant IT resources and expertise could also choose to develop and test their own Active Directory effective access assessment capabilities in-house.

Real-World Proof

For most IT personnel familiar with Active Directory, the example presented above should be sufficient to illustrate the risk.

For those who must have real-world proof, you can use this tool (its free), to see for yourself, in under 2 minutes, exactly how many individuals can reset your own password, as well as the password of any of your colleagues, including that of your organization's CFO.

Need one say more?

Best wishes,
Sanjay