A Trillion $ Question to Microsoft regarding "Identities" and Cyber Security

Dear Microsoft,

Today is Day-11 of our advanced Active Directory Security School for you, and today I'd like to ask you a very simple question that concerns the most elemental and fundamental aspect of cyber security in Windows-based networks worldwide - Identities.

Identity is fundamental to Cyber Security

Identity is an elemental and fundamental aspect of cyber security, as each one of the 3-As of cyber security i.e. Authentication, Authorization and Auditing, require the ability to be able to uniquely identify entities i.e. people, computers, service accts etc.

The importance of identities is evidenced by that fact that an entire field of IT security is devoted to it, i.e. Identity Management, and that numerous multi-million $ companies such as Ping Identity, Centrify etc. exist only to help make identities more secure.

So, ...



Identities in Windows Environments

Now, as you know, at the foundation of over 90% of all business and government organizations worldwide lies Active Directory, and in these organizations, the Identities of their employees, contractors, executives, privileged users and other stakeholders are all represented by ...

A Domain User Account in Active Directory

... none other than their  unique  Active Directory domain user accounts !

(For completeness, it must be mentioned that computers have identities too represented by their domain computer accounts, and that strictly/technically speaking, it is a domain account's Security Identifier (i.e. SID) that uniquely represents its identity.)


That's right. In Active Directory based IT infrastructures, it is domain (i.e. Active Directory) accounts that represent identities.

In fact, at thousands of organizations worldwide, it is Active Directory domain user accounts that represent corporate identities, and in Active Directory deployments worldwide, today hundreds of millions of identities are represented by these accounts.





Uniqueness Is Imperative

Now, of vital note here is that, as you know, the keyword above is unique, because the entire premise of cyber security in Active Directory based networks rests on each user having a single, irrefutably uniquely identifiable domain user account!

After all, you likely don't have two domain user accounts at Microsoft for say, Satya Nadella, right? Yes I know that to address certain needs, some users like privileged users have multiple (e.g. alt) accounts, but they are always explicitly labeled as such.

In fact, here's why it is so important that users have only (one identity, i.e.) one domain user account -

1. Security - Uniqueness is required to eliminate ambiguity. Ensuring secure access to securable resources in a network requires that resource owners be able to uniquely identify the entities/individuals for whom access is to be specified.


2. Accountability - Accountability necessitates uniqueness. Should a user be able to authenticate him/herself using an account other than one assigned to him/her, he/she could engage in malicious activity, such as obtaining unauthorized access to, divulging and/or destroying various IT resources, that could not be irrefutably tied/traced back to him/her.

In fact, ensuring security requires that, ideally speaking, no user (except for a known few explicitly authorized administrative personnel) must ever be in a position that provides him/her access to more than one uniquely authenticatable domain account.

Now there are generally only two ways in which one could obtain access to an additional account - 1) a user could create a new domain user account in Active Directory, or 2) a user could reset the password of an existing domain user account in Active Directory. For now, let's assume that the second way is not that important (although it is), and lets just focus on the first one.

It turns out that the seemingly simple and mundane task of being able to create domain user accounts in Active Directory is actually very important to cyber security, because, as explained above, if someone could create a domain user account in Active Directory, he/she could instantly obtain and be in possession of an additional, separate uniquely authenticable identity.

Incidentally, the very least one could do with an additional domain user account is use it to scour the entire IT network for vulnerabilities, perform network logons on to most computers, and access anything and everything (e.g. files on servers, databases, SharePoint portals, ) to which Domain Users and Authenticated Users have read access (and you would be surprised to know as to just how much these two well-knowns (-RID and -SID) have access to in most organizations today.)

Of course, a proficient individual (intruder/perpetrator) could use an alternate domain account to engage in all sorts of nefarious activities, and the smartest ones could possibly find and exploit privilege escalation paths to take over the entire network.

In fact, if you consider even just the recent critical vulnerability that you just patched i.e. CVE-2017-8563 (Windows Elevation of Privilege), note that its exploit vector too involved/required that the perpetrator create a domain user account in Active Directory!





A Simple Trillion Dollar Question -

So, in light of the above, as you'll hopefully agree, it is absolutely imperative that organizations know at all times as to exactly who can create new identities in their environment, i.e. who can create new domain user accounts in their Active Directory?!

So, and speaking of which, here's yet another a very simple Trillion dollar question for you, Microsoft -

Exactly how do/should organizations find out exactly who can create domain user accounts in their Active Directory? (and ideally also, where they can do so & how)

[ My apologies for harping on "exactly" ; it is just that when it comes to cyber security, accuracy is paramount. ] 

Make no mistake about it - organizations that do not know the answer to this most fundamental of cyber security questions concerning identity management in Windows based networks cannot be considered secure from a cyber perspective.


Now, in case this seems like a simple question, consider what it might take to accurately answer this question at an organization that may have numerous (say even 20+, if not 100s of) organizational units and containers in their Active Directory domain(s).

Here's a hint - In all likelihood, even you*, the $ 550+ Billion Microsoft, that may be spending billions to so convince the world to get on its recent Cloud offering, don't possess the ability to help organizations answer this simplest of cyber security questions.

(In light of which, this might now 

make sense, esp. paragraph 7.)

I, and the whole world, look forward to your answer.  (Also, since you're likely not going to answer it, I'll answer it on Day-12.)

Best wishes,
Sanjay


* Not just you, not a single one of dozens of multi-million/billion $ IT, cyber security, tech and defense companies focused on identity management and cyber security can help organizations answer this simple cyber security question. Well, except one.

PS: August 05, 2017 Update - I've answered the question here.

Understanding Windows Elevation of Privilege Vulnerability (CVE-2017-8563, LDAP & NTLM) + Helping Preempt With Active Directory Security

Folks,

This is VERY important, so you'll want to read it. It concerns a zero-day vulnerability in Windows brought to Microsoft's attention by a company called Preempt, that exploits a weakness in LDAP-S involving NTLM, which could result in elevation of privilege.

[ By the way, it's only Wednesday and its already been a busy week - I was going to pen Day-10 of our Active Directory Security school for Microsoft on Sunday night, but instead had to pen a letter to President Trump in light of his tweet. Then I was going to pen it yesterday, but in light of this vulnerability, I had to pen this to help everyone easily understand this, and to help Preempt. ]




A Short Summary of This Vulnerability

Folks, in the interest of everyone's time, I'm not going to repeat all the details in-depth. You can find them here, here and here.

In short, there exists a vulnerability in LDAP-S that permits the enactment of an NTLM relay attack, and in effect could allow an individual to effectively impersonate a(n already) privileged user and enact certain LDAP operations to gain privileged access.

Very Important: The term "privileged user" is often loosely used and misconstrued, so its imperative to understand that here a privileged user refers to any domain user account that has privileged access in Active Directory.

The simple, key thing to understand here is that since the vulnerability exists in Microsoft's implementation of LDAP-S, LDAP being the protocol used to access and manage Active Directory content, its primary target ends up being Active Directory content, and since it involves exposure to NTLM relay attacks, Active Directory privileged users are prime victim candidates.

To describe this simply, if a user that possesses privileged access in Active Directory authenticates using NTLM to a machine owned by a perpetrator, the perpetrator could exploit this vulnerability in LDAP-S to enact an NTLM relay attack in which he/she would impersonate the privileged user('s account) to Active Directory, then just enact a few LDAP operations in that privileged user's security context to obtain a separate authenticable account that would now possess privileged access in Active Directory.




A Simple Example

Here's an example. Imagine that you are a Domain Admin, so obviously to begin with you have God-like powers within Active Directory itself (and by extension everywhere, but that's not important here), and so of course you can do things like create new user accounts in Active Directory, modify group memberships including those of privileged groups such as Domain Admins.

Now, lets assume you're logged in using our Domain Admin account and you happen to access a Share point portal that resides on a machine owned by the perpetrator (think intruder.) In that simple act, if the machine could have the authentication involved be downgraded to NTLM, then...

• Firstly, that very moment, malicious code running on that machine would attempt to and successfully impersonate you to a Domain Controller, thus ending up having a network logon session as you on a Domain Controller, & then ...
• Secondly, since it now has successfully authenticated to a Domain Controller as you, it could now enact a simple LDAP operation (create object) to create a new user account with a password of the perpetrator's choice, followed by another simple LDAP operation (modify object) to add that newly created account to the Domain Admins group.

That's it! All of this would happen very quickly (almost instantaneously) and so transparently to you that you wouldn't even notice, and within seconds the perpetrator would now have a new user account that also has Domain Admin privileges!




A Small Suggestion (and Active Directory Security 102) For Preempt

I'm sure we are all thankful to Preempt for discovering this vulnerability and bringing it to Microsoft's attention, which led to Microsoft releasing a patch for it today. That said I do have some helpful reading and a small suggestion for Preempt -

Here's how Preempt describes the potential impact of this risk (source) -

"As a result, every connection of an infected machine (SMB, WMI, SQL, HTTP) with a domain admin would result in the attacker creating a domain admin account and getting full control over the attacked network."

My suggestion to them would be to perhaps consider making the following modification to their description -

"As a result, every connection of an infected machine (SMB, WMI, SQL, HTTP) with any domain user account that has sufficient privileged access (i.e. Active Directory effective permissions) to enact any one the following tasks (all of which merely involve LDAP operations) in Active Directory could result in the attacker potentially obtaining full control over the attacked network."

1. Use Mimikatz DCSync to replicate secrets from Active Directory
2. Modify permissions in the ACL protecting the Domain root object
3. Reset the password of any one Active Directory privileged user account
4. Modify the membership of any one Active Directory privileged group
5. Modify permissions in the ACL protecting the AdminSDHolder object's ACL
6. Modify gpLink and gpOptions attributes on the default Domain Controllers OU
7. Modify critical Active Directory configuration content or the Schema
8. Establish an incoming forest trust or an external trust with domain

+


9. Create a user account (; this is optional AND it is only required if the perpetrator does not already have either his/her own or control over someone else's domain user account)

Here's why. To exploit this vulnerability and gain full control over the network, you don't need to be a Domain Admin. You only need sufficient privileges (i.e. effective permissions / effective access) in Active Directory to enact any one of the above tasks.

In the foundational Active Directory deployments of most organizations, you'll find that there are many many more accounts that can actually enact any, some or all of the admin tasks (i.e. LDAP operations) listed above than the number of Domain Admins!

Hopefully you can now see why it is so vital to know at all times, exactly who can enact each of these tasks in Active Directory.




How to Mitigate This Vulnerability

To mitigate this vulnerability, ensure that all systems are patched and up to date as of July 11, 2017. Specifically, you'll want to ensure that the update for CVE-2017-8563 is installed. In addition, to make LDAP authentication over SSL/TLS more secure, admins will need to create a LdapEnforceChannelBinding registry setting on a Domain Controller (; Microsoft KB 4034879.)



A Few Interesting Observations

Before I conclude this post, I'd like to share a few observations that I think you'll find interesting -

1. Is it just me, or do you too find it so very interesting that this is the second time that a major vulnerability in Windows authentication protocols has been found by a company in the business of building behavioral firewalls?! I suppose they need to find such smoking guns to validate the need for their products, and they seem go to great lengths to do so.


2. I care deeply for Microsoft, but I'll say this again - how come start-ups funded to the tune of a few million $ can find such vulnerabilities in Windows, whereas a $ 550 Billion behemoth (Microsoft) is not able to find them on its own?


3. What is going to take to make organizations and vendors realize that Domain Admins are merely the Tip of the Iceberg? There are so many more accounts that also posses a substantial amount of excessive privilege in Active Directory?


4. Why can't organizations accomplish something as simple as a) minimizing the number of privileged users in their Active Directory and b) creating and enforcing a simple policy that such users are only to logon to admin workstations and DCs?


5. In light of this and this, how can organizations not yet know how to correctly audit privileged access in Active Directory?

That's it for today.

Best wishes,
Sanjay.