How to Easily Mitigate the Security Risk Posed by Mimiktaz DCSync

Folks,

Hello. I hope this finds you all doing well. This post is Day-7 of Active Directory Security for Cyber Security Experts.

Today, I will share with you how to easily mitigate the serious cyber security risk posed by Mimikatz DCSync hacking tool to Active Directory deployments, as well as walk through a real-world example in our Active Directory Security lab VM.




Overview

Mimikatz DCSync is a hacking tool written by Benjamin Delpy that is often used by perpetrators to swiftly and substantially compromise Active Directory deployments by letting them determine the passwords of all organizational domain accounts.

In short, if a perpetrator could successfully run Mimikatz DCSync against your domain, he/she/they could instantly find out everyone's passwords, from that of all Domain Admin accounts to that of the CEO's account to that of the krbtgt account.

In short, it would be Game Over in minutes, and the organization would have suffered a massive cyber security breach.





Root Cause

The simple reason that Mimikatz DCSync is able to determine the passwords of all domain accounts is that the account being used by the perpetrator has sufficient access so as to be able to request and obtain from Active Directory, the password hashes of all domain accounts, which it can then easily determine the clear-text version of.

To be specific, any user that has (i.e. is granted) sufficient privileged access in Active Directory to be able to replicate secrets from Active Directory can simply 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 that is required to be able 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

That's literally all that a perpetrator needs to be able to run Mimikatz DCSync against an organization's Active Directory.




Prevention

Organizations can in fact prevent perpetrators from being able to run Mimikatz DCSync against their Active Directory.

To do so, they need to first accurately identify, and then review and lockdown the list of all personnel who are currently authorized to, i.e. have sufficient privileged access to, be able to replicate secrets from their Active Directory domains.

Specifically, if organizations can accurately determine exactly which domain accounts have these two Active Directory extended rights effectively granted in the ACL protecting the domain root object, then they can easily determine exactly who all can run Mimikatz DCSync agains their Active Directory today.

Once they have done so, a review of this list will instantly identify and reveal all accounts that currently do but that should not have this level of privileged access, and if they can additionally determine the underlying security permissions in the ACL of the domain root object that entitle these accounts to the required privileged access, they can instantly and reliably lockdown those permissions to minimize this number down to virtually zero.

Subsequently, to maintain locked-down access, security conscious organizations will want to periodically (daily, weekly or biweekly) monitor (audit) any changes in privileged access (i.e. Active Directory effective permissions) on the domain root.


In short, a simple three-step process is all it takes to prevent the use of Mimikatz DCSync -

1. Accurately identify who has sufficient effective permissions to replicate secrets from the domain
2. Review list and lockdown access, by identifying and then tweaking the underlying entitling permissions
3. Subsequently, monitor (audit) effective permissions on domain root to identify any changes in privileged access

By following this simple three-step process, organizations can easily prevent the use of Mimikatz DCSync against their foundational Active Directory, and prevent the credentials of the entirety of their user populace from being compromised.





A Classic Mistake

A classic mistake that many organizations often make when trying to determine who has the required privileged access to be able to replicate secrets from Active Directory is that they often only focus on identifying "Who has what permissions?" on the domain root object whereas in fact what they need to be doing is identifying "Who has what effective permissions?"

A simple analysis of "Who has what permissions" may not always include the impact of any deny permissions that may have been specific (directly or indirectly), or the impact of arcane nested group memberships, or the impact of any permissions granted to (dynamically evaluated) well-known security principals, or the impact of Special permissions etc.

Further, in most Active Directory deployments, there are almost always well over a hundred security permissions the ACL of the domain root object, so it is difficult, cumbersome and error-prone to make this determination with 100% accuracy.

Consequently, even organizations that know exactly what privileged access enables perpetrators to use Mimikatz DCSync may not always have the correct picture when it comes to who can actually run this tool in their environment.





The Correct Procedure

The simple and correct procedure to make this paramount cyber security determination involves accurately determining effective permissions on the domain root object to identify all individuals who are effectively granted both, the Replicating Directory Changes and the Replicating Directory Changes All extended rights.

Individuals who are on both the lists are the only ones who can successfully run Mimikatz DCSync against Active Directory.





A Step-by-Step Example

With this in mind, let us proceed to enact the three steps outlined above in our corp.local lab Active Directory domain.

• Prerequisite: To follow along this example, you will need to download and use the completely free and ready-to-use accompanying lab Active Directory VM, which can be instantly downloaded from here.

Step 1

Let us begin by examining the ACL protecting the domain root object. To do so, simply launch Active Directory Users and Computers snap-in, select and right-click the domain-root object, click the Security tab and then click the Advanced button.

Active Directory security permissions in the ACL of the domain root object

As one can see, there are many Active Directory security permissions specified in the ACL for many security principals, some allowing and some denying access, and it does not seem easy to even just view these permissions in their entirety.


As an alternative, let us try using Microsoft's dsacls command-line utility to get a better picture of this ACL -

Unfortunately, even with dsacls it seems difficult to even just get a simple listing of all the security permissions in this ACL, perhaps because dsacls is more suited to perform Active Directory ACL modifications than it is to perform ACL analysis.



Today there are several solutions available to help make Active Directory ACL/security permissions analysis easier for everyone, and you are welcome to use any tool/solution of your choice to obtain a better picture and follow along.



I am going to proceed with the Microsoft-endorsed Active Directory ACL Analyzer, because it is the simplest, most capable and most trustworthy Active Directory ACL Analyzer that I know of (, and because I architected it) -

I was able to retrieve the object's ACL at a button's touch; status bar indicates that there are 59 permissions in the ACL.


Next, I click the View Details button and the tool now shows me a detailed view of the ACL, with the security permissions field/column broken down into individual, sortable columns, one for each of the 13 Active Directory security permission types, making it easy for me to sort the ACL and hone-in on just those permissions that impact Extended Rights (CR) -

The rich, detailed view (also available in the exportable CSV format) helped me make the following determinations -

1. Of the 59 permissions in the ACL, there are 33 permissions that specify (allow/deny) extended right permissions
2. Of these 33 permissions, 19 permissions directly or indirectly specify the two permissions we are interested in
3. Of these 19 permissions, 13 permissions indirectly specify both the permissions we are interested in 
4. Of these 19 permissions, 3 permissions directly specify the Replicating Directory Changes extended right
5. Of these 19 permissions, 3 permissions directly specify the Replication Directory Changes All extended right
6. Of these 19 permissions, 2 permissions deny access, and the remaining allow access
7. Finally, altogether, these 19 permissions allow/deny access to 17 unique security principals

As one can see, this information in itself is already helpful because it has helped us determine which of the 59 security permissions in the ACL of the domain root object we need to take into account to make this determination.

In case it helps, here's a snapshot of the output of this tool, exported to CSV and opened in Excel -

Saliently, there are 17 security principals that we need to focus on, almost all of which are security groups that we will need to expand, and perhaps some of them may contain nested groups (of which some could be circularly nested) etc.

This also indicates that we will also have to perform conflict resolution because there are at least 2 security permissions that deny extended rights to 2 different security groups, either of which could be nested (, possibly even circularly nested).

•  Side-note: Question - Does Bloodhound negate denies? If not, how can it be accurate?

Incidentally, I could also have just used the Active Directory Permissions Analyzer to make this very determination, without having to perform any kind of visual analysis i.e. I could have just specified that I am looking for exactly these permissions, and it would have instantly found them for me, making the task even easier -

However, this still leaves us with 16 security groups to completely expand (the 17th security principal being System itself,) and while we could proceed to do so, it would still involve some work, not to mention meticulously taking into account which permissions grant blanket access and which one grant specific access, negating allows with denies etc. etc.

Let us also keep in mind that in this case, we are looking at a small domain of a fictional organization so there are only 16 security groups to expand. In most real-world production Active Directory domain, there are over 100 security permissions and there could easily be many, many more security groups one may have to manually and meticulously expand!


This may make you wonder that there must be an easier way to do this. After all, can you imagine how much effort it might take us each time we needed to make this determination, and all such determinations in Active Directory.

Indeed, there IS actually an easier way, and in fact it is the only correct way to make this determination, and all such determinations, and that ONE simple, easy and correct way is called "Active Directory Effective Permissions"


In fact, its right there in Microsoft's native ADUC tooling's Advanced Security tab, and its called the Effective Access tab.

The importance of this tab is conveyed by the simple fact that it is one of the three tabs that exist in ADUC's Advanced Security tab, along with Permissions and Auditing, and it has existed since day one, i.e. since Windows 2000.

For years it was called the Effective Permissions tab, until Microsoft recently changed its name to Effective Access tab.


Well, if this tab exists in ADUC, let's just proceed to use it to make this determination, and IF IT CAN FULFILL OUR NEED, then there's no point in wasting our precious time on all that ACL/permissions analysis etc., so lets see if it can help us -

The first thing you'll notice is that you need to enter a user's name. As seen above, I entered the name of a specific user, Peter Jackson, and it showed me an approximation of the effective permissions that Peter Jackson has on the domain root. One can scroll down to see the full list of effective access that Peter Jackson is entitled to on this object.

Therein lies the problem. It can at most determine (approximate) effective permissions ONE USER at a time. :-( In other words, you can specify a particular user, and it will determine and show you the effective permissions for that ONE user.

In this demo Active Directory domain itself, there are over a thousand users and computers, and in most organizations there could be tens of thousands of users and computers, and I don't know about you, but most people do NOT have the time to enter ONE USER AT A TIME and then make a note of his/her effective permissions etc. as this would take weeks!

In short, Microsoft's Effective Permissions/Access Tab is hardly useful i.e. practically useless, and that's so unfortunate.

It is only useful to the point wherein you may want to find out what effective permissions a specific user may have. Further it cannot accurately calculate the complete set of effective permissions, and it cannot pinpoint which underlying security permission in the ACL entitles a user to a specific effective permission, which one needs to know to lockdown access.


Hmm. It seems like after all, even after twenty years, we'll just have to go right back to doing boring, complicated and laborious Active Directory permissions analysis, group membership evaluations, conflict resolutions etc. MANUALLY :-(


As I have said earlier, you can use any tool from any vendor you like to help you ultimately do ALL that is involved (i.e. ACL analysis, group membership expansions, allow vs. deny conflict resolution etc.) to make this determination accurately.


As for myself, I'm going to use this Microsoft-endorsed tool, and I'll be completely done in less than one minute -

This unique tool is the world's only accurate fully-automated effective permissions calculator for Microsoft Active Directory.

It can do, what no other tool or entity (i.e. person or company) in the world can - instantly and accurately determine the complete set of effective permissions entitled on any Active Directory object, identify exactly which accounts have these effective permissions, and pinpoint the underlying permissions that entitle these accounts to these effective permissions, all at the touch of a button.

As you can see above, all I had to do was point the tool to the domain root object, and click a button, and in less than a minute, it accurately determined and revealed the complete set of effective permissions entitled on this object, exactly who has these effective permissions, and which underlying permissions entitle a user to a specific effective permission.


I simply used the What drop-down to locate and select Extended Right - Replicating Directory Changes and it instantly showed me that a total of 40 accounts have this effective permissions on the domain root object -

Next, I used the What drop-down to locate and select Extended Right - Replicating Directory Changes All and it instantly showed me that a total of 40 accounts have this effective permissions on the domain root object -


Then, all I had to do was intersect these two lists, which I easily did by exporting the results to CSV and opening it in Excel.


Here is the list of 40 accounts that can run Mimikatz DCSync in the lab corp.local domain

Administrator, Alexander White, Andrew Cushman, Around Trust, Brandon King, Certify Suite, Control Engine, Darren Baker, David Edwards, DC, Donald Parker, Felix Defense, Frank Collins, George Carter, Greg Baker, Harper Anderson, Henry Moore, Isabelle Woods, James Cushman, Jane Moore, Jason Goodman, Kevin Johnson, Larry Phillips, Lauren Cruise, Lucas Allison, Mary Gates, Michael Young, Nancy Clark, Net Tricks, Nicholas White, Passive Server, Peter Brown, Peter Jackson, Ryan Clark, Simon Baker, Solar Breeze, Susan Douglas, Suzanne Goodman, Tim Young, Victor Branson

•  Note - The accounts in red are unmanaged service accounts !

Thus, as seen above, it took me just a few minutes to complete step 1, which was to accurately identfy all accounts that possess sufficient privileged access to be able to replicate secrets from Active Directory.



Step 2

Now that we have accurately identified the list of all individuals/users/accounts who possess sufficient privileged access to be able to replicate secrets from Active Directory, its time to review and lockdown this list.

We have identified 40 accounts that possess this level of access. That is about 39 accounts too many if you ask me, and at least 30 accounts to many by most standards, so we need to review and reduce this list.

Perhaps a good place to begin is by reviewing the 7 unmanaged service accounts (from various vendors), on the list.

As seen above, there are 7 unmanaged service accounts that possess this high level of privilege. During an internal meeting this was discussed and it was determined that none of these 7 service accounts actually require the ability to replicate secrets, so we agreed to take away this privileged access from these service accounts.

The only question was how do we find out which one of those 59 security permissions in the ACL of the domain root is the one that entitles these 7 service accounts to this alarmingly high level of privileged access.

Fortunately, with the tool above, all I had to do was click on the names of these service accounts, and it pinpointed the exact security permission in the domain root object's ACL that was responsible for these service accounts having such a high level of privileged access -

Here's the underlying (culprit) permission:  Allow  corp\Administrators  Extended Right - Replicating Directory Changes All


A quick review of the membership of the corp\Administrators security group confirms the finding -

As we can see in the snapshot above, the Domain Admins security group is a member of the Administrators security group, and the Privileged Service Accounts group is a member of the Domain Admins security group.

Thus, it was this nested group membership that was entitling these 7 service accounts to this privileged access.


Incidentally, I actually used the following tool to view the complete nested membership of any Active Directory Security group, because it automatically shows me the complete nested group membership of any domain security group -

But I digress.

Now, to lockdown the privileged access granted to these 7 unmanaged service accounts, I have many options -

1. I can remove these service accounts from the Privileged Service Accounts group
2. I can remove the Privileged Service Accounts group from the Domain Admins group
3. I can remove the Domain Admins group from the Administrators group
4. I can modify or remove the security permission that grants this extended right to Administrators
5. I can add an explicit deny permission denying the Privileged Service Accounts group one of these extended rights

In short, once I have enacted the above, these service accounts will no longer possess this privileged access on the domain root, and I will have reduced the number of accounts that can replicate secrets from Active Directory by 7!

Further, to verify that I correctly locked it down, I can simply run the tool again, and it will instantly show me the results.

In this manner, I can proceed to evaluate every account on this list, then make a determination as to whether or not that account requires the privilege to replicate secrets from the domain, and if not, I can lockdown access for each of these accounts, thereby substantially reducing the number of accounts with such a high level of privilege.

Most importantly, I now have complete control, because I have complete and accurate insight into exactly who has this level of privilege, and how i.e. I also know which underlying permission is entitling each such account to this privilege.

In this manner, I can eventually reduce this number down to just 2 - the System and the DC itself!



Step 3

It is important to note that it is not sufficient to merely identify these accounts and then lock the access down just once, but in fact to periodically audit who has this level of privileged access in your Active Directory.

The reason is simple - invariably, at least a few Active Directory admins and service accounts may still possess the ability to modify permissions on the domain root, and thus any action taken by them, whether intentional, accidental or coerced could change the state of access provisioned on the domain root.

In addition, any delegated admin who may be in control of a group membership that is currently granted this level of privilege on the domain root could also easily and indirectly cause the resulting effective access to change.

Thus, it is important to periodically review exactly who possesses this level of privileged access on the domain root, and as seen above, with the right tooling, it only takes a few minutes to make this determination.

We recommend that organizations review this at least on a fortnightly basis, if not on a weekly basis.




Something to Try

The accompanying lab AD Security VM is free to download and follow along this example, and others that I will be sharing.

In addition to what I have shared above, (which you can attempt with any tool of your choice), here's something you can easily try to see how the state of effective access changes, impacting who can run Mimikatz DCSync right away!

Select any existing user account from amongst the 1000+ domain user accounts in the VM and simply add this account to the IT Security Incident Response Team. 

When you do so, you'll find that this account will be able to instantly use Mimikatz DCsync against this domain!

Next, take the same account and this time around, also add it to the Contractors team.

When you do so, you'll find that the account will no longer be able to use Mimikatz DCSync against this domain!

When you add the account to the IT Security Incident Response Team, it ends up effectively getting both the extended rights needed to replicate secrets from Active Directory. Next, when you add the account to the Contractors team, it ends up being denied this very access, because the Contractors team is denied this access, so the explicit deny will override the explicit allow.

•  Note - After you are done trying, please undo both changes, because otherwise the overall state of access in your copy of the demo AD lab VM will have changed, and the results of all examples that I will be sharing in days to come will differ in your AD, making it difficult to follow future examples.

This simple experiment shows how effective permissions and actually determine privileged access in Active Directory.





Conclusion

The objective of today's post was to show you how to easily mitigate the serious security posed by Mimikatz DCSync.

We began by identifying exactly what privileged access is needed to successfully run this tool against Active Directory, and then by learning how to correctly determine exactly who has this level of privileged access in Active Directory, because once we know that, we can lock it down and be in control, knowing at all times, exactly who could do so, and how.

We also touched upon the fact that it is important to make this determination periodically, because the state of underlying access can change, either directly or indirectly, impacting this in subtle ways that may not be apparent to the naked eye.

It is also very important to understand just how dangerous a threat the use of Mimikatz DCSync poses to Active Directory and to every organization that operates on it. A perpetrator only needs to run the tool ONCE and he/she would have instantly compromised the credentials of ALL your domain accounts, from the CEO to the CISO to the Domain Admin to every employee and every service account, as well as the krbtgt account.

In short, 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.

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.

Towards that end, possibly the single most important thing you could do for your organization today is to bring this to the attention of all stakeholders, and ensure that they understand this threat and how to protect your organization from it.

Here's a post you could share internally - A Massive Cyber Breach at a Company Whilst it was Considering the 'Cloud'

That's all for now.

Best wishes,
Sanjay.

Question Zero - Who can reset the CISO's password?

Folks,

Today, I'm going to ask possibly the most simple and fundamental question one could possibly ask in all of cyber security.

Who can reset the CISO's password today?

From the Fortune 100 to every government agency in every country in the world, and at 85% of organizations worldwide that operate on Active Directory today, this is the #1 question that investors, customers and employees should be asking.


Here's why - Today cyber security undoubtedly plays a paramount role in corporate and national security, and even though organizations are collectively spending billions of dollars on cyber security, the truth is that most organizations still don't even have answers to the simplest and most fundamental of cyber security questions, and remain vastly vulnerable.

Just think - If $ Billion organizations don't even know who can reset the password of their CISO, how could they possibly know who can reset the passwords of the accounts of thousands of their employees, contractors and privileged users?


Oh, and if you don't know just how powerful a password reset is, just look at what happened in the massive Twitter breach.


You may get this response - "We don't worry about password resets because we have multi-factor authentication (MFA)."

No problem. Just ask - "Wonderful, do you know who can disable the use of MFA on your Active Directory account(s)?"
After all, all it takes is the flip of a bit on the user account, after which authentication falls back to being password based.


I ain't kidding you - Today, most CISOs most likely will NOT be able to tell you EXACTLY who can reset their passwords, or disable the use of multi-factor authentication on their accounts, or for that matter, on any of their internal user accounts, or for that matter exactly who can create, delete and manage domain accounts, computers, groups etc. in their organization.


Let me repeat that - Today, the CISO's of most organizations in the world cannot answer this question with exactness.


Here's proof - Let alone their production foundational Active Directory deployments, here is a simple lab Active Directory deployment of a fictional organization with a 1000 accounts, a 100 IT personnel, an executive team, and a CISO account.

All you have to do is ask them if their IT teams even possess the capability to correctly determine and tell you exactly how many users can reset the password of the CISO in this lab Active Directory. If they can, great, insist that they determine and tell you so, but if they can't, be very concerned, because know you too now just how little these organizations know.


Finally, ask yourself - would you invest in or trust an organization whose CISO cannot even answer such a basic question?


We're all in this together.

Best wishes,
Sanjay

Chairman and CEO,
Paramount Defenses

[Also a customer of and an investor in some of the world's largest financial institutions,
cloud computing companies, cyber security companies, airlines and other companies.]


PS: If you want to know the answer to that question, feel free to ask. i.e. feel free to first follow and then DM me on Twitter.

PS2: If you don't think exactness matters, ask yourself this - would you board a plane if I told you that the metal detector at the security checkpoint was not entirely accurate, so there's a good chance that someone onboard may have an explosive.

Day-6 - An Overview of the Active Directory Security Lab Domain

Folks,

Hello. I hope this finds you doing well. This post is Day-6 of Active Directory Security for Cyber Security Experts.


Today, I'll share an overview of the contents of the Active Directory Security Lab VM setup, i.e. the contents of the lab domain that we will be using to learn more about Active Directory security, so we are all sufficiently familiar with it.



Overview

The lab Active Directory Security virtual machine contains a Windows Server 2019 based single domain forest.

The following is an overview of this lab domain, corp.local -

1. There are 3002 objects in this domain, located in and across 277 organizational units and 141 containers
2. There are 277 OUs in a well-defined hierarchy, based on administrative delegation and GP inheritance needs
3. There are 1000 domain user accounts, including privileged, employee, contractor and executive accounts
4. There are 1191 domain computer accounts, including for laptops, workstations and  servers in data-centers
5. There are 284 domain security groups, including 50 privileged access groups and various departmental groups
6. There are 14 GPOs linked to various OUs, as well as 4 service connection points, 10 contacts and 3 printers
7. There are 5 managed service accounts (MSAs), 5 MSA groups, and 7 legacy service accounts in the domain
8. There are 100 IT personnel that are members of 33 IT security groups representing various IT/security roles
9. There are 182,866 ACEs in 3002 ACLs that specify various security permissions for various security principals
10. There are 17 default administrative (privileged access) groups that contain a total of 23 domain user accounts

OU Structure

The realistic OU structure for the corp.local domain of this fictional organization is designed based on the organization's geographical locations, administrative delegation requirements and group policy inheritance needs.

The following is how the OU structure is laid out -

1. The top-most level OU is the Global OU,  ou=global,dc=corp,dc=local
2. Within the Global OU are the OUs for each continent/region in which the company has operations
3. Within each continent/region OU are OUs for all countries in that region where the company has a presence
4. Within each country, there are OUs for each city where the company has an office
5. Within each city, there is Users OU and an Computers OU, the only exception being the San Francisco OU
6. This company is headquartered in San Francisco so its OU contains departmental OUs for various departments including Research, Development, Sales, Marketing, Finance, Legal, Human Resources, Executives, Security & IT
7. All IT user accounts, workstations and security groups are located in the IT OU within the San Francisco OU

There are several administrative delegations done in the ACLs of various OUs, including a common set of delegations on the top-level Global OU, and continent/region specific delegations at the those OU levels, and finally on departmental OUs.

The IT OU is noteworthy, for in it reside all the IT admin accounts, IT workstations, IT groups as well as all legacy service accounts. There are several delegations made in this OU to provide additional protection for IT accounts, computers and security groups. IT accounts that are members of the various default admin groups are protected by AdminSDHolder.




IT/Privileged Access Groups

There are 33 IT groups that are used to delegate administrative (privileged) access across this Active Directory domain, and they reside in the IT Security Groups OU, which resides in the IT OU within the San Francisco OU.

These 33 IT security groups span the following IT management categories and have been duly delegated/provisioned privileged access (i.e. security permissions) in Active Directory to facilitate their respective role responsibilities -

1. IT Management and Internal Audit - IT Managers, IT Service Management Team, IT Auditors, IT Contractors
2. Directory Services Management - IT Critical Infrastructure Admins, IT Directory Services Management Team
3. Privileged Access Management - IT Access Control Team, IT Admin Support Backup Team, IT Admin Support Team
4. Identity & Access Management - IT Identity Management Team, IT Access Management Team, IT Help Desk Team
5. Host Management - IT Host Management Team, IT Americas Admins, IT EMEA Admins, IT APAC Admins
6. Messaging & Collaboration - IT Exchange Admins, IT Exchange Support Team
7. Application & Database Management - IT Database Admins, IT Application Development Team
8. Security Incident and Response - IT Security Incident Response Team, IT Contingency Support Team
9. Cyber & Network Security - IT Cyber Security Team, IT Network Operations Team, IT Data Security Team, IT Group Policy Management Team, IT Executive Support Team, IT Network Security Team, IT Local Admin Teams
10. Special Operations - IT Special Ops, IT Cloud Computing Team, IT Security Analysts, IT Data Center Team

Thus, as seen above, there are numerous IT groups that have been granted various levels of access in this domain.




Administrative Delegations

As noted above, numerous administrative delegations have been done across this Active Directory domain to facilitate the access that the above mentioned groups need in order to carry out their responsibilities.

For instance, here are some high-level delegations that have been done to provision sufficient access -

1. Identity Management Team - Privileged access to be able to create, manage and delete domain user accounts
2. Access Management Team - Privileged access to be able to create, manage and delete domain security groups 
3. IT Help Desk Team - Privileged access to be able to perform password resets and unlock accounts
4. IT Admin Support Team - Privileged access to be able to manage IT/privileged access accounts
5. IT Local Admin Teams - Privileged access to be able to manage local computer accounts 
6. IT Group Policy Management Teams - Privileged access to be able to link manager GPOs and link them to OUs
7. IT Access Control Team - Privileged access to be able to modify permissions in Active Directory 
8. IT Executive Support Team - Privileged access to be able to manage high-value executive accounts
9. IT Cloud Computing Team - Privileged access to be able to integrate AD with cloud services
10. IT Special Ops -  Special privileged access to be able to perform certain sensitive operations  

In this manner, every domain security group listed above has been granted various security permissions in this domain.




Default Administrative Group Memberships

To make this lab VM as realistic as possible, just like in the real world, several default administrative groups are in use, and custom IT security groups have been made members of these groups to facilitate unrestricted privileged access.

For instance, the following are the direct group memberships of some of the default administrative groups -

1. Administrators - Administrator account, Enterprise Admins, Domain Admins
2. Enterprise Admins - Administrator account, IT Critical Infrastructure Admins
3. Domain Admins - Administrator account, IT Directory Services Management Team, Privileged Service Accounts
4. Schema Admins - Administrator account
5. Backup Operators - IT Directory Services Management Team
6. Server Operators - IT Directory Services Management Team, IT Host Management Team
7. Accounts Operators - <empty>
8. Print Operators - <empty>
9. Domain Controllers - <empty>
10. Read-only Domain Controllers - <empty>
11. Replicator - <empty>
12. Key Admins - <empty>
13. Enterprise Key Admins - <empty>

Thus, as seen above, most default administrative groups have been used as they would be in a real-world deployment.




AdminSDHolder

As you know, the ACL protecting the AdminSDHolder object in the System container is stamped on all default administrative accounts and groups and serves to provide them additional protection.

To facilitate privileged access management of these default administrative accounts and groups, as well as to explicitly prevent certain groups from having any access on them, the AdminSDHolder ACL has been accordingly modified, and includes several Deny and Allow permissions for various non-default administrative/IT groups.

Further, there are a total of 13 default administrative groups and 4 non-default administrative groups protected by AdminSDHolder, and they contain a total of 23 domain user accounts, including the default Administrator account.




Domain Root ACL

The ACL protecting the domain root object has also been modified, as is usually the case in most Active Directory deployments, and several administrative delegations have been made in this ACL.

Thus, there are many additional security permissions in this ACL, some controlling access on the domain root object itself, and other inherited permissions controlling and impacting access domain-wide.




Summary

In today's lesson, we took a closer look at the contents of our lab VM Active Directory domain so that we could become familiar with its contents. We now have a better understanding of its OU structure, its contents, administrative delegations and the existence of various custom permissions across the domain, including notably on the domain root, the Global OU, the Executives OU, the IT OU and on the AdminSDHolder object.

Further, and more importantly, as it pertains to privileged access, we know also know that there are a total of 21 domain user accounts (which includes 7 legacy service accounts) that are considered to be privileged in nature, as they are all directly or indirectly members of all default and other administrative groups that are being protected by AdminSDHolder.

However, is the real number of individuals who possess privileged access in this domain 21, or is it greater?!

Tomorrow onwards, we'll start deep-diving into various aspects of privileged access, and during these exercises, we will learn how to correctly identify and lockdown privileged access in Active Directory, and how to bullet-proof Active Directory.

That's all for now.

Best wishes,
Sanjay

The Twitter Hack - Brazen, Alarming & Unsophisticated - An Amateur Job

Folks,

Hello. Today I just wanted to take a few moments to share a few initial thoughts on the recent, brazen Twitter Breach


The Twitter Breach

As we all know, on July 15, 2020, hackers successfully breached security at Twitter and hacked the Twitter accounts of some of the world's most powerful and wealthiest people including Bill Gates, Jeff Bezos, Elon Musk, Barack Obama, Michael Bloomberg and others, as well as those of some of the world's top companies including Apple and Uber.

Simply put, hackers were able to take over the Twitter accounts of these individuals and companies, and tweet as them.

As we all know, from world leaders to business tycoons, and from government agencies to multi-billion $ corporations, literally everyone's on Twitter, tweeting their thoughts and opinions away.

Given the role that Twitter has come to play in politics, national security, business and the national and global discourse, the ramifications of such a brazen security breach, and its mere possibility, should be extremely concerning, and merit the highest scrutiny.




What Likely Happened

As brazen and alarming as it is, from a technical standpoint, it appears to have been rather unsophisticated.

Shortly after the breach, Twitter issued the following statement -

"We detected what we believe to be a coordinated social engineering attack by people who successfully targeted some of our employees with access to internal systems and tools."

Simply stated, here's what likely happened - in all likelihood, an internal corporate account of a Twitter employee who likely had some form of "privileged access" to an internal "admin tool" that could be used to manage Twitter accounts, was either compromised by using social engineering, or this individual was complicit in the hack, and essentially that one account was used to then take over a specific set of notable Twitter accounts and send a Tweet out.

For non-tech savvy folks, online writeups such as this one on Forbes or this one on TechCrunch may sound "wow", but for tech-savvy folks, this was simply a matter of someone gaining unauthorized access to an account that sufficient "privileged access" to an internal tool, and then exploiting that unauthorized access to accomplish a malicious objective.

In short, unlike most breaches, in the Twitter hack, hackers may not even have had a need to even try to compromise all-powerful privileged users who have unrestricted privileged access aka Active Directory privileged user accounts.

In the Twitter hack, all it seems to have taken is compromising a single account that just enough "privileged access" to be able to use an internal "admin tool" to manage Twitter accounts.

Pretty straight-forward and unsophisticated.



An Amateur Job

Perhaps the most amusing / confounding part of the Twitter breach seems to be that, on one hand the perpetrators had clearly demonstrated sufficient capability so as to be able to take over numerous high-profile Twitter accounts, on the other hand their intentions were simply to pull off a banal scam.

That likely indicates that whoever carried out this breach was not too savvy at all. For them to have believed that their little shenanigan wouldn't get almost immediately noticed and put to an end within minutes, only proves this further.

After all, if financial gain were their motive, one could easily have likely made millions, if not billions, just by tweeting one infactual statement from any one of these compromised accounts.

For instance, a simple "Tesla's stock is too high (again ;-))" tweet purportedly from Elon Musk's Twitter account would have caused someone who would have shorted Tesla stock (TSLA) to likely make millions within minutes.

Similarly, a simple tweet purportedly from Bill Gates' Twitter account saying "I've decided to sell all my Microsoft stock as I'm not happy with the new (substantially) privacy-invasive Microsoft" would've likely caused a sell-off in MSFT shares.

Likewise, a simple tweet purportedly from former President Barack Obama's account saying "I'll be voting for Trump because he's doing a great job at handling COVID-19. #MAGA" would have caused all kinds of mayhem in the world. ;-)

On a lighter note, a tweet purportedly from the wealthiest person on the planet, Jeff Bezos saying "During this crisis, I'm donating a million $ to help people in need" would've caused millions of struggling people to enjoy a light-hearted laugh :-)

You get the drift - the amount of financial and political damage that could have been inflicted was massive.

But none of that happened.

Instead these hackers at best attempted a banal scam that would only have worked on the most gullible of people on Twitter, demonstrating that their scam prowess is no match for their technical prowess, which in turn is no match for the prowess of real, professional hackers.

In short, this seemed like a pretty amateur job, which too is actually frightening because if amateurs could pull off such a breach, just imagine what professionals could pull off vis-à-vis being able to hijack Twitter accounts.





Was a Privileged Account Compromised?

According to an article on Forbes, titled Dissecting The Twitter Hack With A Cybersecurity Evangelist, when the article's author asked a (supposed) industry expert "what did you believe would cause such a massive hack," that expert's answer was "most likely a credential-based attack, because 80% of today's data breaches go back to privilege access use."

The expert continued "When performing reconnaissance, hackers commonly try to identify regular IT schedules, security measures, network traffic flows and scan the entire IT environment to gain an accurate picture of the network resources, privileged accounts and services. Domain controllers, Active Directory and servers are prime reconnaissance targets to hunt for additional privileged credentials and privileged access."

These days everyone seems to be an "expert" and whilst that statement is generally true, in Twitter's case, I don't think the hackers had to work that hard at all to pull off this brazen breach, which lays bare society's increasing ridiculous and frail dependence on Social Media.

While on the subject of breaches and the role of privileged access in most of them, here's something to think about -

• Fact - Almost all major recent cyber security breaches including JP Morgan, Sony Hack, Target, Snowden, the OPM Breach, Anthem, Avast, the United Nations breach etc. involved the compromise and misuse of a single Active Directory privileged user account.


• Reason -  Active Directory privileged user accounts are the crown jewels that hold the proverbial "Keys to the Kingdom," and have unrestricted access to just about everything, thus being most targeted and most prized.


• Situation - Today, at most organizations worldwide, likely no one in IT or in security has a clue as to exactly who has what privileged access in their Active Directory. We know this because over the last decade, thousands of organizations have requested our assistance (unsolicited) in making this paramount determination.

Twitter did later confirm that indeed, "The attackers successfully manipulated a small number of employees and used their credentials to access Twitter’s internal systems, including getting through our two-factor protections. As of now, we know that they accessed tools only available to our internal support teams to target 130 Twitter accounts."




A What if Scenario

Consider this. In all likelihood, like the rest of the world, even Twitter likely operates on Active Directory, which means that the entirety of their employee accounts are likely Active Directory accounts, each one having access to various aspects of Twitter's IT systems, so at least some of them obviously possess the ability to control the entirety of Twitter's over three hundred million accounts.

In a more sophisticated attack, such as the one that "expert" was alluding to, proficient hackers could gain privileged access in Active Directory, then perform simple reconnaissance to determine which Twitter employee's Active Directory account had sufficient access to control millions of accounts, and then they could have simply reset that Twitter's account's password to have an automated script run that could instantly and automatically grant full-control over the entirety of all three hundred million Twitter accounts to the hackers.

From that point on, the smartest hackers would basically just plant a backdoor designed to give them access to whatever account they wanted to, whenever they wanted it, and could use that access over time for substantial personal, financial, political or other gain.

This begs us a simple question - does Twitter know exactly how many Active Directory domain user accounts possess what level of privileged access in its foundational Active Directory?




A Wake-Up Call 

The Twitter hack should be a massive wake-up call for all organizations worldwide, and here's why -

Like Twitter, 85% of organizations worldwide, including just about every organization you can think, including all Social Media, IT and tech companies, the entire Fortune 1000, and the entire U.S. government, all operate on Active Directory.

Consider this - if the mere compromise of a single internal account that merely had just enough "privileged access" to be able to manage an internal asset i.e. an admin tool that can be used to manage Twitter accounts, just think about how much damage the compromise if an internal account that possesses unrestricted privileged access in Active Directory could do.

I'll make it simple for you - the compromise of a single Active Directory privileged user account could instantly result in a massive, cyber security breach of gargantuan proportions, because the entirety of the organization's IT assets could be exposed to the risk of compromise.

There's an old saying - "the wise learn from others mistakes," and in that regard, wise organizations should consider this a wake-up call and very seriously consider accurately identifying, minimizing and then adequately protecting each and every one of their Active Directory privileged user accounts.



Conclusion

The Twitter breach may possibly be the simplest and clearest example yet of just how much damage could be caused, and how quickly so, were a single insider account with even limited privileged access, to be compromised by hackers.

As we saw, hackers were able to take over and tweet on behalf of some of the world's most powerful business and political individuals and organizations, merely by taking over one or more insider accounts that had minimal privileged access to an "admin tool."

Fortunately for the world, whoever carried out this attack seemed to be amateur, and as a result, their motivations seem to have been purely financial, and puny at that. Perhaps they deserve the 2020 Darwin awards for Stupidity.

The fact that someone was able to take over Twitter accounts though was rightly highly concerning and alarming, and by now the FBI is also investigating the breach ; in weeks to come, exact details of just how it all happened should emerge.

We can all learn from the Twitter breach - to reiterate, it showed us just how much damage can be done by someone who could compromise even one insider account with privileged access to likely merely one asset, and just how quickly so.

In light of it, consider then, just how much damage could be done by someone who were able to compromise an account that had privileged access to just about everything i.e. what they call an Active Directory privileged user account

After all, if you don't even know who has the "Keys to your Kingdom," how can you possibly protect your Kingdom?

Best wishes,
Sanjay.

CEO,
Paramount Defenses



PS: I find it amusing that while the Gartners, Forresters, Microsofts, CyberArks, BeyondTrusts, Centrifys etc. of the world tell the world's CISOs that "Privileged Access Management" (PAM) is very important, they all seem to conveniently forget to tell them that accurate "privileged account discovery" is actually the very first step in an organization's PAM journey ;-)


PS2: I've been trying to get a simple, message across to President Trump - this Tweet.
Perhaps someone could get it to over to him. Many thanks. Maybe I'll just give him a call.

What Lies at the Foundation of Cyber Security of Microsoft, Amazon, Google and Facebook, the Tech Giants of the World?

Folks,

Today, I wanted to take a moment to share a simple fact that concerns the foundational security of the world's tech giants.

At the foundation of cyber security of Microsoft, Amazon, Google and Facebook lies a single technology - Active Directory.

Each one of these technology behemoths operates on Active Directory, and today, collectively hundreds of millions of Active Directory security permissions specified in the access control lists (ACLs) of millions of Active Directory objects in their foundational Active Directory domains collectively serve to secure and protect these organizations.

To give you some perspective, the collectively net worth of these four companies alone exceeds a Trillion dollars.

Today, literally the entire world operates on Active Directory, and today in the foundational Active Directory deployments of these organizations lie billions of Active Directory security permissions that today collectively determine exactly who has the Keys to the Kingdom in these organizations; in other words they control the foundational security of the entire world.

That's all for today.

Best wishes,
Sanjay.