Folks,
Today, as former Microsoft Program Manager for Active Directory Security, I'd like to take a few minutes to publicly recognize and praise the efforts that Mr. Sean Metcalf has put in over the last few years to help raise awareness about the importance of (and weaknesses in) Active Directory Security.
[Quick process note - you'll want to read this blog post in its entirety.]
For those of you who may not know Sean Metcalf, he runs the
ADSecurity.org website, and is a Microsoft Certified Master (MCM) in Directory Services. He has also spoken at numerous conferences such as Black Hat, Def Con, DerbyCon etc.
 |
| Sean Metcalf presenting at Black Hat 2015 |
Today, as a valued consultant, he helps many organizations assess the security of their Active Directory deployments.
I do not know him personally, nor have I ever met him, but I've heard of his efforts, and I appreciate them and wish him well.
Praise for his Efforts
Folks, I believe Sean's journey into Active Directory Security
began in 2011, i.e. almost 5 years ago, when he was inspired by an email from his friend. In March of 2011, he committed to his friend that he would pass all the tests required to be an MCITP:EA in 2 months! Keep in mind that around that time he was also the proud father of 1-year old triplets, so you can imagine how determined he must have been to succeed.
Fast forwarding to February 2012, on Super Bowl Sunday, he attended the elite Microsoft Certified Master (MCM) Directory Services Program in Building 40 at Microsoft headquarters in Redmond, WA. (I have fond memories of Building 40 as I spent 4 years of my own life in it (2001-2005.))
At 9:00 pm on February 21st, he
received an email which read - “
Congratulations! You have earned the Microsoft Certified Master | Windows Server 2008 R2 Directory certification!”
During his journey thus far, he has put a lot of effort and acquired a wealth of knowledge, starting from the very basics.
Speaking of basics, for instance, he
once learnt the optimal way to find users in Active Directory, and another time
he learnt how to Active Directory recon without requiring admin rights. (Of course, since Authenticated Users have blanket read access in Active Directory, performing AD recon requires no admin rights whatsoever. Zilch. Its easy-peasy, and today anyone can do substantial basic AD recon with this
free tool at a button's touch.) Over the years, he continued on to gain
advanced knowledge.
Over the last few years, Sean has put in a considerable amount of effort on researching numerous aspects of Windows and Active Directory Security and sharing his research online via
70+ posts at his blog.
In doing so, he has helped many organizations gain a deeper understanding of various aspects of Active Directory/Windows Security, predominantly vulnerabilities involving Microsoft's implementation of Kerberos and related attack vectors such as Pass-the-Hash, Pass-the-Ticket, Kerberos Golden Tickets, as well as related tooling (e.g. Mimikatz) etc.
Great work, Sean! The world could use more people like you, so thank you again for all your efforts.
First Things First
Sean had recently posted a blog entry on
Attack Methods for Gaining Domain Admin Rights in Active Directory, and in it he lists a few attack vectors -
- Passwords in SYSVOL & Group Policy Preferences
- Exploit the MS14-068 Kerberos Vulnerability on a Domain Controller Missing the Patch
- Kerberos TGS Service Ticket Offline Cracking (Kerberoast)
- The Credential Theft Shuffle
- Pass the hash evolves into Pass-the-Credential
- Gain Access to the Active Directory Database File (ntds.dit)
Sean has done a good job in providing adequate details and mitigations for each of them. In days to come, time-permitting, I'll shed some more light on them. For now, the salient part of that blog post, which is in the first paragraph is worth noting:
"The techniques described here “assume breach” where an attacker already has a foothold on an internal system and has gained domain user credentials."
(Hmm. If one were to assume breach, and knew
how to do this, or had
this or
this, the
Kingdom would be 0wned
in minutes.)
In contrast, each of the attack vectors listed above seem like they take
way too much effort to compromise an Active Directory,
in comparison to the most potent, effective and powerful Active Directory attack vector which unfortunately is not on that list yet i.e.
this one. In days to come, I'll share more details on it, in a blog post titled -
Breach to Owned in 5 Minutes.
By the way, when I say
0wned, I mean its
Game Over. The attacker will have attained complete control over the entire Active Directory forest, and there's nothing anyone will be able to do to stop him.
Period.
Active Directory Security 101 for the World, and for the Black Hat Conference
Since Sean will be presenting at Black Hat in a few days, I think Sean will likely agree that during his journey, he too must have realized that Windows Security and Active Directory security are vast subjects and there's an ocean of knowledge to be gained.
I say so from my own personal experience, because as former Microsoft Program Manager for Active Directory Security, here are just a few areas of Windows Security I had to master back in 2001 -
Distributed Security, AuthN, Authz, Auditing, Winlogon, Kerberos, NTLM, Digest, SSPI, SPNEGO, Mutual Auth, Logon Sessions, Windows Stations, Profiles, LUIDs, Access Tokens, SDs, ACLS, ACEs, Privileges, Rights, SMB, Lan Manager, NULL Sessions, Names Pipes, COM, SSL, TLS, SChannel, SAM Server, Federation, DCs, DS Repl, Trusts, SID Filtering, LDAP, DPAPI, SAML, Effective Permissions, PKI, Name Mappings, GCs, DNTs, DC Locator, ESENT, ADAM, ADFS, WinLogon, SID History, TDOs, TLNExclusions, ANR, Cross Refs, msDsQuotas, DFS, FRS, LVR, Credman, PAC, Windows Integrated Auth, DBDump, userAccountControl, Constructed Attributes, PDC Chaining, SAML, ADAM, RODCs, FGPP, Certificate Services, Token Bloat, Password Resets, Active Directory Privilege Escalation and about 100 other topics that come to mind.
Now, during the last few years, thanks mostly to a little bit of creative systems programming efforts of a certain Mr.
Benjamin Delpy, what was until then deemed theoretical
came to life, creating a menace for Microsoft's ecosystem and endangering the security of thousands of organizations, and ultimately leading to Microsoft putting in a lot of effort to introduce many
new security features, acquiring
a company or two, and releasing
guidance on how organizations could protect themselves from credential theft and reuse attacks. Impactful work on Mr. Delpy's part though, as it helped enhance Windows security.
(On a lighter note, interestingly, given how corporations work, Mr. Nadella and company might even use this to
tout Windows' 10 new security features and continue their
aggressive push to get the world on Windows 10, whether or
not people want it ;-))
(Also interestingly, it appears that the largest financial beneficiary from Mimikatz may possibly have been a little Israeli start-up named
Aorato, given its recent acquisition by Microsoft, albeit for
petty change. Recently, interesting to see the
former VP of Research at Aorato exchange notes with Mr. Delpy on Twitter quite a few times. Hmm ;-) By the way, on a lighter note, not too long ago, a few years ago, one day, someone at Aorato
sat thinking for two hours (as to) how to build an attack path, and then
realized that
everyone has access to Active Directory! Hilarious!! - that video's
here (2:10 onwards.) But I digress.)
Anyway, in all of this hoopla, a few CARDINAL points, including the world's #1 attack vector, seem do have gotten drowned -
1. Mimikatz requires local admin credentials to run on a Windows machine. To the uninformed, Mimikatz might sound like wow, but to the informed, it is merely an artifact of the a simple security truism - "You cannot prevent the administrator of a machine from controlling its Trusted Computing Base (TCB)." Conceptually, all Mimikatz does is inject code into LSASS and utilize the Crypto API to do a few things that can lead to credential harvesting, replay and misuse. I'm not belittling it; I'm just saying its just a system-level routine running as admin injecting code into LSASS and exploiting a few features in Windows designed to make network authentication a little more seamless.
2. Kerberos Golden Tickets require the NTLM password hash of the domain's KRBTGT account, which can only* be obtained by logging on to a Domain Controller as Admin. In other words, in order to acquire a Kerberos Golden Ticket, you at a minimum* need to have logged on as Admin on a Domain Controller. Any kid in Kindergarten will tell you that if you can logon to a Domain Controller as Admin, you already OWN the entire Active Directory forest! So, you don't need to work so hard (i.e. dump LSASS etc.) after that to get anywhere! Simply spawn a process as SYSTEM and you can play GOD in seconds! So again, what's the big deal here?
* Last year, a DCSync feature was added to Mimikatz, allowing it to be able to request and obtain from Active Directory, all data including account password data from a targeted Domain Controller. Again, to the uninitiated, this might sound like Wow, but to some of us, this is hardly surprising. Here's why. In order for the "DCSync" feature to work, the attacker requires that he/she effectively have the DS-Replication-Get-Changes-All extended right set on the domain root. Er, I wrote Microsoft's Whitepaper titled Best Practices for Delegating Active Directory Administration way back in 2003, and as early as then, we have said very clearly that if you have this right, you can in effect replicate password data out from the Active Directory, and play G0D!
Here's the extend right listed in Appendix D of my delegation whitepaper, published online as early as 2003. Point being that if you have this extended right granted in ACL of the domain root object, you already are for all practical purposes a God-like Admin, so what's the big deal here?
In short, to the uninitiated, all this hoopla caused by Mimikatz and the like may be wow-worthy, but to some of us, its just an example of someone utilizing some advanced Windows Security programming to convert a theoretical risk into reality.
In all of this hoopla, over the last few years, the world seems to have completely ignored (and thus still remains
highly vulnerable to) the biggest risk to Active Directory security - that of
Active Directory Privilege Escalation based on the identification and exploitation of unauthorized effective access grants in Active Directory.
Some Dots to Connect
Those who know how to exploit that risk can, given access to a single insider's credential (non-admin domain user/computer account) likely take over and shut down virtually any Active Directory forest, within minutes, from any domain-joined machine,WITHOUT requiring a SINGLE admin to have logged on an 0wned machine, let alone requiring the ability to logon to a DC as admin -
 |
| Active Directory Privilege Escalation |
By the way, password resets are simply one out of
umpteen ways to exploit this system-wide weakness. Group membership changes, group policy link changes, service connection point keyword changes, sensitive ACL modifications, disabling two-factor authentication, etc. etc. all fall under this attack vector. So, its a little more than just password resets.
In fact, 99% of the world doesn't know much about this risk. Those who do know that it poses a substantially greater cyber security danger to the world, than do these basic credential-theft attacks. I'll spare the details for another blog-post, and/or if you are really interested, and you're good at connecting dots, here are some dots for you to connect -
Dot 1 - The Paramount Brief
Dot 2 - The Attack Surface
Dot 3 - The Attack Vector
Dot 4 - Five Minutes
Dot 5 - An Interesting Picture
Dot 6 - 100% Mitigatable
In short, while we've seen Mr. Metcalf and 1000s of IT personnel worldwide focus on Kerberos related attacks, or simple SYSVOL related attacks etc. etc., we've not seen anyone talk about this huge security hole that's the size of the
Pacific Ocean in virtually every Active Directory deployment out there.
Billions of ACLs (The Pacific Ocean)
Folks, today, in thousands of Active Directory deployments across the world,
right within these Active Directory deployments, lie
billions of
access control lists (
ACLs) protecting billions of vital Active Directory objects, which represent administrative accounts and groups, employee user accounts, all domain computers accounts, all domain security groups, service connection points, group policies, contacts, and the entirety of Active Directory configuration content (including the Schema, the Configuration partition, the System container, the domain root object etc. etc. etc.)
The list goes on and on and on...
... yet, virtually no one in any organization has any idea as to who can truly do what in their foundational Active Directory.
In short, if you're into Active Directory security, you'll want to (literally) get INTO Active Directory, and if when you'll look inside, you'll find an ocean. Domain Admins are just the TIP of the Iceberg in this ocean of Active Directory security permissions.
10 SIMPLE Active Directory Security Related Questions -
To Sean Metcalf and other Active Directory security focused cyber security experts in the world,
including those at Microsoft, I would like to
most respectfully pose a few very simple, fundamental, elemental Active Directory security questions to consider -
In any production Active Directory forest in the world, does anyone know -
1. Exactly who has the Replication Get Changes All extended right effectively granted in the domain root's ACL?
2. Exactly who can change the security permissions in the ACL on the domain root object?
3. Exactly who can reset the password of all Built-in-Admin, Domain Admin and Enterprise Admin accounts?
4. Exactly who can disable the use of Smartcard authentication on accounts in Active Directory?
5. Exactly who can change the security permissions in the ACL of the AdminSDHolder object?
6. Exactly who can control linking the default Domain Controller Policy?
7. Exactly who can control linking the default Domain Policy?
8. Exactly who can delete Organizational Units (possibly containing 1000s of objects)?
9. Exactly who can set the Password not required bit on Active Directory domain user accounts?
10. Exactly who can set the Trusted for Unconstrained Delegation bit on computer accounts in Active Directory?
You see, not only are these simple, elemental, fundamental questions directly related to Active Directory security, they impact the foundational cyber security of business and government organizations worldwide, and that's why Active Directory administrators, security experts and IT teams worldwide (including Microsoft IT) must have answers to these at all times.
Not only that, for those that may not know this, these questions also directly impact the effectiveness of Mimikatz, and the degree to which a hacker could use Mimikatz in his/her efforts to compromise an organization.
In fairness to Sean Metcalf, in
one blog post, he did very briefly touch upon the topic of delegated access in Active Directory, and I quote from this post -
Not tracking/monitoring/documenting delegated access to Active Directory -
"The best way to administer Active Directory and associated resources is to create custom groups and delegate specific access for these groups. If this isn’t planned and executed properly, this delegation can get out of control enabling far greater resource access for accounts than planned. Regular auditing of groups and their access is required to properly ensure Active Directory security. Don’t use the existing default groups to delegate rights to custom groups (ex. Help Desk members in “Account Operators” group) since the default groups provide more rights than are typically required. Delegation can be properly leveraged to ensure appropriate rights for each admin group. This requires gathering true requirements in plain English and translating them to system access rights."
For completeness, this good advice could have been rounded off with an appropriate concluding sentence such as: "
Likewise, because delegations can be changed by many, anytime, it is very important to assess them frequently. This requires analyzing effective system access rights, and translating them back into plain English." (i.e. in other words,
this or
this.)
But if you look closely, in the 70+ posts on Active Directory security, at most a handful of them have touched upon the subject of administrative delegation, and unfortunately, none talks about "
assessing who is delegated what access".
Again, in complete fairness to him, behind the global ignorance on this subject lies an
aging behemoth's own ignorance.
A Trillion $ Keyword
If you find yourself thinking too hard about the above questions, don't sweat it. I'll give you a hint.
The answer to the above questions lies in a very simply, fundamental, elemental concept that
no one, including the world's top/popular cyber security companies, such as Microsoft, Cisco, IBM, Google, Amazon.com, EMC, Dell, HP, CA, Centrify, Palo Alto Networks, FireEye, CyberArk, Beyond Trust, Leiberman Software, Thycotic, Checkpoint Software, Palantir Technologies, Kasperky Labs, Tripwire, DarkTrace, Lockheed Martin, BAE Systems, Tanium, BAH,
etc. etc., likely
has a clue how to (or the ability to)
accurately and
efficiently determine -
this.
Or for that matter, something like
this,
this and
this (and if you're smart, you'll understand the power of
this.)
By the way, in all likelihood, even the cyber security companies listed above most likely don't have the answers to the above questions in their own foundational Active Directory deployments. (Speaking of which, "magic-quadrants" etc. are laughable!)
More on all this
in days to come.
Oh, and in case you happen to chance upon
this and think it will do it, let me tell you that that piece of software is not only
woefully inadequate, it is
dangerously inaccurate. I cannot over-emphasize the "
dangerously" part. Virtually the same is true of
this,
this and almost anything else out there.
So, if anyone knows anyone in the world that possesses the ability to accurately
answer even ONE of the questions listed above in any production Active Directory deployment, I'd like to know.
Time's Up
Unfortunately, my 10-minute timer just rang, so my time's up. I'll have to end this here.
All said and done, Sean has done a great job on helping people understand the importance of Active Directory Security thus far, and it is my hope that he will continue to expand his knowledge and continue to share it with the rest of the world.
Please know that my praise for Sean is
sincere, and should not be taken any other way. The objective of this blog post was two-fold - to praise Sean's tremendous efforts thus far, and to help the world understand just how much more there is to learn in the ocean of a subject called
Active Directory Security.
In all seriousness, the sheer amount of effort he has put in to help the world understand the importance of Active Directory security, and shed light on various attack vectors is clearly noticeable when you visit his blog, and is praiseworthy.
Before I sign off, I should mention that when he received his MCM certification, Sean Metcalf (deservingly and humbly) shared -
"NOW I AM A MICROSOFT CERTIFIED MASTER in Directory Services, 1 of only about 100 in the WORLD!"
As former Microsoft Program Manager for Active Directory Security (I believe 1 of only about 1 in the world) I'd like to congratulate him on his hard-earned accomplishments and contributions over the years.
So much effort, and great work, Sean! Please keep up the good work. If I can help you in any way, please do not hesitate to let me know. As you'll hopefully agree, there's so much more for everyone to learn, and here are three helpful pointers to get started -
one,
two and
three.
Best wishes.
Sanjay
PS: Sean, good luck at Black Hat 2016. Unfortunately, thanks to the
Black Hat Review Board's
lack of knowledge on
Active Directory Security, I won't be attending Black Hat. If you want to know why, just ask them to share the email I sent them.
PS2: If you're into cyber security, you may find this
this blog interesting.
