Dear Mr. Delpy,
Hello. I hope this finds you doing well. Although we don't personally know each other, I've heard about your work, and the impact it's had on improvements in Windows Security, so
thank you for your contributions to the field of Windows Security.
To begin with, I'd like to apologize for not having been able to tune sooner into the incredible
circus caused by your interesting
hobbies over these past few years :-), as I was away, silently working on the
world's most powerful cyber security weapon ...
 |
Gold Finger 007G
|
... you know, one that can be used to go from
breach to 0wned (AD) in about 5 minutes in any Active Directory deployment in the world, even and particularly in environments (such as the one described below) wherein an intruder couldn't accomplish much with
Mimikatz. We've built it for the good guys though, so that they can prevent such scenarios from occurring.
By the way, like you, I too am a programmer. I
personally wrote about 10% of the code for all of Gold Finger and 007G.
(The rest of it was written and tested by a team of < ~ 50 software dev and QA engineers, all of whom are ex-Microsoft.)
However, given its sheer power, I'm not too big a fan of releasing our work in the wild, because I believe in an old saying - "
Along with great power, comes great responsibility." (As for
this, it is merely temporary and
controlled.)
(Oh I digress. I have a bad habit of digressing often, so my apologies. End of digression.)
I did however briefly hear about Microsoft scrambling to try and save its face by
buying a little start-up whose founder (, and you too might find this funny,) not too long ago, one day,
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.))
Oh, by the way, I forgot to introduce myself. I'm the
one who did a risk assessment of Microsoft Corporation's global Active Directory more than a decade ago and showed them...
...well, I'm not about to reveal what I showed them.
They know it, and that's all that matters.
Oh, I'm also the one who amongst other things, wrote Microsoft's
400-page whitepaper on
how to delegate privileged access in Active Directory, only about 10 years before the world had heard of Mimikatz or an Aorato.
Speaking of privileged access in Active Directory, as you probably know, that cool little recent
DCSync feature of yours, would be rendered
completely USELESS if the perpetrator didn't have sufficient rights to replicate secrets out of Active Directory.
 |
| Replicating Directory Changes All Extended Right on Domain root in Active Directory |
And while that feature may wow some, to us it very simply boils down to this - if you already possess sufficient privilege to be able to replicate secrets out of Active Directory, you're already virtually God in that environment any way. But thank you nonetheless for showing the world just how easy it can be. (Actually its not
that super easy too, so I respect your work.)
Interesting side note question - Do you think
anyone in the world knows exactly who has the
Get Replication Changes All extended right
effectively granted to whom in any production Active Directory environment, wherein the domain root ACL has been changed even once? (I don't think so.)
Oh, and by the way, as you may well know, you can't generate a Kerberos Golden Ticket without having the NTLM hash for the krbtgt account, and if you don't have the
Get-Replication-Changes-All extended right to request secrets from a DC, you can't have that hash until you can log on as an Admin on a Domain Controller, BUT, if you can log in as an Admin on a Domain Controller, buddy, its
ALREADY GAME OVER RIGHT THERE!
So, why bother going a step or five forward (LSASS dump, hash extraction etc.), when its already game over! Just use the task scheduler to launch a cmd prompt as System, and you're playing God in no time ;-)
I mean, seriously, if you're telling me that its that easy for a perpetrator to be able to logon as Admin on a Domain Controller at hundreds or thousands of organizations worldwide, then I must say, the $400+ Billion Microsoft hasn't done enough to educate its customers about the importance of protecting its Domain Controllers, and probably ought to spend a petty $100 million to do so right away (because if that's that easy, forget ATA, nothing's going to be able to protect these organizations from getting 0wned in minutes.)
[Again, a (not so) small digression...
Active Directory / Cyber Security 101 for the World
If your Domain Controller has been compromised, you're
DONE. Period.
 |
| Domain Controllers in a Data Center |
From the AD Admin to the CEO, it's time to pack up, go home, and
find another job, because believe you me, until you completely re-build the forest from scratch, he who knows what to do will have you for ETERNITY without needing any ticket, let alone a Golden Ticket, at all! (To whose who would like to see a demo of this, please let us know.)
Let me repeat that. If an unauthorized individual can login to a Domain Controller as Admin, you are done! D-O-N-E!
Only ignorant organizations will continue to operate that Active Directory forest,
because you'd be operating on a compromised foundation, and if you do, those who truly understand Active Directory security, will know (and could divulge) everything there is to know about you, tamper with anything, destroy anything at will etc. etc. And yes, even
Microsoft's latest toy won't be able to stop them.
... end of digression.]
Mr. Delpy,
if you'll allow me, I'd like to most respectfully paint a very simple picture for you, one wherein, one could possibly grow old and maybe even have grand-children, and
yet not succeed with Mimikatz. For brevity, I'll keep it simple.
Consider a forest with one or more domains wherein -
1. Domain Controllers: All physically secured in data-centers, requiring triple-factor authentication to physically access. Interactive logon denied to everyone except an empty AD security group. Of course, fully patched (so no low-hanging fruit etc.), plus all default User Rights and Privilege assignments severely locked-down. Soldered USB drives and keyboards i.e. no chance of applying a keystroke logger or USB-anything. No 3rd party software of any kind on these machines. Etc. etc.
2. Get Replication Changes All Extended Right: Only granted to Domain Controllers.
3. Domain Admins: None. All responsibilities for Active Directory service and data management (i.e. account and group management) natively delegated in Active Directory. In fact, the Domain Admins group SID has been removed from across Active Directory by a simple execution of a baby of a tool called dsrevoke.
4. Active Directory Admins and Designated Workstations: Less than 5 AD admins, each one with alt accounts, and separate workstations for every day use and admin use. Admin use workstations are as secure as the DCs, and interactive and network logons only allowed to the designated admin. Soldered USB drives and keyboards i.e. no chance of applying a keystroke logger or USB-anything. No 3rd party software of any kind on these machines. Minimum 25-character passwords, changed frequently, never written or stored anywhere.
5. Active Directory Backups: Stored encrypted in a physical bank vault, physical access to which requires the CISO to escort you to them. Only the CISO can get into bank vault.
6. An Educated Active Directory Admin Team: These aren't you ordinary admins. They know NEVER to logon to any system they do not OWN and CONTROL. They're also bound by a simple policy - you logon to any other system and you will be instantly terminated. Besides, Group Policy prevents them from logging on anywhere else.
7. Zero Services Using Domain Admin Creds: Not a single service in the enterprise uses Domain Admin creds, because if you know how to do security, you know that nothing strictly requires running as Domain Admin.
8. No DCs in the Cloud: Yes, you heard it right. I don't care how iron-clad the SLA is, we're not putting a single DC in the cloud with any provider yet. Not just yet. (More on that in days to come.)
9. Microsoft ATA: Microsoft ATA is NOT deployed just yet, because if you think about it, its still just some rudimentary technology acquired from a start-up, and rolled out in just months. Not sure how robust and reliable it is in code and its art to protect multi-$ Billion companies.
I could go on and on, but you get the drift. (BTW, if you want to make it harder, throw in 2-factor authentication, at least for all admin accounts at a minimum, and a bunch of other latest
Band-aids, none of which can stop a knowledgeable perpetrator.)
In such an environment, you might be able to compromise a domain-joined machine, but you're
likely not going to get anywhere close to getting Domain Admin type credentials, because a Domain Admin type account will NEVER logon to a system 0wned by an intruder, and the intruder will almost NEVER be able to logon to an admin workstation or on to a DC as admin.
Period.
In such a situation, I doubt an intruder's going to have a field day harvesting or reusing credentials to gain administrative access to Active Directory. In all likelihood, he/she'd sit and wait, and wait and wait, and wait, and grow old, and still not get anywhere.
 |
| Disgruntled intruder not getting any success with Mimikatz :-( |
Hmm.
Not a fun day with Mimikatz anymore, is it :-(
NOW, I'll be the first to admit that the environment described above is a rarity, but not an impossibility by any stretch. In fact, in time, the world will get there, and we already are there. For instance, our Active Directory environment is only about 50 times tighter than I have described above, so at least one such environment exists, and we operate it most easily. But in reality (, and 8,000+ organizations from 160+ countries have knocked at our doors, completely unsolicited of course, so) we know just how bad the situation is out there.
End of digression. Back on track...
Hmm. I wonder if there might be a way for an intruder to compromise a relatively more secure Active Directory environment, specifically, such as the one described above?
Well, it doesn't seem very likely, at least not using credential theft based attack vectors, since no Active Directory admins seem to want to give the bad guys even a chance at getting them.
Duh!
But wait, if this is all about Active Directory Security, then it doesn't take a brilliant mind to figure out the following - hey let me actually look INTO Active Directory, and I mean it literally! Look INTO it! -
 |
| Inside Active Directory |
Wow, now that I'm looking in, it is an ocean in there!
And since we're talking about
security here, perhaps its worth looking at something called an
Access Control List (ACL), you know, that little thing that protects each object in Active Directory, including every administrative account, administrative group, domain user account, domain computer account (and of course the domain controller's domain computer account), the domain root, AdminSDHolder, the System Container, the entire Configuration container, the Schema container, every GPO, etc. etc.-
 |
| Active Directory ACL on some random user, say an Alex Simon's domain user account. |
Hmm. I wonder why nobody has looked INTO the Active Directory that much? And by that, I don't mean looking at basic kid-stuff enumeration of accounts, groups, GPOs, DCs etc. I mean looking a little deeper, and a little more intelligently.
You know, like trying to figure out who can actually
reset a Domain Admin account's password, or who can
change the Domain Admins group membership, or perhaps who can
change the ACL on the AdminSDHolder object, etc. such as and/or
...
... speaking of say, Mimikatz, you know who can
modify the ACL protecting the Domain root to grant someone or themselves the
Get Replication Changes All extended right so they could replicate secrets (password hashes) out from Active Directory, or say, grant themselves
Full Control over the entire Active Directory domain. (You see, intelligent and (very)
powerful stuff.)
[Quick Digression -
Now, a novice might say - "You don't need an effective permissions tool to assess REPL perms on NC." Well, if no one has ever changed the ACL on the NC head, and you're just dealing with default permissions, then its his lucky day and a simple group enumeration should do it, BUT, if the permissions on the NC head have changed even once, and there's even ONE deny permission there (e.g. Deny All extended rights to Group X), well, then tough luck, because if you really want an accurate picture, you're going to have to determine effective permissions on the NC head ;-)"
End of Digression]
Hmm. I wonder. Let me see. Well, to begin with, what could I figure out by looking into these ACLs?
Not much,
other than exactly who has the keys to every door in the kingdom,
and the Keys to the Kingdom of course!
Hmm. Wonder how I do it? Yes, I know! I could use a tool like
dsacls from Microsoft or I could pick up several
amateur scripts from TechNet which claim to help find out who has what permissions -
 |
| dsacls |
But wait, I see
all kinds of permissions :-( > Allow permissions, Deny permissions, Explicit permissions, Inherited permissions, over a
dozen basic permissions,
five dozen plus special permissions (Extended rights), Validated writes, permissions with IO flags, etc. etc.
Whoa!
Where do I even begin?
And does "
who has what permissions" even equal "
who actually has what permissions"?
Well, maybe I should read
Microsoft's bible on all this Active Directory permissions stuff, and perhaps in a year or so, get my head around all this, and could possibly get somewhere. Perhaps, that's when I'll realize that what matters is who has what
effective permissions, not who has what permissions!
Oh wait, yes, I've seen an
Effective Permissions Tab in Active Directory Users and Computers, but I never did give it much thought! Hmm, its one out of four tabs in there, so it must be important -
Why don't I just use that to figure out who can do what within the Active Directory?
Sure, go ahead ... ...consider an environment consisting of thousands of users and you'll know why it is almost
virtually useless.
Oh, and if you come across
this, RUN, because its
dangerously inaccurate. Same is true for the advice on TechNet forums.
Well, perhaps, if I had something like
this, I could actually answer that question accurately and quickly -
Then ask yourself a simple question - what if I wanted to find out who can create a user account in Active Directory? Hmm - would I even know where to begin? Hey, this Active Directory has 100s of OUs, 100s of containers, etc. etc. - how many objects am I going to have to analyze effective access on to answer this one simple question. It'll be 100s if not 1000s.
Again, you could try for a year, or be
done in seconds ...
 |
| An Effective Privileged Access Audit in Active Directory |
But, you should absolutely try it yourself first, so you can get a sense of just how monumentally difficult it is do so.
I insist!
Years may go by, but you'll eventually gain the knowledge to comprehend the profoundness of
this,
this,
this and
this.
When you're there, please let me know, because then you too will have learnt how the (
really) smart guys
find ways to the
Keys to the Kingdom, or to
any door they want in to, in minutes, without having to wait for someone to logon to a machine you 0wn!
When you get there, please let me know...
... I'm already there.
Until then, I wish you well, and hope you continue to enjoy hashes and tickets! Oh, and if the intriguing world of Active Directory Security (which
literally lies within every Active Directory) has piqued your curiosity, here's some recommended
101 reading.
Personally though, as a fellow programmer who too has spent 1000s of hours on an ocean of technical detail that most would
never get into, my humble unsolicited advice to you would be to also enjoy
life because there's a lot more to it than just work. You've already proven how incredibly smart you are, and made a big (enough) difference, so thank you also for helping make Windows more secure for the world.
Sir, for your valued contributions to the field of cyber security, you have my respect, and that of the world.
I most sincerely wish you well.
Thank you.
Best wishes,
ST aka
TS.
PS: Some RESPECK for you in a simple ($100B) question posed to Alex Simons at Microsoft -
here
PS 2: For those who may be new to the subject, and wish to share your thoughts on Twitter-
here + Closure and Clarity -
here
PS 3: For those who may not yet understand the depth of what I just shared above, you may want to take a shot at answering any 1 of the 10 simple questions concerning Active Directory Security that I've posed to Sean Metcalf and Microsoft -
here
PS 4: October 21, 2016 Update - Defending Active Directory Against Cyber Attacks -
here
PS 5: May 22 2017: Taking Microsoft to Active Directory Security School -
here
PS 6: June 01, 2017: How Well Does Microsoft Really Understand Cyber Security -
here
PS 7:
July 25, 2017 Update: You'll want to
read this because its
paramount to security -
Active Directory Effective Permissions
