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|
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 -
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
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.
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) -
- AES-256-CTS-HMAC-SHA1-96 (256 bit)
- AES-128-CTS-HMAC-SHA1-96 (128 bit)
- RC4-HMAC (128 bit)
- RC4-HMAC-EXP (EXP stands for exportable, and is 56-bit)
- DES-CBC-MD5 (56-bit)
- DES-CBC-CRC (56-bit)
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.
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? -
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.)