Today Active Directory Security is mission-critical to organizational security worldwide and thus mission-critical to Cyber Security worldwide. On this blog, former Microsoft Program Manager for Active Directory Security, and today, CEO of Paramount Defenses, shares valuable technical insights on Active Directory Security.


Tuesday, September 19, 2017

The Security Implications of an Unauthorized Change to Domain Computer Accounts in Active Directory + How to Audit Who Can Make Such Changes


Dear Microsoft,

Today is Day 19 of our Active Directory Security School for you. Today, we shall cover another subtle yet important aspect of Active Directory Security; today we will talk about the thousands of domain computer accounts that exist in Active Directory.



Quick Background

Active Directory is the bedrock of cyber security in a Microsoft Windows Server based IT infrastructure, because it enables and facilitates secure (i.e. authenticated, authorized and auditable) access to securable IT resources in a Windows Server network.


In an Active Directory based IT infrastructure, users that have domain user accounts can logon to any domain-joined machine and seamlessly obtain secure (i.e. authenticated, authorized and auditable) access to various IT resources, whether it be e-mail (hosted by Exchange), files (that reside on a shared folder) on a domain-joined machine, applications (that may be running on a domain-joined server), a SharePoint portal, an Intranet site (hosted on one or more domain-joined machines) or VPN, RAS and Internet access. In addition, 3rd party apps also make it possible to extend this single-sign on experience to *nix & Mac clients.

This seamless, secure single-sign on experience that users in an Active Directory environment enjoy is primarily made possible by (Microsoft's implementation of) Kerberos, which, in turn relies on a web of trust that is weaved by the individual (and implicit) trust relationships that exist between Active Directory and each domain-joined machine on which IT securable resources reside.

In particular, it is the act of joining a machine to a domain that results in the creation of both, a unique authenticatable Kerberos security principal to represent that domain computer account, as well as its trust relationship with Active Directory, and together they enable seamless secure access to securable resources that reside on and/or are hosted on that domain-joined machine.

In short, it is the implicit trust relationships and thus the secure trust channel that exists between the Active Directory ((K)DCs) and each domain-joined machine that make the seamless, secure single-sign on experience possible in Windows networks.

(The above is a most HIGHLY simplified overview of how distributed secure access works in Active Directory environments. While one could write an entire book on it, I'll assume you know this, and have only mentioned the above to lay a foundation.)




Domain Computer Accounts in Active Directory

That said, and consequently, just like there exist domain user accounts to represent an organization's various users, similarly, there exist domain computers accounts in Active Directory to represent the organization's various domain-joined machines -

A Domain Computer Account in Active Directory


In fact, when a machine is joined to the domain, a domain computer account is created for it in the default Computers container. These computer accounts can be subsequently moved to other containers or Organizational Units (OUs). Even DCs in Active Directory have their own unique domain computer accounts, which reside in the default Domain Controllers OU.

Further, just like domain user accounts, domain computer accounts too are uniquely authenticatable security principals, and in fact they too are protected with a secret (a password) that is known only to themselves and to the Active Directory, and they too can be granted access to securable IT resources, as well as be made members of domain security groups in Active Directory.

In fact, a service running as System* on a domain-joined machine authenticates itself across the network as that computer's domain computer account, and just like domain user accounts having user principal names (UPNs), domain computer accounts have service principal names (SPNs), which of course silently and implicitly play a prominent role in Kerberos authentication.

Further, akin to domain user accounts, there are many properties/attributes on domain computer accounts as well, such as userAccountControl, servicePrincipalName, samAccountName, dNSHostName etc. and they play a vital role in security -

Attributes on a Domain Controller's Computer Account

Consequently, it goes without saying that the unauthorized modification of any one of these properties/attributes on a domain-joined machine's domain computer account could negatively impact organizational security in various ways.






Security Implications of an Unauthorized Change to a Domain Computer Account

As mentioned above, an unauthorized modification/change of/to any one of various properties/attributes on a domain-joined machine's domain computer account could potentially negatively impact organizational security in various ways.

For instance, consider the impact that an intruder could have if/she could modify the properties of a domain computer account that he/she has compromised (i.e. has control over), such that it would now be trusted for unconstrained delegation. (So as not to tip amateurs off, I'm not going to S P E L L  O U T the ramifications of such an action, even though experts know them well.)

Similarly, consider the impact that an intruder could have if/she could modify the servicePrincipalName attribute on the domain computer account of even a single Domain Controller. (Again, I am not going to spell out its serious security ramifications here.)

Modifying the servicePrincipalName attribute on a domain computer account

After all, there's a reason that there is a special Active Directory security permission, specifically one of two Validated Writes, Validate Write to Service Principal Name to control who can modify the Service Principal Name of a domain-joined computer.

In my previous posts, I have elaborated sufficiently on the potential negative security impact of someone being able to enact an unauthorized task/action in Active Directory, such as here, here, here, here and here, but in this case, I'm not going to do so, because I would like Microsoft to educate its customers about the same, so I'd recommend contacting your Microsoft rep and asking him to help you get sufficient clarity on the ramifications of someone being able to do so.


In fact, it is not just the unauthorized modification of properties/attributes on a domain computer account that could potentially negatively impact organizational security in a substantial way, but also the unauthorized ability to change the security permissions on, or take ownership of the domain computer account that too could have a substantial impact.






Microsoft, A Question for You

Microsoft, if the unauthorized modification of a domain computer account's attributes/properties can have a substantial impact on organizational security, shouldn't organizations be in a position to AT A MINIMUM answer the following question(s) -
Question: Who can change the sensitive attributes/properties of a domain computer account in  Active Directory ?

In fact, here are at least three other specific questions that must ideally have answers to -
  1. Who can modify the ACL/permissions protecting a domain computer account? 
  2. Who can modify the owner of a domain computer account?
  3. Who can delete a domain computer account?   

Microsoft, can you please at least tell the entire world (i.e. your customers) how they can correctly answer these questions?






How to Correctly Audit Who can Make Changes to Domain Computer Accounts

Microsoft, ordinarily, I would've ended this post here, and answered the question tomorrow in a follow-up post. However, since we only have 10 days of school left, and there's SO much more to cover (most of which you're going to love, appreciate and be so thankful for,) I don't want to use an entire day's lesson to answer this question, so I'm going to answer it right here for you.


As always, first the incorrect answer - "Find out / audit who has what permissions on a domain computer account."

Running acldiag on a Domain Controller's domain computer account

Many folks will tell you that this is all you need to do, and you can easily do so using tools like dsacls or acldiag or that you can write PowerShell scripts to do so, or use any one of several 3rd party Active Directory Permissions Audit Tools to do so.


By the way, the reason I provide and harp on the incorrect answer is that to this day, i.e. even 17 years after Active Directory was shipped, 1000s of organizations still continue to engage in this incorrect process to answer these and similar questions.


Now, the correct answer - "Find out / audit who has what effective permissions on a domain computer account."


The Incorrect Microsoft Effective Permissions Tab

As we can all see above, effective permissions are so important that Microsoft's native tooling has an entire tab for them!

Now, before you assume that the Effective Permissions Tab is sufficient/adequate to answer these questions and stop reading this further, let me share with the three (3) reasons as to why it is substantially inadequate and thus almost useless -

  1. First and foremost, it is not 100% accurate because it does not take all the factors that influence the accurate determination of effective permissions in Active Directory into account.

  2. Secondly, it can at best determine (an approximation of, and thus inaccurate) effective permissions one user at a time. So if you have 10,000 users in your organization, you will have to manually enter each user's name individually i.e. one by one, one at a time; now I don't know about you, but if I had to do this, I would probably find another job. 

  3. Finally, even though it can at best determine (an approximation of, and thus inaccurate) effective permissions one user at a time, it (also) CANNOT show you exactly which permission in the object's ACL is granting a specific effective permission, so if you're trying to find out HOW a user has a specific effective permission, you can't do so using this tool.  

Unfortunately, the same is true of dsacls, acldiag, LDP, PowerShell scripts and virtually every other 3rd-party Active Directory ACL/Permissions Analysis/Audit Tool out there, so there's really no easy way to answer these simple questions. Oh, and this free tool is so dangerously inaccurate that if it were an X-ray machine at an airport, I'd advise you to stay away from the airport.

So, is there an easy way in which organizations can make these vital determinations today? Well, keep reading...



Click, Done!

There's an old saying - "Talk is cheap." I believe that it would be irresponsible to merely shed light on a sensitive security challenge such as this one, without also providing a solution to help the world solve it easily and efficiently, and I for one take my responsibilities (of representing the finest of Paramount Defenses and Microsoft, having also been former Microsoft Program Manager for Active Directory Security) seriously, so let me show you just how easily organizations can now do so -


Gold Finger Active Directory Effective Permissions Audit Tool

You see, if I had to paint you a picture of what the correct answer looks like, this (above) is how it would look, and this is how easily organizations can now answer these vital security questions on their domain computer accounts in Active Directory.

Now, an observant mind might take a look at this picture and say - "Wait, although this in itself is phenomenal in that it is the only way to correctly determine effective permissions in Active Directory, it seems like if we had 50,000 domain computer accounts, would we have to press a button 50,000 times, you know, once per domain computer account?"

To which, I would say, "Well, here you go!" -


Gold Finger Active Directory Administrative Access and Delegation Audit Tool


What I've shown above is the world's only accurate Administrative Access / Delegation Audit Tool for Active Directory, and what it can do is determine effective permissions/access on every single domain computer account in any Active Directory domain, no matter its size (i.e. whether it has 500 or 50,000 computers), IN A SINGLE SHOT, and deliver results in plain English!

In other words, it does what is generally considered impossible to do, and it makes it as easy as touching a button!






Summary

Microsoft, over the last few days, I've shed light on various subtle yet important aspects of Active Directory Security, such as what the security ramifications of someone being able to make unauthorized changes to Active Directory content could be.


For instance, over the past few days, we looked at the security ramifications of someone being able to create user accounts, delete organizational units, modify domain security group memberships and change keywords on SCPs in Active Directory.

These examples would not have been complete without also shedding light on the ramifications of someone (e.g. intruder/rogue insider) being able to make unauthorized changes to computer objects i.e. domain computers accounts in Active Directory.

Thus, to round this part (i.e. a few examples of ramifications of unauthorized modification of vital Active Directory content) of our schooling off, I just wanted to shed light on a subtle yet very important aspect of Active Directory Security, one that most folks or organizations may not necessarily even have on their radar, but one that hackers may understand the importance an value of.

As we start to see an increased focus on Active Directory in the hacking community, it was important to put this on the radar of organizations worldwide, so they can be aware of this, and hopefully lockdown access on their domain computer accounts before intruders/hackers have an opportunity to do exploit them to gain elevated access and inflict substantial damage.

That's all for today; I'm excited about tomorrow's post, so stay tuned!

Best wishes,
Sanjay

No comments:

Post a Comment