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

Sunday, December 31, 2017

Looking Back at 2017 - An Eventful Year for Active Directory Security

Folks,

As we get ready to bid farewell to 2017, it may be fitting to recap notable happenings in Active Directory Security this year.

This appears to have been the year in which the mainstream Cyber Security community finally seems to have realized just how important and in fact paramount Active Directory Security is to cyber security worldwide, in that it appears that they may have finally realized that Active Directory is the very heart and foundation of privileged access at 85% of organizations worldwide!


I say so only because it appears to have been in this year that the following terms seem to have become mainstream cyber security buzzwords worldwide - Privileged User, Privileged Access, Domain Admins, Enterprise Admins, Mimikatz DCSync, AdminSDHolder, Active Directory ACLs, Active Directory Privilege Escalation, Sneaky Persistence in Active Directory, Stealthy Admins in Active Directory, Shadow Admins in Active Directory, Domain Controllers, Active Directory Botnets, etc. etc.



Top-10 Notable Active Directory Security Events of 2017

Here are the Top-10 most notable events in Active Directory Security this year -


  1. Since the beginning on the year, i.e. January 01, 2017, Mimikatz DCSync, an incredibly and dangerously powerful tool built by Benjamin Delpy, that can be used to instantly compromise the credentials of all Active Directory domain user accounts in an organization, including those of all privileged user accounts, has been gaining immense popularity, and appears to have become a must-have tool in every hacker, perpetrator and cyber security penetration-tester's arsenal.

  2. On May 15, 2017, the developers of BloodHound introduced version 1.3, with the objective of enhancing its ability to find privilege escalation paths in Active Directory that could help find out "Who can become Domain Admin?"  From that point on, Bloodhound, which is massively inaccurate, seems to have started becoming very popular in the hacking community.

  3. On June 08, 2017, CyberArk a Billion+ $ cyber-security company, and the self-proclaimed leader in Privileged Account Security, introduced the concept of Shadow Admins in Active Directory, as well as released a (massively inaccurate) tool called ACLight to help organizations identify all such Shadow Admins in Active Directory deployments worldwide.

  4. On June 14, 2017, Sean Metcalf, an Active Directory security enthusiast penned an entry-level post "Scanning for Active Directory Privileges and Privileged Accounts" citing that Active Directory Recon is the new hotness since attackers, Red Teamers and penetration testers have realized that control of Active Directory provides power over the organization!

  5. On July 11, 2017, Preempt, a Cyber Security announced that they had found a vulnerability in Microsoft's implementation of 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. 

  6. On July 26, 2017, the developers of (massively inaccurate) BloodHound gave a presentation titled An ACE Up the Sleeve - Designing Active Directory DACL Backdoors at the famed Black Hat Conference USA 2017. This presentation at Black Hat likely played a big role in bringing Active Directory Security to the forefront of mainstream Cyber Security.

  7. Also on July 26, 2017, a second presentation on Active Directory Security at the Black Hat Conference titled The Active Directory Botnet introduced the world to a new attack technique that exploits the default access granted to all Active Directory users, to setup command and control servers within organizations worldwide. This too made waves.

  8. On September 18, 2017, Microsoft's Advanced Threat Analytics (ATA) Team penned a detailed and insightful blog post titled Active Directory Access Control List - Attacks and Defense, citing that recently there has been a lot of attention regarding the use of Active Directory ACLs for privilege escalation in Active Directory environments. Unfortunately, in doing so Microsoft inadvertently ended up revealing just how little its ATA team seems to know about the subject.

  9. On December 12, 2017, Preempt, a Cyber Security announced that they had found a flaw in Microsoft's Azure Active Directory Connect software that could allow Stealthy Admins to gain full domain control. They also suggested that organizations worldwide use their (massively inaccurate) tooling to find these Stealthy Admins in Active Directory.

  10. From January 26, 2017 through December 27, 2017, Paramount Defenses' CEO conducted Active Directory Security School for Microsoft, so that in turn Microsoft could help not just every entity mentioned in points 1- 9 above, but the whole world realize that in fact the key and the only correct way to mitigate each one of the security risks and challenges identified in points 1 - 9  above, lies in Active Directory Effective Permissions and Active Directory Effective Access.





Helping Defend Microsoft's Global Customer Base
( i.e. 85% of Business and Govt. Organizations Worldwide )

Folks, since January 01, 2017, both, as former Microsoft Program Manager for Active Directory Security and as the CEO of Paramount Defenses, I've penned 50+ insightful blog posts to help educate thousands of organizations worldwide about...


...not just the paramount importance of Active Directory Security to their foundational security, but also about how to correctly secure and defend their foundational Active Directory from every cyber security risk/challenge covered in points 1- 9 above.

This year, I ( / we) ...

  1. conducted 30-days of advanced Active Directory Security School for the $ 650+ Billion Microsoft Corporation

    Introduction, How Well Does Microsoft Understand Cyber Security, The Importance of Active Directory Security, The Impact of an Active Directory Security Breach, The Active Directory Attack Surface, The Top-5 Security Risks to Active Directory, Active Directory Privilege Escalation, An Ocean of Access Privileges, AdminSDHolder, Active Directory ACLs - Attack and Defense (Actual),  Active Directory Effective Permissions, and so many more ...


  2. showed thousands of organizations worldwide How to Render Mimikatz DCSync Useless in their Active Directory

  3. helped millions of pros (like Mr. Metcalf) worldwide learn How to Correctly Identify Privileged Users in Active Directory

  4. helped the developers of BloodHound understand How to Easily Identify Sneaky Persistence in Active Directory

  5. helped Microsoft's ATA Team learn advanced stuff About Active Directory ACLs - Actual Attack and Defense

  6. showed CyberArk, trusted by 50% of Fortune 100 CISOs, How to Correctly Identify Shadow Admins in Active Directory

  7. helped cyber security startup Preempt's experts learn How to Correctly Identify Stealthy Admins in Active Directory

  8. helped the presenters of The Active Directory Botnet learn How to Easily Solve the Problem of Active Directory Botnets

  9. helped millions of cyber security folks worldwide understand and illustrate Active Directory Privilege Escalation

  10. Most importantly, I helped thousands of organizations worldwide, including Microsoft, understand the paramount importance of Active Directory Effective Permissions and Active Directory Effective Access to Active Directory Security


In fact, we're not just providing guidance, we're uniquely empowering organizations worldwide to easily solve these challenges.





Summary

All in all, its been quite an eventful year for Active Directory Security (, and one that I saw coming over ten years ago.)

In 2017, attackers, pen-testers and defenders finally seem to have realized the importance of Active Directory Security.


Perhaps, in 2018, they'll realize that the key to Active Directory Security lies in being able to accurately determine this.

Best wishes,
Sanjay.

PS: Why I do, What I do.

Friday, December 29, 2017

Why I do, What I do

Folks,

I trust you're well. Today, I just wanted to take a few minutes to answer a few questions that I've been asked so many times.


Here are the answers to the Top-5 questions I am frequently asked -

  1. You're the CEO of a company (Paramount Defenses), so why do you blog so often, and how do you have time to do so?

    Good question. This is a bit of a unique situation, in that whilst I am the CEO of a company, I am also a subject matter expert in Active Directory Security (simply by virtue of my background) and thus I feel that it is my civic duty to help organizations understand the paramount importance of securing their foundational Active Directory deployments.

    In fact, over the last 7+ years, I've penned 150+ blog posts on Active Directory Security (here) and Cyber Security (here) on various topics such as Active Directory Privilege Escalation, the OPM Breach, Kerberos Token Bloat, Eff Perms, AdminSDHolder, Mimikatz DCSync, Sneaky Persistence, How to Correctly Identify Stealthy Admins in Active Directory, How to Correctly Identify Shadow Admins in Active Directory etc. and most recently on Active Directory Botnets.

    As to how I have the time to do so, that's actually not that difficult. We have a world-class team at Paramount Defenses, and I've been able to delegate a substantial amount of my CEO-related work amongst our executive leadership team.




  2. Speaking of which, how big is Paramount Defenses?

    At Paramount Defenses, we believe that less is more, so our entire global team is less than a 100 people. For security reasons, 100% of our staff are U.S. Citizens, and to-date, the entirety of our R&D team are former Microsoft employees.

    If by how big we are, you meant how many organizations we impact, today our unique high-value cyber security solutions and insights help adequately secure and defend thousands of prominent organizations across six continents worldwide.




  3. Why is it just you (and why aren't your employees) on Social Media (e.g. LinkedIn, Facebook, Twitter etc.)?

    The simple answer to this question - For Security Reasons.

    At Paramount Defenses, we care deeply about cyber security, so we also strive to lead by example in every way.

    As it pertains to cyber security, we have found that the presence of an organization's employees on social-media almost always results in excessive information disclosure that could be very valuable for hackers and various other entities who may have malicious intent, so our corporate policies do not permit a social media presence.

    Also, we're not huge fans of Twitter, and we certainly don't care about being on Facebook. We do like and appreciate LinkedIn, and in fact, we lead the world's largest community of Active Directory Security Professionals on LinkedIn.




  4. What do you intend to accomplish by blogging?

    The intention is to help organizations worldwide understand just how profoundly important Active Directory Security is to organizational cyber security, and how paramount Active Directory Effective Permissions are to Active Directory Security.

    That's because this impacts global security today, and here's why -




    You see, the Crown Jewels of cyber security reside in Active Directory, and if they're compromised, its Game Over. By Crown Jewels, I'm referring to privileged access, or as commonly known, Domain Admin equivalent accounts.

    It is a fact that 100% of all major recent cyber security breaches (except Equifax) involved the compromise of a single Active Directory privileged user account. Such accounts are Target #1 for hackers, which is why it is so very important that organizations be able to exactly identify and minimize the number of such privileged accounts in Active Directory.

    Now, when it comes to identifying privileged user accounts in Active Directory, most organizations focus on enumerating the memberships of their default administrative groups in Active Directory, and that's it. Unfortunately, that's just the Tip of the Iceberg, and we have found that most of them do not even seem to know that in fact there are FAR many more accounts with varying levels of elevated admin/privileged access in Active Directory than they seem to know about.

    This isn't a secret; its something you know if you've ever heard about Active Directory's most powerful and capable cyber security feature - Delegation of Administration. The truth is that at most organizations, a substantial amount of delegation has been done over the years, yet no one seems to have a clue as to who has what privileged access. Here's why.

    In fact, Active Directory privileged access accounts have been getting a lot of attention lately, because so many cyber security experts and companies are starting to realize that there exists a treasure-trove of privileged access in Active Directory. Thus, recently many such cyber security expert and companies have started shedding light on them (for example, one, two, three etc.), and some have even started developing amateur tools to identify such accounts.

    What these experts and companies may not know is that their amateur tools are substantially inaccurate since they rely on finding out "Who has what Permissions in Active Directory" WHEREAS the ONLY way to correctly identify privileged user accounts in Active Directory is by accurately finding out "Who has what Effective Permissions in Active Directory?"

    On a lighter note, I find it rather amusing that for lack of knowing better, most cyber security experts and vendors that may be new to Active Directory Security have been referring to such accounts as Stealthy Admins, Shadow Admins etc.

    To make matters worse, there are many prominent vendors in the Active Directory space that merely offer basic Active Directory Permissions Analysis/Audit Tooling, yet they mislead organizations by claiming to help them "Find out who has what privileged access in Active Directory," and since so many IT personnel don't seem to know better, they get misled.

    Thus, there's an imperative need to help organizations learn how to correctly audit privileged users in Active Directory.

    Consequently, the intention of my blogging is to HELP thousands of organizations and cyber security experts worldwide UNDERSTAND that the ONLY correct way to identify privileged users in Active Directory is by accurately determining effective permissions / effective access in Active Directory. There is only ONE correct way to accomplish this objective.




  5. Why have you been a little hard on Microsoft lately?

    Let me begin by saying that I deeply love and care for Microsoft. It may appear that I may have been a tad hard on them, but that is all well-intentioned and only meant to help them realize that they have an obligation to their global customer base to adequately educate them about various aspects of cyber security in Windows, particularly the most vital aspects.

    In that regard, if you truly understand cyber security in Windows environments, you know that Active Directory Effective Permissions and Active Directory Effective Access play an absolutely paramount role in securing Windows deployments worldwide, and since Active Directory has been around for almost two decades by now, one would expect the world to unequivocally understand this by now. Unfortunately, we found that (as evidenced above) no one seems to have a clue.

    You may be surprised if I were to share with you that at most organizations worldwide, hardly anyone seems to even know about what Active Directory Effective Permissions are, let alone why they're paramount to their security, and this a highly concerning fact, because this means that most organizations worldwide are operating in the proverbial dark today.

    It is upon looking into the reason for this that we realized that in the last decade, it appears that (for whatever reason) Microsoft may not have educated its global customer based about Active Directory Effective Permissions at all - Proof.

    Thus, it is in the best interest of organizations worldwide that we felt a need to substantially raise awareness.

    As to how on earth Microsoft may have completely forgotten to educate the world about this, I can only guess that perhaps they must've gotten so involved in building their Cloud offering and dealing with the menace of local-machine credential-theft attack vectors that they completely seem to have missed this one paramount aspect of Windows security.

    Fortunately for them and the world, we've had our eye on this problem for a decade know and we've been laser-focused. Besides, actions speak louder than words, so once you understand what it is we do at Paramount Defenses, you'll see that we've done more to help secure Microsoft's global customer base than possibly any other company on the planet.

    Those who understand what we've built, know that we may be Microsoft's most strategic ally in the cyber security space.


Finally, the most important reason as to why I do, what I do is because I care deeply and passionately about cyber security.

Best wishes,

Wednesday, December 27, 2017

How to Easily Solve the Difficult Problem of Active Directory Botnets


Folks,

The year's almost coming to an end, and I just realized that one of the topics that I had not yet addressed as a part of my basic Active Directory Security School for Microsoft was this inane topic of Active Directory Botnets so today's post is on AD Botnets.

There's less than 100 hours left this year, and I value every minute, so this one's going to be short, yet sufficient.



Active Directory Botnets


Earlier this year, one of the two presentations on Active Directory Security at the famous Black Hat Conference USA 2017 was titled - The Active Directory Botnet. (The other one was An ACE Up the Sleeve - Designing Active Directory ACL Backdoors.)

Both of these presentations seem to have gotten a lot of attention, and as to the presentation on Active Directory Botnets, its authors said that this is (and I quote) "a nightmare of an implementation error with no easy fix!"


Well, today I'll show you just how easy it is to solve/fix this supposedly difficult problem :-)

In today's post, I am not going to go into the details of how attackers could set up these botnets because my focus is on helping organizations eliminate the very possibility of this issue, so if you're interested in the technical details, here are a few pointers -
  1. The slides of the presentation titled The Active Directory Botnet that was made at the Black Hat Conference 2017
  2. A video of the presentation titled The Active Directory Botnet that was made at the Black Hat Conference 2017
  3. A short interview with the presenters of this presentation.

Since my purpose is on helping organizations mitigate this issue, I'm going to focus on the mitigation aspect.




What Makes This Possible

In order to find out how to easily mitigate this issue, it helps to first understand what makes this issue possible in the first place.

Here's the short of what makes this all possible  -



As you may know, Active Directory, being the very foundation of cyber security in a Microsoft Windows Server network, stores and protects the entirety of an organization's domain user accounts, security groups, computer accounts, security policies etc.

As you may also know, in Active Directory literally everything is an object, and an object is essentially a collection of numerous attributes, as defined in the Active Directory Schema. So for example, there exist attributes for elements such as a user's first name, last name, password, manager, contact details, address details, user profile, a picture etc. etc.

Further, Active Directory's powerful security/delegation model makes it very easy for IT personnel to provision access in Active Directory for various stakeholders, to fulfill business needs wherein these stakeholders may need to be able to modify any of these fields/attributes. For example, if an HR application may have a need to change the Manager field/attribute on user accounts, such access can be very easily and precisely delegated for that HR application's service account.

Now, it turns out that by default, Active Directory also lets all domain user account holders modify certain fields/attributes on their own domain user accounts. Examples of such fields/attributes include Address, Assistant, Personal-Title, Phone-Home-Other, Phone-Ip-Other, Picture, Street-Address, WWW-Home-Page  etc. to name a few.

These attributes could store values of various data-types, so for instance, while some could simply and solely store a text string, others could store a distinguished name, and still others could store binary data. An example of an attribute that can solely store a text value is Surname and an example of an attribute that can store binary data is Picture.

Finally, to simplify access control, numerous such related fields/attributes can be aggregated together into an Active Directory construct known simply as a Property-Set.

Examples of Active Directory Property Sets include Personal Information, Private Information, Web Information, etc.


Tying all of the above together, in the access control list (ACL) of every domain user account, by default there are explicit access control entries (ACEs) that grant the security principal Personal Self, the ability to modify the Personal Information, Phone and Mail Options and Web Information property sets. Since the Personal Self  security principal on an Active Directory user object maps to the domain user account itself, the presence of these security permissions provides sufficient effective access to the domain user account holder to be able to modify all the attributes that are members of these property sets!

Now, imagine a scenario wherein the computer onto which this domain user account usually logs on has been compromised. In that scenario, the attacker could now have malicious code run in the security context of this domain user account, and if so, then one of the things that malicious code could do is update these attributes on the user's domain user account! 

In such a scenario, how the attacker chooses to use this default ability to update these attributes in Active Directory is purely a function of his/her imagination, and it so happens that in this particular case, the presenters of that specific presentation at Black Hat came up with a scenario wherein attackers could choose to use this default access granted to domain user accounts to introduce and operate Botnets in Active Directory environments!






How to Easily Solve the Supposedly Difficult Problem of
Active Directory Botnets -

According to the authors of this presentation, this is (and I quote) "a nightmare of an implementation error with no east fix!

If you ask me, I'll tell you "this is an issue that can be mitigated in minutes, and here's how" -



All that organizational IT personnel need to do is write a simple script whose purpose is simply to remove those explicit ACEs in the ACLs of domain user accounts in an Active Directory that grant the Personal Self security principal Write-Property permissions to the involved property sets.

Specifically, here are the three explicit ACEs that you may want to remove -
  1. { Allow   SELF   Read/write personal information }
  2. { Allow   SELF   Read/write phone and mail options }
  3. { Allow   SELF   Read/write web information }

Such a script can be written and be executed within minutes, and once it has been executed, there should no longer* be any ACEs in the ACLs of the organization's domain user accounts that would allow these domain user accounts the ability to modify these attributes on their own objects, and as a consequence, perpetrators will no longer be able to leverage this default modify access in Active Directory, resulting in a situation where this issue would no longer be an issue at all, since the underlying enabler of this issue would have been eliminated!
* Kindly see sections titled A Caveat and An Advanced Tip below

It really is as simple as this! That's it!


Now, some might ask - "But wouldn't this impact the ability to users to modify such attributes in Active Directory and/or cause potential application compatibility issues if certain apps were relying on this default access to properly function today?!"

The answer to that question is that realistically speaking, domain user accounts holders should not ideally possess any level of modify access in the Active Directory, and most likely no default applications should be relying on this default access granted to domain user accounts to function, so the application compatibility impact of making this change could be none to minimal.
Disclaimer: Organizations know their unique Active Directory environments best, so before acting on this advice, organizations will want to ensure that there in fact are no Active Directory integrated applications or business use-cases that leverage this default modify access granted to domain users on their accounts. This advice is provided on a best-efforts basis and your use of it is subject to our Terms of Use.

That's literally all there is to it, and that is literally how easy it is to solve this inane problem!





One Caveat

There is ONE caveat that could possibly still enable a perpetrator to still try and leverage the limited write-property access that might remain even after you remove each one of those explicit ACEs that grant SELF modify access to those property sets.

Here's the caveat - at the domain root, there is an inheritable permission specified that is inherited by all objects, including all user objects, and it grants SELF the ability to read and write the Private Information property set -  { Allow   SELF   Special }



Members of the Private Information property-set include* - 
  1. ms-PKI-Credential-Roaming-Tokens
  2. MS-PKI-RoamingTimeStamp
  3. MS-PKI-DPAPIMasterKeys
  4. MS-PKI-AccountCredentials
* This property-set has the above four members in Windows Server 2008 R2 and beyond.


As a result, theoretically speaking, a perpetrator could possibly try to use these attributes to achieve the same mal-effect.

However, in practice, should the system be using these attributes, then any values that the perpetrator might write into these attributes will likely get overwritten by whatever the system writes into them, thus in practice rendering that option infeasible.

Of course, if you know for a fact that these attributes are not being used in your environment, then you can simply remove this ACE from the domain root, which will then have the effect of it being removed from all domain user accounts as well.
Disclaimer: Organizations know their unique Active Directory environments best, so before acting on this advice, organizations will want to ensure that there in fact are no Active Directory integrated applications or business use-cases that leverage this default modify access granted to domain users on their accounts. This advice is provided on a best-efforts basis and your use of it is subject to our Terms of Use.





An Advanced Tip

Those who know the subject well know that even if each one of these ACEs no longer exist, a user could still possibly have sufficient effective permissions so as to be able to modify one or more attributes on the domain user account, should there be other permissions in the ACL of the account that might effectively grant the user sufficient effective access so as to be able to do so. The only way to correctly find out whether or not a user can in fact still modify attributes on his/her domain user account is by accurately determining Active Directory effective permissions on that domain user account.

Gold Finger Active Directory Effective Permissions Calculator

For instance, in the snapshot above, one can see that on the domain user account of a user, Jeff Bezos, the user Jeff Bezos still has write-property effective permissions to the Phone-Ip-Other attribute (which is a member of the Personal Information property-set), and he has this access on his own account not by virtue of those SELF ACEs but in fact by virtue of the fact that there exists an ACE that grants the IT Cloud DevOps Team domain security group, of which he is a member, Write-Property information to the Personal Information property set.

The likelihood of this is low, yet in the interest of completeness, since it is always a possibility, I felt the need to mention this, and security conscious organizations will want to take Active Directory Effective Permissions into account for completeness.





Summary

Today, I just wanted to take a few minutes to share with you just how easily organizations worldwide can solve this supposedly difficult problem of Active Directory Botnets! Of all the problems I've helped solve this year, this one was by far the easiest.


The short of it is that this inane issue can be mitigated within minutes by simply using basic scripting to remove the very ACEs that grant domain user accounts the ability to modify the attributes that this attack vector leverages. It really is as simple as that!

I apologize if this post was short and to the point. I usually spend a lot more time on my posts, but its almost the end of the year, and my time is very valuable, so I decided to keep it short. Besides this is so easy, that it only needed minutes to address.

Best wishes,
Sanjay

Saturday, December 23, 2017

Just ONE Question to Microsoft & Preempt re Security Advisory 4056318 and Active Directory Privilege Escalation in Office 365 / Azure AD Connect

(About the Flaw in Azure AD Connect Software That Can Allow Stealthy Admins to Gain Full Domain Control)



Folks,

On Dec 12, 2017, Microsoft issued Security Advisory 4056318 in response to a flaw that Preempt discovered in Microsoft's Azure AD Connect software that lets its customers synchronize directory data between their on-premises AD and Azure AD.


This is rather important, as evidenced by this headline - Microsoft launches privilege escalation attack on itself with Office 365 !

Indeed, Microsoft may just shot themselves (and their customers) in the foot by making one HUGE careless mistake!

I thought I'd share a few thoughts.



First, a quick SUMMARY

Here's the summary of the flaw -
Preempt (a startup, more on which below) discovered that when organizations run Azure AD Connect to integrate their on-premises Active Directory with Azure Active Directory, if they select Express Settings during installation, then the domain user account MSOL that is created for Azure AD Connect is granted the Get Replication Changes All extended right on the domain root (, so that it can sync content, including passwords,) YET this account is NOT afforded special protection under the umbrella of AdminSDHolder, AND AS A RESULT, this results in a non-administrative / non-privileged domain user account possessing what is clearly tantamount to administrative / privileged access in Active Directory, thus paving an Active Directory Privilege Escalation path.

What I've shared above is the essence of this issue. In short, if you run Azure AD Connect and select Express Settings, you will have introduced in your environment a privilege escalation path leading from a delegated admin to Domain Admin (equivalent) !




The VULNERABILITY

Herein lies the flaw/vulnerability -
Since this MSOL account is not protected by AdminSDHolder, its ACL (access control list) is neither protected nor locked-down, and thus it could easily contain many ACEs (access control entries), some Explicit, and others Inherited from its parent, that could in effect end up granting numerous non-privileged users sufficient Active Directory effective permissions (e.g. Reset Password, Modify Permissions,Modify Owner) on it so as to be able to obtain control over this account and then misuse the Get Replication Changes All effective permissions that this account has on the domain root by using tooling like Mimikatz DCSync to instantly compromise the passwords of every single account in the Active Directory, including those of all Active Directory privileged users!

Thus, this one little Active Directory ACL misconfiguration automatically enables this scenario - Massive Cyber Security Breach !

By the way, if you want to know who can reset the MSOL account's password today, all you have to do is touch a button.





A QUESTION to MICROSOFT

You do realize that a single such mistake could instantly jeopardize the security of thousands of organizations worldwide, yes?


Question: Since WHEN did we become SO careless?! How could this have passed basic vetting? I had just asked a question a few weeks ago, with the hope that y'all would start taking this seriously - How Well Does Microsoft Understand Cyber Security ?!

This stuff is very important, and I know you're capable of much better than this, so can we please be more careful next time?!

(It appears to me that you may likely not have the right set of folks working on Active Directory Security. If you need me to help you identify the right set of Microsoft employees that should be working on AD Security, or help you out generally, let me know.)





PREEMPT ISSUES ITS OWN GUIDANCE

Preempt, in addition to having found this flaw and reported it to Microsoft, also issued its own guidance for organizations.

Here it is - Advisory: Flaw in Azure AD Connect Software Can Allow Stealthy Admins to Gain Full Domain Control.

You'll want to read it, as here are the parts they discussed - Understanding Stealthy Admins, Details on the Azure AD Connect Account Flaw, Who is Impacted, How Stealthy Admins can be Exploited, How Organizations can Protect Themselves, Free Preempt Inspector Tool for Determining if you are at Risk. They even made two videos, and uploaded them to YouTube .

They also shared that Microsoft has acknowledged the issue and released a Microsoft Security Advisory and a PowerShell script that address the flaw by adjusting the permissions of the Active Directory domain accounts to address this issue.

Finally, they issued guidance on how organizations can protect themselves -
  1. Review all stealthy administrators in your network
  2. For each stealthy admin, decide whether added permissions are indeed necessary
  3. Protect your privileged (known and stealthy) users by adding protection

Their guidance ends with:  FREE TOOL: Download Preempt Inspector to see if you have stealthy admins in your organization.

Their simple, well-intentioned guidance is spot-on. Can the same be said about their tooling? Well...  (keep reading.)




SOME GUIDANCE FOR PREEMPT

Since Preempt has been so helpful to a company I so love i.e. Microsoft, by discovering this flaw and sharing it with Microsoft, perhaps the gentlemanly thing to do here would be to return the favor by sharing a few thoughts with them -

  1. As you'll hopefully agree, if there exist such "Stealthy Admins" in Active Directory, then it is paramount that organizations be able to accurately identify all such "Stealthy Admins", because even just ONE such account could be used to gain complete command and control over Active Directory, and consequently over the entire network.

  2. This notion of "Stealthy Admins" that you likely seem to have introduced, as likely did CyberArk the notion of "Shadow Admins", does sound very catchy, but it is not actually new. What you seem to be referring to as "Stealthy Admins" is actually what thousands of organizations have, for almost two decades now, known simply as Delegated Admins.

  3. I thought I'd share that in 2016, we had informed the Chairmen, CEOs and CFOs of the world's top 200 organizations, as well as MSRC that due to one specific deficiency in Active Directory, there likely exist hundreds of such stealthy / shadow admins (and thus thousands of privilege escalation paths) in most Active Directory deployments worldwide?

  4. Did you know that most vendors in the Active Directory space do not seem to know that to correctly identify stealthy / shadow admins in Active Directory, one needs to be able to determine Active Directory Effective Permissions ?

  5. Finally, I do recall having read a few articles on this very subject on the Internet (; if you merely replace the term "Delegated Admins" with "Stealthy Admins" in these articles, they may all sound very familiar) -

    1. From way way back in 2013 - Active Directory Privilege Escalation  (+ again in 2017)

    2. From way back in 2014 - Using Password Resets to Escalate Privilege in Active Directory   (+ again in 2017)

    3. From back in 2015 - How to Identify and Minimize Privileged Users in Active Directory

    4. From 2016 - 10 Examples of Delegated (Stealthy) Admins in Active Directory

    5. From 2017 - How to Correctly Discover Stealthy Admins in Active Directory + 50 More

Thus, Preempt's focus on Stealthy Admins in Active Directory is spot-on, but the Bible on the subject has already been written.




A QUESTION TO PREEMPT

Finally, since Preempt's experts seem to be proficient at finding flaws, thought I'd ask most respectfully ask them a question -

The Question: Preempt, are you SURE that your free tool Preempt Inspector, which you've been recommending to organizations worldwide as a means to identify all Stealthy Admins in Active Directory deployments, can in fact accurately identify Stealthy Admins in Active Directory?  (or could there potentially be a(n equally big) flaw in it?)


Again, I ask this most respectfully, and I only ask this because
as you'll hopefully agree, accuracy after all is paramount.



The answer, in days to come
(; it'll be very similar to this.)


That's all for now.

Best wishes,
Sanjay.



PS: By the way, Microsoft's guidance in its Security Advisory 4056318 is INSUFFICIENT, in that even if you enacted it exactly as specified, you may still be left exposed. If you want to know why, please feel free to tune in here in a few days, or to ask us.

Thursday, December 21, 2017

A Very Simple and Fundamental Cyber Security Question

Folks,

Today, I'd like to ask a very simple question to you all, and I do so because this too impacts cyber security worldwide.

Question - When a Cyber Security company develops, releases and promotes the use of a security product (i.e. one that potentially thousands of organizations worldwide may use and rely on to make mission-critical cyber security decisions,) irrespective of whether it may be free software or not, does the company put its credibility on the line vis-à-vis the reliability of that product?

Context: If subsequent to the release of such a security product by a company, it is found / discovered that this product is actually unreliable in that it may be delivering (substantially) inaccurate information, reliance upon which could result in thousands of organizations worldwide making inaccurate access-control decisions, which could then leave them with a false sense of security, and thus potentially vulnerable to the risk of compromise, then could such a finding impact the credibility of this company?

Potential Answers:    A) YES   or   B) NO


I'd encourage everyone to give this question a few minutes of thought.

Best wishes,
Sanjay

Tuesday, December 12, 2017

How to Correctly Discover Shadow Admins in Active Directory

Shadow Admins - The Stealthy Accounts That You Should Fear The Most, but Needn't Anymore


Folks,

A few weeks ago, CyberArk, a $ Billion+ cyber security company in the Privileged Account Security space, published guidance on how organizations could identify dangerous "Shadow Admin" accounts that exist in almost every Active Directory today.

Here's their blog post - Shadow Admins - The Stealthy Accounts that You Should Fear The Most.


Unfortunately, their well-intentioned guidance (and accompanying tooling) for organizations worldwide, although on-point concerning the real danger that undetected "Shadow Admins" pose to organizations, seems substantially inaccurate.

Thus, to help CyberArk's own cyber security experts, as well as to help all IT and Cyber Security professionals at thousands of organizations better understand this subject, today, I'll show you how to correctly identify "Shadow Admins" in Active Directory.

This is Part II of the following, so you'll absolutely want to read - Paramount Privileged Account Security Guidance for CyberArk.

Pre-Requisites: To follow the contents of, and the examples shared in this post, you'll want to read the following -
  1. Shadow Admins - The Stealthy Accounts that You Should Fear The Most
  2. Paramount Privileged Account Security Guidance for CyberArk




First, Some Quick Background

As we all know, over 85% of organizations worldwide operate on Microsoft's Windows Server platform, and in IT infrastructures powered by Windows Server, at the very heart of cyber security and privileged access lies Microsoft Active Directory.


Not only does Active Directory store and protect the most powerful administrative/privileged accounts in a Windows network, it is also the focal point of  administrative delegation, and over the last 17 years, at most organizations, a substantial amount of access provisioning has been done in Active Directory, both to delegate administrative authority and to fulfill business needs.

Consequently, generally speaking, there are 3 levels of privileged access in Windows networks -
  1. Local administrative/privileged access on domain-joined machines
  2. Delegated administrative access within Active Directory
  3. Unrestricted privileged access (accounts and groups) in Active Directory

Of these 3 levels of privileged access, 1 is least powerful and 3 is most powerful. Level 2 is interesting because depending on the access provisioned/delegated, many level 2 access holders, unbeknownst to anyone, could in fact possess Level 3 access!

Now, consider Level 2 accounts that may not be members of any default admin (privileged) access group in Active Directory.

Should any of these Level 2 accounts directly or indirectly have certain modify access effectively allowed on one or more level 3 accounts or groups, then in effect even though they're not members of any default administrative (privileged) access groups in Active Directory, they would still have access that it tantamount to possessing unrestricted privileged access in Active Directory, and it is such accounts that CyberArk's experts are referring to as "Shadow Admins."

Further, since these accounts are not members of any default admin Active Directory groups, and the extent to which most organizations go to identify privileged users in Active Directory is to enumerate the membership of these default admin groups, at most organizations all such accounts will likely remain undetected, even though a proficient intruder who knows how to identify such accounts could easily identify and subsequently exploit them to effortlessly obtain complete command and control over the entire organization!

Up until this point, CyberArks guidance is accurate.




Ah, Active Directory Effective Permissions 

Now consider this - consider the domain user account of an ordinary user John Doe. Assume that he is not a member of any default admin (privileged) user group in Active Directory. Further assume that in the ACL of the Domain Admins group, he has been directly granted the following Active Directory security permissions -  { Allow John Doe Write-property Member }

Based on the above, do you think John Doe will be able to modify the membership of the Domain Admins group?

Most IT personnel, including CyberArks experts will likely say - YES!

However, if you ask an Active Directory Security expert, his answer will be - Maybe. (It depends.)

So, what does it depend on?!

Consider this. Imagine that there is a security group in Active Directory called Active Directory Security Novices and assume that this security group is NOT a member of any default Active Directory admin groups. However, assume that perhaps a few months ago, someone specified ANY ONE of the following several security permissions in the Domain Admins group's ACL -
  1. { Deny Active Directory Security Novices Write-property Member } OR
  2. { Deny Active Directory Security Novices Write All Properties } OR
  3. { Deny Active Directory Security Novices Full Control }

Now, if you ask an Active Directory Security expert, his answer will still be - Maybe. (It depends.)

The reason it is still Maybe, is because it depends on whether these Deny permissions were explicit (i.e. specified directly in the object's ACL) or whether they were inherited, and whether the Allow permissions for John Doe are explicit or inherited.

If these deny permissions were explicit, then even though there exists an { Allow John Doe Write-property Member } permission for John Doe in the ACL of the Domain Admins group's object, John Doe will NOT be able to change the group's membership!

What I have just shared with you is a very highly simplified example of Active Directory Effective Permissions.


Thus, if one were to merely "search and analyze the ACL permissions granted to each account" one could easily end up with inaccurate results, and in security, even ONE such inaccuracy could mean the difference between secure and breach!

This is where CyberArk's guidance is inaccurate.

Specifically, their guidance and tooling does NOT involve determining effective permissions in Active Directory; it merely involves searching Active Directory ACLs for any permissions granted to individual user accounts, and as we have just seen, such an approach is not only the incorrect way to discover such "Shadow Admin" accounts, it is also dangerously misleading!




The Only Correct Way

The only correct way to find out who actually has what access, including privileged access, in Active Directory is to accurately determine effective permissions in Active Directory. There is NO other way to accurately make this determination. Period.

In fact, Active Directory Effective Permissions are paramount to cyber security because they determine exactly who can do what on any and every object in Active Directory, from the CEO's domain user account to the Domain Admins domain security group!

It is for this simple reason that an organization that does not possess the ability to accurately identify effective permissions in Active Directory could not possibly adequately secure and defend its foundational Active Directory deployment.




Lets See a Demo -

Let us see this in action. In order to keep this very simple, we've used the same domain name for our test Active Directory so that everyone can follow this as an assumed continuation of the examples shared in CyberArk's post.


The Setup

We begin by installing a brand-new Active Directory domain, so it only has default administrative groups and default ACLing.


For our demo, to begin with, we'll create only five objects -
  1. An OU named Demo, to store our demo accounts and groups
  2. A regular domain user account named James
  3. A regular domain user account named Emily
  4. A regular domain security group named Cyberdark Gurus
  5. A regular domain security group named Active Directory Security Novices

That's it. We do not need to create any other objects right now as we're trying to keep this super simple.

Note: Please note that each one of these two domain user accounts and two domain security groups are regular accounts and groups i.e. they are not members of any default Active Directory administrative groups.


The only other thing we will do is make the Cyberdark Gurus group a member of the Active Directory Security Novices group -


Thus, as you can see above, the Cyberdark Gurus group is now a member of the Active Directory Security Novices group.



Demo #1

To begin, we make James a member of the Cyberdark Gurus domain security group -


Next, we will modify the (up until now) default ACL on the Domain Admins security group, and specify the following two explicit permissions -
  1. { Deny Active Directory Security Novices Special* }
  2. { Allow James Write-Property Member}
Special*: Modify Owner, Modify Permissions, Delete, Delete Tree, All Extended Rights, All Validated Writes AND Write All Properties. (We could've easily just denied Write-All Properties and that would have been sufficient.)

Here is the resulting ACL on the Domain Admins security group -



Since we're unable to view the Special permissions in ADUC, we can launch this tool to view the ACL more clearly -



As seen above, we can now clearly see the two permissions we just added (; see Rows #1 and #2.)

Now, as we can see there is clearly a permission allowing James Write-Property member on the Domain Admins group, so does this mean that he is a "Shadow Admin" who can change the Domain Admin group's membership?


To see what CyberArk's ACLight tool determines, let's run it and examine its findings/results -



ACLight has finished its analysis, so let us view its results -


Per ACLight, James is a "Shadow Admin" because the tool seems to have determined that James can modify the membership of the Domain Admins group, as there is an Allow permission granted to him directly in the ACL of the Domain Admins group.

To verify this finding perhaps we should login as James and try to modify the membership of the Domain Admins security group, and see if we are able to succeed in doing so -



As you can see above, the Add and Remove buttons are disabled, which is because ADUC has determined that James does not in fact have sufficient access so as to be able to do so!

Hmm... does this mean that ACLight's findings are inaccurate? Is there even a way to verify this?


Well, let's launch the world's only accurate Active Directory Effective Permissions Calculator, and see what it reveals -


According to this tool, James is NOT on the list of individuals who have sufficient Write-Property Member effective permissions on the Domain Admins security group, and since he is not on the list, according to this tool's findings, he cannot in fact change the membership of the Domain Admins security group, and thus he is NOT a "Shadow Admin"!

In other words, CyberArk's ACLight tool is delivering inaccurate results, because as we have experimentally verified as well, James was NOT in fact able to modify the Domain Admins group membership!

To conclude Demo #1, let us examine why he was not able to do so.

Let us take a closer look at the ACL of the Domain Admins group -


As we can see, the explicit Deny Write All Properties permission specified for Active Directory Security Novices will override the explicit Allow Write-Property Member permission specified for James, BECAUSE James is a member of the Cyberdark Gurus group, which in turn is a member of the Active Directory Security Novices group (which is something not readily apparent here!)

Now, in case you're a CISO or someone who may not know as much about Active Directory effective permissions, you can still make this determination most easily by using the second tool on this page -


As you can see, this tool make this determination and provides its output in plain English, completely obviating the need for you to know any Active Directory security technical details.

Thus, we just saw and verified that indeed the ACLight tool is NOT delivering accurate results!

Before moving on to the second demo, you'll want to undo these two ACL changes to continue to keep it simple.




Demo #2

For our second demo, we'll create a new domain user account called SysAdmin in the Users container, and then we will add it to the default Builtin Admins (i.e. Administrators) group so that it is now a privileged user account -


Now that we have an additional privileged user account to experiment on, let's proceed with demo #2.

To begin, we make Emily a member of the Cyberdark Gurus domain security group -



Next, we will modify the (up until now) default ACL on the SysAdmins privileged domain user account, and specify the following two explicit permissions -
  1. { Deny Active Directory Security Novices All Extended Rights }
  2. { Allow Emily Extended Right Reset Password}

Here is the resulting ACL on the SysAdmin privileged user account -



Again, to see these permissions most clearly, let us view this object's ACL using this tool -



As seen above, we can now clearly see the two permissions we just added (; see Rows #1 and #2.)

Now, as we can see there is clearly a permission allowing Emily the Reset Password extended right on the SysAdmins account, so does this mean that she is a "Shadow Admin" who can reset the SysAdmin's privileged user account's password?


To see what CyberArk's ACLight tool determines, let's run it and examine its findings/results -



ACLight has finished its analysis, so let us view its results -


Per ACLight, Emily is a "Shadow Admin" because the tool seems to have determined that Emily can reset the password of the SysAdmins user account, as there is an Allow permission granted to her directly in the ACL of the SysAdmins account.


To verify this finding perhaps we should login as Emily and try to reset the password of the SysAdmins privileged user account, and see if we are able to succeed in doing so -



As you can see above, Emily is unable to reset the password of the SysAdmins privileged user account and ADUC has displayed the message "Windows cannot complete the password change for SysAdmin because: Access is Denied." In other words Emily does not in fact have sufficient access so as to be able to do so!

Hmm... does this mean that ACLight's findings are inaccurate?

Let's launch the world's only accurate Active Directory Effective Permissions Calculator, and see what it reveals -


According to this tool, Emily is NOT on the list of individuals who have sufficient Reset Password extended right effective permissions on the SysAdmins domain user account, and since she is not on the list, according to this tool's findings, she cannot in fact reset the SysAdmins privieged user account's password, and thus she too is NOT a "Shadow Admin"!

In other words, CyberArk's ACLight tool appears to have yet again delivered inaccurate results, because as we have experimentally verified as well, Emily was NOT in fact able to reset the SysAdmins privileged account's password!

To conclude Demo #2, let us examine why she was not able to do so.

Let us take a closer look at the ACL of the SysAdmins privileged user account -



As we can see, the explicit Deny All Extended Rights permission specified for Active Directory Security Novices will override the explicit Allow Reset Password Extended Right permission specified for Emily, BECAUSE Emily is a member of the Cyberdark Gurus group, which in turn is a member of the Active Directory Security Novices group (which too isn't apparent here!)

Now, in case you're a CISO or someone who may not know as much about Active Directory effective permissions, you can still make this determination most easily by using the second tool on this page -


As you can see, this tool make this determination and provides its output in plain English, completely obviating the need for you to know any Active Directory security technical details.

Thus, we just saw and verified twice that indeed the ACLight tool is NOT delivering accurate results!




Domain-wide Assessment

Now, some of you may find yourself pointing out that the tools we used above only seem to be able to determine effective permissions/access on a per object basis. That is in fact right, and yet they are the only tools on the planet that can accurately determine effective permissions and effective access in Active Directory.

However, there is hope. Organizations can in fact make these determinations domain-wide today by using the following tool, which is the world's only accurate Active Directory Administrative Access / Delegation Audit Tool - 


This tool can make these determinations domain-wide, i.e. on thousands of objects in an Active Directory domain, in a single assessment, at the touch of a single button, and usually within minutes!

Perhaps, if we were Active Directory novices, we may have called is an Active Directory Shadow Admin Discovery/Audit Tool, but since we're experts, we know that what are being referred to as "Shadow Admins", "Stealthy Admins" etc. are merely just "Delegated Admins" in Active Directory, thus the name of this tool i.e. Active Directory Access and Delegation Audit Tool.

In fact this tool above can do in minutes what a thousand Active Directory security experts put together couldn't accomplish in a year, and do so in real (complex) Active Directory environments comprised of thousands of objects, accounts and groups.

Finally to anyone or any organization who may be inspired to make such a tool, by all means, please go ahead and try it. It took us six years of highly disciplined laser-focused Research and Development to build our tooling, and we know a thing or two about Active Directory Security. Should you like some guidance, you may want to read our 120-page patent on how to do so.

That wraps up the Demo.

Note: These two demos above were purposely keep super simple so that anyone (including CyberArk's experts) could replicate these exact steps in any new Active Directory domain and verify that what we have demo'ed above is accurate.




Complexity

Now, if these examples look so simple, that's because they were intended to look simple for illustrative purposes.

In reality, the challenge is exponentially hard. Consider a typical Active Directory deployment - there could easily be well over a hundred ACEs in the ACL of each Active Directory object, there could possibly be thousands of domain security groups to which users could belong, and many of these domain security groups could possibly be nested in other domain security groups, and some of these could be circularly nested, and there could be a substantial amount of administrative delegation and/or access provisioning done in Active Directory, and there could easily be thousands of objects in an Active Directory domain and there could possibly be numerous domains in an Active Directory forest.

Any tool designed to accurately identify such "Shadow Admin" accounts would have to be able to accurately determine effective permissions on every single one of thousands of object in Active Directory, in light of the complexity that I've just shared above.

Based on my assessment, not only does CyberArk's ACLight not evaluate effective permissions in Active Directory, it is light years away from being able to do what I've just described above. The same is true of every other tool you may have heard of out there, including BloodHound, or any PowerShell script anyone could ever write, or anything available from Microsoft.

There is only ONE tool that I know of that can accomplish this monumental feat - its this one, and I know so because I built it.



Summary

Folks, in closing, Privileged Account Security is paramount to organizational cyber security, and please don't just take my word for it, for here's CyberArk communicating in effect the same fact -
"Privileged accounts represent the largest security vulnerability an organization faces today. These powerful accounts are used in nearly every cyber-attack, and they allow anyone who gains possession of them to control organization(al) resources, disable security systems, and access vast amounts of sensitive data."
As I've said above, CyberArk is 100% right. The compromise of even just 1 (i.e. ONE) such privileged account could easily grant perpetrators complete command and control over your entire network and empower them to swiftly take over everything.

In fact, 100% of all major recent high-impact cyber security breaches (E.g. Snowden, Target, JP Morgan, Sony, Anthem, OPM) involved the compromise and subsequent misuse of a single, i.e. just ONE Active Directory Privileged User Account.


CyberArk is also 100% right that in most Active Directory deployments worldwide, today there likely exist a dangerously and excessively large number of such "Shadow Admin" accounts, that for all practical reasons possess the same level of privileged access as do members of default Active Directory administrative / privileged access groups, yet because they're not members of any default Active Directory privileged access groups, these accounts are in fact very difficult to accurately identify.

Consequently, their presence may possibly post a FAR greater risk to organizational cyber security, which is why it is so very important for organizations to be able to accurately discover/identify all such accounts i.e. each and every single one of them.

In this blog post, I wanted to show you why CyberArk's well-intentioned guidance and tooling are in fact inaccurate, as well as show you why we need to be able to accurately determine Active Directory Effective Permissions / Active Directory Effective Access to correctly discover all such "Shadow Admin" accounts in Active Directory.

I hope you've found this to be helpful, and I wish you all, including CyberArk, all the very best.

Best wishes,
Sanjay


PS: Recommended Technical Reading -
  1. Active Directory Privileged Access Insight
  2. Active Directory Effective Permissions
  3. Defending Active Directory Against CyberAttacks (Slide 88 alludes to CyberArk)
  4. The Impact of Compromise of Shadow Admin Accounts in Active Directory
  5. How to Audit Who Can Change Group Memberships in Active Directory?
  6. How to Audit Who Can Delete an Organizational Unit in Active Directory?
  7. How to Audit Who can Create User Accounts in Active Directory?
  8. How to Audit Who can Reset Domain User Accounts Passwords in Active Directory?
  9. How to Correctly Audit/Identify/Discover Privileged Accounts in Active Directory
  10. Active Directory Access Control Lists (ACLs) - Real Attack and Defense