I'll keep this short. There were some interesting comments on Twitter, which are worthy of a (befitting) response, so here goes -
A. In response to - "If you really don't understand the purpose of mimikatz DCSync, don't write angry posts insulting the author."
Oh, I understand the purpose of ALL of mimikatz's features, not just DCSync, so don't assume that I don't. In fact, you'll want to tune in shortly (12 - 36 hours) for more on that feature, because I think the world needs some help dealing with it.
Most importantly, no one's angry and no one's insulting its author. In fact, I've not only praised him for his work, but referred to him as Sir. I doubt anyone else ex-Microsoft may have referred to him as Sir. I've also unequivocally stated - "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."
Finally, perhaps you didn't read the whole thing. I ended with - "Sir, for your valued contributions to the field of cyber security, you have my respect, and that of the world."
I just wanted to make a simple point, which was that when it comes to Active Directory Security, in a hardened environment, of which I had given a concrete example, wherein an intruder couldn't likely get to being a Domain Admin (or equivalent) using mimikatz, by simply possessing the ability to be able to accurately and quickly determine effective permissions in the ocean of ACLs within Active Directory, he/she (in the same hardened environment) could find 1000s of privilege escalation paths leading to virtually any IT resource. It was as simple as that! You may not get it now, but you eventually will.
B. In response to - "All his criticism of mimikatz could be directed right back at him."
Like I said, I didn't criticize mimikatz. I think mimikatz has done a lot to improve Windows Security for the world, and for that the world should be thankful to Mr. Delpy.
Further, the illustrative examples that we have provided are of how an intruder/perpetrator could exploit pervasive excessive access in Active Directory to exploit virtually any IT resource of choice, that is directly or indirectly protected by Active Directory i.e. any domain user account, any domain computer account (and thus any domain-joined computer), any IT resources that are stored on domain-joined computers, any domain security groups, as well as any IT resource protected by domain security groups. In other words, just about everything there is to protect in a Windows Server environment powered by Active Directory.
C. In response to - "His first attack is: an admin account that can create domain user accounts and gain "Authenticated Users" access. Uh ...ok"
Hey, when you're teaching someone how to do something difficult, you start with the easiest possible lesson. By the way, just to be clear, it's not attack, its "impact of compromise" which can be found here. You shared the first (simplest) one, but didn't care to mention the 9 others that followed?
For example, you didn't share the last one - "Impact of compromise of any account that can modify the security permissions on the AdminSDHolder object." Uh ...why?! It's impact is GAME OVER!
By the way, more on this below, in response to your follow-up comment.
D. In response to - "Its hard for me to imagine any plausible scenario where they wouldn't already have that access. And so it goes on."
Aha! Have you considered a scenario wherein access to a honey-pot server was being audited to lure and catch a perpetrator?
In such a scenario, assuming they suspected that John Doe's account had been compromised, if you were simply to use John Doe's account to access that honey-pot server, you'd show up on their radar immediately, and likely have someone knocking at your door very quickly. However, if you could create another account, say Jane Doe, then you could access the same server but the likelihood of your access being red-flagged would be much lower. That's just one scenario.
Here's another scenario. A disgruntled local IT admin would like to perform a network-wide scan to enumerate the list of all files and folders across the network. However he/she doesn't want to show up doing so on any radar. If he/she could create another identity (i.e. another domain user account), then he/she could perform the same scan using an alternate identity, which even if showed up on a radar, and was investigated, couldn't be traced back to him. That's another. (I could give you many more.)
So, just because something is hard for you to imagine, doesn't mean you slight it. Perhaps someone with a little more experience may have given it a little more thought prior to putting it out there.
E. Finally, (and this is my favorite one, so thank you for this) in response to - "I've been reading the whole site. Its just like he just discovered AD ACLs and now that is the "only thing in the world"
Actually I discovered AD ACLs in the year 2001. Perhaps you may have been in high-school then. I also wrote Microsoft's 400-page bible on the subject back in 2003, but nonetheless allow me to substantiate a trillion $ point -
 |
| An Active Directory ACL |
You may not realize it yet that although AD ACLs are not the "only thing in the world", they are very close to being the "most important thing in the cyber security world."
Since I'm not sure if you'll "get that", allow me substantiate it for you with some concrete examples -
1. Let's start with something right up your alley. With mimikatz DCSync, you could compromise an entire organization within minutes. However, if you merely tightened a single AD ACL, you could render the DCSync feature completely useless, thus eliminating a critical attack-vector to the security of that organization.
2. If you could change the ACL on AdminSDHolder object, you could instantly control every single administrative account and group in Active Directory.
3. If you could change a single ACL in the Configuration Partition, and you know what to change, you could disrupt the very operation of Active Directory, and possibly render it inoperable.
4. If you could change the ACL protecting the Domain Controllers OU, you could take over any Domain Controller within minutes.
5. If you could change the ACL protecting the domain root, it would be game over in 5 minutes.
6. If you could change the ACL protecting a security group that is being used to protect 1000s of IT resources, you could instantly and legitimately obtain access to the entirety of these resources.
I could go on and on, but hopefully you're smart enough to get the drift. Literally everything in an Active Directory deployment, from all Domain Controllers to all privileged access accounts, and from all employee accounts to all domain-joined hosts, is ultimately protected by an Active Directory ACL.
The world of AD ACLs and the ability to be able to precisely assess effective permissions on them is equally and likely far more important than the world of machine-based credential theft of accounts that may happen to logon to an 0wned machine.
By the way it is not the ACLs in themselves that matter, it is the vast universe of unauthorized effective access that they end up effectively granting to individuals that matters, and if you possess the ability to correctly determine effective access (effective permissions) based on these ACLs, you'll find 1000s of privilege escalation paths leading to just about everything within minutes in almost any Active Directory deployment in the world.
Now, as your acquaintance Sean Metcalf says, let's begin by assuming breach. Well, if you begin there, and you can do what I just shared with you above, you can likely own the kingdom within minutes, without having to compromise a single credential (hash/ticket).
Good night,
Sanjay
PS: I've said what I had to. In general, before you question what I'm saying, please consider where I came from. No more time to waste on this stuff. There's far more important stuff to talk about, right here on this blog, in the next few days.
