Praise for Sean Metcalf of ADSecurity.Org + Active Directory Security 101 for the World and the Black Hat Conference 2016

Folks,

Today, as former Microsoft Program Manager for Active Directory Security, I'd like to take a few minutes to publicly recognize and praise the efforts that Mr. Sean Metcalf has put in over the last few years to help raise awareness about the importance of (and weaknesses in) Active Directory Security.

[Quick process note - you'll want to read this blog post in its entirety.]

For those of you who may not know Sean Metcalf, he runs the ADSecurity.org website, and is a Microsoft Certified Master (MCM) in Directory Services. He has also spoken at numerous conferences such as Black Hat, Def Con, DerbyCon etc.

Sean Metcalf presenting at Black Hat 2015

Today, as a valued consultant, he helps many organizations assess the security of their Active Directory deployments.

I do not know him personally, nor have I ever met him, but I've heard of his efforts, and I appreciate them and wish him well.




Praise for his Efforts

Folks, I believe Sean's journey into Active Directory Security began in 2011, i.e. almost 5 years ago, when he was inspired by an email from his friend. In March of 2011, he committed to his friend that he would pass all the tests required to be an MCITP:EA in 2 months! Keep in mind that around that time he was also the proud father of 1-year old triplets, so you can imagine how determined he must have been to succeed.

Fast forwarding to February 2012, on Super Bowl Sunday, he attended the elite Microsoft Certified Master (MCM) Directory Services Program in Building 40 at Microsoft headquarters in Redmond, WA. (I have fond memories of Building 40 as I spent 4 years of my own life in it (2001-2005.))

At 9:00 pm on February 21st, he received an email which read - “Congratulations! You have earned the Microsoft Certified Master | Windows Server 2008 R2 Directory certification!”

During his journey thus far, he has put a lot of effort and acquired a wealth of knowledge, starting from the very basics.

Speaking of basics, for instance, he once learnt the optimal way to find users in Active Directory, and another time he learnt how to Active Directory recon without requiring admin rights. (Of course, since Authenticated Users have blanket read access in Active Directory, performing AD recon requires no admin rights whatsoever. Zilch. Its easy-peasy, and today anyone can do substantial basic AD recon with this free tool at a button's touch.) Over the years, he continued on to gain advanced knowledge.

Over the last few years, Sean has put in a considerable amount of effort on researching numerous aspects of Windows and Active Directory Security and sharing his research online via 70+ posts at his blog.

In doing so, he has helped many organizations gain a deeper understanding of various aspects of Active Directory/Windows Security, predominantly vulnerabilities involving Microsoft's implementation of Kerberos and related attack vectors such as Pass-the-Hash, Pass-the-Ticket, Kerberos Golden Tickets, as well as related tooling (e.g. Mimikatz) etc.

Great work, Sean!  The world could use more people like you, so thank you again for all your efforts.





First Things First

Sean had recently posted a blog entry on Attack Methods for Gaining Domain Admin Rights in Active Directory, and in it he lists a few attack vectors -

1. Passwords in SYSVOL & Group Policy Preferences
2. Exploit the MS14-068 Kerberos Vulnerability on a Domain Controller Missing the Patch 
3. Kerberos TGS Service Ticket Offline Cracking (Kerberoast)
4. The Credential Theft Shuffle 
5. Pass the hash evolves into Pass-the-Credential 
6. Gain Access to the Active Directory Database File (ntds.dit)

Sean has done a good job in providing adequate details and mitigations for each of them. In days to come, time-permitting, I'll shed some more light on them. For now, the salient part of that blog post, which is in the first paragraph is worth noting:

"The techniques described here “assume breach” where an attacker already has a foothold on an internal system and has gained domain user credentials."

(Hmm. If one were to assume breach, and knew how to do this, or had this or this, the Kingdom would be 0wned in minutes.)

In contrast, each of the attack vectors listed above seem like they take way too much effort to compromise an Active Directory, in comparison to the most potent, effective and powerful Active Directory attack vector which unfortunately is not on that list yet i.e. this one. In days to come, I'll share more details on it, in a blog post titled - Breach to Owned in 5 Minutes.

By the way, when I say 0wned, I mean its Game Over. The attacker will have attained complete control over the entire Active Directory forest, and there's nothing anyone will be able to do to stop him. Period.





Active Directory Security 101 for the World, and for the Black Hat Conference 

Since Sean will be presenting at Black Hat in a few days, I think Sean will likely agree that during his journey, he too must have realized that Windows Security and Active Directory security are vast subjects and there's an ocean of knowledge to be gained.

I say so from my own personal experience, because as former Microsoft Program Manager for Active Directory Security, here are just a few areas of Windows Security I had to master back in 2001 -

Distributed Security, AuthN, Authz, Auditing, Winlogon, Kerberos, NTLM, Digest, SSPI, SPNEGO, Mutual Auth, Logon Sessions, Windows Stations, Profiles, LUIDs, Access Tokens, SDs, ACLS, ACEs, Privileges, Rights, SMB, Lan Manager, NULL Sessions, Names Pipes, COM, SSL, TLS, SChannel, SAM Server, Federation, DCs, DS Repl, Trusts, SID Filtering, LDAP, DPAPI, SAML, Effective Permissions, PKI, Name Mappings, GCs, DNTs, DC Locator, ESENT, ADAM, ADFS, WinLogon, SID History, TDOs, TLNExclusions, ANR, Cross Refs, msDsQuotas, DFS, FRS, LVR, Credman, PAC, Windows Integrated Auth, DBDump, userAccountControl, Constructed Attributes, PDC Chaining, SAML, ADAM, RODCs, FGPP, Certificate Services,  Token Bloat, Password Resets, Active Directory Privilege Escalation and about 100 other topics that come to mind.

Now, during the last few years, thanks mostly to a little bit of creative systems programming efforts of a certain Mr. Benjamin Delpy, what was until then deemed theoretical came to life, creating a menace for Microsoft's ecosystem and endangering the security of thousands of organizations, and ultimately leading to Microsoft putting in a lot of effort to introduce many new security features, acquiring a company or two, and releasing guidance on how organizations could protect themselves from credential theft and reuse attacks. Impactful work on Mr. Delpy's part though, as it helped enhance Windows security.

(On a lighter note, interestingly, given how corporations work, Mr. Nadella and company might even use this to tout Windows' 10 new security features and continue their aggressive push to get the world on Windows 10, whether or not people want it ;-))


(Also interestingly, it appears that the largest financial beneficiary from Mimikatz may possibly have been a little Israeli start-up named Aorato, given its recent acquisition by Microsoft, albeit for petty change. Recently, interesting to see the former VP of Research at Aorato exchange notes with Mr. Delpy on Twitter quite a few times. Hmm ;-) By the way, on a lighter note, not too long ago, a few years ago, one day, someone at Aorato sat thinking for two hours (as to) how to build an attack path, and then realized that everyone has access to Active Directory! Hilarious!! - that video's here (2:10 onwards.) But I digress.)



Anyway, in all of this hoopla, a few CARDINAL points, including the world's #1 attack vector, seem do have gotten drowned -

1. Mimikatz requires local admin credentials to run on a Windows machine. To the uninformed, Mimikatz might sound like wow, but to the informed, it is merely an artifact of the a simple security truism - "You cannot prevent the administrator of a machine from controlling its Trusted Computing Base (TCB)." Conceptually, all Mimikatz does is inject code into LSASS and utilize the Crypto API to do a few things that can lead to credential harvesting, replay and misuse.  I'm not belittling it; I'm just saying its just a system-level routine running as admin injecting code into LSASS and exploiting a few features in Windows designed to make network authentication a little more seamless.

2. Kerberos Golden Tickets require the NTLM password hash of the domain's KRBTGT account, which can only* be obtained by logging on to a Domain Controller as Admin. In other words, in order to acquire a Kerberos Golden Ticket, you at a minimum* need to have logged on as Admin on a Domain Controller. Any kid in Kindergarten will tell you that if you can logon to a Domain Controller as Admin, you already OWN the entire Active Directory forest! So, you don't need to work so hard (i.e. dump LSASS etc.) after that to get anywhere! Simply spawn a process as SYSTEM and you can play GOD in seconds! So again, what's the big deal here?

* Last year, a DCSync feature was added to Mimikatz, allowing it to be able to request and obtain from Active Directory, all data including account password data from a targeted Domain Controller. Again, to the uninitiated, this might sound like Wow, but to some of us, this is hardly surprising. Here's why. In order for the "DCSync" feature to work, the attacker requires that he/she effectively have the DS-Replication-Get-Changes-All extended right set on the domain root. Er, I wrote Microsoft's Whitepaper titled Best Practices for Delegating Active Directory Administration way back in 2003, and as early as then, we have said very clearly that if you have this right, you can in effect replicate password data out from the Active Directory, and play G0D!

Here's the extend right listed in Appendix D of my delegation whitepaper, published online as early as 2003. Point being that if you have this extended right granted in ACL of the domain root object, you already are for all practical purposes a God-like Admin, so what's the big deal here? 

In short, to the uninitiated, all this hoopla caused by Mimikatz and the like may be wow-worthy, but to some of us, its just an example of someone utilizing some advanced Windows Security programming to convert a theoretical risk into reality.

In all of this hoopla, over the last few years, the world seems to have completely ignored (and thus still remains highly vulnerable to) the biggest risk to Active Directory security - that of Active Directory Privilege Escalation based on the identification and exploitation of unauthorized effective access grants in Active Directory.




Some Dots to Connect

Those who know how to exploit that risk can, given access to a single insider's credential (non-admin domain user/computer account) likely take over and shut down virtually any Active Directory forest, within minutes, from any domain-joined machine,WITHOUT requiring a SINGLE admin to have logged on an 0wned machine, let alone requiring the ability to logon to a DC as admin -

Active Directory Privilege Escalation

By the way, password resets are simply one out of umpteen ways to exploit this system-wide weakness. Group membership changes, group policy link changes, service connection point keyword changes, sensitive ACL modifications, disabling two-factor authentication, etc. etc. all fall under this attack vector. So, its a little more than just password resets.

In fact, 99% of the world doesn't know much about this risk. Those who do know that it poses a substantially greater cyber security danger to the world, than do these basic credential-theft attacks. I'll spare the details for another blog-post, and/or if you are really interested, and you're good at connecting dots, here are some dots for you to connect -

Dot 1 - The Paramount Brief 

Dot 2 - The Attack Surface

Dot 3 - The Attack Vector

Dot 4 - Five Minutes

Dot 5 - An Interesting Picture

Dot 6 - 100% Mitigatable

In short, while we've seen Mr. Metcalf and 1000s of IT personnel worldwide focus on Kerberos related attacks, or simple SYSVOL related attacks etc. etc., we've not seen anyone talk about this huge security hole that's the size of the Pacific Ocean in virtually every Active Directory deployment out there.





Billions of ACLs (The Pacific Ocean)

Folks, today, in thousands of Active Directory deployments across the world, right within these Active Directory deployments, lie billions of access control lists (ACLs) protecting billions of vital Active Directory objects, which represent administrative accounts and groups, employee user accounts, all domain computers accounts, all domain security groups, service connection points, group policies, contacts, and the entirety of Active Directory configuration content (including the Schema, the Configuration partition, the System container, the domain root object etc. etc. etc.) The list goes on and on and on...

... yet, virtually no one in any organization has any idea as to who can truly do what in their foundational Active Directory.

In short, if you're into Active Directory security, you'll want to (literally) get INTO Active Directory, and if when you'll look inside, you'll find an ocean. Domain Admins are just the TIP of the Iceberg in this ocean of Active Directory security permissions.





10 SIMPLE Active Directory Security Related Questions -

To Sean Metcalf and other Active Directory security focused cyber security experts in the world, including those at Microsoft, I would like to most respectfully pose a few very simple, fundamental, elemental Active Directory security questions to consider -

In any production Active Directory forest in the world, does anyone know -

1. Exactly who has the Replication Get Changes All extended right effectively granted in the domain root's ACL?

2. Exactly who can change the security permissions in the ACL on the domain root object?

3. Exactly who can reset the password of all Built-in-Admin, Domain Admin and Enterprise Admin accounts?

4. Exactly who can disable the use of Smartcard authentication on accounts in Active Directory? 

5. Exactly who can change the security permissions in the ACL of the AdminSDHolder object?

6. Exactly who can control linking the default Domain Controller Policy?

7. Exactly who can control linking the default Domain Policy?

8. Exactly who can delete Organizational Units (possibly containing 1000s of objects)?

9. Exactly who can set the Password not required bit on Active Directory domain user accounts?

10. Exactly who can set the Trusted for Unconstrained Delegation bit on computer accounts in Active Directory?

You see, not only are these simple, elemental, fundamental questions directly related to Active Directory security, they impact the foundational cyber security of business and government organizations worldwide, and that's why Active Directory administrators, security experts and IT teams worldwide (including Microsoft IT) must have answers to these at all times.

Not only that, for those that may not know this, these questions also directly impact the effectiveness of Mimikatz, and the degree to which a hacker could use Mimikatz in his/her efforts to compromise an organization.

In fairness to Sean Metcalf, in one blog post, he did very briefly touch upon the topic of delegated access in Active Directory, and I quote from this post -

Not tracking/monitoring/documenting delegated access to Active Directory -

"The best way to administer Active Directory and associated resources is to create custom groups and delegate specific access for these groups. If this isn’t planned and executed properly, this delegation can get out of control enabling far greater resource access for accounts than planned. Regular auditing of groups and their access is required to properly ensure Active Directory security. Don’t use the existing default groups to delegate rights to custom groups (ex. Help Desk members in “Account Operators” group) since the default groups provide more rights than are typically required. Delegation can be properly leveraged to ensure appropriate rights for each admin group. This requires gathering true requirements in plain English and translating them to system access rights."

For completeness, this good advice could have been rounded off with an appropriate concluding sentence such as: "Likewise, because delegations can be changed by many, anytime, it is very important to assess them frequently. This requires analyzing effective system access rights, and translating them back into plain English." (i.e. in other words, this or this.)

But if you look closely, in the 70+ posts on Active Directory security, at most a handful of them have touched upon the subject of administrative delegation, and unfortunately, none talks about "assessing who is delegated what access".

Again, in complete fairness to him, behind the global ignorance on this subject lies an aging behemoth's own ignorance.





A Trillion $ Keyword

If you find yourself thinking too hard about the above questions, don't sweat it. I'll give you a hint.

The answer to the above questions lies in a very simply, fundamental, elemental concept that no one, including the world's top/popular cyber security companies, such as Microsoft, Cisco, IBM, Google, Amazon.com, EMC, Dell, HP, CA, Centrify, Palo Alto Networks, FireEye, CyberArk, Beyond Trust, Leiberman Software, Thycotic, Checkpoint Software, Palantir Technologies, Kasperky Labs, Tripwire, DarkTrace, Lockheed Martin, BAE Systems, Tanium, BAH, etc. etc., likely has a clue how to (or the ability to) accurately and efficiently determine - this.

Or for that matter, something like this, this and this (and if you're smart, you'll understand the power of this.)

By the way, in all likelihood, even the cyber security companies listed above most likely don't have the answers to the above questions in their own foundational Active Directory deployments. (Speaking of which, "magic-quadrants" etc. are laughable!)

More on all this in days to come.

Oh, and in case you happen to chance upon this and think it will do it, let me tell you that that piece of software is not only woefully inadequate, it is dangerously inaccurate. I cannot over-emphasize the "dangerously" part. Virtually the same is true of this, this and almost anything else out there.

So, if anyone knows anyone in the world that possesses the ability to accurately answer even ONE of the questions listed above in any production Active Directory deployment, I'd like to know.


Time's Up

Unfortunately, my 10-minute timer just rang, so my time's up. I'll have to end this here.

All said and done, Sean has done a great job on helping people understand the importance of Active Directory Security thus far, and it is my hope that he will continue to expand his knowledge and continue to share it with the rest of the world.

Please know that my praise for Sean is sincere, and should not be taken any other way. The objective of this blog post was two-fold - to praise Sean's tremendous efforts thus far, and to help the world understand just how much more there is to learn in the ocean of a subject called Active Directory Security.

In all seriousness, the sheer amount of effort he has put in to help the world understand the importance of Active Directory security, and shed light on various attack vectors is clearly noticeable when you visit his blog, and is praiseworthy.


Before I sign off, I should mention that when he received his MCM certification, Sean Metcalf (deservingly and humbly) shared -

"NOW I AM A MICROSOFT CERTIFIED MASTER in Directory Services, 1 of only about 100 in the WORLD!"

As former Microsoft Program Manager for Active Directory Security (I believe 1 of only about 1 in the world) I'd like to congratulate him on his hard-earned accomplishments and contributions over the years.

So much effort, and great work, Sean! Please keep up the good work. If I can help you in any way, please do not hesitate to let me know. As you'll hopefully agree, there's so much more for everyone to learn, and here are three helpful pointers to get started - one, two and three.

Best wishes.
Sanjay


PS: Sean, good luck at Black Hat 2016. Unfortunately, thanks to the Black Hat Review Board's lack of knowledge on Active Directory Security, I won't be attending Black Hat. If you want to know why, just ask them to share the email I sent them.

PS2: If you're into cyber security, you may find this this blog interesting.

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

Microsoft IT’s Best Practices for Securing Active Directory – A Must Read (5 Takeaways and 1 Glaring Omission)

Folks,

If you’re a part of the Microsoft ecosystem, in all likelihood, you already know how valuable Active Directory is to Microsoft's Windows Server ecosystem, and how important the security of Active Directory deployments is to organizations worldwide.

(For those of you who don’t, Active Directory is the very foundation of cyber security in every organization whose IT infrastructure is powered by Microsoft Windows Server i.e. about 85% of all organizations worldwide.)

As you may also know, Microsoft's own global Active Directory deployment is one of the world’s most prominent and important Active Directory deployments, as it serves as the foundation for Microsoft’s global organizational security infrastructure.


Microsoft IT’s Best Practices for Securing Active Directory

Earlier this year, Microsoft IT released a whitepaper titled Best Practices for Securing Active Directory, which encompasses experience from several hundred Active Directory security assessments, critical incident responses, and recovery engagements -

 

Best Practices for Securing Active Directory

 

If you are in the Active Directory space, I highly recommend reading this whitepaper.

This whitepaper seems quite well written and covers a lot of interesting ground, (although a tad bit of the content seems repetitive.) The four key sections it covers include Avenues to Compromise, Reducing the Active Directory Attack Surface, Monitoring Active Directory for Signs of Compromise and Planning for Compromise.

 

I wanted to summarize the 5 key takeaways from this paper (below) but I also wanted to add that I was really surprised to see a glaring omission from this whitepaper i.e. that of the #1 risk to Active Directory deployments today (; more on that below.)

(BTW, I happen to know a thing or two about Microsoft's Active Directory deployment because I had the opportunity to propose and perform a risk assessment of Microsoft’s global Active Directory deployment SEVEN years ago i.e. long before Bret was the CISO. One of the outcomes of that assessment was that Microsoft IT's Directory Services Team was moved under the IT Corporate Security team, for the first time in the history of Microsoft IT. But I digress.)

5 Key Active Directory Security Takeaways

The following, in my humble opinion, are the Top 5 key takeaways from this whitepaper –

 

1.      Active Directory Security is Mission-Critical To Business

The very first thing that is noteworthy about it is that the Foreword of this whitepaper is by none other than Microsoft’s Chief Information Office Security Officer (CISO.)
 

Quoting Bret Arsenault, Microsoft’s CISO – “Active Directory plays a critical role in the IT infrastructure, and ensures the harmony and security of different network resources in a global, interconnected environment.” 

IMHO nothing conveys the criticality of Active Directory Security more than the CISO of Microsoft Corporation stating in clear words that “Active Directory plays a critical role in the IT infrastructure”

 

At Paramount Defenses, we have been saying this for over 7 years now. It was about time that Microsoft too publicly acknowledged the importance of Active Directory Security, and I am glad to see that they finally have done so.

 

I do sincerely hope that CIOs across the world are listening to what Bret has to say, and taking this seriously, in their own best interest, and of course in the best interest of their employees, customers, partners and shareholders.

2.      Active Directory Security Incidents (Compromises) Do and Have Occurred

IT personnel and management at so many organizations worldwide continue to think that Active Directory security incidents do not occur, and/or that the likelihood of occurrence in their organizations is low. Well, here’s a snippet from this whitepaper that might encourage them to give this fallacy a second thought – 

“Much of the content of this document is derived from the ADSA (Active Directory Security Assessment) and other ACE (Assessment, Consulting and Engineering) Team assessments performed for compromised customers and customers who have not experienced significant compromise.”

The fact that much of the content of this document has been derived from assessments performed at compromised customers clearly indicates that there have been enough Active Directory security incidents (compromises) to warrant the issuance of such guidance from Microsoft IT and to provide sufficient content for an entire whitepaper on Active Directory Security.

 

In fact, an introduction of the Avenues to Compromise section reads as follows – “This section provides information about some of the most commonly leveraged vulnerabilities we have found to be used by attackers to compromise customers’ infrastructures. This section begins with general categories of vulnerabilities and how they are leveraged to initially penetrate customers’ infrastructures, propagate compromise across additional systems, and eventually target AD DS and domain controllers to obtain complete control of organizations’ forests.”

Need one say more?

 

3.      The #1 Mitigation Step is to reduce the Number of Privileged Administrative Accounts

The #1 topic that the introduction to the section of Reducing the Attack Surface begins with reads – “This section begins by providing background information about privileged accounts and groups in Active Directory to provide the information that helps clarify the reasons for the subsequent recommendations for securing and managing privileged groups and accounts. We then discuss approaches to reduce the need to use highly privileged accounts for day-to-day administration, which does not require the level of privilege that is granted to groups such as the Enterprise Admins (EA), Domain Admins (DA), and Built-in Administrators (BA) groups in Active Directory. Next, we provide guidance for securing the privileged groups and accounts and for implementing secure administrative practices and systems.” 

At Paramount Defenses, we have been saying for years now that nothing is more important than minimizing the number of privileged administrative accounts in Active Directory by delegating all non-critical administrative tasks based on the principal of least privilege access (LPA) and ensuring that you know exactly who can do what in your Active Directory deployments, because the compromise of a single privileged administrative account/group is sufficient and tantamount to compromise the entire Active Directory.

Also, as any Active Directory security expert will tell you, it is not sufficient to minimize the membership of the default privileged administrative groups. In order to achieve true security, you have to know exactly who can perform which administrative tasks on which IT resources in Active Directory, because the ability to perform a single administrative task could be sufficient to take over the Active Directory.

For instance, a user John Doe may not be a member of any default administrative group, but if he effectively has the ability to modify the membership of any administrative group, or reset the password of any administrative account, he is effectively just one step away from being a privileged administrator himself.

Incidentally, the only way to know for sure exactly who has what privileged access in Active Directory is to perform an Active Directory Effective Access Audit to find out who really (i.e. effectively) has what administrative access provisioned in AD.

 

4. Active Directory Auditing only helps see Signs of Compromise

Most organizations view Active Directory Auditing as the #1 Active Directory security risk mitigation measure, but in fact, its use is primarily limited to delivering accountability and helping see signs of compromise.

An introduction of the section titled Monitoring Active Directory for Signs of Compromise reads – “Whether you have implemented robust SIEM in your environment or are using other mechanisms to monitor the security of the infrastructure, this section provides information that can be used to identify events on Windows systems that may indicate that an organization is being attacked.”

If you’re looking at an event in an event log, the administrative task / access corresponding to that event has already occurred. The keyword here is “already” meaning that it is in the past.

 

 

Should that event indicate the occurrence of a malicious action, then that action has ALREADY taken place. In other words, the system has already been compromised; now, all you can do is react to it, by trying to contain it if possible, and/or investigate for legal/accountability purposes. In other words, you’re reacting to a security incident.

Now, because no action can be performed without authorization, whether explicit, or implicit, the fact that someone was able to enact a specific action implies that he/she had sufficient effective access to be able to do so. He/she may not be supposed to have that access by policy, but it was effectively provisioned in the system, which is the only reason, he/she was able to carry out that action.

In most organizations today, no one really knows who has what effective access, and thus they’re operating in the proverbial dark, relying on auditing to give them some clue as to the misuse of excessive (unauthorized/unintended) access in Active Directory deployments.

On the other hand, if one knows exactly who can do what, one can have the assurance of knowing exactly who has the authorization to take a specific action to begin with, and that is SO MUCH BETTER than having no idea, and then relying on auditing to let you know that someone has ALREADY done something bad.

In that regard, a proactive Active Directory Audit of Effective Access is substantially more valuable than Active Directory Auditing, and in fact is an activity that should be performed by every organization on a periodic basis, ideally once a week, and at least once a month, because access changes frequently.

 

5. Accurate (Effective) Access Visibility is Mission-Critical To Active Directory Security

As you may know, most systems start in a known good secure state, and it is only over time that driven by access changes, that gaps start to appear between the "intended" state and the "actual" state, and over time, it is these gaps that become vulnerabilities that malicious entities identify and exploit.

 

Quoting from the first paragraph of the section on Avenues to Compromise – “In organizations that have experienced catastrophic compromise events, assessments usually reveal that the organizations have limited visibility into the actual state of their IT infrastructures, which may differ significantly from their “as documented” states. These variances introduce vulnerabilities that expose the environment to compromise, often with little risk of discovery until the compromise has progressed to the point at which the attackers effectively “own” the environment.”

 

The second paragraph continues to read – “Detailed assessments of these organizations’ AD DS configuration, public key infrastructures (PKIs), servers, workstations, applications, access control lists (ACLs), and other technologies reveal mis-configurations and vulnerabilities that, if remediated, could have prevented the initial compromise.”

In regards to vulnerabilities and mis-configurations in Active Directory content (i.e. the thousands of objects that reside in Active Directory), as such all Active Directory deployments are highly securable, because every IT resource is adequately securable via its access control list (ACL), and most IT resources in Active Directory deployments start out being adequately secured initially.

However, with the passage of time, the state of provisioned access changes quickly, and the “actual” state of provisioned access can deviate very quickly from the “documented” state of access, resulting in a situation wherein numerous vulnerabilities are introduced that can be identified an exploited to inflict damage and take over the Active Directory.

 

For example, one of the easiest ways to become a Domain Admin and gain complete control over an Active Directory deployment is to add one’s own account to the Domain Admins group. In order to do so, one only needs to find out who currently possesses the ability to change the membership of the Domain Admins group.

In 99% of organizations worldwide, there is a “documented” list which states the identities of individuals who should be able to do so, and there is the “actual” list, which is the list of individuals who can currently effectively change the membership of the Domain Admins group, and in a 100% of these organizations, these two lists are not identical.

In fact, there are always more individuals who can change this group’s membership than there are individuals on the “documented” list. The “actual” list can be put together by anyone with a domain user account and some Windows security knowledge, and used to identify at least one non administrative individual who has sufficient privilege to modify this group’s membership. This one individual then becomes the easiest avenue to obtaining privileged and unrestricted administrative access in the Active Directory deployment.

This is why it is very important (in fact paramount) to always have accurate visibility into who really has what effective access on which objects in Active Directory. At a minimum, organizations must always know exactly who can modify administrative group memberships and reset administrative account passwords, because these two tasks are the easiest avenues to gaining administrative power in Active Directory.

It is never easy to keep track of access in medium to large systems, which is why vulnerabilities exist to begin with. The ability to identify access vulnerabilities in Active Directory quickly and reliably can go a long way in identifying and eliminating vulnerabilities, and thus substantially help ensure security.

 

 

I'm sure there are other takeaways from the whitepaper as well, but these were the most interesting ones in my humble opinion. I'm a big believer in "Prevention is better than cure" because not everything is easy to cure, especially an Active Directory security compromise, so while I found the sections on Planning for Compromise interesting, I seriously do hope no organization needs to be in a situation wherein they actually have to use that information. They should be ready though, but I hope they never have to use it.

 

 

One Glaring Omission

Microsoft IT has done a good job at providing both, information on key threats to Active Directory, as well as actionable guidance on how to enhance Active Directory security. In regards to the threats, they’ve rightly pointed out that the single biggest target in Active Directory deployments are the administrative accounts and groups that can easily be targeted in an attempt to compromise Active Directory, and they have mentioned some of the top attack vectors including the pass the hash attack (PTH) vector.

But there was NO mention whatsoever of the #1 risk to Active Directory deployments.

The omission of the #1 risk to Active Directory is intriguing. Perhaps it is intentional, or perhaps, even Microsoft IT does not know what the #1 risk to Active Directory deployments is.

 

(The latter I find a little hard to believe, although it is not out of the realm of possibilities because there was hardly any coverage in the whitepaper on one of the most important areas of Active Directory Security, which is so extensively used worldwide, and to which the #1 risk is related.)

Anyway, since we’re about to declassify it shortly, if Microsoft IT does not know about it yet, they too will know about it, shortly, along with the rest of the world.

All in all, this whitepaper is a must-read and I highly recommend it. Although there seems to be some duplication of content within the whitepaper, there is still much information of value to learn from.

Kindest regards,

Sanjay

PS: You may find this interesting as well - Responding to a Domain Admin Account Compromise