Wednesday, April 27, 2022

Active Directory - The World's Most TRUSTWORTHY Foundational Technology


Today I'd like to share a few thoughts with you on one the most important topics in all of organizational security - i.e. which FOUNDATIONAL technology should organizations be operating upon today? I will make the case of Active Directory (🔺).

Microsoft Active Directory - The World's Most Trustworthy Foundational Technology

For the last twenty years, the entire world has successfully operated on a highly trustworthy foundation - Active Directory.

Indeed, from the entire United States Government to virtually the entire global Fortune 1000, today over twenty thousand government and business organizations in over one hundred and ninety countries operate on Microsoft Active Directory.

Active Directory has stood the test of time and is the most trustworthy foundation that organizations can operate on today.

While some may view Active Directory as merely an Identity Provider (IDP), in reality, it is substantially more than that. 

Active Directory is -

  1. An enterprise-grade multi-mastered directory service that offers unrivaled availability, fault-tolerance and resilience. 

  2. A Kerberos realm that enables enterprise-wide trustworthy network authentication and seamless single sign-on.

  3. The Foundation of Authentication, Authorization and Auditing (AAA) that empowers organizations to precisely control network user authentication, secure authorization to IT resources and auditing for all vital AA actions.

  4. The Heart of Identity and Access Management (IAM) considering that the entirety of an organization's identities (and their credentials) and security groups reside in and are secured and managed in Active Directory.   

  5. The Heart of Privileged Access and Enabler of Least Privileged Access (LPA) considering that the most powerful privileged accounts are stored, secured and managed in it -AND- that privileged access for all salient aspects of identity and access management can be precisely provisioned/delegated based on the principle of least privilege.    

  6. The Control Center for Centralized Host and Security Management that via Group Policy enables organizations to easily, efficiently and comprehensively control and manage all endpoints -AND- their security.

  7. The Foundation for Zero Trust considering that Zero Trust is fundamentally about ensuring that all access is provisioned based on the principle of least privilege (i.e. LPA), and in environments powered by Active Directory, access for all aspects of identity and access management is provisioned, controlled and audited in Active Directory.

In addition, Active Directory lets organizations easily enable seamless single sign-on to external systems via federation, and it can be synchronized with secondary IDPs like Microsoft Azure to facilitate SSO access to Cloud based services.

Finally, contrary to popular belief, Active Directory can* in fact be easily, efficiently and reliably operated and secured. 

However, the most important and overlooked strength of Active Directory is that enables and empowers organizations to be able to autonomously and independently operate their IT infrastructures, without any eternal external dependencies, without having to expose the entire organization to the Internet, and without having to incur a dime of additional cost.


In essence, today, an organization's Active Directory deployment is the very foundation of its cyber security, the heart of privileged access and the bedrock of organizational security, which makes it an extremely valuable organizational asset.

Above all, it lets organizations independently operate, highly trustworthy, self-reliant and fixed-cost IT infrastructures, in contrast to having to relinquish all control and transition to relatively new, constantly costing, third-party operated services.

In conclusion, when it comes to cyber security, technical maturity, operational excellence and autonomous operation, today, no technology can rival the trustworthiness, resilience and autonomy that Active Directory offers organizations.

Best wishes,
Sanjay Tandon

Program Manager
Active Directory Security
Microsoft Corporation

Friday, April 8, 2022

How to CORRECTLY identify WHO can run DCSync against Active Directory


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.

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?



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,

Tuesday, April 5, 2022

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


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, MimikatzDCSync, 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.


Monday, April 4, 2022

Pardon the Absence + The World's Finest Cyber Security Insights


I hope this finds you doing well. Pardon our absence here on this blog as we have been extremely busy on several fronts, assisting organizations worldwide adequately secure and defend their foundational Active Directory deployments.

As such, over the years, we have already shared the world's most advanced cyber security insights on topics including Privileged Access, Active Directory Security, Active Directory Privilege Escalation, Active Directory Effective Permissions and more, all of which directly impact the foundational security of over twenty thousand organizations worldwide.

In addition, I personally have been active on LinkedIn, providing some much needed thought leadership to organizational cyber security leaders, Domain Admins and other cyber security practioners. In fact, over the last few months, I've shared some valuable insights and asked some of the world's most important questions on LinkedIn, including -

  1. Is it easy to find out who has what privileged access in Active Directory today?

  2. The Keys to the Cyber Security of every organization in the world lie in a deep ocean

  3. What is this string and why should you care? > (A;WD; WD;;;)

  4. Even Microsoft is not bullet proof

  5. At the heart of the most critical step in Russian GRU hacking attempts lies Active Directory

  6. What lies at the foundation of cyber security of 85% of organizations worldwide?

  7. Microsoft buys RiskIQ for $500 Million, but may be exaggerating its capabilities

  8. Can anyone answer this simple Cyber Security 101 question?

  9. The Top-10 cyber security insights every organization must have

  10. Cyber security is mostly a joke at most organizations worldwide

  11. There exist billions of Active Directory privilege escalation paths worldwide

  12. The most valuable organizational asset worldwide today - Active Directory

  13. One 3-letter acronym entity* controls cyber security worldwide today

  14. The Top-5 ways to compromise an Active Directory domain user account

  15. The easiest way to compromise Microsoft Azure

  16. Technically speaking, most organizations worldwide can be compromised in minutes

  17. Who needs WMDS today?

  18. The keys to global security lie in ONE technical thing - AD ACLs

  19. If you were a hacker, and you could only compromise ONE account, which one would it be?

  20. What costs a $ Billion and yet not even one of the 1000+ billionaires in the world can actually buy it?

  21. 10 technical facts that underlie the cyber security of the entire world today

  22. Microsoft views Cyber Security as a $150 Billion addressable market

  23. The difference between amateurs and professionals in cyber security

  24. The answer to "Who needs WMDs today"?

  25. Microsoft just confirmed what I've been saying for years now

That said, in light of the recent breaches at Microsoft and Okta by LAPSUS$, I have decided that perhaps we need to share a few more insights with the world, so in days and weeks to come, you can expect a few insightful blog posts here.

Until then, if you want to learn more, you may want to ready my posts on LinkedIn.


Paramount Defenses Logo

© 2006 - 2024 Paramount Defenses.
All Rights Reserved.

Your Privacy

We use cookies to give you the best online experience. Please let us know if you accept these cookies.