Today Active Directory Security has become 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.

Gold Finger The Paramount Brief Gold Finger Mini World Peace

Wednesday, September 27, 2017

Active Directory Access Control Lists (ACLs) - "Actual" Attack and Defense

Folks,

This post impacts the cyber security of every foundational Active Directory deployment in the world, so you may want to read it.


Active Directory Access Control Lists (ACLs)

Active Directory is the foundation of cyber security worldwide because it enables distributed security in Windows environments and it stores, protects and enables the administration of the entirety of an organization's building blocks of cyber security.

In essence, literally from the entirety of the user accounts of an organization's workforce (including those of all privileged users), to the entirety of computer accounts that represent the organization's computers, and from the entirety of the domain security groups that protect the entirety of an organization's IT resources to the entirety of an organization's security policies (GPOs), at thousands of organizations worldwide, all building blocks of cyber security are stored, secured and managed in Active Directory.

Guess what protects each & every one of these building blocks of cyber security i.e. these Active Directory objects, worldwide?

It is Active Directory Access Control Lists (ACLs) -


An Active Directory Access Control List (ACL) protecting an Active Directory Object

Specifically, it is the ACL of an Active Directory object in which the organization's access intent for that object is specified (whether it be the CEO's user account or the Domain Admins group,) and it is this intent that is enforced by the "System."

In fact, today, billions of Active Directory ACLs that exist in Active Directory deployments worldwide, together serve to secure and defend the very building blocks of organizational cyber security at thousands of business and government organizations.

In short, not only do Active Directory ACLs today help protect trillions of dollars of wealth worldwide, they play a paramount role in securing and defending most business and government organizations, and thus they impact business and national security.

(By the way, if you want to get a complete look at an Active Directory object's ACL, here's likely the most capable tool to do so.)





Attack and Defense - Microsoft's Version

On September 18, 2017, i.e. about one week ago, Microsoft shared its thoughts on this subject in a blog post titled -



If you haven't read it, I highly recommend that you read it, NOT because you'll learn anything at all, but only because it reveals volumes about just how little Microsoft may actually seem to know about Active Directory Security, ACLs, attacks and defense.


Attack

If you listen to what today's Microsoft has to say, they'll downplay the exploitation of Active Directory ACLs as an attack vector, suggest that recently there's been some attention given to Active Directory ACLs by amateurs, indirectly concede that it may be possible to exploit weaknesses in Active Directory ACLs, tell you about AdminSDHolder to claim that this couldn't likely be used to escalate privilege to privileged users, reticently agree that it might be possible to find ways to compromise non-privileged users/objects in Active Directory and end by saying - "If you find a path with no obstacles, it probably leads somewhere!"


Defense

In regards to defense, the best today's Microsoft can do is tell you that that their latest toy, Microsoft Advanced Threat Analytics (ATA) can detect recon methods used by newbie tooling like Bloodhound (which incidentally is massively inaccurate.)


Folks, what today's Microsoft is telling you about attack and defense, sounds like Baloney.


Sadly, I don't think they're doing it intently though, as it very well might be that they actually either have no one from the old-guard working on this, and/or the new guards truly have no idea about any of this, both of which are really scary scenarios!








The Actual Attack and Defense

Folks, if you understand the subject of Active Directory Security well enough, then you know that Active Directory access control lists (ACLs) today don't just impact organizational security worldwide, they likely impact national and global security.


Further, you also know that today not only does there lie an ocean of access privileges specified within Active Directory ACLs at almost every organization worldwide, but also because Active Directory lacks the ability to adequately help organizations find out who actually what access in Active Directory, for so many years, most organizations have been operating in the dark, and today there likely exist thousands of privilege escalation paths leading to all kinds of privileges, including to privileged users.

By the way, it is now seventeen (17) years since Active Directory has been around, and even though this attack surface has existed since then, it is only now that a few enthusiasts are starting to realize what a gold-mine of information Active Directory is, and just how many privilege escalation paths one could find to just about everything in Active Directory. In fact, some of these enthusiasts may have gotten a little too excited and even released some infantile tooling, which I believe goes by the name Bloodhound, and lo and behold it is one of the hottest pen-test tools today, even though it is massively inaccurate!




Attack

Speaking of attack, the exploitation of excessive/unauthorized access specified in Active Directory ACLs, as illustrated here, summarized here, described here and a realistic example of which is shown here, is a very real and serious possibility today.


That's because in most Active Directory deployments worldwide, today there likely exist thousands of privilege escalation paths in Active Directory ACLs, just waiting to be found (and exploited (by the bad guys), or eliminated (by the good guys)) by anyone who has the skills or the tooling required to accurately perform effective permissions analysis in Active Directory deployments.


To illustrate how serious this is, here are 7 specific examples of Attack that involve the exploitation of Active Directory ACLs -
  1. The complete compromise of an organization's entire workforce's credentials, by an unauthorized individual, such as an intruder or a rogue insider, enactable by the use of the hacking tool Mimikatz DCSync which involves requesting and retrieving the secrets (passwords) of the entirety of an organization's domain user accounts, is possible (and can only be made possible) if that unauthorized individual has sufficient Get-Replication-Changes-All effective permissions in the Active Directory ACL of the target Active Directory domain's domain root object. 

  2. The complete compromise of an organization's Active Directory privileged domain user accounts and security groups, such as the Administrator account, the Domain Admins group etc., involving an unauthorized password reset and/or a group membership change etc., is possible if that unauthorized individual has sufficient Write-Property (member or blanket), effective permissions or Reset-Password Extended Right effective permissions in the Active Directory ACL of the target Active Directory domain's unique AdminSDHolder object.

    An Important Note: AdminSDHolder protection only protects the members of those default Active Directory administrative groups that it is intended to cover, and it does so transitively.

    However, if any security principals other than those that fall under the AdminSDHolder protection, were to be granted any kind of access in the AdminSDHolder object's ACL, then those security principals would NOT be protected by AdminSDHolder protection, and THAT opens up the possibility of there existing privilege escalation paths from non-privileged users to privileged users protected by AdminSDHolder.

    Many organizations do modify the default AdminSDHolder object's ACL for various reasons, such as to implement their own custom delegations, configure or lockdown access to privileged users etc.
  3.   
  4. The complete compromise of the majority of an organization's Active Directory content, i.e. all of their domain user accounts, computer accounts, domain security groups, containers, OUs, service connection points etc. whose Active Directory ACL is not marked Protected, by an unauthorized individual, is possible if that unauthorized individual has sufficient Modify Permissions effective permissions in the Active Directory ACL of any large or Top-level Organizational Unit (OU), or on the domain root, because it would allow the unauthorized individual to make a single malicious change and leverage permission inheritance to obtain full control over the entirety* of all objects whose Active Directory ACLs will end up inheriting that malicious ACL change. 

  5. A massive (even if temporary i.e. ranging from a few hours to a few days) denial-of-service (DoS) attack on virtually an organization's entire IT infrastructure, their entire workforce and their ability to do business, made possible by something as simple as the deletion of a top-level Organizational Unit (OU) by an unauthorized individual, is possible if that unauthorized individual has sufficient Delete* (details) effective permissions in the Active Directory ACL of that OU.

  6. The identity theft and thus compromise of organizational users, involving a password reset of their domain user accounts by an unauthorized individual, is possible if that unauthorized individual has sufficient Reset-Password Extended Right effective permissions in the Active Directory ACL of the victim's Active Directory domain user account. This could also be used to in effect escalate privilege in Active Directory, and there could possibly exist privilege escalation paths leading from a non-privileged user to highly privileged users, in effect also providing a perpetrator system-wide command and control over an organization's IT infrastructure.

    An Important Note: Organizations that may have various kinds of multi-factor authentication (MFA) in place, such as Smartcards for domain user accounts, should note that if an unauthorized individual has sufficient Write-Property (either blanket, or for the appropriate attribute) effective permissions on a user's domain account, then he/she could easily turn MFA off on the account, in which case, the account's security will fallback to being password based ( i.e. a system-generated random password) and a password reset (assuming the perpetrator also has sufficient effective permissions to do so) would then allow the unauthorized individual to effortlessly steal its identity, i.e. effectively take over that account.

  7. A critical denial-of-service (DoS) attack aimed at disrupting one or more possibly mission-critical applications, such as Microsoft Exchange, Centrify Server Suite, Microsoft Rights Management Server, Microsoft Group Policy, Microsoft Terminal Server, Microsoft Azure, Quest Active Roles Server, Quest Change Auditor, Quest InTrust, Quest Privileged Password Manager, BeyondTrust PowerBroker for Windows, Citrix XenApp and XenDesktop, IBM DB2, to name a few, that rely on the use of Service Connection Points in Active Directory, by an unauthorized individual, is possible if that unauthorized individual has sufficient Write-Property (keywords or Blanket) effective permissions in the Active Directory ACL of one or more of the Service Connection Points of that specific mission-critical application.

  8. A massive cyber security breach in which an unauthorized individual, such an intruder, a disgruntled or rogue insider, an APT, a compromised delegated admin/service account etc., is able to obtain access to and leak/divulge, exfiltrate, tamper or destroy literally any (some, or all) organizational IT resource of his/her/their choice, such as a specific file, folder, database, server, application etc., or thousands thereof, is possible if that unauthorized individual simply has Write-Property (member or blanket) effective permissions in the Active Directory ACL of the specific domain security group (, such as All EmployeesBlueprint Access Group, Email Servers, Project Windham Group, etc.) in Active Directory that is currently gating access to that organizational IT resource, as this would allow that individual to add any domain account under his/her control to the membership of this domain security group and subsequently instantly and legitimately gain unrestricted access to the target organizational IT resource.

Note: In each case above, in lieu of the effective permissions mentioned above, it would alternatively be sufficient for the unauthorized individual to have Modify-Permissions effective permissions of Modify-Owner effective permissions in the ACL of the involved target Active Directory objects.

I could give many more examples, but to the wise a hint is enough, and I've given you 7 concrete examples of just how much damage an unauthorized individual who possesses various levels of unauthorized access in Active Directory ACLs, could do.

The reality is that literally anything and everything in Active Directory could be a target - The Active Directory Attack Surface


Now, that said, let's talk about Defense.





Defense

Take a deep breath of calm because this risk can be actually be easily, swiftly and completely eliminated by organizations.


The truth of the matter is that even though the serious cyber security risk posed by the potential exploitation of the vast number of excessive/unauthorized privilege access grants that are today specified in billions of Active Directory ACLs across thousands of Active Directory deployments, likely poses a clear and present danger to organizational cyber security worldwide, this risk can actually be easily, swiftly and completely eliminated by organizations, leaving no opportunity on the table for perpetrators.


How, you ask?  Keep reading...

A Small Digression
To understand how to mitigate this risk, we need to understand what caused this risk in the first place.


For years now, organizations have been leveraging Active Directory's precise administrative delegation / access provisioning capability to delegate/provision all kinds of access in Active Directory to fulfill business needs.  
While Active Directory makes it very easy to precisely delegate/provision access, unfortunately, it completely lacks the capability to help precisely assess/audit the actual resulting access that ends up getting implemented, and thus organizational IT personnel / AD admins have no way of being able to precisely a) verify the accuracy of their delegations or b) audit who actually has what access provisioned in Active Directory at any point in time.
Further, 3 factors contribute to exacerbating the situation -
  1. Active Directory's security model is quite rich and powerful, and thus complex, since it has almost a dozen generic security permissions and five dozen special security permissions (known as extended rights), and further, because mechanisms like inheritance of permissions involve and require precedence orders, applicability etc. all of this makes it difficult to determine the actual access implemented in Active Directory.

  2. A majority of all access specified in Active Directory is specified for security groups (as it should be), which given the possibility of group nesting, and often to multiple levels, further complicates not only who all might be ending end up with all kinds of access, but also trying to find out who actually has what access, especially since the membership of any of these groups could be changed by so many others, anytime.

  3. Considering the above, the slightest change made in even one place in Active Directory, such as in the ACL of a top-level OU, or the membership of even a single mid-level nested domain security group, could easily end up changing the actual state of access in Active Directory quickly & in many cases substantially.

Consequently, though organizations have been delegating/provisioning access in Active Directory for years now, they have almost never had the means or the opportunity to be able to accurately audit the actual existing state of access in Active Directory, and in light of the above, considering that in most Active Directory domains there may thus far have been 1000s of changes made, there likely exists a vast amount of excessive / unauthorized access, and no one actually knows exactly who can do what in their Active Directory deployments.
End of Digression.

The reason there exists vast amounts of excessive/unauthorized access in Active Directory is that organizations don't have the means to easily and correctly audit/assess who is actually i.e. effectively delegated/provisioned what access in Active Directory.

In order to be able to correctly do so, all that organizations need is the ability to be able to accurately, adequately and efficiently determine exactly who has what effective permissions/access in Active Directory, on a per-object basis, & ideally domain-wide.

By "adequately", I mean that given an Active Directory object, organizations should be able to easily determine a) the complete set of effective permissions provisioned on it, b) as well as the complete list of individuals that have these effective permissions, and c) HOW each one of these individuals is getting these effective permissions, as that data is needed to lock-down access.

Unfortunately, this capability does not seem to natively exist in Active Directory, so most organizations have just been performing basic Active Directory Permissions Audits, which are almost useless, and as a result, no one really knows exactly who can do what in Active Directory!

Over the years, this has resulted in a substantial amount of excessive/unauthorized access in Active Directory, which is best evidenced by the fact that even a tool as massively inaccurate as Bloodhound is able to find so many privilege escalation paths!


That said, here's Defense -

Conceptually, to defend against these attacks, all that organizations require is the ability to be able to accurately and adequately determine Active Directory Effective Permissions on their Active Directory objects, as this will give them a correct picture of who can actually do what on these objects, and show them how these users have such access today, and thus enable them to know exactly which security permissions to tweak in the ACLs of which Active Directory objects, and/or which group memberships to tweak, to lockdown any and all excessive / unauthorized access that is currently provisioned on their Active Directory objects.

Again, by "adequately", I mean that, given an Active Directory object, organizations should be able to determine a) the complete set of effective permissions provisioned on it, b) as well as the complete list of individuals that have these effective permissions, and c) HOW each one of these individuals is getting these effective permissions, as that data is needed to lock-down access.





A Simple 3-Step Defense Process

To defend against these attacks, this simple 3-step process is all that organizations need to perform -

  • Step 1 - Perform an Active Directory Effective Privileged Access Audit. This is a simple audit that involves the accurate determination of effective permissions/access in Active Directory, and it is the correct way to identify exactly who actually i.e. effectively has what access (anywhere and everywhere) in an Active Directory domain.

  • Step 2 - Analyze the results of this audit to identify all such users who currently possess any kind of access in Active Directory that they should NOT ideally be in possession of. Also identify where they currently possess such access.

  • Step 3 - For each such user identified in the analysis of Step 2, for each object on which they have such identified access, further analyze the results of this audit to additionally identify the HOW i.e. the underlying permissions in the ACL of the object that are entitling them to such effective access. Then, use this information to appropriately tweak the underlying ACL or the involved group membership to revoke all such identified excessive / unauthorized access.

In essence, in Step 1 we accurately determine object-specific/domain-wide effective permissions/access, in Step 2 we analyze these results to identify all "unauthorized access" and the underlying permissions in Active Directory ACLs that cause them, and in Step 3 we use this data to tweak these permissions in the ACLs (, or group memberships,) to lockdown Active Directory.

That's it!

For an illustrative step-by-step example that shows how to follow these
steps on a specific Active Directory object, see section IX of this post.



A Simple Example

If I had more time at hand, I would've shown you exactly how to do so, domain-wide. Since I don't, I'll share a quick example.

Lets assume that your organization wants to ensure that no one can make an unauthorized group membership change to any of the thousands of domain security groups in your Active Directory that are being used to protect the entirety of your IT resources.


To do so, technically what you need to do is accurately determine effective permissions on every domain security group in your Active Directory to find out who has Write-Property Member effective permissions on each one of these domain security groups.

Now, this in itself might seem like a herculean undertaking, and it is, but with the involved tooling, you can easily get it done.

Once you've done so, you'll have the accurate technical data that shows you exactly who can change the group membership of each one of your domain security groups in Active Directory, and once you have this insight, you'll be able to identify exactly how many individuals can currently enact this task versus how many should ideally be able to do so, and thus you'll be able to easily identify all such individuals who are not supposed to be able to do so, but nonetheless are able to do so today i.e. you'll be able to identify all users who possess "unauthorized access" as it pertains to this example.

Once you have identified all such users who possess this "unauthorized access", if you know which underlying permissions in the Active Directory object's ACLs are entitling them to this unauthorized access (and you will have this data if you perform the above mentioned audit, because the involved tooling will provide it to you), you can now tweak either the permissions or the membership of the domain security groups to which these permissions are granted, as needed, to revoke this unauthorized access, and in this manner, you can easily, efficiently and provably lockdown the access granted in Active Directory.

An Effective Privileged Access Audit is thus a simple, logical and straight-forward process that involves enacting the above to help organizations easily and accurately obtain the insight they need to identify unauthorized access in Active Directory.

One last thing - wouldn't it be nice if instead of having to determine who has what effective permissions in terms of technical Active Directory permissions (e.g.  Write-Property Member), we could just obtain this information in terms of administrative access entitlements i.e. in terms of who can enact what administrative tasks (e.g. Who can change a group's membership)?

I happen to think so, because security is best kept simple, and we humans can think about and analyze situations described in terms of administrative tasks much better than we can do so in terms of arcane technical permissions. In this regard, the tooling involved in such an audit is designed to deliver this insight in terms of administrative tasks rather than technical permissions. Of course, should you also like the data in terms of technical permissions, the involved tooling can certainly deliver that as well.

Thus, as it pertains to this example, an Effective Privileged Access Audit will deliver the following data to you - a complete list of all individuals who can change domain security groups in our Active Directory, the exact identity of each domain security group whose membership they can change, and the exact underlying security permission in the ACL of that domain security group that entitles this user to being able to change its membership. Armed with this valuable insight, we can easily and completely lockdown Active Directory vis-à-vis this example, in a matter of days.

End of Example.


A comprehensive Effective Privileged Access Audit will thus empower your organization to easily, efficiently and accurately determine the entirety of access that is currently provisioned/delegated in your Active Directory, i.e. it will span finding out who can do what concerning account management, group management, OU and Container management, SCP management, Directory Services management etc. and do so in a matter of hours, not months, and thus it will get you the data you need to adequately lockdown your Active Directory, and in doing so enable your organization to swiftly, measurably and demonstratably attain and maintain least privileged access in Active Directory.

Any organization or individual who needs additional information or clarity into this process may be feel free to contact us. Our technical specialists will be happy to help you adequately understand this process, our compliments (i.e. free of charge.)



So you see, this is all we need to do, and once we've done this, there will be no unauthorized access left in our Active Directory, no matter how large it is, and there will be no unknown privilege escalation paths left for perpetrators to find and exploit. None!


Let me repeat that. Once you've done this, there will be no unauthorized access left in your Active Directory. None... 
Zero!      нуль, nul, صفر , 零,Null, μηδέν, ʻole, אֶפֶס , शून्य, ゼロ,제로, nihil, sero !

This is all that organizations need to do to easily, efficiently and accurately identify and lockdown all unauthorized access in Active Directory. From that point on, you'll want to maintain this least privileged access state by performing regular audits.


So, what tooling is needed to perform an Active Directory Effective Privileged Access Audit?  You're going to need this & this.

In fairness, to be totally objective, strictly speaking you can use any tool that can help you accurately and adequately determine effective permissions in Active Directory, at a minimum on a per-object basis, and ideally domain-wide (unless you have years to solve this problem). I only mentioned those two tools because those are the only tools that I know of that can help do this.




In Summary

The potential exploitation of the vast amount of excessive/unauthorized access that exists in billions of Active Directory ACLs worldwide today is a serious challenge that 1000s of organizations face because it impacts their foundational cyber security.

Fortunately, with the right guidance, tooling and executive support, it can be quickly, efficiently and completely addressed.


Here's what we at Paramount Defenses believe -
"We at Paramount Defenses care deeply about cyber security and we understand that left unaddressed, this could pose a serious cyber security risk to organizations worldwide that operate on Active Directory. Be rest assured that Active Directory is a highly robust, trustworthy and securable technology, and here is exactly how organizations can easily, adequately and reliably identify and lock-down privileged access in their foundational Active Directory deployments, leaving no room for perpetrators to identify and exploit any weaknesses."

Lastly, I know that I make it sound so simple, but in reality, this is a very difficult problem to solve, and without the ability to be able to obtain accurate effective access insight, which in turn requires the right tooling, it really is almost impossible to solve.

As for the right tooling, building it requires vision, a deep understanding of the subject, and years to build, test and perfect.

Best wishes,
Sanjay

CEO, Paramount Defenses

Formerly, Program Manager,
Active Directory Security,
Microsoft Corporation


PS: I could've easily communicated all of this in just a simple Executive Summary, and we did - its called The Paramount Brief. In fact, last year, we had even FedEx overnighted it to the CEOs, CFOs and Chairmen of the Top-200 organizations worldwide, and FedEx tracking helped ensure that they all received it. They've all been informed. I even shared it with Microsoft (MSRC).

PS2: To my friends at Microsoft - "This only took a decade of vision, persistence, grit and laser-focused execution to address."

PS3: If you liked this post, you're likely going to love the next few posts.

Thursday, September 21, 2017

Did Microsoft Just Reveal How Little It May Seem to Know about Active Directory Security In Speaking of Access Control List Attacks & Defense?

Folks,

Three (3) days ago i.e. on September 18, 2017, Microsoft's Advanced Threat Analytics (ATA) Team posted a blog post titled -



If you haven't read it, I highly recommend that you read it, NOT because you'll learn anything at all, but only because it reveals volumes about just how little Microsoft may actually seem to know about Active Directory Security, ACLs, attacks and defense.


When you read it, it will likely be unequivocally clear to you as well as to just how little Microsoft seems to understand about not just the sheer depth and breadth of this monumental challenge, but about the impact it could have on organizations worldwide!


You see, if you understand the subject of Active Directory Security well enough, then you know that Active Directory access control lists (ACLs) today don't just impact organizational security worldwide, they likely impact national and global security !

That said, in that post, the best Microsoft could do is concede that this could be a problem, wonder why organizations might ever need to change AdminSDHolder, falsely assume that it may not impact privileged users, praise a massively inaccurate tool for shedding light on this attack vector, and end by saying - "If you find a path with no obstacles, it probably leads somewhere!"

Oh, and the very last thing they tell you that is their nascent ATA technology can detect multiple AD reconnaissance methods.


You really have to read it to get what I'm saying. Seriously, here's all this post mostly touched upon - a quick overview of Active Directory ACLs, an overview of AdminSDHolder protection in Active Directory, and a note on delegated permissions in AD.

Oh, and they thanked whoever made that massively inaccurate tool called Bloodhound for bringing ACLs to the front, literally!

By the way, that baby of a tool, Bloodhound just recently came out, and I've been saying this since for half a decade now, here. Maybe to learn a thing or two re AD Security, the good folks at Microsoft should Google "Active Directory Privilege Escalation"


Perhaps the one line that stood out most (of many lines that stand out) is -

"Why would you want to change AdminSDHolder manually? 
To date, our team hasn't found a solid reason!"

Microsoft, when you publicly ask such a question, you reveal how little your team may know about Active Directory Security.

(Dear Microsoft, FYI, and in case you didn't know, likely the number #1 thing most organizations need to do to secure/lockdown access to/on all their default privileged user accounts and security groups in Active Directory, is to change AdminSDHolder!)

Oh, and has it ever occurred to you that many mature organizations may choose to implement their own custom AD delegation models, in which case they may not even end up relying on default AD administrative accounts and groups, in which case your point concerning ACL based vulnerabilities not impacting privileged users and groups in Active Directory would be moot.




You see, here's what they should have said - "We care deeply about cyber security and we understand that left unaddressed, this could pose a serious cyber security risk to our customers. Be rest assured that Microsoft Active Directory is a highly robust and securable technology, and here's exactly how organizations can adequately and reliably identify and lock-down privileged access in their Active Directory deployments, leaving no room for perpetrators to identify and exploit any weaknesses."

The reason I say that should've been the response is because if you know enough about this problem, then you also know that it can actually be completely and sufficiently addressed, and that you don't need to rely on detection as a security measure.

Sadly, since they don't seem to have a clue as to this, you're likely not going to get that response from Microsoft.

BTW, to appreciate how little Microsoft seems to understand about this huge cyber security challenge, you'll want a yardstick to compare Microsoft's response with, so here it is (; you'll want to read the posts) - Active Directory Security School for Microsoft.



Finally, if this is how little Microsoft seems to understand about such a profoundly important cyber security challenge concerning your own technology, I cannot help but wonder how well their customers might actually be protected in its recent Cloud offering!


It is now abundantly clear that Microsoft may need help, so in days to come, I'm going to help them out.

Best wishes,
Sanjay



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

Friday, September 15, 2017

How to Audit Who Can Change/Control/Delete a Service Connection Point in Active Directory?


Dear Microsoft,

Today is Day-18 of our Active Directory Security School for you. Today, I'll answer the question I had asked you on Day-17, and in doing so, along with you, we will also help thousands of organizations worldwide find out how to correctly audit who can change, control or delete Service Connection Points in their Active Directory deployments.



First, A Quick Recap

If you have yet to read the previous post, which can be found here, you may want to do so to get sufficient context for this post.

In the previous post, we had talked about what a Service Connection Point is, and how numerous Active Directory-integrated applications, both those developed in-house as well as 3rd-party applications, use and rely on them to deliver their functionality.


A Service Connection Point in Active Directory

In short, we had seen how various mission-critical applications that provide everything from email to two-factor authentication and from Linux/UNIX integration with Active Directory to auditing and privileged user account management, use and rely on Service Connection Points in Active Directory for their proper functioning. (A list of a few such apps is provided below.)


We had also covered the impact of someone being able to make an unauthorized modification to one or more attributes of the Service Connection Points of these mission-critical cyber security enabling Active Directory integrated-applications.


An Intruder Changing the Keywords Attribute on a Service Connection Point in Active Directory

To be precise, we had concluded that in the event that an intruder or a malicious insider could do so, he/she could potentially disrupt these applications from delivering their functionality, the impact of which could range from an instant denial-of-service attack on these critical Active Directory-integrated applications to leaving millions of IT resources vulnerable to compromise.




Next, A Few Such Apps

To appreciate the real-world security implications of an unauthorized change made to the Service Connection Points of such applications, perhaps it may help to identify even just a few prominent such applications that are today extensively deployed worldwide and depend on, and thus could be impacted by the unauthorized modification of Service Connection Points.



Here are 10 such prominent applications that may likely be deployed at 1000s of organizations worldwide today -

  1. BeyondTrust PowerBroker for Windows - BeyondTrust's PowerBroker Identity Services (PBIS) centralizes authentication for Unix, Linux and Mac environments by extending Active Directory's Kerberos authentication and single sign-on capabilities to these platforms. As documented here, to store information about a group or a user, PBIS creates a serviceConnectionPoint object (in Active Directory) and stores information in its keywords attribute. 

  2. Centrify Server Suite - Centrify's Server Suite, beyond its core capability of integrating UNIX and Linux accounts into Microsoft Active Directory, supports privilege management capabilities, integrated cross-platform auditing, dynamic server isolation, and single sign-on to on-premises applications. One of the major strengths of the Centrify Server Suite, is that all UNIX identity and authorization data is stored as Active Directory objects. As documented here, it extensively creates and uses serviceConnectionPoint objects in Active Directory to represent computer profiles, UNIX group profiles and UNIX user profiles.

  3. Citrix XenApp and XenDesktop - Citrix's XenApp and XenDesktop application virtualization solutions optimize productivity with universal access to virtual applications, desktops and data from any device. As documented here, delivery controllers, the server-side component responsible for managing user access brokering and optimizing connections, are represented by serviceConnectionPoint objects in Site OUs in Active Directory. Each time a Controller starts, it validates the contents of its Service Connection Point. In addition, Windows Desktop Virtual Delivery Agents (VDAs) use OU-based controller discovery which relies on these service connection point objects.

  4. IBM DB2 - IBM's DB2 for Linux, UNIX and Windows is a next generation data platform for transactional and analytical operations that provides continuous availability of data to keep transactional workflows and analytics operating at maximum efficiency. As documented here, DB2 database servers are published in the Active Directory as ibm_db2Node objects, which is a subclass of the serviceConnectionPoint object class. Each such object contains protocol configuration information to allow client applications to connect to the DB2 database server. When connecting to a remote database, a DB2 client queries the Active Directory though the LDAP interface for these objects.

  5. Microsoft Exchange - Microsoft's Exchange Server is a messaging platform that provides email, scheduling and tools for customer collaboration and messaging service applications. As documented here, Exchange stores the configuration of Exchange Servers as well as information about user mailboxes in Active Directory. Its Autodiscover feature, that enables client applications and users to configure themselves with minimal input, uses Active Directory service connection points to store and retrieve a list of Autodiscover URLs for the forest in which Exchange is installed. When you install Exchange 2016, you need to update the SCP object to point to the Exchange 2016 server. This is necessary because Exchange 2016 servers provide additional Autodiscover information to clients to improve the discovery process.

  6. Microsoft Active Directory Rights Management Server - Microsoft's Active Directory Rights Management Server delivers Active Directory Rights Management Services (AD RMS), information protection technology that works with AD RMS-enabled applications to help safeguard digital information from unauthorized user, both online and offline, inside and outside of a firewall. As documented here, AD RMS publish Service Connection Points in Active Directory to hold the web address of the AD RMS certification cluster. AD RMS-enabled applications then use these Service Connection Points to discover the AD RMS service; it is the first connection point for users to discover the AD RMS web services.

  7. One Identity / Quest Privileged Password Manager - One Identity / Quest Software's Privileged Password Manager helps automate, control and secure the process of granting administrators the credentials necessary to perform their duties. Privileged Password Manager is a critical component of One Identity privileged account management solutions. As documented here, Privileged Password Manager publishes and relies upon Service Connection Points in Active Directory. In particular it modifies the serviceBindingInformation, displayName and keywords attributes of its Service Connection Points to store, amongst other pieces of information, your registered company name, Server URLs etc.   

  8. Quest Active Roles Server - Quest's Active Roles Server is a proxy solution designed to help organizations enhance account administration, directory management and security in Active Directory deployments. As documented here, as Active Roles performs operations on behalf of delegated users, the Active Directory service account requires adequate permissions. Quest recommends making Active Roles a member of Domain Admins. If organizational policies restrict its Domain Admin membership, then at a minimum, amongst a plethora of other permissions, since its service account must be able to publish itself in Active Directory, it will also require permissions to create serviceConnectionPoint objects.

  9. Quest Change Auditor - Quest's Change Auditor is an auditing solution that helps organizations track/audit changes to Active Directory, and thus helps ensure security, compliance and control of Active Directory content. As documented here, Change Auditor publishes Service Connection Points in Active Directory so that Change Auditor clients, agents and other third-party applications can automatically locate the Change Auditor coordinator. When clients or agents start up, they search Active Directory for these Service Connection Points to retrieve connection information for the Change Auditor coordinator such as hostname, listening port, and other authentication information.

  10. Quest InTrust - Quest's Intrust enables organizations to collect, store, search and analyze IT data from numerous data sources, devices and security information and event management (SIEM) solutions in one place. As documented here, Quest Intrust creates the following service connection point in Active Directory - <MyDomainName>/System/Quest In Trust/InTrustServer{<InTrustServerGUID>}.

Note - It must also be mentioned that the manner in which most of these applications have been integrated with Active Directory is consistent with Microsoft's recommendations, and in fact by integrating with Active Directory, these applications get to leverage its various capabilities, strengths and uses, and that is a good thing.

Speaking of which, of the applications above, perhaps the one that is most well-integrated with Active Directory, and thus one that uses and relies upon Service Connection Points most extensively may be Centrify Server Suite.


Oh, and the Azure AD Connect feature of Microsoft Azure also uses/relies on Service Connection Points in Active Directory.
( Specifically, as documented here, if you have an on-premises Active Directory environment and you want to join your domain-joined devices to Azure AD, you can accomplish this by configuring hybrid Azure AD joined devices. During their registration process, these domain-joined devices query the Active Directory for a Service Connection Point to discover Azure AD tenant information. Specifically they search for the object "cn=62a0ff2e-97b9-4513-943f-0d221bd30080,cn=Device Registration Configuration,cn=Services,cn=Configuration,dc=<forest-root-domain>" as it is this object's Keywords attribute that contains the organization's Azure AD tenant information. )


As you'll likely agree, many of these applications play a vital role in ensuring cyber security at many organizations worldwide.

If you understand the role that these applications play in providing and ensuring security at organizations worldwide, then you know that the unauthorized modification of the attributes of their Service Connection Points could substantially impact security.



The Question

In light of the above, I had posed the following few most simple and elemental questions, and asked you how organizations worldwide could answer these questions  -

Question: Who can change the various attributes/properties of a Service Connection Point in  Active Directory ?

In fact, in addition, it also begs the following questions -
  1. Who can modify the ACL/permissions protecting a Service Connection Point? 
  2. Who can modify the owner of a Service Connection Point?
  3. Who can delete a Service Connection Point?
     That's because if you can do either one of the above, you can have the same effect on the service.





Finally, The Answer

It is imperative that every organization that has any application that relies on the use of Service Connection Points in Active Directory know the exact answers to these questions at all times, and now let me show you how to correctly answer them.


First, lets rule out the incorrect answer, which is how most organizations worldwide may be trying to answer these questions today, and that incorrect answer is - "Find out who has what permissions on a Service Connection Point in Active Directory."


acldiag

Even though this is the incorrect answer, most organizations may not know this, so they continue to use tools like dsacls, acldiag, PowerShell scripts etc. or any one of numerous 3rd-party Active Directory Permissions Audit Tools to do so.


Now, the correct answer, which is how every organization worldwide should be attempting to answer these questions today, and that correct answer is - "Find out who has what effective permissions on a Service Connection Point in Active Directory."


The Effective Permissions Tab is Inaccurate


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.

Before we continue further, let me say this again. I cannot stress this enough - if you don't know what effective permissions in Active Directory are and why they're paramount to your security, you'll want to read this - Active Directory Effective Permissions.



So, now that we know that theoretically the correct answer is - "Find out who has what effective permissions on a Service Connection Point in Active Directory", is there an easy way to determine effective permissions on Active Directory objects?

Yes, (thankfully) there is one way...



Here's how so many of the world's top business and government organizations easily and accurately answer these questions -


The Gold Finger Active Directory Effective Permissions Audit Tool


The snapshot above is of the Gold Finger Active Directory Effective Permissions Audit Tool.

This tool quite simply is the world's only accurate and adequate effective permissions calculator for Active Directory.

Not only can this tool accurately determine effective permissions on any object in Active Directory, to use this tool, all you have to do is point the tool at whatever object you want to determine effective permissions on, and then click ONE button. That's it!

As seen in the snapshot above, we used this tool to perform an effective permissions audit on a service connection point called RMS Service in Active Directory, and the audit results show us every single security permission-combination that is effectively allowed on this service connection point object, as well as exactly who each effective permission is granted to, and how so.

So, for example, to find out who can change a Service Connection Point's keywords, all you have to do is use the What drop-down to select Write-Property - Keywords effective permissions and the tool will display the complete list of all individuals who can do so. Similarly you can find out exactly who can change each attribute/property, as well as its ownership and permissions.


Now, wouldn't it be nice if someone could make it even simpler such that all these technical details (i.e. effective permissions, attributes, mappings etc.) could be abstracted enough that we could just find all this out in English. Well, guess what? Done! -


The Gold Finger Active Directory Effective Access Audit Tool

The snapshot above is of the Gold Finger Active Directory Effective Access Audit Tool, which is the world's only tool that can accurately and adequately determine effective access in Active Directory environments.

As seen in the snapshot above, we used this tool to perform an effective access audit on a service connection point called RMS Service in Active Directory, and the audit results show us every single administrative task that can be enacted on this object by virtue of the effective permissions allowed on this service connection point object, as well as exactly who can enact each one of these administrative tasks, and of course, how so. In other words, you can now find out exactly who can do what, in English!

(Finally, if you have numerous Service Connection Points in Active Directory, this tool can audit all of them at a button's touch.)

In this manner, every organization worldwide that needs to know exactly who can change, control or delete Service Connection Points in their Active Directory can now accurately and instantly find out so 365-24-7, in seconds, and at the touch of a button.


So, Microsoft, you see, today this is how organizations worldwide can answer these simple yet vital cyber security questions.

In contrast, let alone providing your customers i.e. organizations worldwide, a solution, in 17 years, you haven't even told them that what they actually need to do is not to audit "who has what permissions" but to audit "who has what effective permissions"!

Need one say more?

Best,
Sanjay


PS: It took half a decade of laser-focused execution to make something this difficult, this easy for the world. You're welcome.