Today Cyber Security plays a paramount role in global security. On this blog, the CEO of Paramount Defenses shares rare insights on issues related to Cyber Security, including the World's Top Cyber Security Risk, Advanced Persistent Threats (APT), Cyber Warfare, Corporate Espionage, Insider Threats and other topics.


Gold Finger The Paramount Brief Gold Finger Mini World Peace

Tuesday, July 29, 2014

Cyber Security Claim "Critical Design Flaw in Microsoft Active Directory Could Allow Password Change" Incorrect: Active Directory Security 101

Folks,

95% of the Fortune 1000 run on Active Directory, so unless you're living on another planet, you'll want to read this.

95% of the Fortune 1000 Run on Active Directory
As former Microsoft Program Manager for Active Directory Security, and today as CEO of Paramount Defenses, the world's #1 cyber security company focused on Active Directory Security, allow me to share a few thoughts with you on what might very well be a bold yet incorrect claim.

Last week, we received a call from a journalist who wished to request our thoughts on a reported vulnerability related to Active Directory that has been widely reported as Critical design flaw in Microsoft's Active Directory could allow password change and exposed by a company called Aorato. Having never heard of this company before, we asked the journalist to email the details. The journalist then emailed us a link to Aorato's blog, which can be found here.

[Given my role at PD, I don't ordinarily have time to address such issues, but since we had a lot of organizations requesting our take on such a bold claim, I felt it necessary to shed some light on it, and am doing so via this blog entry.]



Aorato's claim that "Active Directory Vulnerability Disclosure: Weak encryption enables attacker to change a victim’s password without being logged" is incorrect.

With utmost respect to Aorato, I'd like to unequivocally state that, based on our assessment of their claim -

From a technical perspective, THIS IS NOT AN ACTIVE DIRECTORY VULNERABILITY at all.

Let me repeat that - technically speaking, this is NOT a vulnerability in Active Directory AT ALL. It is at best, a potentially exploitable weakness in Microsoft Corporation's implementation of Kerberos that has been known for years. Technically speaking, the only relation this has to Active Directory is that Kerberos uses Active Directory as its account database.

In my humble opinion, it may thus have been irresponsible to make such a bold yet technically incorrect claim, because doing so can result in a situation wherein thousands of organizations worldwide could panic, and incorrectly assume that their foundational Active Directory deployments are vulnerable, when in fact this is not the case.

I'm happy to demystify their claim and explain why this is not an Active Directory vulnerability (and I've done so below) but before I can do so, allow me to share a few thoughts with you.



A Little Knowledge is a Dangerous Thing

By claiming that their find is a vulnerability in Active Directory, Aorato may have demonstrated how much/little it may actually know about Active Directory Security, and as goes the old saying - a little knowledge is a dangerous thing.


I also have to admit that in my 15 year professional career, I've come across many Cyber Security companies, but I've never come across a company whose mission statement reads -

"At the core of Aorato’s founding was the acknowledgement that Active Directory is exposed – by default and by design. The consequence of which, is that the entire organization is at risk."

Now that's a first. A cyber security company at the core of which is the acknowledgement that one of the world's most robust and highly securable technologies, Microsoft's Active Directory is exposed - by default and by design.

In reality, of course, nothing could be farther from the truth. If you truly understand Active Directory security, you know that it is one of the most securable technologies in the world. It is neither exposed by default, nor in design. So such a claim only makes you wonder how much (or how little) this company might actually know about Active Directory security.

(If anything, an Active Directory deployment can be exposed to the risk of Active Directory Privilege Escalation, but that is neither by default nor by design. It is only because after years of delegating access in Active Directory, organizations do not have the means to reliably assess who is delegated what administrative access in Active Directory, and this exposure too can be reliably eliminated.)

Anyway, while browsing their website, it was a little unsettling to come across assertions/statements such as -
  • "Your Active Directory is exposed. Protect Active Directory and your organization from advanced attacks"
  • "Is your Active Directory under attack? We’re here."
  • "Windows Update to Fix Pass-the-Hash Vulnerability? Not!"

The most insightful one was on their Labs Page - "Your Knowledge Center for all Active Directory Security-Related Research"

I felt it was insightful because it only covered 4 technical topics - Pass-the-Hash, Pass-the-Ticket, Kerberos and NTLM. Microsoft has an entire 100 page+ white paper on Active Directory Security because it is an ocean of a subject, and these 4 topics at best comprise about 1% of the contents of the white paper, so to call it "Your Knowledge Center for all Active Directory Security-Related Research" seemed to provide valuable insight into how much/little they may actually know about Active Directory Security. (A better description could have been "Our Knowledge Center for Kerberos and NTLM Weaknesses Related Research.")

Perhaps they could benefit from an Active Directory Security 101 primer.



Active Directory Security 101 - A Demo of How Someone Could Actually Easily Compromise Virtually Any Active Directory Deployment in the World within Minutes

Folks, at Paramount Defenses, we actually do know a thing or two about Active Directory Security, yet out of respect for organizations worldwide, we have never demonstrated the impact of our knowledge to the world.


However, today, solely to help folks learn about the real risks to Active Directory security, and to help journalists who spin out sensational headlines without an inherent understanding of the technicals, allow us to share with you a little snippet of our knowledge - A Demo of How a Trusted Insider Could Easily Compromise any Active Directory in Minutes.


You see, if you truly understand Active Directory Security, you know that virtually any Active Directory deployment in the world can be compromised within minutes, without so much so as having to compromise a single machine, let alone having to carry out sophisticated PtH type attacks -


Active Directory Privilege Escalation
Anyone still working with techniques like Pass-the-Hash etc. is trying way too hard, for there are far easier ways to obtain administrative access in Active Directory,  so they may want to learn a thing or two about Active Directory Security.

Again, here's the link - A Demo of How a Trusted Insider Could Easily Compromise any Active Directory in Minutes


With that out of the way, here's our 2c on the vulnerability Aorato seems to have demonstrated.


The Vulnerability - A Potential Design Flaw in Microsoft's implementation of Kerberos, Not in Active Directory

If you truly understand Windows and Active Directory security, you'll most likely agree that the headline should have read - "Potential Design Flaw in Microsoft's Kerberos Implementation Could Allow Password Change" as this has everything to do with choices that Microsoft made when implementing Kerberos in Windows 2000 and nothing to do with a vulnerability in Active Directory.

Here's why...

Technically speaking, Active Directory is essentially an enterprise-grade, fault-tolerant and highly available (multi-mastered) directory service, which in addition to serving as a central directory service, can be (and is) leveraged by various components of Windows management, such as Kerberos, Group Policy, Exchange, PKI etc.

A vulnerability in Active Directory would have to do with one of the numerous components of the directory service itself, such as, but not limited to the database itsef, the Schema, its replication protocols, the LDAP protocol etc.

For instance, if someone had found a way to modify DC-to-DC replication traffic such that the data in transit could be tampered with, resulting in the inbound replication of modified tampered data at the receiving domain controller, that would constitute an Active Directory vulnerability.

The vulnerability described by Aorato has nothing to do with either of these components of Active Directory.

It only has to do with the the choice of encryption algorithms used by Microsoft's implementation of Kerberos to encrypt a Kerberos security principal's credential i.e. his/her password, the hashed version of which just happens to be stored in an attribute in Active Directory, because Microsoft's implementation of Kerberos uses Active Directory as its account database.

(For instance, consider a 3rd party application that leverages Active Directory and extends the Schema to introduce a new custom attribute that is used to store some application-specific data in Active Directory, and lets say that the manner in which that application uses the data (stored in that custom attribute) results in a potential security vulnerability. In such a situation, it would absolutely not be an Active Directory vulnerability. It would simply be a vulnerability specific to that application. In this case, that application just happens to be Microsoft's implementation of Kerberos. As far as Active Directory is concerned, there's just a blob stored in an attribute on a class of objects in it.)

Thus, it should be reasonably apparent to those of ordinary skill in the art, that this is NOT an Active Directory vulnerability. Consequently, the following claim, as made by them is factually incorrect - "As part of our ongoing research on advanced attacks, we expose a critical Active Directory flaw which enables an attacker to change the victim’s password."

For the last time, I'll say this again - this vulnerability is NOT an Active Directory flaw at all, LET ALONE alone it being a critical Active Directory flaw. With this fact out of the way, I'm happy to focus on the issue at hand.


A Potential Design Flaw in Microsoft's Implementation of Kerberos?

The issue at hand here is rather simple.

As many of you may know, there are two authentication protocols in Windows environments - Kerberos v5.0 and NTLM.

Kerberos is the default authentication protocol in Windows 2000 and beyond, and relative to NTLM, it offers various benefits such as more efficient authentication, mutual authentication, delegated authentication, simplified trust management, and of course interoperability.

I'm not about go into the details of how Kerberos and NTLM work, as you can find the details online, such as here. I'll assume that you have a decent understanding of these protocols work, so we can get to the heart of this issue.

What is commonly referred to as a "domain account" is technically a Kerberos Security Principal, and what is commonly referred to as a "domain" is technically a Kerberos realm. At the heart of Kerberos is the Key Distribution Center Service, the KDC, which happens to run on Domain Controllers (DCs) since it leverages the Active Directory as its account database.

Now, every domain account, whether it be a user account or a computer account, has a password associated with it, which is (ideally) known only to the account holder itself, and of course the KDC has access to a hashed version of the password. It is this (hashed version of the) password that is a shared secret between a Kerberos security principal and the KDC, and the KDC happens to share a unique secret with every Kerberos security principal, whether it be a user account or a computer account, and as a result, it is this set of shared secrets that enables Kerberos to facilitate secure access between two Kerberos security principals, and that is the fundamental basis upon which Kerberos works.

Now, when a user authenticates using Kerberos, he/she demonstrates knowledge of the password to the KDC during the Kerberos Authentication Service Request (KRB_AS_REQ) by encrypting pre-authentication data with the user's key, which is derived from the user's password. Since the KDC has a copy of the same user's key, it can decrypt the pre-authentication data, and authenticate the user.

As you may know, there is a fair amount of encryption involved in the inner workings of Kerberos. For instance, the authenticator requires encryption, as do tickets and session keys. In order to facilitate encryption/decryption, Kerberos allows a KDC client and the KDC to negotiate the encryption types to be used i.e. the actual encryption algorithms and checksum types to be used by a client and server to encrypt authenticators, session keys and Kerberos tickets.

For instance a client requesting a TGT from the KDC can during the KRB_AS_REQ inform the KDC about the encryption types and key lengths it can work with, and the KDC will generally pick the strictest encryption type that both the client and the KDC support, assuming it can work with the one of the requested types. (There can also be situations where in the KDC will be unable to use a specific encryption type, and in such cases, will issue an error to the client.)

Microsoft's implementation of Kerberos supports the following encryption types, (; their key lengths in parentheses)  -
  1. AES-256-CTS-HMAC-SHA1-96 (256 bit) 
  2. AES-128-CTS-HMAC-SHA1-96 (128 bit)
  3. RC4-HMAC (128 bit)
  4. RC4-HMAC-EXP (EXP stands for exportable, and is 56-bit)
  5. DES-CBC-MD5 (56-bit)
  6. DES-CBC-CRC (56-bit)
(There are also about a dozen checksum types that it supports such as CRC32, SHA1 (Unkeyed) etc.)

Anyway, the core point to note is that over the years Microsoft's implementation of Kerberos has supported multiple encryption types ranging from the weak DES-CBC-CRC to the strong AES-256. It is also worth noting that not all the encryption types have been there all along, and not all encryption types will be supported all along. For instance, AES-256 wasn't supported until recently and DES which was introduced in Windows 2000 is now off by default in Windows 7 and beyond.

The one common encryption type that has been consistently available is RC4-HMAC. It has been available since Windows 2000 and it is still supported in Windows Server 2012, although starting Windows Server 2008 R2, it can NOW be disabled on all domain controllers. (However, this requires a minimum of a Windows Server 2008 domain functional level and an environment where all Kerberos clients, application servers, and trust relationships to and from the domain must support AES. Support for AES was introduced in Windows Server 2008 and Windows Vista.)

The issue at hand has to do with the key used for RC4-HMAC. Since it was introduced way back in Windows 2000, and (apparently) because Microsoft wanted to make the upgrade from Windows NT to Windows 2000 seamless, (it appears that) a decision was made that the key to be used for RC4-HMAC would the same as the existing Windows NT key (NT Password Hash) for compatibility reasons.

Now it turns out that the NT Password Hash is the same as the NTLM Hash, and thus what Aorato appears to be claiming is that if an attacker can gain access to a user's NTLM Hash by using appropriate tooling that can extract/copy hashes from memory, theoretically, since the attacker has the user's NTLM hash, he/she could potentially use it in an attempt to obtain a Kerberos ticket if the KDC can be made to support the RC4-HMAC as the encryption type to be used during the exchange.

Interestingly, here is where Aorato's description/claim starts to get murky, because they tangent out to claim that since "KAdmin" i.e. the module that handles password changes, essentially operates in a similar manner, theoretically, the NTLM hash could be used to request a password change operation via "KAdmin" and once the password can be changed to one of a value set by the attacker, the attacker could then additionally also obtain access to resources that require an interactive logon (i.e. the use of a clear-text password), examples of which include Remote Desktop RDP) & Outlook Web Access (OWA).

That's where their claim ends.

PtH attacks have been in use for some time now, and their exploit methodology is generally well understood by most folks. One key aspect of such PtH attacks is that password hashes can only be used for network logons, so for instance, you cannot use a password hash to obtain access to a resource that requires that you enter a clear-text password.

In light of this limitation, hypothetically it would be additionally advantageous if one could leverage a copied hash to somehow learn of the existence of a user's clear-text password. The next best thing to learning of the user's current clear-text password is to be able to change it to one of your choice, and what they're saying is that it appears that one can use the NTLM hash to carry out a password change request, thereby additionally gaining the benefit of being able to now also access resources that do require the entry of a clear-text password, examples of which include interactive logons as well as to access other services and features such as Remote Desktop.

Now, the fact that the key used for RC4-HMAC is the same as the existing Windows NT key (NT Password Hash) has been public knowledge for years now, and thus it is only logical that theoretically, anyone with access to the NTLM hash could potentially use it to try and use it to obtain a Kerberos ticket, and along the same lines, use KAdmin to try and enact a password change.

(Its been public knowledge because RFC 4757 states very clearly that - "The key used for RC4-HMAC is the same as the existing Windows NT key (NT Password Hash) for compatibility reasons.")

If something is theoretically possible, it is generally only a matter of time, before someone can build sufficient tooling to enact the scenario out. Aorato seems to have invested some time to demonstrate this in a proof-of-concept scenario, and although they don't provide any verifiable proof to the general public other than a claim that they have demonstrated a proof-of-concept to Microsoft, it is certainly possible to build such tooling.

For example, up until a few years ago, tooling just did not exist to carry out Pass-the-Hash based attacks. Today of course, it is commonly available to virtually the entire world.

It appears they brought this to Microsoft's attention, and in response, Microsoft simply issued a simple statement, a snippet of which follows -

"This report is about a limitation in the Kerberos Network Authentication Service (V5) standard (RFC 4120), that is well-known within the industry, whereby an attacker can authenticate as a user, or change that user’s password, if they know that user’s secret key."

In other words, according to Microsoft there's nothing novel here.

However, Aorato wishes to contend that there is indeed something novel here, because an NTLM hash can be used to perform a password change operation on the victim's account, and thereby additionally gain access to other resource types that explicitly require clear-text credentials i.e. knowledge of the password.

I will certainly give them this much - the fact that this is theoretically possible has been known for years; the fact that they seem to have put in a lot of effort to try and demonstrate it in a proof-of-concept definitely validates the theory, and yes, if based on an NTLM hash, you can obtain a Kerberos ticket, and/or change a user's password via KAdmin, there is arguably something novel about it. But this is NOT an Active Directory flaw, so  in that regard i.e. this being a "Critical Design Flaw in Active Directory", they are incorrect.



4 Realistic Barriers to Success when Using this Attack Vector

This might appear to be high-impact, but in reality, its utility is rather low, for the following reasons -

1. The attacker can only compromise those accounts that happen to logon to the machine he/she owns. If 99% of users never logon to that machine, the attacker can sit there and wait and grow old, but he'll never get anywhere, because no one logged on to his/her machine

2.  Accounts that are not in active use either because they are disabled, or because they have expired cannot be used, because even if you change the password of these accounts, unless an admin enables or unexpires them, you cannot use that account even if you know the password.

3. Accounts that are active can only be targeted for a short duration of time, because the next time around that the victim proceeds to authenticate him/herself, the password known to him/her will not work, and a call to help desk will most likely result in a password reset.

4. With minimal effort, a notification system can be put in place, such that whenever a user's password is changed, he/she instantly receives a notification. A password change not made by the user him/herself will instantly alarm the user, and allow the organization to take reactive measures.

One cardinal difference between the Pass-the-Hash attacks and an attack in which the perpetrator changes the victim's password is that the use of a hash cannot generally be easily detected, whereas a password change on a victim's account can be instantly detected.

The fact that it can be instantly detected implies that a user can instantly detect a password change not carried out by him/her, and consequently, the perpetrator can be very quickly either apprehended or his efforts can be rendered useless.


The Insufficient Auditing Claim

Aorato claims that the resulting audit entries do not have sufficient information to inform IT personnel that something "fishy" might be going on i.e. it fails to show the pertinent attack information.

It appears that the reason auditing entries fail to show pertinent attack information, is because until recently, this was simply theoretical, so it was most likely not on the list of possible scenarios, and thus log/audit support may very well not be there for such a scenario. Of course I don't speak for Microsoft anymore, but you get the drift.

In this regard, unfortunately, there is some not-so-good news for Aorato. Before I share it, I wanted to take a minute to share another thought with you. So hold this thought for a minute.

If you read the blog carefully, there is a snippet that reads -

"One of the inherent shortcomings of logs is that they are a summary of the information. During the process of summarizing some information is bound to get “lost in translation”. Therefore, building a security system and strategy to rely on logs rather than on the actual traffic means that they are built on some shaky foundations."

Now, lets stop for a minute and consider what it is Aorato actually does. If you browse their website, you'll find that they're in the business of developing and offering a "Directory Services Application Firewall" which can monitor all Active Directory related network traffic and try and help organizations detect suspicious activities such as the one involving this attack.

It thus only appears logical that it would be in their research interest to uncover additional attack vectors, the use of which, during attacks, would constitute suspicious activities that their firewall could detect, thereby potentially increasing the need for a product designed to detect such attacks.

The not-so-good news for them is that there are far easier ways for insiders to easily and completely compromise an organization's Active Directory, than having to carry out such sophisticated, expertise-reliant attacks. About a 100 times easier. And the swiftness with which they can be enacted can render virtually all security measures, including their detection by any such firewall, completely useless.

(Any organization that wishes to see a real demo in their environment can contact us. We'll be happy to demonstrate the enactment of this attack vector. In fact, its so easy that literally anyone with a domain user account can enact it today. )

But I digress.

The other not-so-good news for Aorato is that although Kerberos related auditing may not detect something fishy, with just a little bit of coding, Microsoft, or any 3rd party tool can have an alert (via email, text, voicemail etc.) issued to users that their password has changed. This is rather easy to do, and is one of the easiest ways of helping organizations combat the occurrence of such an attack.

The benefit of having end-users know that their password has changed, as opposed to having IT admins know, is that an end-user will be able to instantly identify a suspect password change, and take appropriate action, such as informing IT personnel, who could then investigate the incident.

Finally, perhaps Aorato might wish to know that anytime a user's password is changed, the PwdLastSet attribute is updated, so a malicious password change can be instantly detected.


One Important Point - 0wning a System

Folks, much has been made of hash exploitation related attacks, but one has to understand that in order to carry out such an attack, the attacker has to gain ADMINISTRATIVE control over a machine, and for someone who already has administrative control over a machine, with just a little imagination and social engineering, there are far easier ways to capture a user's clear-text password than to have to go through all this trouble.

There is nothing super heroic about being able to extract hashes from the memory of a computer when you are the Admin of that computer, because in effect, as the admin, you control the Trusted Computing Base (TCB) of that computer.

Secondly, it should again be apparent to those of ordinary skill in the art that once you control a domain-joined machine, and you spawn a process in System context on the machine, it automatically goes across the network as the domain computer account, so you already are an Authenticated User across the entire forest. I'm not about to shed light on interesting things you can do with this, but those who're smart will get the drift.

Of course if this computer account happens to be trusted for (unconstrained) delegation, well, ...


Is this Much Ado About Nothing?

As I mentioned previously, it has been a well-known fact for 8+ years now that the RC4-HMAC uses the Windows NT key (NT Password Hash), and any proficient IT security professional will agree that if its the same as the NTLM Hash, theoretically, with sufficient skill/tooling, it can be used to encrypt the pre-authentication data in a KRB_AS_REQ request and the negotiated use of RC4-HMAC as eType.

What Aorato seems to have done is demonstrated this theory in a proof-of-context, and that's worth something because it demonstrates that tooling to exploit this design flaw can be built.

Their finding may very well have led Microsoft to issue this recommendation - http://technet.microsoft.com/library/9111e6f0-fb7f-4340-b87a-ab941978efe1.aspx

In reality though, for Microsoft's customers, implementing this recommendation is not that easy. Interestingly, this recommendation from Microsoft could certainly catalyze Windows Server upgrades from Windows Server 2003 to Windows Server 2008 and beyond.

However, as I indicated above, in reality, because a password change can be instantly detected, in reality, the use of this attack-vector will almost always result in the perpetrator being caught red-handed.

Although they may have demonstrated how someone could exploit the design flaw in Microsoft's implementation of Kerberos, they unfortunately seem to have incorrectly characterized/sensationalized it as a "critical design flaw in Microsoft Active Directory."

From a quick review of their website and blogs, it appears that such a characterization may most likely have been based on their lack of in depth knowledge of Active Directory and Windows Security.

It also appears that as they work towards increasing their level of Windows and Active Directory security knowledge, they may uncover more weaknesses, some of which may be well-known and a few of which may be novel.

Here's why...

Consider a scenario wherein a beginner is introduced to a new subject. As he learns more and more about the subject, his level of expertise advances from beginner to intermediate and eventually to expert. Somewhere alone the post beginner stage, he learns something new, that to him appears to be cutting-edge, but of course to others, is something logical and well-known. Anyway, all excited about this new discovery, he builds a little proof-of-concept, and claims a huge breakthrough.

For instance, if you read Aorato's blog, a few weeks ago, they seem to have made a big deal about "a Windows authentication flaw that allows deleted/disabled accounts to access corporate data." Technically speaking, all that this refers to is that the lifetime of a TGT is 10 hours, so once you have a TGT, you're good for 10 hours, irrespective of whether the account is disabled or expires. If you read their blog, its a big deal!

If you ask others, such as most folks who've been working with Windows authentication technologies for over 14 years, since Windows 2000 came out, this is just basic knowledge. After all, its just the way Microsoft's implementation of Kerberos works.

But 14 years after Windows 2000 came out, as Aorato begins to learn more about the workings of authentication technologies in Windows, they seem to have had this profound revelation that this 10-hour TGT lifetime related issue is a Windows authentication FLAW.

Their relative newness to the subject is indicated by the following comment made in regards to that blog entry -

"We are all for responsible disclosure. However, as the quoted Microsoft's official documentation shows, they were quite aware to the consequences of their implementation choice. So there's nothing to disclose to Microsoft they did not already know. The needed responsible disclosure is for the rest of us, that were under the false impression that when we disable/delete a user account the disabled user access rights are revoked immediately."

Anyone who knows how Kerberos works in Windows knows that a TGT once issued is (by default) good for 10 hours, and by implication, that it can be used to request a service ticket during that time. The only way one can be under the "false impression that when we disable/delete a user account the disabled user access rights are revoked immediately" is if one is not (yet) decently familiar with how Kerberos works in Windows, which can happen if you're new to the subject, and find this to be a startling discovery.

My genuine well-intentioned suggestion to Aorato would be to take the time to actually understand Windows Security in-depth. In the spirit of sharing, not just for Aorato, but for anyone who wishes to be a Windows Security / Active Directory Security Expert, here's a list of some topics brain-dumped in no particular order, you might wish to read up on -

Distributed Security, AuthN, Authz, Auditing, Winlogon, Kerberos, NTLM, Digest, SSPI, SPNEGO, Logon Sessions, Windows Stations, Profiles, LUIDs, Access Tokens, SDs, ACLS, ACEs, Privileges, Rights, SMB, Lan Manager, NULL seessions, 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, ADAM, ADFS, Azure, 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, Certificate Services,  Token Bloat, Password Resets, Active Directory Privilege Escalation, and about 50 other topcis that come to mind.

For starters, to help figure out just how easy it is for a user to determine whether his/her password has changed WITHOUT even having to look at an audit log, here's one thing to look at - the pwdLastSet attribute on user accounts..

The point is that Windows / Active Directory Security is an ocean of a subject, and the more you learn, the more you realize how much more there is to learn.


Wrapping it Up

Folks, the key point I wanted to make here was that purely technically speaking, this so claimed "critical design flaw" has nothing to do with "Active Directory" per se, and everything to do with someone finally being able to demonstrate that it is possible to take advantage of a potentially exploitable weakness resulting from a decision Microsoft made 15 years ago, in regards to deciding which key to use with the RC4-HMAC encryption type.

In the spirit of fairness, as I have indicated above, the ability to demonstrate how someone could exploit this design flaw, is worth something. However, in this case, the realistic opportunity to use the resulting attack vector is low because it requires a) the attacker to gain control of a machine, b) the victim to logon to that machine and c) a password change which can be instantly detected.

In comparison, when there are far easier ways to compromise virtually any domain user account without so much so as having to gain administrative control over a machine, let alone having to pass hashes, organizations have much bigger problems to solve.

Speaking of bigger problems, in reality, in a majority of the 95% of the Fortune 1000, virtually NO one has ANY idea as to EXACTLY who has what administrative powers in their Active Directory.

(When you have no idea as to exactly who has what administrative in your Active Directory, worrying about advanced attack vectors such as this one, is akin to a kingdom wherein the Defense Ministry has no idea as to exactly who has the keys to which palaces, chambers, residences and gates, but is worrying about what to do about the possibility of an outsider having entered one little hut in the kingdom possibly trying to enter another hut, when in reality, the entire populace of the kingdom, can with the right tools, instantly find out exactly who has the keys to which door across the entire kingdom, including of course to the King's chambers.)


One Final Question -

Here's a question to any company that claims to have expertise in Active Directory Security -



Q. Can you help 95% of the Fortune 1000, answer (even any 1 of) the following 5 fundamental cyber security questions? -

(Each one of these questions have everything to do with Active Directory Security.)


1. Exactly how many people can reset the password of any one of their Domain Admins, Built-in Admins, Enterprise Admins etc. to instantly take over their Active Directory, and thus potentially completely control their entire IT infrastructure?

2. Exactly how many people can reset the CEO's, CFO's, CIO's or the CISO's password to instantly login as him/her and obtain access to everything he/she has access to?

3. Exactly how many people can modify the group membership of any or every security group that they use to control access to the entirety of our organization's IT resources, to in effect gain, grant or revoke any individual of one's choice the ability to access any resource of one's choice?

4. Exactly how many people can delete mission-critical IT resources such as user accounts, computer accounts, security groups, OUs etc, in effect causing substantial and almost always irreversible damage to the organization?

5. What is the easiest path to go from being just an ordinary user account holder (e.g. a contractor working half way around the world) to being a Domain Admin / Enterprise Admin within minutes?

If you can't, please don't be too hard on yourself, because even the Dells, Hewlett-Packards, Ciscos, McAfees, EMCs, Tripwires, CAs, BAHs, Symantecs, Lockheed Martins, FireEyes, Centrifys, CyberArks and Checkpoints of the world can't.

We can (answer all of them, at the touch of a button.)


Best wishes,
Sanjay

Thursday, March 6, 2014

Updated a Potentially $ Trillion Cyber Security Algorithm Last Week

Folks,

My sincere apologies for the unintended lapse in sharing thoughts via this blog, which has primarily been on account of us having received a "seemingly" simple request late last year, the fulfillment of which required my involvement and time.
 
We Need to Know, NOW

A few days after I penned my last blog entry, we received a request from a rather prominent U.S Government agency (i.e. one with a 3-letter acronym ending in A) that happens to have a rather large and complex Active Directory environment.

Administrative/Privileged Access Holders

The request was seemingly simple – we were requested to try and do our best to enhance the performance of Gold Finger’s unique administrative access assessment/audit capabilities, so that Gold Finger could help them “swiftly” identify exactly who had what administrative powers (aka the “keys to the kingdom”) in their environment.
 
By “swiftly” I mean, within a matter of minutes.

Gold Finger could already identify and reveal paramount administrative access/entitlement insight like Who can effectively reset the password of any user in the organization to instantly login as him/her, within minutes in most deployments. It was in complicated environments that it could sometimes take an hour or more. An hour's not that bad at all, considering the sole alternative, which is to try and do the same manually (using basic tools), which could easily take months, if not years. 
 
But I suppose they needed Gold Finger to be able to do the same in their "complex" AD deployment, within minutes.
 
 
Why they needed this is not ours to question. (We don’t question - we only deliver.) But if I had to guess, I'd say its probably because they understood the risk associated with an insider being able to identify and exploit unauthorized access grants in their Active Directory to gain access to and subsequently tamper, divulge or destroy virtually any IT resource he/she wanted to, at will, and may have thus felt the need to attain and maintain least-privileged access (LPA) in their foundational Active Directory at all times, given that access provisioned in AD is always changing, even if by a little.

Anyway, this was, as I said a "seemingly" simple ask.

I say "seemingly" simple because as the architect of Gold Finger, I'll be the first to tell you that the only thing harder than making something as sophisticated as Gold Finger, is trying to make it much faster. Here’s why -

When you press the Gold Finger button, almost half a million lines of code go to work in a magical black box, and within minutes, they reveal completely accurate, instantly actionable and mission-critical effective access insight in plain English.
 
 
 
For instance, when you select a report like Who can reset user account passwords across a domain of say 50,000 users, Gold Finger literally determines effective permissions on 50,000 user accounts in a single shot. That's no easy task. To begin with, it involves retrieving almost 5 million ACEs, doing the relatively easy stuff (resolving 1000s of SIDs, expanding 1000s of direct/nested/circular group memberships, etc. etc.) and then the difficult stuff (assessing millions of access grants taking into account over a dozen factors), to ultimately identify and reveal exactly who can reset whose passwords. There’s also a lot that can go wrong at any point so you have to be able to deal with virtually every potential unknown.

In essence, there are over a 100 different inter-dependent logical functions that operate in unison to do at a touch of a button, what is generally considered almost impossible to do. In other words, there’s just so much complexity involved that trying to make the smallest change, let alone trying to accomplish even a 10% performance gain, can be quite difficult.

So, although this seemed like a simple ask, what was required to deliver on it was in fact a combination of deep subject matter expertise, utmost discipline, world-class software-engineering, and of course comprehensive testing.

After months of highly disciplined work (some of which was already in progress), our Engineering teams ultimately achieved what was no easy feat - making Gold Finger faster. Not just a little faster, but up to 5 times faster.

 

Gold Finger 6.0

Gold Finger 6.0 embodies our patented cumulative access entitlement technology and is the culmination of over half a decade of innovative cyber security research and development. It is not only the world's fastest cyber security solution that can accurately identify and reveal the identities of all individuals who effectively possess (any level of) administrative / privileged access in Microsoft Windows Server based IT infrastructures powered by Active Directory, it may possibly be the world's ONLY cyber security solution that can do so.
 
 
A Potentially Trillion $ Algorithm 

As you may know, in most organizations worldwide today, the compromise of a single administrative / privileged account could be sufficient to inflict colossal and often irreversible damage to the organization, so the need to know exactly who has what administrative access in Active Directory (which stores and protects the keys to virtually every lock in the kingdom) is paramount. 
 
For those, to whom this seems overstated or far fetched, there’s just one name to mention – Edward Snowden.

In our efforts to fulfill this request, not only were we able to help one of the world’s most important government agencies, we have also been able to (now) empower virtually every organization worldwide to finally be able to know within minutes with complete accuracy, exactly who has the proverbial keys to their kingdoms.

With over 85% of all government and business organizations worldwide running on Active Directory, including virtually the entire Fortune 1000, even we’re not sure how to value an algorithm that can uniquely and instantly help determine exactly who’s got the keys to the(se) kingdom(s).
 
 
All we know, and care deeply about, is helping organizations worldwide attain and maintain least-privileged access (LPA) in their Active Directory deployments, because we believe nothing is more important than “defending the keys to the kingdom”.
 
Alright, back to work.

Best wishes,
Sanjay

PS: Sadly, it takes just ONE malicious or coerced insider with admin/privileged access to inflict colossal damage.

Friday, September 13, 2013

The World's #1 Cyber Security Risk - Active Directory Privilege Escalation

Folks,

The #1 cyber security risk to organizations worldwide i.e. one that today critically impacts 1000s of business and government organizations in almost every country, is Active Directory Privilege Escalation (downloadable Executive Summary below), as evidenced here.


It is SO powerful that one who knows how to exploit it can, with the help of appropriate tooling, use it to instantly take over virtually any Microsoft Windows Server based IT infrastructure in the world.

With sufficient effort, it can also be used to develop an exploit that can then be packaged into a malicious payload that can automate the disruption / destruction of any Active Directory deployment of choice within hours to days, making StuxNet look like child's play, considering the fact that 85% of the world's organizations are powered by Active Directory.



Executive Summary

The following Executive Summary describes this risk. To access it, simply click on the image below -
 
Active Directory Privilege Escalation based on Exploitation of Unauthorized Grants in Active Directory

Why Did We Declassify This?

Strictly speaking, there's nothing to declassify here, because this is common sense. However, in our experience, we have found that hardly any organizations are aware of this. More about that later.

The reason we have declassified it is that we have reason to believe that at least one advanced persistent threat may have figured this out, and given their abundant resources, could potentially, easily build a payload to exploit this threat worldwide.


By the way, the Chinese aren't the only ones who may have potentially figured this out. There are numerous Active Directory and Windows Security Experts in countries like Russia, who are highly capable of figuring this out (, and some of them, of potentially exploiting it as well.)

(If you don't believe that the Russians are good at Active Directory Security, just ask Quest Software (now a part of Dell) how many Project Managers and Software Developers it has in Russia, where I'm told it builds/supports some of its flagship identity and access management solutions, which today are also deployed at departments in the U.S. Government. But I digress.)

One would ordinarily expect organizations to have figured this out on their own, but in our vast experience of having dealt with 1000s of organizations over the last 7 years, we have found that very few organizations in the world actually have any clue about this. (Most of them are still merely looking for how they can enumerate stale accounts in their Active Directory deployments.)

Then, when we saw Microsoft IT release a whopping 328 page white paper on Active Directory Security, and barely even touch upon this subject, it was clear to us that, apparently even Microsoft IT did not understand just how serious this risk was to Active Directory deployments worldwide.

We care deeply about Microsoft's ecosystem, so we decided to shed light on this risk. We decided to share it in the public domain because it would have been too much to try to individually reach out to 20,000+ organizations worldwide.

(By the way, we have been giving hints for a very long time from all the way back in 2006, (here's an example - Who needs WMDs today?) but I suppose these hints were not enough, and until something is said most plainly, it isn't clearly understood.)

That said, I'll now address the technicalities of this risk, and provide some commentary.


Technical Summary

From a pure risk management/assessment standpoint, here is a technical summary of this risk -
  • Asset at Risk – Administrative Delegations, Admin Accounts and Groups
  • Threat Source – Malicious Entity (Could be Outsider or Insider)
  • Attack Surface – Vast (All Active Directory Content)
  • Exploitation Procedure – Detect and exploit unauthorized access grants in Active Directory using freely available tools like dsacls and acldiag. Malicious use of advanced tools like an Active Directory Permissions Analyzer or an Active Directory Password Reset Analysis Tool can speed up the detection process. The free availability of Active Directory management tools like ADUC can be used to enact the exploitations (e.g. perform a password reset to escalate privilege, etc.)
  • Difficulty – Minimal (Authenticated Users have read access by default.)
    Unlike the Pass-The-Hash (PTH) technique, this technique does not require admin access on a server, or the requirement for an admin to logon to that server. It only requires read access to Active Directory (AD) content (which Authenticated Users have by default), the ability to analyze AD ACLs to find excessive rights (which can be easily done using available tools), and the ability to enact administrative tasks (which can be easily done using any Active Directory management tool, such as Microsoft Active Directory Users and Computers.)
  • Impact – Very high (Once gained, administrative access can be used to very quickly cause widespread damage across the IT infrastructure.)

 Risk Overview

There are 3 main components that make this risk critical -





  1. There exist large numbers (1000s) of excessive / unauthorized access grants in most Active Directory deployments worldwide, which effectively grant numerous individuals (that should not technically be provisioned) powerful administrative access.
  1. The identities of these individuals and the excessive access they currently have (, unbeknownst to them, or to the IT groups,) can, be determined by anyone with a domain user account. Once determined, this information can be easily used to perform single/multi step privilege escalations and ultimately gain varying levels of, and usually complete, administrative access within minutes, and performing these privilege escalations only requires enacting simple admin tasks (e.g. Password Resets) for which tooling is freely available.
  1. The attack surface is vast, and the prize is the coveted "keys to the kingdom". The attack surface is vast because it consists of the entirety of all IT resources stored in the Active Directory, and virtually any authenticated user, can with minimal/moderate Active Directory expertise, find these excessive access grants and identify privilege escalation paths which can then be exploited to gain complete administrative control over the Active Directory.

The need for any Active Directory expertise is eliminated if sufficient tooling (e.g. an Active Directory Permissions Analyzer or an Active Directory Password Reset Analysis Tool) exists that makes it possible for someone to make such determinations without requiring any subject matter expertise.


What makes this Risk Possible?

This risk is made possible by the fact that in any Active Directory deployment, at any given moment, there are 1000s of security permissions that specify varying levels of access for various individuals and groups, and that together control who has what effective access to which IT resources in the Active Directory, BUT that are very difficult to correctly assess/verify/audit, because there are numerous factors involved in how the system determines effective access, as a result of which there is no easy way to know who has what effective access at any point in time in Active Directory.


In fact, today, in most organizations worldwide, no one really knows who exactly who can do what in Active Directory.

In regards to these permissions, they control vital administrative actions like who can create user accounts, modify security group memberships, link/unlink GPOs from OUs, delete accounts, groups or entire OUs, as well as perform numerous other administrative tasks on the most vital of IT resources, i.e. user accounts, computer accounts, security groups and GPOs, which are the very building blocks of security in any IT infrastructure.

In regards to the factors that influence effective access, there are numerous factors, such as and not limited to inheritance of permissions, precedence orders, applicability of permissions, individuals and blanket permissions, general and special permissions, group membership evaluations, nested group membership evaluations, circular group membership detection, well-known group memberships, multiple permissions influencing an action, permissions on multiple permissions influencing an action, etc.

As you can imagine, given the complexity involved, and the scale of the problem (i.e. entire Active Directory content), as well as the dynamic (frequently changing) nature of access, it is almost impossible to find out who has what effective access on a single object, let alone an entire OU or domain of objects.

Consequently, without being able to accurately assess who has what effective access, IT personnel have no way of knowing exactly who currently has what effective access, so they continue to provision access (to fulfill dynamic business requirements) based on intentions and approximations, but they have no way to know for sure whether they in fact provisioned access based on the principle of least privilege, or whether they accidentally / inadvertently might have ended up granting access to more individuals than they should have.

As a result, in most Active Directory deployments in the world, there are 1000s of excessive permissions granted, and there is no easy way to find out who really has what effective access in these deployments.


What does it take to Mitigate this Risk?

Objectively speaking, in order to mitigate this risk, 3 abilities are essential -


  1. Minimially, the ability to be able to easily and reliably determine accurate effective access on individual Active Directory objects
  1. Ideally, the ability to do so on a large number of objects in a reasonable amount of time, as well as
  1. The ability to determine HOW someone is getting provisioned specific effective access, so corrective action can be taken.

Finding out Who has what Permissions is NOT the answer

Over the last few years, we have seen 1000s of organizations looking for ways to find out "Who has what permissions in Active Directory" because they believe that in order to solve this problem, they need to find out who has what permissions.

These organizations are not alone. There are also numerous prominent audit organizations (i.e. whose auditors certify companies for compliance of various sorts) that demand that companies furnish reports of who has what permissions in their Active Directory on various objects, such as the CEOs account and that of all Domain Admins.

With all due respect to all of them, knowing who has what permissions in Active Directory is NOT going to help them solve any useful problem, and certainly not help mitigate this risk.

Here's why -

Consider this ACL protecting the CEO's user account. Just because a group such as Help Desk Tier I is granted a specific permission such as Reset Password in the ACL of an object does not mean that all members of that group effectively have that permission on that object.



For instance, just because John Doe is a member of the group Help Desk Tier I and this group has the Allow Reset Password permission on the CEO's user account, does not mean that John Doe can in fact reset the CEO's password.

That's because there could be a Deny permission denying the Outsourced Password Reset Admins group overlapping permissions such as Full Control or Reset Password on the same object, and if John Doe were a member of that group, whether directly, or via a deeply nested group membership, he wouldn't effectively have the ability to reset the CEO's password.

To complicate things, if the Deny permission was inherited and the Allow was Explicit, he would be allowed access. By the same token, there could be numerous other permissions specified in various other ACEs in the ACL of that object that could influence, whether directly or indirectly, what permissions he/she had on the CEO's account.

So you see, finding out Who has what Permissions in Active Directory is not what is needed to solve this problem, or make any meaningful assessment upon which any reliable security action can be taken.

What is needed is the ability to determine who has what Effective Permissions in Active Directory, because that is the only piece of data that would instantly and accurately reveal exactly what access John Doe actually has on a given object, or on any set of objects in the Active Directory.

I'll say this again - the only way to determine who really has what access in Active Directory is to find out who has what (true) effective permissions / effective access in Active Directory.


The Attack Vector

Now getting back to the risk, in case you're wondering what the attack vector is, it is very simple.

All a malicious entity has to do is analyze the ocean of security permissions in Active Directory to find weaknesses that can be exploited, and then exploit them to gain administrative access in Active Directory.

Let me give you an example -

The two easiest ways of becoming a Domain Admin are a) reset a Domain Admin's password and b) modify the membership of the Domain Admins group to add your own account, or that of another user, to the group.




(The PtH attack vector is not the easiest by any means because it REQUIRES that you have Admin level access on a host ON TO WHICH a Domain Admin LOGS ON. If a Domain Admin NEVER logs to your machine, you can sit there and get old, and yet not gain anything (malicious.))

With this attack vector, all a malicious entity has to do is apply some basic knowledge of Active Directory Security to try to determine effective permissions on either a Domain Admin's user account, or the Domain Admins group membership, and figure out a) exactly who can effectively reset the Domain Admin's password, and/or b) figure out who can effectively change the Domain Admins group membership.

Once that's done, you now have a list of lesser protected targets that if compromised can be used to become a Domain Admin.

For example, if the Domain Admins only sit in the Data Centers and never get out of there or logon to any machine other than theirs, the PtH attack vector is completely useless.

However, if John Doe is a delegated admin who sits in a cubicle down the hall from you, and you have been able to figure out that he/she can effecitvely reset a Domain Admin's password, or change the Domain Admin's group membership, all you have to do is compromise the account of the delegated admin John Doe, and you're a minute away from logging on as him and resetting a Domain Admin's password, or adding your own account to the Domain Admin's group membership.

Now, if you have unrestricted physical access to this delegated admin's machine (desktop/laptop), its super easy. There are a gazillion (proverbial) ways to own a machine with unrestricted physical access. In fact you could even use the PtH attack vector in combination to lure this delegated admin to your machine using Social Engineering, and once you have compromised his account, you're a minute away from owning the kingdom.

This approach can also be iterated, meaning you can find who can reset the password of a delegated admin who can reset the password of another delegated admin who can reset the password of a Domain Admin etc. etc..

Please UNDERSTAND that performing the analysis of who has what effective access ONLY involves READ ACCESS to Active Directory, which a) everyone with a Domain user account already has and b) is not/cannot be realistically "audited" because if you started auditing read access to Active Directory, your logs would be rolling over every 30 minutes.

As a consequence, an attacker could take his/her sweet time (hours/weeks/months) to quietly determine effective access on one or more of your Active Directory objects, and eventually determine numerous privilege escalation paths, which could, at a time of his choice, be used within minutes to perform single/multi-step privilege escalations in Active Directory.

Once an attacker has gained Domain Admin access in your environment, he could do whatever he/she wants. Of course the first thing a smart attacker would do is disable all other admin accounts so no one can stop him, then he would disable auditing, and then he could obtain access to, tamper, destroy or divulge whatever IT resource he/she wants. (A devious attacker could also use Group Policy to destroy the entire IT infrastructure within minutes, but I'm not about to talk about that.)

I'll say this again - technically ANYONE with a Domain User account could take HOURS/DAYS/WEEKS to determine effective access in your environment, and find privilege escalation paths, and when he has, at a time of his choice, he could make his move i.e. WITHIN MINUTES, exploit the identified privilege escalation paths to take over the entire IT infrastructure.

(With appropriate tooling, the amount of time involved for the attacker to determine effective access in Active Directory could be reduced down to minutes from hours/days/weeks.)


A Vast Attack Surface

Now let me speak to another very important aspect of this risk; its attack surface is VAST.

By attack surface, we can refer to two things here - one is the set of assets that are at risk, and the second is the set of all entities that can potentially carry out a related attack.

In terms of the assets that are at risk, every user account, every computer account, every security group, every GPO and every OU is at risk. The attacker could select any asset of his choice and determine who has what effective acccess on that object to find weaknesses, then exploit those weaknesses to compromise security.

For example, let's assume that a highly confidential document was residing on a file server, and that a malicious individual wished to gain access to it. The easiest way to access it is not to try to compromise that highly protected file server, but merely examine the ACL of that document to determine which Active Directory domain security group is being used to protect that document. Once you have figured that out, all you need to do is determine effective access on that security group's object in Active Directory, and find out who can change the membership of that group.

That's the weakest link. If you iterate, you can then find out who can reset the password of the individual who can modify the group membership, to find an even easier target to compromise. Once that's done, all you have to do is compromise any one account in the chain, then perform a few password resets (which take 30 seconds) and you can then add your  account to that group. Once you're a member of the group, you can just access that file without compromising any security control on that file server.

Similarly, a malicious user could find out who can delete an entire OU full of resources to instantly cause an internal DOS attack that would take days (and a proverbial $ million) to recover from.

By the same token, if you wanted to disrupt a line-of-business (LOB) application whose clients rely on querying Active Directory for service connection points whose keywords are used to locate specific instances of the service, all you have to do is modify the keyword on the service connection point, and in effect you could DOS that service. In order to modify the keyword, you only need to determine effective permissions on the service connection point to find and exploit weaknesses.

So you see, virtually every IT resource in the Active Directory is a potential target.

Lastly, in regards to the second aspect of the attack surface, virtually anyone with a domain user account has complete and unrestricted read access to the Active Directory, so virtually everyone can examine all the permissions protecting all the IT resources stored in Active Directory.

In other words, literally everyone can examine your Active Directory and look for unauthorized access grants, whenever they want, form whichever computer they want, and on whichever resource they want.


Active Directory Effective Access/Permissions - A Trillion Dollar Phrase

At the heart of this risk lies a single trillion dollar phrase - Active Directory Effective Access/Permissions. If I might add, the correct phrase actually is Accurate Active Directory Effective Access/Permissions.

You see, effective access/permissions are so important to Active Directory Security that along with Auditing, there's an entire Tab for Effective Permissions on the Advanced Security Settings dialog box, which can be accessed by the Active Directory Users and Computers Snap-In as well as Administrative Center -



One unfortunate problem is that this Active Directory Effective Permissions Tab is not accurate and thus is not reliable, and thus is virtually of no practical use.

Furthermore, strictly speaking, even if it were accurate, it's neither user-friendly nor can it assess effective access on more than one object at a time. If your Active Directory has a 1000 objects, even if it were accurate, you'd end up spending months to just determine effective access on those 1000 objects.

What is strictly needed to solve this problem is the ability to determine effective access, not just on a single object, but on entire trees of Active Directory objects at a time, quickly, reliably and ideally in a single shot, as well as having the information delivered in a meaningful way that can be acted upon to identify and lock down unauthorized access grants, and for which, of course, the need to know HOW someone currently has specific effective access is also essential.

For example, something like this.

And by the way, the reason I say this is a TRILLION dollar phrase is because if you take into account the net worth of even the top 1% of organizations that may be exposed to this risk, it'll handily cross a $ Trillion.



So you can imagine my surprise when there was not a SINGLE mention of the phrase "Effective Permissions" in the 300+ page Active Directory Security Guide that Microsoft IT recently released! (Yes, you're welcome to verify this fact; you can download that guide from here.)


IS this Risk Mitigatable?

Absolutely. Like most technical risks, this risk too can be mitigated. The most important thing needed to mitigate this risk, is the will to do so, because the process is (relatively) simple.

Objectively speaking, all that is needed to mitigate this risk is the ability to swiftly and reliably perform an audit of  effective delegated/provisioned access in Active Directory.

Once that is done, organizations should instantly know who currently has what effective access and can review the findings to determine all policy violations i.e. the list of all individuals who should not be able to perform a specific task, but who can today, and HOW.




Then the HOW part can be used to identify the underlying permissions that are causing the excessive / unauthorized access to exist, and this information can be used to determine which security permissions and/or group memberships need to be tweaked to eliminate the unintended access grants from being in the system.

When performed with sufficient diligence, such a process can result in 99% risk reduction in a matter of days to weeks, depending on the resources allocated to the project. The hardest part is to accurately identify the ocean of unauthorized grants across the Active Directory (because fixing them is relatively easy.)

In this regard, the biggest challenge is posed by the effort involved in swiftly and reliably performing an audit of effective delegated / provisioned access in Active Directory. While it is possible to do so manually, doing so could take months. Automation can help reduce the amount of time taken to do this down to hours or days, thereby making the process substantially faster and more economical.

In short, the hardest part to fixing this problem is correctly finding the unauthorized access, not fixing it. Once you know what to fix, fixing it is relatively easy. Its the finding part that's very difficult.


How about a little help from Active Directory Security Solution Vendors?

There are many 3rd party vendors today that offer a host of valuable Active Directory security solutions ranging from valuable professional services to valuable auditing solutions, such as -
  1. Hewlett Packard
  2. Quest Software (now Dell)
  3. Centrify
  4. ManageEngine
  5. Beyond Trust
  6. Netwrix
  7. SolarWinds
  8. Net IQ
  9. Varonis
  10. etc.

Based on my professional opinion as former Microsoft Program Manager for Active Directory Security, I am not aware of any solution from any of the above listed respectable vendors that can solve this specific problem.

(Please don't get me wrong. I'm sure they're all good at what they do, predominantly Auditing (which relatively speaking, is a much simpler problem to solve, because it only (again, relatively speaking) involves collecting and rolling up audit events from DCs into a single database and onward to a dashboard. But I digress again.))

That's because this is a VERY difficult problem to solve.

Let me give you just ONE example -

Let's assume you needed to find out who can effectively delete an OU? (Yes, just a single small OU with a 100 objects in it.)



Here's what it takes to correctly make this effective access determination -

You need to determine who has what effective delete access on the OU which involves considering the influence of the Standard Delete, Delete Child and Delete Tree permissions on the OU, and if the OU is not empty, you further need to determine who all can delete ALL the children in that OU, either by virtue of Standard Delete permissions or Delete Child permissions or Delete Tree permissions, as only he/she who has sufficient effective rights to delete all the children in the OU as well, can delete the OU. (Now, if one had Delete Tree on the OU, it would be sufficient, but if not, then you'd have to evaluate effective access on all the child objects as well.)

If ANYONE in the world, can write a script or make a tool that can accurately determine just this much, on a single non-empty OU (with say just a 100 objects in it,) correctly, taking into account all the factors involved, let alone doing so across an entire Active Directory domain consisting of 100s of 1000s of objects, in a single shot, I'll bow to this individual/entity.

Now, getting back to the risk.


Where's the Proof?

So, if this is so difficult that it virtually impossible to do, why should one worry about this being a threat, and where's the proof that something like this can be automated, such that it could give someone the ability to instantly find out who can reset whose passwords, or for that matter instantly find out who has what effective access across an entire Active Directory?

Here you go -

If you can touch a button, you can use this to instantly find out exactly how many people can reset your password as well as that of any colleague, and of course, of your CEO as well.



(The choices of fictitous names and their fictitous designations in the snapshot above are intentional.)

NOW, we only designed this for use by authorized organizational IT personnel, but the point is that if we can do it (with less than 100 full-time developers, testers and engineers), imagine what a foreign government can do with 1000s of personnel devoted to building something like this, especially if you consider what is at stake, and what can be had.

Besides, there are enough people out there who know enough about Active Directory Security, who can use simplistic tools like this, to figure out a rough approximation of effective access on a single object in about 20 minutes per object. (Keep in mind that all it takes is read access, so you can't detect them doing it.) That particularly tool cannot accurately determine effective permissions, but it can be used to view and analyze AD ACLs instantly.

By the way, if this isn't enough proof, here's some more - if you can touch a button, you can use this to instantly find out who has what effective access across an entire Active Directory, within minutes, at the touch of a button.


Getting to a Bullet Proof State

If you have an Active Directory wherein access grants are always (verifiably and provably) provisioned based on the principle of least privilege, you have no reason to worry.



That's because even if the entire user population were to determine effective access on your Active Directory, all they would find is tightly least-privileged basis provisioned access, wherein only authorized individuals are granted the access they need, so there would be 0 escalation paths for them to exploit.

Is this doable? Absolutely. Our Active Directory deployment is bullet-proof in that regard.

What does it take to do it? More than anything else, it takes the support of executive management (C*Os), and a proficient team of Active Directory Security professionals who are equipped with the resources they need to maintain a solid and secure Active Directory.


How about a Proxy Solution? (Tread with care)

There are some organizations that use a proxy solution to facilitate the delegation of administration in their environments. While there are some benefits to it, generally, there is also an accompanying risk you undertake when you deploy any such solution, because that solution basically has complete and unrestricted access to your Active Directory, and thus a single vulnerability in it, whether accidental or malicious, could instantly jeopardize the security of your entire Active Directory.

The other downside of a proxy solution is that it becomes a very attractive target for malicious entities because if they know that the compromise of that one solution can be used to instantly gain complete and unrestricted administrative access, their efforts to compromise such a solution will substantially increase because there's only one layer to peel there, and a single point of failure.

In contrast, thanks to the multi-mastered nature of Active Directory, i.e. no single point of failure, most attacks can be controlled, if you know how to do so. (Hint: multiple-DCs and replication to the rescue.)

Anyway, AFAIK, there aren't many such solutions, and I'm not sure if they're even built/supported from within the United States. I'm told that at least one (a popular one) is built in/supported from Russia.

I don't know about you, but if I were responsible for leading an IT department in the U.S. Government, or that of a Fortune 500 Company I'm not so sure I'd be inclined to (or even be allowed to) deploy anything built in/supported from Russia, especially in light of the recent Edward Snowden affair. (But that's just me.)

The only other thing I will add is that even if one were to use a proxy solution, the problem still remains, because you'll always have the computer objects representing all the domain-joined machines in the Active Directory, and there will undoubtedly be a need for access to be provisioned on them as well, whether to control aspects like the Trusted for Delegation bit or to allow services running on those computers to modify the service connection points published under the computer objects, etc.

Finally, there are so many Active Directory integrated applications these days, and most of them rely on direct access to the Active Directory, whether it be read access or modify access. In cases where modify access is required, it will still be direct access, and not via the proxy, and so the need to be able to audit and control such direct access will always exist.

In essence, irrespective of whether you're using a proxy solution, the risk described above remains.


About The Chinese

Let me address one penultimate issue.

As you may know, a little company called Mandiant recently because famous because its CEO published a report that essentially showed the extent to which the Chinese were engaging in cyber security compromises.

One of the salient aspects of that report involved a description of HOW the Chinese were doing this, and if you see this Wikipedia page, you'll find, in the APT life cycle section, that the defining act that helped the intruders to gain administrative access was in fact Privilege of Escalation.

Specifically, if you scroll down the Wikipedia page on Advanced Persistent Threats to the APT life cycle section, you'll find the following excerpt: "In 2013, Mandiant presented results of their research on alleged Chinese attacks using APT methodology between 2004 and 2013 that followed similar lifecycle:
  1. Initial compromise — performed by ...
  2. Establish Foothold — plant ...
  3. Escalate Privileges — use exploits and password cracking to acquire administrator privileges over victim's computer and possibly expand it to Windows domain administrator accounts.
  4. Internal Reconnaissance — collect ...
  5. Move Laterally — expand ...
  6. Complete Mission — exfiltrate stolen data from victim's network."
The 3rd step, Escalate Privileges is the defining step that gives a perpetrator administrative access in target IT infrastructures, by virtue of which substantial willful damage can be inflicted.

Thus far intruders have been using age-old techniques like password guessing, but our cyber intelligence data indicates that the Chinese have been actively researching Active Directory Privilege Escalation involving password resets, which is why I chose to declassify this today.

So you see, nothing I have stated here is far fetched at all.


Oh, and this too is VERY important.

Do you know what is one of the easiest ways for the Chinese, or the Russians, or others to deliver a malicious payload into an organization?

Allow me to tell you. Craft and offer a malicious payload as a a Free Active Directory Reporting Tool online, and you will be surprised at just how many 1000s of personnel will download it and execute it. We recently conducted an experiment to test this, (and it is still online) and we were shocked to see the results. (Of course the dummy tool was digitally self-signed and harmless, but you get the point.)

It takes just ONE execution of ONE malicious payload, especially when done in the context of an Active Directory Admin, to potentially automate the compromise/disruption/destruction of an entire Active Directory deployment.

Just ONE.

And we have seen SO many organization search for Free Active Directory Reporting Tools, including organizations, whose names, if I was to reveal to you, you would be shocked!

So, in your best interest, PLEASE do NOT download and run anything FREE from the Internet, UNLESS you have sufficient reason to believe that it is TRUSTWORTHY. Not even ONCE.


A Word about Auditing

This discussion would not have been complete without the mention of auditing.

Auditing is helpful, because it can help detect the occurrence of this attack, but its use is largely limited to just that - detection. It is vastly more important to be able to prevent the occurrence of such an attack, than it is to try and detect it, and then try and stop it, because in all likelihood, if you're up against an advanced perpetrator, he will not give you the opportunity to stop him, and by the time you try to react, he may already have disabled all your domain admin accounts.

So, auditing is good to have, but is not going to help you mitigate this risk. Detect, yes, Mitigate no.



Not Just Domain Admin Accounts, All Active Directory Content is At Risk of Compromise

By the way, lest you be under the impression that only Domain Admin accounts are at risk, if you haven't gotten the drift yet, let me state it clearly - every delegated administrative account and group, as well as every domain security group that is being used to protect access anywhere across the forest, every OU, every GPO and every SCP is a potential target and at risk of compromise.


If you haven't figured out the serious impact of this yet (i.e. not just Domain Admin accounts but virtually all Active Directory content is at a potential risk of instant and wsift compromise), I doubt anything else I say will drive home the point any better.

The point about Domain Admins was just made to convey the mechanics of this risk.



Responsibly Declassified this Risk

As you will hopefully agree, it would be highly irresponsible to shed light on any risk without there also being an adequate risk mitigation measure to mitigate this risk. We have known about this for years now (evidence) but it is today, after 7 years of knowing about this, that we have finally shed light on this risk, only because today there are solutions that can adequately mitigate this risk.

So I hope you'll agree that we have responsibly declassified this critical risk to Active Directory deployments. (Also, perhaps in light of this, this old blog post from 2006 will make some sense.)

By the way, if you were expecting that I will be declassifying a bug/code vulnerability in Active Directory, I'm sorry to have disappointed you. You see, if that was the case, I would have reported it to Microsoft, and not blogged about it. This risk does not stem from any such bug/code vulnerability, but in fact it stems from a capability deficiency in a product, and I had already informed Microsoft about this way back in 2007 (; yes, they were the first to know.)


But We don't worry about Insider Threats

This also happens to be the #1 insider threat to organizations worldwide. Here's why.

Organizations that do not worry about insider threats need only be reminded of one name - Edward Snowden, the classic Trusted Insider, who may not only have caused monumental damage, but also great embarrassment, to arguably the world's most powerful and clandestine national security agency, the U.S. NSA.


In Summary

I know I've touched upon quite a few points today, and I hopefully didn't distract you from the core risk here, which is real, imminent and very serious. If addressed in time and properly, it can easily be mitigated and in a reasonable time-frame.

Unaddressed though, it is a ticking time-bomb...  

... because a malicious entity only needs to find and exploit ONE privilege escalation path to potentially completely compromise an organization's entire Active Directory deployment.

Just ONE.

Best wishes,
Sanjay


PS: What I am also almost certain of is that the Symantecs, McAfees, EMCs, RSAs, TripWires, Mandiants and Booz Allen Hamiltons of the world most certainly have neither a clue about this risk, nor the ability to help organizations worldwide mitigate it.