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

Wednesday, July 27, 2016

A Simple $100B Active Directory Security Question for Alex Simons at Microsoft

Dear Mr. Simons,

I believe you are the Active Directory Czar at Microsoft these days, so I have a simple but very important question for you.

Incidentally, do you know who came up with that ludicrous title, Czar? (By the way, that's not the question I wanted to ask.)

The Question -

With the introduction of the DCSync feature in Mimikatz, the security of an entire Active Directory deployment boils down to this:
Anyone who effectively has the Get Replication Changes All extended right granted to them in the access control list (ACL) protecting the domain root object can now easily compromise the credentials of all Active Directory domain accounts, including those of all Active Directory privileged user accounts!
Although by default, only administrative personnel have this right effectively granted, since most Active Directory deployments have been around for many years, in almost all of them, the ACL protecting the domain root may have been modified several times, and as a consequence the default access may have changed substantially, resulting in a situation wherein no one may really know exactly who effectively has the Get Replication Changes All extended right granted to whom today.

Thus today it is imperative and in fact paramount for every organization in the world to know exactly who effectively has the Get Replication Changes All extended right granted in the ACL of their domain root object, and how they have it. (The need to know how is essential for being able to lock-down access for all those who currently have this critical access, but should not have it.)

So the simple $100B question is -
"Precisely what does Microsoft recommend that customers do to make this paramount determination in their foundational Active Directory deployments?"  i.e. how do they find out exactly who effectively has the Get Replication Changes All extended right granted in the ACL of their domain root object, and how they have it?

Microsoft may or may not realize this but thanks to the technical brilliance of a certain Mr. Benjamin Delpy, this is the 2nd most important Active Directory Security question facing organizations worldwide today. (In a few days, I'll let you know the 1st one.)

I (and the world) look forward to your answer.  (We hope you have one.)

Most respectfully,

PS 1: I imagine it shouldn't be too hard for the $450 Billion Microsoft to answer this simple question.

PS 2: Here's some Q&A that I can envisage happening, between Microsoft and its customers -
Answer: We recommend that organizations use the Effective Permissions Tab provided in our native Active Directory management tools, or our acldiag tool, to find out exactly who effectively has this right granted.

Follow-up Question (from customers): Thank you. We tried that recommendation. These tools don't seem to be very accurate and it appears can only determine effective permissions one user at a time. We have 1000s of users in our Active Directory. Do you expect our IT personnel to enter 1000s of names one-by-one manually?!
Answer: <Silence>

Follow-up Question 2 (from customers) a few weeks later: We (somehow) were able to figure out the identities of everyone who has this right effectively granted in the ACL of the domain root object. Its a long list i.e. much longer than it should be. We need to lock-down it down. Can you recommend how we could go about locking it down?
Answer: We recommend that organizations determine how these individuals have this right effectively granted to them, then use that information to tweak the underlying security permissions or modify involved security groups.

Follow-up Question 2 (from customers): Okay, but how do we determine how these individuals have this right effectively granted to them?
Answer: <Silence>

PS 3:  I sincerely hope your answer isn't one of the following, including why (because there is an easy answer to this question) -
Poor Answer 1: "We recommend that our customers use Microsoft ATA to monitor such activity.
Reason: Microsoft ATA is basically a detection measure. In the list of protection measures, detection comes third. The first is prevention, the second is avoidance. By suggesting detection, you're conceding that you don't have the ability to provide the first two measures. And the world expects better than that from a $450 Billion company. 

Poor Answer 2: "We encourage our customers to transition to Microsoft Azure.
Reason: It seems like Microsoft will do almost anything (including conceding defeat) to get their customers on its Cloud. I hope you realize that the degree to which you can help protect customers that are not in the Cloud, and the thought leadership (or lack thereof) Microsoft may have displayed thus far in cyber security, are a few factors that organizations consider when deciding on whether or not to bet (the security of) their business on your Cloud.  
(Besides, thousands of organizations still run Active Directory on-premises and may not want to get on the Cloud. As such, billions have been spent worldwide integrating so many applications with Active Directory and its ACLs.)

PS 4:  If you're wondering who I am, just ask Microsoft's top cyber security brass. (I'm a former blue-badger who cares deeply about the foundational cyber security of Microsoft's ecosystem.) If you're wondering why I am asking this question publicly, its because its 2016, not 2006, and we the world simply cannot afford to not have adequate solutions to address such fundamental cyber security challenges. Today foundational cyber security is a matter of paramount defenses. Before you respond, kindly also do consider a what-if scenario wherein such critical cyber security challenges, and the threats they pose, would still exist, but adequate solutions to address them did not. (Fortunately, they do exist today, and they are paramount to global security.)

PS 5:  August 01, 2016 update: Here's the answer to this question, and here's some valuable security guidance for Microsoft.

Tuesday, July 26, 2016

The Importance of Active Directory Security: It Impacts Global Security


Today, as the very foundation of identity, security and access management at 90% of business and government organizations worldwide, Microsoft Active Directory is the very foundation of cyber security worldwide. Today, it helps protect Trillions.

To understand how this relates to all of us, perhaps it may help to internalize that at the very foundation of cyber security of virtually every organization that directly impacts billions of people worldwide, from our employers to our financial institutions, from the companies we invest in to our governments, from our educational institutions to our hospitals, from companies that build and sell all that the world needs to companies that provide the world's utilities (energy, transportation, security etc.) lies Microsoft Active Directory.

The security of Active Directory deployments worldwide is thus critical to global security and a matter of paramount defenses.

Unfortunately, the executive and IT leadership of most organizations do not seem to clearly understand this profound fact yet, so a few weeks ago we directly brought this fact to the attention of the executive leaders of the world's Top-100 companies. In weeks to follow, we learnt just how little organizations worldwide know about the top cyber security risks to Active Directory.

It appears that in part, at the root of global lack of gravitas on this most important subject, and the lack of adequate awareness, guidance and solutions on/for Active Directory security, may lie the lack of gravitas of one particular organization, so, starting tomorrow, July 27, 2016, and in days to follow, we will ask a few questions and share a few insights right here on this blog.

Best wishes,

PS: I'll ask a $100B question tomorrow. Technically, given the above, it could be a Trillion $ question, but we'll leave it at 100B.

Monday, July 25, 2016

Clarity and Closure (re comments on Twitter)


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,

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.

Friday, July 22, 2016

Clarity for Self-Proclaimed Cyber Security Experts who Churp on Twitter


When someone doesn't know or understand something, often their first reaction is to make fun of it. Sadly, these days, to their own detriment, they do so publicly on social media. Little do they realize that everything they utter can be seen by the whole world, and by sharing their ignorance on social media with the world, they show the whole world how little they actually know.

For example, consider this individual. Perhaps he knows just enough English to see our homepage, but not to be able to go beyond it, to say this one, or this one, so he publicly and slightingly wonders who we are and asks if anyone's heard of us. I wonder if it might have ever occurred to this individual that perhaps our low-profile until now, may have been by intent. For this individual, and anyone else on Twitter etc., if you want to know who we are, please call Scott Charney at Microsoft.

One of Many Examples

Or for example, this individual, who said regarding Active Directory Privilege Escalation - "That's it? Make sure your delegation is tight big deal."
Wow. Great advice!  Since you make it sound so simple, now why don't you (i.e. this individual) also tell them (i.e. the world) HOW to do so i.e. how to tighten their delegation(s) in their Active Directory domains easily comprised of 1000s of objects?!

You see, this individual likely has no idea HOW to actually do so. If he did, he'd know just how extremely difficult it is to do so, and I doubt would've said - "no big deal!" In fact, I wonder if he even knows that because it is so difficult to do so, hardly any organization in the world (including his past employers, or Microsoft for that matter) may have ever actually accurately done it?

So let me give him, his friends, and the whole world a hint - the very first thing you need to do to tighten your delegation(s) is to assess your current delegations across Active Directory, and to do so you need to be able to determine effective privileged access across the entire Active Directory domain, i.e. on thousands of objects in Active Directory, accurately.

Even the $450 Billion Microsoft Corporation may not know how to do this. But for this individual, its "no big deal."

If he knew this, I'm not sure he might have publicly said - "no big deal!"

In fact, if he, or anyone in the world, can accurately determine effective permissions / effective access across an Active Directory domain, please go ahead, show us and the entire world how you would do so. Please. Be my guest. I insist!

Unequivocal Clarity

For anyone on Twitter who wishes to slight us without substance, let's just make this really simple for you once and for all.

Please know that if you slight us, and there's no substance to it, we too MAY share your ignorance with the WHOLE world.

By the way, if you haven't heard about us yet, its only because for the longest time, we kept a low-profile. Please know that in the last 10 years, 10,000+ organizations from 150+ countries have knocked at our doors, unsolicited, and know who we are. Today our reach is global, and in minutes, we too can have 1000s of folks across 150+ countries learn about you ignorance.

So, to the 1% who may do so, if there's no substance, please don't embarrass yourself by making childish comments. (It's a free world and you're welcome to, but know that the whole world's watching, and they'll know just how much (or little) you know.)

Talk is cheap, actions are not.

Best wishes,

PS: It would be refreshing to actually see someone say something intelligent on the subject. Unfortunately, I've only heard noise. No matter how much, noise is just noise. My time is valuable so I'll tune back in when I've heard something intelligent. Perhaps its time to stop talking for a bit and start reading.

Friday, July 15, 2016

A Letter to Benjamin Delpy regarding Mimikatz & Active Directory Security

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.


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 -


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 -

PS2: For those who may be new to the subject, and may wish to share your thoughts on Twitter-

PS3 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 -

PS4: Closure and Clarity.

PS5: October 21, 2016 Update - Defending Active Directory Against CyberAttacks

Thursday, July 7, 2016



As I have said, starting July 04th 11th, 2016, I'm going to start addressing vital matters of global cyber security.

Today, I just wanted share a picture with you, because as they, "A picture is worth a 1000 words" -

Password Reset Analysis on a random user, say Satya Nadella.

Well, this one's worth a proverbial $ Billion. (You may not yet understand why I say so, but in days to come, you will.)

Stay tuned...

Best wishes,

PS: Today's post was on an Active Directory extended right called Reset Password, the CN for which is User-Force-Change-Password and its Rights-GUID is 00299570-246d-11d0-a768-00aa006e0529. To some its just an extended right, to others it could be the key(s) to the Kingdom.

PS2: If you know how to press a mouse button, and want to know who can reset your password today, or that of any colleague (such as a Domain Admin or your CEO), you can now do so, our compliments (i.e. free), using this tool. On that note, the astute mind will also profoundly appreciate the importance and value of this.

Monday, July 4, 2016

Its Almost Time


Due to certain recent global events, it appears I'm going to have to postpone sharing what I had in mind, by about a week.
I apologize for the slight delay... we'll start on July 11, 2016.


Saturday, July 2, 2016

Kerberos Token Bloat, MaxTokenSize and Tokensz


Starting July 04, 2016, we're going to start addressing certain matters of cyber security that today have a global impact on the security of a majority of business and government organizations worldwide.

Until then, over the next few days, I just wanted to very briefly cover a few technical aspects.

Kerberos Token Bloat

Today, I wanted to briefly talk about Kerberos Token Bloat, a decade old system technical limitation based issue that continues to linger and distract Microsoft's business and government customers from substantially more important cyber security issues.

[ Begin digression...

By the way, In case you're wondering why this topic merited a mention on a blog to do with Cyber Security, its because not many non-IT folks know that this very topic impacts the cyber security of 85% of all organizations worldwide, and that 1000s of organizations today still struggle to address it.

It is only when they can move on from such basic issues that they can even begin to think about addressing far more important cyber security challenges. Until then, they remain vulnerable, and we remain worried.

...end digression. ]

Speaking of Kerberos Token Bloat, here's a simply picture that conveys its impact -

Kerberos Token Bloat

Given the paucity of time, in this blog entry I'm not going to expound upon the issue of Kerberos Token Bloat, as I've already described it, and 3 helpful tools/scripts in substantial detail over here.

The first time I spent some time on it was way back in 2002 during my Microsoft years.

The short of it is that Kerberos Token Bloat is an issue that can result in users being denied access to corporate systems (i.e. a Windows logon) simply by virtue of the fact that they belong to a large (enough)  number of Active Directory security groups.

For example, consider a random user, say Satya Nadella. When he uses his Active Directory domain user account, such as corp\snadella to logon to his domain-joined Windows Surface device, he could be denied access to the system (i.e. denied a logon) if he is a member of a large enough number of domain security groups.

Logon Denied due to Kerberos Token Bloat

In case the snapshot above isn't clear, here's the message he'll see -
Logon Message
The system cannot log you on due to the following error: 
During a logon attempt, the user's security context accumulated too many security IDs.
Please try again or consult your system administrator.

In many medium and large sized organizations worldwide, this can easily be a major and unwelcome IT problem because many users could be in a situation wherein over the years they been made members of a large number of security groups, and thus potentially run the risk of being denied a logon if their group membership count were to continue to increase.

Domain Admin

To minimize the possibility of users being denied access to the system, IT personnel try to proactively determine Kerberos token sizes of their users, so that they can identify at-risk users and enact adequate mitigation measures.

Over the years, Microsoft has issued guidance, introduced basic tooling, made some enhancements and even made it easier to estimate Kerberos token sizes (via auditing). Still, organizations continue to search for tooling to help them easily determine Kerberos token sizes for all their users, and this problem continues to be unaddressed at so many organizations worldwide.

Its High Time

This issue's been around for over a decade now, and you'd think that by now most organizations would have it under control. After all, there are far greater cyber security challenges (that may very well be in their blind spot) as illustrated here that these organizations need to be addressing today. After all, its 2016, not 2006.

Yet, we find that to this day, every week, IT personnel from so many prominent organizations in the world still continue to search for tooling that can help them estimate Kerberos Token Sizes for all their users. We're not about to disclose their names, but if you too knew, you'd possibly fall of your chair.

Click, Done. (Can we please move on now?)

In the interest of organizations worldwide that are potentially impacted by Kerberos Token Bloat, we'd like to humbly suggest that these organizations kindly address this issue once and for all, and then move beyond it, so that they can address issues that today pose a far greater cyber security threat to them, than the (relatively petty and puny) issue of Kerberos Token Bloat.

Incidentally, here are some terms that IT personnel from these organizations continue to extensively search for in their quest to address this problem - tokenszKerberos Token Size Tool, maxTokenSize, CheckMaxTokenSize, Get-TokenSizeReport, tokensz for another user, whoami for another user, TokenSize = 1200 + 40d+ 8s, Warning events for large Kerberos tickets, etc.

So that organizations need not waste anymore precious time trying to dabble with insufficient tooling, half-baked inaccurate solutions or unreliable amateur scripts, we built the world's only professional-grade Kerberos Token Size Tool for them -

Fully-automated, multiple-user Kerberos Token Size Calculator

In essence, with our tooling, if you know how to click a mouse button, you can now instantly and automatically determine the Kerberos token-size of every domain user account in your domain, within hours. By the way, that's only about 1% of what we do, and we only built this because we had a very prominent Swiss Bank request us to build this for them. (More on it here.)

An Associated Denial-of-Service Attack (Just Waiting to Happen)

For most organizations, the scenario of primary concern and the one they wish to address and avoid is one wherein a user ends up being a member of a large enough number of groups, and eventually is unable to logon.

Unfortunately, in most organizations, a malicious perpetrator could actually exploit this very issue to launch a organization-wide denial-of-service attack wherein come Monday morning 9:00 am, no one (including IT personnel) is able to logon, and you have a situation where business comes to a halt.

You can imagine the potential hourly cost to an organization when its business comes to a halt.

When 10,000 employees can't logon, every minute matters, and costs a lot.

So, just how easy is it for a skilled malicious perpetrator to launch a Kerberos Token Bloat based denial-of-service attack?

Turns out, its not difficult at all.

To do so, all the malicious perpetrator would have to do is create a large enough number of security groups in Active Directory, make one a member of just one more group (about 1015 times), and then add a group like Domain Users to the last group (or say in a targeted attack, add a group such as "Executive Users".)

Some might suggest out that Active Directory quotas could help prevent this situation. To which, the response would simply be, that coupled with the ability to create just a few domain user accounts, even quotas could be easily bypassed.

Further and actually, the malicious perpetrator need not even possess sufficient effective permissions in Active Directory to be able to create a large number of security groups; if he/she simply had sufficient effective permissions to be able to modify the membership of a sufficient number of existing domain security groups in Active Directory, he/she could use the power of scripting to accomplish the same objective within minutes.

It also pays to keep in mind that unlike ordinary users, a skilled malicious perpetrator would typically use automation (e.g. scripting) to accomplish his/her objectives, and thus could make his/her move very quickly. (A decently skilled perpetrator could accomplish this feat within a matter of minutes.)

Thus, at the very least, to mitigate the risk posed by a Kerberos Token Bloat based denial-of-service attack, today, all organizations operating on Active Directory should ideally, at a bare minimum, be able to answer the following questions -
1. Exactly who can create security groups in our Active Directory?
2. Exactly who can modify the membership of all existing security groups in our Active Directory?
3. Exactly who can create domain user accounts in our Active Directory?
4. Exactly who can modify the default quota settings in our Active Directory?

Incidentally, it used to be that you'd have to be an Active Directory rocket scientist to answer these fundamental questions. Thankfully, today, man has finally landed on this moon too, and such questions can now be answered at the touch of a button.

Today, ideally, every organization operating on Active Directory should, at a minimum, be able to answer each of the following elemental cyber security related privileged user access questions listed in this document.

Alright, time almost up so this will have to end soon.

In Summary

Kerberos Token Bloat is a decade old issue that most organizations should already have dealt with. Unfortunately, to this day, thousands of prominent organizations worldwide still continue to search for basic tooling in their attempts to deal with it.

I suggest they quickly identify at-risk accounts, take adequate mitigation measures, and, at a bare minimum, answer the 4 questions enumerated above, then swiftly shift and elevate their focus on substantially far greater cyber security issues, the business impact of which is described here.

More on which in days to come.


PS: If you found this interesting, you might like reading this too - Our Trillion $ Insight on the OPM Breach