The American Defense Industrial Complex operates on Active Directory

Folks,

From the U.S. Department of Defense to the Israeli Defense Forces, Microsoft to Nvidia, and Lockheed Martin to Palantir, today virtually the entire American Defense Industrial Complex operates on Microsoft Active Directory.

In fact, the entire United States Government, as well as the Fortune 100 and Wall Street also operate on Active Directory.

For those who may not know, Active Directory is one of the most important and trustworthy foundational technologies ever built, and it provides two paramount imperatives that the Cloud cannot - operational autonomy and organizational privacy.

Consequently, Active Directory lies at the very foundation of national security, defense and corporate security worldwide.

The National Security Agency Agrees

The stated mission of NSA in cybersecurity is to prevent and eradicate threats to U.S. national security systems with a focus on the Defense Industrial Base and the improvement of its weapons’ security.

Active Directory Security is so important to global security, that just last fortnight, the National Security Agency (NSA) and the Australian Signals Directorate (ASD) issued joint guidance on how to mitigate Active Directory attacks, and I quote -

"Active Directory is the most widely used authentication and authorization solution in enterprise Information Technology (IT) networks globally." 

"Like numerous other networks, Active Directory is used in many Department of Defense and Defense Industrial Base networks as a critical component for managing identities and access,” 

“This makes it an attractive target for malicious actors to attempt to steal the proverbial ‘keys to the kingdom. Taking steps to properly defend AD from these common and advanced techniques will detect and prevent adversary activities and protect sensitive data from determined malicious cyber actors.”

To state it as simply as one can, the National Security Agency (NSA) of the United States of America just confirmed not only what we've been saying for years, but also the paramount importance of what it is we do at Paramount Defenses. 

You see, the number one way to steal the proverbial Keys to the Kingdom that the NSA is referring to is Active Directory Privilege Escalation, and in fact we had released the underlying technical facts in The Paramount Brief way back (2014).

I wonder what took the NSA so long. We've been saying this for a decade - 2014, 2015, 2016, 2017, 2018, 2019, 2020.

This is Paramount

The accurate assessment of privileged access in Active Directory is absolutely paramount to organizational cyber security.

As every cyber security professional, Domain Admin and CISO worth his/her salt knows well, the most important (the #1) measure in all of organizational cyber security and in Active Directory security is the attainment of Least Privilege Access (LPA) in Active Directory, which involves accurately assessing and then locking-down privileged access in Active Directory, and one simply cannot do so without the ability to accurately assess privileged access in Active Directory. 

Decision Support (aka Proof)

At the heart of both the SolarWinds Breach and the Colonial Pipeline Hack lay privileged access in Active Directory.

Both these attacks could've been prevented if only organizations had attained and maintained LPA in Active Directory. 

Here's why / consider this - the Top-5 ways of escalating in privilege in Active Directory are i) DC Sync eff-perms / WD eff-perms on domain root, ii) WD eff-perms on AdminSDHolder, iii) CR-Reset Password eff-perms on any AD admin account, iv) WP-member eff-perms on any AD admin group, and v) WP - GP Link and GP Options eff-perms on the default DC OU.

Anyone who has any of these eff-perms in AD owns the organization, and can completely destroy it, should they so desire, so at an absolute minimum*, assessing and locking-down the above eff-perms domain-wide is absolutely paramount.

*Oh, and this is merely the tip of the iceberg. Consider the following - 

Anyone and everyone who has { CR-Reset Password or WD or WO } eff-perms on any AD user account in the domain can own that account in one second, anyone who has { WP-Member or WD or WO } eff-perms on any AD group in the domain can control that group in one second (and access everything it protects), anyone who has { WD or WO } eff-perms on an(y) OU in the domain can own every* object in that OU, easily escalate privilege and/or control and/or destroy everything in it.

Pro Tip for Amateurs - Count the number of times I've said eff perms above, because it is NOT perms, but eff-perms (aka Active Directory Effective Permissions) that control everything in AD. Permissions analysis is almost useless. 

Organizations that do not know who has what eff-perms in their AD are dangerously operating in the proverbial dark.

Extremely Difficult

The accurate determination of access entitlements, i.e. who has what privileged access where and how, in Active Directory is extremely difficult and error-prone, and likely one of the biggest challenges in organizational cyber security today.

It is extremely difficult because it involves analyzing millions of individual access control specifications that cumulatively impact resultant access, and thus is involves meticulously connecting millions of dots with absolutely zero room for error.

There is no room for error, because like performing heart surgery or screening baggage at airports, even a single error could result in an unmitigated privilege escalation path that could be used to completely destroy an entire organization.

The process is akin to finding a thousand unique needles in a haystack the size of One World Trade Center, New York, wherein in order to ensure security, it is paramount that each and every single needle in the entire haystack be found. 

Mission Accomplished

For anyone who may not yet know, there is one and only cyber security solution in the entire world that can accurately assess privileged access in Active Directory - our unique, unrivaled, all-American, Microsoft-endorsed Gold Finger.

Gold Finger is the only cyber security solution in the world that can accurately assess access entitlements i.e. who has what privileged access in Active Directory, based on the accurate determination of effective permissions in Active Directory.

Let there be no ambiguity about that cardinal technical fact, none whatsoever. Although there are over twenty solutions that claim to be able to assess privileged access in Active Directory, not even one of them can do so accurately, because there is one and only correct way to accurately assess privileged access in Active Directory and that involves the accurate determination of Active Directory Effective Permissions, which is extremely difficult, and none of those solutions do so.

Not a single one of them.

As such, the method and system for the accurate determination of who has what access entitlements in Active Directory, including of course privileged access, and privilege escalation paths, is governed by our patent, U.S. Patent 8429708.

The Bible of Access Assessment

I should also mention this is no ordinary patent. It is the Bible of how to accurately assess access in an IT system, wherein access is controlled using ACLs, and today, over 75 patents from many of the world's top cyber security companies cite it, including Microsoft, Amazon, IBM, VMWare, McAfee, CyberArk, FireEye, Dell, VMWare, Palantir and others.

Our patented, Microsoft-endorsed accurate effective access assessment capabilities are embodied in our Gold Finger, Gold Finger Mini and Gold Finger 007G solutions, are unique in their ability to enable organizations to fulfill this paramount objective and over the last decade, from the U.S. DoD to the United Nations and from the U.S. Treasury to several Fortune 100 companies, they have been instrumental in helping so many important organizations attain and maintain LPA in AD.

Simply Unrivaled  (F-35)

To give the world an idea of just how capable and superlative our access assessment technology is, consider this -

Gold Finger can accurately assess exactly who has what privileged access, where and how, domain-wide in any Active Directory domain in the world, comprised of thousands of objects, within just minutes, and at the touch of a button. 

To put that in perspective, in less time than the Generals in the U.S Military can brief the U.S. Secretary of Defense as to the state of cyber security of their respective forces, or for that matter in less time than the CEO of Microsoft has an hourly meeting with his top cyber security experts, Gold Finger can find out exactly who has not just the Keys to the Kingdom, but also who has the keys to every single door in the kingdom, in every Active Directory domain in the U.S. Dept. of Defense.

In fact, we recently offered to give away up to one hundred million dollars in software to any and every organization or professional who could provably show us even one tool in the world that can do what Gold Finger's privileged access assessment capabilities can, and guess how many organizations/professionals have taken us up on the offer thus far? 

Zero! Need one say more?

In Closing

In closing, I will only add that at Paramount Defenses we continue to be laser-focused on Active Directory security because it is absolutely paramount to the national security of the United States of America, and that of 100+ countries worldwide. 

You see, there can be no national security without a government having operational autonomy and organizational privacy, and only Active Directory makes these two imperatives possible. Fortunately, today every organization in the world that wishes to do so can easily attain and maintain least privilege access (LPA) in their foundational Active Directory domains, thereby measurably eliminating 99% of avenues of privilege escalation to the "Keys to the Kingdom" in Active Directory.

That's all for now.

Best wishes,
Sanjay.

How to CORRECTLY identify WHO can run DCSync against Active Directory

Folks,

Hello. Today, we'll share with you what the CORRECT procedure is for finding out who can successfully execute Mimikatz DCSync against your Active Directory, particularly because so many IT professionals errantly believe that they know how to accurately make this determination. 

As many know, Mimikatz DCSync is a hacking tool written by Benjamin Delpy that is often used by perpetrators to swiftly and substantially compromise organizations by letting them determine the passwords of all organizational AD accounts.

This is extremely important because DCSync is possibly the single biggest threat to all organizations operating on Active Directory, considering that even just a single successful enactment of DCSync instantly results in the compromise of the credentials of ALL domain user accounts, and thus, is in effect, tantamount to a colossal breach.

In fact, as recently shared by Microsoft Security, and I quote below, even LAPSUS$ i.e. DEV-0537 have been observed to use DCSync to substantially compromise several organizations, including most notably, Okta -

"The group compromised the servers running these applications to get the credentials of a privileged account or run in the context of the said account and dump credentials from there. The group used DCSync attacks and Mimikatz to perform privilege escalation routines. Once domain administrator access or its equivalent has been obtained, the group used the built-in ntdsutil utility to extract the AD database."

Now, it is very important to understand that LAPSUS$ were only able to successfully use DCSync because they were able to compromise an account that had sufficient ACCESS in their Active Directory domain so to be able to run DCSync.

In other words, if an account compromised by perpetrators does NOT have sufficient ACCESS to be able to successfully run DCSync, then the perpetrators will NOT actually be able to successfully run DCSync against Active Directory, so if we can correctly find out who has sufficient ACCESS to run DCSync against our Active Directory, we can lockdown all such exploitable access, minimizing the possibility of perpetrators being able to use DCSync against our Active Directory. 

The ACCESS required to DCSync

In order for organizations to be able to identity ALL accounts that possess sufficient ACCESS to be able to run DCSync, they first need to know exactly what ACCESS an account needs to to be able to run DCSync against Active Directory.

From a technical standpoint, any user that has (i.e. is granted) sufficient privileged access in Active Directory to be able to replicate secrets from Active Directory can request Active Directory to provide it a copy of the entire domain contents, including all secrets i.e. password hashes of all domain accounts.

It logically follows that a perpetrator can only successfully use Mimikatz DCSync against an Active Directory domain if the compromised domain account that he/she is using has sufficient privileged access in Active Directory to be able to request and obtain secrets (i.e. password hashes) from Active Directory.

Speaking of which, the exact privileged access required to obtain (replicate) secrets from Active Directory involves two Active Directory extended rights, and an attacker requires BOTH of these permissions to be effectively granted -

1. Replicating Directory Changes
2. Replicating Directory Changes All

To be specific, to be able to successfully execute DCSync, an account needs to have both of these Active Directory extended rights be effectively granted in the ACL of the domain root object of an organization's Active Directory.

The Mistake 99% of IT Pros Make 

Now, it is at this point that we must take a moment's pause and understand something extremely important.

The operative word in the previous sentence is "effectively" granted, and therein lies the answer to this question.

You see, most IT professionals errantly assume that all they need to do is find out "Who has these permissions in Active Directory" and to do so all they need to do is use any Active Directory ACL/Permissions Analysis tool, or write a few lines of PowerShell script to find out which users and groups are granted these permissions, and that's it!

Unfortunately, any IT professional that makes the above assumption is very likely going to end up with an inaccurate list of accounts that can run DCSync because what needs to be determined here is not "Who has these permissions in Active Directory" but in fact "Who has these effective permissions in Active Directory?"

In short, it is not "who has what permissions in Active Directory" but in fact "who has what effective permissions in Active Directory" that determines who actually has sufficient privileged access so as to be able to run Mimikatz DCSync!

Further, and as such, "effective permissions" not only determines who can actually run DCSync against Active Directory, it actually determines exactly who has what privileged access to do just about anything and everything in Active Directory.

This subtle yet profound difference can be very easy to get wrong, and yet is extremely important to understand, because it determines whether or not the results of one's analysis are accurate or not, and as you know, when it comes to privileged access, there is absolutely no room for error and accuracy is paramount.

Consequently, while it is relatively easy to find out "Who has these permissions in Active Directory" using PowerShell or any ACL/Permissions Analysis tool, it is extremely and far more difficult, if not almost impossible, to accurately find out "Who has these effective permissions in Active Directory" using PowerShell or such tools.

   

Effective Permissions

In this section, we will understand why it is not "Who has what permissions in Active Directory" that we need to determine, but in fact "Who has what effective permissions in Active Directory" that we need to determine if we care about accuracy.

Once you have understood this, you will also understand why no AD ACL/Permissions Analysis tooling and/or any PowerShell script that one may have written, no matter how complicated, can actually provide accurate results.

Let us consider what we need to determine to make this paramount determination. 

In essence, what we need to determine is in light of ALL the security permissions specified in the ACL protecting the domain root object, exactly who has BOTH the "Get Replication Changes" and "Get Replication Changes All" extended right effectively allowed.

By "effectively" what we mean is the following - consider that a user John Doe is a member of two groups, Group X and Group Y. Further consider that in the ACL of the domain root, the following permissions exist for Group X and Group Y -

Deny   Group X   All Extended Rights

Allow   Group Y    Full Control 

Note - As you may know, each of the above is an ACE (access control entry) in an ACL (access control list), and each ACE either allows or denies either a generic or a a specific type of permission to a specific security principal.

Consequently, one might rightly assume that for starters we need to consider ALL ACEs in the ACL that specify either one of the following permissions - "Get Replication Changes" extended right, "Get Replication Changes All" extended right, All Extended Rights and Full Control.

Note: Some pros like to include the impact of being able to modify permissions on the ACL at this stage, but that is strictly speaking, an entirely separate entitlement/administrative task, which is why, strictly speaking, it need not be taken into account at this stage. 

Now, based on the above, most PowerShell scripts would be programmed to find all permissions that grant either of the above four rights, and that is indeed the correct way to BEGIN to approach this analysis.

However, it is at this point that not only most PowerShell scripts, but also all AD ACL/Permissions analysis tools, and even tools like Bloodhound, meet their match and start falling substantially short.

Let me explain -

Based solely on an ACL that has the above two permissions, virtually all PowerShell scripts and tools like Bloodhound, will enumerate both permissions but make either of the two following errors - 

1. Error 1 - They will errantly assume that since there is an ACE specifying the specified access for two groups, members of both these groups have the required access, at which point they will proceed to expand these group memberships and report that all the members of both these groups can in fact replicate secrets, whereas nothing could be further from the truth!


2.  Error 2 - A more refined script looking merely for Allow permissions will partially rightly determine that only members of Group Y have the required access, at which point it will proceed to expand this group's membership and report that all its members can in fact replicate secrets, which too would unfortunately be inaccurate.

Here's why both of the above will lead to inaccurate results - you see, what such PowerShell scripts and tools like Bloodhound ACTUALLY need to be doing is determining that Group Y is allowed the required access -AND- Group X is denied the required access so they need to be identifying members of both these groups, then performing conflict resolution, which involves correctly identifying any and all individuals that may be members of both these groups, and eliminating those individuals that are on both lists, from the final list, since the deny permission will have precedence over the allow permission!

NOW, in theory, and especially when you are considering merely two ACEs, as we have above, being able to perform this conflict resolution may seem simple, BUT in practice and reality, the ACL of the domain root could easily have hundreds of ACEs/permissions, any theoretically each one of them could be in play, i.e. could influence such access, and be either allow or deny, so for any PowerShell script or a tool like Bloodhound to be able to deliver accurate results, it would have to have the automated ability to be able to accurately perform conflict resolution involving hundreds of ACEs (/permissions.)

Further, in the illustrative example shared above, John Doe was directly a member of these two groups. 

In the real world, thousands of accounts could also indirectly, i.e. via nested group memberships, some of which may be deeply nested, and others may possibly also be circularly nested, be members of hundreds of domain security groups for which permissions may be specified in the domain root's ACL, and the PowerShell script or a tool like Bloodhound will need to have the ability to be able to process even such substantial complexity with 100% accuracy.

In addition, theoretically speaking, Active Directory security permissions could also be specified for one or more well-known RIDs as well as well-known security principals, such as Domain Users, Authenticated Users, Everyone, etc. and so PowerShell scripts and tools like Bloodhound will also need to be able to accurately evaluate the impact of all such permissions on the resulting access.

Also, there are several other factors that influence the accurate determination of "who has what privileged access in Active Directory" and I'm not going to list them all out there.

Finally, the ACL on the domain root object is an exception in that it is possibly the only object (, other than those that have protected ACLs,) wherein there are no inherited permissions to deal with. In reality, 99% of objects in Active Directory also inherit hundreds of security permissions, and it is exponentially difficult to be able to accurately do conflict resolution when inherited permissions are also in play, because one has to be able to accurately determine resulting access in light of the precedence order involving both explicit and inherited allow and deny permissions.    

For anyone who wants to learn more, a more detailed explanation and example of just how difficult and complicated it is to accurately determine Active Directory Effective Permissions can be found here.

In short, it is extremely difficult, if not almost impossible, to write any amount of PowerShell that can take all of the above complexity into account and yet determine with 100% accuracy, exactly who has sufficient effective access so as to be able to enact a critical operation such as DCSync against Active Directory, or perform any one of over one hundred possible administrative tasks in Active Directory.

This is why it is almost impossible for any PowerShell script or a tool like Bloodhound to be able to accurately determine who can successfully execute DCSync against an organization's Active Directory.

An Actual, Step-by-Step Example

The best way to understand what I have shared above is for you to try it yourself in an Active Directory, and to facilitate exactly that, we have made available a real-world like lab AD of a fictional company in a free VM.

You can follow an entire step-by-step example of how to correctly identify who can run DCSync against Active Directory right here.

Your PowerShell Script is Woefully Inadequate

Once you've had an opportunity to understand the technical nuances I've shared above and follow the step-by-step example I've provided above, you'll know for yourself that it is extremely difficult, if not impossible, to find out exactly who can do what in Active Directory using PowerShell.

Specifically, there are over a dozen factors one needs to take into account, with 100% precision, and zero room for error, and no amount of PowerShell, even written by the world's best Active Directory Security practioners can make this paramount determination accurately.

The same is true of all well-intentioned but woefully deficient amateur tools like Bloodhound, which self-admittedly do not even take deny permissions into account. The sheer fact that they do not take one of the most important factors in the entire process into account renders them virtually useless from a professional standpoint.

Of course, if you don't care about accuracy, then by all means, even basic tools like acldiag can help you get "a list."  Of course, since you don't care about accuracy, you likely won't care about whether or not that list is accurate.

Click, Done

There is one and only way to accurately make these paramount determinations in Active Directory, and that is by accurately determining Active Directory Effective Permissions.

There is also one and only on solution in the whole world that can accurately determine effective permissions in Active Directory and that is our Microsoft-endorsed Gold Finger solution. Fortunately, to help everyone make this paramount determination for FREE, a subset of its unique capabilities are now also available in Gold Finger Mini.

Gold Finger Mini

The most important report in Gold Finger Mini is - "Who can replicate secrets (i.e. password hashes)) from the domain?" and that one report can instantly and accurately determine "Active Directory Effective Permissions" on the domain root and reveal exactly how many accounts possess sufficient access to be able to run DCSync against your Active Directory, and who they are.

The basic version of Gold Finger Mini is free, and it can help every organization instantly find out exactly how many accounts can successfully run DCSync against their Active Directory today.

Gold Finger Mini can be instantly download, and installed in under two-minutes, and at the click of a button, reveal this information, for free, using any domain user account. It is a 100% read-only tool and does not require any admin access.

In light of what Microsoft shared about LAPSUS$, if I were the CISO, an IT Manager, a Domain Admin, or an IT Auditor at an organization, I would not want to sleep without having determined how many accounts possess sufficient privileged access so as to be able to run DCSync against our Active Directory today. After all, what else could be more important?

 

 

Conclusion

The objective of today's post was to help everyone realize that trying to accurately find out can successfully execute DCSync against your Active Directory is not as easy as it may seem, and neither amateur tools like Bloodhound nor PowerShell scripting can accurately take all the factors involved in this determination.

As the breaches at Okta and Microsot by LAPSUS$ have shown the entire world, a single occurrence of this threat could result in a massive cyber security breach, that could cost the organization not just millions of dollars to recover from, but serious reputational damage as well, not to mention potentially substantial liability arising from the potential loss of all kinds of organizational data, such as customer PII, financials, trade secrets etc.

Consequently, all organizations that operate on Microsoft Active Directory today, must know at all times, exactly which accounts possess sufficient ACCESS to be able to run DCSync against their Active Directory, because having this paramount insight can help them ensure that ALL such accounts are on their radar and sufficiently protected.

In contrast, it takes almost nothing at all to mitigate this serious threat and minimize the possibility of its occurrence, and today from the CEO to the CISO to the Domain Admin, all stakeholders must know what Mimikatz DCSync is, and exactly who can run DCSync against their foundational Active Directory -

👉   Gold Finger Mini - Advanced Level - Report #1 - "Who can replicate secrets from the domain?"

I'll leave you with this thought - if your organization doesn't even know exactly which accounts can execute DCSync against your Active Directory, how can it be safe from a cyber security perspective, and what does it really know?


That's all for now.

Best wishes,
Sanjay.

At the HEART of LAPSUS$'s success - "Active Directory Privilege Escalation"

Folks,

Last month, Microsoft Security shared details of the tactics, techniques and procedures (TTPs) employed by LAPSUS$ (DEV-0537) in its attempts to compromise organizations, including confirmed breaches at Okta, Microsoft and others.

If you read Microsoft's observations, you'll find that the defining i.e. cardinal step in their attack methodology, i.e. the one that ultimately enabled them to succeed in their objectives was none other than "Active Directory Privilege Escalation."

Quoting Microsoft -

"The group compromised the servers running these applications to get the credentials of a privileged account or run in the context of the said account and dump credentials from there. The group used DCSync attacks and Mimikatz to perform privilege escalation routines. Once domain admin(istrator) access or its equivalent has been obtained, the group used the built-in ntdsutil utility to extract the AD database."

That right there is irrefutable evidence that LAPSUS$ indeed undoubtedly engaged in Active Directory Privilege Escalation, and as I stated above, once Domain Admin or equivalent access had been gained, they used that "privileged access in AD" to execute DCSync to compromise everyone's credentials, at which point, they could easily play proverbial God!

The World has had Sufficient Warning

I cannot begin to tell you how many times I have warned the world about the just how dangerous, damaging and effective "Active Directory Privilege Escalation" is as an attack vector, but  it seems to have fallen on deaf ears, so let me try and enumerate the number of times I have warned about this attack vector and DCSync in particular -

2013 - The World's #1 Cyber Security Risk - Active Directory Privilege Escalation

2013 - A Real-World Example of Active Directory Privilege Escalation 

2014 - Exploiting Active Directory Privilege Escalation to compromise Active Directory 

2015 - Presentation on Active Directory Security at Black Hat 2015 missing #1 Attack Vector 

2015 - Active Directory Privilege Escalation likely at heart of the OPM Data Breach   

2016 - A Letter to Benjamin Delpy regarding Mimikatz and Active Directory Security 

2016 - The Paramount Brief - Active Directory Privilege Escalation poses a Serious Risk

2016 - How to Lockdown Active Directory to thwart use of Mimikatz DCSync

2016 - Active Directory Beyond the MCSE for the Black Hat Conference 2016

2016 - Attack Methods for Gaining Domain Admin Rights in Active Directory

2017 - An Example of How DCSync could result in a Colossal Cyber Security Breach

2018 - Mimikatz DCSync Mitigation and Can anyone help mitigate Mimikatz DCSync?

2019 - Active Directory Privilege Escalation - An Executive Summary

2020 - How to Easily Mitigate the Risk Posed by Mimikatz DCSync

2021 - What's Common between the SolarWinds Breach and Colonial Pipeline Hack?

2022 - How to Identify Who can Engage in Active Directory Privilege Escalation 

 

In addition, in December 2015, we had officially informed the executive leadership (i.e. the CEOs, CISOs and Chairmen) of the world's top 200 business organizations (including Samsung), as well as every agency in the United States Government about the dangers of "Active Directory Privilege Escalation."

In fact, as late as May 0f 2021, I had yet again pointed out that even in the SolarWinds Breach, the defining step that provided perpetrators unrestricted access was in fact Active Directory Privilege Escalation and DCSync.

As such, all you have to do is read the one paragraph shared above from Microsoft's observations, and then see for yourself how many times the words Privilege Escalation, Mimikatz, DCSync, AD (Active Directory) and Domain Admin have been mentioned in the links I have shared above, and you'll know who has been warning the world for years now.

Further quoting Microsoft -

"They (LAPSUS$) have been consistently observed to use AD Explorer, a publicly available tool, to enumerate all users and groups in the said network. This allows them to understand which accounts might have higher privileges."

There you have it again. It is abundantly clear from Microsoft's observations that once LAPSUS$ gains initial access at an organization, their next and immediate objective is to identify accounts that possess privileged access in Active Directory.

The reason is simple - the compromise of a single account that possesses privileged access in Active Directory is sufficient to instantly gain complete command and control over an organization's network because even one account that possesses privileged access in Active Directory possesses the "Keys to the Kingdom."

 

To the wise, a Hint is enough

Today, over twenty thousand organizations worldwide operate on Microsoft Active Directory, and organizations that have not yet been breached should strive to learn from the attack methodologies used in virtually every major recent breach.

Every major recent breach, including the SolarWinds Breach, the Colonial Pipeline Hack, the Okta breach and all breaches carried out by LAPSUS$ and others have ONE thing in common...

... in each of these breaches, the perpetrators targeted Active Directory, and specifically, accounts that possess privileged access in Active Directory, and once compromised, they used those privileged account to easily accomplish their objective.

This cannot be overstated - just ONE Active Directory Privileged User account. Not one hundred, not ten, but just ONE.

Consequently, if there is one learning lesson for all organizations from these high-profile breaches, it is that organizations must strive to accurately identify, minimize and sufficiently protect every single Active Directory privileged user account.

Saying NO more

Over the last ten years, we have said enough, and we have been SPOT-ON for a decade now i.e. 100% of all major recent breaches have involved perpetrators compromising and then misusing a single Active Directory privileged user account, access to which is gained via Active Directory Privilege Escalation, and once such access has been obtained, the perpetrators have subsequently been able to easily accomplish their objectives.

We have said enough and on this paramount subject, we have shared more technical information than any other entity in the world, via the resources pointed to above, as well as via valuable and actionable insights on our website.

Organizations that care about their cyber security must immediately consider enacting the #1, most important and effective risk mitigation measure they can today - accurately identify and minimize privileged access in Active Directory.

This is Paramount

It is imperative and paramount to understand that to be able to escalate privilege in Active Directory and/or to be able to successfully execute DCSync, perpetrators require ACCESS. After all, without sufficient effective access, perpetrators CANNOT escalate privilege, execute DCSync, and for that matter, they cannot enact any privileged action.

Consequently, if organizations are to win this battle, they need to DENY perpetrators the ACCESS required to escalate privilege and/or enact privileged operations, and to deny perpetrators access, all that is required is to accurately identify and then lockdown who currently possesses privileged access in Active Directory.

The #1 reason perpetrators are able to succeed is that they are able to find and compromise accounts that possess privileged access in Active Directory, many of which may be insufficiently protected because they may not be on the organization's radar i.e. the organization may not even realize that these accounts possess privileged access.  

Thus, the accurate identification, subsequent reduction and adequate protection of all accounts that possess privileged access in Active Directory is the #1 measure that organizations can take to minimize the possibility of being colossally compromised by perpetrators seeking to exploit unidentified privileged access in Active Directory.

Finally, the accurate identification of privileged access in Active Directory requires just ONE fundamental and essential cyber security capability - this, which is embodied in this and in this. Organizations that possess this ONE capability can easily and instantly accurately identify and lockdown privileged access in Active Directory. Organizations that do not possess this ONE capability will continue to be at substantial risk, and likely minutes away from being compromised.

  

I'll leave you with this thought - organizations that do not know exactly who has what privileged access in Active Directory remain at high risk of being substantially compromised and likely being the next organization to be massively breached. 

All you have to do is ask your CISO if your organization has answers to these paramount questions today.

Thank you very much. We wish all organizations well.

Sincerely,
Sanjay.